从项目转型为产品

关键点

• 敏捷转型意味着产品思维而非项目思维。
• 敏捷是观念模式，而不是一系列需要遵循的规则。它需要的是文化变革而非改变流程。
• 敏捷改变了我们衡量项目成果的方式，也改变了我们评价人员行为的方式。
• 变革是困难的。
• 项目管理和人员管理是最需要变革的方面。

有个老梗是这么说的：敏捷转型很简单，你只需改变两件事：所说的一切和所做的一切。

这个笑话浅显易懂，但显然它也是错误的。你要改变的只有一件事，那就是你的思维方式。

项目或产品

我向来认为，当我们谈到敏捷转型，我们说的是转变我们的思维方式。以前我们以“项目”的思维看待交付，现在则要变为“产品”思维。以前我们考核人员是看他们的工作量，现在则是看他们对一个共同目标的综合贡献（也就是他们增加的价值）。

项目：“一项独立或合作的事业活动，经过精心策划和设计以实现特定目标。”

产品：“一种事物，创造或改进它的目的是满足某种需求。”

一如我们所见，软件产品的开发工作是很复杂的。一方面来说，这种复杂性体现在开发工作自身，我们会面临一系列无法预知的可变因素、难题和未知事项。但更复杂的一方面在于，除非我们亲眼见到了自己需要的东西，否则我们很难发现自己的真实需求。结果，有大量优质的软件产品并没有有效满足客户的需要。

经验告诉我们，经常与利益相关者回顾进展，并基于其反馈进行调整的做法对产品的成功大有裨益。

大多数情况下，对于复杂和定制的软件解决方案，无论你们之前的分析做得有多到位，想从一开始就预测到最终状态是不可能的。而不管我们多擅长做计划，如果不知道最终状态，我们的计划就会存在缺陷。鉴于我们无法预测未知因素，就算最好的计划也是不可靠的。

我们开始意识到，定制软件的交付更接近产品的设计和开发，而不是项目交付。

所谓管理就是把事情做正确；所谓领导就是做正确的事情。——彼得·德鲁克。

敏捷转型就是从管理到领导的转变

彼得德鲁克给了我们启发。过去我们太注重把事情做正确、注重效率提升，或者是在这个那个限期之前完成这件那件工作。我们忘记思考自己所做的事情是否带来了价值。我们所有的重心都放在了考核和监测工作量或效率上，却不去评估我们是否在实现当初的目标。

如果你在考虑进行敏捷转型，你可能已经发现“管理”项目的努力会走向错误的结果，应该把关注点从工作量转向价值。我们应该确定方向，并“引导”产品开发的路线。试着不再去考核输出，而是开始评价成果。

对项目经理和商业分析师的影响

但是对多数公司来说这是一项重大的文化变革，实施起来并不轻松。这是整体观念的转变，从规划“项目”的交付转向合作创造“产品”。

对项目经理来说这尤其困难。

有效的项目管理需要“大致”了解最终状态，这样才能用熟悉的步骤以“大致”可预期的方式走向终点。知道了最终状态，制订了可预期的步骤之后，项目经理就能有效地实现目标。

但定制软件实在太复杂了，通常涉及许多不可预测的可变因素。其中最大的可变因素就是最终状态。多数案例中一开始是不知道最终状态是怎样的，其形态要随着产品开发推进而逐渐浮出水面。真正的最终状态所要满足的需求，经常会和初期预测的相差巨大。具备基于新增信息进行灵活转向的能力和弹性，对于交付价值、开发成功产品而言是至关重要的。

项目经理通常认为转向敏捷思维模式是最艰巨的任务，因为他们的角色受影响最大，最终反而变得无足轻重。同软件打交道时，太多传统的指标都被颠覆了。当你不再假设定制软件开发是可预期、可重复的工作，并开始认识到每个项目或产品都是独特、非定义的，那么事情就会变得容易些。软件开发中也可能会有项目管理的一席之地，但也不是按部就班地管理产品，或是管理客户和利益相关者的预期。

商业分析师也必须适应新形势。项目规划通常需要在规划时了解尽可能多的信息，获取这些信息非常依赖商业分析师的工作。而产品开发对商业分析师也是一种思维转变。产品开发不再需要提前获知细节，实际上，在大多数情况下，这种工作是在浪费精力，因为随着产品开发的进展，我们得到的信息越来越多，我们的方向和优先级也会频繁发生变更。

敏捷软件产品开发中，商业分析在早期阶段只需要大方向的评估，而细节分析应该发生在工作快接近尾声的时候。此时对实际需求的了解更加丰富，于是我们就不用浪费精力去分析那些不准备做的事情了。

对于商业分析师来说转型更容易些，他们的角色变动幅度不大，改变的主要是时间安排，与客户的对话发生在工作结束之前。分析师通常可以成为很好的产品负责人，因为他们关注的重点就是识别客户的需求。

敏捷思维模式

