本文主要是介绍《启示录》读书笔记（3），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
第二部分 流程
第21章 产品验证
产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。
产品经理向产品团队提供最终的产品说明文档前，需要进行以下3项重要的验证。
可行性测试
- 首先要明确在现有技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行方案。
可用性测试
- 交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用
- 一定要请真实的用户来试用可用性原型，从目标用户那里可以得到宝贵的反馈信息
价值测试
- 价值测试重在观察用户是否喜欢这些功能，有多喜欢产品的设计，是否愿意购买
第22章 原型测试
产品原型可以让用户验证产品创意，加深产品经理对产品的理解，避免开发团队浪费时间和精力开发没有把握的产品。
如何寻找测试者呢？
- 如果已经有一批特约用户，可以邀请他们参加测试
- 如果是企业级产品，同类产品的展销会是寻找目标用户的好地方
- 如果是大众产品可以邀请亲朋好友参加测试
- 通过公司网站征集志愿者
- 离开公司到街头巷尾去，到用户聚集的地方去
第23章 改进现有产品
不是一味地添加功能
大多数产品团队实际上只是功能加工厂，附带制作补丁，修补缺陷。说白了，他们只会一味地添加新功能。很多情况下，添加新功能不仅不会为产品增色，反而会让产品性能变得更糟糕。
作者认为，改进产品不是简单地满足个别用户的要求，也不能对用户调查的结果照单全收。能提高指标的功能才是你关注的重点。
产品经理应该找准方向，分析关键指标，有针对性地改进产品。
第24章 平滑部署
通常情况下，用户不喜欢变化。虽然他们也希望产品更完善，功能更丰富，但前提是不改变已有的使用习惯，大多数人不愿意花时间学习、适应新的使用方式。
然而我们的工作要不断推陈出新，这就是矛盾所在。我们不能因噎废食，不能因为用户可能反感就放弃更新产品，但是更新产品时必须谨慎、理智。
用户反感新版本主要有以下原因：
- 用户没时间学习、适应新版本
- 新版本无法正常运行
- 新旧版本不兼容
- 虽然新版本可以正常运行，但用户认为添加的功能和特性毫无必要
- 新版本修改了用户使用习惯和操作流程
- 接二连三的版本更新使用户感到疲于应付
为了将版本更新带来的负面影响降到最低，可以采取以下几种措施：
- 加倍做好测试工作，避免可靠性、兼容性问题，确保将来不会陷入被迫返回旧版本的窘境
- 如果更新版本会影响大规模的用户，应该采取并行部署、小范围部署、增量部署
- 通过公告、在线教程等方式提前通知用户（效果有限，大多数人不会看）
第25章 快速响应阶段
产品发布后的一周内，所有项目成员应该留出时间作为快速响应阶段。
这个阶段的主要工作是快速响应，处理产品发布后的用户反馈意见。这样做投资小，回报高。
即便在正式发布前严格测试产品，你依然无法预料所有的意外情况，有些问题发布后才能显露端倪。关键在于能多快解决问题。
第26章 合理运用敏捷方法
尽管敏捷方法（Scrum/极限编程）有许多优点，但这类方法源自于定制软件领域，不完全适用于开发产品软件（product software）。
在产品软件开发中，使用敏捷方法的诀窍：
- 产品经理要与开发团队保持密切联系，协助开发进程，及时解决出现的问题
- 使用敏捷方法绝不等于省略产品规划
- 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保开发团队有足够的时间攻克难题
- 让开发人员自主划分迭代周期。有的产品功能可以在一个迭代周期完成，有的却需要好几次迭代才能完成
- 产品经理必须出席每天晨会。晨会是一天沟通过程的开始，而不是结束，关于产品的讨论会持续一整天
- 定义明确的、有价值的用户故事（user story）和产品原型，作为开发的基础。产品经理必须全面认真地思考问题，向开发团队明确地描述每次迭代周期需要完成的任务。
第27章 合理运用瀑布式开发方法
瀑布式开发方法的理念很简单，主要两点：
- 采用阶段式开发 软件开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署
- 采用阶段式评审 每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段
瀑布式开发方法经久不衰的原因有：
- 流程具有可预测性，深受管理层欢迎。只要能准确理解需求和技术，而且需求不再变更，开发团队就能为大规模的、复杂的项目制定准确的开发计划。相反，迭代方法的迭代次数不可预估，难以让管理层放心。
- 每个阶段结束，都可以有详实的书面材料。有了详实的文档和设计图表，管理层、用户、开发人员觉得所有工作都是经过深思熟虑的，才能放心。问题在于，即便文档正确，软件依然可能得不到大多数用户的认可。
瀑布式开发方法让产品经理头疼的地方：
- 产品验证严重滞后
- 变更计划代价不菲：对前期决策的修改会打乱开发节奏，大量工作需要从头来过
- 无法适应快速的市场变化
第28章 创业型公司的产品管理
创业型公司习惯从技术层面，着手开发产品，但是优秀的创业者应该意识到首要任务是确定开发什么样的产品，千万别浪费大量的人力、无力开发一堆用户不需要/不喜欢的功能。
因此首要的是改进产品设计流程，这里重复两个关键点：
- 创建体现用户体验的高保真原型
- 邀请真实的目标用户验证产品原型
确定产品原型后，再招聘程序员进行开发。有了产品原型，开发人员可以更直观、高效地领会产品设计和开发要求，这将大大缩短开发时间。
第29章 大公司如何创新
随着规模扩大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，比起小公司来，大公司的损失惨重得多。
如果你发现在公司里难以实现创新，不妨试试以下方法：
20%法则
谷歌的程序员有20%的时间来进行创新研究。人们误以为优秀的产品是战略规划的结果，或是来自公司高管的创意。其实，最好的创意大多来自普通员工。20%法则鼓励普通员工自己尝试各种想法，发挥大家的主观能动性。
主动观察
仔细观察用户使用公司产品或同类产品的一举一动，留心他们欣喜和失望的表情，假以时日，你肯定能想出办法更好地满足他们的需求。
记住，创新不是发现新问题，而是用新方法解决已有问题。观察人们对现有产品的不满，是创新的最佳途径。
改善用户体验
改善用户体验，不仅要提高产品的工作效率，更要剔除多余功能，明白哪些功能是用户必须的，哪些是设计和开发带来的衍生物。
找到用户失望的地方，就找到了创新机会，至少是改善产品的机会。
第30章 在大公司施展拳脚
多数大公司都采取矩阵式的管理方式，核心部门（比如设计、开发、测试、运维、市场）是共享资源，产品经理要确保争取到足够的资源才能研发出产品。
采用这种组织结构不是因为它的效率高，而是为了节约公司运营的成本。
再者大公司承担的风险更大，因此会有更多的流程、规定和条条框框以降低风险。
理解这两点后，我们能更好地在大公司施展拳脚：
- 了解公司制定决策的方式
- 建立人脉网络
- 自己顶上
- 有选择地据理力争
- 会前沟通，形成默契
- 合理分配时间
- 分享信息
- 向上司接力
- 传播你的产品理念
这篇关于《启示录》读书笔记（3）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
