공개 출시 전 내부 런치 레디니스(launch readiness) 체크 작성하기

공개 출시는 쉬운 부분입니다. 출시가 실제로 실패하는 곳은 내부 레디니스입니다

실패하는 공개 출시는 프로덕트가 망가져서 실패하는 경우가 드뭅니다. 서포트가 교육되지 않았거나, 세일즈에 데모가 없었거나, 애널리틱스 대시보드가 출시되지 않았거나, 리걸 리뷰가 늦게 들어왔거나, 온콜 로테이션이 얇았기 때문에 실패합니다. 그 모든 갭은 예방 가능했고, 팀에는 단지 모든 기능이 출시일 전에 통과 조건에 약속하도록 강제하는 단일 산출물이 없었을 뿐입니다.

내부 레디니스 체크가 그 산출물입니다. 그것은 상태 문서가 아니라 계약입니다.

Atlassian의 프로덕트 런치 글과 agile-at-scale 관행은 같은 요점을 정리합니다. 크로스 펑셔널(cross-functional) 출시는 기능별 명시적 소유권과 명시적 통과 조건을 요구합니다. 일반적인 "준비됨"은 규모에서 절대 유지되지 않습니다.

상태 매트릭스가 체크리스트를 이기는 이유

상태 체크리스트는 모두 그린으로 표류합니다. 오너가 자가 입증하고 동료 리뷰가 없기 때문입니다. 행별로 구체적 통과 기준과 동료 견제를 요구하는 매트릭스가 그 표류를 막습니다. 팀은 다섯 개의 "괜찮아 보인다" 행으로 출시를 착륙시킬 수 없습니다. 각 행이 증거를 가리켜야 합니다.

매트릭스가 작동하게 하는 세 가지 규율:

• 구체적 통과 기준. "서포트 준비됨"은 기준이 아닙니다. "5개 매크로가 배포되고 실제 티켓 두 건으로 테스트됨"이 기준입니다.
• 그린에 대한 동료 견제. 자가 입증은 낙관적 그린을 만듭니다. 동료가 증거를 읽고 확인합니다.
• 증거 없이는 그린 없음. 증거는 스크린샷, 테스트 리포트, 배포 URL, 또는 짧은 글로 된 확인일 수 있습니다. 구두 "예"는 안 됩니다.

Draft an internal launch readiness check prompt 작동 방식

Step 1은 런치 티어를 설정합니다. Tier 1은 PR이 있는 광범위 공개, Tier 2는 세그먼트 또는 베타 졸업, Tier 3은 사일런트 또는 플래그 게이트. 티어는 매트릭스 범위를 정해, 플래그 게이트 롤아웃이 마케팅 행을 필요로 하지 않도록 합니다.

Step 2는 매트릭스를 구축합니다. 각 행은 기능, 오너, 통과 기준을 가집니다. 표준 세트는 엔지니어링, QA, 서포트, 세일즈, 마케팅, 리걸, 애널리틱스, 빌링, 시큐리티, 커뮤니케이션을 다룹니다. Tier 2와 3은 해당 없는 행을 잘라냅니다.

Step 3은 행별 하드 통과/실패를 정의합니다. 프롬프트는 구체적 테스트를 강제합니다. "텔레메트리 존재"는 "런치 대시보드가 5개 핵심 이벤트의 라이브 데이터를 보여줌"으로 대체됩니다. 그린으로의 표류를 막는 것은 구체성입니다.

Step 4는 드라이 런 일정을 잡습니다. T-7일에 매트릭스를 두고 모든 오너를 함께 모읍니다. 레드와 옐로는 블로커와 날짜를 받습니다. 그린은 동료 견제를 받습니다. T-3일은 옐로였던 것을 다시 봅니다.

Step 5는 go/no-go 기준을 정의합니다. Tier 1은 T-1에 모든 그린을 요구하며, 문서화된 완화책이 있는 옐로 최대 2개를 허용합니다. 어떤 레드라도 no-go입니다. 기준이 글로 되어 있어, 출시 결정이 전날의 논쟁이 아닙니다.

Step 6은 Day-1 워치리스트를 정의합니다. 팀이 첫 24-72시간에 모니터링할 것과 롤백을 트리거하는 임계값. SVPG의 팀 목표 글과 Transformed는 출시가 선언되는 것이 아니라 관찰되는 것이라고 강조합니다. 워치리스트가 관찰을 체계적으로 만듭니다.

매트릭스가 출시를 살리는 때

매트릭스가 자기 몫을 하는 세 가지 패턴:

• 늦은 리걸 리뷰. 리걸이 T-7에 매트릭스를 보고 두 시장에 필요한 프라이버시 업데이트를 플래그합니다. 팀은 글로벌 출시를 끌어내리는 대신 그 시장만 일주일 늦게 출시합니다.
• 교육되지 않은 서포트. 서포트가 12명 중 4명만 브리핑되었다고 플래그합니다. 팀은 T-2에 브라운백을 추가해 출시일 혼란을 피합니다.
• 텔레메트리 갭. 애널리틱스가 5개 핵심 이벤트 중 두 개가 대시보드에 로깅되지 않는다고 플래그합니다. 엔지니어링이 T-3에 수정을 출시해 Day-1 모니터링이 온전합니다.

Atlassian의 스프린트 플래닝 글은 기저 규율을 강화합니다. 여러 팀에 걸친 큰 이니셔티브는 암묵적 공유 이해가 아니라 명시적 소유권 산출물을 요구합니다.

When to use it

• 공개 출시가 2-4주 앞이고, 팀이 "준비되었는가"에 느낌으로 답해왔습니다.
• 이전 출시가 예방 가능한 갭으로 어려움을 겪었습니다 (서포트 미교육, 텔레메트리 늦은 출시, 리걸 막판 플래그).
• 신규 프로덕트가 시장에 나가는데 팀이 이 규모의 출시를 운영해본 적이 없습니다.
• 규제 민감 출시가 명시적 리걸과 시큐리티 사인오프를 필요로 합니다.
• 리더십 리뷰가 어느 출시가 go이고 어느 것이 위험에 있는지 묻습니다.

Common pitfalls

• 자가 입증으로 모두 그린. 동료 견제는 비협상입니다.
• 일반적 통과 기준. "준비됨"은 기준이 아닙니다. 구체적 테스트가 기준입니다.
• 티어 범위 부재. 사일런트 플래그 롤아웃은 마케팅 행이 필요 없고, Tier 1 공개 출시는 모두 필요합니다.

Sources

• Product launch - Atlassian
• Agile at scale - Atlassian
• Sprint planning - Atlassian
• Team objectives overview - Silicon Valley Product Group
• Transformed - Silicon Valley Product Group