넘겨받은 커머스의 개발을 이끌 리더가 새로 합류했다. 지금까지의 일은 보고서와 대화 기록에 흩어져 있었고, 시스템 전체를 설명한 Markdown 문서는 145KB, GitHub 저장소 목록은 84KB 였다. 이것을 그대로 건네면 받는 사람은 무엇부터 정해야 하는지 모른 채 수백 KB 를 읽게 된다. 그래서 두 가지를 결정했다. 인계 문서를 어떤 순서로 쓸지, 그리고 리더가 매일 볼 업무 보드를 어떤 단위로 둘지다.
Table of contents
Open Table of contents
배경 — 받는 사람이 첫날 해야 하는 일
인계를 받는 사람은 리더다. 리더가 첫날 해야 하는 일은 경위를 이해하는 것이 아니라 무엇부터 할지 정하는 것이다. 그런데 넘겨받은 시스템은 이름이 비슷한 것이 많아, 순서 없이 읽으면 어느 화면이 어느 시스템인지부터 헷갈린다. 고객 웹(PC·모바일)과 iOS·Android 앱은 같은 Google Firebase 데이터를 쓰고, 직원이 쓰는 백오피스는 새 백오피스와 옛 PHP 백오피스 두 계열로 나뉘며, 뒤에서는 출고 회차·주문 마감·자동 결제가 정해진 시각에 돈다. 옛 PHP 백오피스에서는 출고 담당이 매일 출고 목록을 Excel 로 내려받아 위탁 출고처로 보내고, 회신받은 송장번호 Excel 을 다시 올린다.
판단 — 인계 문서의 순서
순서를 짜는 방법은 두 가지가 있었다.
- 일어난 순서대로 쓴다. 배경 → 시스템 → 범위가 늘어난 경위 → 지금 상태 → 앞으로 할 일
- 받는 사람이 할 일의 순서대로 쓴다. 앞으로 할 개발과 우선순위 → 그 판단에 필요한 배경 → 시스템 → 경위
2번을 고른 이유는 받는 사람이 정할 것을 맨 앞에 두어야 하기 때문이다. 1번은 기록으로는 정확한 대신 결정할 것이 맨 끝에 묻힌다. 반면 2번은 결정할 것이 첫 절에 오고, 배경은 그 결정에 필요한 만큼만 뒤에서 받친다. 대가는 경위가 뒤로 밀려, 왜 이렇게 됐는지가 궁금한 독자는 여러 절을 오가야 한다는 점이다.
그래서 문서는 「앞으로 할 개발 — 우선순위와 기획(받는 사람이 정할 것)」을 첫 절로 두고, 그다음에 배경·시스템 지도·범위가 늘어난 경위·계약으로 정한 범위·GKE 테스트 서버에서 확인 중인 것을 이어 붙였다. 메신저·메일·회의에서 이미 내려진 결정을 모은 절을 따로 두고, 운영 쪽 남은 일은 「회사 결정 · 외부 · 기한」으로 나눈 뒤 끝에 한 장 요약을 붙였다. 이미 내려진 결정이 대화 기록에만 있으면, 새로 온 사람에게는 없는 결정과 같다.
해결 — 진척률이 실제로 도는 업무 보드
리더가 쓰는 업무 보드는 Notion 의 과제·세부 업무 데이터베이스였다. 현황을 내보내 보니 진척률은 「세부 업무 중 상태가 완료인 수 ÷ 전체 수」로만 계산되고, 날짜와 단계는 계산에 쓰이지 않았다. 세부 업무가 서술형 문장 하나에 여러 일을 담고 있으면, 그 행은 다 끝나기 전까지 완료가 되지 않아 진척률이 실제보다 낮게 머문다. 리더의 요구도 같았다. 세부 업무를 짧은 작업 단위로 나누고, 상태와 기간을 채워 진척률과 WBS 타임라인이 제대로 돌게 해 달라는 것이었다.
재설계에는 규칙을 먼저 정했다.
- 행을 지우지 않는다. 바꾸는 것은 제목·단계·상태·담당·시작일·완료예정일·실제완료일뿐이다
- 리더가 직접 쓴 「기존 기록」 행은 제목을 바꾸지 않고 빈 칸만 채운다
- 새로 쪼갠 행은 Notion API 의
createSub로 만들고, 등록 기준 칸에 「제안·확인 필요」를 둔다 - 과제(상위) 행의 시작일은 세부 업무의 가장 이른 시작일로, 완료예정일은 가장 늦은 완료예정일로 채운다
- 상태가 완료인 세부 업무는 실제완료일을 반드시 채운다. 내보낸 현황에서 누락이 2건 있었다
- 제안한 일정은 날짜 칸에 넣되, 근거 칸에 「일정 제안」이라고 적어 확정 일정과 구분한다
보드는 외부와 함께 보는 곳이라, 보안·인프라 항목은 「관리자 화면 보안 보강」처럼 일반 표현으로만 쓰고 결함의 모양·IP·키 이름은 넣지 않는다는 원칙도 함께 정했다. 다만 이 재설계를 실제 보드에 반영하는 것은 결정을 받은 뒤로 미뤘다.
결과 — 리더의 첫 결정과 보드의 숫자
- 리더의 첫 결정. 인계 문서의 첫 절이 「받는 사람이 정할 것」이 되어, 우선순위 결정이 경위 이해를 기다리지 않게 했다
- 진척률의 신뢰. Notion 보드의 진척률과 WBS 타임라인이 무엇으로 계산되는지 확인한 뒤 작업 단위를 바꾸기로 해, 보드의 숫자가 실제 진행을 따라가게 할 기준을 세웠다
- 남이 쓴 기록의 보존. 행을 지우지 않고 남이 쓴 제목을 바꾸지 않는 규칙으로, 보드를 고치면서 이전 기록을 잃는 위험을 없앴다
정리
- 인계 문서는 받는 사람의 첫 일부터 쓴다. 리더에게는 정할 것이 맨 앞이다
- 이미 내려진 결정은 따로 모아 넘긴다. 대화 기록에만 있는 결정은 새 사람에게 없는 결정이다
- 업무 보드의 진척률이 무엇으로 계산되는지 먼저 확인한다. 한 행에 여러 일이 들어 있으면 진척률은 실제보다 낮게 머문다
- 남이 쓴 행은 지우거나 제목을 바꾸지 않고 빈 칸만 채운다