产品那些事产品经理今日看点

PM如何管理好产品——《从点子到产品》03笔记

2017-02-07  本文已影响661人  林魔王
《从点子到产品》—— 刘飞老师

本书目录

如何找到产品价值和用户痛点——《从点子到产品》01笔记
从需求分析到功能设计——《从点子到产品》02笔记
PM如何管理好产品——《从点子到产品》03笔记

一、文档管理

什么是好的文档?

能够减少甚至免除在开发过程中技术人员跟产品经理沟通的文档就是好文档。

好文档的几个条件:

  1. 没有逻辑硬伤
  2. 没有疏漏
  3. 逻辑清晰
  4. 可读性强:尽量提供数据、信息、流程展示图

文档逻辑

功能框架逻辑

业务流程逻辑

描述功能时注意事项

需求用例模板

| 用例名 | 描述 |
| :---------------: |:-- --:|
| 场景 | 当前使用的场景 |
| 用户需求 | 具体解决用户什么问题 |
| 前置条件 | 完成该功能点的前提条件 |
| 需求详述 | 描述该功能点所能实现的业务功能 |
| 后置条件 | 完成该功能点产生的结果 |
| 补充说明 | 如有例外或特殊情况补充说明 |

二、需求管理

获取需求阶段

  1. 判断需求
  1. 记录需求

讨论和设计阶段

  1. 判断需求的优先级
四象限法则(非书内原图)

重要程度排序

判断紧急程度

KANO模型简化版

必要型需求
基本的“痛点”需求,如果功能存在,用户没有感觉,但是功能没有,用户会不开心。

期待型需求
功能存在用户会开心,功能不存在用户会不开心,属于最直接、最明显的用户需求,实现后符合用户的心理预期。

惊喜型需求
用户没有预期,功能不存在时,用户没有感觉,但功能存在用户会很开心,超出用户的预期。

2.方案草稿
针对待解决的问题,先讨论方案,如果涉及到其他业务部门,达成共识后,继续推进。

3.指定负责人
按照模块进行分配,并设计职责的边界。

4.划定时间节点
设定Dealine,建议最长不超过一周的时间,同时将需求的状态提供给需求的来源方。

待开发阶段

  1. 方案可行性评估:提出方案的实现细节,并评估是否有可行性。
  2. 有没有更好的方案:给技术部门灌输需求背景,思考是否有跟多可行性方案或思路。
  3. 涉及的产品和技术环节有哪些:如果涉及影响其他产品线,需要技术评估那些人需要知情或参与评估。
  4. 方案的成本评估:除了评估人力、资源、时间等表面成本,也要考虑服务器、带宽等隐性成本。
  5. 讨论结束:输出严谨的可执行方案,如果没有达成一致,也要确认下一次解决问题的时间节点。

开发阶段

开发优先级排序
两个维度:重要紧急程度、开发成本
开发顺序:1-9

不复杂 比较复杂 非常复杂
重要紧急 1 2 5
重要不紧急 3 4 7
不紧急 6 8 9

开发阶段注意事项

复盘阶段

需求完成生命周期之后执行,复盘需求管理中的故障及问题,防止下次再出现。

三、工作流管理

协作管理

与技术人员常规协作

与技术人员协作的临时状况(紧急新增、修改需求)

与需求来源方协作
重点是需求完成的准确度完成度,需要努力同步信息。

协作素养

  1. 文档记录:再小的需求也要更新到文档。
  2. 会议记录:主要记录讨论节点和结论,以最终发出的邮件为准。
  3. 想法和思路:主要用于备忘。

流程管理

协作标准化和流程化

  1. 所有需求由邮件提出,记录需求并明确负责人。
  2. 对接多个业务方时,固定接口人,防止未达成一致的需求、重复设计需求等。
  3. 需求状态固定时间发布,让需求方放心,并了解当前推进的状态。
  4. 有延期的需求,需要告知需求方,并告知原委。

减少手工劳动
使用协作软件,解决需求协同管理的问题。

让一些工作可复用

  1. 原型交互做成模块化,可复用,遵循视觉和逻辑的统一。
  2. 话术、文案根据不同的场景(警告、提醒、解释说明),统一规范表达。

避免重复犯错
通过找到犯错的原因,加强管控。

  1. 由于疏漏导致。
  2. 由于信息不全、知识不完备导致。
  3. 由于没有责任心导致。
  4. 由于无法胜任导致。

个人管理

任务管理
常见的陷阱

  1. 把焦急当做任务的紧急程度。
  2. 把充实感当做完成任务。
  3. 眼光不够长远,只做半衰期短的事情。
  4. 不设置截止日期。
  5. 不检视效果。

知识管理
通过在线笔记储备知识(参考笔记术)

团队管理

  1. 提升专业技能服众
  2. 提升管理技能
上一篇下一篇

猜你喜欢

热点阅读