WBS 표는 먼저 여기서 갈리기 시작합니다
구글 스프레드시트 WBS를 찾는 분들은 보통 멋진 양식이 필요한 게 아닙니다. 일이 어디서 밀리는지, 누가 뭘 잡고 있는지, 오늘 바로 확인할 표가 필요한 경우가 많아요.
처음부터 복잡하게 만들 필요는 없습니다. 작업명, 담당자, 시작일, 종료일, 상태만 있어도 흐름이 보입니다. 여기에 우선순위나 메모를 살짝 붙이면 작은 프로젝트는 꽤 오래 버팁니다.
구글 스프레드시트 WBS는 팀원이 같이 보는 표라서 더 실용적입니다. 엑셀 파일을 주고받는 것보다 수정 흔적이 보이고, 회의 중에도 바로 고칠 수 있거든요.
잠깐 정리하면, 처음 만들 때는 이 순서가 편합니다.
- 작업을 너무 크게 쓰지 않기
- 담당자를 한 명 기준으로 정하기
- 날짜는 실제 시작 가능한 날로 넣기
- 상태값은 4개 안쪽으로 줄이기
- 회의 때 바뀐 내용은 바로 표에 반영하기
프로젝트 문서가 아직 헷갈린다면 기능정의서 작성방법처럼 요구사항을 먼저 쪼개는 글을 같이 보면 감이 더 빨리 옵니다. WBS는 결국 일을 작게 나눈 표라서요.
처음 표는 네 칸부터 확인하면 됩니다
구글 스프레드시트 WBS를 처음 만들 때 가장 많이 하는 실수는 열을 너무 많이 넣는 겁니다. 리스크, 산출물, 의존성, 상세 메모까지 한 번에 넣으면 표가 있어 보이긴 해요.
근데 막상 팀원이 쓰기 시작하면 안 채워집니다. 표가 무거워지면 회의 때 아무도 업데이트를 안 해요. 이거 은근 중요합니다.
처음에는 아래처럼 작게 시작하는 게 낫습니다.
| 구분 | 넣을 내용 | 왜 필요한지 |
|---|---|---|
| 작업명 | 실제 해야 할 일 | 너무 큰 덩어리를 쪼개기 위해 |
| 담당자 | 책임지는 사람 1명 | 애매한 일을 줄이기 위해 |
| 일정 | 시작일과 종료일 | 밀리는 지점을 보기 위해 |
| 상태 | 예정, 진행, 대기, 완료 | 회의 때 바로 보기 위해 |
구글 스프레드시트 WBS는 “관리자가 보기 좋은 표”보다 “팀원이 계속 고치는 표”가 더 오래 갑니다. 그래서 칸을 줄이는 게 오히려 실무에서는 이깁니다.
날짜보다 작업 쪼개기가 먼저입니다
일정표를 만들다 보면 날짜부터 넣고 싶어집니다. 월요일부터 금요일까지 줄을 쭉 깔아두면 뭔가 프로젝트가 잡힌 느낌이 들거든요.
그런데 날짜보다 먼저 볼 건 작업 크기입니다. “회원가입 개발”처럼 큰 작업은 밀렸을 때 원인을 찾기가 어렵거든요. “약관 동의 화면”, “이메일 인증”, “가입 완료 알림”처럼 나눠야 막히는 곳이 보여요.
구글 스프레드시트 WBS에서 작업명은 작을수록 좋아요. 하루나 이틀 안에 확인 가능한 크기면 회의 때 상태를 바꾸기도 쉬워요.
요구사항이 아직 덜 쪼개졌다면 요구사항 정의서 작성법에서 먼저 기능 단위를 잡고 오는 편이 낫습니다. 큰 요구사항을 그대로 일정표에 넣으면 나중에 표만 커집니다.
담당자와 상태값은 여기서 짧게 갑니다
구글 스프레드시트 WBS가 지저분해지는 순간은 보통 담당자와 상태값에서 옵니다. 담당자가 여러 명이면 책임이 흐려지고, 상태값이 많으면 보는 사람이 해석해야 합니다.
담당자는 가능하면 한 명만 적습니다. 같이 일하는 사람이 있어도 표에는 책임자 한 명을 세워두는 편이 깔끔해요.
상태값도 네 개면 충분합니다.
- 예정
- 진행
- 대기
- 완료
여기에 “검토중”, “보류”, “재확인”, “이슈”, “완료 예정” 같은 말을 계속 늘리면 표가 말장난처럼 됩니다. 상태는 짧고, 설명은 메모에 적는 게 낫습니다.
구글 스프레드시트 WBS는 회의 중 10초 안에 읽혀야 합니다. 누가 봐도 밀린 일과 끝난 일이 보여야 진짜 쓸모가 생깁니다.
실제 업무에서는 여기서 많이 꼬입니다
표를 만들었는데도 일정이 계속 밀린다면 원인은 양식이 아닐 수 있습니다. 작업이 너무 크거나, 담당자가 애매하거나, 완료 기준이 없는 경우가 많습니다.
예를 들어 “관리자 페이지 작업”이라고만 쓰면 완료 기준이 흐립니다. 목록 화면인지, 검색인지, 권한인지, 엑셀 다운로드인지 서로 다르게 생각할 수 있어요.
구글 스프레드시트 WBS에서는 작업명 옆에 완료 기준을 짧게 붙이면 좋습니다. “검색 조건 3개 적용”, “권한별 버튼 노출 확인”처럼 끝난 상태가 보이면 대화가 줄어듭니다.
QA 단계까지 생각한다면 서비스 기획자 QA 체크리스트로 이어서 보는 게 좋습니다. WBS에서 끝났다고 표시한 일이 실제 화면에서도 문제없이 돌아가는지는 또 다른 이야기거든요.
팀 공유용은 색보다 규칙을 먼저 봅니다
색을 잘 쓰면 보기 좋습니다. 그런데 색이 너무 많으면 의미가 흐려져요. 빨강, 노랑, 초록 정도만 써도 충분합니다.
구글 스프레드시트 WBS를 팀에서 같이 쓸 때는 색보다 규칙을 먼저 정해야 합니다. 언제 상태를 바꾸는지, 누가 날짜를 고치는지, 대기 상태는 어떤 경우에 쓰는지만 합의해도 표가 덜 흔들립니다.
작은 규칙은 이런 식으로 잡으면 됩니다.
- 상태 변경은 담당자가 직접
- 일정이 밀리면 종료일과 사유를 같이 기록
- 대기는 외부 답변이나 의사결정이 막힌 경우만
- 완료 전 확인자가 한 번 더 체크
구글 스프레드시트 WBS는 자동화 도구가 아닙니다. 대신 모두가 같은 표를 보게 만드는 약속에 가깝습니다.
자주 묻는 질문, 여기서 많이 헷갈립니다
구글 스프레드시트 WBS는 엑셀보다 뭐가 편한가요
같이 수정하기 편한 게 가장 큽니다. 파일을 주고받지 않아도 되고, 회의 중에 담당자나 날짜를 바로 바꿀 수 있습니다. 단순한 프로젝트라면 별도 관리 도구보다 가볍게 시작하기 좋아요.
다만 복잡한 의존성, 리소스 관리, 자동 알림이 필요하다면 전용 프로젝트 관리 도구가 더 맞을 수 있습니다. 구글 스프레드시트 WBS는 작은 팀이 빠르게 맞춰보는 용도로 생각하면 편합니다.
어떤 열부터 만들면 덜 복잡한가요
작업명, 담당자, 시작일, 종료일, 상태부터 만들면 됩니다. 처음부터 너무 많은 열을 넣으면 관리하는 사람이 지치고, 팀원도 업데이트를 미루게 됩니다.
구글 스프레드시트 WBS는 처음 표가 작아야 오래 갑니다. 나중에 진짜 필요해진 열만 하나씩 붙이는 편이 훨씬 나아요. 특히 메모, 우선순위, 완료 기준은 프로젝트가 한 번 돌아간 뒤 추가해도 늦지 않습니다.
상태값은 몇 개가 적당한가요
예정, 진행, 대기, 완료 정도면 충분해요. 상태값이 많아지면 표를 읽는 사람이 매번 의미를 해석하게 됩니다.
대기와 보류를 나누고 싶을 때도 있지만, 초반에는 하나로 묶는 게 좋아요. 중요한 건 상태 이름이 아니라 왜 멈췄는지 메모에 남기는 일이에요.
상태값은 적을수록 회의가 빨라집니다. 이름을 많이 만들기보다 멈춘 이유와 다음 확인자를 적어두는 쪽이 훨씬 덜 헷갈립니다.
오늘 바로 손볼 곳은 한 줄입니다
구글 스프레드시트 WBS를 이미 만들어뒀다면 전체를 갈아엎지 않아도 됩니다. 먼저 작업명이 너무 큰 줄 하나만 골라서 더 작게 쪼개보세요.
그다음 담당자가 애매한 줄, 상태가 오래 멈춘 줄, 종료일만 계속 밀리는 줄을 보면 됩니다. 표 전체를 예쁘게 만드는 것보다 막힌 줄을 찾는 게 먼저입니다.
작게 손보면 팀 대화도 달라집니다. “왜 늦었나요”가 아니라 “어느 작업이 막혔나요”로 바뀌거든요. 그 차이가 WBS를 쓰는 이유입니다.
지금 쓰는 표에서 제일 애매한 작업명 하나를 골라보세요. 그 한 줄이 정리되면 다음 회의가 꽤 가벼워집니다.
