이 책은 소프트웨어 개발 프로젝트에 대한 이야기이다. 프로젝트를 진행하며 지켜야할 것들, 프로젝트를 성공시키기 위해서 해야할 일들을 깔끔하게 정리하여 우리에게 전달하고 있다. 일반적으로 프로젝트 진행이나 관리는 프로젝트 관리자가 하는 것으로 알고 있다. 아니, 어쩌면 우리는 프로젝트 관리는 프로젝트 관리자만 하는 것이라고 생각하는지도 모른다. 하지만, 이 책에서는 프로젝트를 제대로 관리하고 성공시키기 위해서는 프로젝트 관리자 뿐만 아니라 프로젝트에 참여하는 모든 구성원들이 함께 노력하고 진행해야 한다는 점을 강조하고 있다.
'소프트웨어 상품 기능'에 대한 우리의 기대는 '프로젝트 수행 기준'에 비해 놀라울 정도로 엄격하다. 소프트웨어를 사용하는 사람들은 소프트웨어가 다운되지 않고 오류 없이 수행되길 기대한다. 그러나 소프트웨어를 개발하는 사람들이 프로젝트에 바라는 기대치는 아주 낮다. 사용자나 고객은 프로젝트가 1개월 또는 3개월, 6개월 지연되었을 경우에 불만을 나타낸다. 또한 사용이 불편하거나 몇 가지 중요한 기능이 빠져 있으면 불만을 토로한다. 그렇지만 계획된 소프트웨어의 상당 부분을 완성하면 성공적이라고 생각한다. 수단과 방법을 가리지 않고 엄청난 비용을 들여서라도 완성된 경우 사용자 대부분은 그 프로젝트를 성공적이라고 생각한다. 우리는 실패를 너무나 많이 겪어 왔기에 완전히 무너진 경우에만 실패라고 보는 것이다.
소프트웨어 프로젝트 생존전략, 스티브 맥코넬 지음, 김덕규 외 옮김, 인사이트, 2003년 8월, 26쪽.
남의 일 같지가 않다. 바로 우리들의 생각이 이렇지 않나 싶다. 개발 절차가 어떻게 되든, 프로그램 내부 구조가 어떻게 되든, 개발 과정에서 어떤 일이 있든, 그저 제대로 동작하고 프로젝트 기간만 최대한 맞추면 성공했다고 생각하게 된다. 하지만, 정말 성공한 것일까? 물론 제대로 동작하지도 못하고 기간도 맞추지 못한 경우가 허다하다. 이런 경우에 비한다면야 성공적인 프로젝트이지만, 과연 이런 식으로 얼마나 버틸 수 있을까.
이 책을 읽으며 많은 생각을 했다. 현재 진행 중이 프로젝트와 비교하며 생각을 하니 마음이 답답하기까지 했다. 분명 책에서 말하는 것처럼 하는 것이 원칙이라는 것을 알고는 있지만, 현실적으로 이런 식으로 작업하기는 거의 불가능하다. 기간의 문제, 비용의 문제, 개발 인력의 문제 등 현실의 문제들로 인해 우리가 하고 있는 프로젝트는 누더기가 되어가고 있다.
과정보다는 결과를 중시하고 미래보다는 현재만 편하고자 하는 개발자들과 관리자들 덕분에 현재 우리의 프로젝트 개발 절차는 난잡하기 그지 없다. 이 책은 개발자와 프로젝트 관리자 뿐만 아니라 의사 결정 권한이 있는 사람들이 꼭 읽어봐야 하지 않을까 싶다. 초기에는 어렵고 힘들겠지만, 이런 절차와 방식이 정착되면 효율이 좋아지고 비용도 절감할 수 있다는 사실을 알아야 할 것이다.
이 책에서는 책 앞부분에 "생존 테스트 문제"라고 하여 아래의 문제들에 대해 물어보고 있다. 한 번 이 물음들에 대해 "예"라고 자신있게 답할 수 있는 항목들이 얼마나 되는지 확인해보라.
요구사항 (Requirements)
- 프로젝트에 대한 명확한 비전이나 임무(mission)가 있는가?
- 팀 구성원 모두가 제시된 비전을 현실적이라고 생각하는가?
- 고객 쪽 입장에서 얻게 되는 비즈니스적인 이점과 그 이점에 대한 측정 방법이 상세하게 제시되어 있는 사업계획서(business case)가 있는가?
- 실제 시스템이 갖는 기능을 실질적으로 명확하게 보여줄 사용자 인터페이스 프로토타입(user interface prototype)이 있는가?
- 소프트웨어 명세(software specification)는 상세하게 문서화 되어 있는가?
- 팀원들은 소프트웨어의 실제 사용자(end user)와 프로젝트 초기에 면담을 했는가? 또 이들이 프로젝트 전반에 걸쳐 지속적으로 참여하는가?
계획 (Planning)
- 소프트웨어 개발 계획이 상사하게 문서화 되어 있는가?
- 작업(task) 목록에 설치용 프로그램 개발, 이전 버전에서 신 버전으로의 데이터 변환(conversion), 제3자 소프트웨어와 통합, 고객과 회의, 기타 사소한 일까지 모두 포함되어 있는가?
- 일정과 예산 추정치를 가장 최근에 완료한 단계에 공식적으로 업데이트(update)했는가?
- 프로젝트의 아키텍처와 설계를 상세하게 문서로 만들었는가?
- 시스템 테스트는 물론이며 설계 및 코드 리뷰(review)까지 요구하는 상세한 품질 보증 계획(QAP, Quality Assurance Plan)이 문서화 되어 있는가?
- 각 단계(stage)별로 어떤 소프트웨어가 구현되고 납품될지 상세히 설명한 단계별 납품 계획이 있는가?
- 프로젝트 계획에 휴일, 휴가, 병가, 교육 등의 기간을 포함시켰는가? 자원의 할당은 100퍼센트가 안 되도록 하였는가?
- 일정을 포함한 프로젝트 계획은 개발팀, 품질 보증팀, 기술 문서화팀(technical writing team) 같이 관련된 모든 사람들의 승인을 얻었는가?
프로젝트 통제 (Project Control)
- 의사결정 권한을 가진 임원 1명이 프로젝트를 챔임지는가? 또 그 임원은 프로젝트를 적극 지원하는가?
- PM이 프로젝트에 열중할 여건이 조성되어 있는가?
- 일의 완성(100퍼센트) 여부를 파악하기 위한 명확하고도 상세한 마일스톤(binary milestones)이 정의되어 있는가?
- 프로젝트 이해 관계자들이 마일스톤 완성 여부를 쉽게 파악할 수 있는가?
- 팀원들이 무기명으로 직속상사나 상급 관리자에게 문제점을 보고하고, 그 결과를 피드백(feedback) 받을 수 있게 되어 있는가?
- 소프트웨어 명세서 변경을 통제하는 계획이 문서화 되어 있는가?
- 변경 요청 사항을 수용하거나 거부할 수 있는 최종 권한을 가진 변경통제위원회(CCB, Change Control Board)가 있는가?
- 작업량(effort, 공수)과 예상 일정, 업무 분장(task assignment), 계획 대비 진도 등 프로젝트 현황을 팀원들이 알 수 있는가?
- 소스코드의 개정 통제(revision control)는 자동화되어 있는가?
- 오류 추적(defect tracking) 소프트웨어, 소스코드 통제(control), 프로젝트 관리 소프트웨어 등 프로젝트 수행 환경(project environment)에 대한 기초적인 자동화 도구가 준비되어 있는가?
리스크 관리 (Risk Management)
- 계획서에 리스크 목록이 명확하게 제시되어 있으며 최신 상태로 업데이트 되고 있는가?
- 리스크 식별 책임이 있는 리스크 관리 책임자가 있는가?
- 하도급이 필요한 경우 협력 업체 관리 계획과 당담자가 있는가?
인력 (Personnel)
- 프로젝트를 완료하는 데 필요한 모든 기술력(technical expertise)을 보유하고 있는가?
- 팀원들은 소프트웨어가 운영될 업무 환경에 대한 전문지식을 보유하고 있는가?
- 프로젝트를 성공적으로 이끌 기술 리더가 있는가?
- 요구된 모든 과업을 수행할 인력은 충분한가?
- 팀워크는 좋은가?
- 팀원들이 프로젝트에 전념하고 있는가?
소프트웨어 프로젝트 생존전략, 스티브 맥코넬 지음, 김덕규 외 옮김, 인사이트, 2003년 8월, 36쪽.
'Books' 카테고리의 다른 글
| 뮤지컬을 꿈꾸다 (0) | 2009/10/10 |
|---|---|
| 집단지성이란 무엇인가 (2) | 2009/10/08 |
| 소프트웨어 프로젝트 생존전략 (2) | 2009/10/02 |
| 설득의 심리학 (2) | 2009/09/27 |
| 유쾌한 심리학 (0) | 2009/09/22 |
| The Link (4) | 2009/09/15 |
Recent comment