本文共 1223 字，大约阅读时间需要 4 分钟。

衡量开发人员的工作量一直是让很多管理者头疼的问题，开发工作的不易量化让对于开发人员个体的工作变得难以评估。这时许多管理者为了图方便，直接只用代码行数来评估开发人员的工作量，这让很多开发人员都苦不堪言。

在开发工作中，代码行数体现的数据最直观，这点我们不能否认，它一定是一个可以参考的维度。但是如果仅用代码行数来评估开发人员的工作量，甚至以代码行数来设定 KPI ，这无疑是非常错误的行为，其带来的后果也是非常严重的。

首先这并不是一种非常专业且科学的评估方式，甚至会让制定该规则的人显得有些「业余」。亲自有过项目经验的开发者和技术管理人员应该都知道，一个项目中真正耗费精力的地方是框架搭建、功能需求分解，以及后续的功能测试，真正去写代码的时间占比其实并没有多少。

其次，如果仅用代码行数来评估开发工作量的话，团队所面临的最大难题便是垃圾代码的增加。团队成员为了完成 KPI ，在本就能 20 行写完的功能上加入各种注释和无用的函数，甚至直接往项目里面贴源码，而不去考虑代码的耦合性、可读性、可维护性、重用性等。虽然 KPI 完成了，但开发人员逐渐降低的效率、延误越来越久的项目、质量越来越低的代码，团队在进行着完全没有必要的内耗，会让整个项目越来越艰难，和最初的目的背道而驰。

比尔盖茨曾经总结过这么一句话，“用代码行数来衡量编程的进度，就如同用重量来衡量飞机的制造进度”。没错的，代码数量并不等于代码质量，一味的追求写了多少行代码没有多大本质意义，关键在于是不是真的解决了实际问题。而只用代码行数来评估工作量，无疑是管理方式落后的表现。不客气的讲，这样的管理者思想仍旧停留在农耕时代，高产出=高价值，这样的等式在软件研发领域是不成立的。

那么，一个合格的管理者到底应该如何科学的评估开发人员的工作量呢？

目前比较常见的方法是基于 WBS（Work Breakdown Structure）的工作量估算，也称作自下而上法。通常的估算步骤如下：

1. 寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；
2. 进行 WBS 分解，力所能及地将整个项目的任务进行分解；
3. 参考类似项目的数据，采用类比法或专家法，估计 WBS 中每类活动的工作量；
4. 汇总得到项目的总工作量；
5. 与第1步的结果进行印证分析，根据分析结果，确定估计结果。

此外，也有 Putnam 模型、 COCOMOⅡ模型、IBM 模型等科学的估算方法，虽然看起来比较复杂，但比「一刀切」式的只看代码行数的评估方法要有效的多。

始终追求高效开发协作的 Gitee 企业版也在和大家一起探索更科学、合理、公正的工作量评估体系，Gitee 企业版刚上线不久的「统计」模块将多维度可视化的指标独立出来，让管理者更全面、直观、立体地了解项目进度级团队情况。

「统计」模块在未来仍将会是 Gitee 企业版的重点，后续我们会对该模块持续改进，提高大家的效率是我们不变的目标。

转载地址：https://blog.csdn.net/ZicoChan/article/details/104774690 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！