按照工作量计算成本，几乎成了这些年很多软件厂商的共识。这确实是对交付工作价值的一种认可，也是试图走向标准化的有益尝试。但一个不容忽视的现实是：无论是客户还是第三方顾问，都很少真正在意厂商付出了多少“工作量”。换句话说，客户关心的最终结果和厂商紧盯的交付过程，并未因为厂商对“工作量”的执着而变得协调，反而常常是完全脱节的状态。
2025年已经过去，与一些业内朋友交流时，难免会回顾上一年的业务状况。那些从事企业管理软件，尤其是CRM领域的朋友，很多人会感慨一句：2025年的业务营收有所好转，但就是没怎么赚到钱。
聊得更深入一些，原因往往聚焦在实施交付成本居高不下。稍大一点的项目，就像陷入了添油战术的泥潭，像个黑洞一样，需要不断投入人力和天数。
更令人头疼的是，在不断追加投入之后，客户的满意度非但没有提升，项目需要处理的事情反而越来越多，形成了恶性循环。
“工作量”这个概念，其成立有一个最基本的前提：那就是相对的标准化，或者说，需要一个涉及项目各方的、明确的共识。
近两年，我自己接触过几个规模较大且复杂的项目。如果纯粹按照“工作量”来核算成本，乙方肯定是亏损得一塌糊涂。但如果跳出项目本身，从一个客观的第三方视角去审视，会发现乙方的亏损一点都不冤枉。
因为这些项目的乙方，且不谈能否与外部达成关于工作量的共识，就连自己内部对“工作量”都没有一个基本的标准。同一个任务，让一个刚入职的新员工和一个拥有多年经验的项目经理去执行，所需要的工作量可能是天差地别的。当然，有些公司也会对项目经理进行分级报价，但这更多时候只是流于形式，因为内部几乎没有客观、细化且可落地的项目经理能力分级体系。
直接说结论吧，所谓的“工作量”误区，其实包含两层含义。
第一层是不断努力的目标或理想状态。 在这种状态下，“工作量”不仅包含传统理解上的工时投入，更包含了有相对统一标准的“工作内容”本身。这要求厂商从实施交付团队的能力模型规划、招聘时的能力标准对标，到实际工作中的能力协同与配合，都建立起相对量化的、并且（这是关键）能够落地的体系。这个体系需要将复杂的能力拆解为一个个可以落实到文字、并可进行考核的能力模块，这样才能作为项目成本估算的重要依据，并为内部考核与能力提升提供清晰的空间。
例如，从制定项目组计划到执行项目调研的方法论，这些属于项目管理能力；对特定行业的业务理解，这属于项目顾问能力；而凡事做到事前有计划、事中有执行、事后有闭环，这属于初级工程师应具备的基本职业素养。
第二层是残酷的现实与现状。 在这个层面，“工作量”就仅仅是传统理解上的工时数字。不同能力的人做同一件事，效率和质量差异极大；每个人可能有自己擅长的项目类型或客户类型，但这种优势很难被量化或复制。此时，若将这样的“工作量”作为项目成本的唯一依据，不仅不准确，甚至会对整个团队产生极大的误导。
如果第一层的理想状态暂时还无法达到，那不如暂且忘记“工作量”这个指标。提醒自己和团队要勤能补拙，用勤奋和极度负责任的态度去赢得客户的信任，而不是去抱怨客户的“挑剔”。
关于“工作量”，这么多年来有两个（或者说两类）让我感触非常明显的例子。
第一个例子来自某CRM头部厂商。自2017年因战略转型，其团队经历了“腾笼换鸟”式的人员更迭。短暂的“动荡”之后，很快出现了一个很有意思的现象。
华南地区或许因为“天高皇帝远”，更多地继承了该厂商原有的“依靠个人努力到极致以达成目标”的激情型企业文化。相应地，新加入的CRM专业人员，更多的是做好手头工作，扮演好“螺丝钉”的角色。当客户问题堆积如山时，他们往往秉持着诚恳的态度和敬业的精神，走一步算一步，很多事情是以结果为导向，流程为结果服务。
至少在“工作量”这件事上，绝大多数一线人员仍然会尽全力为客户解决问题，而不会过度纠结于项目投入了多少个“人天”。
华北地区则相对逐渐开始了向CRM专业化的转变。原有的那种“传销式”的激情文化不可避免地遭到稀释或改变，很多事情开始讲究流程、追求规范，以期能够复制成功经验并提升团队的整体能力。
比如在“工作量”这件事上，它变成了一本复杂的账。目前可见的是，这种转变尚未真正走向成熟的专业化（这可能与公司核心团队的判断以及其他不可知的困难有关），整个团队似乎在过程的规范化与结果的最优化之间不断徘徊与纠结。
结果是，从过去近十年的发展来看，华南地区的客户在项目实施初期可能和华北一样，面临各种问题甚至陷入泥潭。但由于基层“不计工作量”的服务态度，让许多客户逐渐稳定下来。一旦客户熟悉了系统，就熬过了因厂商初期不熟悉业务而带来的反复折腾阶段。反观华北，则因为深陷“工作量”的误区，依然在交付的泥潭中挣扎。
第二个例子来自最近几年我自己接触到的一些项目，特别是那些大型项目，正如开头提到的，和朋友聊天时谈起因实施投入过大而导致亏损的情况。
他的好几个项目我曾短暂接触过。我发现，他们面对客户的一线员工，既不具备支撑“工作量”背后所需的那些专业基础能力，又在主观心态上拿着“工作量”去和客户“说事”，而不是以勤奋、低调、勤能补拙的心态去尽力服务客户、维护关系（虽然这种方式也不够专业，但总比耽误客户的实际应用要好一些）。
一线员工抱有这种心态还不是最可怕的，更可怕的是中高层管理者也抱有同样的心态。这样一来，整个业务就会变得非常“拧巴”，即便是“好客户”，最终也可能被做成“挑剔又不讲道理的客户”。
还有一个更有意思的观察。一位在业内颇有影响力的做知识星球的老师，最近也写了一篇文章，呐喊“不解决交付问题，中国软件就永远无法真正征服高端市场”。
我最初看到时很兴奋，但点进去仔细读完却有些失望。因为他作为前国外ERP顾问，在文中主要呼吁的是让厂商提高顾问的单价。但问题的核心，真的只是单价吗？“工作量”的问题，本质上并非单价高低的事情。太多的项目报价单上的人天单价，其实是根据客户愿意支付的实施总费用，除以自己预估的工作量“倒算”出来的一个数字啊。
这就像学生考不上清华，是因为他自己不想吗？不，他可能缺少的是有效的学习方法，甚至是最基础的学习资料。在软件交付领域，我们缺少的正是那套客观、可量化、可复制的能力体系与交付方法论，而不仅仅是提高单价的呼声。在云栈社区，我们也经常看到开发者们分享关于项目管理与效率提升的实践与讨论，这恰恰是构建这套体系所需要的底层思维碰撞。
发表于 5 小时前
|
查看: 1|
回复: 0
