태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Search results for '프로젝트/커뮤니케이션'

회의 때문에 일할 시간이 없다.

2009.08.20 17:16 by 전규현


잠시 후 Google blogger로 이동됩니다.




경영자들은 "우리는 업무 공유가 안돼. 커뮤니케이션이 안돼" 라고 하면서 물리적으로 소통을 증가시키는 방법을 찾곤 합니다.

억지로 회의를 가지게 하고, 영업팀과 개발팀을 옆에 붙여 놓거나, 회사의 파티션의 높이를 낮추는 등의 조치를 취하기도 합니다.

회의시간을 늘인다고, 옆에 있다고 커뮤니케이션이 잘되지는 않습니다. 오히려 잦은 회의는 업무시간만 줄어들고 성격이 다른 부서들이 서로 뭉쳐 있으면 소음 때문에 개발에 방해만 됩니다. 

커뮤니케이션은 적절한 프로세스와 시스템을 통해서 해결해야 합니다. 스펙을 작성하고 리뷰할 줄도 모르는데 제품이 어떻게 만들어지고 있는지 공유가 안된다고 한탄할 수는 없습니다. 프로젝트 관리 시스템이 있다면 회사의 모든 사람들이 프로젝트 진행과정을 물어보지 않아도 훤히 알 수 있습니다. 

대화는 커뮤니케이션에서 가장 중요한 수단이기도 하지만, 가장 비싸면서 오류도 많고 휘발성입니다. 따라서 커뮤니케이션을 강화하려면 대화의 수단은 줄이고 시스템과 기록을 강화해야 합니다.

체계를 제대로 갖추고 있는 소프트웨어 회사라면 대부분의 업무가 몇 가지의 핵심 시스템을 통해서 이루어지며 대화는 꼭 필요한 경우에만 사용됩니다.

물론 당사자들이 모두 모여서 한번이면 해결 가능한 이슈를 메일이나 다른 수단을 이용해서 여러차례 반복해서 소통을 하는 것은 비효율적이죠. 하지만 반대로 시스템으로 간단히 공유하고 의견을 전달할 수 있는 것들을 만나서 해결하는 것은 더 비효율적입니다.

아직도 문제가 생기면 매일 모여서 회의하고 또 결론이 없어서 다음에 또 회의를 반복하고 정보를 공유하기 위해서 또 회의하고 개발 시간은 점점 줄어들고 이런 상황인가요? 프로세스와 시스템이 필요할 때가 된 겁니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/커뮤니케이션 시스템, 커뮤니케이션, 회의

왜 이리 버그가 많아요?

2009.05.26 23:17 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 릴리즈는 그 성격에 따라서 몇 가지 형태로 구분이 됩니다.

소프트웨어는 그 종류가 셀 수 없이 많아서 획일적으로 얘기할 수는 없어도, 릴리즈를 구분하여 부르는 것은 필요합니다. 릴리즈를 구분하다는 것은 현재 릴리즈가 어떠한 것이고, 그에 따라서 어떠한 프로세스를 따라야 하고, 어떠한 기대값을 가져야 하는지 그 이름만 들어도 알 수 있게 합니다.

하지만, 팩키지를 개발하는 소프트웨어 회사는 나름대로 릴리즈 구분에 익숙해져 있지만, SI회사, 게임회사, 포탈 등의 서비스 회사, 금융회사들은 릴리즈는 그냥 릴리즈라는 생각을 하고 합니다. 따라서 수많은 릴리즈를 함에도 불구하고 각 릴리즈를 부르는 버전도 없는 경우가 허다하고, 개발자가 임의대로 릴리즈를 하는 경우도 많습니다.

그럼 릴리즈를 어떻게 구분하여 부르면 의사 소통에 도움이 될지 알아보죠.

업그레이드 릴리즈 (Upgrade release)
계획된 일정에 따라서 제품의 주요한 기능이 바뀌어서 릴리즈 되는 것을 일컫습니다. 그 규모와 성격에 따라서 메이져 또는 마이너 업그레이드라고 하고 정상적인 개발 프로세스를 거치며 테스트로 전 기능에 걸쳐서 철저하게 이루어 지는 것이 보통입니다.
 
패치 릴리즈 (Patch release)
특정 기능에서 발생한 버그나 작은 기능을 개선한 것들을 모아서 릴리즈 하는 것을 말합니다. 보통 계획적으로 일정을 잡거나 업그레이드 릴리즈 후 고객들의 반응을 보고 패리 릴리즈 일정을 잡기도 합니다. 보통 유지보수 개발자들이 개발을 담당하고 테스트로 업그레이드 릴리즈 때보다는 간소화 하기도 합니다.

핫픽스 (Hotfix)
심각한 버그가 발견되어서 긴급하게 특정 고객을 대상으로 또는 전체 고객에게 버그를 수정한 버전을 전달하는 것을 말합니다. 이 경우 사안이 긴급하여 개발 및 테스트 프로세스가 상당부분 생략되며, 이로 이한 위험부담을 어느 정도 감수하는 릴리즈를 말합니다.

또 제품의 완성도에 따라서 알파, 베타, RC 릴리즈로 나뉠 수 있습니다.

알파 릴리즈는 제품의 기능은 구현이 다 되었으나 버그는 좀 있을 수 있습니다. 하지만, 제품을 더이상 써 볼 수 있는 정도의 심각한 버그는 없어야 합니다.

베타 릴리즈는 제품의 심각한 버그는 거의 없어서 기능을 거의다 정상적으로 사용할 수 있는 상태를 말합니다.

RC 릴리즈는 제품을 출시할 수 있는 정도로 사소한 버그가 몇개만 포함된 버전을 말합니다.

이렇게 릴리즈를 나누는 이유는 각 릴리즈에 따라서 들어가는 비용과 개발 프로세스가 다르고, 리스크가 다르기 때문입니다. 이러한 구분이 없이 그냥 개발자가 소프트웨어를 수정하는 대로 릴리즈를 하고 있다면, 테스트 등 릴리즈에 들어가는 비용을 들이지 않는 주먹구구식 개발일 가능성이 높습니다. 하지만 이러한 마구잡이식 릴리즈가 결국 더 많인 비용을 이미 지불하고 있다는 것을 알아야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/커뮤니케이션 RC, 릴리즈, 베타, 알파, 업그레이드, 패치, 핫픽스

  1. MS에서 제로데이어택을 막기위해 배포하는핫픽스도 저렇게 많은 절차를 건너뛰고 배포되는걸려나요? 확실히 저러한 배포판들을 릴리즈 하기 위한 자동화 시스템이 구축되어있다면 좋겠다는 생각이 드는군요..

  2. 구차니님 안녕하세요.
    각 회사마다 패치/핫픽스의 프로세스는 다릅니다. 따라서 절대 비교는 할 수 없어도, 핫픽스가 기타 다른 릴리즈보다 절차가 짧기는 마찬가지 입니다. 따라서 빌드/릴리즈가 자동화 되어 있고, 테스트가 상당부분 자동화가 되어 있다면 Hotfix를 릴리즈하더라도 좀더 안정적인 버전을 내놓을 수 있습니다.

  3. Blog Icon

    비밀댓글입니다

커뮤니케이션 오류

2009.04.19 23:16 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.
문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.
 
특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 
당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/커뮤니케이션 가정, 결정, 리스크, 문서, 사실, 소프트웨어, 의견, 추측, 커뮤니케이션, 표현, 프로젝트

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바