완벽한 계획보다는 괜찮은 계획의 반복

PM 일을 하면서 고집하는 것이 하나 있다. 바로 팀이 해야 할 일을 단순하게 유지하는 일이다. "그건 나중에 합시다"라는 말을 꽤 자주 한다. 미루는 게 별로 안 좋게 들릴지는 몰라도 많이 한다.

나는 단순한 해결책이 부풀어 오르지 않도록 주의한다. "이런 기능도 있으면 좋지 않을까?" 같은 논의가 반복되며 원래의 의도에 비해 거대해지는 것을 경계한다.

왜 항상 풍선처럼 부풀어 오르는 것일까 고민해 보았는데, 그것은 부가적으로 언급된 내용들이 있으면 정말로 좋기 때문이다. 있으면 좋을 것을 거부하기란 쉽지 않다. 그리고 "이왕 할 거..."라며 문서에 이것저것 더하는 것이 별로 어렵지 않은 것도 한몫한다. 겨우 한 줄 더 추가하는 거니까.

문제는 기획된 내용을 실제로 개발해야 할 때다. 원래는 '유저가 의견을 제출할 수 있는 폼을 추가한다'에서 끝나는 이야기였는데, 어쩌다 보니 담당자 배정, 이메일 알림, 날짜별 정렬 등 부가 기능까지 만들어야 한다. 기획자들 눈에 그 기능들의 존재는 이미 당연하다. 회의를 반복하면서 눈에 익숙해졌기 때문이다. 그러나 막상 개발을 시작하면 요구사항 한 줄 한 줄이 나름의 복잡성을 지닌다.

물론 이론적으로는 모두 가능하다. 완벽한 기획 문서를 기반으로 모든 실행단계가 명확하도록 준비해 그대로 실행하기만 하면 된다. 그러나 그런 완벽성은 현실성이 떨어진다. 완벽한 짜임새로 작성했다고 한들, 그 문서를 읽는 이들은 각자의 논리와 개념으로 이해한다. 한 번에 모두가 동일하게 이해하는 결말은 그야말로 기적이다. 거의 일어나지 않는다.

아무리 명확하게 써 놓았다 해도 질문이 발생할 것이며, 모두가 동일한 내용으로 이해하기 위한 추가 커뮤니케이션이 필요해진다. 추가되는 회의가 시간을 잡아먹는다. 또 중간에 누군가 병가를 내면 그 사람을 위한 별도 커뮤니케이션도 필요하다. 일이 복잡할수록 말하는데 시간을 할애해야 한다. 개발 중 예상치 못한 오류가 발생할 확률도 높아진다.

그래서 나에게 "그건 나중에 합시다"라는 말이 유용하다. 왜냐하면 나중에 해도 되는 일은 나중에 해도 되기 때문이다. 차근차근 쌓아가는 것이 한꺼번에 몰아치는 것보다 느리게 보일지언정 효율적일 수 있다. 몰아쳐야 할 때야 몰아쳐야 하지만, 항상 그럴 필요는 없다. 내용이 단순할수록 설명할 필요가 없어지고, 설명할 필요가 없어지면 회의가 반복되는 일을 막을 수 있다. 나는 다 같이 내용을 확인하기 위한 회의가 정말로 싫다.

어차피 만들다 보면 생각지도 못한 문제와 디테일이 튀어나올 수밖에 없다. 외부 환경에 의한 변화가 있을 수도 있다. 우리는 신이 아니니 모든 걸 예측할 수 없다. 계획은 결국 수정될 수밖에 없다. 그러니 완벽한 계획보다는 괜찮은 계획의 반복이 더 낫다는 것이 나의 결론이다. 반복해서 설명해야 겨우 이해가 되는 내용이라면 그것은 좀 더 단순해져야 하는 일일지도 모른다.