1프로세스 지도 보고서
bash github-pm-starter-kit/process-map.sh pm-lab/orbit-event-log-clean.csv > pm-lab/orbit-process-map.md
보고서는 활동, 직접 이어짐 관계, 대기 시간이 긴 연결, 변형, 사례별 처리 시간, 적합성 검사 순서다. 이 실습은 앞의 네 부분을 읽는다.
2지도로 보기
아래 프로세스 지도는 보고서의 직접 이어짐 관계 표를 그린 것이다. 재생하면 업무 257건이 점 257개로 나타나 3월부터 9월까지 기록 시각을 따라 움직인다. 점이 몰려 오래 머무는 화살표가 많은 업무가 기다린 연결이다.
“최소 횟수”를 1로 내리면 연결 18개가 모두 보이고, 30으로 올리면 13개만 남는다. 빠지는 연결은 “막힘 해소 → 업무 완료”(4회) 같은 드문 연결이다. 빈도로 연결을 거르는 것은 휴리스틱 마이너(Heuristics Miner, 2006)가 쓰는 방법과 같은 생각이다. 사례가 수천 건이 되면 모든 연결을 그린 지도는 선이 엉켜 읽을 수 없으므로, 처음에는 많이 나온 연결만 남겨 주된 흐름을 보고 기준을 조금씩 내리며 예외를 확인한다.
3변형 읽기
변형(variant)은 같은 활동 순서로 흐른 사례의 묶음이다. 257건이 20개 변형으로 나뉘었다. 보고서의 변형 표 앞부분이다.
| 사례 수 | 활동 순서 | 사례 | | - | - | - | | 125 | 업무 생성 → 작업 시작 → 첫 커밋 → PR 생성 → 리뷰 승인 → PR 병합 → 업무 완료 | OB-001, OB-002, OB-003, OB-007, OB-008, OB-011, OB-013, OB-014 외 117건 | | 32 | 업무 생성 → 작업 시작 → 첫 커밋 → PR 생성 → 변경 요청 → 리뷰 승인 → PR 병합 → 업무 완료 | OB-004, OB-016, OB-019, OB-022, OB-024, OB-032, OB-039, OB-055 외 24건 | | 20 | 업무 생성 → 작업 시작 → 막힘 → 막힘 해소 → 첫 커밋 → PR 생성 → 리뷰 승인 → PR 병합 → 업무 완료 | OB-012, OB-015, OB-030, OB-033, OB-038, OB-051, OB-053, OB-062 외 12건 | | 19 | 업무 생성 → 작업 시작 → 업무 완료 | OB-034, OB-061, OB-065, OB-089, OB-090, OB-098, OB-133, OB-152 외 11건 | | 14 | 업무 생성 → 작업 시작 → 첫 커밋 → 결정 기록 → PR 생성 → 리뷰 승인 → PR 병합 → 업무 완료 | OB-006, OB-077, OB-127, OB-141, OB-142, OB-153, OB-164, OB-187 외 6건 | | 13 | 업무 생성 → 작업 시작 → 첫 커밋 → 결정 기록 → PR 생성 → 변경 요청 → 리뷰 승인 → PR 병합 → 업무 완료 | OB-026, OB-045, OB-050, OB-054, OB-094, OB-100, OB-104, OB-121 외 5건 | (이하 14개 변형 생략)
| 순위 | 사례 | 비율 | 기본 경로와 다른 점 |
|---|---|---|---|
| 1 | 125 | 49% | 없음. 업무 생성부터 업무 완료까지 7단계 |
| 2 | 32 | 12% | 첫 리뷰에서 변경 요청이 한 번 있었다 |
| 3 | 20 | 8% | 작업 시작 직후 막혔다가 풀렸다 |
| 4 | 19 | 7% | PR이 없다. 확인해 보면 모두 area:qa 업무다 |
| 5 | 14 | 5% | 첫 커밋과 PR 생성 사이에 결정 기록이 있다 |
| 6 | 13 | 5% | 결정 기록과 변경 요청이 함께 있다 |
상위 6개 변형이 사례 223건(87%)이고, 나머지 14개 변형에 34건이 흩어져 있다. 나머지 변형은 변경 요청이 두세 번 반복되었거나(“변경 요청 → 변경 요청” 12회), 업무가 완료 뒤 다시 열려 PR을 한 번 더 만든 경우(13건)다. 다시 열린 업무는 사건이 13~17개로, 기본 경로의 두 배다.
변형 표에서 바로 확인할 것은 두 가지다.
- 가장 많은 변형의 비율: 49%다. 사례의 절반이 팀이 기대한 경로를 그대로 지났다. 이 비율은 기간을 나눠 보면 절차가 정착하는지 보는 숫자가 된다.
- 기본 경로에 없는 활동이 무엇과 함께 나오는가: 결정 기록이 있는 변형(5, 6위)에는 변경 요청이 함께 있는 경우가 많다. 14건과 13건으로 거의 반반이다. 결정 기록이 없는 기본 경로(1, 2위)에서는 125건 대 32건이다. 이 차이가 우연인지는 사례 수와 비교 묶음을 정해 따로 확인해야 한다.
판 데르 알스트는 변형이 적고 지도가 단정한 프로세스를 라자냐(lasagna) 프로세스, 사례마다 경로가 달라 지도가 엉키는 프로세스를 스파게티(spaghetti) 프로세스라고 불렀다. 257건에 변형 20개인 Orbit은 앞의 경우다. 고객 문의 처리, 장애 대응처럼 경로가 제각각인 업무는 변형이 사례 수에 가깝게 나오며, 이때는 변형을 하나씩 읽는 대신 활동 빈도와 연결 빈도로 거른 지도를 먼저 본다.
4대기 시간이 긴 연결
보고서의 “대기 시간이 긴 연결”은 연결마다 앞 활동부터 뒤 활동까지 걸린 달력 시간의 중앙값이 큰 순서다.
| 연결 | 횟수 | 중앙값 | 읽는 법 |
|---|---|---|---|
| 업무 생성 → 작업 시작 | 257 | 3.2일 | 백로그에서 기다린 시간이다. PM이 정한 순서를 기다린 것이므로 병목과 구분한다 |
| 업무 완료 → 다시 열림 | 13 | 2.7일 | 완료 뒤 QA가 결함을 찾기까지의 시간이다. 이 시간 동안 업무는 끝난 것으로 보인다 |
| 막힘 해소 → 업무 완료 | 4 | 2.4일 | QA 업무 4건이다. 건수가 적어 판단하지 않는다 |
| 결정 기록 → PR 생성 | 43 | 1.9일 | 결정이 바뀐 뒤 PR을 만들기까지다. 개발이 이어지는 시간이 함께 들어 있다 |
| 막힘 → 막힘 해소 | 36 | 1.9일 | 막힌 업무가 풀리기를 기다린 시간이다 |
직접 이어짐 관계의 대기 시간에는 두 가지 한계가 있다. 첫째, 달력 시간이라 금요일 오후에 생긴 연결은 주말만큼 길게 나온다. 둘째, “바로 다음 사건”까지의 시간이라, PR 생성 다음에 변경 요청이 오든 리뷰 승인이 오든 “첫 리뷰까지의 대기”라는 하나의 단계로 묶이지 않는다. Orbit에서 PR 생성 뒤의 연결은 “PR 생성 → 리뷰 승인”(184회, 3.6시간)과 “PR 생성 → 변경 요청”(63회, 3.7시간)으로 나뉜다. 단계 단위로 재려면 단계의 시작 사건과 끝 사건을 따로 정해야 한다.
5지도를 위키에 올리기
회의와 위키에는 주된 흐름만 남긴 지도가 읽기 쉽다. 30번 이상 나온 연결만 남기고, 화살표에 대기 시간 중앙값을 적는다.
bash github-pm-starter-kit/process-map.sh pm-lab/orbit-event-log-clean.csv --mermaid time --min-count 30 > pm-lab/orbit-process-map-mermaid.md
실습 17의 wiki-sync.sh --process로 이 파일을 위키의 프로세스 지도 페이지에 올린다. 지도 아래에는 로그 파일 이름, 정리 규칙, 걸러 낸 기준(30회)을 함께 적어 둔다.
6지도가 보여 주지 않는 것
- 병행과 선택의 구분: 직접 이어짐 그래프는 두 활동이 동시에 진행되는 경우(병행)와 둘 중 하나만 일어나는 경우(선택)를 구분하지 못한다. 병행하는 두 활동은 서로를 가리키는 화살표 두 개로 나타난다. 이 구분이 필요하면 페트리넷이나 BPMN 같은 프로세스 모델을 발견하는 알고리즘을 쓴다.
- 기록되지 않은 일: 리뷰어가 PR을 열어 보기 시작한 시각, 회의에서 결정만 하고 댓글을 남기지 않은 일은 지도에 없다.
- 원인: 지도는 어디서 기다렸는지를 보여 줄 뿐 왜 기다렸는지는 보여 주지 않는다. 원인은 비교와 기록 확인으로 좁힌다.
막히면
| 증상 | 확인과 해결 |
|---|---|
| 프로세스 지도 화면이 Launchpad 6건만 보여 준다 | 로그 파일을 읽지 못했다. 교안을 파일로 열었으면(file://) docs 폴더에서 python3 -m http.server를 실행하고 http://localhost:8000으로 연다 |
| 보고서의 숫자가 교안과 다르다 | 원본 로그(orbit-event-log.csv)로 실행했는지 확인한다. 이 실습은 실습 22에서 만든 정리한 로그를 쓴다 |
| 위키에서 흐름도가 그려지지 않는다 | 코드 블록의 언어 표시가 ```mermaid인지 확인한다. 화살표 숫자 안에 |가 들어가면 깨진다 |
pm-lab/orbit-process-map.md를 만들었다.- 프로세스 지도에서 최소 횟수를 바꿔 주된 흐름과 드문 연결을 구분했다.
- 상위 6개 변형이 각각 기본 경로와 어떻게 다른지 설명할 수 있다.
- 대기 시간이 긴 연결 중 계획상 대기(백로그)를 병목과 구분했다.
- 30회 이상 나온 연결만 남긴 흐름도를 만들었다.
마치며...
Orbit의 업무 절반은 기본 경로를 그대로 지났고, 나머지는 변경 요청, 막힘, 결정 기록, 다시 열림이 더해진 경로로 갈라졌다. 직접 이어짐 그래프는 이 갈래를 횟수와 대기 시간으로 보여 주지만, 병행과 선택을 구분하지 못하고 단계 단위의 시간을 재지 못한다. 다음 실습에서는 같은 로그를 PM4Py로 읽어 프로세스 모델을 발견하고, 모델이 로그를 얼마나 잘 설명하는지 숫자로 평가한다.