敏捷开发&瀑布式开发

分享主题：读书笔记—《启示录:打造用户喜爱的产品》（中-2）

Marty Cagan作为高级产品经理人为多家一流企业工作过，包括惠普、网景、美国在线、eBay。他亲历了个人电脑、互联网、电子商务的起落沉浮。

《启示录：打造用户喜爱的产品》从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。流程篇一流互联网公司的流程及技术与普通公司相比有很多不同之处，第二部分讨论探索及开发富有创意的产品时反复应用的流程和成功的实践经验。

11、产品验证——证明产品的价值、可用性、可行性

产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求。产品经理向产品团队提供最终的产品说明文档前，需要进行以下三项重要的验证：

1、可行性测试。明确在现有的技术条件下，能否成功开发出产品。

2、可用性测试。交互设计师应该与产品经理密切合作，想方设法突出产品的功能特性，让不同类型的用户都能明白如何使用。为了测试可用性，即使要模拟复杂的后台处理过程也是值得的，关键是要评估用户体验的实际效果。

3、价值测试。同样要紧的是知道用户是否觉得你的产品有用，是否愿意购买，有多喜欢产品的设计。价值测试可以和可用性测试同时进行，使用原型也是一样的。

过去使用原型主要有两个障碍：

1、缺少制作原型的工具，制作原型非常耗时。

2、管理层不明白原型和真实产品的区别，产品团队被迫在原型的基础上开发产品，最终的产品品质可想而知。

12、原型测试——把产品创意呈现给真实用户

产品可用性测试（检验用户能够想明白如何使用产品）和产品价值测试（检验用户是否渴望使用产品）同样重要。

如何物色测试者：

1、可邀请已有的特约用户参加。

2、如果是企业级产品，同类产品的展销会是寻找目标用户的好去处。

3、在分类信息网站上发布广告，征集测试者。

4、如果是大众产品，可以邀请自己的亲朋好友参加测试，当然不能只局限于亲友。

5、从用户的电子邮件列表中筛选测试者，营销团队可以帮你缩小名单范围。

6、通过公司的网站征选志愿者，需要筛选，避免参加测试的都是产品尝鲜者。

7、较大公司开展原型测试活动，每次邀请10~20位测试者参加。

8、离开公司，到街头巷尾去，到用户聚集的地方去。

9、如果邀请测试者上门参加测试，尤其是出于商业目的，应该补偿测试者为此损失的时间。

10、即使和测试者约定了测试时间，还是有人会忘记时间，爽约的几率大概是30%。

准备测试

确定可用性测试的内容，并拟出问题，就产品的价值向测试者提问。

1、事先拟好测试内容。

2、你只有一次机会了解测试者未接触产品原型之前如何解决产品要解决的产品。

3、测试原型前还有一件事要做，即观察测试者能否从原型首页看出产品要解决什么问题，哪些地方最能吸引他们。

4、待测试者完成测试任务，了解产品用途后，通过聊天进一步收集信息。

5、为每个问题的答案来打分，或者干脆让测试者用数字来回答问题，以此记录每个阶段产品原型的表现。

6、不必等到完整原型完成后再测试，可以先测试主要项目，即使某些功能空着也没关系。

测试环境

如何准备测试环境：

1、正规的测试实验室通常会配备单向透明镜和闭路监视器，并配有多个摄影机同时拍摄用户和电脑显示屏幕。

2、用户的办公室也是上佳的测试场所。

3、测试越多越好，但面对面的测试是不可替代的。

4、产品经理应该亲自参加每次原型测试，不能委托他人，尽可能多与用户接触。

5、获取用户反馈信息是完善产品设计的最佳途径。产品经理亲自参与测试的益处远远大于可能无法客观测试带来的风险。

6、理想情况下，应该安排一个人主持测试，另一个人记录。

7、还可以邀请开发人员、交互设计师、视觉设计师，甚至公司高管帮忙。参加原型测试会让他们受益匪浅。

测试原型

实际测试的技巧和窍门：

1、测试前不宜与测试者交谈过多。事先谈得越多，透露的产品线索就越多，测试者就越不可能说出他们对产品的第一印象。

2、寒暄之后务必告诉测试者：这只是产品原型，是初步的产品创意不是正式的产品。被测试的对象是原型，不是测试者，测试者不必担心测试失败，只有原型会通不过测试。

