红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

规划和掌控复杂项目

Beyond Budgeting to the Rescue

  • 2013-12-03
  • 本文字数:5755 字

    阅读完需:约 19 分钟

在复杂的大型敏捷项目方面,我所拥有的 10 年以上的经历所见:一般来说,人们都是基于对开发成果的预测,进行规划和编制预算。很多时候,开发团队对故事进行了估算,但整个项目的预算却又与该估算相互独立。特别是在复杂项目中,这往往会带来出乎意料的结果(不欢迎的)。面对这些问题,对 Daniel Kahneman 和超越预算理论那伙人的工作进行学习,非常有助于让我更好地理解规范、估算和预算编制之间是如何联系的,以及为何传统方法行不通。当然,我们都知道这些在小项目中是如何运作的,也知道如何通过迭代规划和控制一个项目。然而,我们如何决定赞成还是反对一个项目,如何定义启动某个大型项目的预算,以及如何知道我们的微小迭代(跨越许多特性团队)如何融入长期的项目目标?请注意,我并不是在说小型或常规项目,而是指那些拥有 50 到 300 开发者、持续例如 3 到 5 年才能完成的大型项目,或类似规模的大型产品(产品线)开发。

预测并不可靠

诺贝尔经济学奖获得者 Daniel Kahneman——尽管他是一位心理学家——得到了这样的结论:大部分事情的发生都基于巧合。他给出的例子之一与过去的历史有关——发展成为阿道夫希特勒的那枚胚胎,其实有 50% 的可能诞生的是一位女性。谁知道这个历史分支的不同走向,会对之后世界百年历史产生何种影响?这意味着要想预测复杂的事情是不可能的。

此外,Kahneman 也收集了来自从事该领域研究的同事们的类似工作成果,以验证他的观点。例如,宾夕法尼亚大学的心理学家 Philip Tetlock,收集了超过 8 万条政治和经济学方面的预测。请注意,做出这些预测的人,正是以此为生。因此我们谈论的是一些真正的专家!问题是,这些预测甚至比运用正态分布曲线得出的预测结果还要糟糕。但当被证明预测出错的时候,鲜有人承认自己的预测是错的。大部分专家开始找借口或理由,来解释为什么他们认为自己实际上是对的,只不过时机出了问题——但他们不会提供任何推论,来说明什么类型的时机是正确的。

在另一项研究中,伯克利大学的经济学教授 Terry Odeon 分析了大约 1 万份代理结果,其间涵盖了 16.3 万份交易。关于经纪费用,有趣的一面是,在每次交易中都必定有人相信卖掉股票或其他什么会更有利,同时也会有人相信买入更有利。然而,交易双方一般都被认为是该领域的专家。在这份分析中,Odeon 发现,与买入相比,卖出股票的表现要好 3.2%。

在最后一个例子中,我想提到的是一件基于 Kahneman 自身经历的事情。他过去曾为以色列军方服务。在那里他创造了一项测试,供他和他的团队来评估候选者的军旅职业生涯。我们或许可以很清晰地想象出,在面试之后参加这项测试时,候选者必须解决一些非常困难的问题、搭建一些东西,克服一些东西,而这种方式让谁领先、谁反对、谁是一位好的团队成员等结果都变得“显而易见”。通过在测试中观察申请者,Kanneman 和他的团队总是会对申请者的进一步资格认证树立起高度的自信。然而,每隔几个月他们从指挥官那里获得的反馈都会指出,其评估结果仅仅比盲猜好一点点。有趣的是,Kahneman 和他的同事既没有对方法做出调整,也没有基于这一反馈改变其观察所得到的结论。当看到某位申请者在测试中领先时,对他们来说,显然这依旧是军旅职业生涯的完美候选者。他们对自己的印象过于自信,以至于对他们来说要改变结论似乎是不可能的。

那么,从这些研究中我们能学到什么?实际上有两个非常重要的教训需要牢记:

  • 首先,预测将永远是一项容易出错的工作,因为这个世界——或是任何复杂事件——都是不可预测的。
  • 其次,高度主观自信(就像专家经常会表现出来的那种自信——无论是推荐参军士兵还是估算某个项目)并不意味着准确,而是意味着专家拥有一个完整的故事。只有在你处于稳定的环境中时,高度自信(有时候又被称为直觉)才可以相信。
  • 下面实际上是 Kahneman 研究中的第三条教训——我没有费力去通过研究来验证它,因为这是迭代开发的基础:与长期趋势不同,只要基于以往的行为、模式和成果,人们就可以得到非常精确的短期预测。

让超越预算来帮忙

