실패한 프로젝트 성공프로젝트로 바꾸기

실패한 프로젝트를 성공으로 만들기는 매우 어렵습니다. 이미 실패하지 않으려고 별 시도를 다 해봤거나 개발자들이 지쳐서 더이상 일하기 힘들기 때문이죠, 게다가 이미 실패로 이끈 관리자가 성공적으로 전환시킬수 있다고 예상하기는 힘들죠.

어찌됐건...

실패한 프로젝트를 성공적으로 이끄는 방법이 무엇인지는 알아보도록 하죠.  

계획수립.

1. 상황진단
기한이 정말로 중요한가? 기한에 맞추려면 무엇을 해야 하는가?
대게는 기한은 정작 중요치 않은 수가 많죠. 최고 경영자에게 약속한 날짜이기 때문에 기한을 맞춰야 한다든가.
그러나.. 사용자들은 기한이 늦은 것은 기억하지 않죠. 제품에 질이 좋은가 나쁜가를 더 잘 기억할 뿐입니다.

 

2.  W 이론을 적용한다.
개발자, 관리자, 경영자, 영업부 모두가 좋은 것이 무엇인지 그것을 찾아야 합니다.


3. 프로젝트 실패를 팀, 관리층에 알린다.
팀과 관리층이 실패라는 사실을 받아들이지 못하면… 실패!  더 이상 진행할 수 없습니다.
다른 회사를 알아보세요. 또는 다른 프로젝트를 알아보세요.
엄청~ 중요한 사실인데... 프로젝트를 실패했다는 가정하에 프로젝트를 복원할 수 있습니다. 실패를 인정안한다면... 복구 시도 자체를 받아들이지 않죠.
폐암 말기라는 것을 인정하지 못하는 환자에게 어떻게 암치료를 권장할 수 있을까요?
이미 엉망인 식사습관과 생활습관이 암을 만든것입니다. 식사습관과 생활 습관을 고치라는 의사의 말을 듣고 약물치료를 받아야 하는 것입니다.


4. 팀원들에게 해야 할 일을 물어라
팀원 모두에게 프로젝트를 살릴 수 있는 방법 5가지씩 요청후에 검토한다.
개발자가 정답을 알고 있을 확률이 매우 높습니다. 개발자 의견을 따릅시다.


5. 현실적인 시각을 가져라.
프로젝트를 실패했다. 복구가 얼마나 걸릴지 알 수 없다.
정상궤도로 돌릴 수 있는 계획을 세운다. 기한을 맞출 수 있다는 확실한 근거 없이 새로운 날짜를 약속하지 않는다.
매우 확실하고도 정확한 일정을 세워야 합니다. 그리고 그 일정을 하나씩 지켜나갈때 개발자사기도 올라가고 관리층에서도 새로운 일정에 대한 신뢰를 보입니다.
어설프게 세워서 또 지연을 한다면... 그건 이전 상황과 다르지 않습니다.

 

사람

1. 이미 땅에 떨어진 사기를 높여야 한다.
좋은 방법 ? 회사의 규정을 깨는 예외 조치(자유복장/ 출퇴근시간조정/식사 조달/휴가)
말로만 새롭게 시작하자고 하고 똑같은 조건을 내 세운다면 어느 누가 믿고 따를까요?  다른사람에게서 친절을 원한다면 내가 먼저 인사를 해야 하는 것입니다.  


2. 인사문제 정리
문제 팀원 처리 _ 비협조적 팀원 처리
문제있는 사람 처리가 가장 큰 문제...


3. 지휘층 문제 정리
이미 프로젝트 관리 실패를 한 관리자라면 성공으로 이끌 가망성도 거의 없다.
가능하다면 프로젝트 지휘층 변경을 고려한다. 책임자 교체도 고려한다.
- 관리자의 상사를 바꾼다 : 관리자도 통솔이 필요하다
- 관리자에게 참여 임무를 맡긴다
- 관리자에게 비서를 할당한다. 관리자는 상부 관리층과 의사소통만 맡는다.
관리자가 엉뚱한 곳에 노력을 빼앗기고 있지는 않은지요?  


4. 필요한 경우 주의깊게 인력을 더 투입한다.


5. 개발자 시간에 집중하라
새인력 투입 비용을 기존 개발자에게 투자한다면 더 큰 이득을 볼 수도 있다.
추가 인력을 고용한다면 비 개발자를 고용한다.->개발 이외의 잡무를 도와줄 사람


6. 다양성을 허용하라.
영웅적으로 해결 하겠다고 나서는 사람이 있어도 좋다. 다만 프로젝트 복구 단계에서는 사기가 떨어져 있기 때문에 영웅적으로 너무 나선다고 비꼬는 사람은 내버려두면 안된다.
다들 열심히 하자고 덤비는데.. 그게 되겠어?  라고 비꼬는 사람이 있다면. 바로 ...


7. 개발자 스스로 페이스를 조절하게 하라
일정 압력을 자제하라. 압력이 커지면 스트레스도 커지고 결함도 증가한다.
과연 이 조언을 따를 회사는 있을까요?  이미 실패한 프로젝트에서는 개발자 무시가 지속적으로 있었기 때문에 일정압박은 더 심해질 텐데... ㅋㅋ
이것도 역시 프로젝트가 실패했다는 것을 받아들이면 가능한 얘기지만 실패를 인정 못하면 당연히 개발자 압력이 커지기만 하죠.
채찍을 휘두르면 이렇게 얘기하죠..  일해! 일하지 않으면 월급도 없다!! 


공정

