엔지니어링 팀을 위한 프로젝트 킥오프 회의 아젠다

킥오프 회의가 건너뛰는 질문

잘 진행된 프로젝트 킥오프는 무엇을 만들지, 누가 무엇을 하는지, 언제까지인지에 대해 팀을 정렬시켜 놓습니다. 그 정렬은 보통 3주 정도 유지됩니다. 그러다 범위가 슬금슬금 늘고, 이해관계자가 핵심 가정에 대해 마음을 바꾸고, 의존성이 밀리고, 그제야 팀은 합리적인 두 사람이 의견을 달리할 때 누가 판단하는지에 대해 한 번도 합의한 적이 없다는 것을 알게 됩니다.

대부분의 킥오프 아젠다가 건너뛰는 질문은 이것입니다. 무언가 틀어졌을 때 이 팀은 어떻게 결정을 내릴 것인가? 프로젝트 계획이 아니라 — 의사결정 체계 말입니다. 기능을 잘라내야 할 때 범위를 책임지는 사람은 누구인가? 기술적 제약이 제품 요구사항을 무효화할 때 팀은 무엇을 하는가? 두 부서가 서로 다른 것을 원할 때 최종 결정권은 어느 이해관계자에게 있는가?

이런 질문은 아직 아무것도 걸려 있지 않은 킥오프에서는 답하기 쉽습니다. 모두가 입장을 가진 프로젝트 중반에는 훨씬 답하기 어렵습니다. 아래 템플릿은 어려운 국면이 시작되기 전에 이 질문들을 위한 시간을 확보해 둡니다.

아젠다 (복사해서 붙여넣으세요)

소요 시간: 프로젝트 복잡도에 따라 60~90분
형식: 진행자 주도. 모든 핵심 이해관계자와 기여자가 참석하거나 시작 전에 비동기로 검토

섹션 1 — 프로젝트 목표와 범위 (20분)

목표를 한 문장으로 진술하세요: 성공은 어떤 결과로 보이는가, 가능하면 측정 가능하게
범위 내: 이 프로젝트가 전달할 것을 구체적으로 지목
범위 밖: 이 프로젝트가 명시적으로 하지 않을 것 — 최소 세 가지를 나열하세요
성공 기준: 팀은 프로젝트가 끝났음을 어떻게 알 수 있는가?
이 섹션은 EM이나 PM이 책임집니다. 진술된 범위가 실현 가능성과 맞지 않으면 엔지니어가 반론을 제기합니다

섹션 2 — 역할과 책임 (15분)

각 워크스트림마다 담당자 한 명을 지목하세요 — 팀이 아니라 사람으로
다음에 대해 최종 결정을 내리는 사람은 누구인가: 제품 범위, 기술 아키텍처, 외부 커뮤니케이션?
각 주요 결정 유형에서 통보 대상, 협의 대상, 의사결정권자는 각각 누구인가?
다른 것이 다 불분명해도 책임을 지는 프로젝트 리드를 지목하세요

섹션 3 — 제약과 위험 (15분)

확고한 제약: 마감, 예산, 규제 준수, 다른 팀에 대한 의존성
알려진 위험: 이 프로젝트를 탈선시킬 수 있는 상위 세 가지는 무엇인가?
각 위험마다: 발생 가능성, 영향, 완화 담당자
무엇이 프로젝트를 취소하거나 크게 축소하게 만들 수 있는가? 지금 지목하세요

섹션 4 — 커뮤니케이션 계획 (10분)

팀은 얼마나 자주 싱크하는가? 어떤 형식으로?
누가 상태 업데이트를 받고, 어떻게 받는가? 이해관계자가 같은 채널을 원한다고 가정하지 마세요
프로젝트 문서는 어디에 두는가?
무언가 프로젝트를 막을 때 에스컬레이션 경로는 무엇인가?

섹션 5 — 미결 질문 (15분)

오늘 팀이 답할 수 없는 모든 질문을 나열하세요
각 질문마다: 담당자와, 답이 필요한 기한을 배정
기한과 담당자가 없는 질문은 중반이 되어도 여전히 열려 있을 것입니다

섹션 6 — 다음 단계 (10분)

실제 작업을 시작하기 위해 앞으로 5영업일 안에 반드시 일어나야 할 세 가지
각 다음 단계에는 담당자가 한 명씩 있습니다
킥오프 요약을 어떻게, 누구에게 배포할지 확인하세요

킥오프 노트를 제대로 남길 가치가 있는 이유

킥오프 문서는 어떤 프로젝트에서든 가장 자주 참조되는 산출물입니다. 범위가 다투어질 때, 새 팀원이 합류할 때, 이해관계자가 "우리 킥오프에서 X로 결정하지 않았나?"라고 물을 때 사람들이 확인하는 자료입니다. 잘 문서화된 킥오프는 관리하기 더 쉬운 프로젝트입니다.

Pavleur는 전체 킥오프를 자동으로 포착합니다: 진술된 그대로의 범위, 배정된 그대로의 역할, 지목된 그대로의 위험, 담당자가 붙은 미결 질문, 담당자와 기한이 붙은 다음 단계. 누군가 회의 도중 프로젝트 개요서, 다이어그램, 요구사항 문서를 화면 공유했다면, 그 시각 자료는 논의와 나란히 보고서에 담깁니다. 오디오만 다루는 도구는 누가 무슨 말을 했는지는 주지만, 테크 리드가 의존성을 설명할 때 화면에 있던 아키텍처 다이어그램은 포착하지 못합니다. 그렇게 만들어진 보고서는 첫날부터 프로젝트의 단일 진실 공급원 문서로 쓰입니다. 이것이 전통적인 회의 기록 도구와 어떻게 다른지는 Pavleur와 대안 비교를 참고하세요.

참석에 관한 참고

이 프로젝트에서 결정을 내릴 것으로 기대되는 모든 사람은 킥오프에 참석하거나, 작업 시작 전에 전체 녹화본과 서면 요약을 검토해야 합니다. 킥오프를 놓치고 2주 뒤에 범위를 비공식적으로 알게 된 이해관계자는 프로젝트 중반의 범위 분쟁을 예고합니다. 킥오프의 역할은 공유된 맥락을 세우는 것이고, 공유된 맥락은 관련된 사람들이 한자리에 있을 때만 존재합니다.