인력양성 방안
프로젝트를 통해 직원의 역량을 향상시키자.
앞서 얘기한 바 있지만, 프로젝트를 수행하는 조직은 프로젝트를 통해 조직 구성원들의 성장을 이끌어낼 수 있어야 한다.
이번 장에서는 회사의 직원을 성장시키기 위해 PM으로써 어떻게 해야 하는지 내가 생각하는 바를 적어보려고 한다. 단순히 프로젝트만 바라보고 성공시키고자 하는 사람이 PM이라고 할 수도 있을 것이고, 직원의 성장까지 고민해야 하는 것이 과연 PM인지 문제제기를 하는 사람도 있겠지만, 나는 PM이 그런 영역까지 고민해야 한다고 생각하는 편이다.
그 이유는 1) 프로젝트에 모든 개발자가 풍부한 경험을 보유한 전문가로만 구성될 가능성은 거의 없고, 2) 기술적으로 완벽히 알고 있는 기술로만 수행하면 되는 경우도 거의 없으며, 3) 개발자 본인의 열정을 이끌어내고, 몰입하게 만드는 것은 프로젝트의 성공을 위해 필수적인 요소라고 생각하기 때문이다.
그리고, 무엇보다 4) 프로젝트는 PM 혼자만 뛰어나다고 해서 절대로 성공할 수 없기 때문이다. 나는 그러한 부분에서 PM으로써 나 스스로의 한계를 느낀 바 있다. 조직이 보유한 직원의 역량이 기본적인 수준으로 받쳐주지 않는 상태에서 프로젝트를 성공시키는 것은 100% 불가능하다. 그런 경우에는 외부인원 소싱을 한다든가, 내부 인원 중 더 나은 인원을 프로젝트에 투입시킬 수 있어야 하겠지만, 대부분의 경우 현재 프로젝트에 투입되지 않은 가용한 인원 중에서 배정받기 마련이고, 배정받은 인원으로 어떻게든 성공시키려고 노력해왔던 것 같다. 인원의 교체나 외부인원 아웃소싱 시도를 안 해본 것은 아니지만, 많은 경우 회사의 사정상 실현되기는 어려웠고, 실현한 경우에도 아웃소싱 인원을 구하는데 시간이 오래 걸리고, 교체된 인원이 인수인계받는 데 시간이 걸리므로, 기대한 만큼 좋은 효과를 얻지 못했던 것 같다.
그 이후로 나의 목표는 "모든 프로젝트를 성공시키는 PM"에서 "모든 프로젝트를 성공시킬 능력을 가진 프로젝트팀을 보유한 PM"으로 조금 바뀐 것 같다. 읽는 사람 입장에서 실패한 프로젝트의 책임을 능력이 부족한 팀원에게 떠넘기는 것처럼 느껴질 수도 있겠지만, 결코 그렇지는 않다. 프로젝트의 성공 여부는 전적으로 PM의 책임이라고 (적어도 나는) 생각한다. 다만, 조직의 역량이 너무 받쳐주지 않는 경우에 PM이 프로젝트를 성공시키는 데는 한계가 있으므로, 조직 전체의 역량을 향상시키는 부분까지를 나의 목표로 삼아 고민하게 되었다는 것을 얘기하고 싶은 것이다.
개발자가 성장하려면 3가지 요소가 필요하다고 한다.
(꼭 개발자에게만 적용되는 것은 아닐 수도 있을 것 같다. 어쨌든 이 부분은 예전에 같이 일하던 이ㅇㅇ 개발자로부터 들었던 부분이고, 저작권이 있는 얘기는 아닌 것 같으므로, 잠시 인용하려고 한다.)
첫 번째, 지금 당장 내 실력으로 해결하기 어려운 Mission
두 번째, 그 문제를 해결해가는 과정 상 결정적인 순간에 도움을 줄 수 있는 뛰어난 사수
세 번째, 개발자 본인 스스로의 성장하고자 하는 의지, 열정
따라서, PM은 직원의 성장을 위해 위 3가지 요소가 프로젝트 진행 중에 항상 충족되는 상황을 만들기 위해 전략적으로 노력해야 한다.
첫 번째 사항 (어려운 미션) 같은 경우는 프로젝트 상황 자체가 이미 해결하기 어려운 Mission이 어느 정도는 포함되어 있을 것이므로, 그러한 상황을 만드는 것은 크게 어려운 것은 아니다. 리스크 관리 차원에서 프로젝트 초반 기술적으로 구현 상 리스크가 있는 항목을 사전에 도출하여 해당 기술을 어떻게 구현해 갈 것인지 방안과 일정을 수립해보는 것으로 충분할 수도 있다.
두 번째 사항 (뛰어난 사수)는 프로젝트 상황에 따라 다르겠지만, 프로젝트 투입인원 중 key-man에게 나머지 개발자들의 결과물(개발 소스) 품질을 컨트롤하도록 역할을 부여해야 한다. PM은 프로젝트의 key-man(한 명일 수도 있고, 여러 명일 수도 있겠지만)에 대해서는 직접, 자주, 최대한 밀접하게 의사소통할 필요가 있다. PM의 프로젝트에 대한 생각, 인력 양성에 대한 생각을 그 Key-man에게 공유하고, 후배 개발자를 양성하는 데 어느 정도 시간을 할애하도록 지시해야 하며, 그것까지가 그 key-man에게 부여된 책임임을 분명히 주지시키자.
그리고, key-man 본인에게는 프로젝트 내부에 사수가 없는 상태이므로, 그 사람에게 도움을 줄 누군가가 필요한 상태인지, 기술적으로 부족함을 느끼는 부분이 있는지 얘기해보아야 한다. 필요하다면, 본사 내부의 지원인력(연구소, 기술개발팀 등)과 네트워크를 만들어준다든가, 필요시 외부 교육을 다녀오도록 배려해준다든가 하는 식으로 사수를 대체할 무언가를 만들어주도록 노력하자.
세 번째, (개발자 본인의 의지)는 사실 PM 마음대로 안 되는 부분이기는 한데, 그래도 개발자들 개개인별로 면담을 통해 본인의 성장 의지를 확인하고 애로사항은 없는지 확인하는 것이 기본이자 시작점이라고 생각한다.
프로젝트 초반 본인의 기술 수준 대비 현재 프로젝트 범위에서 경험해보지 못한 부분은 무엇인지, 프로젝트 완료 시 습득 예상되는 기술을 생각해보게 만들고, 그런 경험을 진짜 본인의 실력으로 습득하려면 어떻게 해야 할지, PM이 지원해주어야 할 부분은 무엇이 있는지 한 번 글로 써볼 수 있는 시간을 가지면 좋다. 더 나아가 장기적으로 본인이 이루고 싶은 목표가 있는지, 현재 무슨 노력을 하고 있는지까지 끌어낸다면 더욱 좋을 것이다.
대체로 개발자들은 그런 형태의(본인의 생각과 실력을 드러내 놓는) 대화를 싫어하고, 소스코드가 아닌 내용을 자판으로 치는 것은 더욱 싫어하기 때문에 생각만큼 리액션이 없을 수도 있다.
그러나, PM이 먼저 마음을 열고 다가간다면, 적어도 10명 중 2~3명은 진심으로 받아들일 것이고, 나머지 중 5~6명 정도는 흉내는 낼 것이고, 1~2명은 고집스럽게 답을 안 하겠지만 그럼에도 불구하고 답을 하지 않은 그 사람들조차도 한 번쯤은 생각은 해볼 것이기 때문에 충분히 가치 있는 활동이다.
무심한 개발자들에게 상처 받지 말고 일단 한 번은 들이대자.
개발자들에게 열정을 이끌어내는 방법은 PM 개인별로 노하우가 있을 것이고, 개발자 개인별로도 모두 성향이 다르므로, 여기서는 더 이상의 얘기는 하지 않고자 한다. 그러한 방법과 관련해서는 수없이 많은 더 좋은 글과 책들이 무수히 많은 세상이니까.
단지 한 가지 조심할 부분은 PM이 너무 적극적으로 너무 자주 열정이나 비전, 성장, 역량 향상 등을 얘기할 경우, 개발자들은 자칫 심한 압박을 느낄 수 있고, 그것 자체가 어찌 보면 PM의 꼰대 짓으로 느낄 수 있으므로, 개발자의 의사를 타진해보고 딱히 반응이 없거나, 거부반응이 감지된다면, 너무 그것에 집착하지는 말도록 하자. (PM이 보기에는 개발자에게 부족한 부분이 보이고, 더 잘할 수 있는 가능성이 보임에도 불구하고) 본인이 무언가 더 열심히 할 필요성을 느끼지 않는다거나, 누군가 간섭하는 것을 극도로 싫어하는 타입이라면 그러한 PM의 접근이 오히려 역효과가 날 수도 있다.
나 스스로도 40대가 넘어서면서부터는 꼰대 소리를 듣지 않기 위해 조심하고 있다. (어찌 보면 참 서글픈 현실이다.)
예외. 프리랜서 개발자를 투입하는 경우
프로젝트 투입인력을 구성할 때 위 세 가지 조건을 갖추기 힘든 상황이 프리랜서 개발자를 투입하여야 하는 경우이다. 프리랜서 개발자의 투입을 고려하는 경우는 대체로 다음과 같다.
- 자사 인원의 기술 부족 : 자사에서 보유한 인원 중에 프로젝트에 포함된 개발범위의 기술을 수행해본 경험이나 능력이 부족하여 자사 인원으로 직접 수행이 불가능한 경우.
- 자사 투입인원 부족 : 기술적으로 난관을 해결하기 위한 방안이 아니라, 보유한 개발자 중에 현재 프로젝트에 투입 가능한 인원이 없어 외부 소싱을 해서라도 수행하려고 하는 경우
이 중에서 자사 인원의 기술 부족으로 기술/경험이 풍부한 개발자를 소싱하는 경우라면, 자사 인원을 추가로 한 명 더 투입해서라도 해당 프리랜서 개발자의 기술을 프로젝트 기간 동안 모두 흡수하는 것을 제1의 목표로 부여해야 한다. 그렇지 않다면, 비슷한 사업 내용이 나올 경우에 계속해서 해당 프리랜서 인원에 의존할 수밖에 없고, 자사 인원의 성장도 더딜 수밖에 없다. 프로젝트에 당장 꼭 필요하지 않은 인원을 한 명 더 투입하는 것은 회사 차원의 의사결정이 필요한 일이겠지만, 그것은 회사에서 사람을 키우기 위해 꼭 필요한 투자라고 생각한다.
즉, 프리랜서 개발자는 PM이 고민할 인력양성의 대상이 아니고, 이용해야 할 대상일 뿐이다.
PM의 프로젝트 인력 구성 권한에 대하여
우리나라 IT업체 중에 프로젝트 투입인원을 PM이 선택할 수 있는 체계를 가진 곳은 극히 드문 것 같다. 하지만, 나는 개인적으로 프로젝트 팀원을 PM이 선택할 수 있는 체계, 적어도 성공적인 프로젝트 경험을 가진 프로젝트 수행팀원을 PM이 그대로 유지하여 데리고 다닐 수 있는 체계는 필요하다고 생각한다. 성공적으로 프로젝트를 마무리한 프로젝트팀은 이미 팀워크가 형성되어있는 상태이기 때문에 다른 프로젝트에 다시 투입될 경우, 1) 프로젝트 초반의 팀워크 형성 과정을 생략하고, 빠르게 퍼포먼스를 낼 수 있는 상태가 될 수 있을 것이고, 2) 이미 검증된 인원들이므로, 그 인원들이 어느 정도의 생산성을 가질 것인지 PM은 이미 과거 프로젝트의 데이터를 통해 알고 있으므로 보다 정확한 일정관리가 가능할 것이다.
본인도 그 많은 프로젝트들 중에 정말 팀워크가 좋았던 경우가 딱 두 번 있었다. 정말로 일 자체를 즐기는 팀을 만드는 데 성공했었고, 일정, 원가, 품질 어느 하나 빠짐없이 잘 관리되었고, 고객 만족도 또한 상당히 높았다. 이슈가 없었던 것은 아니었고, 해결 과정 상 어려움도 있었지만, 야근도 해가며 문제를 해결하는 과정에서 성취감을 느낄 수 있었고, 고비를 넘길 때마다 팀워크가 더 좋아졌었다. 끝날 때가 되어서는 이 멤버를 데리고 규모가 2~3배 되는 프로젝트라도 해낼 수 있을 것 같은 느낌이었다. 하지만, 그렇게 잘 된 프로젝트의 멤버들은 대체로 높은 평가를 받고, 다른 조직에서 탐을 내기 마련이고, 그것이 그들의 발전을 위해 더 나은 길일 거라는 생각이 들었기 때문에 보내줄 수밖에 없었다.
난이도가 정말 높고 반드시 성공해야 하는 프로젝트일수록 PM에게 프로젝트 팀원을 선택할 수 있는 권한을 부여해주었으면 좋겠다. 그게 프로젝트 성공을 위해 가장 확실한 방법이 아닐까?
