태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

  1. 2009/08/20 -- 회의 때문에 일할 시간이 없다.
  2. 2009/05/26 -- 왜 이리 버그가 많아요? (3)
  3. 2009/04/19 -- 커뮤니케이션 오류

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

2009/08/20 17:16 by 전규현
Leave a Comment
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

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

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

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

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

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

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

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

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

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

'프로젝트 > 커뮤니케이션' 카테고리의 다른 글

회의 때문에 일할 시간이 없다.  (0) 2009/08/20
왜 이리 버그가 많아요?  (3) 2009/05/26
커뮤니케이션 오류  (0) 2009/04/19

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

Trackback Address: http://allofsoftware.net/trackback/140 관련글 쓰기
  1. 2009/08/21 13:28
    Delete
    회의 관리자? Tracked from Younghoe.Info
  2. 2009/08/21 13:29
    Delete
    회의에서의 의사진행 기법 Tracked from Younghoe.Info
  3. 2009/08/21 13:29
    Delete
    지루한 회의? 효과적인 커뮤니케이션 Tracked from Younghoe.Info
  4. 2009/08/30 16:35
    Delete
    회의는 왜 하나요 Tracked from Life Algorithm
  5. 2009/10/13 08:26
    Delete
    커뮤니케이션에 관한 글 Tracked from ICT 블로그

왜 이리 버그가 많아요?

2009/05/26 23:17 by 전규현
3 Comments
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
소프트웨어 릴리즈는 그 성격에 따라서 몇 가지 형태로 구분이 됩니다.

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

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

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

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

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

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

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

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

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

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

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

'프로젝트 > 커뮤니케이션' 카테고리의 다른 글

회의 때문에 일할 시간이 없다.  (0) 2009/08/20
왜 이리 버그가 많아요?  (3) 2009/05/26
커뮤니케이션 오류  (0) 2009/04/19

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

Trackback Address: http://allofsoftware.net/trackback/124 관련글 쓰기
  1. Blog Icon
    Favicon of http://minimonk.tistory.com BlogIcon 구차니
    2009/05/27 10:13
    Reply | Edit

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

  2. Blog Icon
    Favicon of http://allofsoftware.net BlogIcon Ray.전규현
    2009/05/28 12:40
    Reply | Edit

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

  3. Blog Icon
    2009/06/10 06:02
    Reply | Edit

    비밀댓글입니다

커뮤니케이션 오류

2009/04/19 23:16 by 전규현
Leave a Comment
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.
문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

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

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

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

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

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

'프로젝트 > 커뮤니케이션' 카테고리의 다른 글

회의 때문에 일할 시간이 없다.  (0) 2009/08/20
왜 이리 버그가 많아요?  (3) 2009/05/26
커뮤니케이션 오류  (0) 2009/04/19

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

Trackback Address: http://allofsoftware.net/trackback/114 관련글 쓰기
분류 전체보기
더보기
결국 최고 걸림돌은 경영진이다.
결국 최고 걸림돌은 경영진이다. 2013/06/19

소프트웨어 회사가 제대로 개발 역량을 갖추는데 최고의 걸림돌은 소프트웨어에 대한 이해가 부족한 경영진이다. 일반 경영자들이 소프트웨어를 이해할 수 없기 때문에 CTO가 존재한다. 하지만 우리나라 대부분의 소프트웨어 회사에는..

SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까?
SRS를 개발 후에 연습하는 차원으로 적어보면 도움이 되지 않을까? 2013/06/03

소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 SRS(Software Requirements Specification) 즉, 스펙을 잘 작성하는 것이다. 그럼 SRS 작성법을 배우고 싶은데 어떻게 해야 할까? 남이..

내가 없어도 회사가 잘 돌아가면 왠지 불안하다.
내가 없어도 회사가 잘 돌아가면 왠지 불안하다. 2013/05/28

그동안 이래저래 바쁘다는 핑계로 블로그에 글을 못올리고 있다. 앞으로 짧막하게라도 글을 올리려고 한다. 내가 만약 일주일동안 회사를 안나오면 회사가 잘 돌아갈까? 그럼 한달동안 안나오면 어떻게 될까? 대부분의 소프트웨어 회사..

넣는 것 보다 빼는 것이 더 어렵다.
넣는 것 보다 빼는 것이 더 어렵다. 2013/05/14

초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다. 성공하는 회사들의 초기 제품은 간략하고 핵..

[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.
[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다. 2013/03/14

소프트웨어를 개발하는데 있어서 가장 어려운 것을 하나 꼽으라면 "요구사항분석"입니다. 소프트웨어를 개발하는데 있어서 가장 중요한 것을 하나 꼽으라도 "요구사항분석"을 선택합니다 하지만 우리나라에서 "요구사항분석" 역량을 제대..

투명한 개발 문화의 효과
투명한 개발 문화의 효과 2013/03/05

흔히 투명한 개발이 효율적이고 좋다고 한다. 그 진정한 의미를 알아보자. 투명한 개발이란 개발에 관련된 거의 모든 정보와 지식이 공유되는 것을 말하지만 추가로 내가 강조하고 싶은 것이 따로 있다. 거의 모든 결정의 과정 및..

소프트웨어공학은 실전이다.
소프트웨어공학은 실전이다. 2013/03/04

이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다. 2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요. 알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스..

거의 다 만들었어요.
거의 다 만들었어요. 2013/02/27

"거의 다 만들어서 2주후에 개발이 끝나요" 이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다. 개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다. 하지만 이런 대화는 여..

고쳤으니 테스트 해주세요.
고쳤으니 테스트 해주세요. 2013/02/18

여기 두가지 테스트 방법이 있다. 우리 회사는 어떤 방법을 사용하고 있나 생각해보자. 첫째, 테스트 도중에 버그를 고쳐서 좀더 안정된 버전을 테스트팀에 계속 전달하는 방식이다. 테스트 한사이클을 도는데 2주일이 걸린다고 생각..

인해전술이 오히려 프로젝트를 망친다.
인해전술이 오히려 프로젝트를 망친다. 2013/02/11

일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다. 프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다. 많은 인력을..