아웃라이어가 되기 위한 방법
1만 시간이 필요하지는 않습니다.
말콤 글래드웰이 쓴 <아웃라이어>를 통해 많은 사람이 알게 된 유명한 법칙이 있습니다. 그건 바로 '1만 시간의 법칙'입니다. 안데르스 에릭손 교수가 1993년에 발표한 논문에서 처음 등장한 이 법칙은 실력이 월등한 사람들의 경우, 그 사람들의 재능보다는 얼마나 많이 연습했느냐와 같은 연습량에 비례하여 그 결과가 좋아지는 것을 의미합니다.
하지만 이 이론을 전파했던 안데르스 에릭손 교수는 1만 시간의 재발견이라는 내용으로 자신의 지난 이론의 오류를 말합니다. 1만 시간이라는 연습량이 우선이 아닌 '올바른 방법'으로 연습하는 것이 우선이 되어야 한다고 말합니다. 즉, 올바른 방법으로 연습하는 몇 시간이 올바르지 못한 방법으로 연습하는 몇백 시간보다 낫다는 말입니다.
저는 프로젝트 관리도 이와 같다고 생각합니다. 이미 인터넷과 우리의 주변을 통해 어떻게 하면 더 나은 프로젝트 관리를 할 수 있는지 알 수 있습니다. 그런데 그것만으로는 부족하다고 생각합니다. 어느 정도 내가 하는 일에 대해 자신만의 생각이나 철학이 있어야 더 발전할 수 있고, 소위 아웃라이어의 반열에 이를 수 있지 않을까 생각합니다.
저도 제가 갖고 있는 생각을 더 관철시키고자 노력하는 중입니다. 그래서 이에 대한 부분을 다음과 같이 풀어써보았습니다.
저는 프로젝트 관리를 잘하기 위해서 크게 세 가지를 파악해야 한다고 생각합니다. 그건 바로 What / Who / Why입니다.
What - 프로젝트가 무엇인지 파악한다.
내가 맡은 프로젝트가 무엇인지 파악하는 것은 너무나 당연한 일입니다. 하지만 제가 말하는 파악은 단순히 요약된 형태의 파악이 아닌 세부적인 것까지 알아가는 파악을 의미합니다. 가령 이 프로젝트는 어떤 기능이 구현되어야 하는 것인지, 각 기능이 구현되기 위해서는 어떤 작업들이 필요한지, 그 작업들을 만들 때는 영향도가 얼마나 발생하는지, 또 어느 시점에 배포 또는 출시가 되어야 하는지, 각 작업을 진행할 때 예상되는 Milestone은 어떤 것들이 있는지. 등입니다.
저는 전체를 알지 못하면 문제가 발생하더라도 무엇이 문제인지를 알 수 없다는 생각을 갖고 있습니다. 각자는 자신의 작업에 맞춰 일을 하지만 이 작업들을 하나로 모았을 때, 미처 확인하지 못했던 문제가 나오는 것처럼 전체를 보는 관점이 없는 사람은 문제를 미리 확인할 수 없다고 생각합니다.
그리고 타인을 설득하고 이해시키기 위해서는 누구보다 내가 잘 알아야 그 설명이 가능하다고 생각합니다. 가령 어떤 작업을 진행한다고 할 때, 내가 그 작업을 이해하지 못한 상태에서 다른 사람에게 설명한다면 설명을 들은 사람은 정리가 되지 않은 상태로 혼란스러울 것이고 설명을 한 나는 상대방이 잘 이해했는지가 판단이 서지 않을 것입니다. 그래서 프로젝트에 대해 누구보다 더 상세하게 작업들을 인지해야 한다고 생각합니다.
결국 한 팀이 되어 프로젝트를 진행하기 위해서 관리자는 각 기능에 대해 이해가 되지 않은 팀원들도 이해시킬 수 있을 만큼 프로젝트를 잘 이해해야 한다고 생각합니다. 그렇기 위해서는 프로젝트가 무엇인지를 잘 파악하고 뜯어보고 공부해야 합니다.
Who - 프로젝트를 누구와 함께 하는지 파악한다.
하나의 프로젝트에는 꽤 많은 부서들이 함께 합니다. 프로젝트의 기획, 요구사항의 상세화, 개발 요건으로의 정의, 구현, 테스트, 출시의 마일스톤이 진행될 때까지 프로젝트는 각 구간에서 많은 부서들을 접하고 함께 작업을 하게 됩니다. 그런데 각 마일스톤마다 중심이 되어 작업해야 하는 부서는 매번 달라지게 됩니다.
저는 프로젝트 관리자가 각 시점과 중심이 돼줄 담당자들을 제대로 확인하고 알려주어야 한다고 봅니다. 그래야 각 팀원은 본인이 명확히 활동해야 하는 시기가 왔을 때에 맞춰 작업을 파악할 수 있게 되므로 작업 소홀에 의한 위험요소를 감소시킨다고 생각합니다. 그러기 위해서는 프로젝트 관리자가 프로젝트를 함께 해야 하는 사람들이 누구인지를 정확하게 알고 있어야 합니다.
또, 저는 어느 부서가 담당한다만으로는 부족하다고 봅니다. 그 부서의 담당자가 명확히 있어야 Ownership을 갖고 작업을 진행할 수 있다고 생각하기 때문입니다. 그리고 담당자와의 직접적인 대화를 통해 서로가 갖고 있는 걱정점을 논의를 통해 해소할 수 있다고 생각합니다.
저는 프로젝트 관리자는 지정된 담당자의 의견을 충분히 존중하고 의견 조율이 잘 될 수 있도록 그 사람을 파악해야 한다고 생각합니다. 사람은 의견을 자유롭게 낼 수 있는 환경이 구성되어 있어야 의견을 낼 수 있기 때문입니다. 그리고 그 환경을 만들어 낼 수 있는 것도 결국 사람이기 때문에 프로젝트를 관리하는 사람이라면 모름지기 이 부분도 신경을 써야 합니다.
Why - 프로젝트를 왜 해야 하는지 파악한다.
실제로 프로젝트를 진행하는 사람들은 프로젝트를 왜 해야 하는지 알지 못하는 경우가 많습니다. 프로젝트의 한 일원으로 참가하고 있으니 당연히 알고 있을 것이라 생각할 수 있겠지만 제가 아는 한 사람은 자신이 관심 있는 일 외에는 적극적으로 알려고 하지 않습니다. 그래서 함께 진행하는 사람을 이해시키기 위해 프로젝트를 왜 하는지를 말해야 합니다.
이런 노력을 해야 하는 이유는 간단합니다. 사람은 자신이 이해가 가고 설득이 되지 않으면 적극적으로 행동하지 않기 때문입니다. 이는 마치 내가 내 일을 하는 것이 아니라 다른 사람이 시켜서 억지로 하는 것과 동일하기 때문에 정말 해야 하는 일만 할 뿐, 실제 더 확인하고 봐줘야 하는 일에는 소홀하게 될 가능성이 높습니다.
결국 그 설명을 잘하기 위해서는 왜 이 프로젝트를 해야 하는지에 대해 명확하게 정리가 되어 있어야 하고 설명할 수 있어야 합니다. 이 프로젝트를 통해 해결하고자 하는 문제점이 무엇인지, 그리고 그 문제를 해결하기 위해 우리가 이루고자 하는 목표는 무엇인지, 그 목표를 만들기 위한 방법이 다음과 같고 사용자들은 이렇게 쓰게 되고, 이 프로젝트를 통해 사용자들이 갖는 효과, 또는 조직이 갖게 되는 이점 등은 이렇다. 등을 잘 설명해야 프로젝트를 바라보는 관점을 각자의 관점으로 치환시켜 대입할 수 있게 됩니다.
저는 이렇게 팀원에게 프로젝트를 함께 만들어가자고 설득하는 과정이 서로의 핵심가치를 공유하는 과정이라고 생각합니다. 그래서 더 중요하다고 봅니다. 서로 다른 방향을 보며 가던 사람들이 한 팀이 되기 위해서는 핵심가치라는 목적지와 그 모습을 공유해야 올바른 방향으로 갈 수 있습니다. 그래서 프로젝트를 관리하는 사람은 모든 방향을 한 방향으로 이끌기 위해 프로젝트의 핵심가치를 누구보다도 잘 파악하고 있어야 한다고 생각합니다.
What / Who / Why
위의 설명처럼 저는 프로젝트를 잘 관리하기 위해서는 프로젝트가 무엇인지(What), 누구와 함께 하는지(Who), 그리고 어떤 가치를 이루기 위해 하는 것인지(Why)를 알아야 한다고 생각합니다. 그래야 프로젝트를 진행하면서 발생될 수 있는 위험 요소를 줄일 수 있기 때문입니다.
그러기 위해서는 누구보다 프로젝트에 대한 공부를 많이 해야 하고 누구보다 팀원분들과 많은 대화를 나누어야 하고 진행되는 매 과정을 세세하게 파악하고 있어야 합니다.
물론 이 방법이 쉽지만은 않습니다. 각각의 작업만을 이해하거나 전체에 대해 어느 정도만 이해하는 것과는 다르게 더 많이 공부해야 하고 시간을 투자해야 하기 때문입니다.
하지만 저는 이런 노력들이 그만한 가치를 가지고 있다고 생각합니다. 노력하지 않으면 얻을 수 있는 것은 아무것도 없고 프로젝트 관리자는 누구보다도 더 노력해야 하는 사람이라고 저는 생각하기 때문입니다.
저는 프로젝트 관리의 경험으로 일을 시작한 것은 아닙니다. 하지만 그 일을 배우게 되었을 때, 여러 좋은 분들을 통해 배워갈 수 있었고 경험을 통해 체득할 수 있었습니다.
과거에는 이렇게 해야 좋은 것이라고만 단순히 알고 있었지만 이 작업들이 왜 중요한지를 생각하고 정리해 보니 점점 나만의 방법과 그 철학 등이 생겨나는 것 같습니다.
'올바른 방법'으로 학습해야 한다는 이론에 덧붙이자면 익히고 배워가는 이론들을 점점 나만의 것으로 만들어가는 과정을 거쳐야 내가 배운 이론들이 잘 체득된다고 생각합니다.
그래야 내가 정말 업계에서 아웃라이어가 될 수 있다고 생각합니다.
