交付功能还是交付价值？
TL;DR：衡量项目成败，不只是按范围交付功能，更要交付价值；范围与需求并非对立，真正的选择是做一次性生意还是长期生意。AI 带来的成本敏感性下降，让“交付价值”成为最终唯一能为投入辩护的东西。
1. 一个“任务型”项目的触动
衡量一个项目成功的标准，是按照范围约定交付功能，还是为客户交付价值？
成为项目经理的第五年，我开始重新思考这个问题。身为乙方，我一直视合同为圭臬，秉承着“合同里写明的内容，一定不能少；合同里没写的内容，一点都不多做”的原则来管理项目。定制化软件研发项目中，最大的成本支出往往就是人力成本。为了尽可能给公司降低成本，时常也需要和得寸进尺的客户斡旋缠斗：这里多做一点，那里能不能少做一点；这么做（某种更简单好实现的方式）行不行；时间比较紧张，这个新功能工作量比较大，是不是暂时不做了。我也一直为自己能最大程度保证项目边界清晰、范围不蔓延为荣，也常常为边界的不确定、范围扩大的可能性而陷入内耗。
促使我这次重新思考这个问题的契机是在目前手上一个项目中和客户的接触。这个项目的特殊之处在于它立项的契机不完全是出于需求，而更像是某种任务。因此在项目的建设范围内，只有一小部分功能真正代表了客户的需求，而其他部分，出于种种原因，是为了保障项目的完整性和高价值而存在。秉承着乙方的自我修养，我们在交付的内容上自然不会偷工减料：合同里写了多少功能，我们就会交付多少功能，哪怕甲方明确告诉我们这些功能未来未必会用。也因此需求调研开展得也很困难，系统设计步履维艰，但我们也必须将这些非必要的功能交付出来。
然而棘手的地方在于，正因为甲方认为他们可以在非必要功能上对你的交付成果睁一只眼闭一只眼，他们同时也期待你在真实的需求上多花一点功夫（即，大概率在这些功能上项目范围会有一定蔓延）。
假设我依然严格遵循合同描述去开展工作和交付，可能会发生什么呢？
在团队技术能力依然过硬的情况下，我们可以在时间要求内交付所有功能，也有可能顺利通过验收，合同金额圆满到手。但是在客户眼里，系统建成了，款付出去了，功能都在，可是他们未必用得起来，或者说他们真正需要的功能，没那么好用。那么这个项目，究竟算成功还是失败？
瀑布式运行的项目的经典困境，催生了敏捷项目管理方式，然而这么多年过去了，本行业大量项目依然在以一种陈旧的却最保险的模式在运行，这也是为什么到今天我们依然在讨论这个问题。
2. 范围与需求并非对立
我们这个行业里见惯了大量的假需求，在一个真实的需求出现时我反而会为之一振。由于这个项目的周期较长，在这段时间逐步接触了解客户的业务过程中，我真切感受到客户对这一部分能力的需求。如果我把这个成果做好，一定能够帮到客户，帮助他们在目前的业务中极大提升效率，也一定能够在客户心中树起一个真心为客户服务的形象。
在这里，天平的两边并不是合同范围 vs 客户需求；相反，现在的我觉得，把合同范围和客户需求树立成对立面本身就是一种较为幼稚的非黑即白的表现。这个问题的核心更像是，你只想要这一次合同金额，还是想要做长期生意。
这次机会让我重新开始思考，即便范围管理依然是项目管理中十分重要的内容，综合考虑本行业的现状（包括但不仅限于立项时的种种限制、资金投入的偏好等等，这些因素带来的“借一个名头去立项”的情况），是否应该把精力从合同中具体的表述上移开，投入更多精力在理解文字背后的真实需求，多迈出一步去了解这些需求的来源，接受一定程度的不确定性，给自己和客户都留有余地，才能交付真实的价值。
3. 执行层面：如何守住范围与成本
那么下一个问题则是执行层面的问题：如何在这种情况下，依然尽量控制范围和整体成本？
在定制软件项目中，和人力成本直接相关的除了范围，还有系统设计复杂度。在系统设计层面，降低复杂度可以有非常具体的落地，从信息的层级设计、接口的处理逻辑，到前端的交互层级，都可以一点点减少工作量。
这里还有一个较大的变量，就是AI在定制软件开发项目中扮演的角色。在AI没有深度参与开发工作前，评估工作量往往是建立在系统原型基本完整的前提下，由资深工程师开展评估，还要加上预留。在AI深度参与项目后，这个评估方式变得极不可靠，也让项目经理在考虑变更的时候多了很多变量：虽然开发速度提升了，建设团队的成本敏感性似乎也有所下降，但维护和变更的代价也变高了，因为最终AI生成的代码依然需要人类去为其兜底。
也正因如此，现阶段在项目管理工作中，仅仅抓住工作量这个指标已经不足以支撑对一个项目建设范围的评估，更核心的是依然要把握住系统的业务价值。
回到文章最初提的问题：交付功能，还是交付价值？在投入成本敏感性不断下降的今天，唯有最终交付的价值能够为投入成本进行辩护。与此同时，我们不要忘记，项目管理最初的出发点就是资源的有限性，从而衍生出一整套管理的哲学。如果可以无限投入，我们也就不需要管理。而资源的有限性，考验的正是管理的能力：如何将有限的资源有效投入，最大化最终的价值。