어떤 일을 시작하든지 간에 맨 처음 해야 하는 일은 ‘계획’을 세우는 일이다. 혼자하는 일이라면 상관 없겠지만, 회사에서 하는 일이라면 계획 수립은 필수다. 보통 계획이라고 하면 크게 두 가지 내용을 담고 있다. 하나는 해야 할 일들의 목록이고 나머지 하나는 일정이다. 간단히 말해 계획이란 어떤 일들을 언제까지 완료해야 한다는 것이다. 이 중에 특히 더 어렵게 느껴지는 부분은 일정 수립이다. 왜냐하면 일정 수립은 순전히 ‘가설’이기 때문이다.
의도적 수련 항목에 작업 계획 세우기를 추가한다. 파트 리더 할 때부터 유난히 WBS 만들고 일정 수립하는데 어려움을 겪었다. 돌이켜보면 일정한 기준 없이 순전히 감으로 (저 담당자가 하면 몇일 정도 걸릴 것 같다) 일정을 잡았던 것 같다. 작은 작업이라 할 지라고 의도적으로 작업 시간을 추정하고 시작해보기로 한다. 여기서 중요한 것은 작업 시간 추정의 단위를 만들어 내는 것이다. (산정 근거)
예를 들어, 데이터 적재 업무라면 대략 1일치 데이터를 적재하는데 얼마가 걸리므로, 1달치 데이터 적재 소요시간 = 1일치 소요시간 * 30 과 같이 작업 시간을 추정해볼 수 있다. 이 때 추정 단위는 1일치 데이터의 적재 소요시간이다. 이러한 추정의 단위가 발견되지 않는 업무라면 과거 경험을 토대로 유사 업무의 작업 시간을 토대로 추정해야 한다.
이 의도적 수련의 1차적 목표는 비교적 정확한 일정을 수립하기 위함이고, 궁극적인 목표는 스스로의 퍼포먼스를 알아내기 위함이다.
updated 2014.11.26
김창준 님의 ‘개발 기간 추정이 엉망이 되게 하는 비결‘을 읽어보니 일정 추정에 어려움을 겪었던 이유를 조금은 알게된 것 같아 인용한다. 나는 기간에 대한 압박 (요구사항이거나 스스로 가하는 것이거나)에 가장 크게 영향을 받는 것 같다.
소프트웨어공학에서는 수십년의 연구를 통해 이 개발자 추정의 정확도에 영향을 미치는 요소들을 찾아내었습니다. 이 주제 하나만으로 AC2의 하루 워크숍 꺼리이긴 한데, 그 중 추정이 엉망이 되게 하는 비결 몇가지를 소개해 볼까 합니다.
- 요구사항 문서의 폰트 크기를 줄여라.
- 기간이 별로 없다고 알려줘라 (심지어는 간접적으로 넌지시 해도 효과가 있다)
- 기준치를 제공하라 (언제 안에 해야한다거나)
- 새로운 기능이라고 하지 말고 사소한 확장이라고 말해줘라
- 리스크 분석을 하라
- 외부 평가자를 두지 말라
연구를 통해 위 방법을 사용하면 개발자 추정이 지나치게 낙관적으로 나오며(개발자 추정은 대부분의 경우 낙관적이라고 분석됨) 따라서 정확도가 떨어진다는 발견이 나왔습니다.