제품 출시 속도가 떨어지는 이유 진단하기(Diagnose why your product's shipping velocity is declining)

Description

팀 규모는 5명에서 15명으로 늘었는데 분기당 출시 기능 수는 오히려 줄고 있을 때 쓰는 프롬프트입니다. 스탠드업은 형식적이고, PR은 며칠씩 리뷰에 묶이며, 스프린트 약속은 계속 어긋나는 상황에서 진짜 병목이 프로세스인지, 아키텍처인지, 사람인지 구조적으로 진단합니다.

{{product_name}}의 shipping velocity가 감소하는 근본 원인을 진단하고, 구체적인 해결책을 추천해주세요.

## 컨텍스트(Context)
- Product: {{product_name}}
- 팀 규모: {{team_size}} engineers (최고 속도 시점에는 {{previous_team_size}})
- Sprint length: {{sprint_length}}
- 최근 6개 sprint의 평균 완료 story points: {{velocity_numbers}}
- Deploy frequency: {{deploy_frequency}}
- 평균 PR review 시간: {{pr_review_time}}
- 현재 진행 중인 프로젝트/스트림 수: {{active_projects}}

## Step 1: 증상 인벤토리(Symptom Inventory)
각 증상을 평가하세요. (0 = 문제 아님, 5 = 치명적 병목)
1. PR이 24시간 이상 review에 머문다.
2. Sprint commitment를 40% 이상 놓친다.
3. 회의가 각 엔지니어 주간 시간의 25% 이상을 차지한다.
4. 요구사항이 불명확해 sprint 중간에 scope가 바뀐다.
5. Deployment pipeline이 30분 이상 걸린다.
6. 엔지니어가 매일 여러 프로젝트 사이에서 context switching한다.
7. 신규 엔지니어가 독립적으로 배포하기까지 3개월 이상 걸린다.
8. technical debt 때문에 대부분의 기능에서 workaround가 필요하다.
9. 팀 간 dependency 때문에 blocker가 자주 생긴다.
10. on-call 또는 incident response가 계획된 업무를 방해한다.

## Step 2: 근본 원인 분석(Root Cause Analysis)
가장 점수가 높은 증상을 다음 root cause로 묶으세요.
- **Process bloat**: 승인, ceremony, handoff가 너무 많음
- **Architecture friction**: monolith, shared codebase, flaky tests, slow CI
- **Coordination overhead**: 너무 많은 사람이 같은 표면 영역을 건드림
- **Scope creep**: 요구사항 변화 속도가 팀의 흡수 속도보다 빠름
- **Skill/knowledge gaps**: 신규 채용의 생산성이 낮거나 senior engineer가 부족함

각 root cause마다:
1. 이 진단을 뒷받침하는 증거는 무엇인가요?
2. 이 문제가 언제부터 시작됐나요? (timeline)
3. 이전에 무엇을 시도했나요? 왜 효과가 없었나요?

## Step 3: 개입 설계(Intervention Design)
확인된 각 root cause에 대해 구체적인 intervention을 제안하세요.
1. Target: 어떤 증상을 해결하나요?
2. Action: 정확히 무엇이 바뀌나요? ("process 개선"처럼 추상적으로 쓰지 말고 "주 3회의 sync를 비동기 Slack 업데이트로 대체"처럼 구체적으로)
3. Owner: 누가 이 변화를 주도하나요?
4. Timeline: 언제 효과가 나타나나요?
5. Success metric: 무엇을 보면 성공인지 알 수 있나요?

## Step 4: Quick Wins vs. Structural Fixes
intervention을 다음으로 나누세요.
- **Quick wins** (이번 주 실행, 2 sprint 내 효과): 3개
- **Medium-term** (이번 달 실행, 1분기 내 효과): 3개
- **Structural** (투자가 필요하며, 2분기 내 효과): 2개

## Step 5: Tracking Dashboard
다음 항목을 포함한 velocity health dashboard를 설계하세요.
- Deploy frequency (주간 추세)
- Cycle time (PR open → merged → deployed)
- Sprint commitment accuracy (committed vs. completed)
- Engineering time allocation (features vs. debt vs. meetings vs. support)

Customize This Prompt