프로젝트 일정관리 개선점 찾기...

안녕하세요. 기온이 많이 내려갔네요, 감기 조심하시기 바랍니다.

프로젝트 관리 , 제품 개발 프로세스 등에 관해서 일반적이고 실무적인 수준의 내용으로 진행을 해오고 있습니다.

글을 쓰면서 계속 느끼게되는 것이 아무래도 제가 좀 급한 성격이기도 하고 시간 압박을 느끼면서 작성을 하다보니 설명이 많이 부족했던 것 같고 논리의 흐름도 일정하지 않아 이해하기도 힘들었던 것 같습니다.

오늘 부터는 "일정관리 개선방법", "릴리스 이후 품질관리" 등으로 좀 더 주제를 세분화하여 범위를 좁히고

촉박하지 않은 시간대를 골라서 차분히 해 보도록 하겠습니다. 이러면 조금씩 글쓰는 게 나아지지 않을까 합니다.

오늘은 일정관리의 개선방법에 대해 어떤 방법들이 있는지 살펴 보겠습니다.

지난번 글들 "조엘 따라하기 #1" , 2, 3 에서 언급이 되었던 Time-Table 은 Work-List 를 일일 단위로 세분화하고 , 진행되는 내용을 시간 단위로 매일 업데이트 하면서 진행 내용을 관리한다고 했었습니다.

Time-Table 은 그 활용에 따라서 여러가지 용도로 쓰일 수 있는데 , 오늘의 주제인 일정관리 개선방법에

활용해 보도록 하겠습니다.

Time-Table은 시간 단위의 관리이기 때문에 최초 도입에 담당자들의 거부감이 매우 큽니다. 도입 단계에서

그 목적과 효과에 이해가 충분히 설명되지 않으면 시행을 한다고 하여도 제대로 그 효과를 보기 어렵다는

말씀을 다시 드리고 싶습니다.

Time-Table 도입에 있어 초기 관리자에게 또 하나 어려운 점이라면 일일 단위의 Work-List 를 작성하는 것이 쉽지 않다는 것일 것 같습니다. 프로젝트의 규모가 작고 Work-List 가 될 내용을 대부분 경험해 본 관리자라면 혼자서 작성해도 문제가 없겠지만 , 웹개발과 같이 기술적 폭이 넓은 경우에는 관리자의 경력이 아무리 오래 되었다고 하여도 한계가 있기 마련입니다. 예를들어 웹 디자인 경험을 해보고 각 단계을 알고 있으면 이를 일일 단위로 나눌 수 있는 관리자는 거의 없지 않겠습니까 ?

어쨌던 , 그래서 규모가 크던 작던 프로젝트의 Work-List 를 만드는 과정에는 프로젝트 팀원이 모두 참여해서 진행을 하도록 해야 합니다. 웹디자인 , 데이터베이스 설계 , UI 설계 , 웹코딩 , 비지니스 프로세스 설계 , 외부 연동 설계 , 라이브러리 사용, 테스트 등등 시간이 소요되는 모든 일들은 Work-List 의 대상이 된다고 생각하시고 프로젝트 관리자로서 모두 꼼꼼히 챙겨 보시기 바랍니다.

이런 과정을 거쳐서 Work-List 가 완성이 되면, 각 Work-List 에 예상 작업 소요량을 시간단위로 추가하고 , 담당자를 확정하고 우선순위를 매겨서 Time-Table 작성을 완성하게 됩니다. 이제 남은 일은 Time-Table에 따라서 실행을 하면 됩니다.

실행 과정에 대해서는 제가 따로 정리할 기회가 있으면 하겠지만 제 글 여기 저기 흩어져 있습니다. 블로그 글들을 간단히 한 번 둘러 보시기면 도움이 되실 수 있을 것입니다.

이제 이렇게 계획을 수행을 했을 때 ,  어떤 개선 방안을 찾는 어떤 방법이 있는 지 살펴 보겠습니다.

첫번째는 프로젝트의 종료 시점이 되면  Time-Table 이 초기의 것과 많이 달라져 있을 것입니다. 어떤 Work-List 는 초기 예상에서는 포함이 되었다가 없어졌을 수도 있고 어떤 Work-List 는 새로이 추가가 되어 있을 것입니다.

또 어떤 경우는 나누어 지거나 합쳐진 Work-List 도 있을 것입니다.

이렇게 변화무쌍한 것이 프로젝트의 특성이 아니겠느냐 하실 분도 있을 수 있는데 , 이러한 의견은 어떤 측면에서는 옳습니다. 초기의 요구사항 부터 기술적인 대처 방안들이 변화하지 않을 수가 없기 때문일 것입니다.

문제는 이러한 프로젝트의 특성을 그대로 인정하고 별다른 대책을 세우지 않는다면 발전을 기대하기는 어렵다는 것이겠지요.

과거로부터 배워 , 현실을 개선 , 발전 시켜야 하지 않겠습니까 ?

현재의 상태에 대하여 기본 가정에서 부터 문제 의식을 가지고 바라보며 , 개선을 하겠다는 의지를 가지지 않으면 발전이라는 것은 없다는 것이지요. CMM 의 최고 단계 수준이 계속 발전하는 모델이 잖습니까.

아무튼 조금 옆길로 새버렸습니다.

초기 Work-List 와 최종 Work-List가 변경이 되는데 그 변화의 폭에 주목해보면 , 예를들어 변경이 아주 많았던

