프로젝트 개발 범위를 정할 때 '예산'을 고정시켜놓고 이를 기준으로 의사결정을 하는 것이 좋습니다. 저희처럼 고객사의 프로젝트를 진행하는 경우는 고객사의 개발 예산이 통제변인이 될 것이고, 회사 내부 개발팀이 진행하는 경우에도 우선순위와 투입 예산을 정해두면 그에 맞는 개발 범위, 일정, 기대치를 도출해내기 수월할 것입니다.
당연한 얘기라고 볼 수도 있지만 '예산'이 고정되어 있지 않은 경우가 종종 있습니다. 예산은 충분하니 신경쓰지 말고 개발하자는 얘기는 백지 수표처럼 들리지만 사실은 논의의 기준점이 사라져 이야기가 허공에서 떠돌 가능성이 있습니다.
어느 디자인 수준으로 어떤 기능들을 포함시켜서 몇 명의 개발자를 투입해 언제까지 개발할지를 결정할 때 결정의 근거가 없는 상태가 되는 것이죠. 우선순위는 조율하기가 어렵지 않은데 우선순위 중 어느 범위까지로 정할지는 예산이 정해져 있어야만 협의하기 쉽습니다.
저희는 고객사 예산이 정해져 있지 않은 경우 5-8천만 원 정도 사이에서 예산을 정한 후 어느 정도의 디자인과 기능까지는 구현이 가능하다는 식으로 견적서를 통해 구현 범위와 개발 일정을 조율하고 있습니다. 추가적인 기능 요청이 왔을 때도 구현 수준과 구현 비용 등을 예상해서 제시할 수 있으면 추가 예산 집행 여부를 고객사가 판단할 수 있게 됩니다.
저희처럼 외부 고객사를 둔 개발사가 아니라 회사 내 개발팀이라면, 영업팀, 운영팀, 기획팀, 디자인팀, TFT 등 다양한 내부 고객들에게 요청을 받고 그 안에서 개발 우선순위와 범위를 정해야 할텐데 이 때 특히 예산을 기준으로 하는 방식이 유용합니다.
가령 A라는 요청사항을 MVP, 베타, 정식 수준으로 구현하기 위해 각각 500만 원, 천 만 원, 2천 만 원 정도의 예산이 필요하다는 식으로 측정을 해두고 MVP는 어떤 디자인 수준과 어떤 기능들이 포함되어 있는지 설명할 수 있다면 그 요청사항이 구현되었을 때의 효용과 구현 비용을 바탕으로 ROI를 측정할 수 있게 되고 구현 여부와 구현 범위, 구현 수준을 합의하는 기준이 될 수 있습니다.
개발 비용은 대부분 인건비이기 때문에 개발자들이 특정 기능 구현을 위해 얼마나 시간을 할애했는지를 측정할 수 있다면 개발비도 꽤 정확하게 측정할 수 있습니다. 저희는 10분 단위로 테스크별 업무 시간을 기록하고 있기 때문에 이를 바탕으로 비용 청구를 하고 이를 바탕으로 고객사가 의사결정을 할 수 있습니다.
이렇게 시간 단위로 측정하지 않는 회사라 하더라도 주기적인 회고를 통해 테스크당 업무 시간을 대략적으로 측정해보고 이를 바탕으로 비용 산정을 해본다면, 데이터를 기반한 의사결정과 유사한 장점을 갖게 됩니다.
이나모리가즈오 회장의 관리회계 개념에서 주장하는 것처럼, 회사나 제품 차원의 회계적인 비용과 수익을 계산하는 것을 넘어서 공정 단위로 필요한 비용과 그 공정을 통해 얻는 효용을 측정할 수 있게 된다면 감이나 목소리 크기에 의한 의사결정이 아니라 ROI에 의한 의사결정을 내릴 수 있습니다.