"WBS 만들어놨는데 아무도 안 봐요."
많은 PM이 하는 하소연입니다. 프로젝트 시작할 때 며칠을 들여 만든 WBS가 2주도 안 돼서 먼지만 쌓이고 있다는 거죠.
왜 열심히 만든 WBS가 죽어버릴까요?
답은 간단합니다. WBS를 "문서"로 만들었기 때문입니다. 살아있는 "도구"로 만들어야 합니다.
죽은 WBS vs 살아있는 WBS
죽은 WBS의 일생
Day 1: "완벽한 WBS 완성!" 🎉
Day 7: "음... 실제랑 좀 다르네"
Day 14: "WBS? 그거 어디 있더라?"
Day 21: "그냥 감으로 하자"
Day 30: "WBS 파일 어디 갔지?" (이미 늦음)
투자한 시간: 16시간
활용도: 0%
ROI: -100%
살아있는 WBS의 하루
09:00: "오늘 뭐하지?" → WBS 확인
10:00: Task 시작 → 상태 업데이트
12:00: 진행률 50% → 자동 반영
15:00: 이슈 발생 → 즉시 기록
17:00: Task 완료 → 다음 작업 확인
18:00: 일일 리포트 → 자동 생성
투자한 시간: 16시간
일일 사용: 10분
ROI: 1000%+
왜 WBS가 죽을까?
1. 한 번 만들고 끝
프로젝트는 살아 움직이는데 WBS는 정지해 있습니다. 첫날의 계획이 마지막 날까지 유효할 리 없죠.
2. 업데이트가 귀찮음
기존 방식:
1. 엑셀 파일 찾기 (2분)
2. 최신 버전 확인 (3분)
3. 수정하기 (5분)
4. 저장하고 공유 (2분)
5. "제가 수정했습니다" 메일 (3분)
총: 15분
하루에 3번 업데이트? 45분 낭비
3. 현실과 동떨어짐
WBS: "API 개발 16시간"
현실: "이미 24시간 썼는데 아직도..."
이런 괴리가 생기면 아무도 WBS를 믿지 않습니다.
Living WBS의 5가지 원칙
1. 일일 터치포인트 (Daily Touchpoint)
WBS를 매일 최소 3번은 봐야 합니다.
아침: 오늘 할 일 확인
점심: 진행 상황 업데이트
저녁: 완료 표시, 내일 준비
// 일일 루틴 자동화
const dailyRoutine = {
morning: {
time: "09:00",
action: "오늘의 작업 자동 할당",
notification: "Slack으로 전송"
},
lunch: {
time: "12:00",
action: "진행률 체크 알림",
question: "오전 작업 어떻게 되가나요?"
},
evening: {
time: "18:00",
action: "일일 요약 생성",
report: "완료/진행중/블로커 자동 정리"
}
};
2. 실시간 동기화 (Real-time Sync)
팀원 한 명이 업데이트하면 모두가 즉시 봅니다.
# Before: 파일 기반
def update_wbs_old():
# 1. 파일 다운로드
# 2. 수정
# 3. 업로드
# 4. 이메일 공유
# 5. 충돌 해결...
time_wasted = "30분"
# After: 클라우드 기반
def update_wbs_new():
# 클릭 한 번
# 모두에게 즉시 반영
time_spent = "5초"
3. 진행률 시각화 (Visual Progress)
숫자보다 그래프가 강력합니다.
전체 진행률: ████████░░ 80%
이번 주 번다운:
월 ████████████ 12 tasks
화 ██████████ 10 tasks
수 ████████ 8 tasks
목 ██████ 6 tasks (현재)
금 ???? ? tasks (예상: 3)
한눈에 보이니까 모두가 관심을 갖습니다.
4. 블로커 알림 (Blocker Alert)
문제가 생기면 즉시 알려야 합니다.
블로커 발생:
task: "결제 API 연동"
blocker: "PG사 API 문서 불일치"
impact: "2일 지연 예상"
자동 액션:
- PM에게 즉시 알림
- 관련 팀원 소집
- 대안 경로 제시
- 일정 재조정 시뮬레이션
5. 예측 가능성 (Predictability)
과거 데이터로 미래를 예측합니다.
def predict_completion():
"""과거 속도로 미래 예측"""
completed_tasks = 45
remaining_tasks = 15
days_elapsed = 10
daily_velocity = completed_tasks / days_elapsed # 4.5 tasks/day
days_remaining = remaining_tasks / daily_velocity # 3.3 days
return {
"예상 완료일": "3일 후",
"신뢰도": "85%",
"리스크": "팀원 1명 휴가 시 5일로 연장"
}
실제 적용 사례
사례 1: 스타트업 A팀
Before (죽은 WBS)
- WBS 업데이트 주기: 2주에 한 번
- 정확도: 30%
- 프로젝트 지연: 항상
After (Living WBS)
- WBS 업데이트: 실시간
- 정확도: 90%
- 프로젝트: 예정보다 3일 조기 완료
변화 포인트:
- 엑셀 → 클라우드 도구 전환
- 주간 업데이트 → 일일 스탠드업 연동
- PM 혼자 → 팀 전체 참여
사례 2: 대기업 B팀
문제: 50명 규모 프로젝트, WBS가 너무 복잡
해결책: 계층별 뷰
CEO View: 전체 진행률만 (1개 숫자)
├── PM View: 주요 마일스톤 (10개 항목)
│ ├── Team Lead View: 스프린트 목표 (50개)
│ │ └── Developer View: 일일 태스크 (500개)
각자 필요한 수준만 보니 모두가 WBS를 활용합니다.
Living WBS 구현 전략
Step 1: 도구 선택
필수 기능:
- 실시간 협업
- 모바일 지원
- 알림 기능
- API 연동
- 시각화
추천 도구:
- Plexo: WBS 특화, 실시간 동기화
- Jira: 개발팀 친화적
- Monday: 시각화 강점
Step 2: 습관 만들기
## 일일 WBS 체크리스트
### 아침 (5분)
- [ ] 어제 완료 작업 확인
- [ ] 오늘 작업 선택
- [ ] 예상 시간 입력
### 점심 (2분)
- [ ] 오전 작업 진행률 업데이트
- [ ] 블로커 있으면 표시
### 퇴근 전 (3분)
- [ ] 오늘 작업 완료 표시
- [ ] 내일 작업 미리보기
- [ ] 이슈 있으면 코멘트
Step 3: 팀 문화 만들기
WBS를 문화로:
- 스탠드업 미팅: WBS 화면 공유하며 진행
- 코드 커밋: WBS 태스크 번호 포함
- 성과 평가: WBS 완료율 반영
자동화로 살아있게 하기
Git 연동
# 커밋 메시지에 WBS 번호 포함
git commit -m "[WBS-123] 로그인 API 구현 완료"
# 자동으로 WBS 업데이트
# WBS-123: 진행중 → 완료
CI/CD 연동
# 배포 성공 시 WBS 자동 업데이트
deploy:
on_success:
- update_wbs_task("DEPLOY-01", "completed")
- notify_team("배포 완료!")
캘린더 연동
// WBS 마감일 → 구글 캘린더
function syncToCalendar(task) {
calendar.createEvent({
title: `[WBS] ${task.name}`,
date: task.dueDate,
reminder: "1일 전"
});
}
Living WBS의 ROI
실제 측정 결과:
시간 절약
- 일일 상태 회의: 30분 → 10분
- 주간 보고서 작성: 2시간 → 자동
- 진행 상황 파악: 즉시
품질 향상
- 일정 정확도: 50% → 85%
- 블로커 해결 시간: 2일 → 4시간
- 팀 만족도: 2배 상승
비용 절감
- 프로젝트 지연 감소: 80%
- 재작업 감소: 60%
- 커뮤니케이션 비용: 50% 감소
주의사항
과도한 업데이트 피하기
❌ 나쁜 예:
- 10분마다 업데이트
- 모든 세부사항 기록
- 1% 단위 진행률
✅ 좋은 예:
- 의미 있는 진척 시 업데이트
- 핵심 정보만 기록
- 25% 단위 진행률
도구에 종속되지 않기
도구는 수단일 뿐입니다. 중요한 건 매일 보고 업데이트하는 습관입니다.
마무리: WBS는 정원과 같다
WBS는 정원과 같습니다. 한 번 만들고 방치하면 잡초만 무성해집니다. 매일 물 주고 가꾸면 아름다운 꽃을 피웁니다.
Living WBS의 핵심:
- 매일 터치
- 실시간 동기화
- 시각화
- 자동화
- 팀 참여
죽은 문서 대신 살아있는 도구를 만드세요.
프로젝트가 살아납니다.
실시간으로 살아 움직이는 WBS 관리가 필요하신가요? Plexo를 확인해보세요.
댓글 없음:
댓글 쓰기