프로젝트 일수록 잦은 일정 변경이 있었을 것이고 계획에 없었던 인력 이동도 많이 발생했을 것입니다.

달리 말하면 관리적으로 좀 어렵게 진행이 되었을 것이라는 것입니다. 일정 변경에 따른 계획 수정이 자주 발생하면서 이에 따른 조직의 부담이 늘어나게 되는데 이의 결과로 개발 효율이 올라가지 못하고 떨어지게 됩니다.

그러면 이러한 Work-List 변화의 폭은 어떻게 측정하고 어떻게 줄일 수 있을까요.

측정에 관해서는 아래의 수식을 살펴봐 주시기 바랍니다.

전체 Work-List 의 시간이란 최초 계획된 시간입니다.

위 수식의 Work-List 변화도는 그 값이 커질수록 예측대비 실행 단계에서의 변화가 많았다는 것을 의미하게 됩니다.

사실 변화도가 높다는 것은 최초 계획 단계에서의 예측력이 낮았다는 것을 의미하는 것이기 때문에 이에 대한 분석을 하는 것으로 개선점 발견의 시작으로 잡으시면 될 것 같습니다.

Work-List가 변한 이유는 한 두가지 이유가 아니기 때문에 이에 대한 분석이 필요합니다. 분석 결과에 가지고 그에 맞는 대책들을 마련하는 과정을 거쳐야 합니다. 이 대책들은 다음 프로젝트 진행시에 Time-Table에 반영을 하도록 하는 방식으로 프로젝트 개선 프로세스를 만들어 운용하는 방안이 있을 수 있습니다.

또한 Work-List 변화치를 관리자 또는 담당자자의 평가 지표로도 사용하는 방안이 있을 수 있습니다.

평가 지표의 명칭은 , 예를들어 , "일정 예측도" 같은 지표가 될 것입니다.

이 지표를 운영하시면서 매년 그 기준치를 조금씩 올려가는 관리 전략이 경영적으로는 중요한 의미를 가질 것입니다.

다음으로 일정 개선의 방안 두번째

프로젝트가 종료된 후에 Time-Table 상에는 예상 일정을 초과하여 , 또는 빨리 진행되는 Work-List 들이 있습니다. 초기에 너무 넉넉하게? 또는 빡빡하게 설정한 경우로 판단 되는 것 들인데요.

예를들어 8 시간을 잡은 일이 16 시간으로 종료될 수 있고 또는 4 시간만에 종료되는 것이 표에 쭉 나타나게 됩니다.

이러한 항목내에서의 예측치와 실측치의 차이를 보시면 담당자별로 다음의 세가지 패턴 중 하나를 발견하시게 될 것입니다.  

1. 대부분의 Work-List 가 계획된 시간에 완료됨.

2. 각 Work-List 의 소요 시간이 계획 대비 (+) , (-) 차이가 많이남.

3. 대부분의 Work-List 가 계획된 시간에 비하여 초과하여 완료됨.

각각의 경우에 대한 문제점과 개선 방안들에 대해 논해 보겠습니다.

1.번의 경우는 대부분의 Work-List 가 계획대로 완료가 되었기 때문에 겉으로 보기에는 전혀 문제가 없어 보입니다 만 내면적인 면을 생각해 보면 그렇지가 않습니다.

이 내용만으로 가능한 또 다른 해석은 "일정 소용 산정이 과장되어 있을 수 있다" 는 것입니다. 이런 담당자는 자신의 능력을 너무 과소평가 하거나 일에 대한 과대 평가가 원인일 것인데 주로 소극적인 업무 자세를 가지는 경우에 발생 한다고 할 수 도 있습니다. 뭔가 개선책이 필요하다고 할 수 있을 것입니다.

이런 사항이 발생하는 경우에는 점차적으로 실제 수행 시간이 예상된 시간을 초과하는 일이 발생하는 지점까지 할당된 일에 대한 소요시간을 줄여 주는 것이 좋을 것입니다. 이 방법은 프로젝트 기간이 길다면 수행중에도 가능한 운영 방안이 될 것이고 만약 기간이 짧은 프로젝트의 경우라면 다음 프로젝트에 반영이 될 수 있도록 관리를 해야 할 것입니다.

2.번의 경우는 소요시간이 계획대비 차이가 많이 나는 경우인데 , 최초 계획이 어설프게 되었거나 담당자가 자기 통제가 안되는 경우입니다. 이런 담당자의 경우는 해당 Work-List 에 대한 소요산정 내용을 다시 Review 해 보는 것이 좋을 것입니다. 아무래도 지난 경과를 가지고 팀에서 논의를 하게 되면 좀 더 나은 예측치가 되지 않을까 합니다.

물론 진행중에 별도의 시간을 내서 Review 해 보기는 어려울 수 있지만 말입니다.

3.번의 경우는 담당자 본인이 자신의 능력을 과대 평가하는 경우인데 1.번의 경우와는 반대로 예측치의 시간을 조금씩 올려서 운용하는 것이 합리적일 것입니다. 일에 대한 자세가 너무 적극적이거나 소극적인 것이 전체적으로 도움이 안되는 경우가 많기 때문입니다.

이상으로 일정 관리에 대하여 몇가지 말씀을 드렸습니다.

