본문 바로가기

정보관리기술/소프트웨어공학

프로젝트 제대로 망해보자 - 사람편


- 프로젝트를 성공시키는 방법은 참 이야기 하기 어렵다. 하지만 그 반대로 망하게 하는 방법은 너무나도 많고, 찾기도 쉽다.
이런 프로젝트를 말아먹는 방법중 사람을 맘대로 다뤄서 망하게 하는 방법들을 몇가지 알아보자.

1. 동기저하
- 프로젝트 성공의 지름길은 동기 유발이다. 그럼 프로젝을 말아 먹는 방법은? 동기를 저하 시키는 것이다. 당근..
- 이러한 동기를 저하 시키는 방법은 무엇이 있을까? 프로젝트 초반에 이루어지는 진부한 격려 "잘해봅시다. 여러분의 손에 달려 있다." 참나 뭘 사먹이면서 이딴 이야기를 하든지 말여, 그리고 프로젝트 중 가장 힘들때, 혼자 몰래 휴일은 다 챙겨 먹고, 막상 힘없는 개발자들은 죽으라고 밤을 새도록 한다. (이방법은 거의 쵝오의 방법이다.)
- 힘들때, 회식한번 안하고 회식비 딱 정해놓자. 절대로 그 이상은 못먹게.. (요런게 오래가면 폭동이 일어날수 있다. 그럼 프로젝트 말아먹는거지...)


2. 저급 인력
- 프로젝트의 성공요인중 또하나는 우수한 인력이다. 슈퍼맨 같은 체력에, 빠른 머리회전 이런 사람은 어디가서든지 프로젝트메인이 되고도 남는다. 그럼 이런 사람을 아예 뽑지 않으면, 그리고 생판 초짜만 갖다 투입하면 프로젝트를 멋지게 말아 잡술수 있다.
- 프로젝트를 나가서 리딩을 해보면, 참 다양한 사람들이 참여한다. 그저 받는 돈이나 받고, 배움의 지식이라든지 이딴것은 아예 집구석에 쳐박아 둔 사람, 그리고 각종 행사란 행사는 다 다니는 전문 비즈니스맨 같은 개발자(말은 정말 잘한다. 그런데 개발은 참 멋지게 해놓는다. 발로 짜도 이것보다 낳을 정도의 예술이랄까?), 그리고 생판 프로젝트라고는 처음 해보는 사람(이사람은 크게 문제가 없다. 사실 의욕만 있으면 이런 사람은 한둘 필요하다.)
최근 개발건이 있었는데 사실 개발 인원의 80%가 이런 사람들이었다. "나보고 어케 하라고" 교육 시키는데만 1달 이상 걸렸다.


3. 문제인물 방치
- 저급 인력에 보이는 사람들중, 문제인물들도 있다. 사실 가장 문제인물은 입으로 프로젝을 하는 사람이다. 영업도 아니고, PM도 아닌데 자기가 결정내리고, 자기가 행동지시를 한다. 또 어떤 문제 인물은 가끔 해적들을 물리치러 잠수함을 탄다. 출근 시간도 아주 멋지게 나온다. 이런 분들은 젊은 나이에 중년의 여유로움을 만끽하는 분들이다. 이런 문제인물들은 프로젝트를 진행해가는데 걸림돌이고 짐이다.
- 이런 사람들을 그대로 방치하자. 앞으로 진행해가는 프로젝트는 봤지만, 뒤로가면 어떻게 되는지 궁금할때가 있다. 이런사람이 뒤로 당겨주면 된다.


4. 영웅적 행동
- 요즘 사람이 참 없다. 그래서 조금 해본사람을 뽑으려고 비싼 돈을 들인다. 돈을 비싸게 주면 비싸게 줄수록 이런 영웅이 걸릴 확율이 크다. 영웅은 고집이 있다. (삼국지에서도 보면 영웅들은 각자 고집이 만만치 않다.) 이런 영웅들은 그야말로 자기가 없으면 안돌아 간다고 생각한다. 그래서 출근도 영웅답게 하고, 일도 영웅답게 물어보지도 않고 혼자서 척척척 잘해낸다. 그리고 나중에 고객이 "내가 원한건 이게 아닌데요?" 하면 "닥쳐 너까짓게~.. 난 영웅이야." 라는 자세로 응수한다.
- 이런 사람을 볼때면 차라리 이름이 영웅이었으면 한다. "김영웅", "이영웅" 말이지.. "영웅아~ 닥치고 일해라.~"
- 갑자기 이세상 모든 영웅이라는 이름을 가진사람에게 죄송해진다.


