如何改变产品管理才能实现敏捷企业

　　开发团队采用敏捷时，产品管理会给他们已经超负荷的工作量中再增加更多工作，团队因此措手不及。敏捷需要新的产品管理技巧，传统的人员编制模型一般无法适应新的产品负责人角色。鉴于大多数产品经理已经超负荷工作，他们如何管理这些新的活动，以便从软件项目和产品上获得更多价值？

　　简而言之，敏捷产品经理必须改变他们的工作方式，以赶上更快的开发周期以及更短的客户反馈周期。本文将给出一个成功过渡到敏捷产品管理的概览，指出要避免的常见陷阱是什么，应对新挑战有哪些建议的解决方案。

　　传统的产品管理角色

　　在讨论敏捷组织中的产品经理角色前，让我们回顾一下传统产品经理的角色。在许多组织中，该角色往往是模糊的，而敏捷新的产品负责人角色，并没有让事情变得更加简单。你是一名产品负责人或者产品经理吗？现实情况是，极少数的大学课程致力于产品管理专业，所以大多数产品经理源自不同的背景——从市场营销、工程、售前和售后支持，甚至来自于业务拓展背景——每种背景的观点都倾向于自己的专业。一个组织中的产品经理可能与另一个组织中的产品经理专注于非常不同的事情（这不会让他们更好或更差）。

　　话虽如此，一名“娴熟”的产品经理通常对以下常见任务负有责任：

　　* 定义产品愿景以及路线图
　　* 建立商业案例，以获得资金
　　* 确定发布产品的最佳市场时机
　　* 细分市场，识别目标受众
　　* 识别并跟踪竞争对手
　　* 成为开发团队的“客户心声”
　　* 识别要解决的客户需求
　　* 确定下一次发布要交付的功能
　　* 记录产品需求
　　* 向管理人员和其他利益相关者提供最新的发布状态
　　* 为公司最大化市场发布的影响做好准备
　　* 教授市场部门如何定位产品
　　* 教授销售部门如何销售产品
　　* 教授专业客服如何支持客户
　　* 对发布中已知的“陷阱”和备忘提供支持

　　无论产品经理有何不同，所有传统产品经理有一个共性。他们中很少有人会花很多时间跟开发团队在一起，因为传统的产品经理主要关注战略活动，还有很长的需求文档，让开发团队在未来18个月保持忙碌，18个月是传统软件发布花费的时间。

　　当开发团队采用敏捷时，这马上会改变……

　　敏捷如何改变传统产品经理的角色

　　敏捷引入了一种新的产品管理角色：产品负责人（Product owner）。产品负责人主要的职责是准备产品backlog、给开发人员介绍故事并给开发团队充当“客户心声”。

　　由于敏捷软件开发更快的开发周期，产品负责人的角色给开发人员与客户之间提供了关键的接口，在每个sprint结束时快速搜集客户反馈，并适应不断变化的客户需求。这是传统开发方法中非常缺失的角色，在客户意见非常少的情况下，开发工作却可以进行数月，导致软件行业众所周知的不良统计——罕有在预算内完成的项目、经常为时已晚、对客户没多大价值。

　　从本质上说，产品负责人的角色是把产品管理嵌入到开发团队中，以此提醒开发人员他们的决定应该由客户价值来驱动，提醒产品经理并非所有功能在技术上是平等的，并以此积极回应市场和客户在产品发布之前不断变化的需求。

　　终于可以建立起响应客户需求的解决方案，这听起来是梦幻般的消息，然而，产品经理的负担通常在拥抱敏捷之前就已经很重了。

　　产品负责人的角色很耗时间：在sprint计划上，产品负责人给开发团队介绍接下来几周要着手的故事。在sprint中（通常是1到4周），她监视进度、阐述故事细节、验证完成的故事并为下一个sprint做故事调查。对于大多数产品，这可不是一份兼职工作！据Enthiosys这样的产品管理顾问公司评估，软件团队采用敏捷时，产品管理的工作量会增加50%左右。

　　那么我们先前列出的传统产品经理的任务有什么变化？谁与客户需求保持联系？谁去掌握市场趋势和竞争对手的动向？谁去评审最近销售的得失？谁为新产品制定包装和价格？谁去指导销售团队和支持团队新的功能？