敏捷首先是一种思维模式，如果深入了解敏捷，我们会发现其中并没有全新的、原创的内容。我们会惊奇地发现，虽然过去 20 多年来软件产业频频用到敏捷这个词汇，但其中的行为实践只是一般管理方法中的那些优秀行为实践，后者的历史可以追溯到一个世纪，甚至一两千年之前。

“敏捷”，不管我们谈到的是 Scrum、看板、精益、精益创业或是其它的许多敏捷框架，多数情况下都是一系列有历史意义的优秀实践与指引的集合。这些实践和指引由过去成功的领导者和商业案例所定义，然后用一套概念进行包装和宣传。宣传包装工作非常成功，这大概也就是你们会来读这篇文章的原因。我是想说“敏捷”并不是什么全新、未经检验的概念。当然其中存在不少误用、扭曲的理念，但其原则是稳固的，是基于大量经验的。

举一个例子，如果你回顾百年前福特汽车的案例，用今天的敏捷标准去评估他们的做法，我想他们是做的非常出色的。

敏捷转型不应该是目的

敏捷转型经常被当作是一个目标，而现实中它应该被视为达成目标的策略。花些功夫搞清楚真正的目标是什么，就能让转型更容易取得成功。

• 你们的客户是否不满意？
• 你们的产品是否未能达成预期？
• 你们（或你们的客户）是否认为你们没在创造价值、赚取收益？
• 你们是否跟不上市场节奏？
• 如果你们在为内部团队开发软件产品，他们的反应是否没有符合你们的预期？
• 人们是否拒绝使用你们的工具？
• 你们在软件开发上的回报率是否过低？
• 你们是否在流失重要的开发成员？
• 软件开发的流程是否缺乏透明度？

以上只是公司想要进行敏捷转型的诸多原因中的一部分。这些是全局性的商业问题，这正是关键所在：敏捷转型并非只是软件部门的活动，它改变的是整个商业模式。它是一项重大的文化变革，从上至下彻底影响我们的商业活动。从我们销售产品的方式到招聘人员的做法，尤其是看待成功的方式，都会随之发生变化。

传统变革管理

敏捷转型正是一种传统变革管理的模式。“敏捷”的重心是文化变革而非流程变化，因此它无需被限定在软件行业。如果你们的公司迫切需要改进，愿意采取行动，创造拥抱变革、持续进步的文化，那么你们就已经迈出了第一步，也是最重要的一步。但这也是多数公司走得最艰难的一步。

如果你们转向敏捷只是因为听说它卓有成效，想藉此改变流程，却不愿触及公司文化，那么你们很可能会陷入困境。

如果你们考核团队的方式一如既往，那么团队的行为和考核结果也会一成不变，依旧是你们想要改变的那个老样子。

衡量标准

敏捷的程度取决于你们赏罚哪些行为

很多小公司创业时非常敏捷，他们必须如此，这是生存所迫。从失败中学习、适应、进化并思考是至关重要的。我们经常会听到成功的创业公司谈到，快速学习失败的教训对他们帮助多大，以及他们所有的努力都朝向共同的目标。但是当公司越来越壮大，他们开始“成熟”，组织变得复杂，责任变得分散，对待失败的态度也从正面变成了负面。公司不再有共同的目标，各个部门都有了自己的算盘，部门目标与公司的前景缺乏关联。

各部门有自己评价的目标，团队有目标，个体有目标。我不是说目标是坏事，如果它们不和组织的共同目标相关，那么就算不上什么好事情。这类目标会导致相冲突的行为和活动，不仅不会帮助公司前进，更有可能让公司离目标更远。

静下心来想一想，你们的组织是不是经常需要做一些事情来达成公司目标，比如交付产品或招聘更多人员。但这只会让你们依赖另一个团队或个体，可那个团队不会或不愿解决你们的问题。IT 支持（抱歉拿你们举例）通常是个典型的例子，为了启动新产品对防火墙做出简单的变更就需要花费几周来做计划，或者新人到任后整一个星期后才能拿到配备的新电脑。

这类麻烦搞得我们团团转：人头数是有限或不变的，于是我们只能“暂时”雇佣费用更高的合同工来满足需要、实现部门目标。这类情况的问题在于，它们是因为部门目标与公司目标不一致而产生的。或者目标被误读，导致部门间互相竞争或无法合作。

如果公司明确指出产品发布是最高优先事项，那么 IT 支持就会知道自己该在哪些方面做出努力。如果目标是削减开支或限制人员数量，那么回避这一目标无助于共同目标的实现。类似的，冻结招聘可能会妨碍盈利。

最大的障碍

人们的行为取决于受评价的方式。对于敏捷转型来说，最大的障碍在于项目管理和人员管理。这恰恰是因为敏捷改变了我们评价项目成就的方式，也改变了我们评价人员行为的标准。

告诉我你怎样评价我，我就会告诉你我会怎样行事。——艾利·高德拉特博士（企业管理大师）

项目经理会定期受考核，考察项目是否处在正轨。每周他们都会报告项目的状态：

是否如计划行事？是否符合预算？是否按时推进？是否超出范围？

于是他们尽一切努力避免项目超支、超时、超出范围。你会问，这有什么问题？项目经理按照预期行事，并因此获得奖励。