5. 프로젝트 후반에 인력 추가
- 프로젝트 후반에 일이 몰리고, 잘 안된다고 생각되면, 인력을 추가하자. 그럼 어떻게 되느냐? 그사람 하나에게 지금까지 프로젝트 히스토리에 대해서 설명하기 위해서 한명, 프로젝트 환경 설정을 위해 한명, 신규 추가 인원을 위한 술한잔에 하루를 보내게 된다. 아주 멋진 일이다. 거의 한사람 투입으로 2명 이상을 묶어둘수 있다. 능력의 여하를 막론하고 차후에 투입된 사람은 2사람 이상이 필요하다. 이쯤되면 "거의 지뢰다 지뢰.." 지뢰는 밟은 사람은 죽지 않는다. 대신 다리를 잃게 된다. 그러나 문제는 그 한사람도 버릴수 없기에, 2명의 군인이 그사람을 대리고 가야한다. 지뢰는 이러한 점을 노리는 아주 치졸한 무기이다.
- 프로젝트 후반에 사람을 넣느니 지뢰를 햄버거 패딩으로 넣어서 달라고 하는게 낳을수도..


6. 시끄럽고 붐비는 사무실
- 잡상인이 많은 곳은 집중을 하기 참 힘든 곳이다. 시끄러운 사무실, 거의 시장바닥을 연상케하는 사무실을 만들어 보자. 아마도 프로젝트 팀원은 조금있다가 스스로 하얀 옷을 입고 언덕위의 하얀집인 정신병원으로 가고싶을 수도 있을것이다.
- 조용하면서도, 잔잔한 음악을 틀수 있는 곳은 프로젝트를 집중하고, 팀워크를 이루기에 좋은 환경이다. 이런 환경을 만들면 프로젝트를 지루하지 않고 끝까지 마칠수 있는 환경이 된다. 프로젝트를 망치고 싶거나, 딜레이 시키고 싶다면, 시장을 선택해서 개발하자. 핫도그도 하나 먹고, 호떡도 먹으면서...


7. 개발자와 고객사이의 마찰
- 고객은 같은 값이면 더 좋은 품질을 빠른 시간내에 보고 싶어한다. 하지만 개발자는 그러한 것이 이루어 질 수 없다는것을 알기에 고객과 자주 다투게 된다.
- 관리자는 이러한 환경 분위기 변화를 잘 느껴야 한다. 그리고는 중재하도록 해야할것이다. 고객과 의사소통 단절은 개발 완료후에 고객으로 부터 "내가 원한건 이게 아냐~" 라는 말을 듣을수 있는 지름길이 된다.
- 구호탕란?(호랑이와 여우를 이간질 시키는 전술이 있다.) 이걸 쓰면 프로젝트를 망칠수 있다. 그런데 이거 반대의 고사성어는? 모르겠다.


8. 비현실적 기대
- 이전 설명에서 고객과의 마찰의 대부분은 이런 비현실적 기대이다. 한술 더뜨고 싶다면, Yes맨이 되면 된다. 고객이 뭔 이야기만 하면 Yes를 연발하라. 그럼 고객은 꿈과 낭만의 세계를 프로젝트에 그리게 될것이다.
- 현실을 현실이라 그대로 말할수 있는 용기는 프로젝트를 성공으로 가게하는 가장 중요한 용기일 것이다.


9. 효과적인 프로젝트 후원 부족
- 사실 프로젝트든, 싸움이든 딱가리들은 입만 거칠고 주먹만 휘드르지 별로 실속이 없다. 머든 대빵이 가리키는 곳을 향해서 가게 마련이다. 그렇다면 대빵이 당당히 고객과 대응해주고, 팀을 감싸주고 지원해준다면 지금껏 설명한 다양한 문제가 해결될 수 있다. 반대로 대빵이 고개를 숙이고, 예산이나 따지고 있다면(사실 손해보지 않는 경우가 더 많다. 그냥 전략적으로 예산 어쩌니 이딴 소리를 한다. - 내부적으로 쓰는 전략도 전략인지 모르겠지만) 12월 25일이면 방영되는 나홀로 집에 나 십계와 같은 영상을 기대할 수 있다.
- 사실 난 회사에 있는 부장쯤 되는 사람은 응원부대가 되어야 한다고 생각한다. 자기가 데리고 있는 팀원들을 위해서 기꺼이 술을 따라줄수 있는 부장, 차장은 팀원들에게는 천군 만마와 같은 존재가 된다. 하지만 1번 사람을 B프로젝트에 넣어야지 라고 생각하면서 팀원을 체스 말 정도로 생각하는 사람은 그냥 쓰레기다. 밥만 먹는..
- 체스 정도의 게임은 어린 아이도 한다. 그많큼 회사밥 먹었으면 몸쫌 움직이자, 프로젝트 나가서 북도치고 장구도 치고 말이다, 배에 붙어있는 살쩜 빼고 말이지..

