今天继续为大家更新《启示录-如何打造用户喜爱的产品》
第27章 合理运用瀑布式开发方法
Succeeding with the Waterfall Process
扬长避短
本章讨论目前大多数产品团队仍然在使用的开发方法——瀑布式开发方法。
瀑布式开发方法已经有三十多年历史了。虽然开发人员和产品经理们早已怨声载道， 但它依旧是最常用的软件开发方法。
大多数开发团队仍然在使用瀑布式开发方法，只是人们不好意思承认，所以纷纷换了别的称呼，比如，持续改进方法、里程碑式开发方法等等。
本章先揭示瀑布式开发方法的主要缺点，然后着重探讨产品经理如何在瀑布式开发方法中扬长避短。
瀑布式开发方法的基本原则
传统瀑布式开发方法的理念很简单，主要有两点。
1.采用阶段式开发 软件开发过程被事先分成固定的几个阶段：撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署。
2.采用阶段式评审 每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段。
瀑布式开发方法有正式和非正式两种形式。正式的形式可以参考美国国防部软件开发标准2167A及后来的标准498，其中详细地描述了该方法所有阶段的流程，以及需要提交的文档。更常见的还是非正式的形式：首先由市场人员收集市场需求，提交给开发人员；接着由开发人员制订开发计划，设计软件架构，进一步完善设计细节；然后进入开发测试阶段，完工后邀请用户测试产品，最后部署。
在讨论瀑布式开发方法的局限性之前，有必要先回顾一下它经久不衰的原因。
首先，瀑布式开发方法的流程具有可预测性，因而深受管理层欢迎。只要能准确理解需求和技术，而且需求不再变更，开发团队就能为大规模的、复杂的项目制订精确的开发计划。这种情况虽然很少见，但并非不可能做到。相反，迭代方法的迭代次数不可预估，难以让管理层安心。
其次， 采用瀑布式开发方法， 在每个阶段结束时都会提交书面材料。有了翔实的文档和设计图表，管理层、客户(委托方)、 开发人员觉得所有工作都是经过深思熟虑的，才能放心。这些材料可以从一定程度上增强人们对项目的信心。问题在于把书面材料当成定心丸多少有些靠不住， 毕竟文档不能像软件一样运行、验证。
瀑布式开发方法让产品经理头痛的地方
从产品经理的角度来看，瀑布式开发方法存在不少问题。
产品验证严重滞后
这是最严重的问题。产品经理必须等到软件开发的尾声，才能看到可以运行的软件。也就是说，在投入大量人力和资金前， 软件的可用性无法得到验证。
进入开发阶段之前，产品经理应该制作产品原型，请目标用户测试，确保最终提交给开发部门的产品设计是通过了用户验证的。此外，在设计软件架构、准备开发之前，在定义产品的过程中，产品经理就应该请开发人员评估产品设计的技术风险和可行性，确保交到开发团队手里的产品设计是可行的。
变更计划代价不菲
在瀑布式开发过程中，任何对前期决策的修改都会打乱开发流程，大量工作需要从头来过，不仅浪费资金，而且耗费精力。此外，在开发和测试过程中常常会发现前期设计中的缺陷，临时修补也会严重延误开发进度。
产品经理负责跟踪客户和用户的需求，如果需求发生变化，修改产品设计是不可避免的，不过是迟早的问题。推迟到下个发布周期再修改，只是权宜之计。除非有特殊情况，我建议发现问题应尽早解决，从成本上考虑，早改肯定比晚改好。
无法适应快速的市场变化
瀑布式开发方法严重依赖文档和流程，在这方面开销很大。哪怕是一点小小的改动都要花费不少的工夫。这使得产品经理的压力倍增，因为一方面产品经理要尽量确保提交的产品设计通过了验证、没有缺陷；另一方面，产品发布后产品经理仍然提心吊胆，随时准备着和产品团队以最快的速度修补产品。
小结
了解了瀑布式开发方法在实际应用中的缺点，就不难理解为什么要改用Scrum和极限编程这类敏捷方法了。瀑布式开发方法过于理想化，以为人们能预见所有问题，全面把握需求。实践证明除非是规模很小的项目， 否则瀑布式开发方法很难顺利执行。
如果采用传统的瀑布式开发方法开发产品软件，产品的交付时间通常会比预期的晚，而且用户常常发现产品存在缺陷，开发团队还需要花费大量的时间和资金修补、完善。
如果不得不使用瀑布式开发方法，产品经理应该设法规避以上提到的问题。首要的工作是在探索(定义)产品阶段，制作产品原型，请目标用户试用，确保产品设计是有价值的、可用的、可行的。只有这样才能提高产品成功的几率，同时节约开发团队的时间和成本。
第28章 创业型公司的产品管理
Startup Product Management
关键在于产品探索
过去几年，我以顾问的身份指导过不少创业型公司，偶尔也承担一些具体工作。创业意味着打造新产品，这样的平台无疑会让产品经理如鱼得水，这也是我喜欢协助创业型公司的原因。我认为目前创业型公司中流行的产品研发模式存在不足，因此很多好创意没能得到投资，走向市场。
目前流行的研发模式通常是这样的：创业者想到一个好点子，得到启动资金后，马上招聘程序员开发产品。由于创始人最清楚要做什么，因此，他通常会扮演产品经理和产品设计师的角色，开发团队则按照他的想法实现产品。这些创业型公司一般在“秘密状态”下运行，很少与用户互动。 另外，由于产品需求和创意往往边做边变化，开发进度相对较慢。
通常要经过半年左右的时间，创业型公司才能开发出可以内测的产品。这个版本往往漏洞百出，开发团队不得不继续修修补补。虽然开发团队没日没夜地工作，但效果并不明显——资金渐渐耗尽，产品依旧末能完成。除非天上掉馅饼，获得额外的投，否则成功的机会很渺茫。为解燃眉之急，有些创业型公司把开发工作外包出去，希望节约成本，但由于没有改进研发流程，问题依旧存在。
我想介绍一种截然不同的产品设计方式，采用这种方式不仅能提高产品的成功率，还能大幅节约创业成本。创业初期只设三个职位：产品经理、 交互设计师和原型开发人员。为节约成本，公司创始人可以亲自担任产品经理，交互设计师也可以由原型开发人员兼任，只要有人负责承担这三项工作(产品管理、交互设计、原型制作)即可。这个团队可以快速展开产品设计，迭代修改。我在第18章详细介绍了这种产品设计流程，这里只重复两个关键点。
1.创建体现用户体验的高保真原型；
2.邀请真实的目标用户验证产品原型。
在迭代设计产品原型的过程中，通常会产生很多版本，这很正常，因为创意每天都会变化，有时是小的变动，有时是大的改进。随着迭代的深入，产品会渐趋完善。这个过程通常需要从几周到两个月环等的时间。采用这种方式的优势在于：可以获得通过市场检验的产品设计；用鲜活的产品原型代替死板的产品说明文档作为开发产品的基础；加深团队对产品需求和后续工作的理解。
确定产品原型后，再招聘程序员进行开发。有了产品原型(代替产品说明文档)，开发人员可以更直观、高效地领会产品设计和开发要求。这将大大缩短开发时间。
借助原型探索产品是制造业的普遍做法，但是在软件行业尚未普及。这主要是因为软件行业有非常强的技术导向性，我们习惯从技术层面着手开发产品，但是创业型公司应该认识到首要任务是确定开发什么样的产品，千万别等浪费五十万美金之后才醒悟。
这种方法不仅适用于创业型公司，也适用于大公司。区别在于，大公司有实力承受多次迭代，确保设计出有价值的产品，创业型公司则不然，但创业型公司的工作效率远高于大公司。如果你打算创业，不妨试试我推荐的新方法。
第29章 大公司如何创新
Innovating in Large Companies
有困难，但值得一试
人们一向对大公司里的创新嗤之以鼻，认为唯有创业型公司才可能创新，大公司只能复制创业型公司的成果，或者千脆收购那些成功的创业型公司。不可否认，创业型公司的氛围更适合创新，但不代表大公司做不到这一点。
没在大公司里工作过，你想象不出在大公司里创新有多难。正如第30章介绍的那样，随着规模变大，公司会不可避免地变得更加保守，不敢冒险。因为一旦失败，比起小公司来，大公司的损失会惨重得多，所以只要情况允许，他们会尽可能维持现状。但大公司也需要创新以谋求发展，何况大公司还有自己的优势。
有两大因素影响着大公司的创新氛围：企业文化和老板的观念。依我看，任何一家大公司都有潜力为自己的员工营造创新氛围。如果你发现在公司里难以实现创新，那么可以尝试以下方法。
20%法则
你也许听说过，谷歌的程序员有20%的工作时间可以用来从事创新研究。二十多年前我在惠普工作时就这样做过，这个方法最早是从施乐帕克研究所学来的，至今仍然行之有效。在惠普实验室，我们的工作任务是技术创新，然后和产品部门合作“孵化”出产品。我所在的小组一共完成了五款产品，有四款是20%法则催生的，剩下的一款产品是公司高管命令我们完成的，结果只有这款产品被市场淘汰了。
人们误以为优秀的产品是战略规划的结果，或是来自公司高管的创意。其实, 最好的创意大多来自于普通员工。20%法则鼓励普通员工自己尝试各种想法，发挥大家的主观能动性，让员工打心底愿意倾注更多的激情和汗水去创新。
20%法则不仅适用于开发人员，也同样适用产品经理和交互设计师。遗憾的是，大部分公司没有采用20%法则，我建议产品公司尝试这个方法。如果公司实在不同意在工作时间创新，那我们只好私下开展“臭鼬工程”了。
臭鼬工程
臭鼬工程是工程界的行话，原指秘密军事行动，现指在受限制的条件下，利用自己的时间，低调地进行创新研究。臭鼬工程拯救了很多大公司。
在大公司里，普通员工很难凭空获得允许从事创新研究。如果你能拿出阶段性的成果来，获得许可会容易得多。在这种情况下，只要不耽误本职工作，管理层通常会支持你的做法。
有一点要提醒大家，有些公司规定员工在职期间研究出来的成果都归公司所有，所以不要随意拿研究成果自行创业。如果公司因为某些原因不愿意帮助你，你才能尝试谋求其他途径来实现自己的创意。了解硅谷历史的人知道，当年斯蒂夫.沃兹尼亚克(Steve Wozniak) 因为惠普公司不愿意进入个人电脑市场，所以离职创业，才有了后来的苹果公司。
主动观察
观察和倾听是最简单的创新途径。仔细观察用户使用公司产品或同类产品的一举一动，留心他们欣喜和失望的表情， 假以时日，你肯定能想出办法更好地满足他们的需求。再找一位熟悉技术的开发人员合作，你们就可以着手改进产品了。
注意，应该选择实际用户作为观察对象，不要选择产品尝鲜者，更不能选择公司同事。测试产品用不着正式的可用性测试实验室，你可以去用户的住所、办公室、购物场所，请他们就地体验你的产品。不仅观察软件能否正常使用，更要留心软件能否满足他们的需求。即使软件可用，他们真的需要吗?究竟他们想解决的问题是什么?
记住，创新不是发现新问题，而是用新方法解决已有的问题。观察人们对现有产品的不满，是创新的最佳途径。
改善用户体验
另一种创新途径是跳出技术局限，完善用户体验。改善用户体验不仅要提高产品的工作效率，更要剔除多余的功能，明白哪些功能是用户必需的，哪些是设计和开发带来的衍生物。
每款产品都有特定的实现模型，但用户脑子里装的是概念模型，他们对产品要解决的问题，以及如何解决问题有自己的想法。如果实现模型与用户的概念模型不一致，用户就会感到失望。找到用户失望的地方，就找到了创新的机会，至少是改善产品的机会。
收购小公司
最后，我们来谈谈“收购”别人的创意。有些产品经理看不起这种做法，其实收购是有效维持创新的手段。创业型公司如雨后春笋般出现，经过市场淘汰，留下来的通常都有其特长，可以作为收购对象。收购创业型公司不仅可以引入新技术，而且可以引入创新型人才，为公司注入新鲜的血液。
我建议大公司的产品经理多和业内活跃的创业型公司建立联系，互相帮助，互相学习。这种人脉关系也许能替公司节省上百万的资金。从以往的经验来看，创业型公司在选择收购自己的东家时，并不是只看重收购价格，他们往往会选择有过合作关系的公司。
妥善安排收购来的新员工，让他们继续发挥特长，才能拓展产品线，保持市场领先地位，但是很遗憾，多数公司没有处理好这个问题。
建议大家尝试以上的方法，帮助公司保持创新。德鲁克曾说过：“公司的核心竞争力在于创新。” 我相信大公司一样可以创新，苹果公司是最好的例子。
更多资料可扫码关注“产品经理读书营”，百人产品经理手把手带你实现进阶。进群即可领取产品大礼包。
