"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
많은 경우 프로젝트 실패의 원인을 요구사항 변경관리 실패에서 찾습니다. 그래서 프로젝트 초반 철저한 분석을 통해 요구사항을 확정하고 철저한 요구사항 변경프로세스로 함부로 요구사항변경을 하지 못하게 하는 경우 프로젝트가 성공하는지 생각해 보았습니다. 사실 이런 프로젝트가 현실에서 발견하기 어렵기 때문에 아래와 같이 사고실험을 해 봅니다.(이미지출처)
어떤 프로젝트가...
개발자
내게 주어진 업무를 정확하고 깔끔하게 제때 모두 끝냈것 같아. 자 봐 이렇게 완벽한 테스트케이스가 걸린 소스코드를 찾아보기란 쉽지 않을 거야. 게다가 소스코드는 누가 봐도 읽기 쉽게 깔끔하게 작성되었어. 내가 만든 소스코드 중 제일 맘에 들어.
설계자
내가 설계한 의도대로 구현까지 모두 완벽히 된 것 같아. 내가 설계한 업무에 논리적인 결함이나 빈틈이 없잖아. 게다가 업무가 어떻게 확장되든 충분히 대응할 수 있다고 봐. 하하. 이렇게 완결한 설계와 다양한 디자인 패턴을 적용한 경우는 처음이야. 다른 프로젝트에 참고자료로 쓰여도 손색이 없을거야.
아키텍트
고객이 요구한 보안이나 성능에 대한 요구사항은 충분히 만족시킨 것 같아. 고객이 예상한 사용자의 2배도 견디는 걸. 좀 사용하기 까다롭기는 하지만 시스템 접근에 대한 인증/인가도 충분해. 보안쪽이 뚫리기는 쉽지 않을거야. 만족해. 진짜 만족해
프로젝트 관리자
역시 철저한 일정관리와 요구사항 변경관리가 프로젝트 관리의 핵심이었어. 처음 계약한 대로 요구사항을 on-time에 모두 완결했어. 역시 프로젝트 관리가 내 적성인가봐. 회사에서도 이번 프로젝트로 수익이 좋게 나왔다고 좋아하는 걸...
고객
다행하게도 프로젝트는 비용넘지 않고 제 때 끝났네. 처음 그린 그림대로 잘 나온 것 같고. 그런데 처음 그린 그림대로 만들고 나니 뭔가 업무가 어색하게 돌아가네. 이런 이런 이건 현실과 좀 맞지 않은 부분이네.
그건 그렇고 오픈 한 지 한달이 넘는데 사용하는 사람이 거의 없네. 이거 핵심업무인데도 말이야. 뭐라고! 아직도 엑셀로 처리하고 있다고? 후~
모두가 각기 자신의 업무를 성공적으로 수행했고 프로젝트에 관여한 사람 모두 만족한 프로젝트입니다. 다만 고객만 좀 찜찜해 하는군요.
성공한 프로젝트 맞나요? 애매하니까 다수결로 성공했다고 치죠. -.-; 뭐가 문제인가요?
(이미지출처)
'애자일' 카테고리의 다른 글
| 실전! 플래닝 포커 (0) | 2011/11/23 |
|---|---|
| 다수결로 프로젝트가 성공한 예 (0) | 2011/10/12 |
| 급한 이벤트로 계획(스프린트)이 자꾸 망가질 때... (0) | 2011/07/13 |
| 새로운 형태의 작업이 추정이 어려울 때 (0) | 2011/07/11 |
| 애자일 게임을 하다 (0) | 2011/06/20 |
| Agile에 대한 12가지 질문들 (2) | 2011/06/13 |



