효율적인 협업 = 문서 잘 쓰기가 아니다
스타트업 프로덕트 고민상담 - 4화
스타트업은 프로덕트가 전부다.
2020년부터 프로덕트에 진심인 스타트업의 대표와 팀원들을 만나오고 있다. 현재를 살고 있는 그들도, 내가 5년 전에 했던 고민들을 안고 있더라. 나는 멘토로서 그들이 가지고 있는 모든 문제를 해결하지는 못한다. 하지만 적어도 그들의 프로덕트가 올바른 방향으로 성장하기 위해 반드시 해야 할 일이 무엇인지 알고 있다.
그들에게 목이 쉬도록 알려준 말들은 또 비슷한 고민을 다른 누군가들에게도 도움이 될 것이다. 스타트업에서 프로덕트에 대한 고민은 결국 다 비슷비슷하니까.
그렇게 <스타트업 프로덕트 고민상담> 연재를 시작한다.
시리즈 네 번째,
우리 회사에 PM이 없는데... 내가 PM인 것 같다
멘티: 기획문서에 최소한 어떤 것들을 준비해야 할지 궁금하다. 개발자들은 "제품에 대한 모든 게 알고 싶다"라고 한다.
지수: 디자이너와 대표, 개발자 3개 부서가 협업하여 서비스를 만들고 있는 상황으로 이해된다. 나도 그렇게 시작했던 기억이 난다. 디자이너로서 기획자와 PM역할을 자연스럽게 가져가게 되더라.
기획자나 PM이라는 직책을 가진 누군가가 존재하지 않아도, PM의 역할은 누군가 한 사람이 맡아야 한다. 본인(엔지니어)이어도 좋고, 함께 일하는 디자이너여도 좋다. 대표가 맡기엔 무리다. 대표는 회사의 큰 방향을 내다보는 사람이어야 한다. PM은 일시적이고 규모가 작은 업무가 아니기 때문에 제품에 집중하는 사람이 대표 외 한 명이 더 필요하다.
결론부터 말하면 "제품에 대한 모든 게 알게 한다"는 문서로 해결할 수 있는 것이 아니다. 모든 것을 작성한 대하드라마 시나리오 같은 분량의 문서를 작성한다고 한들, 엔지니어가 전체 TEXT를 이해하여 완벽하게 동일한 제품을 구현할 수 있을까? 내 경험에 의하면 불가능이다.
또한 "문서 그대로 구현하겠다"는 태도가 스타트업 엔지니어에게 그리고 그 엔지니어와 협업하는 이들에게 어떤 이점이 있는가? 누군가의 의사결정을 그대로 따르는 것은 편한 일이다. 그러나 초기 스타트업은 필연적으로 실패를 경험하게 되어있다. 그것이 크건 작건 힘 빠지는 순간이 올 것이다. 그런데 "쟤가 시키는 대로 했더니 죽도 밥도 안되더라"는 것을 학습하면 매우 방어적이고 회의적인 팀원이 되어 버릴 것이다. 당연하다.
가장 좋은 방법은, 제품 개발에 참여하는 팀원들이 초기 기획 단계를 함께 하는 것이다. 물론 "우리 모두 함께 기획한다"는 건 최악의 형태다. 제품에 대해 최종 의사결정자와 주도자는 한 사람이어야 한다. 집단 의사결정은 무조건 실패하게 되어있다. 그게 아니라, 어떤 과정으로 제품이 만들어지고 의사 결정되는지, 이 제품은 애초에 왜 만들어져야 하는지에 대한 동기화가 되어 있어야 한다는 것이다. 팀에 자문해보자. 제품 개발에 관여하는 이들은 우리 제품의 존재 이유와 목표에 대해 얼마나 이해하고 있는가?
제품 기획을 주도하는 대표나 디자이너가 디테일한 구현 방식과 화면을 놓칠 수 있다. 이때 "우리는 주먹구구식으로 일한다."며 불안 해하지 말자. 엔지니어는 빠진 부분을 어떻게 채우면 기술적으로 효율적인가, 고객에게 더 편리한가에 대한 의견을 제시할 수 있는 기회다. 그리고 그래야 한다. 엔지니어가 의사 결정할 수 없는 영역이 빠져있다면 발견되는 대로 공론화하여 의사결정을 하고, 기획 담당하고 있는 사람이 다음 기획에선 잊지 않도록 합의하면 된다. 빠트린 사람도 자신의 불완전함에 대해 핑계를 대거나 방어적으로 나올 필요 없다. 그렇게 채워가고 맞춰가는 것이 중요하다.
소규모의 스타트업에서 완벽한 분업은 없다. 제품을 만드는 과정에 참여하는 사람이라면 제품이 어떻게 만들어지는지 관심을 가져야 한다. 또한 그들에게 기획에 참여할 수 있는 기회를 주는 것이 전제가 되어야 한다.
정리하면, 효율적인 협업 = 기획문서 잘 쓰기가 아니라는 뜻이다. 수십 개의 프로젝트가 돌아가는 회사라면 이야기가 다를 수 있지만, 한 회사에서 하나의 프로젝트가 진행되는 초기 스타트업이라면 문서는 오히려 독이 될 수 있다.
그럼에도! 기획문서에 뭘 써야 되는지 모르겠다면 꼭 정리해두어야 할 내용은 아래와 같다.
1) 개발 이유: 고객에게 이 제품이 필요한 이유, 회사가 비즈니스 측면에서 이것을 해야 하는 이유
2) 핵심 목표: 제품 성공 시 회사와 팀원이 만족할 수 있는 목표 (참여 팀원들이 목표 달성에 부합하게끔 제품이 기획되었는가? 논의할 수 있다면 좋은 문화라고 생각함)
3) 메인 고객 시나리오: 도식화, UI 이미지, 프로토타이핑, 맵 등 자유 형식. 커뮤니케이션만 되면 된다.
4) 시나리오 케이스 정리: 각 화면에 대한 설명, 예외 케이스 등 정리. 다시 말하지만 모-든 케이스를 작성하는 것은 무의미하며 발견 즉시 팀원들과 논의하여 의사 결정할 수 있는 기준과 문화가 필요함.
멘티: 프로젝트 참여인원별로 오늘은 뭐하는지 어제는 뭐했는지 내일은 뭐할지 이런 부분들이 항상 궁금한데 Jira, 아사나, 노션 등 협업 툴을 이용해 업무 트래킹을 해보려고 한다. 욕심이 지나친 건지?
지수: 여러 툴을 도입해보고, 가장 편리한 툴을 적용해보자. 개인적으로 아사나도 괜찮았다. 그러나 결국은 팀원들이 매일매일 본인의 일과를 툴에 작성해주어야 한다는 것이 이슈다. 팀원들의 적극적인 지지가 있다면 툴을 써보는 건 Why not이다.
과연 툴을 적용해보는 것 만이 문제를 해결하는 유일한 방법인가 생각해보자. 일정 관리, 프로젝트 진행상황 파악은 결국 하나의 목표를 향해 잘 나아가고 있는지 점검하기 위함이다. 매일 stand-up meeting을 해보는 것도 괜찮다. 이 미팅은 어제 한 일, 오늘 할 일, 목표 달성을 위해 도움이 필요한 부분에 대해 각자가 짧게 공유하는 시간이다. 전체 미팅 시간이 10분을 넘지 않는 게 좋다. 이 미팅의 취지는 좋지만 어디까지나 이것 또한 무형의 '툴'이다. 누군가 리드하지 않으면 미팅이 점차 흐지부지가 되어버리고, 영혼 없이 의무적으로 흘려보내는 시간이 되어버리니 미팅을 주도하는 인물은 반드시 있어야 한다. 보통 PM 또는 PM역할을 맡은 사람의 몫이다. 어느 정도 진행상황 팔로업이 되었다면 주에 3회, 주에 1회 정도로 줄이는 것도 좋고, 메신저로 대체해도 좋다.
스타트업은 일정을 맞추는 것에도 어려움을 겪는다. 계획을 세우고 그 목표 일정을 맞추기 위해 노력해야 하지만, 우리에겐 항상 예상치 못한 상황이 생긴다. 결국 아름다운 계획을 수정해야 하는 상황이 빈번해지는데, 이를 막기 위해 어떤 툴이나 방법론이 해결해줄 것이라는 생각은 버려야 한다. 대기업에서는 Work Breakdown Sheet(WBS)라는 것을 작성한다. 엑셀 시트를 일별로 자르고 모든 세부 업무들을 트래킹 하는 것이다. 보기만 해도 숨이 막힌다. 이렇게 자잘하게 업무 계획을 세우기 때문에, 일정 맞추는 것이 가능하다고 믿는 사람도 있다. 과연 그런가? 그렇지 않다. 스타트업에서 WBS를 썼다간 팀원 절반이 증발하는 불상사를 맛보게 될 것이다. 저런 시트를 작성하는 탑다운 문화의 조직에서는 납기일을 지키지 않으면 이것을 담당하고 있는 나, 개인에게 어떤 불이익이 생길지 명확하다. 그리고 의사결정자가 나에게 불이익을 충분히 행사할 수 있는 힘이 있다는 것을 알기 때문에 사람들은 이를 악물고 몸을 갈아 넣어서 목표를 지킨다. 대부분의 스타트업에서는 적용하기 힘든 문화일 것이라 생각한다. 현명한 중간점을 찾는 것이 성공으로 가고자 하는 스타트업의 숙제다.
일정을 세우고 이행하는 것은 팀원의 역량, 리더십 역량, 조직의 분위기에 달려있다. 안타깝게도 이것이 하루아침에 갑자기 개선되는 것은 아니다. 리더로서의 마음가짐은 일정은 언제든 바뀔 수 있다는 것을 염두에 두는 것이다. 물론 팀원에게 이것을 내비칠 필요는 없다. 팀원들에게는 일정 변경이 필요하다는 걸 감지했을 때 즉시 모두에게, 적어도 리더에게 상황 공유를 해주어야 함을 강조해야 한다.
대체로 일정을 맞출 수 없을 것 같다고 감지했으나 이를 드러내지 않고 꽁꽁 싸매고 있거나, 비공식적으로 하소연으로 그치는 경우가 허다하다. 그러나 문제는 언젠가 터지기 마련이고 뒤늦게 이것이 탄로가 났을 때 문제는 커진다.
