关键点
- 敏捷转型意味着产品思维而非项目思维。
- 敏捷是观念模式,而不是一系列需要遵循的规则。它需要的是文化变革而非改变流程。
- 敏捷改变了我们衡量项目成果的方式,也改变了我们评价人员行为的方式。
- 变革是困难的。
- 项目管理和人员管理是最需要变革的方面。
有个老梗是这么说的:敏捷转型很简单,你只需改变两件事:所说的一切和所做的一切。
这个笑话浅显易懂,但显然它也是错误的。你要改变的只有一件事,那就是你的思维方式。
项目或产品
我向来认为,当我们谈到敏捷转型,我们说的是转变我们的思维方式。以前我们以“项目”的思维看待交付,现在则要变为“产品”思维。以前我们考核人员是看他们的工作量,现在则是看他们对一个共同目标的综合贡献(也就是他们增加的价值)。
项目:“一项独立或合作的事业活动,经过精心策划和设计以实现特定目标。”
产品:“一种事物,创造或改进它的目的是满足某种需求。”
一如我们所见,软件产品的开发工作是很复杂的。一方面来说,这种复杂性体现在开发工作自身,我们会面临一系列无法预知的可变因素、难题和未知事项。但更复杂的一方面在于,除非我们亲眼见到了自己需要的东西,否则我们很难发现自己的真实需求。结果,有大量优质的软件产品并没有有效满足客户的需要。
经验告诉我们,经常与利益相关者回顾进展,并基于其反馈进行调整的做法对产品的成功大有裨益。
大多数情况下,对于复杂和定制的软件解决方案,无论你们之前的分析做得有多到位,想从一开始就预测到最终状态是不可能的。而不管我们多擅长做计划,如果不知道最终状态,我们的计划就会存在缺陷。鉴于我们无法预测未知因素,就算最好的计划也是不可靠的。
我们开始意识到,定制软件的交付更接近产品的设计和开发,而不是项目交付。
所谓管理就是把事情做正确;所谓领导就是做正确的事情。——彼得·德鲁克。
敏捷转型就是从管理到领导的转变
彼得德鲁克给了我们启发。过去我们太注重把事情做正确、注重效率提升,或者是在这个那个限期之前完成这件那件工作。我们忘记思考自己所做的事情是否带来了价值。我们所有的重心都放在了考核和监测工作量或效率上,却不去评估我们是否在实现当初的目标。
如果你在考虑进行敏捷转型,你可能已经发现“管理”项目的努力会走向错误的结果,应该把关注点从工作量转向价值。我们应该确定方向,并“引导”产品开发的路线。试着不再去考核输出,而是开始评价成果。
对项目经理和商业分析师的影响
但是对多数公司来说这是一项重大的文化变革,实施起来并不轻松。这是整体观念的转变,从规划“项目”的交付转向合作创造“产品”。
对项目经理来说这尤其困难。
有效的项目管理需要“大致”了解最终状态,这样才能用熟悉的步骤以“大致”可预期的方式走向终点。知道了最终状态,制订了可预期的步骤之后,项目经理就能有效地实现目标。
但定制软件实在太复杂了,通常涉及许多不可预测的可变因素。其中最大的可变因素就是最终状态。多数案例中一开始是不知道最终状态是怎样的,其形态要随着产品开发推进而逐渐浮出水面。真正的最终状态所要满足的需求,经常会和初期预测的相差巨大。具备基于新增信息进行灵活转向的能力和弹性,对于交付价值、开发成功产品而言是至关重要的。
项目经理通常认为转向敏捷思维模式是最艰巨的任务,因为他们的角色受影响最大,最终反而变得无足轻重。同软件打交道时,太多传统的指标都被颠覆了。当你不再假设定制软件开发是可预期、可重复的工作,并开始认识到每个项目或产品都是独特、非定义的,那么事情就会变得容易些。软件开发中也可能会有项目管理的一席之地,但也不是按部就班地管理产品,或是管理客户和利益相关者的预期。
商业分析师也必须适应新形势。项目规划通常需要在规划时了解尽可能多的信息,获取这些信息非常依赖商业分析师的工作。而产品开发对商业分析师也是一种思维转变。产品开发不再需要提前获知细节,实际上,在大多数情况下,这种工作是在浪费精力,因为随着产品开发的进展,我们得到的信息越来越多,我们的方向和优先级也会频繁发生变更。
敏捷软件产品开发中,商业分析在早期阶段只需要大方向的评估,而细节分析应该发生在工作快接近尾声的时候。此时对实际需求的了解更加丰富,于是我们就不用浪费精力去分析那些不准备做的事情了。
对于商业分析师来说转型更容易些,他们的角色变动幅度不大,改变的主要是时间安排,与客户的对话发生在工作结束之前。分析师通常可以成为很好的产品负责人,因为他们关注的重点就是识别客户的需求。
敏捷思维模式
敏捷首先是一种思维模式,如果深入了解敏捷,我们会发现其中并没有全新的、原创的内容。我们会惊奇地发现,虽然过去 20 多年来软件产业频频用到敏捷这个词汇,但其中的行为实践只是一般管理方法中的那些优秀行为实践,后者的历史可以追溯到一个世纪,甚至一两千年之前。
“敏捷”,不管我们谈到的是 Scrum、看板、精益、精益创业或是其它的许多敏捷框架,多数情况下都是一系列有历史意义的优秀实践与指引的集合。这些实践和指引由过去成功的领导者和商业案例所定义,然后用一套概念进行包装和宣传。宣传包装工作非常成功,这大概也就是你们会来读这篇文章的原因。我是想说“敏捷”并不是什么全新、未经检验的概念。当然其中存在不少误用、扭曲的理念,但其原则是稳固的,是基于大量经验的。
举一个例子,如果你回顾百年前福特汽车的案例,用今天的敏捷标准去评估他们的做法,我想他们是做的非常出色的。
敏捷转型不应该是目的
敏捷转型经常被当作是一个目标,而现实中它应该被视为达成目标的策略。花些功夫搞清楚真正的目标是什么,就能让转型更容易取得成功。
- 你们的客户是否不满意?
- 你们的产品是否未能达成预期?
- 你们(或你们的客户)是否认为你们没在创造价值、赚取收益?
- 你们是否跟不上市场节奏?
- 如果你们在为内部团队开发软件产品,他们的反应是否没有符合你们的预期?
- 人们是否拒绝使用你们的工具?
- 你们在软件开发上的回报率是否过低?
- 你们是否在流失重要的开发成员?
- 软件开发的流程是否缺乏透明度?
以上只是公司想要进行敏捷转型的诸多原因中的一部分。这些是全局性的商业问题,这正是关键所在:敏捷转型并非只是软件部门的活动,它改变的是整个商业模式。它是一项重大的文化变革,从上至下彻底影响我们的商业活动。从我们销售产品的方式到招聘人员的做法,尤其是看待成功的方式,都会随之发生变化。
传统变革管理
敏捷转型正是一种传统变革管理的模式。“敏捷”的重心是文化变革而非流程变化,因此它无需被限定在软件行业。如果你们的公司迫切需要改进,愿意采取行动,创造拥抱变革、持续进步的文化,那么你们就已经迈出了第一步,也是最重要的一步。但这也是多数公司走得最艰难的一步。
如果你们转向敏捷只是因为听说它卓有成效,想藉此改变流程,却不愿触及公司文化,那么你们很可能会陷入困境。
如果你们考核团队的方式一如既往,那么团队的行为和考核结果也会一成不变,依旧是你们想要改变的那个老样子。
衡量标准
敏捷的程度取决于你们赏罚哪些行为
很多小公司创业时非常敏捷,他们必须如此,这是生存所迫。从失败中学习、适应、进化并思考是至关重要的。我们经常会听到成功的创业公司谈到,快速学习失败的教训对他们帮助多大,以及他们所有的努力都朝向共同的目标。但是当公司越来越壮大,他们开始“成熟”,组织变得复杂,责任变得分散,对待失败的态度也从正面变成了负面。公司不再有共同的目标,各个部门都有了自己的算盘,部门目标与公司的前景缺乏关联。
各部门有自己评价的目标,团队有目标,个体有目标。我不是说目标是坏事,如果它们不和组织的共同目标相关,那么就算不上什么好事情。这类目标会导致相冲突的行为和活动,不仅不会帮助公司前进,更有可能让公司离目标更远。
静下心来想一想,你们的组织是不是经常需要做一些事情来达成公司目标,比如交付产品或招聘更多人员。但这只会让你们依赖另一个团队或个体,可那个团队不会或不愿解决你们的问题。IT 支持(抱歉拿你们举例)通常是个典型的例子,为了启动新产品对防火墙做出简单的变更就需要花费几周来做计划,或者新人到任后整一个星期后才能拿到配备的新电脑。
这类麻烦搞得我们团团转:人头数是有限或不变的,于是我们只能“暂时”雇佣费用更高的合同工来满足需要、实现部门目标。这类情况的问题在于,它们是因为部门目标与公司目标不一致而产生的。或者目标被误读,导致部门间互相竞争或无法合作。
如果公司明确指出产品发布是最高优先事项,那么 IT 支持就会知道自己该在哪些方面做出努力。如果目标是削减开支或限制人员数量,那么回避这一目标无助于共同目标的实现。类似的,冻结招聘可能会妨碍盈利。
最大的障碍
人们的行为取决于受评价的方式。对于敏捷转型来说,最大的障碍在于项目管理和人员管理。这恰恰是因为敏捷改变了我们评价项目成就的方式,也改变了我们评价人员行为的标准。
告诉我你怎样评价我,我就会告诉你我会怎样行事。——艾利·高德拉特博士(企业管理大师)
项目经理会定期受考核,考察项目是否处在正轨。每周他们都会报告项目的状态:
是否如计划行事?是否符合预算?是否按时推进?是否超出范围?
于是他们尽一切努力避免项目超支、超时、超出范围。你会问,这有什么问题?项目经理按照预期行事,并因此获得奖励。
然而问题在于,让项目“保持正轨”不应该是公司的目标。如之前所提到的,软件产品很难预测最终状态,所以向最终状态前进是不可行的。我们需要改变目标,目标应该是满足需求,并且前提是无法基于未知的最终状态进行评价。
我们的目标应该是交付正确的产品(创造利润的)并保持客户满意度。几乎不曾有初始的项目计划能符合这一目标。所以关注于纠正错误的事情并不会帮助我们实现目标。
项目管理是把事情“做”对;产品领导是“做”对的事情。
(无耻地阐释彼得·德鲁克的名言)
在将传统的项目管理应用到复杂软件产品时,是把“错误”的事情做对(按时、不超支、在范围内)。敏捷产品领导则会接受这些现实:计划可能是错误或不清晰的,范围是未知的。由此敏捷会适应变化并做正确的事情,以满足我们客户的需求。
当项目经理调整并改进项目计划,以使其一直符合目标、跟上变化的需求并应对突发事件时,他们就应该得到奖励,升为领导。但更常见的情况是,他们尽可能强制让突发事件和现实去符合他们的计划,于是“管理”项目的结果是让项目越走越偏。
换句话说,他们的行为取决于你们的考核方式。在你们的下一次项目状态会议上,想想你们要问什么:你们是在要求项目经理展现对客户和现实情况的意识,并表明他们在应对变化,还是因为他们说项目一切正常、没有问题就奖励他们?
没有问题才是最大的问题。——大野耐一(丰田生产方式的创始人)
考核价值还是工作量
相比价值而言更看重工作量,这是所有层级都会发生的问题,它在个体层级也同样是有害的。如果在每日站会中你们问到“你们今天做了什么?”,这就是一种无形的压力,要求人们表现出忙碌的样子。当然大家就会因此找事情去忙了。考核效用不应该是一项目标,而客户满意度、交付价值以获取收益、创造增长和新的机会才应该是更有价值的目标。
试着改变每日站会的内容,问大家“你做了哪些事情来帮助团队以实现目标?”,这是一个完全不同的问题,不会鼓励人们为了做出忙碌的样子而完成那些不重要的工作。这会鼓励团队去寻找那些能实现价值的工作,而不是白忙活。要奖励帮助团队实现目标的人员,并让人们为忙于不能帮助团队实现目标的工作(不管那看上去多有用、多有效率)负责。
让你们的站会从:**“我们今天要做什么?”改成“我们今天怎样能帮助团队实现目标?”** 能让行为变得大为不同。
敏捷实践和原则
你会注意到我讲了很多关于组织变革的内容,你们考核的方式本质上决定了你们公司的文化。但我几乎没有提到敏捷实践和原则,我这是经过深思熟虑的。如果你们的组织明白,需要进行文化变革以关注公司的真正目标,那么你们的文化就会反映这些原则。如果你们学会基于对公司目标的贡献进行考核并奖励成就,而不是关注于小事情的优化,那么就能很容易地接受敏捷(或者说不那么困难了,鉴于旧有的习惯难以改变)。几乎所有的敏捷框架共同的观念就是鼓励系统层面的思维,并发扬这种类型的文化。
但如果敏捷没有成为你们文化的一部分,那么你们的转型就会卡壳,因为新的实践在用旧的一套规则来评价。这样你们得到的结果不会是敏捷,相比过去可能也没什么改善。文化变革很困难,但这样做是值得的。
敏捷文化
我觉得敏捷运动中的这个说法效果适得其反。我们的目标是进行文化变革以改进组织,使用最佳的实践和工具来实现公司目标。如果我们认同这只是出色的商业直觉,并拿掉敏捷转型这个术语,那么我们可能会更好地理解在组织中发起文化变革的意义所在。
你们的商业部门可能会说:我们哪里需要改进?我们要怎样衡量是否成功?敏捷转型可能是实现这一目标的方式。
如果你们选择了敏捷转型,你们对成功的看法将是交付客户需求的内容、创造快乐、满足客户,而不被计划捆住手脚。你们考察团队成就时会看他们是否愿意学习和成长。通过授权团队决策自己的事情,你们就能创造持续进步的环境。
改变是困难的
改变是困难的,我们总是低估了困难的程度。我们更喜欢新瓶装旧酒,假装拥抱了新事物。可悲的是很多框架也吃这一套,提供的解决方案只会让所有人照旧做事,只是加个站会就说这是敏捷了。事实上转向敏捷思维模式是对未来的投资,如果你们不想付出努力进行这项投资,只会重蹈覆辙。
关于作者
John Yorke是 WWT Asynchrony Labs 的敏捷教练。他在 Asynchrony 中主管产品负责人分部,在圣路易斯开设了产品负责人研讨会。John 作为开发者、设计师、项目经理和部门领导,在软件交付领域有超过 20 年的工作经验。如今,他作为教练帮助客户进行敏捷转型,同时培训内部的交付团队。他也是敏捷领域话题的作者和演说者。
查看英文原文: Transforming from Projects to Products
感谢薛命灯对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论