WBS (Work Breakdown Structure) 가이드
WBS란 무엇인가요?
WBS(Work Breakdown Structure)는 복잡한 프로젝트를 더 작고 관리 가능한 구성 요소로 분해하는 프로젝트 관리 기법입니다. 작업을 계층적으로 분해하여 다음과 같은 도움을 제공합니다:
- 모든 프로젝트 결과물 정의
- 시간과 리소스를 정확하게 추정
- 명확한 책임 할당
- 진행 상황을 체계적으로 추적
Plexo의 WBS 구성 요소
1. 프로젝트
WBS의 최상위 레벨입니다. 각 프로젝트는:
- 이름 및 설명
- 시작 및 종료 날짜
- 팀원 및 리더
- 전체 예산 및 일정
2. 카테고리 (선택사항이지만 권장됨)
작업을 논리적 그룹으로 구성합니다:
- 1단계: 주요 단계 또는 기능 (예: "디자인", "개발", "테스트")
- 2단계: 하위 카테고리 (예: "개발" > "프론트엔드", "백엔드")
예시:
모바일 앱 프로젝트
3. Tasks
실제 작업 항목입니다. 각 작업은 다음을 포함합니다:
- 이름: 명확하고 실행 가능한 제목
- 예상 시간: 소요 예상 시간
- 실제 시간: 실제 소요된 시간 (진행률에서 자동 계산)
- 남은 시간: 아직 필요한 시간
- 담당자: 담당자
- 우선순위: P1 (높음), P2 (보통), P3 (낮음)
- 상태: 계획됨, 진행 중, 완료됨, 취소됨, 재개됨
- 시작/마감일: 예정된 타임라인
- 의존성: 먼저 완료되어야 하는 작업 (곧 출시 예정)
모범 사례
1. 적절한 단위로 세분화하세요
너무 큼: "웹사이트 구축" (500시간) - 추적 및 예측이 어려움
너무 작음: "버튼 색상 변경" (0.5시간) - 관리 부담이 너무 큼
적절함: "사용자 로그인 페이지 구현" (8-40시간) - 관리 및 추적 가능
기본 원칙: 작업은 4-40시간 사이여야 합니다. 작업이 더 크다면 더 세분화하세요.
2. 행동 중심의 이름을 사용하세요
- ✅ 좋음: "홈페이지 목업 디자인", "결제 API 구현", "사용자 가이드 작성"
- ❌ 나쁨: "홈페이지", "결제", "문서화"
3. 보수적으로 예측하세요
여유 시간 추가 (20-30%):
- 예상치 못한 문제
- 코드 리뷰 및 테스트
- 회의 및 커뮤니케이션
- 학습 및 연구
4. 담당자를 명확하게 지정하세요
모든 작업에는 정확히 한 명의 주 담당자가 있어야 합니다. 이는 책임감을 만들고 혼란을 방지합니다.
5. 진행 상황을 정기적으로 업데이트하세요
최소 매일 작업 상태를 업데이트하세요:
- 시작할 때 작업을 "진행 중"으로 이동하세요
- 작업하면서 실제 시간 업데이트
- 완료되면 "완료"로 이동하세요
6. 카테고리를 현명하게 사용하세요
좋은 카테고리 구조:
- 단계별: 기획 → 디자인 → 개발 → 테스트 → 배포
- 기능별: 사용자 인증 → 대시보드 → 리포트 → 설정
- 팀별: 프론트엔드 → 백엔드 → DevOps → QA
일반적인 패턴
소프트웨어 개발 프로젝트
프로젝트: 웹 애플리케이션
마케팅 캠페인
프로젝트: 제품 출시 캠페인
이벤트 기획
프로젝트: 연례 컨퍼런스
고급 팁
종속성을 현명하게 사용
순차적으로 완료해야 하는 작업을 연결하세요:
- "데이터베이스 스키마 설계"는 "데이터베이스 구현" 전에 완료되어야 합니다
- "API 작성"은 "프론트엔드를 API에 연결" 전에 완료되어야 합니다
이는 Plexo가 임계 경로를 계산하고 지연을 예측하는 데 도움이 됩니다.
마일스톤 추적
중요한 프로젝트 체크포인트를 높은 우선순위 작업으로 표시하세요:
- "MVP 데모 준비 완료" - 스프린트 1 종료
- "베타 릴리스" - 출시 전 마일스톤
- "서비스 오픈" - 공식 런칭
검토 및 조정
WBS는 고정된 것이 아닙니다. 프로젝트에 대해 더 많이 알게 되면서:
- 예상치 못한 작업에 대한 새 작업 추가
- 실제 성능을 기반으로 추정치 조정
- 필요에 따라 카테고리 재구성
- 우선순위가 변경될 때 종속성 업데이트