超越预算( Beyond Budgeting )是一项由来自不同公司的 CFO 推动的发展过程。这些 CFO 们对于预算在各自公司的成功中发挥的作用并不满意。我们可能都会有所涉及的典型经验,主要包含两个方面:

  • 想象一下这种情景:某人为了某项目申请一笔特定的预算,而该项目最终与预计相比节省了开支。这时,由于担心下次申请资金的时候会被砍掉很大一部分(例如减半),他会想办法把剩下的钱花掉(却并不是为了最初的目标)。因此,这实际上并未对公司的成功做出真正的贡献。
  • 现在再想象一下:某人申请了一笔特定的预算,但随后市场发生了变化,从而导致他需要两倍的资金。但由于他没有预先申请,就无法根据市场需求做出应对。公司的成功则再次由于原始的预算而受损。

基于这些经验,提出超越预算理论的人开发了多种类型的原则和推荐建议。这些原则和建议都并不是让人们一定要摆脱预算,而是希望更灵活地使用。例如,按年度沟通预算被视作不灵活的做法,而推荐的建议是使用诸如滚动预算这样的方式——这意味着每个月都要核查该把钱花在何处才最有利。滚动预算的另一个备选方案,是基于事件制定预算,这样在任何出现变更的时候,预算都将会被重新考虑。

在我看来,超越预算最重要的洞见之一是区分目标与预测。其根本原因在于,每个目标都应该是雄心勃勃的,而预测(或估算)则是通往目标的桥梁。现在,如果强制要求目标和预测二者一致,那么要么是目标不再是雄心勃勃的,要么估算是一场骗局。

运用超越预算理论

为了决定是赞成还是反对某个项目或产品,某个人首先会有一个初步想法,随后他或许会询问一位资深开发者甚而是一支团队,以便获得用数字形式展现的工作量,以及由此而来的成本。问题在于,在此时此刻,大家对项目的了解还不是很多,因此估算也并不多么可靠。有时候,是由销售在没有咨询开发部门的情况下就给出了估算,而后做出了决策。(当然,无论是谁提出这样一份最初的估算,对开发来说,毫无疑问它都不会被认真对待,而一旦我们了解了更多信息,将会对其进行调整……)

从 Kahneman 和超越预算的研究结果来看,刚刚描述的方法并无益处。首先,它忽略了超越预算对目标和预测之间的区分。其次,与 Kahneman 的观点相反,这一方法假定复杂项目可以被预测。第三,与超越预算的建议相反,它建议提前批准预算。

实际上,我们需要的是首先去弄清楚整体目标。为了避免仅仅依赖于一支专家小组(注意 Kahneman 的研究结果),我建议基于不同背景的小组推动这一工作。根据项目情况,这里的小组可以由来自诸如客户、市场人员、销售、产品管理者等群体的人组成。而且小组最好能够得到科学方法的支持,以便找出市场的真正需求——就像精益创业所建议的那样。这项工作的产出并不是一份估算,而是对公司(或客户)希望通过这一项目所实现的业务价值的定义。通过观察业务价值,我们会调整心态,将关注的焦点从关注成本,转变到能够获得的收益上。可以通过讨论来定义业务价值,在讨论中使用 Delphi 会话,又或是像我过去常做的那样:使用规划扑克的变体。对后一种方法,不要使用估算的数字来推动讨论,而是让团队成员使用关于业务价值的数字。

接下来的事情,也并不是去询问需要花费多长时间,相反,这一支背景各异的团队必须弄清楚他们愿意花多少钱(基于他们之前得出的业务价值)。自然地,与开发者们进行评估时所采用的方式类似,这个团队将会挣扎着(在一开始)得出一个投资的数字。然而,业务必须决定它想把钱花在哪里。从开发的角度来看,任何事情都可以用一种极其精巧和昂贵的方式(一般来说这也是非常符合工作道德的,例如干净的代码)去做,但同样也可以用一种低成本的方式来实现(可能会产生难以维护的代码)。因此,业务必须判断业务价值,到底价值几何(可能会导致要求廉价解决方案)。这并不意味着在规划过程中,开发者无需肩负任何责任——他们的任务是保证业务能够理解廉价(或昂贵)的解决方案可能会产生什么样的影响。因此,此时此刻,焦点并不在于估算,而是关于业务价值和公司想要进行的投资的决策,必须推动开发。再一次的,这些驱动力来自业务,而不是开发。某些团队却恰恰相反,他们要求开发不止在故事层面进行估算,还要在史诗层面(例如通过 T-Shirt 的尺码进行估算),或者甚至是在项目的层面。在更粗粒度的层面进行估算本身并不是个问题,只要估算是用来帮助更好地理解内容的。然而,尝试回答项目、史诗或故事花费多少(或持续多长时间)却是聚焦在错误的问题上了。再次重申,应该询问的问题是,价值几何,以及我们愿意为此投入多少。

