PM, 칸반(Kanban)을 도입하다

스타트업 PM의 '망했군요,' 탈출기-1

이야기를 시작하기에 앞서, 부제에 들어간 '망했군요,' 시기를 설명할 필요가 있을 것 같습니다. 이 시기는 '망했어요?' 시기에 이은 저의 PM생활 2기에 해당합니다. (PM 역할을 한 지가 고작 8개월 여에 불과한 탓에 그 시기를 쪼개어 구분하는 것이 무의미할 수도 있겠지만, 그래도 제가 경험한 내용을 전달하기엔 이 편이 조금 수월하리라는 생각이 드네요.) 앞선 시점인 '망했어요?' 시기는 유저해빗이라는 회사와 서비스를 이해하는 일종의 적응기였습니다. 주로 CS에 집중하며, 간단한 마케팅 업무를 소화하는 것이 주된 일정이었죠. 약 3개월 정도의 시간이 걸렸고요.

그리고 어느 정도 적응이 마무리 되어가는 느낌이 들었을 때, 회사의 어느 동료분이 조심스레 이런 이야기를 꺼냈습니다.

"준형님, 준형님은 PM이니까 PM 역할에 좀 더 집중해주셨으면 좋겠어요 ^^;"

"네, 그래야죠. 이제 구조 파악도 어느 정도 끝났고, 슬슬 본업을 시작해볼게요 ^^!..(어떡하지..?)"

이미지는 이렇지만 사실 저희는 구서원이 한국인 100%인 토종 스타트업입니다..

대답은 자신 있게 했지만 솔직히 문제가 하나 있었습니다. 그 당시만 해도 PM이 도대체 무슨 일을 하는 건지 감을 잡을 수가 없었다는 겁니다. 입사 초기, 저는 제가 이전 회사에서 수행하던 업무를 이어나가는 것이 저의 역할이라고 생각했습니다. 전 회사에서 제 직책은 '부대표'였습니다. 그저 공동 창업자였기 때문에 얻은 자리였죠. 역할은 말 그대로 구멍난 자리 메우기! 디자이너가 없어서 앱 디자인을 했고, 마케터가 없어서 보도자료를 쓰고 SNS 채널을 관리했습니다. 유저해빗과는 달리 청소년 대상의 B2C 서비스였기 때문에 사용자와 소통하거나 커뮤니티를 관리하는 것도 제 역할이었죠. 심지어는 굿즈를 만들고, 판매하고, 배송하는 역할까지 했고요.

'아니, 내가 뭘 잘못하고 있는 거지? 뭘 더 해야 하는 거지?'

라는 생각이 가장 먼저 들었습니다. 이미 지금 회사(유저해빗)에서도 수많은 고객사를 대상으로 한 CS와 마케팅 업무만으로도 너무 바쁘고, 정신 없는 나날을 보내고 있었거든요. 며칠 고민을 하다가 대표님, 이야기를 꺼낸 분께 제게 어떤 역할을 원하는지 물었습니다. 제가 생각한 PM의 역할과 구성원들이 생각하는 저의 역할이 다를 수도 있겠다는 생각이 들었기 때문이죠.

"음.. 제가 생각한 준형님의 역할은 개발팀과 기획팀의 일정을 컨트롤하고, 최종적인 목표에 도달하도록 하는 거예요. 그동안 유저해빗은 개발자 개개인이 목표를 정하고 별다른 기한 없이 이를 달성하는 식으로 일을 해왔어요. 자율성을 바탕으로 효율이 극대화될 때도 있었지만, 분명 독이 되는 시기도 있었다고 느껴져요. 회사가 성장하고, 구성원이 많아져가는 시기이다 보니 그 체계를 다시 한 번 점검한 시기가 온 것 같아요."

두 분과의 대화를 마치고 나니 회사 구성원들이 저에게 원하는 바가 무엇인지 조금 더 명확하게 다가왔습니다. 바로 개발/기획팀의 '일정 관리'와 '로드맵 수립'이라는 것을 말이죠. 어쩌면 (지금에 와서는 너무나 당연하게 느껴지는) PM의 역할을 저는 전혀 수행하지 못하고 있던 겁니다.

