새로운 프로젝트 관리의 패러다임이 필요하다... IT로 먹고살기






 일단 ... 자아비판부터 하고 쓰겠다...나도 과거에 개발자였고, 팀장을 했고, 사장도 잠시 해봤었는데...
 정말, 진실로, 솔직하게, 레알 프로젝트 관리라는걸 열심히 생각해 본 적이 없다....
 그러다가 PM 일을 하면서...나름 공부도 하고 현업에서도 새로 배우고, 느낀 것들을 돌이켜 보면...
 정말 제대로 해 왔는지 의구심이 든다....일정관리, 목표달성, 고객만족이라는 나름 거창하지만, 말뿐인 
 구호만 외쳐온 것이 아닌가 싶다....

 내가 생각하는 PM은, 프로젝트의 관리를 ... 계획 혹은 착수보고가 시작이라고 보지 않는다..
 계획의 수립일, 착수보고, 킥오프(KickOff)...다 좋고 중요한데 이게 다 건축쪽에서 온 거다....
 건축에서의 프로젝트 관리, 건설 관리를 비하할 생각은 전혀 없지만
 일단 내가 주로 하는 소프트웨어 개발에 있어서의 프로젝트는 단순히 시작일, 보고일, 완료(예정)일 설정하는
 걸로 시작하진 않는다고 생각한다...아니 생각하기 시작했다...

 건축, 토목 쪽에서는 관리하는 것은 상대적으로 명료하다....가로 세로 각각 1m의 깊이 1m의 구덩이를 판다고 하면
 (이걸 프로젝트라고 하면) 삽질을 하면 몇번, 포크레인을 쓰면 몇번, 인부가 몇명이면 된다는 것이 경험적으로, 
 계산적으로 유추가 가능하다. 물론 보정될 계수가 있겠지만 기본적으로 '인부 2명과 포크레인 1대로 2시간 작업하면
 된다'는 방식으로 진행이 가능하다. 인부는 보편적으로 '삽질'을 1년 이상 해본 사람이라면 비슷한 수준의 일처리가 
 된다라는 식의 가정과 pre condition설정도 가능하므로 ... 상기 방식을 조금 확장해 보면,
 '1년 이상 삽질을 해온 인부 2명과 중간크기의 기계삽이 달린 포크레인을 1년 이상의 경험자가 운전하면 
  가로 세로 깊이 각각 1m의 정사각형 구덩이를 2시간에 팔 수 있다'는 정도의 상세한 조건설정이 가능해 진다.
 뭐 물론 삽질시 다른 사람과 다르게 옆으로 파는 사람이라거나 포크레인으로 이쑤시개만 집어요 하는 특이조건(!)도
 있겠지만 이런건 다 걸러낼 수 있다. 즉, 조건에 맞추면 누구나 할 수 있다는 것이다. 

 이런 기본조건, pre condition을 다양하게 정리, 조합한다면 당장 집 뒤 공터를 파내는 거나 대형 빌딩을 짓는거나 
 차곡차곡 산술적으로 계산이 가능하고, 이 기간들을 조합하고 동시에 진행하는 것도 고려하면 '전체일정'이 나오고
 인건비, 장비사용비용, 등의 '예산' 혹은 'budget'이 산출되고 진척도(Progress)를 도출해 낼 수 있다.

 이게 바로 우리가 알고, 우리가 행하고 있는 프로젝트 관리다...

 그런데 미래산업의 꽃이라(고 하는데 실제로 그런지는 여전히 모르겠다) 하는 소프트웨어 개발도 이런 방법론을 
 그대로 적용 가능한지...갈수록 모르겠다....

 시간이 곧 돈인 세상인지라, 밤을 새서라도 기획안 하루 만에 튀어 나오고, 디자인 시안 뚝딱 만들어서 컨펌 받고,
 시스템 아키텍트는 기존에 사용하던 DB, WAS를 그대로 쓰되 사용자 수에 맞춰서 서버를 한대 더 넣을지 말지만 결정하고
 애플리케이션 개발자는 서버에서 주는 API가 없으니 무작정 기다리다가 마지막 날 되면 한번에 코딩하고, 에러 무수히
 튀어 나오고, 프로그래밍할 일정은 줄어도 검토/검증할 기간은 무조건 1~3개월 해야 하고, 그러다 보니 검토/검증하는 동안
 개발하고 디버깅하고, 그러다 중간보고 들어가면 윗분이 '이거 맘에 안드네' 한 마디에 디자인부터 기능 싸악 재검토, 변경되는
 이런 상황은....과연 우리가 프로젝트 관리를 잘 못해서 발생하는 것일까?

 솔직하게....사장, 대표이사, 이런 보스급들은 소프트웨어 프로젝트 관리를 저쪽 동네의 래O안 아파트 단지 건설과 동일하게
 생각하고 있지 않은가? 아니, 그전에 10년 이상되는 회사(그것도 IT)에 왜 chief architect는 없고, chief PM은 없는 걸까?
 
 결국 우리는 소프트웨어라는 분야 자체를 잘 못 대하고 있는(음..대략 실리콘 밸리의 여느 IT 회사 혹은 그 환경에 비해?) 것이
 아닐까? 

 이런 불편한 진실(ㅋㅋ)을 기반으로 지금까지 생각하고 실천해 오고, 그러면서 마구 깨져왔던 프로젝트 관리를 새로
 정의해 보고자 한다. 뭐 개인적인 블로그이니깐 ... 지가 하고 싶은 말 적는다 생각하면서 ... 편하게 정리해서 
 연재식으로 정리해 봐야겠다...목표는 1주일에 글 한편 이상씩으로...

 아래 이미지는 정말 이런 제품이 있는지 모르겠으나 아이폰/아이패드용 독인 듯 하다...이쁘네..


