프로젝트는 길어질수록 리스크가 기하급수적으로 커집니다.
3개월 이내로 마무리할 수 있도록 범위를 조정하세요.
불가피하게 크다면 완결성 있는 단위로 나누는 것이 핵심입니다.
단순히 태스크를 쪼개는 것과 완결성 있는 결과물을 만드는 것은 다릅니다.
테스트까지 마쳐서 사용자에게 보여줄 수 있는 상태로 쪼개야 합니다.
IT 과제에서 1+1이 반드시 2가 되는 건 아닙니다. 통합 과정에서 예상치 못한 복잡성이 폭발하기 때문입니다.
프로젝트는 2~3주 단위 라운드로 운영하는 것이 효과적입니다.
각 라운드에서 개발뿐 아니라 테스트까지 완료해야 합니다.
라운드 초반 2~3일 내에 테스트 케이스를 작성하고, 개발이 끝나면 이를 모두 통과해야 완료로 인정합니다.
"개발 완료"가 아니라 "테스트 통과"가 진짜 완료입니다.
작업 구조(WBS)를 설계할 때는 계층적으로 접근하세요.
에픽(Epic): 큰 목표(이니셔티브). 보통 3~5개면 충분합니다.
업무/스토리(Task/Story): 1~2주 단위 작업. 가장 적정한 크기는 1주입니다.
하위 업무(Subtask): 실무 담당자가 직접 수행하는 세부 단위.
이 계층 구조를 활용하면 WBS 작성이 훨씬 명확해지고, 각 담당자의 책임 범위도 깔끔해집니다.
개발 후 3~5일은 버그 수정 및 테스트 케이스 통과에 집중합니다.
테스트 케이스가 아직 없다면 개발은 “반쯤 끝난 상태”라고 봐야 합니다.
품질은 나중에 몰아서 확보하는 것이 아니라 매 라운드마다 확보해야 합니다.
프로젝트는 작게 쪼개되, 완결성을 보장해야 한다.
“개발 완료”가 아니라 "테스트 통과 후 완료"라는 기준을 세운다.
3개월·3주·3일 원칙
- 3개월 넘지 않게 과제를 관리한다.
- 2~3주 단위 라운드로 일정을 짠다.
- 3~5일은 테스트와 FIX에 집중한다.
이 원칙을 따르면 프로젝트가 훨씬 예측 가능하고 안정적으로 진행됩니다.