10. 관련자 참여 부족
- 프로젝트를 하다보면 꼭 중요한 이야기할때에는 없다가, 나중에 와서 뒤집는 인간들이 있다. 사실 그들은 인간이 아닌듯 하다. 재미삼아 그러는지 모르겠지만 꼭 결정하라고 할때는 안하다가, 다 만들고 나면 그때서야 결정한다. 그것도 꼭 삐딱하게 말이지..
- 자신의 요구사항을 정확하게 어필하란 말야.. 이것들아.~.. 멀 원하는지.
- 플젝을 망치고 싶은 관리자가 있다면, 잦은 외출을 하라. 그럼 아무것도 결정된것 없이 이상한 산출물이 당신을 반겨줄 것이다.


11. 사용자 참여부족
- 지금까지 프로젝트를 해보면 실제적으로 사용하는 사람이 와서 회의를 하는 것은 보지 못했다. 그들은 그냥 교육되어진다. 만든대로 움직이느냐? 그럼 그것도 아니다. 그들은 다 만들고 나면 그제서야 실전 환경에서 멋지게 테스트를 하고 있다. 얼굴이 붉어지고, 입에서 쌍씨옷을 연발하면서...
이게 그들만의 문제는 아니다. 실제 사용자는 배제된 기획자들의 아름다운 상상으로 프로젝트는 종종 많이 진행된다.


12. 실속보다 정치
- 정치는 참 중요하다. 그런데 꼭 필요없는 정치를 하고, 실속은 다 빼끼는 멋진 관리나으리들이 있다. 한마디로 프로젝트는 잘 모르는체 입만 살아서, 그리고 어디서 주섬주섬 주워서 고객과 이야기를 한다. 와 ~ 그들의 응용력이란 감탄할만하다. 모르면서 유창하다. 그런데 가만히 듣고 보면, 이거는 뭐 우리보고 죽으라는 말만 해댄다. 정작 중요한것을 집으란 말이야~..
- 입으로 정치하는 관리들을 보면 미술작품 하나가 생각난다. "이삭줍는 여인들..." 어디서 이것저것 잘 주워 담는 모습이 그런거 같다.


13. 막연한 기대
- "일정이 얼마나 걸릴꺼 같아요?" , "한 6개월이면 안되것습니꺼?" 옆 프로젝트 팀도 6개월 하니까. 우리팀도 6개월쯤 될꺼야. 우리팀은 경력이 많은 개발자들이 있어서 더 빨리 할수도 있을 꺼에요.. 모든게 정확한것은 없다. 그냥 추정치도 아니다. 한마디로 갠또다 갠또. 프로젝트를 갠또로 한다 요즘도 그렇고 과거도 그렇고 말이다.
- 프로젝트는 초기에 완벽한 기간이나 비용을 산정할 수 없다. 하지만 가면서 그 목표가 가시화 되어야 한다. 그러니 막연한 기대로 갠또 날리지 말자. 대신 정확하게 말해주자. "우리의 경험을 토대로 산정해보면 통상 6개월이란 기간이 걸립니다. 프로젝트의 요구사항과 환경에 따라 더 걸릴수도 있고, 더 빨리 끝날수도 있으니, 프로젝트 마일스톤 기점 A, B, C지점에서 진행상황이 점차 구체화될 것입니다."라고..
- 갠또 하면 생각나는 친구가 있다. 그 친구는 수리에 강하지만 인문과목은 약했다. 그래서 한문 과목에서 전 문제를 갠또 5로 때렸다. 그후로 그 친구는 교무실에 불려가서 돌아오지 못했다는 전설이 있다.
- 갠또는 이렇게 위험하다. "모 아니면 도도 아니다. 어떻게 될지 전혀 모르는 암흑과 같은 것이다."


결론
프로젝트를 망하게 하는 위험 요소들을 13가지 정도 나열해 봤다.
이 13가지 항목은 Rapid Development라는 책에서 발췌한 것이지만, 내용은 내가 작성한 것이다.
프로젝트를 하면서, 유난히도 이런 문제는 늘 겪으면서 이것들 때문에 고생하지만, 프로젝트 할때마다 저지르는 실수다.

프로젝트 중간에 인력을 추가투입하는데, 아무말 못하고 그냥 받아들여서 4 ~ 5일을 까먹었던 날들, 그리고 팀원들의 사기가 바닥을 치고 있는데도, 지갑한번 안열던 PM, 말은 잘하는데 프로젝트 상황에 대해서는 하나도 모르는 PM, 그리고 쌓아놓으면 무너뜨리는 모래성 놀이 하는듯한 고객의 변덕.., Yes 맨의 상냥한 우리 기획팀 총괄 등등...

참 많은 위험들이 어김없이 프로젝트 마다 찾아온다.
프로젝트를 망치고 싶은 사람은 아마 이세상에 없을것이다. 있다면 내가 가까운 병원 소개해주고 싶다.

프로젝트에서 가장 중요한것은 팀원의 역량이다.
PM은 PM의 역량이 필요하고, 개발자는 개발자의 역량을 갖춰야 한다. 그러기 위해서 지금까지 나열한 것들을 다시한번 경험에 비추어 보는 자세가 필요하지 않을까 한다.