美文网首页产品那些事产品经理今日看点
PM如何管理好产品——《从点子到产品》03笔记

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

作者: 林魔王 | 来源:发表于2017-02-07 16:42 被阅读661次
    《从点子到产品》—— 刘飞老师

    本书目录

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

    一、文档管理

    什么是好的文档?

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

    好文档的几个条件:

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

    文档逻辑

    功能框架逻辑

    • 拆分:罗列所有要做的功能点
    • 组合:根据模块将功能重新组合

    业务流程逻辑

    • 面向事件:完成某个事件需要多部操作,一般使用流程图来描述(用户执行的操作流程)。
    • 面向对象:在对象的整个生命周期里,涉及所有完整的功能的使用(某个功能的完整流转,例如订单)。

    描述功能时注意事项

    • 完整:尽可能列举所有的情况,关注功能可能产生的变化,如果描述内容比较复杂,可以用表格来展示。
    • 考虑所有的影响点:增加/修改某些功能,可能会对其他的功能产生影响,尽力排查。
    • 条件判断清晰:什么条件下产生/触发什么功能,需要罗列清晰,参考if/else、while、switch
    • 含义明确:尽量不使用缩写和特殊词汇,保证高效沟通。
    • 叙述场景:叙述功能的背景及达到的目的。

    需求用例模板

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

    二、需求管理

    获取需求阶段

    1. 判断需求
    • 判断需求重要性
    • 考虑需求来源
    • 了解需求背景
    1. 记录需求
    • 记录格式:“来源+问题(背景)+方案(需求描述)”建立需求池(Excel)。
    • 不该记的需求:没说清楚原因的需求,说不清逻辑的需求,不是实际遇到的需求。

    讨论和设计阶段

    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. 提升管理技能

    相关文章

      网友评论

        本文标题:PM如何管理好产品——《从点子到产品》03笔记

        本文链接:https://www.haomeiwen.com/subject/hcipittx.html