여기까지 읽으시다보면 "이거 너무 통제가 강한 것 같은데" 또는 "가능하지 않을 것 같은데" 같은 여러가지 의견이 있을 것 같습니다.

오늘은 이만 줄이겠습니다.

제품 개발 프로세스 #4

이번엔 아마 제품개발 프로세스 끝낼 수 있을 듯..

지난번에 설계 단계까지 했었군요.

구현 단계에 대해서는 구현의 방법등과 같은 내용 보다는 관리적인 면을 말씀드리겠습니다.

일전의 글에서 개발자들에게 코드 리뷰 시간을 할당하라고 하였었는데 , 바로 이 단계에서 필요한 것입니다.

코드리뷰 일정은 이미 개발계획서에 반영이 되어 있을 것입니다. 보통 주1회 2시간 정도가 적당합니다.

그리고 구현단계 초기에는 코딩가이드에 대한 교육도 진행이 되어야 합니다.

코드리뷰에 대해서는 Fagan Inspection 과 같은 관리적, 절차적 지침도 있는 것 같고 , 코드리뷰 관리 시스템도

일부 제작이 되어 있는 것 같기도 합니다. ( 이 시스템으로 논문을 진행하시는 분이 있어서 ...^^ )

어떤 방법을 사용하든 코드리뷰의 목적을 정하고 시작하면 그 방법에 대하여는 크게 고민하지 않아도 될 것 같습니다. 다만 너무 무거운 프로세스나 시스템을 사용하게 되면 본래의 목적을 잃게 되는 경우가 있어 되도록이면

큰 제약 사항없이 진행하는 것이 좋을 것 같습니다.

코드리뷰의 목적은 크게 아래의 두가지 일 것입니다.

첫째는 코드의 품질 향상이고 두번째는 개발자간의 기술공유가 될 것입니다.

방법적으로 코드리뷰는 일주일 단위로 주기적으로 진행을 하게 되는데 , 지난 시간에 지적이 나왔거나 논의가 된 부분에 대한 결과를 먼저 공유하고 , 지난 주간에 제작된 코드를 전체 리뷰를 하는 식으로 하면 무리가 없을 듯합니다.

시간은 진행을 해보니 전체 두시간 정도가 적당하고 가능하면 개발자 전원이 모일 수 있도록 해야 효과가 커집니다. 여기서 주의하실 점은 관리자의 입장에서 코드리뷰 도중에 나오는 개발자간 커뮤니케이션을 관여하게 되면 , 구현상의 솔직한 의견들이 나오기 어렵다는 것입니다. 그래서 코드리뷰의 원활한 진행을 위해서는 관리자 참여에 제한을 두는 것도 하나의 방법이 될 것입니다. 이 리뷰의 내용은 인사에 반영하지 말란 것이지요.

코드리뷰 외에도 Pair Programming 등의 진행 기법이 있는데, 전체적으로 적용하기에는 어려운 점이 있습니다. 신규 개발자 라든지 외주 개발자가 섞인 경우 시행 해 볼 수도 있을 것입니다. ( 저는 해본 적 없습니다만 )

구현이 진행되기 전에 도움말 제작 등의 작업은 없어도 되지만 , 스타일 가이드와 그래픽등의 UI 작업은 완료가 되어 있어야 합니다. 프로젝트 관리자는 설계기간 조정과 투입인력의 배분을 통해서 이러한 팀간의 일정 연결이 잘 되도록 특별히 신경을 써야 합니다.

그리고 빌드관리 시스템을 가동하게 됩니다. 빌드관리 시스템은 일일빌드 체계로 운영하는 것이 좋으며 , 개발팀

전체가 항상 최신의 버전으로 개발에 임할 수 있도록 해야 합니다. 되도록이면 오후4시경에 빌드를 하는 것이 무리가 없을 것입니다. 오후 4시에 하는 이유는 당일 빌드는 당일에 완료해야 하기 때문이죠. 실패했더라도 수정에  필요한 시간을 주어야 하기 때문입니다. 만약 빌드가 계속 안되게 되면 그 담당자는 문제가 해결 될 때까지 퇴근 할 수 없다는 원칙은 세워 두시기 바랍니다.

이렇게 일일빌드를 체크하시며 구현을 진행하시면 됩니다. 그래서 구현단계의 마지막에 다다르게 되면 개발자 테스트 단계가 됩니다. 개발자 테스트 단계에서는 아래의 사항을 만족 할 때까지 계속 코드를 고치거나 수정을 해야 합니다.

첫째 요구사항에 나온 모든 기능이 구현 완료된 상태가 되어야 하고 ,

둘째 시스템이 죽는 Crash 레벨 버그가 없어야 하며

셋째 프로세스 진행이 중단되는 Block 상황이 발생하면 안됩니다

그리고 마지막으로 도움말 등의 텍스트 작업까지 모두 완료되어 있어야 합니다.

이 모든 조건을 만족하게 되면 개발자 테스트의 다음 단계인 QA - 알파테스트 과정으로 진입을 선언하게 됩니다. 알파테스트 단계가 되면 형상관리를 본격적으로 진행하게 되는데 , 프로젝트 관리자는 개발자에게 알파테스트의 각 단계마다 알파1, 알파2, 등과 같이 반드시 Tagging 을 하도록 지시해야 하고 이 Tagging 버전을 기준으로 테스트를 진행 하도록 합니다.

