watist's blog ... I am interested and passionate in building software.

Case 1. 20MD의 작업이 진행된다. 오픈은 꼭 20일 후에 완료해야 하는 작업이다. 개인별로 하루중의 40%가 신규 개발에 투입된다고 판단되어 20MD를 0.4로 나눈다. 혼자 하면 50일이 걸린다는 예상. 3명이서 17일만에 완료하도록 개발자를 배정한다. Case 2. 30MD의 작업이 진행된다. 오픈은 꼭 10일 후에 완료해야 하는 작업이다. 10일 후에 완료하기 위해 작업 분량을 조절한다. 20MD가 남았다. 10일 후에 완료한다고 보고 하기 위해 개발자에게 10MD만에 하라고 명령한다.(혹은 설득한다??) --------------------------------------- Case1의 개발자는 행복하다. 일을 제시간에, 정확한 서비스로 완료하기 위해 열심히다. 하루의 60%는 시존 서비..

최근에 피플웨어류의 서적들의 영향을 받아 공격적인 일정은 프로젝트를 실패하게 한다고 믿게 되었다. 최근의 경험에 비추어 봐서도 공격적인 일정의 프로젝트(?)들은 정도의 차이는 있지만, 모두 개인적으로 판단한 일정보다 지연됐다. 그럼 이렇게 파국이 예고된 프로젝트에 임하는 개발자의 자세는 어떡해야 하는가? 타입 1. 일정을 최대한 맞추기 위해 야근과 주말 근무에 열심이다. 타입 2. 욕 먹어도 억울하지 않을 만큼 농땡이 부린다. 당신은 타입 1, 혹은 타입 2. 난 물론 타입 2다. 비단 이것이 파국이 예고된 프로젝트이기 때문만은 아니다. 타입 1의 사람이 롱런할 수 없다고 생각하기 때문이다. 특별한 근거는 없지만, 365일을 100%의 능률로 근무할 수는 없다고 생각하기 때문이다. 오늘 쉬는 것이 오늘 ..