1. 전형적인 실수를 찾아 고쳐라.
- 제품정의가 여전히 변하는가? (단 한줄이지만.. 매우 심각한 사항이죠 )
- 불충분한설계로 인해 어려움이 있는가?
- 관리 감독이 충분하지 못해서 프로젝트 진행 상황을 파악하지 못하는가?
- 기한을 맞추기 위해 품질을 희생했는가?
- 기한이 현실적인가? ( 이미 두번 이상 일정을 지연했다면 현실적이라고 할 수 없다)
- 사람들이 너무 힘들게 일해서 프로젝트 후에 또는 그 이전에 그만둘 위험이 있는가? (벌써 그만둔 사람이 있다면, 너무 힘들게 일하고 있다는 뜻이다)
- 검증 받지 않은 새 기술을 사용해서 시간을 잃었는가?
- 문제 개발자가 다른 팀원 의욕을 떨어뜨리는가?
- 프로젝트를 끝낼 수 있을 만큼 사기가 높은가?
- 책임 공백이 있는가? 고의는 아니더라도 업무 결과가 미덥지 못한 사람이나 그룹이 있는가?


2. 확실히 문제가 있는 부분부터 고쳐라.
프로젝트가 잘못 된 이유를 대게 알고 있다.
다만 관리자(PM, PL) 만 모르는 경우가 많다. 이런 관리자는 얘기를 해줘도 귀담아 듣지 않는게 전형적인 모습이지만.. 사람관련 문제 참고하세요. 


3.  상세 중간 목표를 만든다.
프로젝트 복구 단계에서는 업무 파악이 상세하게 되었기 때문에 상세 중간 목표설정이 가능해진다.


4. 중간 목표 완료에 맞춰 일정을 세워라.
계획에 초과근무를 가정하지 않는다.
개발자들이 중간 목표를 달성하지 못하면 초과근무를 시켜서 맞추게 한다.


5. 일정에 따른 꼼꼼한 진행상황 체크
완료 또는 실패 둘중에 하나만이 허용된다.  90%는 완료가 아니다.
90% 완료 됬구요.. 10% 남았습니다..는 절대 허용안된다. 중간 상세 마일 스톤에서는 YES, NO 둘중에 하나만이 존재한다.


6. 중간목표를 놓친 이유를 기록하라.
기록해두면 나중에 문제 해결의 원인 파악에 도움이된다.


7. 개발자가 반나절 이상 중간 목표를 뒤쳐질 경우에는 일정을 재 조정하라
이제까지의 지연을 감안하여 다시 일정을 계산한다.
4일 분량이 7일 걸리면.. 남은 일수에 7/4 를 곱한다. 절대로 나중에 따라 잡을 계산을 하지 마라
나중에 따라잡을 계획이라구요?  그러니까. 여태 실패하고 있는겁니다.


8. 확신되는 일정이 아니면 약속하지 마라
상부 관리층에게 성급하게 보고하지 마라.
일정을 1-2주 구체화하고 1-2주 검토후에 넘긴다.


9. 위험관리 지침을 따른다.

제품

1. 요구사항을 고정하라 (대부분 클라이언트가 이부분을 인정 안하려고 하죠)
요구사항이 계속 변하면 개발자체가 불가능해진다.
요구사항 확정후에는 변경검토에 하루 이상의 시간을 들여라.
요구사항을 받아들이는 기준을 높게 책정한다.


2. 기능집합을 쳐낸다.
우선순위에서 순위가 높은 것을 우선 구현한다. 낮은 것은 과감히….
대부분의 클라이언트는 너무 많은 것을 요구한다. 필요없는 기능을 요구한다.
다시 한번 생각해보세요. 그게 정말 필요한겁니까? 정말?
자동차를 만드는데... ABS 는 옵션입니다.자동차 만드는데도 1년이 걸리는데  ABS까지 함께 완성하려면 2년이 걸립니다. 그런대로 1년짜리 프로젝트에 ABS 를 꼭 넣어야 합니까?
프로젝트는 더 이상 넣을 것이 없을때까지가 아니라.. 더이상 뺄것이 없을 때가 가장 이상적인 결과가 나온다는 것을 명심하세요.


3. 정치적인 상황을 진단하라
프로젝트의 개발 자체가 아닌 정치적인 면이 존재하는가?
이런 부분도 알아서 처리하기를... 이딴게 존재하면... 짱나요. ㅡ,.ㅡ 


4. 제품의 쓰레기 모듈을 버려라
설계를 검토하여 오류 모듈을 버려라.

5. 결함수를 줄여라
흔히 일정 문제에 부딪히면 일정에만 집중하고 품질은 적당히 넘어가기 쉽다.
이런 상황은 후반에 오히려 심각한 일정 지연을 일으킨다.


시기

프로젝트 복구 계획을 시작한 시점이 반드시 프로젝트에 문제가 있다는 판단을 한 순간이라고 할 수는 없다. 관리층과 개발팀이 이 계획을 받아 들일 준비가 되어 있어야 하며, 프로젝트 복구에 필요한 조치를 취할 자세가 되어 있어야 한다.

복구 계획을 너무 일찍 시작하면 정말로 복구가 필요한지 의심을 받는다.다른 사람들이 늑대를 보기도 전에 “늑대다.!” 라고 외쳐봤자 소용이 없다.  하지만 복구 계획을 너무 늦게 시작하면 여러 차례에 걸친 작은 변경과 사소한 복구 시도록 끝나기 쉽다. 이번에는 대규모 복구를 효과적으로 이끄는 능력을 의심받는다. 너무 많이 “늑대다!” 라고 외치는 꼴이 된다

 

암환자가 암이라고 인정을 해야 암치료가 가능해진다.

당신은 죽어요 라고 아무리 얘기해봐야... 소용없습니다.

 

    인용 및 변경을 했지만..   - 출처 : 쾌속개발