这样,业务价值和投资就定义了控制开发的框架。最好的情况下,二者都应该被分解到故事层面,不过至少也应该到史诗层面。对大型项目来说,我们已经拥有了从至少三个层面进行规划的良好经验。最高的层面是整体项目规划(一般称之为路线图)。第二个层面是发布规划,每个发布最多覆盖三个月的时间。因此,在开始某次发布之前,史诗必须用业务价值和投资来进行定义。在迭代层面(最低层面),进行经典迭代规划(也就是 Sprint 1 和 2)之前,要先定义故事的业务价值和投资。根据发布的长度(以及项目复杂度),我们有时候需要 Mike Cohn 曾称之为“滚动预测规划”的东西。因此,我们查看故事的业务价值和投资,不只是为了即将到来的一次迭代,而是同时也为了未来的两次甚至三次迭代。在这些不同层面进行规划,为业务提供了这样的可能性:首先在粗粒度层面定义业务价值和投资,并在接下来用迭代的方式将业务价值和投资进行更细粒度的定义。对大型项目来说,立即在细粒度层面定义,一方面是不可能的,另一方面也没有用处——因为业务价值(以及投资的缘由)很有可能将会随着时间的推移而发生变化。

在不同层面运用这一方法,确保了开发总是由业务价值和投资而不是估算驱动的。对于开发团队,我依旧推荐为估算故事采用规划扑克过程。然而,这是为了在团队中创建有关故事的知识所做的,而并不是为了驱动开发。因此,只有对驱动对话来说,得出的估算数字才是重要的,特别是当团队成员最初并不同意估算数字的时候,对其各自不同的假设进行讨论,将创建对故事的共识。在这种方式下,对团队来说估算依旧有帮助,但却不会驱动规划。定义优先级,以及定义对于在开发范围中纳入哪些、移除哪些,将基于故事的价值——它将以业务价值和投资的方式(而不是将持续多长时间,或是需要消耗多少故事点)来衡量。因此,业务价值与投资一起为优先次序和开发提供了一份指南。例如,如果某个特定故事被分配了低投资额,而且它无法产出高业务价值,那么它的优先级必定是有争议的(与它故事点的估算无关)。此外,对这样的故事来说,开发团队显然应该考虑最经济的解决方案;如果并不存在这样的方案,那么就应该用具有更高业务价值(和 / 或公司决定进行更多地投入)的故事来取代它。

与滚动预算或基于事件的预算类似,我们必须定期核查业务价值和投资业。例如,至少每隔一个迭代就要看一下都学到了什么:从利益干系人那里(例如,哪些变更将提供有竞争力的优势)、从市场(例如,我们需要在哪里进行投入以创建更高的业务价值),以及从开发那里(例如,某个特定技术能够提供哪些优势)。接下来分析这些将如何在不同层面影响业务价值和 / 或投入。最好先查看一下这些对发布计划意味着什么——一般来说它只影响发布计划这个层面,因此无需将其放大到整个项目的层面。然而,在某些时候也存在这样的情况:路线图也会受到变更的影响。当然,在为即将到来的迭代(而且如果可能的话,也为了滚动的展望计划,即接下来的两到三个迭代)定义业务价值和投入的时候,应该考虑学到的新的教训。

总之,如果客户的竞争优势正是我们的焦点,那么业务必须被业务价值驱动。迄今为止,在敏捷开发中我们一直在谈论业务价值,但我们只考虑了优先级(一般来说,除此之外也会考虑估算)。然而只有将投入与业务价值结合,才能够确保我们永远将客户兴趣中的价值最大化。

结语

近期的研究结果,与来自超越预算的洞察一起,证明了我们许多人都曾经历的事情:准确的预测是不可能的,因为这个世界是不可预测的(特别是在现如今)。从一位专家处获得高度可信的预测,只不过意味着这位专家讲了一个完整的故事,而不代表预测的精度很高——因此,与其询问一位专家,还不如向一组背景各异的人去求教。

为了不掉进将估算与规划混杂在一起的陷阱,我们应该定义业务价值、提出愿意投入这份事业的投资并将这些价值用于规划。这些价值将帮助我们做出支持或反对启动某个项目的决定,并帮助我们得出项目(或产品)的路线图和发布计划。因此特别对于项目和史诗层面,业务价值和已定义的投资将驱动开发。

短期预测是有可能的,因此请测量速度,并在规划下次迭代时将其纳入考虑范围。而迭代和利益干系人的反馈,将帮助我们改进对业务价值和投资的处理。因此,一方面,业务价值和投资控制着迭代;在另一方面,迭代的反馈则促进业务价值和投资的提升。或者换句话说:路线图影响着发布规划,而后者又影响着迭代,反过来也一样——迭代的结果反馈到发布规划,而这又反馈到路线图。因此业务价值和投资被当作滚动预算来对待,他们将被定期重新审视,因此所有学到的教训都会被重新考虑。

