【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

从项目转型为产品

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:412603

评论

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

C++ 中的四种智能指针

桑榆

c++ 8月月更

一起学习集合框架之 TreeSet

宇宙之一粟

Java 8月月更

Kubernetes证书过期怎么玩

CTO技术共享

开源 签约计划第三季 8月月更

C++深拷贝与浅拷贝,初始化列表,对象成员,静态成员相关分析

CtrlX

8月月更

头脑风暴:零钱兑换

HelloWorld杰少

8月月更

Kubernetes网络模型

CTO技术共享

开源 Kubernetes 集群 签约计划第三季 8月月更

如何克服紧张

踏雪痕

Kubernetes 调度器优化

CTO技术共享

开源 Kubernetes 集群 签约计划第三季

关于 SAP UI5 floating footer 显示与否的单步调试以及使用 SAP UI5 的收益

Jerry Wang

前端开发 SAP SAP UI5 ui5 8月月更

Kubernetes信息安全

CTO技术共享

开源 信息安全 Kubernetes 集群 签约计划第三季 8月月更

文本词频统计的利器 Trie树

Five

c 算法题 8月月更

Python 教程之输入输出(5)—— input() 函数中的漏洞 – Python 2.x

海拥(haiyong.site)

Python 8月月更

Service Mesh迁移原则

阿泽🧸

Service Mesh 8月月更

Kubernetes 实现灰度和蓝绿发布

CTO技术共享

开源 灰度发布 蓝绿发布 签约计划第三季 8月月更

Linux的难题,终于有解了!

Jackpop

Docker基础:Docker 常用命令梳理

天使不哭

#开源 8月月更

VS Code如何打造C/C++开发环境?

Jackpop

SRv6网络典型部署场景

穿过生命散发芬芳

8月月更 SRv6

百家号打击挂载恶意导流链接行为,必须严厉打击恶意挂链灰产

石头IT视角

钝感力与自我和解

Amazing_eve

#开源

系统管理-Linux重定向与管道

Albert Edison

Linux centos 运维 服务器 8月月更

电动汽车充电站的部署优化策略

乌龟哥哥

8月月更

SRE运维解密-服务质量目标:SLI,SLO,SLA

董哥的黑板报

微服务 运维 云原生 SRE Google

Kubernetes故障排查eBPF

CTO技术共享

开源 ebpf 签约计划第三季 8月月更

Kubernetes内存泄露怎么玩

CTO技术共享

开源 内存泄漏 签约计划第三季 8月月更

为什么互联网大厂一边疯狂裁员,一边不停招聘?

Jackpop

开源一夏 | jQuery 密码验证和深入理解JSONP【前端jQuery框架】

恒山其若陋兮

开源 8月月更

C++为什么始终无法取代 C 吗?

Jackpop

gulp 的常用 API

Jason199

js gulp 8月月更

Go-Excelize API源码阅读(一)——NewFile()

Regan Yue

Go 开源 源码刨析 8月月更

Kubernetes构建Redis 集群

CTO技术共享

redis 开源 签约计划第三季 8月月更

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