PM 비하인드스토리 - 멤버 간 이해관계 ?

# 2. 프로젝트 멤버들 간의 이해관계의 차이

 회사와 조직마다 차이가 있을 수 있다. 내가 소속된 조직에서의 이해관계에 대한 이야기를 정리해보려고 한다.

FE-BE

 어떤 조직은 프론트엔드 개발자와 백엔드 개발자 간의 구분이 없다. 우리 조직은 2개 조직이 분리돼있다. 프론트엔드가 백엔드를 호출해서, 백엔드에 저장된 값을 프론트에게 API로 전달해주어 화면에 출력하기도 하고, 프론트엔드에서 화면에서 인풋된 값을 백엔드에게 API로 전달해주어 DB에 값을 저장하기도 한다.

 

 이렇게 프론트엔드-백엔드 간에 서로 통신할 수 있는 API가 필요하다. 이 API를 백엔드가 설계하면 프론트엔드가 원하는 호출구조를 반영하지 않게 될 수도 있어, 프론트엔드에서는 이 API를 함께 논의해 확정하기를 희망한다. 백엔드는 본인들이 설계한 DB구조에서 좀더 편한 방법으로 프론트에게 값을 주기 위해 백엔드가 먼저 API를 설계하고 이것에 맞추어서 프론트엔드가 작업하기를 희망한다.

 

 물론, 이렇게 양쪽의 희망사항은 다르지만 잘 협의해서 수정을 해가면서 합을 맞추어 일을 한다면 좋지만 일정에 쫓기고 또 서로 성향이 다른 개발자들이 협업할 때 이 부분에서 의견이 틀어지면 프로젝트 내내 서로 티격태격하게 되기도 한다.

 처음에 FE-BE 간 API로 갈등 사건을 마주했을 때, PM인 내가 나서서 정리해주려는 태도로 임했다. 그런데 문제는 나도 잘 모르는 부분이 많을 수밖에 없어, 내가 정해주는 데에 한계가 있었다. 여러 번 시행착오끝에, PM으로서 API에 대한 최종 정책과 이슈는 꿰고 있돼, 구체적인 업무방향은 FE-BE 간 합의해 정할 수 있도록 가이드하는 것이 가장 바람직하다는 레슨런을 얻었다.

UX-기획

 어떤 조직은 기획조직 안에 UX파트가 포함돼있기도 하고, 기획자가 UX설계까지 꼼꼼히 가이드하는 경우도 있다. 우리 조직은 UX조직과 기획부서가 분리돼있다. UX정책을 정하며 일부 기획정책을 정하기도 하고, 기획정책을 정하며 UX정책을 정하기도 하는 등 롤이 겹치는 부분은 존재한다. 그러나 기본적으로 메인 롤을 담당하는 부서의 견해를 우선시하며 협업이 진행되는 편이다.

 UX부서는 사용자 동선 상 자연스럽고 편리한 것이 최우선 과제이고, 기획도 역시 그 부분도 중요하지만 트래픽과 매출 등의 과제들도 함께 고려하게 된다. UX는 순수히 이 동선이 더 편리하다는 관점으로 내놓은 사용자 시나리오가 기획 입장에서는 강조해야할 서비스 엣지를 약화시키는 것 같다고 판단되는 경우이거나, UX 입장에서 작성한 라이팅이 좀더 사용자 친화적인 어조이지만 기획 입장에서는 정보전달이 명확하지 않은 어조라고 판단하는 경우 등이 의견이 상충되는 지점이다.

 예전에는 기획의 의도를 관철시키기 위해 UX와 설전을 벌이기도 하고 굉장히 집요하게 컴을 했었다. 그러나, 사용성이라는 것은 매우 주관적이므로 절대적인 답은 존재할 수 없다는 사실을 깨닫게 된 이후로 최초 기획된 정책이 가장 최고의 것이 아닐 수 있다고 생각을 한다. 그러다보니 반드시 양보할 수 없는 부분들 외에는 UX의 방향성도 반영하고자하고, 검증이 필요하다면 A/B테스트를 통해 데이터로서 추후 의사결정을 하는 솔루션을 주로 선택하고 있다.