크로스 펑셔널 킥오프 브리프(Cross-Functional Kickoff Brief)

대부분의 프로젝트는 10주차가 아니라 1주차에 실패한다

내가 세 곳의 회사에서 반복해서 본 패턴이 있습니다. PM이 스펙을 씁니다. 엔지니어링은 대충 읽습니다. 디자인은 질문이 있지만 kickoff meeting을 기다립니다. 마케팅은 Slack thread를 통해 프로젝트 소식을 듣습니다. 킥오프 미팅은 열리더라도, PM이 스펙을 소리 내어 읽고 모두가 고개를 끄덕이는 방식으로 끝납니다. 2주 뒤가 되면 엔지니어링은 디자인이 이해한 것과 다른 것을 만들고, 마케팅은 3일 차에 이미 바뀐 scope를 기준으로 launch를 준비하고, PM은 모두를 다시 맞추기 위해 back-to-back 미팅을 돌고 있습니다.

실패 지점은 실행이 아니라 kickoff였습니다.

alignment 부채는 technical debt보다 더 빨리 쌓인다

Project Management Institute 연구에 따르면 프로젝트에 투입된 1달러당 11.4%가 poor project performance로 낭비되며, 그 선두 원인은 시작 단계의 부적절한 alignment입니다. 백만 달러짜리 initiative라면, 사람들이 무엇을 만들고 있는지 합의하기 전에 개발을 시작했다는 이유만으로 11만 4천 달러가 타버리는 셈입니다.

크로스 펑셔널 misalignment가 특히 위험한 이유는 초기 몇 주 동안 보이지 않는다는 점입니다. 모두 바쁘고, 모두 생산적인 것처럼 느끼며, 이해의 divergence는 결과물이 서로 부딪힐 때가 되어서야 드러납니다. 엔지니어링의 "MVP"에는 디자인이 mockup조차 하지 않은 기능 세 개가 들어 있고, 마케팅의 launch plan은 누구도 동의한 적 없는 타임라인을 전제로 하며, 고객 성공팀은 sprint 두 번째 주에 descoped된 기능을 고객에게 이미 약속하고 있습니다.

해결책은 의외로 단순합니다. 목표, 범위, non-goals, 타임라인, 역할, 커뮤니케이션 규범, decision right를 어떤 작업이 시작되기 전에 명시적으로 합의하게 만드는 구조화된 kickoff document입니다. 미팅이 아니라 문서입니다. 모든 기능 조직이 검토하고 sign-off한 문서. 미팅은 그 문서를 실시간으로 만드는 자리가 아니라, 이미 문서화된 내용을 토론하는 자리여야 합니다.

이 프롬프트가 돕는 방식

이 프롬프트는 팀이 흔히 어긋나는 모든 차원을 포괄하는 크로스 펑셔널 kickoff brief를 생성합니다. 우리가 해결할 문제(그리고 명시적으로 해결하지 않을 것), 성공 지표, scope boundary, 팀 역할과 의사결정 권한, milestone이 들어간 timeline, 커뮤니케이션 cadence, escalation path까지 포함합니다. 프로젝트 내내 모두가 참조할 single source of truth를 만드는 것입니다.

이건 "우리가 그렇게 합의했다고 생각했는데..."와 "kickoff doc을 확인해보죠"의 차이입니다.

언제 꺼내 쓸까

• 세 개 이상 팀이 얽힌 프로젝트를 시작하며, 일 시작 전에 모두를 같은 페이지로 맞춰야 할 때
• 이전 프로젝트가 scope creep이나 역할 혼선으로 고생했고, 이번엔 그걸 막고 싶을 때
• 새 PM으로 mid-stream 합류했고, 무엇이 합의됐는지 retroactive alignment가 필요할 때
• 엔지니어링과 디자인이 역할/핸드오프가 불분명한 스펙 때문에 계속 다른 것을 만들고 있을 때
• 모든 major initiative에 재사용할 수 있는 kickoff 프로세스를 만들고 싶을 때

좋은 결과물의 모습

강한 kickoff brief는 2-3페이지 안에 들어가고, 5분 안에 훑을 수 있으며, 누가 무엇을 소유하는지에 대해 애매함이 없어야 합니다. goals 섹션에는 explicit non-goals가 있어야 하고, timeline에는 ship date만이 아니라 milestone이 있어야 하며, roles 섹션에는 팀 이름이 아니라 개인 이름과 그들의 decision-making authority가 들어가야 합니다. 그리고 일이 바뀔 때 무엇을 할지에 대한 명확한 섹션도 있어야 합니다. 바뀔 것이기 때문입니다. 최고의 kickoff doc은 프로젝트 내내 매주 다시 열어봅니다. kickoff meeting 이후 아무도 다시 열지 않는다면, 충분히 구체적이지 않았던 것입니다.

참고 자료

• Pulse of the Profession: The Cost of Poor Alignment — Project Management Institute
• How Figma Runs Project Kickoffs — Figma Engineering Blog
• The Anatomy of a Good Kickoff Document — First Round Review