Blog

비정상이 정상이 된 일정 산정 방식

December 15, 2014

비정상이 정상이 된 일정 산정 방식

나는 기획자다. 그런데 개발을 조금 할 줄 안다는 이유로 개발이 매우 어렵다는 것을 알고 있고, 그 덕분에 나도 모르게 개발자 마인드를 갖게 됐다. ‘A방식은 B방식보다 어려우니까’, ‘B방식 대비 A방식은 여러 담당자들의 손을 거쳐야 하니까’ 등의 이유로 나도 모르게 내 기획에 제한을 두고 있다. 조금의 고민 끝에 “필요없는 것 같으니까 그 기능은 빼자, B방식으로 해도 충분할 것 같다”는 말을 어렵지 않게 한다.

기획자란 직업은 디자이너와 개발자, 영업부서 사이에서 말을 옮기며 협의하는 일이 상당부분을 차지해서 솔직히 일이 재미있지는 않다. 유일한 매력요소가 프로페셔널한 디자이너와 개발자를 통해서 내 돈 안 들이면서 내가 만들고 싶은 것을 만들 수 있다는 것인데, 나도 모르게 제한을 두니 매력요소를 스스로 없애는 꼴이다. 제품이 좋은 반응을 얻으면 모두가 win-win하는 것인데, 왜 나는 내 직업의 유일한 재미마저 죽여가며 이러고 있을까. 개인적인 재미도 잃을 뿐만 아니라, 성과조차 나지 않을 수 있으니 여러모로 안 좋다. ( 물론, 내 기획대로 안 해서 더 잘 될 수도 있다 :) )

나름대로 고민해서 내린 결론은, 내가 사람이 좋아서 그러는 것이 아니라 시작부터 일정 산정이 잘못 됐기 때문이다. 프로젝트 발의 부서와 프로젝트 수행 부서 (개발팀)가 다르다. 다른 것이 문제가 아니라 전혀 교류조차 없다는 것이 문제다. 발의를 해서 진행이 되게하려면 상부의 결재가 필요하다. 결재를 하기 위해서는 이 프로젝트에 얼마의 돈이 필요한지, 얼마를 벌 수 있는지, 언제부터 벌 수 있는지에 대한 데이터가 필요하다. 이 데이터가 문제다. 얼마의 돈이 필요한지, 그리고 언제부터 벌 수 있는지.

IT에서는 투입 자본금이란 것이 달리 없다. 개발자다. (그래서 리소스라는 말을 쓰는 것 같은데, 이 말의 거북한 뉘앙스에 대해서는 또 나중에 말할 기회가 있을 것 같다) “얼마의 돈이 필요한지”라는 질문은 “몇 명의 개발자가 프로젝트에 참여할 수 있는지 ?”와 같고, “언제부터 벌 수 있는지”는 “예상 가능한 개발 완료 시점은 ?”과 같다. 이 2가지 질문은 무엇을 만들어야 하는지 알아야 대답할 수 있는 질문이다. 무엇을 만드는지 모르는데, 언제까지 만들 수 있을지 어떻게 말할 수 있으랴. 집은 집인데 3층짜리인지 10층짜리인지 알려주지 않으면, 완료 시점을 당연히 알 수가 없다.

이런 비유를 예로 들면, 이 당연한 소리를 왜 이렇게 길게 하느냐는 소리를 듣기 십상인데, 현실에서는 이런 일이 비일비재하다. 발의 부서에서는 무엇을 할지 머릿 속에 모호하게 있지만, 결재를 받기 위해 완료 시점을 정한 상태로 커뮤니케이션을 시작한다. 수행부서는 전혀 모르고 있다가 개발 완료 일정만 전달 받는다. 자세한 설계도도 없이 집 짓는다는 말과 함께. 그야말로 비정상이 정상이 된 셈이다. 이런 업무 절차가 정상이 된 경위는 나도 모르겠다. 하지만, 비정상인 것만큼은 확실히 알겠다. 이런 환경에서는 100만큼 기획을 해도, 일정 상의 이유로 반 이상이 잘려나간다. 아니, 정확히는 일정 상의 이유로 언제 올지 모르는 Phase 2 로 미루는 것이 그 중 절반이고, 나머지 절반은 실제로는 일정 때문인데 다른 번듯한 이유로 돌려서 커뮤니케이션하고 있다고 생각한다. 그런 커뮤니케이션 속에서 기획자는 이쪽 저쪽 다니면서 같은 말을 반복하고.

결국, 사용하기 쉬운 기획보다는, 어쨌든 돌아가는 기획안으로 채택된다. 새로운 방식은 일정을 예상하기 어려우니 남들이 했던 안전한 것 위주로만 만들게 된다. 어드민의 사용성은 완전히 뒷전이라서 운영 부서는 점점 수작업이 늘어난다. 결국은 안 쓰는 어드민 메뉴만 한 트럭이 된다. 이 모든 것이 단지 완료일정을 고정시켜놨기 때문이라고 단정지을 수는 없지만, 상당히 큰 영향을 미치고 있다고 생각한다.