예전에 운영하다가 한동안 썩혀두었던 제 블로그 글들을 정리했습니다.그러다 제가 작은 벤처회사에서 열정적으로 일할 때 썼던 글이 눈에 띄었습니다. "나의 프로젝트 관리 철학"이라는 거창한 제목이 붙은 글이네요.
제가 쓴 이 글을 읽으면서 얼굴이 화끈거립니다만, 다만 그 열정만은 마음을 훈훈하게 하네요.
이제 몸과 마음이 지치고 열정이 식어 남극의 얼음보다 더 차가운 지금의 나에게 내가 쓴 이 글이 큰 자극이 되었으면 하는 바램으로 다시 싣습니다. 예전의 내가 지금의 나에게...
소규모의 PM부터 중규모의 PM까지 PM만 어느듯 6년을 했다. 대규모 SI업체에서 하는 로비부터 시작해서 장비구성 소프트웨어 설계, 감리, 도큐먼트를 아우르는 몇백억대의 프로젝트는 해보지 못했지만 수억원대의 프로젝트는 많이 수행해본 경험이 있다.
PM은 정치와 비슷하다. 나 스스로 정치를 한다고 생각한다. 내가 팀원들에게 어떻게 보이느냐, 어떻게 하면 팀원들에게 동기부여를 해서 무리한 일정을 강행시킬 수 있나, 프로젝트의 비참한 현실(진행도 면에서)을 어떻게 잘 포장해서 고객에게 보고할 것인가 등등 정치를 못하면 PM은 못한다고 봐야 한다.
항상 팀원들에게는 카리스마 있으며, 믿음직하고 Fair한 PM이 되어야 하고, 고객에게는 일정 준수는 칼같이 한다는 신뢰, 제품 성능에 대한 신뢰, 투철한 책임감, 비위를 맞추는 등의 일들이 PM의 일이다.
현재 나는 4개(곧 5개가 되겠지만)의 소팀을 꾸리는 대빵 PM이다. 각팀당 4명씩이니 16명~20명 정도의 조직이 될 터이다. 각 소팀은 나름대로의 전문분야를 기준으로 분류되었으며, 그러나 나름대로 하나의 프로젝트를 독자적으로 소화할 수 있는 완결구조를 가지게 하려고 노력한다.
아래에 나의 프로젝트(팀원)관리의 원칙을 정리해보았다.
1. 재미없는 프로젝트일 수록 중요성을 항상 주지시킨다.
- 프로젝트에 따라 개발자에게 흥미를 주지만 돈이 안되는 경우도 있고, 돈은 되지만 유지보수와 같은 재미없는 일도 있을 수 있다. 이 둘을 만족하는 프로젝트는 흔치 않다. 기술적 난이도가 높은 프로젝트는 뒤집어 말하면 노가다/밤샘이 필연적으로 따라오는 프로젝트이기 때문이다.
- 기술적 난이도가 있는 프로젝트들을 일반적인 개발자라면 좋아들 한다. 그래서 사실 이런 프로젝트는 별로 걱정을 하지 않는다. 문제는 별로 재미없고 기술적 난이도도 낮은 프로젝트들이다. 이런 프로젝트는 유지보수가 대부분인데, 유지보수 프로젝트는 큰 클라이언트를 상대로 할때 안정적인 수익을 보장할 수 있는 회사 입장에서는 매우 좋은 프로젝트이다.
- 재미없는 프로젝트일 수록 이 프로젝트를 수행하는 팀원들에게 회사가 얼마나 고마워하고 있는지, 회사에게 얼마나 이득이 되는 프로젝트인지를 자세히 설명하고, PM인 내가 관심을 가져준다. 팀원들을 불러 진행사항을 일일이 보고받고, "알아서 하세요" 보다는 "이렇게 하는것이 좋은 것 같은데, 판단해보시고 좋은 방안을 선택하세요"라고 관심을 보여야 한다.
2. PM은 재미없고, 아무도 안하려 하고, 힘든일을 해야 한다.
- 흔히 저지르기 쉬운 오류는 프로젝트의 코어부분에 대해서 PM이 직접 개발한다는 것이다. 그외의 팀원은 재미없고, 아무도 안하려 하는, 힘든일을 하고... 이것은 팀원들의 불만을 가져올 뿐이다. 그 팀원이 아무리 실력없어 보여도 코어부분을 맡기고 지속적으로 감시해보라... 우리는 CVS를 쓰기 때문에 팀원들이 개발하는 사항을 일단위로 update하여 볼 수 있다.
- 소스를 검토해보고... 문제점을 메일로 알려주는 방식으로 계속 팀원을 업그레이드시켜 나가야 한다.
- 그럼 PM이 하는 일은 뭔가? 실제로 내가 프로젝트에서 실제 개발하는 일은 OAM, 프로세스 관리, 시스템 설정, 이중화 구성 등의 어찌보면 시스템 엔지니어의 일을 하고 있다. 그러나 이런 일이 없으면 서비스를 운영하지 못한다.
3. 팀원들 보다 늦게 출근해도 좋다. 대신 먼저 퇴근하지 마라.
- 프로젝트를 하다보면 야근에 철야가 있기 마련이다. PM이라면 팀원들보다 늦게 출근하는 한이 있더라도 먼저 퇴근하면 안된다. 프로젝트 전체가 loose해버려지는 문제가 있다.
4. 내가 무엇을 할까 보다는 무슨일을 시킬 것인가 먼저 고민해라.
- 프로젝트를 받으면 업무분장을 먼저하는데... 설계를 담당하는 PM입장에서 가장 먼저 해야할 일은 팀원들이 무슨일을 해야하는지를 명확히 해주어야 한다는 점이다.
- 그러므로 모듈을 나누고, 기능 정의를 하는 것, 그리고 모듈간의 인터페이스는 어떻게 할 것인가가 가장 먼저 나와야 하는 설계서이다. 내가 할일은 그 다음으로 미루어야 한다.
- 프로젝트 일정은 다가오는데, PM만 열라 바쁘고, 팀원은 할일이 없다면... 바로 이문제이다.
5. Python을 적극 활용하라.
- 본인은 C++ 엔지니어이지만, Python을 더 좋아하고 더 많이 활용한다. 요즘은 C를 Python extension 개발용으로 밖에 사용하지 않는다.
- 각 소팀이 프로젝트의 처음부터 끝까지를 맡을 수 있는 구조가 된데는 Python을 개발공통 언어로 도입한 것이 크다.
- Python을 책을 각 팀별로 하나씩 사주었고, Python으로 코딩하는 법에 대한 세미나를 두세번 열었다. 그리고 각 프로젝트를 Python으로 진행하도록 독려하였다. 그 결과 요즘의 서버-사이드 프로젝트는 Python으로 거의 다 개발된다.
- Python의 장점은 상당한 수준의 신뢰성있는 모듈이 매우 빠른 속도로 개발된다는 것이다. 실례로 얼마전 개발완료된 Cyworld관련 프로젝트에서는 개발기간 2주를 엄수한바 있다. 만일 C로 작성했다면 2달정도 걸릴 일이라고 판단된다.
- 팀원/팀의 퍼포먼스 향상은 자연히 새로운 일을 맡게될 여력이 생기게 만들며, 자칫 한 프로젝트를 오래함으로 생기는 피로감을 줄일 수 있으며, 늘 새로운일을 할 수 있게하는 장점이 있다.
6. 팀장의 관리
- 조직도 상 나와 함께 일하는 4(5)명의 소팀장이 있는데... 작은 회사다 보니 항상 모든 커뮤니케이션이 소팀장과만 이루어지는 것은 아니다.
- 가끔씩 내가 저지르는 실수가 어떤 팀원에게 직접 일을 시키는 경우인데... 이런 일은 되도록 피해야 한다. 아무리 간단한 일이라도 팀장을 통하는 것이 좋다.
7. 묵묵히 궂은일을 하는 팀원을 주목하라.
- PM의 입장에서 개발자는 결원이 생겨도 비교적 쉽게 충원할 수 있다고 보여진다. 물론 내 자신이 개발자이기 때문에 안되면 내가 때우면 되지라는 생각일 터.
- 그러나 묵묵히 궂은일을 하는 팀원이 만일 없는 상황이 온다면 무척이나 곤란할 것이라 생각한다. 궂은일이라는 것은 시스템 운영, 시스템 관리 등의 개발 외적인 일이다. 이런 분야의 성실하고 출중한 인재를 보유하고 있다면 그 회사의 서비스는 안정적으로 돌아간다.
- 흔히들 기술인력이 아니라는 이유로 간과하기 쉽지만... 진짜로 중요한 인재는 바로 그런 인력들이다.
8. 고객중심의 마인드를 강조하라.
- PM 자신이 고객 중심의 마인드를 갖지 않으면 팀원들도 마찬가지이다. 실제로는 고객과 의견충돌을 일으키더라도, 팀원들한테는 고객 우선에 대한 마인드를 항상 강조하도록 해야 한다.
- 장애가 발생했는데도 굉장히 무심한 경우가 있다. 고객은 서비스 사용에 차질이 생기고, 콜센터에 항의하는 사태가 생기는데, 담당 개발자는 식사한다고 좀있다 해결한다고 하는 경우가 있다.
9. 창조적이고 자발적인 노력에 대해 칭찬하고 널리 알리라.
- PM은 팀원들이 어떤 식으로 일을 진행하는지... 항상 지켜보아야 한다. 가끔씩 내가 기대한 것보다 더 좋은 성과가, 내가 기대한 것보다 더 많은 일을 하는 개발자가 있다. 그 개발자가 그것에 대해 자랑하지 않더라도 PM은 그것을 알아야 한다.
- 아까도 CVS 얘기를 했지만, 팀원들의 개발소스를 틈틈히 들여다 보고... 면담을 하면서... 이러한 개선사항을 찾아내어야 한다.
- 프로젝트가 완료되면 프로젝트 완료 발표회를 꼭 한다. 이것은 전체 팀원/회사전체를 위한 것이다. 이 완료발표회시 꼭 빠지면 안되는 내용은 창의적이고 자발적인 노력에 대한 사례를 발표하게 하는 것이고 그 팀원에 대한 칭찬을 하게 하는 것이다. 이런 사례가 쌓이면 능력있는 인재의 조기 승진이 아무런 저항에 부딪히지 않게 된다.
위 내용 외에도 언급은 되어 있지 않지만 개발 중인 소스들을 안전하게 백업하고 히스토리를 관리하는 형상관리도구(Revision Control System)을 사용하는 것도 매우 중요합니다. 개발팀의 안정성과 깊어지고 넓어지는 개발팀의 토대를 구축합니다. 형상관리도구는 CVS나 Subversion보다는 Mercurial을 추천합니다.
그리고 개발팀의 개발코드 외적인 자산을 모으는 Wiki와 같은 분산 편집되지만 중앙관리되는 지식 데이타베이스를 구축해야 합니다. 저의 경우 MoinMoin을 이용하여 위키를 구축하여 두고 개발자들이 항상 이용하도록 독려합니다. 위키 이용 실적을 인사평가에 반영하기도 합니다.
마지막으로 백업의 중요성을 강조하는 겁니다. 소스코드의 경우 중요 마일스톤마다 커밋을 통해 자동 백업하도록 하고, 문서나 중요한 자료 등도 공용의 NAS 저장고에 저장하게 하고 시스템 엔지니어로 하여금 주기적으로 통합 백업하도록 합니다.
개인의 백업도 중요하지만 시스템적으로 백업을 하는 것도 매우 중요합니다. 경험많은 PM들이 항상 얘기하는 무용담은 백업이 없이 날아간 시스템을 초인적인 방법으로 복구시킨 얘기입니다. 이런 경험담은 사실 얘기할 때는 무용담이지만 그 당시에는 목숨을 끊고 싶을 만큼의 스트레스로 다가옵니다.
댓글 없음:
댓글 쓰기