몇 해를 거쳐오면서 지속적으로 눈에 밟히는 부분은 '커뮤니케이션'의 중요성이었다.
다른 업태의 프로젝트도 비슷할 것 같지만 IT 프로젝트 역시 성과의 40%는 커뮤니케이션이 어떻게 진행되어 왔는지가 좌우하는 것 같다는 생각이 든다.
신규 조직이나 프로젝트의 목표/방향(KPI)/R&R이 정해지는 단계에서 개인적으로는 커뮤니케이션 관련하여 가장 중요한 부분이라고 생각하지만 많은 경우 JD나 프로젝트 킥오프 문서 속의 형식적인 조직도와 한두 줄의 텍스트 설명으로 끝나는 경우가 많다.
평소에도 일당백을 해내야 하는 업무 밀도와 강도가 높은 소규모 조직일수록 프로젝트 빌드업 단계에서 프로젝트 조직도에 포함된 사람들에게 할당된 R&R에 대한 오너십을 쥐게 하는 것은 첫 번째 마주하게 될 가장 큰 장벽 중 하나이다. 팀원들이 '자발적'으로 자신이 해야 할 일을 스스로 찾아내고 움직이도록 하려면 소위 말하는 '동기부여'가 있어야 하는데 개개인의 니즈와 강약점을 이해하고 맞춤형으로 일을 주는 그런 개인 맞춤형의 동기부여가 아니라 아니라 강제적인 형태든, 자율적인 형태든 그들이 '프로젝트를 위해' 의지적으로 action 해야만 하는 '당위성'에 대한 '내제화'가 이루어져야 가능하다.
이 부분은 단순히 프로젝트 PM이 혼자 해결할 수 있는 부분이 아니라 프로젝트 팀원들이 소속되어 있는 서로 다른 각 팀의 팀장들이 그들이 오너십을 쥘 수 있도록 우선순위를 조정해서 여유공간을 만들어 주거나, 여유공간을 줄 수 없다면 팀원이 맡은 R&R에 대한 역할 수행 및 그 결과에 대해 명확하게 처음부터 평가에 반영될 부분이라는 것을 align 해서 명시시켜주어야 한다.
여기서의 또 다른 장애물은 팀장들도 자신이 직접적으로 참여하는 프로젝트가 아닌 이상 이 부분에 대해서 능동적으로 움직이지 않기 때문에 프로젝트 PM은 그런 제반 환경이 구성될 수 있도록 팀장들을 설득하고 그들도 프로젝트의 기여자가 될 수 있도록 align 시키고 지속적으로 주요 의사결정 포인트를 그들에게 노출시키고, 때로는 주요 의사결정의 참여자가 되도록 involve 시키는 작업을 관리해야 한다. 가능하다면 초반부터 그들의 상사인 시니어 리더들에게도 역할을 부여하여(형식적인 'PMO'라는 타이틀이 아니라 어떤 경우에 그들로부터 어떤 지원이 필요한지 구체적으로) 참여시키는 것이 좋다.
문제는 프로젝트를 많이 경험한 PM들이 이미 알고 있는 내용임에도 이 작업이 프로젝트 초기 단계에서 세밀하게 build 되고 준비되는 것이 아니라 프로젝트 중반이 되어서어야 프로젝트 팀원들의 역할 소홀로 구멍이 점점 커지는 것이 risk가 될 조짐이 보일 때 프로젝트 팀원들을 통제하기 위해 시니어리더들에게 SOS를 치는 경우가 많다는 것이다. 이렇게 돼버리면 프로젝트가 끝날 때까지 커뮤니케이션 영역은 PM자신에게도, 프로젝트 팀원들에게도 일을 진행시키기 위한 무거운 짐이 되어버린다.
커뮤니케이션과 관련한 또 다른 중요한 한 가지는 '문서'이다. 적재 적시에 잘 준비된 문서는 매우 훌륭한 커뮤니케이션 도구로 사용될 수 있다. 왜냐면 문서는 실제적인 결과물로서 눈에 보이기도 하고, 구두나 메일로 설명하기 복잡한 내용들을 일목요연하게 표현할 수 있기 때문이다. 커뮤니케이션을 잘하는 사람을 문서/산출물 작성을 별개의 하기 싫은데 왜 해야 하는지 모르겠지만 해야만 하는 숙제와 같은 작업으로 생각하지 않는다. 누가 시키지 않더라도 자신의 업무 효율을 높이기 위해 공유와 정리가 필요한 것을 바로 템플릿을 만들어 지속적으로 업데이트하고 관리한다.
문서를 '숙제'로 생각하고 작성하는 사람과 '도구'로 생각하고 작성하는 사람의 결과물은 활용성/확장성에 있어서도 극명한 차이가 난다. '도구'로 생각하는 사람은 '어떤'내용을 '어떻게'담을지를 먼저 고민하고, 이것을 공유자원으로 표준화시키기도 한다.
마지막으로 중요하다고 생각하는 것은 '제약사항' or '한계'를 직면하고 '출구'를 찾아나가는 커뮤니케이션이다.
업무와 관련된 모든 커뮤니케이션 영역에서 고려가 필요한 부분이고 아마 개인이 컨트롤해야 하지만 컨트롤 하기 가장 어려운 부분일 것이다. 특히 개인이 충돌을 피하기 어려운 유형의 사람을 마주해야 할 때는 더더욱 그렇다.
'리부트(저자: 제리 콜로나)'라는 책에 나오는 내용 중 '기계의 망령'에 대한 비유가 있다. 개발자가 만든 각종 프로그램들은 시간을 거듭해 오면서 새로운 기능과 새로운 방식의 코딩으로 덧씌워지는데 이 과정에서 과거에 만든 코딩이 없어지는 것이 아니라 일부는 그 안에 남아있게 된다. 문제는 더 이상 유효하지 않는 그 과거의 잔여물이 현재 정상 동작되어야 하는 기능을 오작동하게 하거나 망가뜨린다는 것이다.
이 비유는 회사 내에서 다른 사람들과 커뮤니케이션에서 충돌이 발생될 때 보통 상대방이 비이성적이라서 잘못 생각하고 있다고, 잘못 일하고 있다고 주장하지만 사실 우리 모두에게는 우리 자신의 망령이 있다는 것이다.
그들은 우리가 차마 마주하지 못하는 자아의 부정적이거나 긍정적인 자질을 투영하는 막이 된다
우리의 망령을 상대방에게 투영하여 잘못된 커뮤니케이션을 하고 있다면 그것을 바로잡는 것은 나에게 달린 일이다.
가장 최근 내가 고질적으로 부딪히는 커뮤니케이션의 딜레마는 나에게 너무 자연스럽고 당연한 사고의 흐름과 방향을 결정 내리는 방식이 누군가에게는 백번을 설명하고 직접 보여주기까지 해도 상대방은 '도무지 스스로는 어떻게 해야 하는 것인지' catch 하지 못하고 계속 어리둥절한 상태일 수 있다는 것이다. 업무 지시를 하는 입장에서 상대방이 받지 못하는 말을 계속 던지게 되는 루틴이 반복되면 업무 지시자가 던진 말을 몸빵으로 맞으면서 버티고 있는 상대방이 어느 날 눈에 들어오게 된다. 그도 그러고 싶은 것은 아니지만 그냥 그 소용돌이에 휘말려 빠져나갈 구멍을 찾지 못했기 때문이다. 상대방에 대한 제약사항을 인지 못하고 계속 똑같은 방식으로 내 메시지를 전달하는데만 에너지를 쏟으면 그 무한 루틴에서 벗어날 수가 없을 뿐만 아니라 의도와 달리 상대방과 나의 관계마저도 늪으로 빠져들어가게 된다.
나의 경험처럼, 커뮤니케이션이 기대한 방향으로 진행되지 않을 때 중간에 가운데 놓여있는 퍼즐을 풀어 문을 열고 나가는 것보다 커뮤니케이션 그 자체에 매몰되어 진전이 되지 못하는 경우들이 종종 발생한다.
커뮤니케이션의 장벽을 만나면, 가능한 한 빨리 매몰되지 않도록 그 대화에서 빠져나와 한 발자국 떨어져 할 수 없는 것과 할 수 있는 것을 객관적으로 살핀 후 다른 측면으로 접근할 필요가 있다. 그리고 그 답을 찾는 사람이 꼭 '나'가 아니어도 되고, 커뮤니케이션에 응해야 사람이 꼭 내가 지금 상대하고 있는 그 '상대방'이 아니어도 된다. 주변 사람, 상황, 환경 등 활용 가능한 다양한 방식을 통해 다른 방식으로 퍼즐을 풀어나갈 수 있는 것이다.