테스트 도중에 발견되는 버그는 버그트래킹 시스템을 이용하여 테스터가 등록하고 관리자가 판단하여 개발자 할당을 하고 수정이 이루어진 버그들의 숫자가 일정 수준에 이르게 되면 다시 Tagging을 하여 다음 단계 알파테스트를 진행 합니다. 이렇게 계속적인 테스트를 거치면서 구현 제품의 완성도를 높여 가는데 특정 조건이 만족되면 베타 테스트 선언을 하게 됩니다.

사업적인 면에서 보면 , 이 알파테스트 단계로 진입을 하게되면 개발팀 외에도 바빠지는 팀들이 많습니다.

기획,마케팅 부서는 런칭 준비를 해야 하고 , 영업팀은 필드테스트 대상 물색? 에 들어갑니다. 그리고 홍보팀은

언론 대응 준비에 들어가겠지요.

이 알파테스트 단계에서는 프로젝트의 일정이 오로지 개발팀의 책임이 되는데 , 이 알파테스트 또한 다음 단계인 베타테스트 진행을 위한 조건을 만족하지 못하게 되면 계속 반복을 해야 하기 때문에 개발자들이 특히 어려운 기간임에는 분명합니다.

이러한 과정을 거치게 되면 베타 테스트를 진입하게 되는데 , 베타테스트 진입에 필요한 조건은 제품마다 회사마다 다를 것 입니다. 여하튼 이 단계에서는 베타 테스트의 대상을 최종사용자까지 할 것인가 또는 QA ,테스트로만 할 것인가를 정해야 합니다. 대개의 경우 B2C 제품인 경우는 오픈베타, 또는 크로즈베타 등으로 진행을 하고 B2B 제품인 경우는 필드테스트를 진행하게 됩니다. 이 모든게 여의치 않으면 QA 테스트로 대체하기도 합니다.

마찬가지로 베타테스트에도 Tagging 이 적용됩니다. 베타1, 베타2 와 같이 말이지요.

다음으로 베타테스트가 완료되면 RC를 정하게 됩니다.

RC1 , RC2 이렇게 말이죠. ( RC : Release Candidate )

원칙적으로는 RC는 여러개가 존재할 수 있으며 , 대체로 그 중에 제일 안정된 버전을 출시합니다.

프로젝트 관리자는 최종적으로 RTM ( Release To Manufacture , Market ) 회의를 소집하게 되는데 , 이 회의에는 프로젝트 관련 모든 사람들이 모이게 됩니다. ( CEO가 참석하기도 합니다. )

RTM 회의에서는 RC에서 처리가 안 된 잔여 버그들에 대한 보고를 하고 , 프로젝트 경과 보고등을 하게되고 출시 결정이 나게되면 프로젝트를 종료하게 됩니다. 이렇게 되면 이날이 회식하는 날입니다. ^^;

출시되기 전에 제품은 정식 버전을 정하게 되는데 1.0 과 같이 두자리 부터 1.0.3.1 과 같이 네자리 또는 기타 빌드 버전을 붙여서 길게 정하는 경우도 있습니다.

이상으로 제품 개발 프로세스에 대한 소개를 모두 마칩니다.

*쓰고 나서 보니까 뒷 부분으로 가면서 속도 조절이 안되어 빠진 부분이 많이 눈에 띄이는 데 이는 틈틈히 수정해 보도록 하겠습니다.

제품 개발 프로세스 #3

오늘도 어제 못다한 개발프로세스를 계속 진행해 볼까 합니다.

어제까지의 과정을 정리해보면 먼저 제품기획이 완료되고 SRS가 작성이 되면 개발계획서를 작성한다고 했습니다. 이 단계 이후에는 각 개발 관련 팀들이 맡은 일을 진행하게 됩니다.

영업팀 : 사전 영업

마케팅팀 : 제품 마케팅 계획 수립 및 진행

디자인팀 : 제품의 UI 설계와 그래픽 작업에 착수 ( SRS에 화면 요구사항이 있습니다. )

QA팀 : 테스트 계획 및 설계 / 버그관리 계획

형상관리팀 : 프로젝트 형상관리에 필요한 소스트리를 생성할 것입니다.

빌드팀 : 통합빌드 시스템에 빌드 스크립트 작성

TW ( Technical Writer ) : 사용자 설명서 , 도움말 제작 ,  번역

고객 지원팀 : 제품 지원에 대한 가이드 작성

기술 지원팀 : 제품의 설치 사양 및 운용방법 확인 및 설치 테스트

개발팀 : 시스템 설계 - 구현 - 테스트

*상기의 제품팀명은 제가 역할에 맞도록 가상으로 만든 것입니다.

굉장히 많은 팀들이 개발에 관여하기 때문에 지난번에도 말씀드렸지만 개발계획서는 매우 중요합니다.

그래서 각 팀의 일정 준수 자체가 완벽하게 이루어지지 않으면 계획된 기간내에 출시가 안되는 심각한

상황이 발생 할 수 있습니다. 또한 프로젝트 관리자의 소속이 별도의 PMO 조직인 경우도 있지만 그렇지

않은 경우도 있어 팀간의 갈등이 생겼을 경우 이를 해결하는데 많은 시간이 소모되기도 합니다.

