《人人都是产品经理》读书笔记-2020

 

一、需求

1.访谈

• 用户会骗人，说做不一
  • 案例：索尼游戏机；策略：关注用户做了什么，步骤及结果；而用户说的：我觉得，我认为....可信度较低
• 样本以偏概全总体
  • 策略：增量访谈：5+5+5+5+5.....看每次加5后，结论是否变化
• 用户口若悬河
  • 策略：没时间别浪费
• 我们过于强势，像推销
• 总之：用户访谈注意点
  • ► 避免一组固定的问题：固定的问题会让被访者产生被审问的感觉，问题清单只起一个引导作用，并不用照着读。
  • ► 关注目标，任务其次：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。
  • ► 避免让用户成为设计师：听用户说，但不要照着做，用户的解决方案通常短浅、
  • 片面。
  • ► 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式。
  • ► 鼓励讲故事：故事是最好的帮助设计师理解用户的方法。
  • ► 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用么？”一般来说用户会给出毫无意义的肯定答复。

2.调查问卷-沉默的大多数，骑墙的大多数

• 样本代表性
  • 从总样本中筛选出贴近目标群体的子样本
• 样本少
  • 样本太少，比如少于100，不能给出百分比的答案（60%的人选A），而是具体情况的答案。
• 问卷细节
  • 问题应是选择性而非引导性：问是否喜欢，不问你喜欢...吗
  • 顺序偏差and位置偏差
  • 策略：小范围试答，再大范围投放
• 设计一个问卷：样本分类的问题→最想知道的问题→回答者自身情况的问题

3.可用性测试-定性

• 常见问题及对策
  • 可用性测试莫太晚
  • 可用性测试一定要做，即便时间再短，做一个人也行
  • 是测试产品，非测试用户；莫引导，莫施压
• 产品发布后的改进
  • 可新旧版共存一段时间
  • 发起一个小面积试验→监测改版效果

4.数据分析-定量（推荐《黑天鹅》《统计数字会撒谎》https://pan.baidu.com/s/11zKP4）

• 问题点
  • 分析不考虑投入，科研化
  • 误读数据：莫要为迎合一个观点去找数据
  • 设计产品时一定要加上收集数据的功能
• 需求采集
  • 一手需求（用户）
  • 二手需求（销售、老板）-莫让二手需求让产品扭曲了服务用户的初衷
    • 采集方法：单项需求卡片（节省同事提交需求的时间成本）
    • 至少包括：需求描述、需求编号、来源、场景.....
• 需求采集方法
  • 现场了解客户需求
  • AB测试（一半用A设计，一半用B设计，可研究大量用户）
  • 日记研究（业内人士会写使用分析）
  • 卡片分类法（把产品需求写便利贴上，用户一起讨论分类→了解用户的思维）
  • 用户自己提需求

5.听用户的但不必照做（需求分析）

• 用户需求→（需求分析）→产品需求（我们存在的价值呀）
• 方法
  • 改变现状
  • 降低理想
  • 转移需求
• 比喻：

• 需求分析时一个分→总→分的过程

6.需求DNA检测

• 流程：需求转化→ 确定基本属性→分析商业价值→初评实现难度→计算性价比
• 模块设置：与信息架构知识有关
• 如图是本书作者文中的各个需求对应的模块设置样本
• 
•  需求转化
  • 需求分类-KANO模型
  •  
  • 基本属性
  • 
  • 
• 需求的商业价值分析
  • 重要性
  • 紧急性
  • 持续时间
  • +价值描述
  • +价值评级（boss在会议中敲定，无需团队投票均值）
• 需求实现的难度
  • 衡量指标1：工作量
  • 衡量指标2：开发量（开发工程师量+工作量）
• 性价比
  • =商业价值÷开发量
• 需求筛选（PK）
  • 包括：需求打包→BRD制作→产品会议→立项
  • 打包
    • 打包类似功能 
    • 功能间存在依赖关系
    • 需求精度的设置（需求粒子的设置）（会议室灯开关的设置及控制）
  • BRD
    • 项目背景：why
    • 商业价值：meaning
    • 功能需求描述：how to do
    • 非功能需求描述：不重要
    • 资源评估：看成本
    • 风险和对策：潜在风险
• 少做就是多做！（评论的功能）
• 用100%的质量做75%的数量

  ---

  ---

  二、项目的一生

• 1.产品VS项目

特征	产品	项目
生命周期	较长（不断被完善）	较短（起始明确）
具体工作内容	偏修正与创新（探索）	偏计划与控制（任务）
产出物	通用性高、用户量大	个性化定制
举例	做新闻频道	做新闻国庆专题

 

