다음 마일스톤 기획서를 미리 쓰는 계획은 왜 항상 실패할까

여느 흔한, 하지만 훌륭하지는 않은 프로젝트가 마일스톤 계획을 수립하는 광경을 상상해 봅시다. 운이 좋다면 현재 빌드의 상태와 마일스톤이 끝날 때 기대하는 빌드의 상태를 비교해 이들 사이의 차이를 기능으로 정의하고 동시에 마일스톤이 끝날 때 기대하는 빌드의 상태를 런칭과 서비스에 이르는 긴 맥락 속에서 설명하는 계획을 수립할 수도 있습니다.

하지만 운이 좋지 않거나 평범한 운을 가지고 있다면 마일스톤 계획은 그저 맥락 없이 언젠가는 런칭과 서비스 단계에 도달하기는 하겠지만 그 과정 중 어디 쯤에 우리가 위치하고 있는지에 관계 없이, 또한 우리 팀의 퍼포먼스에 관계 없이 그저 기간 안에 개발해야 하는 기능의 나열일 뿐일 가능성이 더 높습니다. 어떤 과정을 거치든 마일스톤 계획은 제한된 기간 안에 개발해야 하는 여러 기능의 목록의 집합에 가까운 모양이고 계획이 수립된 다음에는 이 계획에 동의하든 동의하지 않든 회사에 소속된 이상 이 계획에 따라 행동할 수밖에 없는 상태가 될 겁니다.

한편 프로젝트를 구성하는 각 팀은 그 팀에 붙여진 이름과 원래 그 팀에 의도한 역할 외에도 상황에 따라 다양한 역할을 하기도 하는데 가령 마일스톤 계획에 따라 기능을 정의하는 문서를 쓰던 사람들은 시간이 지나면 개발된 기능과 에셋을 조립해 실제 동작하는 빌드를 만드는데 기여하고 나아가 개발된 기능을 테스트하며 기능이 게임 안에서 올바르게 동작하는 상태로 튜닝하는 역할을 담당하기도 합니다. 또 주로 코드를 작성해 기능을 만드는 역할을 하는 사람들은 종종 개발 인프라를 정의하고 유지보수하는 역할을 겸하기도 하며 종종 중요한 일정이 있을 때 즉시 해결하거나 우회해야 하는 기술적인 문제에 대응하기 위해 대기하고 있기도 하고요.

마일스톤 계획은 이런 각 부서에 명시적으로 정의된 역할에 집중해 퍼포먼스를 예상하기 때문에 꽤 자주 실제 팀이 낼 수 있는 퍼포먼스보다 더 많은 목표를 포함하게 됩니다. 가장 큰 이유는 방금 말한 명시적인 역할이 그 부서의 전체 역할이라고 쉽게 생각하기 때문입니다.

지금까지는 약간 추상적인 표현을 사용해 말하려는 주제 주변을 빙빙 돌고 있었는데 이제부터는 추상적인 단어를 줄이고 실제 사례를 가지고 표면적인 역할에 집중해 수립한 마일스톤 계획이 항상 실패하는 이유를 ‘다음 마일스톤 기획서를 미리 쓰려는 계획이 항상 실패하는 이유’를 설명하겠습니다.