마인드맵(mind map)은 프로젝트의 첫 두 시간에는 알맞은 도구이고, 그 이후에는 맞지 않는 도구입니다. "이 프로젝트는 무엇으로 이루어져 있고, 무엇이 무엇에 의존하는가"라는 질문에는 아주 강하지만, 날짜와 담당자, 진행 상황에는 약합니다. 이후 여섯 달은 바로 그런 것들로 채워집니다.
그래서 쓸 만한 방식은 "마인드맵으로 프로젝트를 계획한다"가 아닙니다. 범위를 맵으로 그리고, 잎(리프)을 추정할 수 있을 때까지 분해한 다음, 그 잎을 실제로 작업을 추적하는 도구로 내보내는 것입니다. 맵의 역할은 인계에서 끝납니다. 그 뒤에는 누군가 "이 작업은 왜 있는 거죠?"라고 물을 때 다시 읽어 보는 자료로 남습니다.
단계가 아니라 결과물로 가지를 나누기
기본 구조는 조사 → 설계 → 구축 → 테스트 → 출시인데, 거의 항상 잘못된 구조입니다. 단계 가지는 프로젝트가 어떻게 움직이는지를 보여 줄 뿐, 무엇이 만들어지는지는 보여 주지 않습니다. 그래서 결과물 하나하나가 다섯 개의 가지에 흩어지고, 어느 것도 전체를 한눈에 볼 수 없게 됩니다.
끝났을 때 존재하게 될 것들을 기준으로 가지를 나누세요.
# Website relaunch
## Content
## Design system
## Build
## Migration
## Launch comms
이 가지들에는 각각 담당자가 있고, 완료의 정의가 있으며, "끝났는가"를 가리는 분명한 기준이 있습니다. 단계에는 없습니다.
예외는 건설 일정이나 규제 기관 제출처럼 진짜로 순서대로 진행되는 프로젝트, 즉 단계 자체가 결과물인 경우입니다. 이때는 방사형 대신 타임라인 레이아웃을 써서 순서를 암시하지 말고 직접 그려 주세요.
추정할 수 있는 잎까지 분해하기
각 가지를 논쟁 없이 걸리는 시간을 말할 수 있는 지점까지 계속 쪼갭니다. 그 지점이 맵의 맨 아래이고, 그 지점을 찾는 것이 이 작업의 전부입니다.
충분히 갔다는 신호는 두 가지입니다.
- 잎이 한 사람의 작업이고, 한 번 앉아서 하거나 하루면 끝납니다. 두 사람이 필요하다면 잎 두 개와 인계 한 번입니다.
- 추정이 논의가 아니라 숫자로 나옵니다. "이틀에서 2주 사이"라면 그 노드에 아직 답이 없는 질문이 들어 있다는 뜻이니, 그 질문을 기준으로 나눕니다.
너무 멀리 갔다는 신호도 두 가지입니다. 잎이 약 100개를 넘거나, 잎이 작업 단위가 아니라 단계별 체크리스트가 되어 버린 경우입니다. "마이그레이션 스크립트 작성"을 여덟 줄의 의사 코드로 쪼개는 것은 받아 적기일 뿐입니다.
보통 3~4단계에서 멈춥니다. 한 가지만 그보다 깊어진다면, 그 가지는 그 자체로 하나의 프로젝트이니 별도의 맵이 필요하다는 뜻입니다.
사람들이 잊어버리는 가지
모든 프로젝트 맵에 이 네 가지를 추가하세요. 일정이 초과되는 네 가지 원인인데, 누구의 결과물도 아니어서 대부분의 계획에서 빠져 있습니다.
- 다른 사람에 대한 의존. 외부의 누군가가 응답할 때까지 프로젝트가 멈추는 모든 지점. 법무 검토, API 키, 클라이언트 승인 같은 것들입니다. 하나하나에 이름을 붙이고 소요 기간을 적습니다.
- 알 수 없는 것. 아직 추정할 수 없는 것들. 추정할 수 없다는 이유로 빼지 마세요. 바로 그래서 눈에 보여야 하고, 이런 것들의 가지가 있는 계획이 정직한 계획입니다.
- 하지 않을 것. 범위에서 제외하는 항목을 분명히 적습니다. 이 가지는 프로젝트에서 가장 비싼 대화를 막아 줍니다. 넉 달째에 "그건 원래 범위 안이었나요"를 두고 벌어지는 그 대화입니다.
- 완료의 기준. 프로젝트 전체의 인수 기준. 의견이 갈려도 아직 비용이 적게 드는 시작 시점에 적어 둡니다.
의존 관계를 교차 링크로 잇기
계층 구조는 포함 관계만 보여 줍니다. "콘텐츠 모델이 승인되기 전에는 마이그레이션을 시작할 수 없다" 같은 관계는 보여 주지 못합니다. 그 사실은 가지와 가지 사이에 있고, 일정을 결정하는 것도 바로 그 사실입니다.
그 링크를 그려 넣으세요. 그런 다음 맵에서 두 가지를 읽습니다.
들어오는 링크가 많은 노드가 병목입니다. 계획 어디에 있든 가장 먼저 시작해야 할 대상이고, 대개 아무도 먼저 하고 싶어 하지 않는 일입니다.
네다섯 개로 이어진 링크의 사슬이 대략적인 크리티컬 패스입니다. 마인드맵이 계산해 주지는 않지만, 가장 긴 사슬이 보이면 어느 가지에 여유가 없는지는 알 수 있습니다.
임의의 두 토픽을 잇는 교차 링크 덕분에 의존 관계 레이어를 만들 수 있고, 진행률이 가지로 합산되는 체크박스 덕분에 결과물마다 자기 완료율을 보고합니다. 레이아웃은 여덟 가지라서 순차적인 프로젝트는 타임라인으로, 범위 정리 맵은 방사형으로 그릴 수 있습니다.
기능맵에서 추정하기
아래에서 위로, 범위로 추정합니다. 각 잎에 추정치를 넣고, 가지의 합계가 자동으로 합산되게 하고, 그 합계를 주어진 마감일에 맞추고 싶은 충동을 참으세요. 두 숫자의 차이가 이 작업 전체에서 가장 쓸모 있는 결과이고, 평균을 내서 없애 버리면 그 가치가 사라집니다.
지켜 둘 만한 습관이 두 가지 있습니다.
한 점이 아니라 범위로 추정하세요. "3~8일"에는 "5일"이 버리는 불확실성이 담겨 있고, 범위의 폭을 보면 어떤 잎을 더 고민해야 하는지 알 수 있습니다.
조율 비용을 명시적으로 더하세요. 네 명이 서른 개의 작업을 하는 프로젝트는 서른 개의 추정치를 더한 값이 아닙니다. 리뷰, 인계, 대기도 실제 작업이며, 아무도 믿지 않는 비율 버퍼보다 이를 위한 가지를 두는 편이 더 정직합니다.
그다음에는 맵에서 나오기
사람들이 건너뛰는 단계이고, "마인드맵으로 계획했다"가 나쁜 결말로 끝나기 쉬운 이유입니다.
잎을 작업 추적 도구로 내보내세요. 대부분의 마인드맵 앱은 Markdown이나 OPML로 내보낼 수 있고, 대부분의 추적 도구는 Markdown 체크리스트를 가져올 수 있으니 2분이면 끝납니다. 추적 도구가 할 수 있고 맵이 할 수 없는 일은 담당자 지정, 날짜 보관, 지연 표시, 여섯 사람의 동시 업데이트입니다.
다만 맵은 남겨 두고, 읽기 전용으로 두세요. 그 뒤의 역할은 "이 작업은 왜 있는가", "이것을 빼면 무엇이 깨지는가"에 답하는 것입니다. 두 질문 모두 추적 도구가 평평하게 만들어 버린 구조에 관한 것이라 추적 도구는 답할 수 없습니다.
편집하려고 다시 여는 것은 범위가 바뀔 때만으로 하세요. 추적 도구와 나란히 매일 관리되는 맵은 기준이 되는 자료가 둘이라는 뜻이고, 그중 하나는 항상 틀립니다.
혼자 프로젝트를 계획할 때
규칙이 조금 다르고, 오히려 더 좋습니다. 맵은 한 번 앉아서 만들고, 두 단계보다 깊게 분해하지 말고, 날짜는 외부 마감이 있는 것에만 넣으세요.
혼자 하는 일에서 가치는 거의 전부 "하지 않을 것"과 "알 수 없는 것" 가지에 있습니다. 계획이 한 사람의 머릿속에 있을 때 보이지 않게 되는 두 가지이고, 혼자 하는 프로젝트를 조용히 갉아먹는 두 가지이기도 합니다.