일정 관리
개발자로서 회사에서 일을 하다보면 가장 많이 듣는 이야기중 하나가 “OO님 지라 티켓 보셨나요? 대충 어느정도 걸릴거 같으세요?”와 같은 일정 산정, 또는 일정 관리일 것이다.
어떤 경우에는 하루면 되요, 일주일이면 되요 등과 같이 답이 쉽게 나오기도 하고 어떤 것은 “글쎄요…“와 같이 답이 나오지 않기도 한다.
장애 처리 티켓이 아닌 이상 대부분은 후자가 많은거 같다. - 내 경험 한정해서 말이다. -
회사에서는 항상 일정 관리가 되어야하고 일정을 예측할 수 있어야 한다고 나도 생각한다. 다만 개발을 함에 있어 어떠한 경우에는 이 일정 산정이 꽤나 어렵거나 아주 불가능한 수준이라고도 생각한다.
왜 일정 산정이 어려운가?
소프트웨어 엔지니어가 내놓는 상품을 보면 최종적으로는 공산품이다. 일정한 규격과 대량 생산이 가능한 면에서 의미이다.
조금 더 자세히 들여다보면 실제로 소프트웨어 엔지니어가 만드는 건 공산품보단 이를 만들기 위한 금형 틀 또는 컨베이어 벨트이다.
일정 산정이 어려운 건 바로 이 부분때문이다. 이 금형 틀 또는 컨베이어 벨트를 만들때장인 기질의 작업들이 요구된다고 나는 생각한다.
매번 비슷한 틀을 만들거나 이미 있는 틀을 조금 고치는, 아니면 컨베이어 벨트의 길이를 늘리는 정도라면 문제가 되지 않을 수 있다.
문제가 되는 경우는 이 금형 틀 혹은 컨베이어 벨트를 아예 새로운 목적에 의해 새로운 형태로 만들어야 할때다.
어느정도 정형화된 틀이 있다면 모르겠는데 매번 맨땅에서 시작하고 매번 수행할 것이 달라진다.
보통 사람들은 소프트웨어 개발 일정이 꽤나 예측가능하다라고 보는데 위 이슈로 인해 거의 불가능해진다. 장인 기질이 다분히 필요하고 각 장인마다 어떻게 만들지 어느정도 기한이 필요핝 다 달라진다. 특히 초기 단계에는 이러한 특성이 매우 크게 발현된다.
물론 이 시기가 어느 정도 지나면 어느정도 토대가 만들어지고 관성이 붙어서 장인적 기질보다는 노동집약적인 기질이 필요해진다. 하지만 여기서 또 문제는 이 시기에 대한 판단도 각 장인마다 매우 기준이 다르다는 것이다.
그래서 결론은
기술의 급격한 발전으로 인해 정량적 기준을 마련하기 매우 어렵다. 기술 발전의 가속도가 줄어드는 그 시점이 되면 가능하지 않을까 싶다.
이때가 되면 일정 산정도 쉽고, 성과 측정도 쉬운 시대가 되지 않을까 싶다.
