软件项⽬中的⼯作量评估问题

        关于软件项目的工作量评估，业界也有各种度量方法、计算标准、评估经验等，总结下来，对软件开发工作量评估的准确程度，取决于以下几个因素：

1. 对业务需求、功能模块的了解程度；
2. 对技术实现方案的掌握程度；
3. 对已有可复用的技术模块、工作环境、编码发布环境的熟练程度；
4. 对开发交付人员能力水平的了解程度；
5. 对于大型复杂项目，非技术因素（如跟需求方沟通成本、跨部门协调成本、 非功能要求等）的经验积累程度；

        因此，全部满足这些要求的，是对该业务非常熟悉、长期参与或了解一线开发的资深技术人员。

        一般情况下，预估工作量主要是给业务方/需求方使用的，比如，甲方客户、产品经理、项目经理等，通过工作量来评估人力成本以及交付计划。普遍场景下，业务方并不能准确评估工作量，即，这里讨论的前提是，甲方客户、产品经理、项目经理等不完全满足上述的1至5的条件，双方存在信息差。不谈他们对业务和技术有丰富经验的情况。

        由于这种信息差，如果业务方与技术方未建立信任，业务方总是觉得评估工作量太多，压低工作量、缩减交付周期，如果技术方没有按期完成，便质疑技术方交付能力，技术方就会报更多的工作量来留砍价空间，跟商业买卖是不是很类似？这种信息差也普遍存在非标产品或服务中，比如房屋装修、古董买卖等。这种质疑和博弈的局面，就不可避免的产生更大的信任危机；

常见的错误做法是：

1. 业务方直接定工作量，或者在技术给的工作量基础上讨价还价；
2. 找不了解项目情况、缺乏实际经验的第三方团队评估；
3. 靠盯工作时长来决定人效，间接判断是预估工作量否有水份；

如何客观地看待这个问题？下面，从技术方的角度分析，工作量评估的各种影响。

首先需要明确：

1. 工作量评估的准确度，因涉及评估人员的专业性、技术和功能的复杂性、开发人员的技术能力以及其他客观条件，客观的工作量是没有任何人或者工具能够精准度量的。评估准还是不准，一定得跟实际消耗工时对比，且评估人员不能是实际开发交付的团队。

2. 评估准确性，并不代表人效，这是两个维度的概念。 业务方质疑评估的准确性，实际上是质疑评估太多，人效太低，低于他们的预期；因此准不准此时并不是那么重要，就像现实世界，往往没有绝对的真相，只有信与不信，满意与不满意；

举例来进一步分析：

假设，某项任务，客观工作量为50人天，推演下，预估工作量、实际耗时，在不同数值下，会是什么情况？

通过分析客观工作量、预估工作量、实际消耗的工时之间的关系，可以知道，业务方的满意程度跟客观工作量没有关系，只跟业务方的心理预期偏差大小、实际工作量与承诺的偏差大小有关。

他们具体关系可以量化为：

1. 评估满意度： 评估满意度 = 技术方评估工作量 / 业务方心理预期工作量， 以1为分界，值越大越不满意，越小越满意；
2. 人效： 人效 = 客观工作量 / 实际耗时， 以1为分界，值越大人效越高，越小人效越低；
3. 工作进展满意度： 工作进展满意度 = 实际工作量 / 技术预估工作量， 值以1为标准，偏离越大越不满意；

也可用下图示意：

我们应该怎么做？氛围良好，团队平等的情况下，建议：

对于技术方：

1. 提高业务水平，提升评估能力，尽可能全盘考虑，使得评估结果接近客观真实情况；
2. 尊重客观规律，不要因为过度自信，或者迫于压力而过度承诺；
3. 不要虚报工作量，既影响业务方的信任，更影响业务健康发展，一损俱损，迟早会被淘汰；
4. 努力提升自身技能，提高工作效率，增强市场竞争力；

总之，“谨慎承诺，超出预期”，这其实也是提升信任度的黄金法则。

对于业务方：

1. 信息不对等的情况下，违背客观规律，盲目压低工时，并不能真正提升人效，反而激发矛盾，形成博弈对峙；
2. 加强学习，深入了解和研究评估逻辑，充分沟通和倾听建议，参考多方评估意见，兼听则明；
3. 做好价值观引导，激发团队的积极主动性，提升目标感，共同拼搏奋斗，上下同欲者胜；
4. 将精力放在业务方向上，开发人效并非业务成败的关键因素，正确的业务方向才是；