업무 범위 줄이기
기획자의 업무 분장은 고무줄과 같습니다
언제는 업무 범위를 넓히라더니 갑자기 업무 범위를 줄이라는 글을 들고 왔다. 연말이 되면 어느 회사나 짬 처리의 시즌이 돌아온다. 바빠서 1년 내내 건드리지도 못했거나, 묵혀뒀거나, 모른 척했거나, 갑자기 누가 똥을 줬거나 등등의 이유로 올해 안에 처리해야만 하는 똥건들이 들이닥친다. 보통 IT 조직에서 똥을 싸는 역할은 이상하게 기획자로 많이 포커싱되어 있다. 빌런은 여기저기에 있지만 이유를 추측해보자면, 아마도 사방팔방에서 던지는 요건을 제일 처음 받게 되는 사람이 기획자이기 때문이다. 유관부서, 파트너사, 프로젝트 수행사, 개발자, 디자이너... 누구든 기획자에게 달려가는 게 제일 쉽다. 기획자가 전체 그림을 알고 있기 때문이다.
한 서비스의 A부터 Z까지 본인의 손길이 닿아있으면 좋다. 갑자기 R을 물어와도 히스토리부터 개발 이슈, 남은 개선사항까지 읊을 수 있는 정도라면 베스트다. 하지만 몸은 하나고 진행되는 프로젝트의 모든 것을 기획자 한 명이 낱낱이 알기란 불가능하다. 그저 남들보다 조금 더 아는 정도에서 그친다. 아쉬울 수도 있으나 한계를 인정하고 욕심을 버려야 한다.
자칫하면 퍼지기 쉬운 기획자의 업무에는 선택과 집중이 필요하다.
1. 과거의 업무가 불현듯 나타날 때
- 아무리 눈에 밟혀도 현재 담당자에게 토스할 것
내 손을 거쳐간 서비스는 다 내새끼 같다. 그게 애정이든 애증이든, 치열하게 고민해오며 오픈한 기억은 대상을 자꾸 신경 쓰이게 한다. 다른 일을 하다가도 키워드 알림을 설정한 것 마냥 관련 단어가 들어오면 키보드를 치던 손을 멈추고 귀를 쫑긋하게 된다. 내가 만들어낸 내새끼를 죽을 때까지 책임질 의무가 있는 것이다. 그럴 수 있다. 여기가 일반 회사가 아니고 IT 기업이었다면.
일반 회사에서는 IT 기업처럼 이미 오픈한 프로젝트에 공을 들이지 않는다. 뜬금없이 고도화를 하거나 재구축을 한답시고 새로운 프로젝트를 하지 않는 이상 위에서 서술한 정의는 IT 기업의 프로덕트 오너에게나 해당된다. 오픈 이후에도 양질의 운영을 위해 서비스 관련 팀이 계속 존재할 때. 대부분의 프로젝트에서 내게 할당된 역할은 PM이었다. 오픈 후 잔여 결함과 개선 건을 어느 정도 마무리하고 안정화될 때쯤에는 어김없이 운영으로 넘겼다. 그리고는 다른 프로젝트가 시작됐다.
과거는 과거. 현재의 업무에 집중해야 한다. 애초에 인수인계가 잘 이뤄졌다면 현재 운영하는 쪽에서 해결할 일이다. 정말 간단하거나 구축 당시 히스토리를 아는 사람이 필요한 정도의 중요 사안이 아니고서는 일을 넘기는 게 맞다. 업무 떠넘기기와는 다르다. 자신이 맡은 업무에 더 집중하고, 옆으로 관심을 분산시키지 않는데 총력을 기울이자.
2. 급한 요건이라며 치고 들어올 때
- 누구의 요청인지 확인 후 업무 단위를 쪼개 빠르게 분산시킬 것
장애가 아니고서야 그 정도로 급한 요건은 없다. 보통은 얼마나 윗분이 요청하셨는지가 다급함의 정도를 결정한다. (장애라면 만사를 제치고 빠르게 상황 파악 및 전파 후 장애 해결에 집중)
어떤 분의 요청으로 어떤 상황과 맥락에서 어떻게 나온 요건인지를 최초 전달자에게서 잘 들어두는 게 중요하다. 차분하게 결재 라인을 따라 보고하고, 차분하게 운영팀 각 담당자에게 요건을 전달하고 분석한 후 업무 공수를 파악하여 요청자에게 전달하면 된다. 과정에서 다소 짜증이 날 수는 있겠으나 중간에서 양쪽이 최대한 납득할 수 있도록 조율하는게 기획자의 역할이다. 이런 상황에서 기획이랄게 있냐 싶을 수도 있지만, 한 번 볼 때 꼼꼼하게 보고 기획이 필요한 부분은 확실히 들어가주는게 시간을 줄인다.
정리하자면, 대략의 흐름을 파악한 후 단위를 쪼개 각 파트로 최대한 빠르게 전달한다. 속도가 핵심이지만 가감을 놓치지 않고 일을 분배할 수 있도록 하자.
3. 메인 업무의 가지가 동시다발적으로 터질 때
- 업무의 경중을 파악해 우선순위의 일부터 처리할 것
위의 두 상황들과는 다르게 메인 업무라면 모두 직접 컨트롤하고 싶은게 당연하다. 문제는 우리가 쳐낼 수 있는 일에는 한계가 있다는 사실이다. 기획자가 여러 명이라면 파트별로 나눠서 담당할 수 있겠지만, 여기는 IT회사가 아니고 대부분 기획자를 한 명만 배정한다. 분담할 수 있는 동료가 없는 우리는 선택해야만 한다. 충분히 품을 들여서 풀어내야만 하는 일과 빠르게 쳐낼 일을.
기획자는 현재 진행 중인 건에 대한 히스토리를 누구보다 잘 파악하고 있어야 한다. 그래야 어느 맥락에서 어떤 일이 터졌을 때 원인을 찾고 담당자를 지정하는 시간이 단축된다. 어느 정도 규모가 있는 업무들에는 WBS가 있다. 각 파트별 일/주/월 목표 작업량도 있다. 계획과 목표는 절대적이지는 않지만 상대적인 판단 기준이 된다. 문서와 히스토리, 당장의 상황을 고려해 우선순위를 세우고 협의를 통해 처리 순서를 확정한다. 당장 해결하지 않으면 업무가 진행이 되지 않는 사안부터 처리해나간다. 보통 많은 파트가 연관되어 있는 정책이나 설계부터 시작해서 자잘한 기획 오류나 수정 건을 후순위로 처리한다.
동시에 모든 걸 잘 해낼 수 있는 사람은 없다. 여러 개를 손에 들고 허둥지둥하다보면, 하나만 했으면 90은 해낼 일을 둘 다 50도 안 되게 처리하게 된다. 언제나 순서를 매기고 하나씩 해결해나가도록 하자.
기획자의 일은 딜레마의 연속이다. 업무 전반을 넓게 보고 전반적인 상황을 포함하는 능력도 가져야 하지만, 지엽적인 부분도 놓칠 수는 없다. 하나의 서비스를 만들 때마다 작은 세계가 태어난다. 새로운 세계는 그 크기와 상관없이 언제나 방대한 기반을 가진다. 기획자는 그 세계의 기반을 다지는 역할이다. 세계를 설계하고 운영하는 일까지 고려해야 한다. 한 번에 하나만 할 수 있는 환경이면 좋겠지만 기획자의 일은 늘 그렇지 못할 것이다. 언제나 정신없이 무언가가 동시에 밀려들 것이고, 때로는 그 밀려드는 것들을 쳐내기에도 급급한 나날일 것이다.
당장 해결해나가야 할 일을 선택하고 집중하되, 하나의 일이 끝날 때마다 전체를 볼 수 있으면 좋겠다. 이 작은 변화로 인해 전체의 그림이 어떤 방향으로 조금씩 바뀌어가는지 늘 기민하게 촉을 세우고 있기를 바란다. 우리의 손에서 태어날 작은 세계들을 위해.
