写点什么

规划和掌控复杂项目

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:052429
用户头像

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

关注

评论

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

1行Python代码,给视频加水印,小白都能用

程序员晚枫

Python 视频 水印

JVM 内存大对象监控和优化实践

vivo互联网技术

监控 内存 优化 大对象 故障转移

零信任体系化能力建设(5):数据安全与控制跟踪

权说安全

网络安全 零信任

解锁安全高效办公——私有化部署的WorkPlus即时通讯软件

WorkPlus

技术之外的职场成长指南

老张

职场成长 职场经验 沟通技巧

CCKS 2023 | 度小满数据智能总经理杨青分享知识图谱在金融领域的应用

科技热闻

“业务敏捷的领导力” 工作坊 · 2023年9月3日

ShineScrum捷行

Apache Celeborn 让 Spark 和 Flink 更快更稳更弹性

Apache Flink

大数据 flink 实时计算

网络直播源码UDP协议搭建:为平台注入一份力量

山东布谷科技

软件开发 udp 流媒体技术 网络直播源码 用户数据报协议

Programming abstractions in C阅读笔记:p130-p131

codists

c

对线面试官 - MQ数据丢失问题的解决方案

派大星

MQ Java 面试题

“PO价值最大化”沙盘演练 · 上海 · 9月23日

ShineScrum捷行

价值

智定义、易调整,火山引擎DataLeap助力企业轻松实现全流程值班管理

字节跳动数据平台

大数据 数据中台 数据治理 数据安全 企业号 8 月 PK 榜

@Configuration 注解的 Full 模式和 Lite 模式!

江南一点雨

Java spring

虚拟货币量化交易机器人开发步骤|区块链炒币机器人开发源码功能详解

V\TG【ch3nguang】

虚拟货币 量化交易机器人开发

DeFi质押流动性挖矿模式系统DAPP开发

V\TG【ch3nguang】

DeFi流动性挖矿 质押挖矿

推荐三款适合运维小白的网络监测工具

小魏写代码

IPP swap孵化器丨LP质押挖矿丨算力分红丨系统开发解决方案

V\TG【ch3nguang】

DeFi去中心化系统开发

Excelize 开源基础库 2.8.0 版本正式发布

xuri

开源 Excel Go 语言 Excelize 开源软件供应链

测试代码终极解决方案 Monkey Patching

江湖十年

golang 后端 单元测试

Stack Overflow开发者调查发布:AI将如何协助DevOps

SEAL安全

人工智能 DevOps 开发者报告 企业号 8 月 PK 榜

蓝易云:如何检查Linux硬盘大小、类型和硬件详细信息?

百度搜索:蓝易云

云计算 Linux 运维 云服务器

首创端云一体多情感模型 火山语音创新发布PortaSpeech 2

科技热闻

合合信息启信宝与全国性股份制商业银行达成合作,聚焦产业链数字化管理

合合技术团队

人工智能 大数据 银行

蓝易云:Alma Linux 9 上安装 Node.js 的 3 种不同安装教程!

百度搜索:蓝易云

node.js 云计算 Linux 运维 Alma

区块链挖矿系统源码|TRX区块链质押挖矿系统开发

V\TG【ch3nguang】

质押挖矿 区块链技术开发

内网即时通讯软件,打造企业信息保密壁垒

WorkPlus

R语言之处理大型数据集的策略

timerring

R 语言

交易所量化炒币智能机器人系统搭建开发

V\TG【ch3nguang】

量化交易机器人开发 炒币机器人

ios ipa包上传需要什么工具

雪奈椰子

ios打包

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