덧글

  • 곰돌군 2011/08/24 15:57 #

    IT 관련 (특히나 소프트웨어) 쪽 프로젝트의 공통적인

    문제점은 의뢰를 하는 클라이언트나 컨펌을 받는 매니저나

    실제 개발을 담당하는 개발인력이나 구체적으로 자기들이

    뭘 만들어야 하는지 모르는 상태에서 일을 시작하는 경우가

    많은것이 문제가 아닐까.. 라는 생각을 잠깐 해봤습니다.
  • 지름신의 형제 2011/09/29 19:43 #

    어디로 갈지 모르고 일단 달리는 경우가 많은 것 같습니다.

    예전보다 코어 개발하는 사람들은 찾아보기 힘든 상황이고...
    잘 만들어 놓은 SDK, Framework, 오픈 소스 가져다 '겉만' 코딩하는 경우도 많네요...

    방문해 주셔서 감사합니다.
  • 하늘의별 2011/08/24 22:22 #

    건설 토목 쪽의 방법론 그대로라면 적어도 아파트 다 지어놨더니 부수고 다시 지어라 라는 상황은 안 나오지 않을까요..
  • 지름신의 형제 2011/09/29 19:42 #

    훗....건설 토목은 그래도 눈에 보이니까...다시 지어라 하기는 힘들 수도 있겠네요..
    소프트웨어는 안 보이니.....막연히 화면에 보이는 UI 만 보면...이거 이렇게 하면 좋겠네...
    한마디에 우르르 무너지는 건가 봅니다 ㅋ

  • 2011/10/12 11:35 # 비공개

    비공개 덧글입니다.
  • 좋은글보고 갑니다 2013/05/23 16:31 # 삭제

    프로젝트관리글 검색하다 여기글까지 읽게 되었습니다 ^^ 좋은글 잘보고 갑니다.
    아! 참고로 지름신의 형제님 보실지는 모르겠지만
    건설토목이 눈에 보이니깐 다시 지어라 하기는 힘들수도 있다고 말씀하시지만

    아니랍니다. 소프트웨어처럼 이거 저거 하다보면 결국 한마디에 우르르 무너지는거는 같습니다

    물론 설계에서도 흔한일이구요 시공쪽에서도 검수한마디에 무너집니다 다 똑같은 일이랍니다.
  • 2015/02/09 17:57 # 비공개

    비공개 덧글입니다.
※ 로그인 사용자만 덧글을 남길 수 있습니다.