PM에게 가장 필요한 것? #3. 질문충
#3. 질문충
[경고] 이 글은 개인의 성향이 몹시 반영돼있어, 공감이 어려운 분들이 있을 수 있습니다.
왜 저 사람이 저 이야기를 하게 되었는지를 이해해야 한다.
프로젝트 참여자들 각자 고민하는 지점이 조금씩 다르다. 프론트엔드는 화면을 개발하는 과정에서 개발효율이 좀더 좋은 방안을 가장 좋은 정책이라고 생각할 수 있고, UX는 프론트엔드나 백엔드 개발의 작업공수와는 상관없이 사용자 동선이 효율적인 게 가장 좋은 정책이라고 생각할 수 있다. 기획은 서비스지표나 매출 등 실적이 좋을만한 정책이 가장 좋은 것이라고 생각할 수 있다. 그래서 같은 아젠다에 대해서도 서로 의견이 쉽게 나뉜다. 이럴 때 나는 가장 먼저 각 당사자들이 지금 어떤 고민때문에 저 방법을 강하게 어필하는지를 파악하려고 한다. 그걸 파악하고 나면 조율의 실마리가 보인다.
난 독심술은 없기때문에 그들이 왜 저 방법을 최선으로 정하게 되었는지 알기 위해 질문을 굉장히 많이 한다. 질문은 메신저, 줌, 대면을 가리지 않고 계속된다. 이렇게 문답과정을 거치면 해당 사안뿐 아니라, 그 작업자의 성향도 파악할 수 있게 된다. 작업 효율/사용성이 좋은 방향을 적극적으로 고민하는 작업자도 있고 가능한한 기획의 정책에 따르는 작업자도 있다. 그 작업자가 어떤 스타일인지 알게되면 이후 협업할 때에도 도움이 된다.
사이드이펙트를 챙기는 건 PM의 몫이다.
개발이 어느정도 진행된 상태에서 정책 변경이 발생하는 순간은 모두가 원치 않지만 반드시 발생하는 상황이다. 이 상황에서는 BEST대안을 찾는 것도 중요하지만, 이미 개발된 부분에 사이드이펙트는 없는지를 꼼꼼히 점검해서 그 부분을 최소화하는 일이라고 생각한다. (프로젝트 출시일은 정해져있으므로) 물론 개발자가 이 부분까지 고려해서 정책의견을 주는 경우도 많다. 하지만 보통 백엔드가 프론트엔드 영향도까지, 프론트엔드가 백엔드 영향도까지 면밀히 고려해서 제안을 하는 것은 현실적으로 쉽지 않다.
이 때 그레이존이 등장한다. 이 경우 PM이 나서서 중간에서 조율을 해야하는가? PM은 개발자가 아닌데 짧은 개발지식으로 끼어들어 정리하면 리소스상 비효율적이지 않은가? 어떤 면에선 맞고 어떤 면에선 틀린 얘기같다.
PM이기 때문에 해당 사안을 회피할 순 없다. 어찌됐든 PM이 끼어들긴 해아한다. 단, 개발이슈이므로 최종 결정하는 주체는 양 개발당사자들이 되어야한다. PM, 백엔드, 프론트엔드 함께 논의하여서 사이드이펙트를 점검하고 정해야한다. 이 사이드이펙트를 바닥까지 밝혀내려면 역시나 PM이 개발에게 긴밀하게 질문을 하고 점검할 필요가 있다.
포기해야 햐는 것, 포기할 수 없는 것을 밝혀내는 것이 프로젝트의 성공을 좌우한다.
프로젝트 기획단계에는 최선의 희망사항을 반영한 기획스펙이 정의된다. 그런데 진행이 되기 시작하면 대내/외적인 변수로 인해 최선의 스펙이 조금씩 어그러지기 시작한다. 이때부터 완벽주의 PM이라면 스트레스를 받기 시작하고 조금씩 멘탈이 무너져내린다. 나도 그랬다. 그런데 기한은 다가오고 있고 프로젝트는 앞으로 나아가야한다.
내가 체득한 방법은 이 프로젝트에서 KEY로 가져가야할 스펙이 무엇인지를 확실히 정하고 그것만큼은 사수하되 다른 것들은 유도리있게 타협하면서 진행하는 방법이다. 내가 지금 맡은 프로젝트에서 포기애햐 하는 것과 포기할 수 없는 것을 밝혀내기 위해서는 상위 의사결정권자의 의중을 잘 파악해야하고, 더 나아가 회사의 방향성도 잘 인지해 이와 얼라인이 돼있어야 한다. 그러려면 윗 사람, 회사에게 내가 생각하는 부분이 맞는지 문답을 해야한다.
