PM 스쿨은 소프트웨어 개발팀 관점에서 프로젝트 관리 방법에 대한 이야기를 합니다. 국내 회사는 대부분 개발 팀장이 PM 역할도 병행하기 때문에 PM 스쿨에서는 “개발 팀장”과 “PM”을 혼용해서 쓰고 있지만 맥락에 따라 엄밀히 구분하는 것도 가능합니다.

예를 들어, 한 팀에 PM이 여러 명이 있을 수도 있고, 개발 팀장이 아닌 별도의 PM을 둘 수도 있습니다. 심지어 팀원들이 돌아가면서 PM을 할 수도 있습니다. 각각의 경우에 대해 자세히 살펴보겠습니다.

한 팀에 PM이 여러 명인 경우

이전 회사에서 하나의 팀이 동시에 2개 이상의 프로젝트를 동시에 진행하게 된 경우가 있었습니다. 같은 엔진이지만 서로 요구사항이 다른 고객사 2곳과 동시에 작업을 해야 했기 때문입니다. 한 프로젝트는 개발 팀장이 직접 PM을 맡고, 다른 프로젝트는 팀원 중에 시니어 개발자 한 명이 PM을 맡았습니다. 완전히 별도의 팀으로 나누지 않는 이유는 고객사 대응 자체가 한시적인 일이고, 일부 인원은 양쪽 모두 유동적으로 대응을 해야했기 때문이었습니다.

이 경우 개발 팀장과 PM 사이에 명확히 역할 구분을 해주는 것이 중요합니다. 정해진 답은 없습니다. 효율적인 프로젝트 관리에 필요한 만큼 의사 결정 권한을 개발 팀장이 PM에게 적절하게 위임해야 합니다. 규칙을 꼼꼼하게 정할 필요는 없습니다. 예상치 못한 상황이 나오면 미리 정한 규칙에 따르기 보단 대화를 통해 해결해야 하는 것이 낫기 때문입니다.

이때 신규 PM은 PM 경험이 부족하기 때문에 좀 더 PM 경험이 많은 개발 팀장이 PM 멘터 역할을 해주는 것이 중요합니다. 좋은 PM을 만드는 체계적인 방법 같은 건 없습니다. 직접 PM 역할을 수행하면서 좀 더 경험 많은 PM에게 이런 저런 조언을 받는 게 좋은 PM이 되는 가장 빠른 방법입니다.

개발 팀장이 PM이 아닌 경우

우리나라에서 “개발 팀장”은 굉장히 복합적인 의미입니다. 이상적인 상황이라면 개발 실무 능력이 검증되었고, 프로젝트 관리도 수행할 수 있는 종합적인 인재가 팀장이 되어야 합니다. 하지만 보통 개발 실력은 출중하지만 PM 능력은 검증되지 않았거나 혹은 관리 능력이 없는 사람을 승진시킬 수밖에 없는 상황이 있습니다. 개발 팀장이 단순 역할이 아니라 연봉이나 직급 면에서 승진을 뜻하기 때문입니다.

이 경우 개발 팀장이 PM을 맡지 않는 것도 방법입니다. 여기서도 역할 구분이 중요합니다. 개발 팀장은 아키텍처나 중요 기술 이슈에 대해 의사 결정을 하거나 기술 이슈가 생겼을 때 트러블슈팅하는 것에 집중하고, 프로젝트 관리 능력이 있는 팀원을 PM으로 지정하여 프로젝트 일정이나 이슈 관리, 사업팀과 커뮤니케이션 등 수행하게 해야합니다.

지난 회사에서 이런 방식으로 PM을 정한 적이 있습니다. 개발 팀장으로 승진한 친구는 굉장히 깊이 있는 엔지니어링 지식을 가지고 있고, 동료 개발자들의 존경을 받았지만 프로젝트 관리 능력은 없었고 본인 스스로도 개발에만 더 집중하고 싶어하였습니다. 하지만 당시에 팀에 비슷한 경력이나 실력의 개발자가 없었기 때문에 이 친구를 팀장으로 승진시킬 수밖에 없었고, 대신 PM은 오히려 연차가 적지만 프로젝트나 관리나 커뮤니케이션에 센스가 있는 친구에게 맡기는 방식을 취했습니다.

이 관계가 유지되려면 개발 팀장과 PM 사이의 신뢰가 무척 중요합니다. 서로의 장점과 단점을 이해하고 역할을 존중해주지 않으면 성립할 수 없는 관계이기 때문입니다. 마찰이 있을 때는 더 높은 직급의 중간 관리자가 둘 사이의 역할과 책임을 적극적으로 조정해 주는 것도 방법입니다. 개발 팀장 입장에서 권한을 빼았겼다는 생각이 들지 않도록 개발 전문성을 존중해주고, PM이 권한이 아니라 프로젝트를 원할하게 돌아가게 하기 위한 역할임을 팀 전체에 명확히 해야 합니다.

팀원이 돌아가면서 PM을 하는 경우

일단 개발 팀장이 꼭 PM일 필요가 없으면 한 단계 더 나아가서 모두가 돌아가면서 PM 역할을 수행할 수도 있습니다. 물론 PM 일이라는 것도 나름의 센스와 전문성이 필요하기 때문에 돌아가면서 맡는 건 위험한 일입니다. 이게 용납되는 상황은 팀에서 통제할 수 없는 외부 요인이 PM 일의 8할을 단순반복 작업으로 만들 때입니다.

예를 들어, 회사가 실무 입장에서 판단했을 때 불필요해 보이는 문서나 자료를 계속해서 요구할 경우 팀장이나 PM이 여기에 매달리기 시작하면 낭비가 너무 커집니다. 이 경우, 중고등학교 때 돌아가면서 주번하듯이 PM을 뽑아서 기계적인 대응을 하는 것도 방법입니다. 정해진 순서대로 할 수도 있고, 지각이나 빌드 브레이크 등의 벌칙으로 PM을 수행하게 만들 수도 있습니다.

외부 업체와 일을 할 때도 비슷한 상황이 있을 수 있습니다. 보통 갑을 관계에서 갑이 프로젝트 관리를 하겠다고 불필요하게 자주 회의를 소집하거나 문서나 자료를 요구하는 경우가 있는데, 이 경우에도 팀장이나 PM이 실제로 필요한 일에 집중할 수 있도록 팀원들이 번갈아가면서 대응할 수 있습니다. 물론 외부에 커뮤니케이션 채널이 여러 개가 되면 혼란을 초래할 수도 있으니, 외부 대응 하나의 창구로 하되 실제 작업은 당번 PM이 수행합니다.

실제로 이런 방식으로 대응을 한 적이 있습니다. 당시 고객사는 어차피 버그 트래커 보면 알 수 있는 버그 진행 사항을 매일 아침 10시마다 컨퍼런스 콜로 보고하기를 원했고, 일과 중에는 2시간 간격으로 진척도를 물었습니다. 덕분에 개발 팀장이나 PM이 이 일을 챙기면 다른 일을 못 하는 상황이었습니다. 궁여지책으로 팀원들이 돌아가면서 PM을 했는데, 이 방식의 최대 장점은 팀원들이 PM 역할의 소중함을 뼈저리게 체감한다는 점입니다 🙂