작업 분해와 역할

“신청 앱 완성”을 한 사람에게 맡겼더니 코드는 있지만 취소 정책과 실행 안내가 빠졌습니다. 기능 이름만으로 계획을 만들면 업무 합의와 검증을 누락하기 쉽습니다.

WBS(작업 분해 구조)는 전체 범위를 관리 가능한 작업으로 나누는 구조입니다. 기능 메뉴와 달리 정책 확인·테스트·문서·릴리스 준비도 포함합니다. 분해의 끝인 작업 묶음은 담당과 완료 증거를 정할 수 있을 만큼 구체적이어야 합니다.

같은 기능의 서로 다른 작업

신청을 “정원 검사 코드” 하나로 나누지 않습니다. 정책 확정, 상태 모델, 함수 구현, 경계 테스트, 안내, 저장 계약을 함께 생각합니다. 너무 작은 타이핑 단위로 나누면 관리 비용이 커지고 너무 크면 지연 원인을 찾기 어렵습니다.

다음 표를 work-plan.md에 저장하고 자신의 담당을 적습니다.

| 작업 | 입력·전제 | 완료 증거 | 담당·검토자 |
| --- | --- | --- | --- |
| 중복 정책 확정 | 진행자 사례 | R3 수락 조건 | 업무 담당 / 진행자 |
| 신청 함수 제작 | 유효 상태 계약 | 반환 코드·상태 | 제작자 / 코드 검토자 |
| 경계 검증 | 정원·ID 조건 | 실패 없는 사례와 범위 | 검증자 / 제작자 |
| 안내 인수 | 결과 코드 표 | 다음 행동이 드러나는 안내 | 문서 담당 / 사용자 |

책임은 결과를 만들거나 결정해야 하는 의무이고 권한은 그 결정을 수행할 수 있는 범위입니다. 제작자가 정원 정책을 임의로 바꿀 권한이 있는지 불명확하면 다시 작업하게 됩니다. 한 사람이 여러 역할을 맡아도 사용자 관점과 코드 관점의 확인을 구분합니다.

조직이 협업에 미치는 영향

기능별 조직에서는 구성원이 개발·검증·운영 등 전문 부문에 속합니다. 전문성을 공유하기 쉽지만 프로젝트 우선순위가 부문 사이에서 충돌할 수 있습니다. 프로젝트 조직은 하나의 결과에 팀을 집중합니다. 판단 경로가 짧을 수 있지만 다른 프로젝트와 자원·지식을 공유하기 어려울 수 있습니다. 매트릭스 조직은 기능 부문과 프로젝트 책임을 함께 가집니다. 누구의 지시를 우선할지 분명히 해야 합니다.

작은 모임 앱에서는 한 명이 개발과 검증을 맡아도 사용자 정책 확인은 진행자에게 받아야 할 수 있습니다. 규모가 커지면 모듈별·기능별·기간별 업무 배치의 장단점도 달라집니다. 조직 형태 이름만으로 소통 비용을 제거할 수는 없습니다.

범위와 완료 상태를 코드로 표현

아래 코드를 work-check.mjs로 실행합니다. 이는 실제 일정 도구가 아니라 빠진 확인 항목을 찾는 작은 목록입니다.

const work = [
  { id: "policy", evidence: "R3 approved" },
  { id: "implementation", evidence: "core.mjs" },
  { id: "test", evidence: "" },
  { id: "guide", evidence: "result codes reviewed" },
];
console.log(work.filter((item) => !item.evidence).map((item) => item.id));

결과는 test입니다. 파일 경로가 있다는 이유만으로 검증 완료로 세지 않습니다. 실제 계획에서는 증거의 존재뿐 아니라 내용·버전·검토 상태를 확인해야 합니다.

독립 문제: 두 책임자의 충돌

검증 담당은 취소 회귀 테스트가 없어서 인수를 보류하고 프로젝트 담당은 버튼이 완성됐으므로 완료 처리하려 합니다. 작업 분해와 결정 책임에 어떤 내용이 빠졌는지, 해결할 기록을 제시하세요.

다음 문서는 작업 규모를 숫자로 표현할 때 어떤 가정을 남겨야 하는지 다룹니다.