1어림하는 방법
whatif.sh는 끝난 사례마다 개선안이 줄일 대기를 계산해 빼고, 처리 시간 분포를 다시 구한다. 시나리오는 세 가지다.
| 옵션 | 가정 | 사례마다 줄어드는 시간 |
|---|---|---|
--review-cap H | PR의 첫 리뷰 대기가 H 업무시간을 넘지 않는다 | PR마다 (첫 리뷰 대기 − H)의 양수 부분 |
--blocked-cap H | 막힘이 H 업무시간 안에 풀린다 | 막힘마다 (막힘 대기 − H)의 양수 부분 |
--drop-reopen | 다시 열림이 없다 | 다시 열기 전의 완료부터 마지막 완료까지 |
계산은 “줄어든 시간만큼 뒤의 사건이 그대로 앞당겨진다”고 가정한다. 리뷰가 빨라져 변경 요청 자체가 줄어드는 효과, 일이 앞당겨져 다른 사람의 줄이 길어지는 효과는 들어가지 않는다.
2지난 개선으로 어림을 검산하기
리뷰 당번은 결과를 이미 안다. 3~5월 업무에 “첫 리뷰 대기 4업무시간 상한”을 적용해 어림하고, 실제 6~9월 숫자와 비교한다.
bash github-pm-starter-kit/whatif.sh pm-lab/orbit-event-log-clean.csv --to 2026-05-31 --review-cap 4
| 숫자 | 3~5월 실제 | 어림 (상한 4h) | 6~9월 실제 |
|---|---|---|---|
| 처리 시간 중앙값 | 36.8h | 33.1h | 27.7h |
| 처리 시간 85% | 56.2h | 53.3h | 48.8h |
어림은 중앙값을 3.7h 줄였고, 실제로는 9.1h 줄었다. 어림이 작게 나온 이유는 실습 27에서 확인했다. 6~9월에는 변경 요청 비율도 줄었고(같은 날 시작한 다른 규칙과 겹친다), 영역별 사례 수도 다르며, 사례 수가 적은 묶음의 흔들림이 있다. 이 검산에서 얻는 사용법은 두 가지다. 어림은 개선안이 겨냥한 대기 하나만 바뀌었을 때의 값이므로 개선안끼리 순서를 정하는 데 쓴다. 팀에 약속하는 목표 숫자로는 쓰지 않는다.
아래 화면에서 기간을 “전”으로 두고 첫 리뷰 대기 상한을 움직이면 같은 계산을 바로 볼 수 있다. 초록 점선은 6~9월의 실제 중앙값이다.
3다음 분기 개선안 후보
지금(6~9월) 기준으로 두 개선안을 어림한다. 위 화면의 기간을 “후”로 바꾸고 막힘 상한과 다시 열림 없음을 켜서 같은 값을 확인한다.
bash github-pm-starter-kit/whatif.sh pm-lab/orbit-event-log-clean.csv --from 2026-06-01 \ --blocked-cap 8 --drop-reopen
| 개선안 | 바꾸는 일 | 어림 옵션 | 영향받는 사례 | 중앙값 | 85% | 줄어드는 합계 |
|---|---|---|---|---|---|---|
| A. 막힘 결정 기한 | blocked 라벨이 붙으면 PM이 4업무시간 안에 결정하거나 결정할 사람을 지정한다. 매일 11시와 16시에 막힌 업무 목록을 확인한다 | --blocked-cap 4 | 18 | 27.7h → 26.8h | 48.8h → 46.4h | 170h |
| B. 착수 전 결정 확인 | 정책 질문이 남은 업무는 In Progress로 옮기지 않는다. 작업 시작 전에 PM이 완료 조건의 정책 항목을 확정한다 | --drop-reopen (상한값) | 6 | 27.7h → 27.7h | 48.8h → 46.3h | 162h |
| (참고) 리뷰 당번 유지 | 이미 적용 중 | --review-cap 4 | 1 | 변화 없음 | 변화 없음 | 7h |
- 중앙값은 거의 움직이지 않는다. 6~9월에 막힘은 사례의 14%, 다시 열림은 5%에만 있어 가운데 사례에는 영향이 없다. 두 개선안이 바꾸는 것은 오래 걸리는 쪽, 곧 85%다. 일정을 약속할 때는 중앙값보다 85% 같은 높은 분위수를 쓰므로(실습 15) 이 숫자가 줄면 약속할 수 있는 날짜가 당겨진다.
- B의 어림은 상한값이다. 6~9월 다시 열림 6건 중 결정 기록이 있는 것은 4건이다. 착수 전 결정 확인은 이 4건을 겨냥하므로 실제 효과는 162h보다 작다. 반대로 결정 기록이 있는 업무의 변경 요청이 줄어드는 효과는 어림에 들어 있지 않다.
- A는 PM의 시간을 쓴다. 6~9월에 막힘은 18건, 주당 1~2건이다. 하루 두 번의 확인은 PM의 시간을 하루 10분 안팎 쓴다.
4우선순위 정하기
| 기준 | A. 막힘 결정 기한 | B. 착수 전 결정 확인 |
|---|---|---|
| 어림 효과 (85%, 합계) | −2.4h, 170h | −2.5h 이하, 162h 이하 |
| 비용 | PM이 하루 두 번 막힌 업무를 확인한다 | 작업 시작이 늦어질 수 있다(백로그 대기 증가) |
| 효과를 확인하는 지표 | 막힘 대기 중앙값과 85%. 4주면 막힘 6건 안팎이 쌓인다 | 결정 기록 업무의 다시 열림 비율. 한 분기에 다시 열림이 몇 건이라 확인에 두 분기 이상 걸린다 |
| 되돌리기 | 쉽다. 확인을 멈추면 된다 | 쉽다. 시작 조건을 없애면 된다 |
A를 먼저 적용한다. 효과가 비슷하고, 지표가 빨리 쌓여 4주 뒤에 확인할 수 있으며, 다른 단계(백로그)를 늘릴 위험이 없다. B는 결정 기록 업무 8건의 원인 확인(인사이트 3의 확인 방법)을 마친 뒤 다시 판단한다. 두 개선을 같은 날 시작하지 않는 것도 이유다. 6월 1일처럼 두 규칙을 함께 시작하면 각각의 효과를 구분할 수 없다.
5개선안을 이슈로 등록하기
키트의 양식으로 개선안을 적는다.
**개선안** - 제목: (예: 리뷰 당번) - 겨냥한 병목: (예: 첫 리뷰 대기, 기간 A 업무 시간 중앙값 6.8h, 첫 리뷰의 52%가 한 사람에게 몰림) - 바꾸는 일: (예: 평일마다 리뷰 당번 한 명이 그날 만든 PR의 첫 리뷰를 맡는다. 당번 표는 위키에 둔다) - 가설: (예: 첫 리뷰 대기가 4h 안으로 줄면 처리 시간 중앙값이 줄어든다) - 어림 효과: (whatif.sh 결과. 예: 처리 시간 중앙값 36.8h → 33.1h, 영향받는 사례 83건) - 비용과 위험: (예: 당번 날의 개발 시간이 줄어든다) - 확인 지표와 목표: (예: 첫 리뷰 대기 중앙값 4h 이하, 4주 뒤 compare.sh --split 적용일) - 적용일과 담당: YYYY-MM-DD, (이름) - 관련: (분석 보고서, 토론, 결정 기록 주소)
개선안 A를 채운 예다.
**개선안** - 제목: 막힘 결정 기한 - 겨냥한 병목: 막힘 대기. 6~9월 업무 시간 중앙값 11.5h, 85% 21.2h, 36건 중 32건을 PM이 해소 - 바꾸는 일: blocked 라벨이 붙으면 PM이 4업무시간 안에 결정하거나 결정할 사람을 지정한다. 매일 11시와 16시에 막힌 업무 목록을 확인한다 - 가설: 막힘은 PM의 결정을 기다린 시간이고, 확인 주기가 정해지면 대기가 4h 안으로 준다 - 어림 효과: whatif.sh --from 2026-06-01 --blocked-cap 4. 처리 시간 85% 48.8h → 46.4h, 영향받는 사례 18건, 합계 170h - 비용과 위험: PM의 확인 시간 하루 10분 안팎. 결정을 서둘러 바꾸는 일이 늘 수 있다 - 확인 지표와 목표: 막힘 대기 업무 시간 중앙값 4h 이하. 적용 4주 뒤 compare.sh --split 적용일과 bottleneck.sh --from 적용일 - 적용일과 담당: 2026-09-14, pm-oh - 관련: 분석 보고서 pm-lab/process-analysis-report.md, 인사이트 2
실습 저장소에 개선안 라벨을 만들고 이슈로 등록한다. 개선안은 업무가 아니므로 Project와 마일스톤에 넣지 않는다.
gh label create "kind:improvement" -R "$PM_REPO" --color 0E8A16 --description "프로세스 개선안" gh issue create -R "$PM_REPO" --title "개선안: 막힘 결정 기한" --label "kind:improvement" --body-file pm-lab/proposal-blocked.md
분석 보고서 7절의 개선안 표에 두 개선안과 우선순위를 옮긴다.
개선안 하나는 “누가, 언제, 무엇을 다르게 하는가”가 한 문장으로 적혀야 한다. “리뷰 문화를 개선한다”처럼 적으면 적용일을 정할 수 없고, 적용일이 없으면 전후 비교를 할 수 없다. 리뷰 당번(“평일마다 한 명이 그날 PR의 첫 리뷰를 맡는다”)은 이 기준을 만족한 예다.
막히면
| 증상 | 확인과 해결 |
|---|---|
오류: 시나리오가 없다 | --review-cap, --blocked-cap, --drop-reopen 중 하나 이상을 준다 |
| “모두 적용” 줄이 없다 | 시나리오가 하나뿐이면 그 줄만 나온다 |
label already exists | 이미 만든 라벨이다. 그대로 다음 명령을 실행한다 |
whatif.sh의 가정과, 어림에 들어가지 않는 효과 두 가지를 설명할 수 있다.- 리뷰 당번 어림(33.1h)과 실제(27.7h)를 비교하고, 어림을 쓰는 범위를 정했다.
- 개선안 A와 B의 어림 효과를 화면과 명령으로 확인했다.
- 우선순위와 그 이유를 적었다.
- 개선안 A를 양식으로 적어 이슈로 등록했다.
마치며...
효과 어림은 개선안끼리 순서를 정하는 도구이고, 지난 개선으로 검산해 보면 어림이 실제보다 작거나 클 수 있음을 알 수 있다. Orbit의 다음 개선안은 중앙값보다 85%를 줄이는 안이었고, 효과를 따로 확인하기 위해 한 번에 하나씩 적용하기로 했다. 다음 실습에서는 적용한 개선이 효과가 있었는지 확인하는 방법과, 이 분석을 매주 자동으로 돌리는 방법을 다룬다.