然而问题在于，让项目“保持正轨”不应该是公司的目标。如之前所提到的，软件产品很难预测最终状态，所以向最终状态前进是不可行的。我们需要改变目标，目标应该是满足需求，并且前提是无法基于未知的最终状态进行评价。

我们的目标应该是交付正确的产品（创造利润的）并保持客户满意度。几乎不曾有初始的项目计划能符合这一目标。所以关注于纠正错误的事情并不会帮助我们实现目标。

项目管理是把事情“做”对；产品领导是“做”对的事情。

（无耻地阐释彼得·德鲁克的名言）

在将传统的项目管理应用到复杂软件产品时，是把“错误”的事情做对（按时、不超支、在范围内）。敏捷产品领导则会接受这些现实：计划可能是错误或不清晰的，范围是未知的。由此敏捷会适应变化并做正确的事情，以满足我们客户的需求。

当项目经理调整并改进项目计划，以使其一直符合目标、跟上变化的需求并应对突发事件时，他们就应该得到奖励，升为领导。但更常见的情况是，他们尽可能强制让突发事件和现实去符合他们的计划，于是“管理”项目的结果是让项目越走越偏。

换句话说，他们的行为取决于你们的考核方式。在你们的下一次项目状态会议上，想想你们要问什么：你们是在要求项目经理展现对客户和现实情况的意识，并表明他们在应对变化，还是因为他们说项目一切正常、没有问题就奖励他们？

没有问题才是最大的问题。——大野耐一（丰田生产方式的创始人）

考核价值还是工作量

相比价值而言更看重工作量，这是所有层级都会发生的问题，它在个体层级也同样是有害的。如果在每日站会中你们问到“你们今天做了什么？”，这就是一种无形的压力，要求人们表现出忙碌的样子。当然大家就会因此找事情去忙了。考核效用不应该是一项目标，而客户满意度、交付价值以获取收益、创造增长和新的机会才应该是更有价值的目标。

试着改变每日站会的内容，问大家“你做了哪些事情来帮助团队以实现目标？”，这是一个完全不同的问题，不会鼓励人们为了做出忙碌的样子而完成那些不重要的工作。这会鼓励团队去寻找那些能实现价值的工作，而不是白忙活。要奖励帮助团队实现目标的人员，并让人们为忙于不能帮助团队实现目标的工作（不管那看上去多有用、多有效率）负责。

让你们的站会从：**“我们今天要做什么？”改成“我们今天怎样能帮助团队实现目标？”** 能让行为变得大为不同。

敏捷实践和原则

你会注意到我讲了很多关于组织变革的内容，你们考核的方式本质上决定了你们公司的文化。但我几乎没有提到敏捷实践和原则，我这是经过深思熟虑的。如果你们的组织明白，需要进行文化变革以关注公司的真正目标，那么你们的文化就会反映这些原则。如果你们学会基于对公司目标的贡献进行考核并奖励成就，而不是关注于小事情的优化，那么就能很容易地接受敏捷（或者说不那么困难了，鉴于旧有的习惯难以改变）。几乎所有的敏捷框架共同的观念就是鼓励系统层面的思维，并发扬这种类型的文化。

但如果敏捷没有成为你们文化的一部分，那么你们的转型就会卡壳，因为新的实践在用旧的一套规则来评价。这样你们得到的结果不会是敏捷，相比过去可能也没什么改善。文化变革很困难，但这样做是值得的。

敏捷文化

我觉得敏捷运动中的这个说法效果适得其反。我们的目标是进行文化变革以改进组织，使用最佳的实践和工具来实现公司目标。如果我们认同这只是出色的商业直觉，并拿掉敏捷转型这个术语，那么我们可能会更好地理解在组织中发起文化变革的意义所在。

你们的商业部门可能会说：我们哪里需要改进？我们要怎样衡量是否成功？敏捷转型可能是实现这一目标的方式。

如果你们选择了敏捷转型，你们对成功的看法将是交付客户需求的内容、创造快乐、满足客户，而不被计划捆住手脚。你们考察团队成就时会看他们是否愿意学习和成长。通过授权团队决策自己的事情，你们就能创造持续进步的环境。

改变是困难的

改变是困难的，我们总是低估了困难的程度。我们更喜欢新瓶装旧酒，假装拥抱了新事物。可悲的是很多框架也吃这一套，提供的解决方案只会让所有人照旧做事，只是加个站会就说这是敏捷了。事实上转向敏捷思维模式是对未来的投资，如果你们不想付出努力进行这项投资，只会重蹈覆辙。

关于作者

John Yorke是 WWT Asynchrony Labs 的敏捷教练。他在 Asynchrony 中主管产品负责人分部，在圣路易斯开设了产品负责人研讨会。John 作为开发者、设计师、项目经理和部门领导，在软件交付领域有超过 20 年的工作经验。如今，他作为教练帮助客户进行敏捷转型，同时培训内部的交付团队。他也是敏捷领域话题的作者和演说者。

查看英文原文： Transforming from Projects to Products

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。