문서의 공유는 이해의 공유가 아니다
손가락이 아니라 달을 보는 연습 - 문제 해결에 집중하는 PM이 되기
1. 이직한지 이제 6개월 (+이제 수습종료!) 새로운 환경에서 PM 겸 기획자로서 우왕좌왕 적응해나가고 있다. 그동안 배우고 느낀 걸 정리하고 싶다는 생각은 있었는데, 얼마 전 읽은 책에서 머리를 한 대 얻어맞은 듯한 경험이 있어서 기록할 겸 몇 자 적어보려 한다.
2. 회사를 옮기면서 나 개인의 성장의 관점에서 기대했던 건 두 가지였다.
- 서비스 안의 작은 기능 단위에서 더 나아가 좀 더 큰 시야에서 서비스와 비즈니스를 바라보는 법을 배우고 싶다.
- 체계와 프로세스가 만드는 서비스가 아니라 아무것도 없는 상황에서도 협력해서 문제를 정의하고 해결하는 법을 배우고 싶다.
3. 서비스와 비즈니스 시야 넓히기
이 역량은 하루 아침에 뚝딱 하고 생기는 것은 아니므로 배웠네 안 배웠네의 기준으로 정의할 순 없을 것 같다. 지속적으로 쌓아가야 하는 업계와 사업적 지식, 그 안에서 인사이트를 얻는 연습을 해야 함은 여실히 깨달은 상태.
다만 서비스를 바라볼 때 기능과 사용성 위주가 아니라 사업적인 목표와 관점, 회사의 지향점도 같이 고려하고 생각해야 한다는 걸 깨달은 것이 지금 기준에서 많이 배운 점이다. (옳은 결정을 내리는 것은 차치하고..ㅎㅎ)
이전 회사 정도의 규모에서는 얻기 쉽지 않았을 경험이라는 데에서 나에겐 너무 값진 결실. 앞으로도 좀 넓은 시야에서 생각하고 바라보는 훈련을 계속 해 나가야겠다.
4. 협력해서 문제를 정의하고 해결하기
사실 이 이야기를 하고 싶었다.
지금까지 내가 생각해온 기획자의 롤은 이러했다
1) 설계한 기능이나 스펙에 대해 이해관계자들과 잘 커뮤니케이션하고
2) 협업하는 이들을 잘 설득&협력해서 결과적으로 하나의 산출물을 만들어내는 사람
이 협업 과정에서 가장 중요하게 생각했던 기획자의 태도 또한 이러했다.
1) 하나의 결과를 내기까지 발생하는 모든 커뮤니케이션의 과정은 모두가 볼 수 있는 장소에 공유되어야 한다.
2) 그래서 지금까지 나는 변경된 스펙이든지. 논의의 과정이든지. 공식 회의의 자리에서나 구두로나 개인 메신저나 이야기한 내용은 정리해서 꼭 모든 이들이 볼 수 있는 형태로 공유했다.
3) 그러고 나서 이후에 비슷한 논의를 하거나 소위 ‘딴 말’을 하는 사람이 있으면 그 문서 내용을 들이밀고 이야기했다. 과거의 팩트를 들고와서 반박하는 건 효과도 좋았다 ㅎㅎ
사실 이 태도가 잘못되었다든가, 이러한 습관이 잘못된 거라는 생각은 하지 않는다. 하지만 내가 ‘공유하는 목적’이 무엇이었는가에 대해 다시금 생각해보게 되었다. (정확히는 반성) 바로 요 책, ‘사용자 스토리 맵 만들기’를 읽고.
우리는 명확하게 대화하고 오해를 피하기 위해 문서를 작성하지만 사실은 그 반대인 경우가 더 많다.
문서의 공유가 이해의 공유를 의미하지는 않는다.
사용자 스토리 맵 만들기 중에서5. 사실 사용자와 서비스의 문제는 PM만, 기획자만 나서서 해결하는 것은 아니다. 문제 해결이라는 공통 목표 아래 사업-기획-디자인-개발-데이터-운영 등 ... 서비스와 관련된 모든 이들이 함께 협력하여 해결하는 데 있다.
해결 방안을 논의하고 그 결과를 서로가 잘 이해하기 위한 수단 중 하나가 문서를 만들어 공유하는 것인데, 내가 지금까지 해온 문서 작성 - 회의록, JIRA나 슬랙 코멘트 등 - 의 목적은 그냥 기록을 남기기 위함인 그저 일차원적인 것이 아니었나 싶었다.
아무리 화려하게 보기좋게 문서를 공유한다고 해도... 결국에 그 문서 전후로 논의한 내용을 서로가 같은 ‘Align’하에 이해하고 있지 않으면 커뮤니케이션 비용만 더 들거나 복잡함만 가중될 뿐인데 말이다.
6. 이후로 내가 다짐하고 상기해야 할 것은
1) PM으로서 수많은 협업관계자들과 커뮤니케이션하는 목적을 잃지 않아야 하고
2) 문서는 단지 그 수단으로서의 역할이라는 것.
우리가 측정하는 것은 우리가 만든 제품과 서비스로 인해 사람들이 어떻게 이전과 다르게 목표에 도달하는지 여부이고
가장 중요한 것은 우리가 그들의 삶을 더 낫게 만들었는가이다.