延展阅读

Thinking Fast and Slow(中译本名为《思考,快与慢》或《快思慢想》), 作者 Daniel Kahneman,企鹅图书出版

Implementing Beyond Budgeting,作者 Bjarte Bogsnes,John Wiley & Sons 出版

Beyond Budgeting Roundtable (超越预算的主页)

Agile Estimating and Planning(中译本名为《敏捷估计与规划》),作者 Mike Cohn,Prentice Hall 出版

关于作者

Jutta Eckstein是来自德国布伦斯维克(Braunschweig)的一位独立教练、顾问和培训师。基于超过十五年项目和产品开发方面的经验,她对敏捷过程有着深入理解。她专注于推动组织机构层面的敏捷开发,并已经帮助全世界许多团队和组织机构完成向敏捷方法的转型。对于在中到大型分布式任务关键型项目中运用敏捷过程,她有着独到的经验。这也是她的著作 Agile Software Development in the Large Agile Software Development with Distributed Teams 的主题。她是敏捷联盟的成员,以及敏捷开发、面向对象和模式领域的许多欧美会议的程序委员会委员。

查看英文原文: Planning and Controlling Complex Projects

2013-12-03 09:052253
用户头像

发布了 256 篇内容, 共 67.8 次阅读, 收获喜欢 10 次。

关注

评论

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

架构实战营 第 6 期 模块二课后作业

火钳刘明

#架构实战营 「架构实战营」

LotusDB 设计与实现—1 基本概念

roseduan

Go 数据库 存储

前端食堂技术周刊第 32 期:2022 年 3 月 TC39 会议、Rome Formatter、Node 内置 Test Runner

童欧巴

JavaScript 程序员 前端 web前端

Spring定义BeanDefinition

IT巅峰技术

C/C++程序员黄金方向-音视频基础知识和ffmpeg编译

玩转音视频技术

HLS SRS 音视频开发 流媒体开发 C/C++程序员

MariaDB 的自增字段 AUTO_INCREMENT 字段

HoneyMoose

网络安全之红蓝对抗实战

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

手写实现分布式锁

Linux服务器开发

分布式锁 协程 定时器 后端开发 Linux服务器开发

微服务分布式事务处理

俞凡

架构 微服务

模块2作业

KennyQ

Linux驱动开发-编写NEC红外线协议解码驱动

DS小龙哥

4月月更

Substrate Builders Program | 了解波卡生态云计算平台与最先进的查询节点框架

One Block Community

区块链 Substrate 波卡

CRMEB多商户后台前端代码打包并更新打包的代码到项目里面教程详解

CRMEB

关于数据湖几个问题详细剖析

五分钟学大数据

数据湖 4月月更

音视频&流媒体的原理以及基础入门知识

玩转音视频技术

Linux SRS 音视频开发 流媒体开发

订单管理系统(OMS)搭建实战 - 低代码拖拽定制订单管理系统

蒋川

低代码 低代码开发 低代码平台 订单系统 订单管理系统

crmeb Java 项目打包可运行jar文件详细教程

CRMEB

Hoo虎符研究院|一图了解币圈后浪Magic Eden

区块链前沿News

虎符研究院

[Day9]-[动态规划]编辑距离

方勇(gopher)

LeetCode 动态规划 数据结构算法

架构师作业2

小虾米

架构师实战营

Java 初始化 List 的几种方法

HoneyMoose

自己动手写Docker系列 -- 5.3实现logs命令查看容器日志

golang Docker

对话核心开发者,波卡的EVM+最新技术分享活动回顾

One Block Community

区块链 Substrate EVM 波卡

Java 在 IntelliJ IDEA 中提示 set the language level 9

HoneyMoose

从分层架构到微服务架构(五)之服务化架构

元闰子

架构 从分层架构到微服务架构

Tomcat:应用加载原理分析

IT巅峰技术

Tomccat

设置 Jupyter Notebook 主题

信号量

Python Jupyter Notebook notebook 主题 科学计算

哈希值游戏DAPP开发|区块链哈希值竞猜游戏开发

薇電13242772558

区块链 哈希值

Go 学习笔记——Only For

为自己带盐

Go 4月月更

Go 实现 WebSockets:1.什么是 WebSockets

宇宙之一粟

Go 4月月更

基于 HTML+CSS+JS 的纸牌记忆游戏

海拥(haiyong.site)

html 游戏 4月月更

规划和掌控复杂项目_架构_Jutta Eckstein_InfoQ精选文章