[아티클 읽기] 2년차 PM의 하루

https://brunch.co.kr/@leesy0203/5

2년차 PM의 하루

 

오전

1. 하루 시간표 짜기

• 오늘의 미팅, QA, 배포 일정 확인
• 관리가 필요한 회색 지대도 확인
• [소통이 중요한 협업] , [집중이 필요한 기획]
• 하루의 그림을 그려보는 것이 업무 안정성에 큰 도움

2. 배포건 현황 분석하기

• 지난 주 배포한 기능 / 실험의 데이터를 확인하고 분석
• Hackle (A/B 테스트)
• 아침마다 루틴으로 현황 분석을 하는 주 목적은 ‘배포 건의 임팩트를 촘촘하게 체크’ , 가끔은 로깅 오류나 가드레일 지표의 악화 등 위험 신호를 찾아내기도 함. 문제가 악화되기 전에 기능 수정 요청을 빠르게 할 수 있음

3. 기획서 작성하기

• 정책 문서
• 제작 요청 문서
• 업무 단위가 테스크인 경우는 바로 제작 요청 문서부터 작성하기도 하지만 새로운 기능 도입 관련 업무이거나 여러 테스크가 얽혀있는 프로젝트 단위의 업무라면 정책 문서에 상당한 시간을 할애함
• 제작 요청 문서의 경우에도 어떤 문서냐에 따라 작성법을 조금씩 달리하는데 디자인 요청 문서의 경우 기획 의도는 최대한 핵심만 작성하고 기획 배경에 참고된 자료를 문서에 첨부
• 디자인에 대한 ‘제안’을 작성하되 어떤 부분에서 디자이너의 주도적인 결정/조언이 조금 더 필요한 내용인지 언급 → 문서는 간결하게 작성하고 같이 화면을 보며 구두로 논의하는 시간이 더 긴 편
• 개발 요청 문서의 경우 백엔드, 프론트엔드, 로그, 실험 세트 연결 로 구성된 요청 문서를 작성
• 기획서 작성 중 여러 유관 부서 간 합의나 인지가 반드시 필요한 내용이 나오면 기획서 공유 미팅 일정을 잡음

4. 실험 세팅하기

• 대부분의 배포건에 모두 A/B 테스트 진행
• 실험 가설에 맞춰 실험 설명 문구, 지표(성공 지표, 가드레일 지표, 보조 지표) 선정
• 엔지니어가 실험 세트를 연결할 수 있도록 실험 Key를 전달하고 지표에 대한 피드백이 필요한 경우 Business Analyst 에게 실험 링크를 공유한다
  • 가설 입증에 참고할 만한 추가 지표 또는 해당 실험군의 매출 기여도를 판단할 수 있는 보조 지표를 제안해주시기도 함

오후

1. 주간 회고 미팅

• ‘이런 데이터는 매일 체크합시다’ 라고 정한 스쿼드 별 대표 지표의 주간 추이를 보고 특이사항은 없었는지 검토
• 지난 주 배포 건의 액션 로그를 함께 보며 지표 변화가 어떤 요인의 영향으로 말미암아 발생했는지 추론
• 지난 액션의 영향력을 파악해 러닝을 쌓고 그 러닝을 어떻게 확장해 나갈 것인지를 논의

2. QA 및 배포 공유

• 기획서 작성하며 확인했던 중요 path 중심으로 테스트 케이스별 QA 진행
• 제작한 기능에 오류는 없는지, 의도했던 바가 정상적으로 구현되었는지 확인하는 과정
• 배포 후 발견될 수 있는 에러에 기민하게 대응하기 위해 QA 완료 시각이 퇴근 직전인 경우 실배포 시각을 다음날 오전으로 조정하기도 함
• 배포가 완료되면 유관 부서를 태그해 각 부서나 스쿼드에서 지표 해석시 참고할 수 있도록 함

3. 밍글링

• 실패하든 성공하든 ‘후회없이 해봤다’ 라는 느낌과 ‘00을 배웠다’ 라는 러닝이 쌓일 수 있게 모두를 합심시키도록 노력하는게 더 의미있다고 생각
• 합심의 기반은 유대감 → 구성원들과 다른 층 간식도 같이 먹으러 가고 종종 점심도 같이 사먹고 시시콜콜한 일상 이야기를 하기도 함

 

인사이트

• 나도 하루를 시작할 때 꼭 계획표를 짜는 편인데 회사를 다니면서도 이런 습관은 계속 가져가면 좋겠다는 생각을 함
• 기획자의 하루를 가까이서 지켜본 것 같은 느낌이 들었다. 회사 다닐 때도 느꼈던 부분인데 기획자는 정말 바쁘다
• 리더라면 설령 후에 틀린 방향으로 밝혀지더라도 구성원 모두가 한 방향을 보고 집중해서 달릴 수 있도록 도와야한다는 말이 인상적이었다. 언제나 옳은 결정만 할 수는 없기 때문에 .. 이번 의사결정에서 무엇을 배웠는지 어떻게 나아가야하는지 정하는 것도 PM의 역량이라고 생각한다