Talk about Software with hani

얼마 전에 제가 참여했던 프로젝트가 끝났습니다. 무사히 끝나서 천만다행이죠. 지금에서야 드는 생각이지만 약간은 무모한 프로젝트가 아니었나 싶습니다. 데드라인도 달력 위에 특정한 날짜로 고정되어 있었고, 개발범위도 협상가능하지 않았으며, 프로젝트 예산조차도 딱 정해져 있었습니다.

이 프로젝트가 제안되고 프로젝트로 만들어질 때, 동료들이 “누가 PM이나 팀원이 될지 모르겠지만, 고생이 심하겠다”고 말할 때, 저도 고개를 끄덕였죠. 물론 프로젝트의 성공만을 놓고 볼 때에, 이런 프로젝트는 피해야 하는 게 상책이지만, 조직 입장에서 매우 중요한 프로젝트였기 때문에, 어쨌든 성공해야 했습니다.

하지만

프로젝트의 PL로서(그리고 실질적인 PM), 제가 낙점되었다는 희소식(?)에 ‘관조끝 고생시작’의 길로 들어섰습니다. 대개 제한인자가 많은 프로젝트에 참여하는 팀원들은, 약간의 피해의식에 빠져드는 경향이 있지만. 그나마 다행스럽게도 팀원들로서 긍정적인 동료들이 참여했죠.

겸손한 개발자가 만든 거만한 소프트웨어에서 다루었지만, 소프트웨어 개발 프로젝트에서 작업량을 예측하는 것은 매우 중요합니다. 즉 거만한 소프트웨어의 한 종류인, 품질이 나쁜 소프트웨어를 만들지 않으려면 프로젝트 기간에 품질을 확보할 있는 작업 시간이 필요 하고. 그럴려면 팀원들이 탈진하지 않고 개발 리듬을 활기차게 유지할 수 있도록, 하루 평균 8시간 정도만 작업해야 합니다.

8시간 근무를 하려면 작업량을 예측하는 작업을 먼저 진행해야죠. 즉 주어진 프로젝트 기간에 주어진 팀원들로 고객이 원하는 기능을 모두 개발할 수 있는지 우선 예측을 해야 합니다. 프로젝트 초기에 내린 작업량 예측치는 대개 틀리기 마련입니다. 예측을 하는 데 필요한 데이터가 부족하고 정확하지 않기 때문이죠.

예측치의 정확도를 높이려면, 애자일에서 하듯이 반복주기가 끝날 무렵 예측치가 얼마나 정확했는지 평가하고, 예측치의 정확도를 높이는 작업을 해야 합니다. 그리고 남은 기간 동안, 고객이 원하는 기능을 모두 인도할 수 있는지 판단해야죠. (가능할지 모르지만) 주어진 기간에 모든 기능을 인도할 수 없다면, 고객(내부고객이든 외부고객이든)과 요구사항 or 예산 or 기간을 두고 협상을 해야 합니다.

앞의 이야기는 프로젝트를 수행해 보신 분들은 거의 아시는 이야기일 듯합니다. 제가 참여했던 프로젝트처럼 지나치게 제약사항이 많은 상황에서도, 작업량을 예측할 필요가 있을까요? 작업량을 예측한다는 것은, 프로젝트를 구성하는 여러 조건들을 조정할 수 있다는 것을 가정하죠. 하지만 제약사항이 모두 고정되어 있을 때 사실 협상의 여지가 없기 때문에, 작업량을 예측하는 것은 그다지 도움이 되지 않습니다.

그렇다면 이런 상황에서, PL로서 저는 어떤 선택을 했을까요? 제약사항이 많았지만, 다행스럽게도 설계서와 비슷한 산출물을 고객이 제공했고, 전문 테스터가 프로젝트에 투입됐습니다(개발자 2명당 테스터 1명이 붙었습니다. 일반적인 프로젝트와 비교했을 때, 테스터 비율이 무척 높았죠*).

이런 호의적인 조건에 덧붙여서 프로젝트를 성공시키기 위해서, 저는 ‘과연 프로젝트를 합리적으로 끝낼 수 있는지 고민’하기보다, ‘프로젝트를 성공에 가깝게 하는 방법’들을 적용하는 데 주력했습니다. 즉 제가 프로젝트의 PM으로 참여할 때 항상 적용하는 애자일 실천방법을 조금 더 밀도 있게 적용했습니다. 이런 실천 방법으로는 스탠드업 미팅, 짝 프로그래밍, 동료 검토(Peer review), statement coverage 100퍼센트를 목표로 한 단위 테스트, 프로젝트 초반부터 테스터와 협업 등이 있었습니다.

애자일 프랙티스를 처음 경험하는 팀원들이 대다수여서, 짝 프로그램이나 동료 검토에 대해서 프로젝트 초반에는 회의적인 분위기가 다소 있었지만. 프로젝트를 시작하고 나서 2주 정도 지나자, 짝 프로그래밍과 동료 검토의 효과를 경험하고 나서, 프로젝트에는 경쾌한 개발 리듬이 형성되었죠. 그리고 다행스럽게도 프로젝트는 잘 마무리되었습니다.

세상에 협상 불가능한 것은 존재하지 않습니다. 제약사항이 많은 프로젝트라든지, 협상이 불가능하다고 선언한 고객이라도, 불가피한 상황에서 이해당사자들이 협상 테이블에 앉기 마련입니다. 그렇기 때문에, 작업량을 계속해서 예측하는 것도 도움이 될지 모르죠. 하지만 협상 테이블이 차려질 정도면, 이미 이해당사자들이 감정이 상한 상태이거나 팀원들이 탈진 상태인 경우가 흔합니다.

작업량을 예측하는 것도 어느 한편으로 도움이 되지만. 그것보다 제가 경험한 프로젝트처럼, 기민하게 프로젝트를 성공시킬 수 있는 실천방법을 적용하든가. 고객 입장에서 우선순위가 가장 높은 기능 순서대로 개발을 해서, 협상 테이블이 차려졌을 때, 협상 가능성을 높이는 편이 낫다는 생각입니다.

* 이번 프로젝트에서 어떤 식으로 테스터와 협업했는지는 다른 포스트에서 한번 다뤄 보겠습니다.

This entry was posted on Saturday, October 3rd, 2009 at 8:56 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.