팀스파르타 PM과정 (25)

아티클 카타, 강의완강, 과제 개요 정하기 

---

1. 아티클 정보

• 제목 : 개발자가 생각하는 좋은 PM 나쁜 PM (링크)
• 작성자(저자) : 배민공통프로덕트실 김영한님

2. 핵심 내용 요약

• 이 아티클의 주요 메시지 : 
• 핵심 키워드 :  좋은 PM, 나쁜 PM 

3. 흥미로운 점/새롭게 알게 된 점

• 읽으면서 가장 흥미로웠던 부분 : 
  • 동기유발하는 PM
    • 내가 고민하고 생각해낸 일은 나의일이 된다. 고민을 나누면서 같이 고민한 사람의 일로 만들기
    • 개발자에게 문제를 공유하면 개발자는 문제해결을 하려고 같이 머리를 써준다 
    • 이 일을 왜 해야 하는지, 어떤 고객/비즈니스 가치가 있는지를 집요하게 설명하여 개발자를 납득시켜줌
    • 개발자가 의견을 내고 피드백을 줄 수 있는 창구를 열어두어, 개발자 스스로 프로젝트를 '나의 일'로 느끼고 적극적으로 참여하게 만든다
    • 인간적인 유대를 제공하는 PM에겐 개발자와 상호소통의 벽이 많이 낮아진다 
    • 프로그래머는 문제를 풀고싶어하고 인정받고 싶어 하기때문에 '고민있어요' 단어 하나로 강력한 유혹을 할수있다 
    • 업무를 독단적으로 하는것보다 상의하며 상대방을 참여시키게 만든다 
    •  
  • 깊이있는 정책이해를 하는 PM
    • 자신이 담당하는 도메인과 서비스 정책의 뼈대를 완벽하게 파악하고있다.
    • 정책을 깊이 이해하고 있어야만 근본적인 서비스 개선이 가능하며, 주변 시스템과 어떻게 엮여 있는지 넓은 시야(넓이와 깊이)를 갖추는 것도 중요
  • 개발시스템을 대략적으로라도 알고있는 PM
    • 개발시스템을 조금이라도 이해하려고 해야한다 
    • 코딩을 직접 할 필요는 없지만, 시스템 관점에서의 업무 프로세스 및 데이터 흐름은 파악하고 있어야한다. 
    • 복잡한 시스템을 '네모 박스'로 도식화하여 각 시스템의 역할과 어떻게 연동되는지 큰 얼개를 이해하고 기획을 해야한다
    • 개발자와의 대화를 이해하려면 시스템에 대한 이해가 있어야한다 
• 이전에는 알지 못했거나 새롭게 배운 내용 : 
  • 숙련된 PM은 먼저 완벽하게 정리해서 보기좋은 결과물을 가져가야한다고 생각하곤했는데 일부러 답을 정해놨어도 가서 상의하고 상대방을 업무에 편입시켜서 동참시키는 노하우가 유쾌하기도 하면서도 사실 정말 그 지점을 잡기 어렵다는 생각도 동시에 들었다. 
  • 커뮤니케이션이 가장 중요한 핵심 역량인 만큼 다양한 직종의 특징을 이해하고 잘 이용해먹을 수있는 방안을 고민해야한다고 느꼈다 

4. 나의 한 문장 요약

• 이 아티클을 한 문장으로 요약하면? 
  • 개발자에게 당근을 쥐어주는 법

 

---

숙련 강의 

PRD 요소 

- 기능 이름

- 기능 설명

- 우선 순위

- 구현 기준

- 프로젝트 개요 ( 목적, 목표, 주요 기능, 타겟 사용자를 간단하게 설명)

- 서비스/제품의 배경

- 우선순위 및 릴리즈 계획 (MVP를 고려하여 중요한 기능부터 개발)

-기대되는 결과물 및 성과

 

주의사항

- 명확하고 구체적인 요구사항작성

- 우선순위 설정과 범위 관리

 

IA (정보구조도)

어떤 정보를 어디에 배치하고 연결할지 설계하는 작업

- 일관성 있는 방향 설정

- 효율적인 협업과 커뮤니케이션 촉진

-법적 및 규제준수

 

작성방법

- 목적 정의 > 핵심 방향성 정리 가능

- 적용할 정책 범위 정리 

- 주요항목 및 세부사항 작성

- 정책 문서화 및 공유

- 정기적인 검토 및 업데이트 

 

---

과제 방향성 잡기 

 

---

개인 역기획 진행 흐름 잡기