좋은 백엔드 개발자, 그리고 이해관계자
저번 글과 이어서 이번에는 백엔드 개발자에 대해서 이야기해보려고 한다.
1. 백엔드 개발자
pm의 일이 익숙하지 않았을 때 백엔드 개발자가 왠지 모르게 좀 어려웠다. 만들어진 기능을 화면을 보면서 이야기할 수도 없고 내 기준에서는 내가 지금 만들려는 기능 UX보다 문제 되는 상황이나 시스템적 관점으로 대화를 나누기가 쉽지 않았다. 하지만 한 백엔드 개발자를 만나고 생각이 달라졌다.
첫째,
백엔드 관점의 UX
좋은 백엔드 개발자라고 하면 당연히 엔지니어적인 능력이 최우선시되어야 하지만 내가 만난 백엔드 개발자는 사용자의 문제를 깊게 이해하려고 하고 디자이너와 프론트 개발자가 만드는 화면 흐름도 같이 커뮤니케이션하며 개발을 진행했다. 백엔드 개발자가 화면의 흐름을 알고 사용자의 문제를 깊게 공감했기 때문에 비즈니스 적인 관점과 UX의 관점 그리고 프론트 개발자가 겪는 어려움까지 이해하여 프론트 개발자의 개발 속도가 빨라지고 무엇보다 QA 테스트(내가 있는 조직은 크기가 작아 pm이 테스트를 직접 진행한다)에서 문제 되는 부분도 적었다.
지금 생각해 보니 그 백엔드 개발자가 사용자의 UX를 상상하면서 api를 설계하고 나에게는 UX 관점으로 말해주고, 그 관점으로 백엔드와 프론트 사이의 개발 스코프를 정하거나 효율적인 의견 조율이 됐던 것 같다.
기술적 코드 품질, 설계보다는 제품적인 관점과 사용자 중심적인 관점으로 대화할 수 있어 동료로서의 안정감도 있었다. 그리고 무엇보다 백엔드 코드를 UX를 결합시켜 이야기해 줘서 이제 백엔드 개발자가 더 이상 어렵지 않아 졌다.
둘째,
일단 만들고 보여주는 개발자
백엔드 개발자들이 테스트하는 걸 봤었는데 그들의 창에는 "True, False, Success, Fail, Null" 같은 응답 값만 보면서 개발을 하는 걸 봤다. 값을 보고 개발을 하다니 신기하기도 하고 저걸로 개발이 되다니 대단하기도 했다.
그러다 위치데이터를 이용한 웹소켓 개발을 진행한 적이 있는데 사용자의 케이스와 위치 케이스가 정말 너 무무 많아서 어떻게 정리하지 막막할 때가 있었는데 한 백엔드 개발자가 일단 자신이 생각하기에 맞다고 생각하는 UX로 쭉 만들고 다시 내가 하나씩 테스트해가면서 UX를 맞춘 적이 있었다.
당연히 그 개발자는 두 번 코딩을 한 부분도 있지만 개발 시간은 정말 반이상이 단축이 되었다. 만약 내가 케이스들을 다 생각해서 정리하고 그걸 다시 개발했었으면 이 속도는 나오지 못했을 거고 내가 상상할 수 없는 걸 결정해서 만들어 달라고 하면 커뮤니케이션도 지금처럼 매끄럽지 않았을 것이다.(시스템적인 동작을 정리도 못했을 것 같다)
일단 개발자가 만들고 보여준 다음에 같이 고치자고 해주는 것 자체가 pm의 시간을 줄여주는 일이었고, 사이즈가 큰 일을 할수록 이 개발자를 찾으면서 많이 의지 했던 것 같다.
2. 이해관계자
PM의 일과 관련된 책을 읽어보면 이해관계자라는 말이 많이 나온다.
이해 관계자 Stakeholder(스테이크홀더)란 무엇일까? 아는 사람도 많겠지만 내가 생각하는 이해관계자는 내가 만들고 관리하는 제품이 변경됐을 때 영향을 받는 모든 사람이라고 생각한다.
제품이 바뀌었을 때 그걸 사용자와 커뮤니케이션하는 운영팀, 제품을 파는 세일즈팀, 그리고 제품의 전략과 방향을 설정하는 C레벨 모두 이해관계자이다.
이해관계자와 PM의 사이는 서로를 이해하고 존중하고 도움 받는 사이라고 생각한다. 제품팀은 제품을 만들고 그 제품을 운영하고 그 제품을 팔러 다니는 사람이 각자의 상황이나 서로를 존중하지 않는다면, 불균형이 일어나 서로를 탓하고 그 제품은 좋은 비즈니스 성과를 낼 수 없을 것이다.
그래서 PM은 이해 관계자들의 이슈나 그들의 업무를 이해하고 있어야 하고 제품의 변화에 그들이 놀래지 않게 가끔은 예고편으로 가끔은 PT로 이해관계자들이 제품을 이해할 수 있도록 노력해야 한다. 물론 이해관계자들도 PM에게 똑같이 자신들의 업무를 알려주고 싱크를 맞추는 게 중요하다.
이게 잘 되려면 이해관계자들이 PM에게 편하게 찾아올 수 있도록 환경을 만들어주는 게 가장 중요하다.
제품은 혼자 만드는 게 아니라 팀과 함께 만드는 것이다.
좋은 디자이너, 좋은 개발자, 좋은 이해관계자도 중요하지만 여기서 가장 중요한 건 이런 문화를 만들고 그들을 좋은 메이커가 될 수 있도록 끌어낼 수 있는 PM의 에너지가 가장 중요하다고 생각한다.