3、尽量让测试者保持平和的情绪，千万不要让他们陷入吹毛求疵的状态。测试的重点是看测试者能否轻松完成测试任务，以及他们是否喜欢产品的功能。多观察用户的操作，少听他们的抱怨。

4、测试时尽量保持安静，不要给测试者提示。

5、通常有三种测试结果：测试者在没有提示的情况下，顺利完成测试项目；测试者遇到麻烦，但通过反复尝试，最终完成了测试项目；测试者受挫，最终放弃。

6、一般来说要尽量避免提示测试者，更不能引导他。

7、测试主持人向鹦鹉学习，使用自言自语技巧。可以避免引导用户，帮助记录人员记下测试要点。

8、测试的作用是理解目标用户如何看待产品要解决的问题，发现原型与用户期望不一致或不相容的地方，也就是原型不符合用户直觉习惯的地方。

9、从测试者的肢体语言和语气里可以发现许多有用的信息。

更新原型

测试原型的目的是找出原型中需要修改的部分，提高原型的可用性和价值（吸引力）。因此，应尽快纠正发现的缺陷。

1、只要两三个用户反映了同一个情况，就动手解决吧。相对于判断设计缺陷来说，判断原型测试何时结束更难一些。如果有连续六位测试者理解和欣赏产品的价值，而且能完成关键的测试项目，就算完成了原型测试任务。

2、如果你发现没法让测试者对原型产生兴趣，或是无法让原型变得足够简单易用，让测试者理解其价值，应该立马收手。放弃这个产品创意。

向大家推荐两个获取测试灵感的资源：

1、是史蒂夫•克鲁格（Steve Krug）的《点石成金：访客至上的网页设计秘籍》。

2、一家产品测试公司Creative Good。他们擅长开展一种称作倾听实验室的测试方法，通过间接测试的方式找出产品功能和设计方面的缺陷，改善公司业绩。

13、改进现有产品——不是一味地添加功能

很多情况下，添加新功能不仅不会为产品增色，反而会让产品性能变得更糟糕。

我建议从另一个角度来改进产品：

1、开发新产品的第一步是要明确目标。为了实现这个目标，需要改善产品，至于应该如何改进，取决于能在多大程度上提升各项指标。

2、先考虑可以从哪些方面改善用户体验。

3、产品经理应该时刻关注这些指标，与交互设计师、用户研究人员、主程序员密切合作，分析改善产品的可能性。通过分析数据改进产品，往往能收到事半功倍的效果。

4、改进产品不是简单地满足个别用户的需求，也不能对用户调查的结果照单全收。

14、平滑部署——避免更新产品导致用户反感

用户产生反感主要有以下几个原因：

1、事前没有收到更新通知，用户觉得措手不及

2、用户没时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用。

3、新版本无法正常运行。

4、新旧版本不兼容。

5、用户认为新添加的功能和特性毫无必要。

6、应付接二连三的版本更新，用户感到疲惫不堪。

7、新版本修改了用户已习惯的使用方式和操作流程，用户不得不重新调整适应。

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

1、通过公告、群发邮件、在线教程等方式提前通知用户。

2、加倍做好测试工作，避免新版本存在影响正常使用的隐患，确保将来不会陷入被迫返回旧版本的窘境，为用户增加不必要的麻烦。

3、如果更新版本会影响大规模用户，应该采取并行部署或者增量部署的方式来降低风险。

平滑部署方式：

1、发布两个并行版本，邀请有兴趣、有时间的用户试用新版本。

2、区域性逐步部署。首先在某个区域内部署新版本，然后逐步扩大范围。

3、增量部署，将更新项分割成几个较小的部分逐步发布。

15、快速响应阶段——产品出炉后切莫虎头蛇尾

交付产品后正是收集反馈信息、改进产品的最佳时机。急于“撤军”是项目管理和产品开发流程中的大忌，只要稍微延长项目周期，观察用户对产品的反应，效果就会有天壤之别。

即便建立了测试团队，在正式开发产品前严格测试原型，依然无法预料所有的意外情况，有些问题发布后才会显露端倪。关键不在于是否会出现问题，而在于能多快解决问题。

评估产品表现应该使用明确的、可量化的指标：

1、针对大众的网络服务，使用专业工具可以协助追踪用户行为，比如谷歌分析工具可以快速清晰地展现用户使用网络产品的状况。

2、企业级软件，派遣产品团队成员亲自上门为客户安装软件。这样总能快速发现、解决问题，因为他们明白不安装好产品就别想离开。