무엇을 바꿔야 할지 고민하던 저는 우선 유저해빗의 업무 프로세스를 재검토해 보기로 했습니다. 당시 유저해빗에서는 나름의 애자일 방법론을 활용하고 있었습니다. 매일 오전 10시 온/오프라인을 통해 모든 구성원들이 모여 자신이 오늘 할 일을 이야기했고, 격주 단위로 모여 2시간 가량 각자의 성과 혹은 실패 사례를 공유했죠. 하지만 꽤 오랜 기간 같은 형식으로 업무 공유가 이루어지고, 대표님이 스크럼 마스터의 역할을 병행했던 탓에 여러가지 문제점이 발생했습니다. (1) 영업, 경영지원 등을 포함한 전 직원이 모여 이야기를 나누다보니 관심사 밖의 이야기에 대해서는 무관심하게 지나가는 경우가 많았고, (2) 대표님이 스크럼 마스터의 역할을 병행하다 보니, 업무 공유가 일종의 '보고' 자리 같은 성격을 지니게 되었죠. (3) 1과 2의 문제가 더해져 회의가 2~30분씩 이어지는 경우도 많았습니다.

며칠간의 고민이 이어진 뒤, 저는 유저해빗의 업무 관리 프로세스를 바꾸기로 했습니다. 바로 칸반(Kanban) 형식으로 말이죠. 칸반이란 다수의 소프트웨어 개발 조직에서 활용 중인 일종의 업무 관리 방법입니다. 오프라인에서는 포스트잇을 활용하여 할 일과 진행 중인 일, 해야 할 일 등을 시각화해 보여주며, 온라인을 통해 이를 측정하고, 관리하죠. 칸반은 다음과 같은 6가지 원칙을 토대로 운영됩니다.

1. 업무 흐름의 시각화 (Visualize the Workflow)
2. 진행 중인 업무 제한 (Limit WIP)
3. 흐름 측정 및 관리 (Measure&Optimize flow)
4. 명시적 프로세스 정책 수립 (Explicit policies)
5. 피드백 루프 (Implement Feedback Loop)
6. 경험적으로 협업 증진 (Improve Collaboratively, evolve Experimentally)

이전 회사에서 칸반 제도를 경험해본 분들의 조언 및 관련 도서를 토대로 나름의 관리 규칙을 설정하고, 각종 준비물(보드, 포스트잇, 표시용 자석 등등)을 구입했습니다. 그리고 드디어 시작..!

유저해빗의 칸반보드와 포스트잇을 작성 중인 개발팀장님!

약 5개월 여의 시간이 지난 지금 제가 생각하는 칸반 도입의 장단점은 아래와 같습니다.

장점

1. 오전 회의가 업무 '보고'가 아닌 '공유'의 변화했다. 그러다 보니 자연스럽게 회의 시간이 짧고 간결해졌다.

2. 개발/기회팀 위주로 참여가 이루어지다 보니, 서로의 업무 내용에 조금 더 관심을 가지게 되었다. 그러다 보니 회의가 끝나고 공유된 문제를 서로 토론하거나 해결책을 제시하는 모습도 자주 마주할 수 있게 되었다.

3. 업무의 시각화가 이루어지다 보니 자신이 무엇을 해야 하는지, 어떤 과제가 주어져 있는지를 보다 쉽게 확인할 수 있다.

4. 보드 전반을 PM이 관리하다 보니, 업무 전반에 대한 이해도를 한층 더 높일 수 있었다.

단점

1. 도입 초기, 타 부서와의 성과 공유 등이 이루어지지 않아 이에 대한 아쉬움을 토로하는 경우가 많았다.

2. 관리 프로세스가 바뀐 것이지, 업무 자체가 바뀐 것은 아니기 때문에 변화를 체감하지 못하는 경우가 많다.

3. 스프린트 단위의 업무량을 측정하고 이를 보드에 반영하는 작업이 생각만큼 쉽지 않다.

(+ 가뜩이나 일이 많은데 PM이 해야 할 일(칸반 관리)이 늘어난 기분이다..)

사실 이밖에도 나열하고 싶은 장점 혹은 단점들이 많이 있지만, 아직 저희도 이를 경험해 나가며 바꿔가는 과정에 있기에 이번 글에서 모두 설명하기에는 다소 어려움이 있을 것 같습니다. (칸반 제도가 '제대로' 정착되는 데에는 통상적으로 1년 정도의 기간이 걸린다고 하더군요.) 이런 부분, 그리고 칸반 제도 도입에 필요한 최소한의 원칙 등에 대해서는 차차 다루어 가도록 하겠습니다.

긴 글, 끝까지 읽어주셔서 감사합니다 :)