프로젝트를 성공하기 위한 PM의 10계명

작성날짜 : 2011-05-11

출처 : GIS 프로그래밍 연구소 

1.산출물을 가벼이 여기지도, 무겁게여기지도 말자.

개발 산출물은 개발을 위한 증거품이자 지침서 이다. 내용은 충실하게하되 꼭 필요한 문서들만 만들자. 그리고 실용적으로 만들자 . 화려하고 많은 분량으로 승부 하는 산출물은 거의 개발에 도움이 안된다.

2. 방법론의 노예가 되지말자

여러가지 개발 방법론이 존재하고 대부분은 매우 훌륭한 방법들이다. 그러나 방법론의 본질은 실용적이고 좋은 소프트 웨어 개발을 위한 방법이다. 때론 방법론이 소프트웨어 개발보다 위에 서 있을 때가 있다. 닭이 먼저인가 달걀이 먼저인가를 먼저 파악하자

3. 좋은 팀웍을 구성하라.

팀웍은 개인기를 능가하는 힘이 있다. 팀웍의 핵심은 팀원들간의 친밀도가 아니라 신뢰이다. 신뢰로 쌓여진 평범한 재능의 집합은 위대한 재능으로 쌓여진 모래알 조직보다 강하다.

4. 긴장의 미학을 즐기지 마라.

 프로젝트 관리자들이 팀원들에게 압박과 긴장으로 일을 추진할 때 가 있다. 단기간 오픈을 앞두고 1~2주는 때로는 효과가 있지만 그것은 모르핀 효과 이다. 장기간 모르핀을 맞으면 결국 폐인이 된다. 프로젝트도 마찬가지이다. 장기간의 압박과 긴장은 결국 팀원의 이탈 및 품질저하로 연결된다.

5. 프로젝트 규모와 상황에 따라 역할을 조정해야 한다.

프로젝트 규모와 상황에 따라 역활이 재조정되어야 한다. 때로는 관리자가 실무인력보다 많은 프로젝트를 만나게 된다. 그 많은 관리인력들은 각자의 역활을 충실히 하기해서 개발자들에게 각자의 관리지침을 내리고 그것을 모니터링하게 된다. 그럴경우

개발자들이 관리지침대로 수행하고 보고하다 실제자기일을 못하게 될 경우가 많다. 반대로 프로젝트 규모가 크고 관리인력이 적거나 아예 없는 경우 결국 개발자가 관리업무를  떠맡아서 능률저하로 이어진다. 대형프로젝트의 경우에서는 특히 관리포인트와 지침이 많기 때문에 역활과 인력을 상황에 따라 재조정 해야한다.

6. 테스트도 개발단계의 중요한요소이다.

대부분의 개발계획에 있어 구현에 초점을 두는 경우가 많다. 고객도 테스트 보다는 구현일정에 더 관심을 두는 경우가 많다.

또한 개발일정도 테스트단계는 지나치게 짧게 두는 경향이 있다. 테스트 일정이 구현일정에 적어도 1/3 내지 1/2정도로 할애 할 때가 가장 이상적이다. 이기간을 확보하고 일정을 수립하는 것이야 말로 PM의 능력이라 할 수 있다.

7. 소프트웨어 개발은 예술이 아니다.

개발 시 공통 컴포넌트를 만들고 프레임워크를 도입하는이유는 개발 시 기능재개발의 낭비를 막으며 빠른 개발생산성 확보 와 유지보수에 용이함에 있다.

그러나 때로는 개발자들이 자신의 기술에 도취하거나 막연한 신기술의 동경으로 인해 검증되지않은 기술이나 컴포넌트를 도입하거나 팀원들에 개발 생산성을 떨어뜨리는 구조로 개발을 하게 되는 사례도 있다.소프트웨어 개발은 예술이 아니고 제조업이다.

8. 개발의 생산성의 정점을 체크하라

개발 시 어느 순간 팀원들의 개발속도가 급속도로 올라갈 때가 있다. 이것이 개발구조의 적응이든 컴포넌트의 도입이든 초기에

완만하다가 생산성이 폭발적으로 증가하시는 시기를 체크하라. 이 시기를 예측하고 계획을 수립하는 것이 좋다. 

9. 회의는 책임추궁의 장이 아니다.

회의시 책임 추궁과 책임회피의 장으로 연결되는 경우가 많다. 그럴경우 사기저하 및 아무도 책임지려하지않는 무책임의조직으로 돌변하게 될 우려가 크다. 차라리 책임추궁하려면 개인면담을 통해서 처리하는게 낫다.

회의는 30분내외로 일정과 문제점 해결에 집중하되 1시간이 넘어가는 경우에도 결론이 나지않는 문제점 이라면 대부분 그 팀    내부에서 해결할 수 없는 문제이므로 외부의도움이나 PM 스스로의 결단이 필요하다.

10. 현업파트너와 소통하되 100%신뢰하지말라. 그리고 자신의 경험을 100% 신뢰하지말라

현업의 요구를 개발에 반영하고, 업무패턴을 분석하기 위해서는 현업파트너와의 의사소통을 원활히 해야한다. 그러나 

현업파트너들의 정보와 업무 분석을 100% 신뢰하지마라. 현업파트너들도 결국 부서가 있으며 부서의 이익과 부서내의 업무중심으로 현장을 묘사 할 때가 있다.

여기에 함정이 있다. 대부분의 프로젝트는 전체조직에서 쓰기 위한 경우가 많으며  파트너들 사이의 보이지않는 업무 간 알력 및

이해관계들 사이에서 소프트웨어가 갈길을 모르고 방황하게 된다.

따라서 현업이 주는 정보는 업무설계와 요구분석을 위한 기초정보로 활용하되 전체적인 숲을 보고 업무는 재구성해야 하고 전체적인 영향도 체크해야 한다.

또한 경험많은 PM들이 저지르는 실수들은 자기 경험의 100% 신뢰이다. 특히 유사업무 이거나 자신이 이전프로젝트를 연속해서 하는 경우로 개발여건과 업무가 변화 되었음에도 불구하고 자기 경험에 의지 할경우 결국 프로젝트는 산으로 가기마련이다. 

오로지 필요한것은 경험을 토대로 분석관점을 넓히는 노력이다.