위와 같은 이유로 개발계획을 산정할 때 별도의 여유 일정을 잡게 되는데 , 이렇게 잡게된 여유 일정이 나중에는 출시를 기다리는 영업/기획팀과 개발팀들간에 심각한 갈등을 일으키도 하고 , 연구소(개발조직)에 대한

경영진의 불신을 불러오는 계기가 되기도 합니다. 여하튼 그런 내부적인 문제들이 발생 할 가능성이 있기

때문에 팀간의 협업, 관리자의 사내 커뮤니케이션이 매우 중요하다고 할 수 있습니다.

다시 개발팀만을 중심으로 설명을 드리면 , 이어지는 단계는 제품 설계입니다.

제품 설계 즉 시스템 설계는 정형화된 방법이 없다고 말씀 드리는 것이 옳을 것 같습니다. 다만 이러이러한

형태로 , 방향으로 가야 하다는 정도는 말씀을 드릴 수가 있겠습니다.

시스템이라는 것은 , 지난번 글 제안서쓰기에서 언급했듯이 , 더 작은 서브시스템으로 나뉘어 질 것입니다.

이렇게 나뉘어 지게 되면 각 서브시스템을 연결해 주는 인터페이스가 생기게 되는데 , 설계는 이러한 서브 시스템의 명세와 인터페이스의 규약의 합으로 정의 할 수 있습니다. 여기서 다시 서브시스템은 더 작은 서브시스템으로 나뉘게되고 계속해서 이러한 방법으로 전체 시스템을 클래스 수준 또는 모듈의 수준까지 나누는 것이 좋을 것 같습니다.

설계를 어떠한 수준까지 명세를 남겨야 되는 것에 대해서는 이견이 있을 것 같습니다. 또한 프레임워크 같은 사전 설계된 시스템을 재사용하게 될 경우에는 극단적으로 시스템 설계를 건너 뛸 수도 있을 것 같습니다.

또다른 관점으로 설계서의 작성 수준을 이야기 하는 경우도 있습니다. 구현 단계에서 외주를 이용하는 경우에 해당 할 수 있는데 이런 가정이라면 설계서의 수준은 개발계획서에 명시된 조건을 갖춘 개발자가 별도의 설명 없이도 구현을 할 수 있는 수준까지 일 것입니다.

설계에 관해서는 이것으로 줄이도록 하겠습니다.

다음 단계로는 구현의 단계입니다.

이 부분은 다음글에서 계속 하도록 하겠습니다.

제품 개발 프로세스 #2

안녕하세요. 주말 잘 보내셨는지요 ?

찬바람이 부는 게 제법 겨울같은 날씨이군요.

오늘은 지난글에 이어서 개발 프로세스에 대한 내용을 적어보려고 합니다.

요구 사항 분석 단계가 완료되고 나면 산출물이 SRS와 개발계획서라고 말씀을 드렸습니다.

SRS에 대해서는 이미 말씀드렸으니 , 오늘은 개발계획서에 대한 내용으로 시작을 하겠습니다.

기획서를 만들 때 개발비용 및 출시일 향후 제품의 로드맵등을 나타냅니다.

개발계획서는 SRS 가 완료되고 난 이후에 작성이 되는 것이기 때문에 기획서의 여러 수치들에 비해서 구체적으로 나타나게 되는데 대표적인 수치가 일정과 비용 항목입니다.

개발계획서에는 이러한 수치를 포함하여 많은 항목들이 들어가게 되지만 필수적으로 포함이 되어야 할 내용들이 있는데 아래의 사항들입니다.

1. 비용

   프로젝트에 참여하게 되는 인적요소에 대한내용

   예를들면 개발자 (외주), 디자이너 , 테스터 , QA , 형상관리 , 관리자 등이 필수로 포함이 되고 필요에 따라서 특허, 인증등에 필요한 인력도 포함됩니다.

   인적요소 이외에도 외부모듈 구매 , 테스트/개발 용 장비 구매 , 공간 확보 등의 비 인적 요소도 있습니다.

2. 일정

   프로젝트 관리자는 각 담당팀의 일정을 취합하여 조정하는 역할을 해서 전체 일정을 작성하게 됩니다.

   CPM( Critical Path Management ) 이 필요한 시점입니다. 다만 , 이 시점의 개발팀 일정은 요구분석 단계이므로 기획 단계보다는 구체적이고 상세하겠지만 , 아직 설계 단계를 거치지 않은 상태이기 때문에 정확하지 않습니다. 대체로 일정 정도의 예비일정을 가지고 있는 단계라고 보시면 됩니다. 회사의 개발 프로세스가 고도화 되어 있다면 일정 예측이 이 단계에서도 매우 정확하게 될 수 있으나 아직 국내에는 이 단계에서 정확하게 할 수 있는 곳이 없는 것으로 알고 있습니다.

   추가적으로 개발 일정에는 해당 프로젝트와 연관이 있는 프로젝트의 일정을 명기해 둡니다.

( 사전 또는 사후 연관이 있는 프로젝트 )

3. 조직

    프로젝트 수행관련 조직 체계를 지정하는 것입니다.

    일상적 보고라인 , 커뮤니케이션 라인을 표시하고 부서의 담당자들을 명기하여 프로젝트를 진행하는 팀원들이 누구인지를 한눈에 알 수 있도록 해야 합니다.

4. 유지보수 계획

    빠뜨리기 쉬운 것이 유지보수 계획입니다.

    제품은 출시 이후에 단종처리가 되기까지는 유지보수를 해야합니다. 이에 대한 담당자와 필요한 계획을 미리 세워 두어야 합니다.

