요새 개인적으로 많이 듣는 말인데요.

'그런 건 금융쪽에서나 하는 거구, 여긴 그렇게 할 수 없어요'
'너무 이상적인 이야기, 꿈의 시나리오 입니다'
'다음에 하도록 하지요'
‘언젠가 그렇게 해야지요’

2006년에는 무엇인가 제대로(?) 해보고자 직장을 5군대 옮기고 옮긴 회사에서 3개월쯤 되었다.그래서 2007년이 되었는데...

프로젝트 상황은 이렇습니다.(중복되는 이야기도 있겠으나)
- 초 간단 일정관리 sheet 하나 없고, 문서가 있다면 갑(?)회사에 보고하는 문서 뿐이다.
- 여기서 너무 당연하지만, 기초적인 분석, 설계 문서는 찾거나 요구하면 위와 같은 말을 들어야 한다.
- 통합된 ERD 하나 없으며 컬럼의 추가나 관리는 개발자가 db에 직접 alter를 해야 한다.(이 상황을 당연한 것으로 여긴다)
- CVS는 동기화가 안되어 상용 오픈 하루 전에 문제가 발생하고, 테스트 서버 빌드는 성공하지만, 누구 하나 테스트 하지 않는다(?) 못한다(?) 되지 않는다(?)
- 소스코드에 코멘트 달린 코드를 찾기가 어렵다.(?)
- 개발자들 옆에 있는 개발자가 무슨 일을 하고 있는 대개 알지 못한다.
- 실제 개발자들이 개발 할 수 있는지, 문제가 무엇인지 관리자들과는 머나먼 이야기 이다.
- 사람이 부족하다고 개발팀에서는 말을 하지만 상위라인의 생각은 사람이 남아 돈다고 이야기한다. 일이 정리되는 과정이 없는 지금 상황이면 사람이 부족 한게 맞음.
(그 누구도 제대로 된 답을 알 수 없다. 체계적인 관리 기술을 사용해서 해보지 않았으므로)
- 위에서는 그 사람이야 어쨌든 담당자만 정해지면 일이 진행 된다고 생각하는 모양이다.(여러 라인에서 일이 온다)
- 어느 사람은, 어느 팀은 여유가 있는데, 다른 한쪽은 날을 새고, 매일 야근을 해야 한다.
- 어느 사람은 평일회사 휴일에도 몰라서 출근을 한다.(창립 기념일)

몇 개월 프로젝트에서 느낀 점은, 기본 process를 만들고 일을 진행하면 재미있게 일할 수 있는 것으로 생각됩니다.
다만 지식의 문제이고 의지의 문제일 뿐입니다. '조직의 성숙도' 문제 일 것입니다.

일을 순환구조로 풀어 가야 할 것으로 생각 됩니다.
- 적절하게 조직을 배치한다.
(지금도 되어 있으나, 일이 그렇게 움직이지도 않습니다. )
- 각 사람에게 역할을 배분한다. 그리고 그 역할에 따른 적절한 지침을 마련해 일하도록 하고, 관리 한다. (PM, 아키텍쳐, 요구사항분석가, PL, 개발자) 현재 인원수 25명의 프로젝트에 이 정도는 적당하다고 생각이 됩니다.
- 외부의 적절한 QA팀에게 주기적으로 프로젝트 감리를 받고, 그 결과를 프로젝트에 적극 참여한다.