3、除了使用网站分析工具掌握用户行为外，还可以借助问卷调查、邮件讨论、留言板、现场测试等方式。

16、合理运用敏捷方法

十大秘诀，只适用于产品软件团队，不适用于定制软件团队。

1、产品经理即是产品负责人，他代表了客户需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。

2、使用敏捷方法绝不等于省略产品规划。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法代替冗长的市场需求文档。

3、产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期。

4、尽量把产品设计工作拆分成独立的部分，分而治之，但也不能太细——好比设计建筑不能一次只设计一个房间。

5、产品经理的主要任务是定义有价值、可用的产品原型和用户故事，作为开发的基础。以此来替代厚厚的产品需求文档和功能说明文档有三个优势：a、可用请用户测试。B、强迫产品经理全面认真地思考问题。C、向开发团队明确地描述每次迭代周期需要完成的任务。

6、让开发人员自主划分迭代周期。

7、产品经理和交互设计师必须出席每天的晨会。

8、除非达到了产品经理的要求，否则不要轻易发布新版本。

9、在每次迭代后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型。

10、在团队内展开敏捷培训。

迭代初期开发的产品能用做原型？

也许适用于定制软件，但不适用于产品软件，原因如下：

1、用一个迭代周期来验证产品创意时间太长。

2、在探索产品的阶段，开发团队还有许多重要的工作要完成。

3、尽管敏捷方法鼓励开发团队不断学习，快速反应，一旦进入开发阶段，设计出软件架构后，再想改变产品设计思路，对开发团队来说无论是成本还是难度都太高了。

17、合理运用瀑布式开发方法——扬长避短

瀑布式开发的基本原则：

1、阶段式开发

2、阶段是评审

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

1、瀑布式开发方法流程具有可预见性，因而深受管理层欢迎。

2、采用瀑布式开发方法在每个阶段结束时都会提交书面材料。

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

1、产品验证严重滞后

2、变更计划代价不菲

3、无法适应快速的市场变化

18、创业型公司的产品管理——关键在于产品探索

目前创业型公司中流行的产品研发模式存在不足：

1、创业者通常会扮演产品经理和产品设计师的角色，开发团队则按照他的想法实现产品，很少与用户互动。

2、产品需求和创意往往边做边变化，开发进度相对较慢。

19、大公司如何创新

有困难，但值得一试，随着规模变大，公司会不可避免地变得更加保守，不敢冒险。两大因素影响大公司的创新氛围：企业文化和老板的观念。

如果你发现在公司里难以实现创新，那么可以尝试以下方法：

1、20%法则

你也许听说过，谷歌程序员有20%的工作时间可以用来从事创新研究。这个法则鼓励普通员工自己尝试各种想法，发挥大家的主观能动性，让员工打心底愿意倾注更多的激情和汗水去创新。

2、臭鼬工程

工程界的行话，原指秘密军事行动，现指在受限制的条件下，利用自己的时间，低调地进行创新研究。有一点要提醒大家，有些公司规定员工在职期间研究出来的成果归公司所有，所以不要随意拿研究成果自行创业。

3、主动观察

观察和倾听是最简单的创新途径。仔细观察用户试用公司产品或同类产品的一举一动，留心他们欣喜和失望的表情，假以时日，你肯定能想出办法更好地满足他们的需求。再找一位熟悉技术的开发人员合作，你们就可以着手改进产品了。注意，应选择实际用户作为观察对象，不要选择产品尝鲜者，更不能选择公司同事。记住，创新不是发现新问题，而是用新方法解决已有的问题。

4、改善用户体验

改善用户体验不仅要提高产品的工作效率，更要剔除多余的功能。找到用户失望的地方，就找到了创新的机会，至少是改善产品的机会。

5、收购小公司

收购是有效维持创新的手段，收购创业型公司不仅可以引入新技术，而且可以引入创新型人才，为公司注入新鲜的血液。

20、在大公司施展拳脚

大公司的现实情况：

1、大公司都遵循一条潜规则---尽量规避风险。

2、多数采取矩阵式的管理方式，这种组织结构是为了节省公司运营成本。

在大公司施展拳脚的十大秘诀：

1、了解公司制定决策的方式

2、建立人脉网络

3、臭鼬工程

4、自己顶上

5、有选择地据理力争

6、会前沟通，形成默契

7、合理分配时间

8、分享信息

9、向上司借力

10、传播你的产品理念

您也可以关注我们的官方微信公众号（ID：ctoutiao），给您更多好看的内容。