빨간 여우

기획자는 기획안을 보통 고객(유저) 중심으로 작성한다.
기획자는 어떠한 기획안도 모두 개발할 수 있다고 믿는다.
개발자 또는 DBA 는 이 기획안을 보며 기술적으로 가능한지 확인하고, 가능하다면 코딩/설계에 들어간다. 개발자 또는 DBA 가 이 기획안을 보면서 답답해하거나 기획안 메일을 확인하면서 한숨을 푹푹 쉰다해도 거의 대부분 그 기획안대로 진행된다. 개발자가 아무리 답답함을 호소해도 "최대한 될 수 있게 해달라"라고 말한다. 그것도 일정에 맞춰서. 개발자와 DBA 는 밤샘작업에 들어가고, 이 작업이 마무리되면 또다른 기획안 메일이 들어와 있다.
작업이 마무리되었지만, 아웃룩을 실행시키기 싫어진다.
사람이 미워지기 시작한다.

일정의 2/3 를 기획에 사용하고, 1/3 이 개발에 들어가지만, 2/3 시간을 들여 작성된 기획안도 제대로 되지 않는다.

그래서 항상 다툰다.
해달라, 안된다, 바꿔달라, 일정에 맞추지 못한다, 어제도 밤샜는데 오늘도 밤새라는거군, 내가 만능 맥가이버라도 되는줄 아나..
그러면서 다음 프로젝트에 다음 기획안을 가지고 또 다툰다.
바뀌지가 않는다. 왜 그럴까.

기획자나 프로젝트 매니저(PM), 프로젝트 리더(PL) 들은 개발자들이 바쁘게 개발을 안하면 놀고 있다고 생각한다. 개발팀이 항상 전속력으로 담배필 시간도 없어 빠듯하게 개발하지 않는다면, 이 상황을 이해하려 하지 않는다.
"아니, 지금 일정도 빡빡한데 왜 개발이 이리 느슨해?"
그들에게 개발자가 프로젝트 방향을 이해하고 있는지는 중요하지 않다.

개발자가 개발을 하지 않는다면, 타이핑 소리가 들리지 않는다면 프로젝트 개발에 진전이 없는 상태입니다. 맞습니까?
아닙니다. 틀렸습니다.

개발하는 시간이, 코딩의 품질이 그렇게 중요하다면 기획/설계는 더 중요합니다.
엉망인 설계도를 가지고 제대로된 집을 지으라는게 대부분의 기획안입니다.
프로젝트가 일정에 뒤쳐지고 있으면 PM 으로부터 책임을 추궁당하는 사람도 개발자이지, 기획자가 아닙니다.

이런 문제를 해결하려면 기획안, 프로토타입 설계, 아이디어 회의에 개발자가 같이 참석해야 합니다. 기획자 혼자 설계하도록 만들면 안됩니다. 같이 기획안을 만들어야 합니다. 개발자도 개발 코딩 전에 충분히 고민하고 설계도를 검토할 시간을 줘야 합니다.

기획자와 개발자가 서로 필요한 것, 중요하게 생각하는걸 모두 적어 같이 확인합니다.
모두가 볼 수 있는 보드에 포스트잇으로 적고, 중요도 그룹이나 업무별 그룹을 만들어 옮겨 붙입니다.



자기가 중요하게 생각하는 부분이 다른 사람에게는 중요하지 않을 수 있으며,
자기는 당연하게 여기는걸 다른 사람은 이해 못할 수도 있습니다.
이걸 알도록 만드는게 PM, PL, 팀장의 몫입니다.

자세한건 "The Art of Project Management 마음을 움직이는 프로젝트 관리 - 스콧 버쿤, 한빛미디어" 178 페이지를 참고하세요.

* 제목을 저렇게 쓰고 나니 좀 이상하다;;