PM 팀 회의 감사하기(Conduct a PM team meetings audit)

회의 감사: 가장 레버리지 높은 시간 회수

PM 팀은 제품 포트폴리오가 기능을 쌓는 방식으로 회의를 쌓습니다 — 각자는 만들어질 때 정당화됐고, 재평가되는 건 거의 없으며, 누구도 죽일 권한이 없습니다. 결과는 팀이 참석하는 회의 이름은 댈 수 있지만 그 회의 때문에 무엇이 출시됐는지는 댈 수 없는 주 18시간 회의 부하입니다. 회의 감사는 보통 PM당 주 6~10시간을 회수하는 한 세션 연습입니다.

Conduct a PM team meetings audit 프롬프트의 작동 방식

프롬프트는 모든 반복 회의를 다섯 가지 데이터 포인트(목적, 주기, 참석자, 산출, 담당자)로 인벤토리하고, 네 가지 차원(목적 명확성, 산출 명확성, 참석 필요성, 결정 속도)에서 각각을 감사하며, keep / redesign / kill로 분류합니다. 재설계 패턴은 실용적 메뉴입니다: 비동기 메모, 주기 감소, 참석자 감소, 사전 읽기 규율, 병합, 분할.

Kill 규칙이 중요합니다. Kill을 알리고, 대화가 어디로 옮겨가는지 명명하고, 30일 체크인을 일정 잡는 것은 팀이 다른 형태로 회의를 조용히 재창조하는 것을 방지합니다. Atlassian의 애자일 지표 글과 Google re:Work의 팀 효과성 가이드 모두 회의 감사가 PM 팀에서 대부분의 생산성 개입보다 더 큰 이익을 만들어낸다는 것을 문서화합니다.

언제 사용할까

• PM이 주 15시간 이상을 회의에 쓰는데 출시 속도가 떨어지고 있을 때
• 새 매니저가 온보딩 중이고 회의 부하가 가시적 이슈일 때
• 분기별 용량 회수가 리더십 목표일 때
• 엔지니어링 파트너가 PM 회의 부하가 협업에 영향을 준다고 불평했을 때
• 새 팀이 만들어지고 있고 굳어지기 전에 회의 위생을 설치하고 싶을 때

흔한 함정

• 대화를 옮기지 않고 죽이기. 회의가 유효한 목적을 가졌다면 대화는 다시 나타날 겁니다 — 보통 Slack 노이즈로. 의도적으로 리다이렉트하세요.
• 줄이지 않고 재설계. 회의 위에 비동기 메모를 더하면 일이 더 늘어나지 줄어들지 않습니다. 재설계는 회의가 짧아지거나 사라진다는 뜻입니다.
• 30일 체크 건너뛰기. 일부 죽인 회의는 명백하지 않은 방식으로 부하지지였습니다. 확인하고 필요하면 더 가벼운 형태로 다시 설치하세요.

참고 자료

• Agile Metrics — Atlassian
• Google re:Work — Google
• Basecamp: Getting Real
• The Pragmatic Engineer