敏捷产品管理之转型

产品负责人是管理产品 Backlog 并确保开发团队交付工作价值的唯一责任人。此角色负责维护产品 Backlog 并确保所有人都可以看见它。                                                                                                                                                                                 —施瓦伯《Scrum指南》

近几年来，互联网应用的涌现和演变在成就了“产品经理”这个角色之外，随着敏捷成功实践的渗透，大家对这个角色也有了更多的期望和要求。

首先，我们来比较下现在大部分互联网公司实行的两种开发模式各自的特征：瀑布式开发和敏捷开发。

瀑布式 VS 敏捷

• 瀑布式

1. 周期漫长。传统的项目模式严格区分了各阶段：需求分析、交互设计、开发阶段、测试阶段、客户验收。这种里程碑一样严格定义输入输出的方式。一旦上一阶段开发达不到要求，不进入下一阶段的开发工作。

2. 重视和强调文档。在开发阶段团队成员将文档作为唯一检验标准，忽略团队成员之间的沟通。成员不了解产品愿景和每个需求背景，按部就班实现需求文档，束缚了开发的创造性，遇见问题只会相互推诿。文档的重要性超过了代码。

3. 合作性较差。团队成员都是独立的个体，每个环节都定义为黑盒，大家只关心手头上自己的工作，对变化比较排斥。

所谓瀑布式开发，即不走回头路，返工成本极大。无法对市场的快速变化作出及时的调整和反馈。

• 敏捷

  
  

1. 快速迭代。把项目按照优先级划细化成颗粒度足够小的 Story，简单设计，以最快的速度推向市场，在实际场景中不断完善。小步快跑，意味着产品交付的时间间隔越短越好，也就是产品有较短的迭代周期，通常是2-4周。传统的瀑布式开发最大的缺点之一，就是产品投放市场的速度太慢。当然，通过这种频繁地迭代是为了与用户形成良好的合作关系，及时反馈，不断地完善和提高产品的用户体验，对于不能给用户或者产品带来价值的功能需求，则坚决不做。

2. 以人为本。减少不必要的文档，留出足够的空间发挥开发人员的创造性。比如之前传统的瀑布式开发要求的使用产品需求说明书来写详细的需求，这个时候我们采用敏捷开发的方法，或许有时候只画一个原型加点备注来告知需求，又或者直接通过口头沟通来告知需求，这就大大简化了项目交付的时间，从而达到了尽早交付的目的。

3. 自组织团队。敏捷需要更强的个人能力和团队能力，实施阶段的任何问题都是团队的问题，每个人都是全栈火枪手，能及时响应变化。

事实上，敏捷的背后是两个在当下非常流行的概念，一个叫做MVP，一个叫做精益分析。从以上来看，传统项目模型更适合大型项目，敏捷项目模式更适合现在瞬息万变的互联网项目，其核心是减小瀑布模型的粒度，采用敏捷开发的优秀实践方式，能快速提高开发的沟通效率，提供项目的全景视图。

那在敏捷转型的过程中，作为产品经理，怎样快速适应市场，快速从一个优秀的产品经理成功转型成一个敏捷的产品负责人呢？

产品经理的敏捷转型

传统意义上的产品经理只是负责新产品的研发，而产品负责人（Product Owner，以后文章我统一简称为 PO) 不仅包含新产品的研发，同时还要对整个产品生命周期进行管理。我眼中理想的 PO 应该是以下几方面的转变：

• 从预言家到实干家

产品经理敏锐的商业嗅觉总能敏锐的抓住市场的机会和用户的需求，像一个预言家一样创造出一个个产品。

而敏捷环境下的 PO 除了能迅速展望最终的产品，清晰的揭示描绘出愿景，最重要的是能见证愿景实现的始终，能和团队成员一起将愿景拆分成一个个Story，解决实践过程中一个个问题，通过快速迭代的方式，不断推出市场试错，最终诞生出一个优秀的产品。

就像通用公司的前主席和首席执行官杰克.韦尔奇说：优秀的商业看领袖创建愿景，清晰勾划愿景，以拥有愿景为荣，然后义无反顾的将其执行到底。

• 从领袖到团队成员

瀑布开发模式下的产品经理在团队中充当一个单一的角色，他更多关注的是市场的变化，用户的体验，客户的需求，以输出需求文档作为最终交付物，等待最终产品的验收。

而敏捷环境下的 PO 既要作为团队的领袖，对于每一个决定提供引导和指引，在实践过程中的必要时刻还要果断的做出决定，同时也要充当创新的守护者，让每一个团队成员都能提供自己的想法，全程参与整个决策的过程。

在团队沟通的部分，我会推荐“一小时法则”，即 PO 每天至少有一小时的时间和团队在一起工作。在团队办公环境上，也可以通过在公共区域展现关键工件: 愿景图、产品 Backlog 、发布计划、燃尽图 ( 具体用法之后文章会详细讲解), 来激发团队的创造性和协作性。

• 从需求提供者到沟通协调者

很多人眼中的产品经理往往代表客户，代表用户，除了能及时的传递客户的需求，还能通过用户调研定义有价值的、可用的产品需求和用户故事，作为开发的基础。

而敏捷环境下的 PO 除了在“意愿”和“技术”之前起到桥梁作用，也要联系团结各方力量: 客户、用户、开发、市场、销售、运营，知道什么时候说"不"，什么时候妥协。知道怎么让开发人员与客户沟通问题，怎么让客户参与到产品迭代的过程中及时反馈问题。开发也能及时响应变化，达到良心循环，共同打造产品。

• 从专业能力到综合管理能力

说起产品经理，大家想到需要具备的能力包括：逻辑能力；分析能力；对行业的熟悉；交互能力；原型工具使用；数据分析能力等。

敏捷下的 PO 除了要具备以上的产品基础的胜任要素，还要包括：对客户和市场有基本的理解；对用户体验满怀热忱；能够清楚传递和描绘需求；管理预算；指导开发项目；能与跨职能自组织的团队良好合作。从专才到全才的转变。

•  从各司其职到相互配合

产品经理往往能独立的输出需求和任务，其他任务的分解交给团队去实施，期间很少参与实践过程。

敏捷模式下有一个角色叫做敏捷教练（Scrum Master，以后文章我统一简称为 SM), 在团队中，SM 的职责是全力支持团队和产品负责人，保证在冲刺的周期内团队以持续有效的节奏完成需求，并且避免技术债。

他与产品负责人的角色始终是互补的，产品负责人负责正确的"方向"，SM负责正确的"方式"，彼此平衡，达到最佳状态。

小结

综上所述，在当今这种不断变化和充满竞争的环境中，需要 PO 具备的能力除了更富有创造性，还需要交付更多的价值。

之后的几篇文章我会从 PO 工作的实践出发，包括如何进行产品愿景描述，如何充分利用开发过程中涌现的新需求，如何打造最基本的可上市产品，如何快速掌握敏捷工件的使用，如何与开发团队紧密合作，带你迅速角色转化。