5. 개발계획 변경관리 방안

    개발계획은 내.외부 요인으로 변경이 될 가능성이 많습니다.

    이렇게 계획이 변경 될 경우의 변경관리 방안을 세워 두도록 합니다.

    계획이 대폭 변경되어야 하는 상황에서는 중요한 의사결정이 이루어져야 함으로 이 부분은 신경을

    써 주셔야 됩니다.

6. 프로젝트 평가방안

    프로젝트 수행 중 또는 종료 후의 평가 방법에 대한 기준을 설정해 둡니다.

    보통의 경우 일정 준수율과 비용 집행율 등이 평가의 기준이 되고 추가적으로 고객만족도, 특허 출원 건수 등이 있을 수 있습니다.

오늘은 시간 관계로 줄이고 , 다음번에는 이어서 설계단계에 대한 설명을 드리도록 하겠습니다.

제품 개발 프로세스 #1

안녕하십니까.

12월들어 눈. 비가 오는 날이 많았는데 오늘도 여전히 날씨가 안 좋군요.

오늘은 계속 미루던 제품 개발의 절차와 각 단계에서 고려되야 할 사항들에 대하여 간단히 말씀을 드려 보고자 합니다. 먼저 제품개발의 순서는 개발하는 곳 마다 세부적으로 다를 수 있고 , 또한 어떻게 해야 된다는 정형화 된 절차도 없기 때문에 아래의 내용은 참고로만 하시기 바랍니다.

제품개발은 SW 개발이라는 부분과 제품의 기획 그리고 마케팅 등과 같은 회사의 부서들과 연결해 보면 대체로 아래와 같은 절차를 밟게 될 것 같습니다.

1. 제품 기획

2. 요구사항분석

3. 설계

4. 구현

5. 테스트

6. 출시

*7. 유지보수

8. 업그레이드 기획 --> 다시 1. 번으로 또는 단종처리

아래는 각 단계별 대략적인 설명입니다.

1. 제품기획

   이 단계에서는 최종 산출물은 제품 기획서입니다. 기획서의 주요 내용은 다음과 같습니다.

   Market : 기획의 대상이 되는 제품이 속해 있는 시장 및 규모

   Customer : 대상 고객의 분석

   Feature : 제품의 주요 기능

   Cost : 개발비용과 제반 경비

   Price : 가격 정책

   Launching Plan : 제품 런칭 계획

   *RoadMap : *필요시 제품 로드맵

   위의 사항들외에도 상황에 따라 4P, STP 등의 마케팅 전략들이 들어갈 수 있겠습니다.

   이 단계에서 제품 개발에 필요한 일정과 리소스가 대략적으로 정해 집니다. 문제는 제품 RoadMap 상의 일정과 개발팀의 운용 일정이 맞지 않을 수 있고 , 제품의 기능에 대한 상호간의 충분한 이해가 안 될 수 있습니다. 그렇게되면 원하는 일정에 제품이 안 나오거나 기능이 다른 원치 않는 제품이 될 수도 있습니다.

또 개발을 하다보면 검토되지 않았던 부분에서 기술적인 문제가 발생 할 수도 있습니다.

   이런 문제점들에 대하여 제품과 연관된 각 팀은 기획이 완료되기 이전에 충분한 커뮤니케이션이 이루어 져야 합니다. 특히 이러한 커뮤니케이션상의 문제 해결과 여러 기술적인 문제들에 사전 검토를 위하여 CTO를 중심으로한 기술위원회를 운용할 수도 있을 것입니다.

   제품 기획과 연관되는 팀으로는 영업, 제품기획, 마케팅, 개발, 디자인, QA, PM, CTO, CEO, 기술지원, 고객지원 등 회사의 거의 전 부서가 다 해당이 되기 때문에 부서간의 이해관계가 얽히는 이슈가 발생하는 경우에는 이러한 커뮤니케이션에도 시간이 많이 걸릴 수 있습니다. 빠른 진행을 위해서는 사내에 커뮤니케이션을 위한 별도의 인프라를 구현해 두는 것이 좋을 것입니다.

제품기획 단계를 거치게 되면 프로젝트 관리자가 정해지게 됩니다.

2. 요구사항 분석

   이 단계의 최종 산출물은 SRS 와 개발계획표가 될 것입니다.

   개발계획표는 저번 글에서 알려드린데로 WBS 기반으로 또는 별도의 방법으로 Time Table 형식으로 작성을 하게 됩니다. SRS에는 너무 많은 부분이 언급이 되기 때문에 전체를 열거하기는 어렵습니다만 대체로 다음과 같습니다.

   - 개요

      프로젝트 목표/프로젝트 범위/개발의 범위/수행의 범위/문서규칙/정의 및 약어/관련문서

      대상 및 읽는 방법/프로젝트 산출물/산출물 형태 및 명칭/특허 출원 유무 및 내용

   - 제품

      전체 설명/제품 조망/전체 시스템 구성/전체 동작방식

      제품 주요 기능 ( 제품의 기능리스트 )/가정과 종속 관계/하위 호환성(BACKWARD COMPATIBILITY)

   - 환경

      운영(설치) 환경/Hardware, Software 환경/제품 설치 및 설정/배포 환경/마스터 구성/배포 방법/

      업그레이드 방법/형상관리/산출물 위치/소스 위치/문서 위치/빌드 환경/버그트래킹/기타 환경

   - 인터페이스

      외부 인터페이스 요구사항/사용자 인터페이스/하드웨어 인터페이스/소프트웨어 인터페이스/

      통신 인터페이스/기타 인터페이스

   - 성능

      THROUGHPUT/CONCURRENT SESSION/RESPONSE TIME/성능 종속 관계/기타 성능 요구사항

    - 기능 이외의 다른 요구사항

       안정성 요구사항/보안 요구사항/소프트웨어 품질 특성/다국어 지원/유니코드 지원/64BIT 지원/

       제품 인증/FIELD TEST/기타 요구 사항

    - 제품 기능 상세

       대분류 기능/ 중분류 기능/소분류 기능

 몇가지만 설명드리겠습니다.

 요구분석 단계에서 가장 중요한 부분은 기능에 대한 명세를 작성하는 것일 것입니다.

