소프트웨어 개발을 하다보면 개발이 어렵기도 하지만, 또 어려운게 부서 간 협업이다. 예를 들어 이번에 우리가 코로나 바이러스로 오프라인이 안되니 온라인 쇼를 열기로 했는데, 그러면 기획 팀에서 기획을 하고, 디자인 팀에서 디자인을 해서, 개발팀에게 일을 내려준다. 자 그래서 앞에서 기획과 디자인을 아주 잘 해서 정확히 그 문서대로 개발을 했더니 모든게 척척 맞아 떨어지더라… 하지만 현실이 그럴리 없으니 뭔가 해야 한다.
예전 회사에서는 수직적인 조직 문화여서, 일단 필요한 사람들을 각 부서에서 뽑아다가 회의실에 모아놓고, 3개월 정도 추진위원회(Task force, TF)를 만들었다. 그러면 그 안에서 일하다가 회의가 필요하면 즉시 그 자리에서 회의를 하고, 궁금한게 있으면 바로 물어보고, 그렇게 시간을 절약해서 후딱 끝내곤 했다. 또한 거기에 프로젝트 매니저(Project manager, PM)를 한 명 둬서, 그 분이 임원으로부터 권한을 위임받아 책임을 지고 프로젝트를 이끌었다. 그럼 그 임원분은 PM을 불러서 진행상황을 보고받고, 이번 프로젝트가 잘 안되면 너랑 나랑 손잡고 짐 싸서 집으로 가는거야… 이렇게 갈굼을 당하곤 했다. 그래도 잘 끝내면 고과 평과에 한 줄 쓸게 생겨서 진급하는데 도움이 되고 그랬다.
그런데 이번 회사는 수평적인 조직 문화여서, 프로젝트를 하는데 프로젝트 매니저(PM)을 두지 않았다. 기획팀은 기획팀대로, 디자인팀은 디자인팀대로, 개발팀은 개발팀대로 알아서 진행해야 했다. 물론 여기도 임원 한 분이 프로젝트를 이끌었지만 그 권한과 책임을 잘 위임하지 않고 파편화되어 내려오다보니 서로 협업하는데 어려움이 많았다. 그렇다고 온라인 쇼를 예정대로 안 할수도 없고, 누군가 이끄는 사람이 없는데 이 프로젝트를 도대체 어떻게 잘 진행할 수 있을까?
나의 생각은, 그런 걸 하는 사람이 없다면 내가 할수도 있다는 것이다. 부서간의 충돌을 해결할 사람이 없다면 내가 그 충돌을 해결할 수도 있고, 뭔가 결정해야 하는데 정확한 결정을 미루면서 회의가 끝도 없이 길어진다면 내가 임의로 결정을 할…순 없고 그러면 너무 나대는 거니까 한 2-3가지 안으로 요약해서 각각의 장단점을 장문의 이메일로 보내서 결정을 독촉한다. 디자인에 문제가 있다면 내가 디자인 파일을 먼저 보고 문제점을 정확히 지적해서 또 장문의 이메일을 써서 독촉하고, 기획에 문제가 있고 이게 비즈니스가 아귀가 안 맞아서 문제가 생길 것 같으면 내가 먼저 어떻게 바꾸면 좋을지 몇가지 안을 생각해서 기획팀에 또 장문의 이메일을 써서 독촉한다.
내가 회의보다 이메일을 좋아하는 이유는, 명시적으로 기록에 남아서이기도 하지만, 회의를 하다보면 말이 길어져서 시간을 낭비할 수 있기 때문이다. 예를 들어 5명이 모여서 1시간을 회의하면 5시간이 드는 셈이지만, 내가 1시간을 들여 이메일을 쓰고 나머지 4명이 이메일을 읽는데 10분이 걸린다면 1시간 40분이 걸리는 셈이다. 어차피 내 입장에서 이렇게 하나 저렇게 하나 1시간이 걸린다면 내가 먼저 나서서 주도하는게 전체적인 시간을 아낄 수 있다.
근데 그러다보면 어딘가에서 꼭 늦어지는 부분이 생긴다. 그게 개발팀일수도 있고, 기획팀일수도 있고, 디자인팀일수도 있다. 그게 조금 파고 들어가보면 그 늦어지는게 누구의 무슨 업무인지 정확히 찝을 수 있다. 그게 Critical Path다. 그걸 풀어야 전체가 풀린다. 그러면 나는 정말 안타까운 일이지만 그 부분을 Micro manage한다. 하루에 한두번씩 꼬박꼬박 진행상황을 물어서 될때까지 닥달을 한다. 물론 그게 다른 부서면 내가 너무 나대는 게 될 수 있으니까 그 부서의 매니저를 통해서 나의 우려를 자주 전달한다. 이렇게 몰아붙이는건 내 시간도 뺐지만 그분의 시간도 뺐는거고 무엇보다 그분이 주도적으로 업무를 할 여지를 줄이기 때문에 마음이 상하고 의욕이 꺾일 수 있다. 그래서 가능하면 안 하는게 좋지만 어쩔 수 없을 때가 생기긴 한다. 내가 남의 마음을 잘 읽지 못하고 내 맘대로 까부는 걸 좋아한다는 점을 항상 명심하며 세심하게 챙겨야 한다.
