[PM,PO] 일정관리법

잘 알려진 IT 프로젝트 방법론으로 

워터폴/에자일방법이 있습니다. 

 

워터폴 방식 : 프로세스에 따라 단계적으로 구현하는 방식 

에자일 방식 : 최소단위 제품(MVP)을 빠르게 출시해서 고객 피드백을 바탕으로 제품을 개선하는 방식

 

프로젝트 성격에 따라서 워터폴이 적합한경우/ 애자일이 적합한경우가 있습니다

 

금융 플랫폼, 운영체제와 같이 한번에 완제품을 출시해야 하는 경우- 워터폴 방식 적합

고객을 사로잡아야 사업의 성패가 결정되는 프로덕트의 경우 - 애자일방식 적합 

 

EX) Backlog 

1. 경영진과 커뮤니케이션에서 나오는 Roadmap

2. 개발하다 나오는 내부이슈, 기술부채 

3. 고객 요구사항

-> 전체적인 일정관리 

 

cf) 많은 회사들이 Atlassian JIRA 로 Task 를 관리하고 Confluence를 wiki로 이용하지만 

다르게 Notion과 Asana를 사용할수 있습니다. 

- 빠르게 출시하다보면 -> 기술부채가 존재할수있습니다.

 

Asana에서 

이 단계에서 발생하는 모든 task들은 Inbox에 정리하고

검토필요한것 -> Pending에 올려서 정리(정리,분류,그룹화)

 

product 관련한 모든 요구사항은 backlog에서 관리하게됨 

요구사항을 작업을 할수있는 형태로 변이시키는것이 pending단계 (정리, 분류, 그룹화)

- Inbox에 모든 요구사항들을 담고있음 

=> 새로운 스프린트로 만들기 

 

- Ready단계에 정리된 task 모아둠 

-Asana의 weekly라는 공간에 진행중인 업무들을 정리함 

=> 무슨일 하고있는지 한눈에 파악하기 쉽다 

- 모든 우선순위는 목표에 의해서 결정함 

PM이 되면 어려운점 중하나  -> 여기저기서 요구사항 발생 / 우선순위 정하기가 어려움 

백로그 요구사항 -> 목표에 대입 -> TASK를 만들어서 관리

- 기간이 있는 TASk를 sprint로 보고있음 (평균2주, 1주~1달경우도 있음 ), 기간을 유연하게 관리

- sprint 만들때 옆에 왜하는지 같이 명시 

- 추천 로직 ( 빠르게 생성-> 코드 불안, 확장성 떨어짐) => 기술부채 해결, 유연성 확대 

=> 확장성 고려 

- 급하게 진행된느거 (operation section = ops)에 작성관리 (20%)

=> 미룰수도 있음 ( 항목으로 sprint를 만들어서 작성가능) 

- sprint에 가급적이면 업무비중 80% 유지 

 

 

회고(피드백을 주고받는 문화) 

sprint가 끝나고나면 sprint에 참여했던 멤버들이 

 

1) 각자 잘한점/개선할점 각자정리 ( 이때 상대눈치보단 무조건 1개라도 개선점 적는게 중요) 

2) 회고 미팅( 내용 한번더 정리) 

3) 최종 정리(최종적으로 회고미팅에서 나왔던 이야기들을 다 정리해가지고 전사적으로 공유함 

 

 

참고>유투브 기획자 데이먼