Project Proposal을 하려면 우선 고객들의 요구 조건에 맞는 결과물을 만들기 위해 어떤 일들을 해야 하는지 쭉 리스트 업을 해야 합니다.
이 리스트 업 된 것을 WBS (Work Breakdown Structure) 라고 합니다.
이 WBS가 완성이 되면 이제 사람은 어떤 사람들이 얼마나 필요하고 비용은 얼마가 들 것이며 그 기간은 언제까지가 될지 계산을 할 수가 있습니다.
거기에다가 프로젝트 진행 중에 발생할 수 있는 리스크들을 정리하고 그에 대한 대비책을 정리하면 훌륭한 프로젝트 제안서를 만들 수 있습니다.
Estimation을 공부하려고 구글링을 하다 보니까 어떤 업체에서 올린 아래 글이 눈에 띄어서 정리해 봤습니다.
한정된 예산과 주어진 시간 내에 양질의 제품을 고객에게 전달하는 것은 프로젝트 가시성을 높여주고 effort의 관리토록 하고, 고객의 기대에 부응 혹은 기대를 넘어설 수 있도록 하는 estimating 접근법을 사용함으로서 가능하게 만들 수 있습니다.
내부적으로든 아니면 주문을 받았든 새로운 제품을 개발하는데 있어서 가장 어려운 부분 중 하나는 effort에 대한 시간과 비용을 정확하게 추정 산출하는 것입니다. estimation은 중요한 프로그램을 지원하고 회사차원의 결정을 만들어내고 장래의 비효율성을 피하기 위해 현실성 있고 정확해야 합니다. Syncroness는 양질의 제품을 정해진 시간과 예산에 맞춰 제공하는 경쟁력있는 성과를 보인 것이 시장에 널리 알려져 있습니다.
Estimating accurately (정확한 추정 산출)
저희들만의 estimating approch를 사용해서 프로젝트의 가시성과 effort를 적절하게 관리 감독 하고 고객의 요구에 부응하거나 그 이상의 서비스를 제공하고 있습니다. 저희들만의 approch는 명확하지 않은 요구조건이나 명확하지 않은 프로젝트 리스크 혹은 예전 방식의 막연한 전망만 가지고 있어도 정확한 프로젝트 estimate를 산출하는 것으로 정평이 나 있습니다.
Focusing responsibility
기회가 주어지면 Syncroness 는 프로젝트 리드나 프로젝트 매니저에게 해당 일을 할당 합니다. 담당자는 estimating effort 뿐만아니라 프로젝트 자체를 성공적으로 마무리하는 책임을 지게 됩니다. 고객들과 함께 일을 하면서 discovery meeting 과 기타 meeting 을 주최해 해당 제품에 대한 요구 사항들을 모두 정리하게 됩니다. 이것을 통해 어떤 특정 기술이 사용되어야 하는지 색상에 대한 마케팅 차원의 필요한 점은 무엇인지 등등을 아주 자세하게 정리합니다. 이 요구사항 리스트는 estimation과 corresponding assumption의 basis가 되며 그것을 기반으로 프로젝트를 운영하게 됩니다.
Breaking down the work
그 다음 저희는 SOW (Statement of Work)을 만듭니다. 이 statement를 통해 우리가 하려고 하는 것들이 정확하게 무엇인지에 대한 대략적인 개요를 제공합니다. 이것은 내부 팀원들에게 Tool로 사용되게 되며 Syncroness와 고객사이에 관련 내용을 명확하게 합니다. 문서에 들어가는 내용은 estimating process 동안 사용될 기본 assumption들 입니다. 그런 과정을 거쳐서 저희들은 WBS (Work Breakdown Structure)를 만듭니다. 혹은 task들의 리스트와 해당 프로젝트를 완료하기 위해 필요한 팀 내의 역할 들을 작성합니다.
Identifying tasks (task 정의하기)
이제 SOW와 assumption들이 있는 WBS를 가지게 됐으니 group estimating 세션을 주최할 수 있습니다. 이 세션들은 통상적으로 프로젝트에 참여할 멤버나 그렇지 않을 멤버 모두가 참가 대상이 됩니다. 이 그룹은 WBS의 task 별로 살펴보고 각각의 task에 대한 estimation들을 제공합니다. 프로젝트 타입에 따라 resource들은 Estimation과 함께 프로젝트를 리드해 나갈 수 있도록 시간별 estimate나 관련된 score estimate (Fibonacci)를 사용할 수 있습니다.
Assessing risk (리스크 평가)
전체 estimation에 대한 윤곽이 잡히면 이 estimation 작업을 완료하기 전에 반드시 리스크를 생각해야 합니다. 이 리스크를 identifying, evaluation, normalizing 혹은 계량화 하기 위한 여러 technique들을 저희는 가지고 있습니다. (Monte Carlo analysis, Fibonacci Analysis and contingency-based risk assessments). 이 분석은 프로젝트에 있는 'unknown unknows'에 대해 account하며 적확하고 실제적인 estimate를 제공함으로서 리스크에 대한 고객들의 의문들을 불러 일으기키는 것을 방지합니다. 이 estimation이 완료되면 effort에 대한 work과 scope을 쌍으로 기술하고 고객의 review와 approval을 위해 공식 proposal 문서로 제공됩니다.
'TDD Project > Software Estimation Model' 카테고리의 다른 글
Software Estimation Memo (0) | 2014.07.28 |
---|---|
Software Estimation Technique (1) | 2014.06.24 |