　　除非在你的团队中有超级英雄般的产品经理——那些晚上只需要4小时不到的睡眠时间、而且没有工作与生活的平衡、可以接受50%更多工作的人——否则总有事情会搞砸。

　　避免一人独大的陷阱

　　团队采用敏捷时，产品经理往往不是开发团队的正驾驶，而开发团队则越来越习惯敏捷实践——从短时间盒到持续集成和测试驱动开发。那时，往往是技术领袖承担产品负责人的角色。一旦开发团队熟悉了这些关键的开发概念，并开始更快速地交付更好的软件，他们就会想要确保他们的努力会给用户带来更大的价值，那时，产品负责人的角色需要一些“真正的”产品管理技能。通常，这就是传统产品经理被拉进来参与敏捷体验的时候。

　　我见过的最大陷阱，是简单地把已有的产品经理转变为产品负责人。每个人都关注于采用敏捷时，这似乎是自然而然的转变，但代价沉重。当公司陷入该陷阱，鉴于工作日仍然只有8到12小时，传统产品经理被迫决定他们以后每天的工作重点时，有两件事情会发生：

　　最常见的情形是，产品经理完全接受她新的产品负责人角色，学习编写好的故事，并去了解她的开发团队。这通常是非常激动人心的时刻，尤其是如果你有一位中立的敏捷教练，不去指出在许多年没有协作后可能会发生的事情时。但是，这让产品负责人没有时间去做传统的产品管理任务，因此那些工作就半途而废了。风险是一个非常高产的开发团队在错误的时间，交付以错误价格启动的软件，销售和支持不足，导致产品无法满足目标受众，并带来预期的收入。软件失败往往由市场失败导致，而不是开发失败导致，因此在只配备产品负责人角色（但没有留下产品管理资源去完成最需要的、战略性的产品管理任务）的情况下，交付解决方案给市场时，会冒着失败的风险。

　　一个不太常见的情形（但影响相同）是产品经理不接受产品负责人的角色。当产品经理有更多“全局性”的谋略，并对产品负责人日常的战术职责不感兴趣时，就会发生这种情况。此时，团队的需求不清，困难重重，在他们前进时总在不愉快地做假设，因为问题出现时没有“客户的心声”。一个要监测的红色警示是用户故事没有验收标准。由于传统产品经理不会参与需求的验证（最常见的是质量保证小组），编写验收标准经常是一种挑战，并很快就被忽视。没有定义良好验收标准的故事，冒着在sprint结束时不被接受的风险，当产品负责人和开发团队忙于“但我以为你认为……”的讨论时，会令人沮丧，并需要代价高昂的返工去修正原来的故事。当完成标准（definition of done）没有明确的验收标准时，其代价是故事不断被返工，相关的开发生产力也会下降。

　　因此，公司转向敏捷时，产品管理怎么去适应，并避免上面讨论的陷阱呢？

　　产品管理适应敏捷需要的实用建议

　　让我们来探讨一些经验教训，我真希望当我从传统产品经理转变为敏捷产品经理时，我已经了解到这些。

　　停止不交付实际客户价值的工作，无论是直接还是间接的，并沟通你将要停止的工作。这似乎是一种明显的倒退，但如果你真地采用这种思维状态，你会发现真的有许多小事情不会给客户带去任何价值。例如，在你的组织中，有没有报告是某个人自己用来追踪，却只有很少的客户价值？或者你是否一直在开发销售工具，却对销售团队没有多少价值？

　　偏爱现场交互胜过冗长的文档，无论它是描述业务案例还是经营管理，或是记录需求。这是一个方面，你可能要有一种信念，那就是相比那些闭塞的需求文档（以及比萨），值得信赖的开发人员更具创造力和生产力。要相信：当人们被赋予做决定的权力时，他们会竭尽全力。

　　实践严格的优先级排名。需求、业务目标或者你们日常的活动是否排列过优先级，分配实际的优先级数字而不要使用MoSCow优先级方法（必须有must-have，应该有shold-have，可以有could-have，不会有won’t-have），通常最终会有太多的必须有和应该有。如果这种做法对你有点困难，那就假设某天你只有一名开发人员。那么你会让他做什么？那就是你首要的需求。

