[주니어 PM의 협업 2편] 프론트엔드/백엔드 개발자
feat. 여러분 안 계시면 전 아무 것도 아니에요..
세 편에 걸쳐, PM으로서 자주 협업하게 되는 직군과의 업무 경험과 배운 점을 기록하고 있습니다. 이번 글에서는 프론트엔드 개발자, 백엔드 개발자와의 협업으로부터 배운 점을 써보려고 합니다. PM, 브랜드 마케터, 프로덕트 디자이너와의 협업 경험은 이전 글을 찾아주세요.
01. 프론트엔드 개발자
프론트엔드 개발자가 갖고 있는 사용자 경험 (UX) 에 대한 관심과 그것을 구현하기 위한 방법에 대한 지식을 잘 이끌어내는 것이 중요하다고 생각합니다. 그래서 구현하고 싶은 to-be 뿐 아니라 그 화면의 의도나 중요도에 대한 설명을 덧붙이려고 노력합니다.
컴포넌트별 역할과 데이터 참조의 구분 명시예전에 이런 경험이 있었습니다. 중요한 기능을 만들어야 하는데 제작 일정도 타이트했고 그 기능의 실효성부터 검증해야 해서 리소스 투입을 최소화해야 했습니다. 그래서 제가 생각하기에 가장 ROI가 높을 만한 방법을 선택해 제품 스펙을 보수적으로 산정했습니다. 제작요청을 위해 프론트엔드 개발자와 이야기하던 중, 실험의 중요성에 크게 공감한 개발자 동료가 (제가 검토했던 여러 제작 방식을 보시더니) '방식 B가 조금 더 시간이 드는 건 맞지만 지금 제안해주신 방식과 리소스 차이가 대단히 크지 않기도 하고, 이게 플로우가 좀 더 자연스러운 것 같은데 방식 B로 가보는 건 어떨까요?'라며 제작방식 변경을 제안했습니다. 그 덕분에 좀 더 완성도 높은 안으로 실험을 진행할 수 있었습니다. 제가 PM으로서 스스로 리소스 산정을 더 정확하게 해야 하는 것도 분명 있겠으나, 결국 이 분야의 전문가인 동료의 역량을 이끌어내고 보고 배우는 것도 중요하다는 것을 새삼 느꼈던 경험입니다.
프론트엔드 개발자는 디자이너와 화면의 생김새를 논의하고, 백엔드 개발자와 화면 내 기능에 대해 논의합니다. 순수 제작 외에도 업무 소통이 잦은 직군입니다. 이 소통 비용을 효율적으로 관리할 수 있도록 PM이 신경쓰는 것이 중요하다 생각합니다. 그래서 사소하지만- 비슷한 논제가 여러 미팅에 걸쳐 논의되지 않도록 논제를 통합해 미팅 일정을 조율하고 & 적시에 소통할 수 있도록 각 직군으로부터 일별 블로커를 수집하는 방식을 시도해보고 있습니다.
일별로 수집하는 블로커, 그리고 블로커 해결차 소통 조율했던 예시02. 백엔드 개발자
첫 협업이 참 떨렸던 직군이 바로 백엔드 개발자입니다. 백엔드 개발자가 일하는 방식에 대해서도 잘 몰랐고, 그래서 PM으로서 어떻게 업무 과정을 이끌어야 하는지 잘 몰랐기 때문입니다. 그래서 업무 과정을 자주 구경(?)하기도 했고 책이나 강의로 지식부터 쌓으면서 다가가려고 노력한 직군입니다. 백엔드 개발자와의 협업에서 중요한 것은 '각 제작건이 전체 시스템에 미치는 영향을 파악하는 것'이라고 생각합니다. 눈에 보이는 1의 변화를 위해 뒤에서 100의 일들이 돌아가고 있기 때문입니다. 그래서 문서화에 특히 더 신경쓰려고 합니다.
문서를 작성하는 행위 자체에서 뿌듯함을 느끼지 않으려고 했습니다. (사실 무엇 하나 정리되어 있지 않은 대혼란 하루를 거친 후에, 잘 작성된 문서를 보면 내 자식처럼 약간 뿌듯하긴 합니다) 결국 이 문서를 보고 실제 작업에 착수할 백엔드 개발자가 어떤 관점으로 이 문서를 해석할지 생각하며 여러 문서 형식을 시도해보았습니다. 그 과정에서 백엔드 개발자들이 작성하는 API 문서를 읽게 되었고, 제작요청건을 개발자가 해석하는 기능 단위로 치환하는 것이 필요하다는 것을 느껴 단위 기준을 비슷하게 가져가보려고 했습니다. 그래서 최근에 로직 개발요청 문서를 작성할 때에는 (1) 주체-액션-객체가 한 쌍으로 묶이는 것을 기준으로 로직 단위를 구분하고 (2) 각 로직에 대해 검증 조건 및 조건 통과 성공/실패 케이스에 대한 발생 효과를 명시하는 형식을 사용합니다. 예외 케이스를 풍부하게 생각하는 데에도 도움이 되고, 백엔드 개발자 동료들이 기획서 해석보다 설계에 좀 더 집중할 수 있도록 하는 데에도 도움이 되었다 판단해 앞으로도 이 방식을 좀 더 발전시켜보려 합니다.
검증 조건 및 조건 통과시 효과 명시, 신규 테이블 기획서 일부의 예시그리고 ERD나 테이블 명세에 대한 공부를 하면서 우리 제품의 데이터 구조를 파악하는 것이 정말 중요합니다. 저희 팀에서는 데이터 / 로그 설계와 관련된 업무도 백엔드 개발자와 협업하고 있는데요. ERD에 기반해 정책을 설계하는 것이- 꼭 필요한 데이터가 누락되지 않도록 기획 문서를 보완하는 데에도 도움이 되고, 데이터 활용을 고려해 테이블 구성에 대한 의견을 드리는 데에도 도움이 됩니다. 더불어 테이블과 컬럼명을 활용해 제작요구사항을 더 명확하게 작성할 수도 있습니다. 아주 간단한 예시이지만- '제품 이름 변경'보다 'product.display_name 변경'이라고 명시하는 것이 불필요한 혼란을 방지하는 것처럼요. 그리고 사람 마음이라는 것이- 배우고 물어가며 더 잘 하려고 하는 사람에게는 잘 알려주고 싶은 것이 당연합니다. 특히 백엔드 개발자가 하는 일은 드러나지 않는 곳에서 핵심 역할을 수행하는 경우가 많기 때문에, 그 문을 먼저 찾아가 열어보는 동료를 더 큰 마음으로 반가워해주시는 경우가 많다고 느꼈습니다. 얼마나 중요한 역할인지 잘 알고 있고 그래서 더 잘 이해하고 싶다는 마음을 적극적으로 표현하는 것이 말랑말랑한 소통에도 도움이 되었던 기억이 있습니다.
원래 두 편에 걸쳐 작성하려고 했던 글이 조금 길어졌습니다. 다음 편에서는 CX, QA와의 협업 경험을 기록할 예정입니다.
