일정만 기억하는 더러운 세상

프로젝트를 처음 시작할때 PM한테 일정을 물어 봅니다.

ME : "이번 프로젝트 일정이 어떻게 됩니까?"
PM : "분석/설계 2개월,개발 3개월"
ME : "일정에 대한 근거는 모죠?"
"전 이세상에서 그게 제일 궁금해서요"
PM : "대충 프로젝트 scope이 그정도돼"
ME : "대충? 글면 프로젝트 scope 과 일정의 척도는 뭐죠?"
PM : "그래서 경험이 중요한거야"
ME : "네에? "
"일정을 소화할 설계자/개발자와 협의 해야 하는것 아닌가요?"
PM : (슬슬 짜증내면서) 왜그래 프로젝트 처음하는 사람 처럼
ME : ............
"설계가 밀리면 일정도 밀리나요?"
PM : "안돼 무조건 끝내야해."

여러분들도 "프로젝트 일정 산정 법칙"
궁금하시지 않습니까?
만약 프로젝트가 일정내에 완료가 되면 둘중 하나 입니다.
정말 운이 좋았거나 아니면 개발자들이 고생해서 일정을
맞추어 준 것입니다. 오히려 고마워 해야죠.

• 일정을 사람에 맞추자
  

여기서 하나 게임을 해보겠습니다.
"회원정보를 가져오는 로직이 있는 소스가 있습니다. 1분안에 위의 로직이 필요한 30개 함수에 반드시 적용해야 합니다".
준비 시작~~~~~~~~~~
저 일정을 소화 하려면 100%로 Copy&Paste 할 것입니다.
"제임스 고슬링" 아저씨가 오던 "로드존스"형이 와도
아마도 CTRL+C,CTRL+V를 누르면서 소스에
화려하게 수를 놓고 계실 것입니다.
공통 함수 만들 생각조차 못할 것입니다.
다소 극단적인 표현을 이기는 하지만
일정을 사람에 맞추지 않고 사람이 일정을 맞추면
그 고객에게 전달될 제품의 퀄리티는 굳이 얘기 하지
않아도 아실듯 합니다.

• 몸에 맞지 않은 옷
  

최근에 스프링이 대세도 아닌 필수가 되어서 열공하시는
분들이 엄청 많아 졌습니다.
그런데 왜 우리는 Spring을 써야만 할까요?
경력에 도움이 되어서,아니면 쓰라고 하니깐..
가끔 EJB 시절 묻지마 개발을 떠올리면
Spring도 그전철을 밡을수도 있다는 생각을
하면 씁쓸해 집니다.
Spring을 사용하는 이유는 많겠지만
그중에서 제일 중요한 부분은
테스트주도 개발 입니다.
즉 제품의 퀄리티는 높이고
고객의 요구 사항에 빠르게 응대를 함으로서
유지 보수를 극대화 하는 것입니다.
이러한 철학과 사상은 애자일적인 생각이죠,
(로드존슨 형은 애자일 신봉자..)
하지만 실무에서는 이러한 순수성은
없어지고 오직 일정을 지켜기 위해서 라면
오히려 느슨한 연결과 오픈 소스들이 짐이 되는 것 같습니다.
그냥 날 JSP+도메인 대신 Map 으로 개발하는 것이
더 낫다고 생각합니다.
절대로 현재의 개발 인프라와 Only waterfall 방법론은
재앙으로 다가 올것입니다.

• 파일럿을 하자

제 개인적으로 비판만 있고 대안이 없는걸 싫어해서
말씀 드립니다.
우리나라 개발 환경 특성상 100% 애자일 도입은
사실상 힘듭니다. 하지만 부분적으로 적용할
필요는 있습니다. 특히 순환 방법 개발 입니다.
일단 프로젝트가 시작하면 scope을 줄여서
한 사이클을 2~ 3개월단위로 파일럿 플젝을 진행해야 한다고
생각 합니다. 그래야 어떤것이 부족하고 개발 공수에
대한 예측이 가능하니깐요.
불과 몇년전과 지금 환경은 너무나도 다릅니다.
업무도 복잡해지고 기술또한 오픈 소스의
홍수속에서 살고 있습니다.
그 만큼 변수가 몇년전에 비해서 너무 많다는 것입니다.
하지만 대부분 프로젝트가 완료일이 가까이 되어서야
한사이클이 됩니다. (그나마 한사이클 돌면 다행이죠..)
엄청난 요구 사항과 기술적인 설계의 결함등이 쓰나미처럼
밀려오죠. 옛날은 몸빵이라도 했지만 지금은
그냥 프로젝트가 정지가 되어버린 상태로 되죠.

• 품질로 승부하자

제발 프로젝트를 제안 할때 단가 또는 일정으로 후리지
않았으면 좋겠습니다.
고객들에게 다소 단가가 높거나 일정이 길수는 있어도
품질만은 확실하게 보장한다고 제안 해야 합니다.
이제는 품질로 승부해야 한다고 생각 합니다.
실제로 이런 부분을 몸소 체험한 몇몇 회사에서는
많이 개선하려고 노력하고 있습니다.

• 커뮤니케이션을 통해서 시간을 Save 하자

개인적으로 프리랜서 활동을 하고 있어서 가끔 프로젝트
중간에 투입이 될 경우가 있습니다.
그럴때 제가 제일 먼저 체크하는건 프로젝트 인력들과의
릴레이션 쉽입니다. 아무리 설계가 안되고 프레임웍이 꼬여도
프로젝트 팀원간의 유대관계가 좋으면 힘들거나 두렵지
않습니다. 제가 제일 두려운건 설계도 프레임웍도 아닌
프로젝트 인력간의 유대 관계입니다.
사실 유대 관계가 좋으면 상황이 나뻐지지도 않습니다.
개발자들 매우 감성적인 사람들 입니다.
지속적인 커뮤니케이션을 통해서 이해하고 유대감을 형성하면
야근,주말근무 알아서들 나와서 도와 줍니다.
왜냐면 일하는게 즐겁기 때문이죠.
지속적인 커뮤니케이션을 통해서 생산성을 높이고
최적의 방안을 논의 한다면 상당수 시간을 줄일수 있다고
생각 합니다.