写点什么

从项目转型为产品

Are You Ready for the Fallout?

  • 2017-08-14
  • 本文字数:5660 字

    阅读完需:约 19 分钟

关键点

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

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

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

项目或产品

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷思维模式

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

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

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

敏捷转型不应该是目的

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

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

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

传统变革管理

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

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

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

衡量标准

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

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

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

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

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

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

最大的障碍

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

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

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

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

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

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

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

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

(无耻地阐释彼得·德鲁克的名言)

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

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

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

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

考核价值还是工作量

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

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

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

敏捷实践和原则

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

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

敏捷文化

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

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

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

改变是困难的

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

关于作者

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

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


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

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

2017-08-14 17:412911

评论

发布
暂无评论
发现更多内容

敏捷开发:影响地图工作坊的反思

华为云开发者联盟

敏捷开发 业务线 需求管理 需求 华为云

第八周作业

赵龙

shell实现SSH自动登陆

阿呦,简笔话_Golden

Week 08 命题作业

Jeremy

英特尔®边缘软件中心重磅发布 一站式资源供给为应用开发创新赋能

最新动态

面试官问:如何设计一个安全的对外接口?

Java小咖秀

Java 面试 经验

第八周学习总结

赵龙

Java开发Spark ELT实践(一)

团子粑粑

大数据 Apache Spark

第八周总结

andy

极客大学

架构训练营第八周作业

张锐

你好,工作!

小天同学

工作 心态 自我思考

架构师训练营第八周作业

sunnywhy

极客大学架构师训练营

架构师训练营 -- 第八周作业

stardust20

世界上最狠的语言

十三

面经手册 · 开篇《面试官都问我啥》

小傅哥

面试

架构师训练营 - 第八周 - 学习总结

stardust20

JVM详解之:汇编角度理解本地变量的生命周期

程序那些事

Java JVM 汇编 生命周期

扎克伯格:从程序员到福布斯全球首富,他经历了什么?

北柯

【API进阶之路】高考要考口语?我用多模态评测API做了一场10w+刷屏活动

华为云开发者联盟

人工智能 学习 评测 API 华为云

第八周作业

方堃

架构师训练营第八章作业

itrickzhang

架构师训练营第8周

大丁💸💵💴💶🚀🐟

域名凭什么能卖出亿元高价?

北柯

创业 互联网 域名解析

设计过度有时比设计不足更可怕

菜根老谭

架构思维 过度设计 演化思维 设计不足

行为型模式:迭代器模式解析

Seven七哥

Java 编程 程序员 设计模式 迭代器模式

产品、方案、生态三力齐发 英特尔驱动智能边缘价值迸发

最新动态

架构师训练营第八章总结

itrickzhang

云图说 | 快速创建一个kubernetes集群

华为云开发者联盟

Kubernetes 容器 虚拟机 集群容错 华为云

保障服务稳定之服务限流

X先生

后端 架构设计 服务设计 限流算法

天天用SpringBoot,它的自动装配你能说出来吗?

root

Java spring springboot 自动装配 EnableAutoConfiguration

Week 08 学习总结

Jeremy

从项目转型为产品_文化 & 方法_John Yorke_InfoQ精选文章