《启示录》读书笔记（3）

第二部分 流程

第21章 产品验证

产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。

产品经理向产品团队提供最终的产品说明文档前，需要进行以下3项重要的验证。

可行性测试

• 首先要明确在现有技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行方案。

可用性测试

• 交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用
• 一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息

价值测试

• 价值测试重在观察用户是否喜欢这些功能，有多喜欢产品的设计，是否愿意购买

第22章 原型测试

产品原型可以让用户验证产品创意，加深产品经理对产品的理解，避免开发团队浪费时间和精力开发没有把握的产品。

如何寻找测试者呢？

1. 如果已经有一批特约用户，可以邀请他们参加测试
2. 如果是企业级产品，同类产品的展销会是寻找目标用户的好地方
3. 如果是大众产品可以邀请亲朋好友参加测试
4. 通过公司网站征集志愿者
5. 离开公司到街头巷尾去，到用户聚集的地方去

第23章 改进现有产品

不是一味地添加功能

大多数产品团队实际上只是功能加工厂，附带制作补丁，修补缺陷。说白了，他们只会一味地添加新功能。很多情况下，添加新功能不仅不会为产品增色，反而会让产品性能变得更糟糕。

作者认为，改进产品不是简单地满足个别用户的要求，也不能对用户调查的结果照单全收。能提高指标的功能才是你关注的重点。

产品经理应该找准方向，分析关键指标，有针对性地改进产品。

第24章 平滑部署

通常情况下，用户不喜欢变化。虽然他们也希望产品更完善，功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。

然而我们的工作要不断推陈出新，这就是矛盾所在。我们不能因噎废食，不能因为用户可能反感就放弃更新产品，但是更新产品时必须谨慎、理智。

用户反感新版本主要有以下原因：

1. 用户没时间学习、适应新版本
2. 新版本无法正常运行
3. 新旧版本不兼容
4. 虽然新版本可以正常运行，但用户认为添加的功能和特性毫无必要
5. 新版本修改了用户使用习惯和操作流程
6. 接二连三的版本更新使用户感到疲于应付

为了将版本更新带来的负面影响降到最低，可以采取以下几种措施：

1. 加倍做好测试工作，避免可靠性、兼容性问题，确保将来不会陷入被迫返回旧版本的窘境
2. 如果更新版本会影响大规模的用户，应该采取并行部署、小范围部署、增量部署
3. 通过公告、在线教程等方式提前通知用户（效果有限，大多数人不会看）

第25章 快速响应阶段

产品发布后的一周内，所有项目成员应该留出时间作为快速响应阶段。

这个阶段的主要工作是快速响应，处理产品发布后的用户反馈意见。这样做投资小，回报高。

即便在正式发布前严格测试产品，你依然无法预料所有的意外情况，有些问题发布后才能显露端倪。关键在于能多快解决问题。

第26章 合理运用敏捷方法

尽管敏捷方法（Scrum/极限编程）有许多优点，但这类方法源自于定制软件领域，不完全适用于开发产品软件（product software）。

在产品软件开发中，使用敏捷方法的诀窍：

• 产品经理要与开发团队保持密切联系，协助开发进程，及时解决出现的问题
• 使用敏捷方法绝不等于省略产品规划
• 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保开发团队有足够的时间攻克难题
• 让开发人员自主划分迭代周期。有的产品功能可以在一个迭代周期完成，有的却需要好几次迭代才能完成
• 产品经理必须出席每天晨会。晨会是一天沟通过程的开始，而不是结束，关于产品的讨论会持续一整天
• 定义明确的、有价值的用户故事（user story）和产品原型，作为开发的基础。产品经理必须全面认真地思考问题，向开发团队明确地描述每次迭代周期需要完成的任务。

第27章 合理运用瀑布式开发方法

瀑布式开发方法的理念很简单，主要两点：

1. 采用阶段式开发   软件开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署
2. 采用阶段式评审   每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段

瀑布式开发方法经久不衰的原因有：

• 流程具有可预测性，深受管理层欢迎。只要能准确理解需求和技术，而且需求不再变更，开发团队就能为大规模的、复杂的项目制定准确的开发计划。相反，迭代方法的迭代次数不可预估，难以让管理层放心。
• 每个阶段结束，都可以有详实的书面材料。有了详实的文档和设计图表，管理层、用户、开发人员觉得所有工作都是经过深思熟虑的，才能放心。问题在于，即便文档正确，软件依然可能得不到大多数用户的认可。

瀑布式开发方法让产品经理头疼的地方：

1. 产品验证严重滞后
2. 变更计划代价不菲：对前期决策的修改会打乱开发节奏，大量工作需要从头来过
3. 无法适应快速的市场变化

第28章 创业型公司的产品管理

创业型公司习惯从技术层面，着手开发产品，但是优秀的创业者应该意识到首要任务是确定开发什么样的产品，千万别浪费大量的人力、无力开发一堆用户不需要/不喜欢的功能。

因此首要的是改进产品设计流程，这里重复两个关键点：

1. 创建体现用户体验的高保真原型
2. 邀请真实的目标用户验证产品原型

确定产品原型后，再招聘程序员进行开发。有了产品原型，开发人员可以更直观、高效地领会产品设计和开发要求，这将大大缩短开发时间。

第29章 大公司如何创新

随着规模扩大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，比起小公司来，大公司的损失惨重得多。

如果你发现在公司里难以实现创新，不妨试试以下方法：

20%法则

谷歌的程序员有20%的时间来进行创新研究。人们误以为优秀的产品是战略规划的结果，或是来自公司高管的创意。其实，最好的创意大多来自普通员工。20%法则鼓励普通员工自己尝试各种想法，发挥大家的主观能动性。

主动观察

仔细观察用户使用公司产品或同类产品的一举一动，留心他们欣喜和失望的表情，假以时日，你肯定能想出办法更好地满足他们的需求。

记住，创新不是发现新问题，而是用新方法解决已有问题。观察人们对现有产品的不满，是创新的最佳途径。

改善用户体验

改善用户体验，不仅要提高产品的工作效率，更要剔除多余功能，明白哪些功能是用户必须的，哪些是设计和开发带来的衍生物。

找到用户失望的地方，就找到了创新机会，至少是改善产品的机会。

第30章 在大公司施展拳脚

多数大公司都采取矩阵式的管理方式，核心部门（比如设计、开发、测试、运维、市场）是共享资源，产品经理要确保争取到足够的资源才能研发出产品。

采用这种组织结构不是因为它的效率高，而是为了节约公司运营的成本。

再者大公司承担的风险更大，因此会有更多的流程、规定和条条框框以降低风险。

理解这两点后，我们能更好地在大公司施展拳脚：

• 了解公司制定决策的方式
• 建立人脉网络
• 自己顶上
• 有选择地据理力争
• 会前沟通，形成默契
• 合理分配时间
• 分享信息
• 向上司接力
• 传播你的产品理念