摘要： 小白叨一叨：随着互联网的不断发展，互联网产品的日新月异，产品经理也必须从老一套的思维中走出来，才能在现代的竞争中脱颖而出。在从旧到新的演化中，将会遇到哪些挑战呢
小白叨一叨：随着互联网的不断发展，互联网产品的日新月异，产品经理也必须从老一套的思维中走出来，才能在现代的竞争中脱颖而出。在从旧到新的演化中，将会遇到哪些挑战呢?来看看 Eric Ries 是怎么说的。
当你处于一个传统的“瀑布模式”工作流程中时，不论你在里面扮演的是什么角色，都会让你有种无力感。特别是对那些在正将新产品推向新市场、大量工作的创业公司中工作的“产品经理”来说，这种感觉是更强烈的。最近我见到了一个真正意义上的负责新产品的产品经理，他和他的开发团队告诉我的故事让我觉得无奈。很明显，这个产品经理努力想从团队中其他人那里获得结果。这些聪明人保持着前进的一致性。
那么，为什么他们还会有那么多的困难呢?
让我们从这个产品经理做什么开始说起吧。按照常理来说，他是定义产品做什么的那个人。他编写详细的产品需求文档，这些文档详细地说明了团队在下一个迭代中应该构建什么功能。将这些需求交给一个设计人员，让他构建所有主要功能点的排布和模型。然后把设计图交给一个具有各种专业开发人员的团队。大家各自负责自己的部分(UI，中间件，后端)，并进行对应的编码。最后，QA团队基于规格说明构建一个测试计划，通过测试功能来评估它们是否能正常运行。
这个系统本身是适合产品经理组织的一般流程。尽管程序员不构建下一个主要功能，但他将忙于编写程序。如此一来，当他们在开始下一个迭代之前时，就不会有任何的闲暇时间。如果程序员空闲，对产品经理来说可不是件好事，因为他本就应该忙于构建产品。否则，公司就是在浪费大量的金钱。
当我见到这个团队时，团队成员之间针锋相对的局面已经形成了。最后构建出来的几个功能跟最初定义的大有不同，需要花相当长时间才能正常运行。程序员一直询问很多有关他们设计和方向上的问题。所以团队正在并已经花越来越多的时间在讨论需求和设计阶段，试图让团队认同正在构建的东西。然而，由于某种原因，尽管团队增加了认同感，最终的产品已经看起来不像最初定义的那么一回事了。VP工程花了所有时间试图确保程序员理解并实现规格要求了，每个迭代花费的时间比之前的还长，各种沮丧负面的情绪不断增加。
没过多久发现产品经理正被责令对每个需求说明书写5次。第一次，他写的工整清晰。接着他和设计人员构建出设计规格，和QA构建出测试计划。当开发人员拿到需求后，他们经常和PM谈判将构建什么。他们交流了许多封的邮件，也因为这样，产品经理时常被打断叫去阐明需求的精确含义。第四次，需求说明仅存在于邮件中，这些邮件会导致表达偏差。当QA拿到功能的时候，他们的测试计划已经严重过时。所以，产品经理上不得不使用该软件、着手更新原型、帮助创建一个新的测试计划。自然地，产出偏离得这么严重，以至于他必须重写当前正在进行的需求(铺垫下一个主要功能)，并把它们一并考虑在内。
讽刺的是，设计这个系统是保证每个职能都能得到100%利用，所以包括产品经理在内也没人偷懒。但是随着迭代次数的增加，产品经理花越来越多的时间来回答问题。这些打岔的事情是这么的糟糕，以至于他得在凌晨3点起来写他的新原型，这只是为了确保工作流程的完整。
这到底出了什么问题?每个人都全力以赴、投入110%的精力工作。但是团队却越来越落后。
下面是我给这个团队的一些调整的建议：
首先，在跨职能团队中工作。每个团队有一名各职能代表。首先，我们尝试一名产品经理、一名设计人员、一名或两名程序员、和一名QA。这个团队拥有一个完整的点对点特征。
其次，关注迭代速度而不是利用每个职能。如果不能帮助当前迭代成功，就让他们偷懒去吧。我一直惊讶究竟有多少人尚未开发他们的潜力。他们不想要空闲。通过让他们关注自己团队的成功，你就可以授权他们做任何可让团队成功的事情。那是否意味着设计组人员可以加入QA帮助测试认证发布的版本呢?让我们拭目以待吧。
最后，将需求过程的推动转化为拉动。以一页的规格开始，不要再多。接着，让团队在他们需要阐明的任何时候询问产品经理问题。作为交换条件，团队成员统一展示每块工作情况给产品经理看，并获得他的许可。他们发现差异点的速度将会快很多，并及时进行解决。而且，团队将会越来越擅长解读只需书写一次的简明规格说明。(最后，他们可能会一起取消规格说明书。)会有更多的方法让这个团队来消除工作方式上的浪费，因此达到迭代更快的目的。最终，我希望让他们进行全面的敏捷开发过程：带有测试驱动开发、日常例会、冲刺、结对编程，等等。但是首先我觉得我们需要将产品经理从老一套的“瀑布模式”的折磨中拯救出来。一旦团队中不同成员能再次互相信任，我们就有了启动一个真正连续改进反馈回路所需要的基础。