위에 보시면 기능에 대하여 두군데에서 언급을 하고 있는데 첫번째는 비개발자들이 기능에 대하여 이해할 수 있는 영역입니다. "제품" 항목에 들어 있는 기능이지요. 평이한 언어로 이해하기 쉽도록 사용자(고객)의 관점에서 기능의 목적과 이용방법 실행결과등을 기술합니다. 두번째는 아래의 "제품 기능 상세" 입니다. 여기서는 입력되는 값의 범위와 오류처리 방법등의 방식으로 명세 형태로 기능을 나타냅니다.

다음으로 개요에 보시면 특허 출원 유무가 있습니다.

 제품의 기능중에서 별도의 시스템 또는 기술로 분류하여 특허로 만들어 두게 되면 향후 이 기술에 대한 적극적 권리 보호가 됩니다. 이것이 왜 SRS에 들어가야 하는지에 대한 의문이 생기실 것인데 제품으로 출시가가 되고 난 뒤에 기술특허 출원을 하게 되면 종래의 기술로 분류되어 특허가 등록이 안 될 가능성이 많기 때문입니다.

    그리고 출원 및 등록에 비용이 발생하게 되며 , 해외 출원을 고려한다면 상당한 금액이 되기 때문에 개발계획에 이 부분이 반드시 포함됩니다. 특허 진행 여부를 사전에 밝히는 것이지요.

    다국어지원 같은 경우 우리나라에서 제작이 되는 SW이므로 기본적으로 한국어를 지원하겠지만 영업상황에 따라서는 해외 전용 SW를 제작하는 경우도 있고 , 전세계 대상 제품을 만들 수도 있습니다. 지원이 되어야 할 언어의 종류에 따라서 번역, 감수 등의 비용이 발생하고 일정에 영향을 미치기 때문에 개발 계획전에 확정을 해야 합니다.

    업그레이드방법이란 이 제품이 기존 제품의 업그레이드인 경우 또는 대체 제품인 경우 어떻게 할 것인가를 정해야 합니다. 예를들어 버전이 3.0 신제품이라면 기존 1.0 부터 3.0 이전의 버전 제품들을 어떻게 할 것인가 이지요. 1.0 제품은 2.0으로 업그레이드 한 후에 3.0으로 업그레이드 한다. 등과 같은 업그레이드 방법입니다. 그리고 한가지더는 제품의 온라인 업그레이드를 지원하는 지 여부를 밝혀 둡니다. 이런 지원이 되려면 다시 업그레이드 서버의 구성등이 추가되게 됩니다.

    요구분석 단계에서는 매우 중요한 이슈를 다루기 때문에 각 부서의 담당자들이 매우 민감해 질 수 있습니다. 특히 이 단계에서 PM은 커뮤니케이션에 주의해야 합니다.

SRS에 한 줄이 추가되면 엄청난 일들이 벌어지기도 하기 때문입니다. ( EAL4 CC인증 같은 것. )

요구분석이 끝나게 되면 각 부서는 개발에 필요한 일정을 산출하여 개발 계획을 작성하게 됩니다.

보통 연관 부서가 많기 때문에 일정 조절에 많은 노력이 들어가게 됩니다.

설계, 구현 , 테스트는 다음으로 미루겠습니다.

코딩가이드 작성하고 그리고 ...

오늘은 코딩가이드 작성에 대하여 말씀 드리겠습니다.

개발 프로젝트는 코딩이 필요한 부분이 매우 많지요.

HTML , CSS , JSP , Java , C++ , SQL , Procedure , XML 등일 것입니다. 이 중에서도 JSP와 Java프로그램은 여러명이서 나누어 개발하게 되는데 , 개발자간의 코딩 스타일에 다소의 차이가 있고 개발자 자신의 스타일도 조금씩 바뀌기 때문에 유사한 형태의 코드를 만들어 내기란 여간 어려운 것이 아닙니다.

그래서 제품개발이나 서비스 개발을 진행함에 있어서 일정한 기간마다 개발자들이 모여서 그 동안 작성된 코드의 리뷰를 하는 경우도 자주 봅니다. 물론 코드리뷰의 주목적이 개발자들간의 코딩 스타일을 맞추려는 것이 아니기 때문에 그 부분에 대하여 시간을 많이 할애하지는 않습니다만 누군가 리뷰를 하게 되는 진행이라면 개발자들이 "코딩 가이드"를 한 번이라도 더 보게 될 것입니다.

