태어나서 처음으로 개발자 팀원과 협업을 해야했던 적이 있다. 프로덕트의 일부를 수정/보완 해야하는 프로젝트의 기획자로 투입이 되었을 때였다.
그때의 경험을 한 마디로 정의하면 '실수 투성이' 였다. 다행히 굉장히 꼼꼼하고 경험 많으신 엔지니어 팀원 덕분에 많은 실수를 커버할 수 있었지만, 그 과정에서 뼈저리게 배운 것들이 있다.
1️⃣ 경우의 수를 자세히 플래닝하지 못했다
개발자가 편하게 작업을 하기 위해서는 기획자가 생각하는 것보다 훨씬 더 디테일한 부분까지 명확히 정의해 드려야 한다. 작은 디테일 하나 때문에 개발 과정에 혼선이 생길 수도 있고, 중간에 추가 기획이 필요해질 수도 있다.
명확하지 않은 기획은 개발 속도를 늦추고, 불필요한 커뮤니케이션 비용을 발생시켰다.
2️⃣ 히스토리와 미팅록을 꼼꼼히 기록해두지 않았다
PRD(기획서)에 필요한 내용을 모두 담으면 충분하다고 생각했다. 하지만 프로젝트가 진행될 수록 느꼈다. 아이디어가 구체화 되는 과정의 모든 미팅, 팀원들과의 1:1 대화 내용, 각종 의사결정 과정 등을 꼼꼼히 기록해둬야 한다는 것을.
히스토리를 모르는 팀원이 보면 반드시 이런 질문을 던질 수 밖에 없다.
"도대체 왜 이 기능이 왜 이렇게 기획된 거죠?"
"여기에 이거를 넣은 이유가 뭐에요?"
기록이 없으면 설명할 때마다 모든 논의를 다시 되짚어야 하고, 심지어 기획이 틀린 것으로 오해받을 수도 있다. 기록은 팀의 집단 기억과도 같다는 느낌이 들었다.
3️⃣ 진행 과정을 자주 공유하지 않았다
처음 맡은 프로젝트이다보니 잘하고 싶다는 마음에 완벽한 상태를 만들기 전에 팀원들에게 공유하는 것이 꺼려졌다. 가장 큰 실수였다.
프로젝트를 매니징할 때는 모든 이해관계자(stakeholder)에게 자주 상황을 공유하고, 의견을 구하고, 수정하는 과정을 반복해야 한다는 점을 뒤늦게 깨달았다.
완벽하지 않은 상태로 공유해도 괜찮다. 오히려 자주 검증받고 피드백을 받는 것이 프로젝트가 올바른 방향으로 나아가게 해주는 것 같다.