PM과 개발자 사이 커뮤니케이션 갭 줄이기

 

"이거 금방 되는 거 아니에요?"라는 말을 PM이 하는 순간, 개발자의 표정이 굳는 걸 몇 번이나 봤습니다.
저도 예전에 이 말을 자주 했었고, 지금 생각하면 왜 그 말이 그렇게 문제였는지 뒤늦게 이해하게 됐어요.
PM과 개발자 사이의 갭은 능력 차이가 아니라, 서로 보고 있는 정보의 종류가 다른 데서 시작되는 경우가 훨씬 많았습니다.

 

PM은 화면과 사용자 경험을 기준으로 난이도를 가늠하고, 개발자는 코드 구조와 기존 시스템과의 연결을 기준으로 가늠합니다.
저희 팀에서 있었던 일인데, "상품 상세 페이지에 최근 본 상품 목록 추가"라는 요청을 제가 "그냥 목록 하나 더 보여주는 거니까 간단하겠다"고 생각했어요.
그런데 개발팀 입장에서는 최근 본 상품을 저장할 저장소를 정하고, 비로그인 사용자는 어떻게 처리할지, 목록이 몇 개까지 쌓일지, 오래된 기록은 언제 삭제할지까지 다 설계해야 하는 작업이었습니다.
겉으로 보이는 화면은 목록 하나였지만, 그 뒤에는 제가 안 보이던 결정들이 쌓여 있었던 거죠.

이 사건 이후로 저는 새 기능을 요청할 때 "이게 왜 간단해 보이는지"를 먼저 말하지 않기로 했습니다.
대신 "이 기능이 다루는 데이터가 어디서 오고 어디에 저장되는지"를 개발자에게 먼저 물어보는 습관을 만들었어요.
질문을 바꾸는 것만으로도 대화의 질이 달라지더라고요.

 

또 하나 자주 겪었던 문제는, 회의에서는 합의된 것 같았는데 나중에 티켓을 보면 서로 다르게 이해하고 있었던 경우입니다.
저희는 이 문제를 줄이려고 회의가 끝나면 그 자리에서 바로 티켓 초안을 같이 보면서 5분 정도 확인하는 시간을 넣었어요.
"회의에서 이렇게 말했으니 알아서 정리해서 올리겠다"가 아니라, 회의 끝나기 전에 화면 공유로 티켓을 같이 채워보는 방식입니다.
이렇게 하니까 "아, 저는 이 부분은 다음 버전이라고 생각했는데요"라는 이야기가 회의 중에 바로 나와서, 나중에 다시 만나서 재조율할 일이 크게 줄었습니다.

 

PM이 쓰는 용어와 개발자가 쓰는 용어가 미묘하게 다른 경우도 많았어요.
저는 "완료"라는 말을 사용자가 최종적으로 확인 가능한 상태로 썼는데, 개발자는 "완료"를 코드가 머지된 상태로 썼습니다.
"버그"라는 말도 저는 기획 의도와 다른 모든 것을 버그라고 불렀는데, 개발자는 명세에 없던 동작은 버그가 아니라 "미정의 동작"이라고 구분해서 불렀어요.
이 미묘한 차이 때문에 "버그 다 고쳤다고 했잖아요"라는 오해가 몇 번 생겼습니다.
결국 팀 위키에 자주 쓰는 용어의 정의를 짧게 정리해서 붙여놨어요.
용어집이라고 하면 거창하지만, 사실 A4 반 페이지도 안 되는 분량이었는데 이게 있고 없고의 차이가 컸습니다.

 

개발자가 "이건 기술적으로 어렵습니다"라고만 말하면 PM은 다음 액션을 잡기가 어려워요.
저는 이럴 때 "어떤 부분이 어려운지 화면 흐름 기준으로 설명해줄 수 있나요"라고 다시 물어보기 시작했습니다.
한 번은 "실시간 재고 반영이 어렵다"는 말을 이렇게 풀어서 들었는데, 알고 보니 재고 데이터가 세 개의 다른 시스템에서 오고 있어서 하나로 합치는 데 시간이 걸린다는 이야기였어요.
이 설명을 들으니 저도 "그럼 우선 재고 데이터가 통합되는 재고관리 시스템 하나부터 실시간으로 반영하고, 나머지는 다음 단계로 미루자"는 식으로 스코프를 조정할 수 있었습니다.
기술적 제약을 그냥 "안 된다"로 받아들이지 않고, 왜 안 되는지를 기획 언어로 다시 번역해서 들으면 대안이 보이는 경우가 훨씬 많았어요.

 

마지막으로 효과가 컸던 건, 격주로 30분씩 "개발팀이 요즘 신경 쓰는 기술 이슈"를 PM에게 공유하는 자리를 만든 것이었습니다.
거꾸로 저도 "요즘 사용자들이 어떤 불편을 겪고 있는지"를 개발팀에 공유하는 자리를 만들었어요.
이 자리가 생기고 나서부터, 개발자들이 기술 부채를 이야기할 때 왜 그게 사용자 경험에 영향을 주는지를 스스로 연결해서 말하기 시작했고, 저도 기능 요청을 할 때 기술적으로 무리한 요구를 미리 걸러낼 수 있게 됐습니다.

PM과 개발자 사이의 갭은 완전히 없앨 수 있는 게 아니라고 생각해요.

서로 보는 관점이 다른 건 당연하고, 그 다름이 오히려 서비스를 더 다각도로 보게 만드는 힘이기도 하니까요.
다만 그 다름 때문에 생기는 오해는 최대한 줄이는 게 PM의 역할이라고 생각하고, 요즘도 계속 이 방법들을 다듬어가고 있습니다.