• 产品经理VS项目经理

  特点	产品经理	项目经理
  关注点	正确的事	正确地做事
  内容	市场需求满足与否、利润有无	事情完美与否、目标是否完成
  能力	判断力与创造力（内驱）	执行力与控制力（外驱）

   

  • 产品经理总是尽可能希望多增加功能以满足用户需求；而项目经理则希望少一些功能来如期完成项目。这两个职位之间需要一个平衡。即黑格尔的“正反合”

• 2.项目KICK OFF

  • 需求筛选→团队组建→计划确定→Kick off

  • 项目组织结构

  • 

  • 复评项目工作量

    • 具体开发工程师运用“三点估算法”估算

      • 1.工作量=（最乐观+最悲观+最可能）÷3

      • 2.工作量=（最乐观+最悲观+最可能x4）÷6

    • 工作粒度更精细化，精细至1人天或1人时；1人天通常≈5~6人时
    • 统计工作量时可留一些余量，减少加班，莫让加班伤太大士气

       

  • 项目经理再在更大粒度上合成项目计划

  • 

  • 沟通从始至终

    • 项目晨会、项目日报、评审会、项目变更申请、发布预告及公告

  • 誓师大会不可或缺！（KO会议）15min左右

    • 项目背景、项目意义、目的及目标、需求、功能点概述、项目组织架构、项目计划、沟通计划

  • 心中一直要有树-WBS

    • 做项目的过程中要学会WBS，一边做项目，一边形成自己的WBS模板

• 3.需求Again（需求文档）

  • 主要包括：BRD、MRD、PRD和FSD

  • PRD

    • 学一点UML——为了描述需求，如果同事不懂可寻求其他工具（Visio可画UML）

      • 类图（像ERD）：一个外行看了就能了解的图

      • 用例图：Use Case Diagram：描述UC之间的关系

      • 状态图：State Diagram：描述实体的状态转换

    • 用例文档

    • 时序图、活动图及其他（再学一点UML）

    • Demo制作（产品原型、演示版）

      • demo不是一定要做，它与用例文档的区别是增加了交互和视觉的细节，所以看开发工程师们需不需要就完了

      • 也可以用可以嵌入富媒体的文档方式，直接把demo嵌入用例

      • demo的制作应由用研主导，产品经理参与其中，在产品会议之前就可以做出来

      • Dreamweaver：一个可以做跨平台和浏览器的充满动感的网页的网页编辑器

    • 设计的详细程度以及分工

      • 对某个问题，如公司名称输入的限制，判断其是业务问题还是技术问题，从而分配给适当的人

      • 细枝末节的东西可以成为规范，后续直接引用即可

  • 需求文档→评审→修改→评审（评审会议上需要有个决定人，避免各方僵持）

    • 

    • 需求评审:PRD（PD） 、UC（PD）、Demo（UE）

    • 设计评审

    • 测试评审

    • 

    •  

 

 

 

名词：

• PMTs：Product management teams 产品管理团队
• SNS：Social Networking Service 社会性网络服务（帮助人们建立社会性网络的应用）
• BRD：Business Requirement Document 商业需求文档
• PRD：Product Requirement Document 产品需求文档
• UT：Using Testing 可用性测试
• Focus Group 焦点小组：是由一个经过训练的主持人以一种无结构的自然的形式与一个小组的被调查者交谈，
  可以视为一种一对多的用户访谈形式
• 种子用户：指指某产品的一些忠诚度很高的用户，产品设计者与他们长期保持交流，让他们试用最新产品，可以
  经常从他们那里获得产品的建议和意见
• UGC：User Generated Content  用户产生内容（用户参与产品设计环节中）
• UC：User Case 用例（用户案例）
• TC：Test Case 测试案例
• WBS：Work Breakdown Structure 工作分解结构
• FSD：Functional  Specifications Document 功能详细说明
• UML：Unified  Modeling Language 统一建模语言：试图将软件工程的过程规范化
• Class Diagram 类图：像工程中常用的实体关系图（ERD），不过ERD更接近现实世界的对象，类图更接近技术实现的对象
• Sequence Diagram：时序图，或顺序图
• Activity Diagram：活动图
• Collaboration Diagram：协作图
• User Experience：UE：用户体验
• QA：Quality Assurance：质量保证人员
• Smoke Test 冒烟测试：时间短
• UAT：User Acceptance Test 用户接受度测试
• severity：缺陷级别
• SVN：Subversion 版本管理工具