PM과 PL 둘이서 이끄는 프로젝트, 협업을 잘하려면
처음에는 혼자 하는 게 더 쉽다
최근에 함께 일하는 동료와 마찰을 겪고 있는 분의 이야기를 듣게 되었다.
일하는 성향도 다르기도 하고, 함께 일하는 분이 아직 일을 시작한 지 얼마 되지 않았기 때문에 발생하는 여러 이슈였다.
어딜 가나 비슷하겠지만 IT 업계에서는 협업이 필수적이다.
그래서 일을 하는 동안 당연히 갈등이 생길 수밖에 없는데
이야기를 듣다 보니 '나는 어떻게 해오고 있었나..'라는 생각이 문득 들었다.
현재 나는 두 개의 프로젝트를 PM으로서 관리하고 있다.
그리고 두 프로젝트 모두 다른 동료가 PL의 역할을 맡아 도움을 주고 있다.
A 프로젝트는 혼자 몇 개월 간 진행을 하다가 새로 PL이 투입된 프로젝트이고, B 프로젝트는 처음부터 같이 시작한 프로젝트이다.
그렇기에 두 프로젝트는 협업을 시작하게 되었을 때 고민의 시작점이 달랐다.
A 프로젝트는 'PL을 어떻게 적응시킬 수 있을까? 그리고 같이 어떻게 테스크를 잘 관리할 수 있을까?'였고, B 프로젝트는 '리드하는 것이 더 편한 두 사람끼리 협업을 잘할 수 있을까?'였다.
그중에서 오늘은 고민이 좀 더 많았던 A 프로젝트에 대해 말해보려 한다.
A 프로젝트는 런칭 후 일이 정말 많은 때였고 그때 K라는 동료가 투입되었다.
내가 PL이었던 적은 있지만 PM으로서 PL과 함께 일해본 적은 이번이 처음이었다.
그리고 K는 당시 인턴이었기 때문에 (나도 배워야 하는 입장이라고 생각하지만) 내가 많은 것을 알려줘야겠다는 생각에 걱정이 앞서기도 했다.
무엇보다 가장 큰 문제는 런칭 후 K가 투입되었기 때문에 일을 하느라 바쁜 와중에도 서비스와 프로젝트 자체에 대한 이해도 씽크를 맞추는 것이었다.
내가 이 서비스에 대해 설명을 주구장창하더라도 K가 기억하지 못한다면 말짱 도루묵이다.
어느 정도의 인수인계를 마친 이후에는 '스토리보드를 많이 읽어보고, 서비스를 많이 사용해면서 파악을 하라'는 요청을 했다.
처음 한 달은 당연히 서비스를 온전히 알고 이해하는 것이 어렵다는 것을 알고 있었기 때문에 차근차근 알려주려 했다. 그 이후에는 이것은 알고 있어야 하는 부분이라고 명확히 짚어주며 PL의 역할을 잘할 수 있게끔 유도했다.
그리고 함께 일을 하며 3가지의 루틴이 자리를 잡았다.
업무 진척도 체크, 우선순위 체크, 월간 회고
업무 진척도 체크
- 테스크 관리 방식은 프로젝트에 맞게 바꾸자
바쁘다 바빠! 우선 상대적으로 작은 업무부터 K에게 배정을 했다.
클라이언트가 요청한 사항들을 Jira 티켓으로 업로드하는 것.
그런데 런칭 이후이다 보니 백로그가 많기도 너무 많았다.
처음에는 노션에서 칸반보드 형태로 테스크를 관리했다.
하나의 테스크 당 단계가 적다면 칸반보드 형태도 괜찮았을 텐데, 우리에게는 단계가 너무 많았다.
기획 - 내부 컨펌 - 기획 내용 고객사 컨펌 - 기획 수정 - 디자인 요청 - 디자인 내부 컨펌 - 디자인 고객사 컨펌 - 디자인 수정 - 개발 요청 - 개발 - 테스트 - 디버깅 - 개발 내용 고객사 컨펌 - 스테이징 서버 배포 - 운영 서버 배포
이렇게 적어도 15개의 단계를 거쳐야 테스크가 종료된다.
그리고 각각의 테스크마다 단계가 다를 수밖에 없었다.
칸반보드로 이 상황을 관리하기에는 어렵다는 판단을 했고,
결국 각 테스크 당 해야 하는 단계를 쭉- 늘여서 작성하고 하나씩 체크리스트를 지워나가는 방식을 선택했다.
대신 긴급도와 중요도를 따져서, 업무들을 색상으로 구분하여 시각적으로 눈에 띄게 한다.
또한 매일 아침 오프닝 세션을 하면서 전날 업무에 대한 브리핑을 하고 오늘 할 업무에 대해 얘기하며 테스크들을 처리한다.
어찌 보면 칸반보드보다는 좀 아날로그적일 수 있는데 나와 K는 이 방식에 적응을 했고 아직 이 방식보다 효율적인 방법을 찾지 못했다.
*칸반보드란? 시각화된 프로젝트 관리 방식의 일종이며, 업무의 과정을 단계별로 체크할 수 있다는 장점이 있는 칸반(kanban)을 도구화한 것을 말한다.
우선순위 체크
- 내가 생각하는 우선순위와 상대방이 생각하는 우선순위가 다를 수 있다.
나는 내가 생각하는 것이 K에게도 동기화가 되어 있을 것이라는 큰 오산을 했다.
예를 들어 a 업무는 b보다 중요도와 긴급도가 높기 때문에 a를 먼저 처리해야 했다.
그런데 아무리 시간이 지나도 a가 완료될 기미가 보이지 않는다.
알고 보니 K는 b를 먼저 진행하고 있었던 것이다.
각 업무의 마감 기한을 말해주지 않은 나의 실수였다.
캐릿 뉴스레터를 읽다가 '선배가 마감기한을 꼭 말해줬으면 좋겠다.'라는 어떠한 분의 멘트를 읽게 되었다.
이 부분을 내가 놓치고 있었다는 것을 깨닫고 그때부터는 마감 기한을 챙겨서 말하려고 노력한다.
그리고 오프닝 세션에서 각 업무의 우선순위를 어떻게 생각하고 있는지를 물어본다.
그때 나와 상대방의 견해차를 알 수 있고 잘못된 사항은 시정하여 서로의 생각을 맞추려고 한다. 우선순위 체크는 꼭 필요한 단계이다.
월간 회고
- 앞으로 함께 더 잘 일하기 위해 속마음을 말하는 시간
출처 : pixabay 'Gerd Altmann'월간 회고에서 프로젝트를 진행하면서 발생했던 이슈와 해결책에 대해서 공유하기도 하고, 더 나아가서 서로에게 바라는 점이나 부족한 점, 좋았던 점에 대해 최대한 말해보려고 한다. 물론 내가 PM이고 내가 더 나이가 많기 때문에 이러한 점에 대해서 말을 하는 게 더 쉽다는 것을 알고 있다. 그럼에도 불구하고 이 시간을 가지는 것은, 그래도 K가 나에게 정말 하고 싶은 말이 있다면 꼭 얘기를 했으면 하는 마음이 있어서다. 처음에는 좋지 않은 얘기는 하지 않으려 하던 K가 나중에는 꺼내기 어려운 말들도 조심스럽게 얘기를 하는 것을 보니 월간회고의 효과가 있다고 생각했다.
이제는 이 프로젝트를 혼자 진행한 시간보다 함께 한 시간이 더 길어졌다.
그리고 함께 하는 것이 익숙해졌고 이제는 내가 걱정 없이 연차를 다녀올 수 있을 정도로 K가 적응을 잘했다.
또한 A 프로젝트에서 사용한 이 루틴들은 B 프로젝트에 맞게 변형하여 진행을 하고 있다.
사실 나도 아직 협업을 하는 것이 어렵지만 협업을 하며 배우는 것이 정말 많다.
IT 업계에서 오래오래 일을 하기 위해, 일하는 방식과 태도에 대해 더 많이 고민해야겠다는 생각이 든다.