　　拥抱变化，把它当作机会而不是威胁。实际上这可以成为产品经理的巨大负担。基于过去sprint中接收到的客户反馈，每个 sprint都去重新评估团队将要从事的工作。你不必在一份巨大的、需要花费18个月去完成的需求文档上签署名字而远离了你的生活。你甚至可以犯错，并在 2周后纠正那些错误。

    识别关键的产品管理任务

    对所有的产品管理任务排列等级。咱们来看看：采用敏捷时，大多数产品经理会对新加的产品负责人角色不知所措。一定要识别出哪些任务对你们产品的成功最为关键，直到你的产品管理团队配备了足够多的人员，去履行新的敏捷职责。减少甚至丢弃一些其他任务（至少是当下），并清晰地同你的组织沟通你的侧重点会在哪里、什么可能不再会交付。至于所有产品管理任务的概览，可以参考实用的营销框架（Pragmatic Marketing Framework），该文档最近为响应产品负责人这一角色更新过。

　　不要放过战略部分。你们选择的关键产品管理任务应该有良好数量的对内任务（关注于团队），以及对外任务（关注组织的其他方面和组织外部）。对内和对外工作的比例可能不同，这取决于你们正在开发的软件，以及你们产品的市场定位。例如，对于一个完善的产品，每次有新的发布时，不需要像一个崭新的产品进入崭新的市场一样，实施很多销售工作。

　　配备适合的人员去履行新的角色和职责

　　假设你需要三头六臂。在极少数情况下，一个人既可以是产品负责人（策略上对内的角色），又是产品经理（策略上对外的角色）。可以开始考虑谁能帮助处理一些产品管理的任务。固执的组织结构会让这成为一个挑战，因此获得管理层的支持可能会有帮助。如果不行，同大家说清楚你在分身乏术的情况下，什么是无法完成的。

　　授权承担产品负责人角色的人能够接触到团队，一旦完成故事，要求他们去验证故事。最重要的是，不要让产品负责人把履行对外工作作为其首要的团队责任，从而分散弱化了产品负责人的主要职责。

　　小心配对个人和产品管理的角色。为了实现这两个战略和新战术上的产品管理功能，选才时要对号入座。一般的指导原则是，善于分析和注重细节的人往往能当好产品负责人。关注大局、外向的人往往能当好产品经理。业务分析师可以成为很好的产品负责人，产品营销经理非常适合一些战略性的产品管理任务，比如竞争对手分析、为发布启用销售和技术支持。不要太执着于职称——它们会造成障碍——给人员分配产品管理任务时，要分配他们熟练并有激情的任务。如果你很幸运，在你的产品管理队伍中有人同时擅长战术和战略方面，可以考虑按功能分割他们的时间，而不是用战略/战术路线来分割。例如，某个人同时为某个功能集担当产品负责人和产品经理的角色，而另一个人为其它功能集同时担当两个角色。在这种情况下，这两个人要腾出时间站在一条战线上，共享共同的产品愿景和发展路线。

    更加接近你的客户

　　了解要交付的客户价值。敏捷主要关注于交付客户价值，并消除浪费活动，因此你必须找出一种方法，让你可以更加接近你的客户。客户互动的方法和实践有很多，以下是我最喜欢的三种：

　　投入到社交网络中。社交网络的出现为产品经理提供了一个有效的机制，让他们不需要跨越全球就能与客户互动。它对功能的优先级还有达尔文效应，用户可以自行提高或降低功能的优先级。只要你知道与你积极互动的用户的相对数量，这种对话可以非常富有成果。除非你所有的用户都是参与者（迄今罕见），否则社交网络存在着风险，那就是让用户子集驱动你的产品路线。欲知更多有关产品经理使用社交网络的情况，可以关注 Forrester的Tom Grant最近所做的工作。

　　利用你组织里的其他人，尤其是那些天天与客户交流的人——销售、销售工程师、支持工程师以及顾问。假如你的组织在全公司内有效地使用诸如Salesforce.com一样的客户关系管理系统（CRM），那么你可以利用这一个技术，将客户意见汇集起来。使用CRM系统来采集客户档案和收益潜力时，它可以成为一个金矿，产品经理可以调阅该系统，评估某个功能请求在其客户群体中的重要性，同时也可以迅速确定由哪些客户来验证某些功能。客户越是关心某个功能，你越可能迅速得到真实的反馈。在 Forrester 的这篇文章中，可以了解更多有关CRM系统可为产品经理做些什么的内容。

