PM에게 가장 필요한 것? #2. 설명충

#2. 설명충

[경고] 이 글은 개인의 성향이 몹시 반영돼있어, 공감이 어려운 분들이 있을 수 있습니다.

기획서. 프로젝트 참여자들의 교과서이다.

UX, 백엔드, 프론트엔드, 마크업, QA 등 모든 작업자들은 내가 작성한 기획서의 한 글자, 한 글자를 토대로 코딩을 하고 화면을 설계하고 QA를 본다. 여러 의미로 해석될 수 있도록 설명을 작성하거나, 미처 정의되지 않은 요건이 있다면 작업이 막힌다. 그래서 기획서 내에 문장을 쓸 때마다 낱말의 어떤 순서로 작성이 돼야 더 의미가 명확할지, 빠뜨린 내용은 없는지 여러번 수정하게 된다. 그러다보면 진짜 이런 것까지 작성해야하나? 이 정도는 작성하지 않아도 알지 않을까? 싶은 순간이 온다. 

이런 것까지 정의해야하나 싶은 수준까지 작성해야한다는 게 내 지론이다.

물론 이게 정답은 아닐 수 있다. 하지만 스펙에 대한 서로 다른 이해로 혼란을 야기하고 싶지 않기에 이 방법을 택했다. 

그러다보니 내 기획서는 설명충이 되어버린다. 

글자가 너무 빼곡해 나조차 읽기싫을 때가 있다. 그치만 기획서 150장 이상을 몇 개월간 업데이트하다보면 나조차 모든 히스토리 기억이 어려운데, 이런 설명충 기획서가 나에게도 교과서가 된다. 지난 달의 내가 정의한 정책을 이번달의 내가 새로운 마음으로 확인하고 안심하게 되는 순간들이 생긴다. 

UX, 백엔드, 프론트엔드 작업자들 각각에게 집중적으로 설명해줘야하는 내용이 다르다. 한 개의 화면에서 UX, 프론트엔드는 화면의 동작, 사용자의 동선에 따른 정책 등이 중요한 반면, 백엔드는 프론트엔드와의 통신, 대외기관과의 통신 상의 정책, DB구조, 데이터 정책 등이 더 중요하다. 한 개의 화면에서 각자 원하는 설명내용이 다른 요구를 어떻게 담을지도 중요한 고민 포인트이다. 각 작업자용으로 기획서를 분리해 작성하는 것도 방법이 될 수 있다. 그치만 내가 최초 기획한 정책이 100% 정답은 아닐 수 있으므로 (작업자들과 상의해 방향 변경 가능) 모두가 1개 기획서를 볼 수 있도록 최대한 모든 작업자에게 전달돼야할 요건을 꾹꾹 담아작성한다. 

그리고, 수정이 발생하면 하루에 3~4번도 기획서를 업데이트해 공유한다. 

나는 계속 본 내용이라 지겨워도 발빠른 업데이트로 작업자들이 방향을 잃지 않고 변경된 방향으로 옳게 작업해나갈 수 있게 다리를 놔줘야한다. 오늘 내가 업데이트하지 않은 정책으로 인해, 작업자는 과거 기획서로 작업을 하게될 수도 있어서, 프로젝트 병목을 줄이기 위해 내가 반드시 실천하는 원칙이다.

내 기획서만 설명충이 아니다. 내 입도 설명충이 된다. 

몇 개월 간의 프로젝트 기간동안 메신저/유선/줌/대면으로 20여명의 작업자들과 하루에도 수십번 컴을 하게 된다. 변경사항이 생기거나 정해야할 이슈가 발견되면 몇번이고, 여러 컴 수단으로 반복적으로 컴을 해서 부러뜨려야한다. 프로젝트 기간 동안 MBTI I인 나는 그 누구보다 열정적인 I가 된다. 정책을 정하기 위한 토론을 하거나, 방향성을 설파하거나, 동기부여를 위한 격려를 하기도 한다. 어쩔 수 없이 손으로도 입으로도 설명충 생활을 하게 되면서 달변가가 되고 컴 스킬은 늘어나게 된다. 이게 어쩌면 PM으로서 장점?이 될 수도 있겠다 싶다. 

회사에게도 설명충이 돼야 하는 것 같다.

최초 프로젝트를 착수할 때부터, 진행중, 출시 이후까지 계속 회사에게(주로 높은 분) 도움을 구하거나, 성과를 보고하기 위해서도 지속적인 설명충이 돼야한다. 물어보기 전에 상황을 공유하고 문제를 지적받기 전에 미리 대처하고 선빵을 날려야 내 프로젝트를 지킬 수 있다.