일정관리의 희비

Case 1.
20MD의 작업이 진행된다. 오픈은 꼭 20일 후에 완료해야 하는 작업이다.
개인별로 하루중의 40%가 신규 개발에 투입된다고 판단되어 20MD를 0.4로 나눈다.
혼자 하면 50일이 걸린다는 예상.
3명이서 17일만에 완료하도록 개발자를 배정한다.

Case 2.
30MD의 작업이 진행된다. 오픈은 꼭 10일 후에 완료해야 하는 작업이다.
10일 후에 완료하기 위해 작업 분량을 조절한다. 20MD가 남았다.
10일 후에 완료한다고 보고 하기 위해 개발자에게 10MD만에 하라고 명령한다.(혹은 설득한다??)

---------------------------------------

Case1의 개발자는 행복하다.
일을 제시간에, 정확한 서비스로 완료하기 위해 열심히다.
하루의 60%는 시존 서비스 오류를 수정하거나 신규 서비스를 더 단단히 만들기 위한 고민과 예외 처리, 테스트 진행 등의 노력과, 동료와 업무상 아이디어 공유에 사용한다.
기획이 변경되는 것도 추가 노력이 가능하고, 변경 사항이 전체 프로그램에 좋을 것임을 의심치 않기에 기쁜 마음으로 받아 들여 진행한다.

아마도 개발은 일정안에 완료되고,
전체 업무를 통솔한 사람도, 업무를 요청한 사람도, 사용자도, 그리고 개발자까지 모두, 모두 행복하다.

Case2의 개발자는 불행하다. 시작부터 업무에 대한 불만과 회의로 불행해진다.
단단한 설계나 확장을 고려한 코딩은 꿈도 꿀 수 없고, 예외 처리나 테스트는 건성으로 처리된다.
아주 약간의 기획변경만으로도 직장 동료와의 관계는 불편해지고, 험한 말이 오고 간다.
오류 수정 요청에 신경은 말할 수 없을 정도로 날카롭게 곤두서고, 인간관계도 엉망이 된다.
계속되는 업무로 스트레스 지수는 최고조에 이르고, 밤 늦은 야근과 주말 출근을에도 지켜지지 않는 일정에 어느새 스스로 개발하는 프로그램이 실패할 거라 믿는다.

아마도 개발은 일정안에 완료되지 않고, 일정을 한참지나서야 내부는 엉망인 채 오픈된다.
전체 업무를 통솔한 사람도, 업무를 요청한 사람도, 사용자까지 모두 불행하다.
개발자는 자신이 만든 것이 부끄러워지고, 스스로가 하는 작업에 회의감을 갖는다.

아쉽지만, 현실이다.
자신이 하는 작업에 자부심을 느끼지 못하고, 스스로가 가장 먼저 실패하리라 믿게 되는 안타까운 현실이다.

왜 모를까? 이것이 정답이 아님을...
이렇게 하는 것이 오히려 마이너스임을...
모두의 불행의 시초가 모두를 행복하게 해줄 거라 믿는 그 "어미없는 일정 강요"임을.
왜 모를까?

ps.
당신은 여유로운 일정과 빡빡한 일정의 개발작업을 진행해본 경험이 있으신가요?
어느 경우에 작업하기 좋았고, 결과물이 좋았나요?
그리고 어느 경우에 일정을 맞출 수 있었나요?