　　投入到产品理事会中。如果你无法采纳以上两种方法，你仍然需要听听那些与客户交谈的人。一个节省时间的方法是建立一个由跨职能代表组成的产品理事会。每个月你都倾听来自业务上方方面面的意见，搜集大家的意见并加入到产品路线中。阅读博文使用产品理事会来驾驭你的开发可以了解更多这方面的内容。

　　磨练你的产品管理技能以适应敏捷的需要

　　经常更新你的产品路线，让它们成为有效的沟通工具，而不是合同的重担——至少一个季度一次，但我喜欢每个月一次。包括明确的“基于客户反馈的变更主题”的公开声明，用以加强你们做变更的开放性，同时澄清敏捷产品路线事实上代表着一种意图，而不是承诺，你们的承诺是交付价值，而不是具体的功能，因为客户需求改变时那些功能马上就会改变。

　　学习把路线功能分割到sprint故事中 。Standish 集团的研究发现，45%的功能从来不会被使用，只有20%的功能经常或总是被使用。我们的目标是侧重在20%必须具备的功能上，并放弃其余的。往往我们开发了过犹不及的功能，却发现只有很少用户会使用它们，或者它们会增加产品的复杂度。把重点放在交付某个功能绝对必须具备的故事上，并让用户告诉你他们何时需要更多功能。使用短发布周期，你很少会有兴趣把精力放在市场价值低的功能上，并可以在下一个发布中对用户需求做出快速响应。同时如果你的客户无法接受1年多次发布的频率，你仍然可以向他们演示新增的功能以获取他们的反馈，让他们对明年的发布感到兴奋。确定20%重点关注的功能，要把功能分割成小而有价值的故事，在每个sprint结束时逐步交付。掌握这种分割方法是最需要磨练的技能之一。请阅读“切割故事的20种方法”，以了解分割故事却仍能交付价值的方法。

　　让你的故事（以及它们的验收标准）保持直白。在你们产品的backlog上，最顶上的故事应该要充分调研，在sprint计划会议上介绍给团队时，要没有歧义。正如之前提到的，不要跳过验收标准，或者准备好返工的代价。与测试人员协作，最后确定每个故事的验收标准清单。我发现调研故事以及访问客户的最佳时机是在sprint开始，当开发人员有足够的工作时间，而且往往问题也很少的时候。

　　总结

　　当我们了解情况后，就知道采用敏捷并不代表产品经理的结束。你会面临的最大转变是某个拥有产品管理经验的人会嵌入到开发团队中。恰当地配备好人员并履行新的产品负责人角色，同时不丢失产品管理战略角色的位置，是改变产品管理实现敏捷企业的关键。

　　那些没有按照敏捷需求重新评估新的产品管理角色，用他们当前的产品经理来勉强应付敏捷管理的组织，无法完全享受到实现敏捷企业的益处。那些利用实用指导的组织则会处于让人羡慕的境地，总能给他们的市场交付富有竞争力的解决方案。

　　我真心希望这篇文章可以帮你避免一些常见的陷阱，我个人过渡到敏捷产品管理时已经经历过，与你分享的实用提示可以辅助这种迫切需要转型的公司过渡到敏捷上。欲了解更多信息，请下载在2009敏捷大会上演示过的关于本文重点的幻灯片。

　　关于Catherine Connor

　　Catherine Connor目前是Rally软件的产品负责人，她在那里负责推动Rally整套的敏捷管理方案。此前，Catherine把一个富有创造力的产品管理方案推向了市场，整合了敏捷项目管理和客户关系管理系统，以缩小客户、销售和开发人员之间的距离。在Rally任职前，Catherine在Borland 软件工作，她在那里开始应用敏捷方法，同时她是用IBM Rational软件产品做需求管理的积极支持者。她的经验使她很适合记录从传统产品管理过渡到敏捷产品管理的最佳实践和陷阱。Catherine的编程经验，以及实现软件方案时对软件客户的支持经验超过20年。