0. 이 책은 Asana 설명서가 아니다
이 책은 Asana 사용법 책처럼 보인다. 하지만 목적은 Asana 기능을 익히는 것이 아니다.
Asana는 예시일 뿐이다. 이 책이 다루는 진짜 주제는 업무를 나중에 봐도 알 수 있는 형태로 만드는 법이다.
대부분의 조직은 일을 만들 때보다 일을 판단할 때 더 많이 흔들린다. 처음에는 모두가 무슨 일인지 아는 것처럼 보인다. “이거 확인해주세요”, “정리해주세요”, “요청해주세요” 같은 문장으로도 충분해 보인다. 문제는 며칠 뒤에 생긴다.
그때 질문은 이렇게 바뀐다.
- 이 일은 왜 생긴 것인가?
- 끝났다고 볼 기준은 무엇이었나?
- 담당자가 이어가고 있나?
- 지금 우리 차례인가, 외부 회신 대기인가?
- 완료 처리해도 되는가?
- 안 끝났다면 무엇이 남았나?
처음 만든 태스크가 이 질문에 답하지 못하면, 중간 점검은 기억 싸움이 된다. 누군가는 “거의 된 것 같은데요”라고 말하고, 누군가는 “그게 완료가 맞나요”라고 묻는다. 에이전트(agent)는 맥락을 추측한다. 결과적으로 태스크는 있었지만 업무구조는 없었던 셈이다.
이 책은 그 문제를 막기 위한 책이다.
핵심 명제
좋은 태스크는 생성 시점부터 중간 점검이 가능하다.
이 말은 간단하지만 운영상 매우 중요하다. 나중에 판단 기준를 덮어씌우는 방식으로는 일관성이 생기지 않는다. 태스크를 줄 때부터 목표, 끝났다고 볼 기준, 보통 걸리는 시간(SLE), 지금 할 일(next action), 남의 답 기다림(Waiting For), 담당, 확인, 막힌 기준(Blocked), 결과 남길 곳이 들어 있어야 한다.
그래야 나중에 누가 보더라도 같은 질문을 던질 수 있다.
원래 목표는 무엇인가?
끝났다고 볼 기준은 무엇인가?
현재 결과물은 기준을 채웠는가?
보통 걸리는 시간(SLE)을 넘었는가?
지금 누구 차례인가?
막힌 것인가, 기다리는 것인가?
책임자는 한 명인가?이 책의 이론 골격
이 책은 여러 업무관리 이론을 섞지만, 아무 기준이나 끌어오지 않는다. 각각 쓰임새가 다르다.
| 판단 항목 | 주 이론 | 역할 |
|---|---|---|
| 상위 목표 / 왜 하는 일인가 | 상위목표(OKR) | 이 일이 어떤 목표(objective)나 결과(outcome)에 붙어 있는지 본다 |
| 이 태스크의 합격조건 | 끝났다고 볼 기준(완료조건 / Acceptance Criteria) / 상황-행동-결과(Given-When-Then) | 완료를 관찰 가능한 결과로 판단한다 |
| 진행 중인지, 늙었는지, 막혔는지 | 흐름관리(Kanban) / 일의 나이(Work Item Age) / 보통 걸리는 시간(SLE) / 막힘(Blocked) | 시작 후 경과시간과 보통 걸리는 시간을 비교한다 |
| 지금 누구 차례인지 | 일처리 정리법(GTD) / 지금 할 일(Next Action) / 남의 답 기다림(Waiting For) | 우리 차례인지, 남의 답 기다림인지, 지금 할 일이 없는지 본다 |
| 책임자가 분명한지 | 책임구분표(RACI) / 끝까지 들고 갈 사람(DRI) | 책임자(owner) 0명 또는 2명 이상이면 주인 없는 일(orphan)로 본다 |
| 어디부터 손볼지 | 병목이론(TOC) | 병목이 정의, 책임자(owner), 외부자료, 승인 중 어디인지 찾는다 |
| 목표 품질 보정 | 목표설정 이론(Locke & Latham Goal Setting) | 목표가 구체적이고 피드백 가능해야 한다는 근거로 쓴다 |
중심은 네 가지다.
상위목표(OKR)
+ 끝났다고 볼 기준(완료조건 / Acceptance Criteria)
+ 흐름관리(Kanban) / 일의 나이(Work Item Age) / 보통 걸리는 시간(SLE) / 막힘(Blocked)
+ 일처리 정리법(GTD) / 지금 할 일(Next Action) / 남의 답 기다림(Waiting For)책임구분표(RACI), 병목이론(TOC), 목표설정 이론(Locke & Latham)은 보조 렌즈다. 책임자가 흐릴 때, 병목을 찾을 때, 목표 문장이 너무 모호할 때 붙인다.
일부러 빼는 것들
이 책은 공통완료정의(Definition of Done)를 중심에 두지 않는다. 스크럼 완료정의(Scrum DoD)는 제품증분(product Increment)의 공통 품질 게이트에 가깝다. 행정, 정산, 채용, 자료요청, 확인 같은 단건 업무에는 태스크별 끝났다고 볼 기준(완료조건 / Acceptance Criteria)이 더 정확하다.
사용자 이야기 점검법(INVEST)도 중심에 두지 않는다. 이것은 사용자 이야기(user story)를 잘 썼는지 보는 기준이지, 지금 이 일이 완료됐는지 판단하는 기준이 아니다.
색상보고(RAG)도 이론으로 쓰지 않는다. 빨강, 노랑, 초록은 보고용 색상이다. 마지막 출력 형식으로는 쓸 수 있지만, 판단 근거가 될 수는 없다.
이 책의 목표는 색깔을 붙이는 것이 아니라, 왜 그 색깔인지 설명할 수 있는 업무구조를 만드는 것이다.