Product Insight/managing.PM (6) 썸네일형 리스트형 사람마다 다른 프로젝트 매니징을 해야한다. 프로젝트 매니징을 효과적으로 하기 위해서는 팀원의 역할과 경험에 맞게 관리를 구분해야 한다.**1. 역할에 따른 관리 방식**- **SI 인력**에는 명확한 기간과 테스트 기간을 제공해야 한다.- **주니어 스타트업 인재**에게는 가이드를 제공하고, 일정 확인 및 상호의존성 관리, 그리고 향후 3개월치 계획을 공유하는 정도로 관리한다.- **시니어 스타트업 인재**에게는 업무 트래킹만 충실히 제공하며 자율성을 존중한다.**2. 업무 방식에 따른 역할 분리** - 코어 프로젝트를 담당할 인력과 - 세부 작업을 담당할 인력, - 양쪽을 모두 소화할 수 있는 인력을 구분하여 역할을 배분해야 한다.**3. 효율성 관리와 균형** - 사람을 다룰 때 최상의 효율을 뽑아내는 것이 목표이지만, 그 과정.. 개발자와 기획자의 린 스타트업 차이 밑에 처럼 하기가 정말 어렵다. 밑에 스케이트보드에서 킥보드는 된다. 킥보드에서 자전거를 만들 때, 미리 설계를 못했으니 때리고 부셔야한다. 자전거 만들 때, 오토바이에 해당되는 내용까지 미리 설계를 하면 백엔드 오버헤드가 발생한다.때리고 부쉬는게 고통스럽고 상처도 많이 받지만, 최단거리다. 개발자가 2->3을 갈 때, 화가 많이 난다.기획자는 2 ->3을 갈 때, 1->2 처럼 갈 수 있을거라 생각한다. 기존 것을 활용해서 이어붙이면 가능할거라 생각한다. 물론 가능을 하지만, 그것은 때려 부쉬고 다시 만드는 것 보다 더 어렵고, 개발자 입장에서는 그것을 기획자말 대로 선뜻한다고 선택했을 때 '감당'할 수도 '책임'을 질 수도 없다. 그러면 어떻게 해야할까? 내 인사이트는 다음과 같다. 1. 대.. IT 프로젝트를 버전별 관리(APP, WEB) 앱은 버전별로 관리해서 사실 관리가 쫌 잡히는 편이고 웹은 즉시 즉시 업데이트가 되니깐 사실상 기능을 모아서 배포하기가 어렵다. 근데 이 모든건 초기 프로덕트가 있냐 없냐가 가장 중요하다. 그리고 즉시 말을 했을 때 대응할 수 있는가 -> 그렇다는 건 지금 주 업무가 비어있을 수도 있다.즉 주 파이프라인을 잡아야한다.다 대응가능한 웹 프론트 개발자가 있다고 해도 말이다.그리고 뒤에 '사소한 추가개발 및 잡 버퍼' 을 넣고 그때 짜잘한거를 몰아버리는 게 낫다. 앱은 기획에서 타겟 버전을 명시해주면 보다 쉽게 풀린다. 프로젝트 관리 팁(실제 내가 쓰는) 내 자신도 까먹을 까봐 남겨놈 요약 -기획문서는 정책문서를 상속-정책문서는 인터페이스 처럼 분야를 분기 ex, 프로덕트 정책문서 / 모빌리티 정책문서- 초기 카오스컨트롤 -> 리스크 최소화 제품 MVP- 시니어 급은 업무 트래킹 - 짧은 기능 단위 기획 / 월별 기능 단위 기획 -> 백/앱/프/디자인 관계없음- 기획문서는 대신 사용자 타입에 따라 기획함 - 개발 프로젝트는 최대 3개월 정도 WBS 를 계속 최신화 - 개발 WBS는 업무트래킹용이 아닌 상호 의존성 확인 용 , 방향성 및- 기획 문서와 달리 개인화가 가능해야함. - 툴은 노션안씀, 최대한 슬랙 Canvas 또는 List 사용- 슬랙 쓰레드를 이어붙임- WBS는 엑셀 사용안함, 구글 스프레드 시트사용 : 이유 : 나는 관리 및 운영만하고 개발.. 프로덕트 만들때 WBS 의 필요성 외주 업체있으면 무조건 있어야하고아주 작은 규모는WBS를 간략화 해서 가지고 있으면 좋고개판 난리이고, 경험 없는 팀은 차라리 없는게 좋다. 했냐 안했냐도 중요하지만,서로 다른 방향으로 깊게 파고들고 항해하는 것을 예방할 수 있다.-> 이게 제일 중요한 것 같다.갠트 차트의 시각적 타임라인을 사용하면 각 작업의 세부정보는 물론 프로젝트 간의 상호 의존성을 확인할 수 있습니다. SI 프로젝트가 아니면, 버전 별로 WBS를 만들어서 가볍게 가져가는게 좋을 것 같다. 웹은 바로바로 배포할 수 있지만 바로바로 배포하면 버전 관리가 안되니깐 앱처럼 핫픽스하고 버전으로 관리해야하고.. 그래야 측정이됨.. 바로바로 배포하면 개판남.. WBS는 버전별로 계속 최신화해서 전달하고기획문서는 월별로 최신화해서 전달.. 기획 문서와 함께 정책 문서도 필요한 이유 일단 규모가 있게 기획 문서를 작성하면 안된다. 왜냐 디자인, 백엔드, 프론트, 앱, 관리자 페이지, 클라우드 그리고 내가 모르는 개발 복잡도와 서로 물리고 물리는 정책.. 기획은 정말 작은 단위로 요청하고 기획 문서를 만들어야한다. 하지만, 이런 상황이 또 올것이다. 결제 -> 간편 결제 추가해주세요결제 -> 미수금 발생시 결제 페이지로 이동하게 해주세요결제 -> 세컨 카드를 등록하게 해주세요 결론: 케컨 카드 등록하게 했는데.. 미수금 발생시 결제 페이지에도 간편 결제 가능하게 띄워요? 세컨 카드 등록하는 거 만들었는데 지난번에 만든 결제 페이지에 간편 결제랑 세컨 카드등록이랑 분기 칠까요? 이렇게 3번 요청해야한다면?미수금 발생시 결제 페이지로 가서, 결제카드를 교체하게 해야하는가? 디폴트 카.. 이전 1 다음
