처음으로 내가 기획 DRI를 맡아서 진행하게 되었다. 당연히 실제 제품 UI나 신규 기능 등은 아니고 백오피스 성격에 가깝다.

크게 한 일은 다음과 같다.
[1] 데이터 팀과 소통하고 현재 방식 파악하고 (일부)자동화가 가능한 구조인지 파악하기. 기술적 문제, 우려하는 부분, 사용되는 리소스 파악하기
[2] 현재 서버 동작방식 확인하기. 데이터팀, 서버, 프론트 구조에서 서버 구조를 구체적으로 알아야 확인이 가능했다. 오늘은 상황상 내가 직접 코드를 확인하면서 이 기능이 가능한건지 기술적 검토를 했다. 그리고 우려되는 부분이나 구조적으로 궁금한 부분을 질문했다.
[3] PRD 및 다양한 문서를 작성했다. 특히 다른 팀 동료도 비슷한 고민을 하고 있어서 서로 생각하는 방향을 파악했다. 그런데 파고들면 파고들수록 너무 백엔드의 깊은 영역으로 넘어가서 적당한 선에서 문서를 마무리했다.

잘한일

• [1] 데이터 팀과의 소통은 잘 한 것 같다. 특히 현재 기능에 대한 구체적인 방식과 전체 플로우, 리소스 등을 파악한게 좋았다. PM도 개발적인 업무를 해야할 때가 있다. 그리고 지금은 그 소통이 필요한 경우였던 것 같다.
• [2] 사실 이건 서버개발자의 영역일지도 모른다. 하지만 내 경험상 PM도 개발적인 ideation 정도는 한다. 그리고 나는 얕은 서버 지식이 있는 프론트 개발자라서 조금 더 구체적인 솔루션까지 낼 수 있었다. 물론 최종 결정권자는 내가 아니고 백엔드 개발자다.
• [3] 문서를 그래도 몇 개 만들어 두어서 이후 작업하는데 도움이 될 수 있을 것 같다.

아쉬운점

• [2] 개발자가 대표인 경우, 개발자가 pm인 경우 불필요하게 관여를 해서 더 안좋은 결과를 내기도 한다는 얘기를 들었다. 지금 내가 하고 있는게 너무 많은 관여를 하는걸까? 라는 생각도 들었다. 처음부터 그게 걱정되어서 한번 싱크를 맞췄지만 내가 잘 한지는 모르겠다. 사실 이건 회사by회사, 팀by팀이라서 뭐가 정답이라고는 할 수 없을 것 같다. 중요한건 이후에 커뮤니케이션을 통해 싱크를 맞추고 목표를 향해 도착할 수 있게 도움을 주는 정도인 것 같다.
• [3] 너무 개발자스러운 문서를 작성했다. 뭐 내가 pm이나 기획자가 될 생각은 없긴한데, 그래도 기획 문서라기엔 개발에 매우 치중된 문서다. 이후에 피드백을 받아보면 좋을 것 같다.