절차로서의 절차 문서로서의 문서

프로젝트 마무리가 한참이다. 이미 시스템은 오픈했고 사용자들의 요구사항이 쏟아 지는 첫주 하지만 수정사항은 반영 되지 않고 있다. 사무실에 불은 꺼지지 않고 개발자들은 앉아서 열라게 자판과 씨름하고 있는데 어째서 요구사항이 반영되고 있지 않는 걸까

그들은 이제 이클립스나 닷넷 혹은 메모장에서 벗어나서 Ms Word나 엑셀로 만들어진 문서들을 체우고 있기 때문이다.(프로그래머들이 MS를 그리 싫어 하는것은 산출물들이 모두 MS 오피스로 되어 있기 때문이 아닐까?)

분석, 설계, 개발, 구현, 안정화 폴더는 차곡 차곡 만들어 지고 템플릿이 뿌려 진다. 그리고 개발자들은 열나게 그 템플릿을 체운다.

대형 SI조직의 PM은 우리 조직이 CMMI 몇단곈줄 아냐며 이거 정말 적은양이고 싹다 가져 오면 여기 개발자들 다 죽는다며 으시댄다. 어쨌거나 그가 내맨 32종 셋트는 일주일안에 체우기는 쉽지 않은 양이다.

방법론과 문서 다 좋다. 그곳이 어디서든 프로젝트의 품질과 생산성을 높인다는 것이 증명된 도구들일것이라고 믿는다.

그런데 어째서 각 단계별로 절차를 지키지도 않으면서 마지막에 이렇게 문서는 만들어야 하는 것일까

PM은 문서까지 만들면 제 시간에 오픈은 택도 없는 소리라고 말한다. 그 말마디가 그 프로젝트의 품질과 생산성을 알려 준다.

절차를 지킬 시간도 없는 개발자들에게 고품질의 결과물을 요구하는 것은 밀가루 없이 빵을 만들라는 것과 무엇이 다를까

그렇게 속도에 목을 맨다면 이미 문서 없이도 다 만들고 오픈한 시스템 뭐하러 이렇게 수많은 문서를 만들고 프린트해서 바인딩 한단 말인가

개발자들의 야근을 갉아 먹으며 자란 그 문서들은 어둠컴컴한 캐비넷에서 보존연한을 체우고는 폐기 처분 되기 전까지 단 한번의 햇빛도 보지 못할텐데.

어차리 고객들이 원하는건 불만이 있을때(그때가 한방중이거나 휴일이라도 상관없이)재깍 전화를 걸수 있는 휴대전화번호가 포함된 명함만 필요할 뿐이면서..