사족이지만 프로젝트 관리하시는 분들은 개발자들에게 일주에 1-2시간 정도라도 코드리뷰를 할 수 있는 시간을 꼭 주시기 바랍니다. 코드리뷰를 하는 과정이 개발자들 간에 맡은 업무에 대한 비지니스 로직과 개발 테크닉등의 정보교환에  사용되는 중요한 시간이 되기 때문입니다.

코딩가이드는 코드가 필요한 모든 부문에 다 만들어 두는 것이 좋습니다. HTML 같은 경우도 별도 코딩가이드를 정해 두어야 합니다. 화면상의 특정 콘트롤의 이름이 데이터베이스의 필드명과 일치시키는 것이 디버깅 과정에서 얼마나 많은 시간을 아껴주는지 모릅니다.

여기서 주의 하셔야 할 점은 이렇게 문서로 코딩가이드를 만들어 두기만 하면 제대로 지켜지기 어렵습니다. 코딩가이드를 제대로 적용시키려면 반드시 그 가이드를 100% 적용한 샘플 프로그램을 준비하셔야 됩니다. 이 샘플 프로그램을 탬플릿으로 활용하기 때문에 프로젝트 최초의 프로그램이 될 가능성이 높습니다.

첨부의 문서는 코딩가이드의 예입니다. ( 2004년도 자료일 겁니다. )

그리고 하나는 JSP 프로그램입니다. ( 다른 가이드가 적용된 것입니다. )

Coding_Guide_C++_2.txt

index_2.jsp

사업계획서 쓰기

안녕하세요. 이번에는 연간사업계획서 쓰기에 대한 내용으로 말씀드리겠습니다.

매년 다가오는 연말에는 다들 사업계획서 쓰시는 일로 바쁘시죠.

한해의 성과를 평가 해보고 다음해 해야 할 사업들에 대한 계획을 세우는 일이라 무척 중요한 일이긴 한데 막상 시작을 할려면 어디서 부터 해야 할 지 막막한 경우가 많습니다. 특히 R&D 분야에서는 느끼는 정도가 더 심할 것 같구요.

여기서는 사업계획서의 목차나 양식을 가지고 설명을 드릴려고 하는 것은 아니고 어떠한 내용이 들어가야 한다는 기본적인 것들을 가지고 이야기를 해 볼려고 합니다. 뭐든지 기본에 충실하면 아무리 어렵게 꼬아 놓더라도 쉽게 풀수 있지 않겠습니까.

사업계획의 내용은 크게 두가지로 나눌 수 있는데 , Operation 과 Strategy 입니다.

Operation 은 매일 주별 월별 분기별 반기별 등과 같이 주기적인 일들과 프로젝트 수행 등과 같이 기간의 주기성은 없지만 계속적으로 일어나는 일들에 대한 관리에 대한 것입니다.

그렇기 때문에 그 내용은 기간별 성과를 도출하고 그 원인을 분석해 보는 것입니다. 예를들면 분기 매출 목표가 얼마였는데 실제 그 분기의 자료를 취합하여 분석을 해보니 이런 이유로 초과 달성하게 되었고 저런 이유로 미달이 되었다 하는 것을 밝히는 것입니다.

조직별로는 적게는 3-4 개에서 많게는 20개 정도의 Operation 목표치들이 KPI ( Key Performance Index ) 형태로 존재하게 되는데 개발부문에서도 이러한 KPI들이 존재합니다. 주로 효율과 관련된 것들입니다. 예를들어 품질부분에서 제품 릴리스 이후 발견되는 치명적 버그의 수 같은 것 들입니다.

두번째 Strategy 부분은 앞서의 Operation 을 어떤 이유로 바꿀 필요가 있게 되는데 이를 위한 활동이 Strategy 입니다.

위에서 예로 들었던 치명적 버그 발생율을 당해 년도에 절반으로 줄이려는 Operation 목표를 세우게 되었는데 이를 달성기 위해서는 통상의 방법으로는 안되고 기간시스템의 개선이나 업무지원 소프트웨어의 개발이 필요하게 됩니다. 이에 따르는 프로젝트가 발생할 수 있고 제품 도입이 될 수 있는 일들이 Strategy 입니다.

두개의 구분은 다음과 같은 문장을 보면 명확해 집니다.

"Strategy 는 Operation 을 변경하는 일" - 어떤 분야에서는 Strategy 대신에 Management 를 넣기도 합니다.

이 두가지를 가지고

"계획이 어떠했는데 실행이 어떻게 되었고 분석해보니 이런 저런점들이 나왔다. 그래서 내년에는 어떻게 해야 되겠다."

의 단계로 작성을 하시면 무리가 없습니다.

사업계획은 크게 위의 두가지 항목에 대한 PLAN-DO-SEE 로 구성이 되고 이런 일들을 하기 위한 인력, 비용 등이 부가적으로 포함되어 년간 사업계획이 완성되게 됩니다.

요즈음 직장인들의 근무 기간이 벤처 같은 경우는 2-3년 정도이고 대기업이라고 하더라도 5-6년이기 때문에 장기적인 계획을 세우기는 좀 부담이 되는 부분이 있습니다. 그래도 년간 사업계획은 어느 직장을 가더라도 해야 되는 것이기에 기본을 알아두면 좋을 것 같은 생각에 몇자 적어 봅니다.