월요일 아침,
프로젝트 회의가 열린다.
각 팀의 부문 PM들은 돌아가면서 현재 진척현황을 기능, 이슈, 진척을 기준으로 보고한다.
먼저 주문개발 팀의 부문 PM이 보고한다.
- - 지난 주 저희 팀은 00 기능과 00 기능에 대한 설계를 완료했습니다. 이번 주는 00 기능에 대한 분석을 시작하겠습니다.
- - 지난 주 저희 팀의 이슈는 인력지연투입 이었고, 협력업체에게
초강력 조치를 통한 결과 목요일 오후에 예정된 3명의 중급 개발자가 모두 긴급 투입된 상태입니다.
- - 지난 주 저희 팀의 목표 대비 진척율은 98%입니다. 진척율 세부사항은 어쩌고 저쩌고 ~ (총괄 PM은 세부 내용은 잘 모르겠고, 오직 98이라는 숫자가 무척 맘에든다. 그의 안면은 흐뭇한 미소로 가득차 있다.)
다음은 배송개발 팀의 부문 PM이 보고한다.
- - 저희 팀은 00 기능은 분석을 마무리했으며 이번
주부터 설계를 시작할 예정입니다. 따라서, 분석담당자 중에
한 명만 남기고 전원 철수시킬 예정입니다. 00 기능은 설계완료 후 검토를 마쳤습니다. 따라서 오늘부로 설계담당자 1명을 제외하고 모두 철수할 예정입니다. (총괄 PM은 인력이 빠진다는 소리에 왠지 기분이 좋다. 예산이 절감되는 듯한 느낌이다.) 00 기능은 업무분석가 투입의
지연으로 분석을 진행하지 못하고 있습니다. 다음 주에 투입될 예정이며 따라서 이 기능 관련 작업은 현재
진행을 못하고 있습니다. (총괄 PM의 표정이 굳어진다.)
- - 저희 팀은 계획에 따라서 분석, 설계 담당 인력 5명이 오늘부로 철수하고, 개발자 10명이
오늘 오후 투입될 예정입니다. 초급 여섯에 중급 세 명, 고급
한 명입니다. 지난 주 협력업체와 단가 문제로 약간의 갈등이 있었습니다. 따라서 중급 2명을 초급으로 대체하여 해결했습니다. (총괄 PM이 묻는다. “예산은
초급이라도 중급으로 투입해야 하는 것 아닌가? 그 업체 사장 좀 만나야겠는데.”) 아, 예, 그래서
고초급[초급 엔지니어를 3단계로 분류했을 때 가장 높은 수준의
초급, 즉 5년차 또는 6년차
엔지니어] 으로 투입하였습니다. (총괄 PM이 다시 묻는다. “저기 11년차
고급은 왜 들어오나? 저런 사람은 나이만 많고 일은 잘못할 것 같은데.”)
인력투입 계획표에 그렇게 되어 있습니다. (총괄 PM은
동의하는듯 고개를 끄덕인다. 하지만, 뭔가 마뜩찮다.)
- - 지난 주 저희 팀의 목표대비 진척율은 94%입니다. 진척율 세부사항은 어쩌고, 저쩌고, (“그만! 김차장 지금 제 정신이야? 94%가 뭐냐고, 엉, 1% 정도는 조금만 더 분발하면 메울 수 있는 것 아니야? 내가 뭐라고 그랬어, 목표대비 오차허용치는 5%라고 그랬지. 그런데 어떻게 94%의 진척율을 가지고 회의 들어올 생각을 했어?” 목소리가 높아지는 시점에서는 수첩을 들어 책상을 탁탁 두드린다. [이후 20분 동안 잔소리는 계속된다] “알겠어, 나의 오차 허용치는 5%란 말이야. 다음 팀 보고해. 지금부터는 진척율만 보고해”)
클라우드 시대로 광속으로 진입하는 이 때, 우리는 아직도 진척율 98%를 향유하며 98%를 노래한다.
모든 일이 끝나지는 않지만 거의 다 끝나가고 있다. 언제나 거의 다 끝나가고 있다. 98%만큼이나.
실제 진척도와 보고 진척도 간의 차이는 프로젝트 규모가 클수록 더 커지는 경향이 있다. 따라서 월 기준 100명 이상이 투입되는 프로젝트에서는 거의 허위보고라고
할 정도의 차이를 보여준다. PM은 이런 상황에서 팀을 리드하고 있다.
때로는 PM이 이런 곡선을 창조해내는 주인공이 된다. 아마도, 이것을 프로젝트의 가장 큰 리스크로 봐야하지않을까. 더욱이 프로젝트
규모가 클수록 고객사의 일반관리자 또는 영업관리자가 PM 역할을 맡는 경우가 많다. PM이 되면 누구나 PM처럼 행동한다. 하지만, PM처럼 사고하지는 않는다.
프로젝트 초기의 n주차부터의 매주 진척률 보고 수치,
-
n+1주차: 진척률 23%, 목표대비 진척률 100%
-
n+2주차: 진척률 26%, 목표대비 진척률 98%
-
n+3주차: 진척률 28% 목표대비 진척률 98.5%
프로젝트 종료일을 앞둔 m주차부터의 매주 진척률 보고 수치,
- m+1주차: 진척률 98.1%, 목표대비
진척률 98% (여전히 98%...)
- m+2주차: 진척률 98.4%, 목표대비
진척률 95% (위험감지! 하지만 혼나고 싶지 않다.)
- m+3주차: 진척률 98.5%, 목표대비
진척률 95% (위험감지! 하지만 혼나고 싶지 않다.)
시간은 흐른다. 프로젝트 계획 종료일 아침, 여느 때처럼 프로젝트 회의가 열린다. 하지만, 분위기는 심상치 않다. 보고가 시작된다. 총괄 PM은 화난 표정을 감추려는 듯 눈을 감고 있다.
- 주문개발팀 PM: (자신감을 잃은 목소리로) “이번 주는 프로젝트 종료일로써, 진척률 100%이며, 목표대비
진척률 역시 100%입니다. 하지만, …”
- 총괄 PM: (흥분하여 벌떡 일어서며) “진척률 100%라고? 좋아 100%라고
하자, 그럼 아직도 개발하고 있는 저 300명은 뭐야? 왜 철수 않하는거야?”
- 배송개발팀 PM: (기어들어가는 목소리로)“테스트 중입니다.”
- 총괄 PM: (목소리가 더 커진다) “프로젝트 종료일이 오늘인데, 그럼 테스트는 프로젝트 종료하고 하나? 테스트는 프로젝트가 아닌가?”
- 배송개발팀 PM: (기어들어가는 목소리로) “개발은 끝났지만, 시스템의 품질을 높이기 위해서, 각 회사가 자발적으로”
- 총괄 PM: (흥분하여 이성을 잃은 듯이) “모두 다 나가! 프로젝트 끝났다고 했잖아. 100%라고 했잖아. 끝났으니 모두 나가란 말이야…“
98%를 위한 담합
보고라는 형식을 취하는 순간, 실제 진척률 수치는 떠나고, 보여주고 싶은 수치나 기대하는 수치가 그 자리에 들어선다. 소프트웨어
개발에서 진척이란 것은 보이지 않으므로 이러한 담합이 언제든 가능하다. 우쭐대고 싶은 PM과 겁 많은 PL의 담합은 오늘도 여기저기서 이루어지고 있다. 그 담합은 아주 달콤한 것이다. 98%가 주는 느낌만큼….
해결책
진척도는 보고하는 것이 아니라 자동으로 집계되는 것이어야 한다. 그래서
보고수치와 실제 현황 수치를 맞추어야 한다. 보고를 통한 진척현황 파악이 아니라 자동으로 집계할 수
있는 어떤 장치를 마련해야 한다. 조직마다 그 접근방법은 다를 것이다.
어느 증권사에서 프로젝트 진척률 자동집계 시스템을 갖추었다. 진척률
그래프에 이전에는 보이지 않던 붉은 색 막대기[지연을 의미함]가
등장하기 시작했다. CIO가 말하기를
“드디어 내가 할 일이 생겼군, 녹색으로 바꾸는 일은 내가 가장 잘 할 수 있지.”
CIO는 담당 PM과 면담을 한 후, 해당 프로젝트의 진짜 문제를 파악하고 해결하는데 지원을 아끼지 않으므로써 막대기의 색은 점점 녹색으로 변하기 시작했다고 한다.
목표대비 진척률 34%라고 보고할 수 있는 보고문화가 필요하다. 하지만 그런 솔직한 보고문화는 오랜 세월이 필요할 것이다. 환경으로 문제를 풀어가는 것이 쉽지 않을까. 그래서 우리에게는 프로젝트 진행 현황을 있는 그대로 볼 수 있도록 만드는 가시화(Visualization) 환경 같은 것이 필요하다. 그러면 34%라고 하는 중압감도 없을테니까...
레알 진척률을 꿈꾸며…
[마흔살 엔지니어]
'SW 현장통신' 카테고리의 다른 글
소프트웨어 엔지니어 버전(Version) (2) | 2011.07.11 |
---|---|
1인 개발자의 꿈 (4) | 2011.07.01 |
개발자, 그대는 영원한 TF (0) | 2011.07.01 |
소프트웨어 프로젝트에 대한 또다른 메타포 (3) | 2011.06.23 |
기기묘묘한 아키텍트의 역할 (6) | 2011.06.22 |