Product Insight (90) 썸네일형 리스트형 PM 내가 기획작성 순서 & 기획을 전달하는 순서 디자이너와 개발자의 숙련도와 연차에 따라서 달라집니다.[앱개발]정책문서 작성기획문서 작성기획문서를 1. 디자이너한테 전달 초안 요청 -> (반박자늦게) 백엔드 개발자와 기획내용 협의 통과하면 일정협의 WBS등.. 2. 앱개발자 마지막으로 전달 마지막: 전체공유 다시 한번 더 [웹개발]정책문서 작성기획문서 작성기획문서를 가지고 1. 프론트개발자와 이야기 2.디자이너와 위와같은 과정 . 3. 백엔드 개발자와 획내용 협의 통과하면 일정협의 WBS등.. 4. 프론트 개발자한테 픽스전달 마지막: 전체공유 다시 한번 더중요한건.. 백엔드 개발자와 이야기할 때는 PM으로서 하나의 기능과 정책에 대해서 해왔던 Context 를 공유해야한다. 그래야 일정을 측정할 수 있다. 디자이너는 경력이 있으면 좋다. 정책문서과 기획문서 차이 난 이렇게 함 개발로 치면 정책문서는 interface고 기획문서는 class임정책 문서에 포함될 경우:"동일한 쿠폰의 중복 발급 방지: 관리자는 동일한 쿠폰을 특정 사용자에게 중복 발급할 수 없으며, 시스템은 중복 발급 시 경고 메시지를 표시합니다."안되는걸 명시해서 쫌 더 느슨하게 작성해야하는 것 같기도?기획 문서에 포함될 경우:"관리자 페이지에서 동일한 쿠폰을 특정 사용자에게 발급할 경우, 중복 발급을 차단하는 로직을 추가합니다. 중복 발급 시 경고 메시지를 표시합니다."사용자는 어떤 기능을 어떻게~를 할 수 있다. 할수있다를 명시하면 편함 이건 대학교 때 배웠던 것 같은데, 아니면 사회초년생때 배웠거나 헷갈리네관리자는 ~를 할 수 있다. 정책 문서는 "왜" 중복 발급을 방지해야 하는지와 "무엇".. PM과 하인리히 법칙 (매니저와 구성원) https://namu.wiki/w/%ED%95%98%EC%9D%B8%EB%A6%AC%ED%9E%88%EC%9D%98%20%EB%B2%95%EC%B9%99 하인리히의 법칙큰 실수는 굵은 밧줄처럼 여러 겹의 섬유로 만들어진다. Les fortes sottises sont souventnamu.wiki늦게 퇴근 + 피곤 빠르게 짧게 요약해서 대충 적겠다. 매니저는 힘들다. 혼자 프로젝트의 '재난' 이 발생하지 않게 노력하는 존재다. (위에 나무위키 참고)혼자 리스크를 부담한다. --- 리더 탓, 무능력한 리더가 고생시킨다.병사가 아닌 장교에게 책임을 물어라 --> 이것 정말 맞는말이고, 내가 좋아하는 말이다. 장교는 구성원들을 적재적소에 배치해야하는 책임이 있고,구성원들에게 비전을 제시해야한다. 근데.. 일정관리와 트래킹 두개로 나뉜다. 근데 사실 모든 걸 완벽하게 할 수 없다. 내 자신 업무를 트래킹하고, (내가 남들하고 Relation 이 있으니깐 관계가 있는 업무들은 자연스럽게 트래킹이 됨),팀을 일정관리 한다. 평가용으로 트래킹하는건 또 일을 하나 더 만드는거여서 안하는 편이다. 사람마다 다른 프로젝트 매니징을 해야한다. 프로젝트 매니징을 효과적으로 하기 위해서는 팀원의 역할과 경험에 맞게 관리를 구분해야 한다.**1. 역할에 따른 관리 방식**- **SI 인력**에는 명확한 기간과 테스트 기간을 제공해야 한다.- **주니어 스타트업 인재**에게는 가이드를 제공하고, 일정 확인 및 상호의존성 관리, 그리고 향후 3개월치 계획을 공유하는 정도로 관리한다.- **시니어 스타트업 인재**에게는 업무 트래킹만 충실히 제공하며 자율성을 존중한다.**2. 업무 방식에 따른 역할 분리** - 코어 프로젝트를 담당할 인력과 - 세부 작업을 담당할 인력, - 양쪽을 모두 소화할 수 있는 인력을 구분하여 역할을 배분해야 한다.**3. 효율성 관리와 균형** - 사람을 다룰 때 최상의 효율을 뽑아내는 것이 목표이지만, 그 과정.. 개발자와 기획자의 린 스타트업 차이 밑에 처럼 하기가 정말 어렵다. 밑에 스케이트보드에서 킥보드는 된다. 킥보드에서 자전거를 만들 때, 미리 설계를 못했으니 때리고 부셔야한다. 자전거 만들 때, 오토바이에 해당되는 내용까지 미리 설계를 하면 백엔드 오버헤드가 발생한다.때리고 부쉬는게 고통스럽고 상처도 많이 받지만, 최단거리다. 개발자가 2->3을 갈 때, 화가 많이 난다.기획자는 2 ->3을 갈 때, 1->2 처럼 갈 수 있을거라 생각한다. 기존 것을 활용해서 이어붙이면 가능할거라 생각한다. 물론 가능을 하지만, 그것은 때려 부쉬고 다시 만드는 것 보다 더 어렵고, 개발자 입장에서는 그것을 기획자말 대로 선뜻한다고 선택했을 때 '감당'할 수도 '책임'을 질 수도 없다. 그러면 어떻게 해야할까? 내 인사이트는 다음과 같다. 1. 대.. IT 프로젝트를 버전별 관리(APP, WEB) 앱은 버전별로 관리해서 사실 관리가 쫌 잡히는 편이고 웹은 즉시 즉시 업데이트가 되니깐 사실상 기능을 모아서 배포하기가 어렵다. 근데 이 모든건 초기 프로덕트가 있냐 없냐가 가장 중요하다. 그리고 즉시 말을 했을 때 대응할 수 있는가 -> 그렇다는 건 지금 주 업무가 비어있을 수도 있다.즉 주 파이프라인을 잡아야한다.다 대응가능한 웹 프론트 개발자가 있다고 해도 말이다.그리고 뒤에 '사소한 추가개발 및 잡 버퍼' 을 넣고 그때 짜잘한거를 몰아버리는 게 낫다. 앱은 기획에서 타겟 버전을 명시해주면 보다 쉽게 풀린다. 프로젝트 관리 팁(실제 내가 쓰는) 내 자신도 까먹을 까봐 남겨놈 요약 -기획문서는 정책문서를 상속-정책문서는 인터페이스 처럼 분야를 분기 ex, 프로덕트 정책문서 / 모빌리티 정책문서- 초기 카오스컨트롤 -> 리스크 최소화 제품 MVP- 시니어 급은 업무 트래킹 - 짧은 기능 단위 기획 / 월별 기능 단위 기획 -> 백/앱/프/디자인 관계없음- 기획문서는 대신 사용자 타입에 따라 기획함 - 개발 프로젝트는 최대 3개월 정도 WBS 를 계속 최신화 - 개발 WBS는 업무트래킹용이 아닌 상호 의존성 확인 용 , 방향성 및- 기획 문서와 달리 개인화가 가능해야함. - 툴은 노션안씀, 최대한 슬랙 Canvas 또는 List 사용- 슬랙 쓰레드를 이어붙임- WBS는 엑셀 사용안함, 구글 스프레드 시트사용 : 이유 : 나는 관리 및 운영만하고 개발.. 이전 1 2 3 4 ··· 12 다음
