​2018年在项目管理大会上听到嘉宾分享「敏捷项目绩效评估」，去年在DevOps社区里听过嘉宾分享「敏捷度量金字塔体系」，在结合平时自己在项目的一些实践和理解，今天就来梳理和总结下“度量与绩效评估”都涉及哪些点，也算是对自己认知升级的一个过程。

管理学大师彼得德鲁克曾经说过“你如果无法度量它，就无法管理它”(“It you can’t measure it, you can’t manage it”)。

度量能让项目目标更明确，现状更清晰，改进更精准。

在传统交付型、预测型、瀑布型项目里的要度量的点就非常多了，从5大过程组、10大知识领域里基本上每个地方都要做度量，这样项目经理才能有效的把控项目，才能使项目保质保量按时交付。项目度量也就是对数据指标进行制定和监测，从而判断项目是否符合预期，是否满足目标的过程。好的度量应该是根据项目特点制定不同的度量指标，并能真实判断项目过程是否符合项目预期。

常见度量维度有：价值、效率、质量，针对这三个维度我们在结合项目实际情况细分度量指标。这点不管是传统项目管理和敏捷项目管理都是适用的。

传统项目管理的度量已经非常完善了，这里主要是聊聊在敏捷思想里我们应该怎么做度量？

度量的三个步骤： why -> What -> How

• 明确目标（Why）。为什么度量，实现什么目标？
• 明确信号（What）。为了实现目标，需要度量什么内容？
• 定义度量数据（How）。详细定义怎么度量，频率多少，代价多高？

度量会带来霍桑效应，就是当人们在意识到自己正在被关注或者观察的时候，会刻意去改变一些行为或者是言语表达的效应。

刻舟求剑

「不善于分析指标数据，无法找到根本原因浮于表面，最终无法解决根本问题」

接下来，我们从“价值、效率、质量”来具体说说敏捷怎么度量。（以下内容是DevOps社区里王明兰老师分享的具体度量指标，供参考）

「适合自己项目的才是最好的」

价值度量（这块度量其实是很难的，怎么才算是有价值？这个应该是没有一个明确的标准），这里也只是给出价值度量的意义：

• 衡量业务经营结果
• 辅助产品决策：在产品或需求启动前评估价值，已做出做与不做，以及什么时候做的决策。
• 形成产品反馈闭环：在产品或需求发布后度量其价值，为调整产品方向，或调整Backlog提供输入。

效率度量：

• 价值交付效率：特性平均周期时间、迭代速率、每个迭代发布的特性数量。
• 工程效率：版本构建效率、回顾验证效率，全量功能验证效率、非功能性验证效率。

质量度量：

• 外部质量：NPS、产品的非功能性属性、缺陷密度。
• 内部质量：代码质量度量、测试覆盖率度量、持续交付流水线运行成功率。

敏捷转型成效度量：

• 基于结果的评估：效率度量、质量度量、价值度量。
• 基于过程的评估：组织或团队能力度量、员工学习和成长度量。

最后，来聊聊敏捷项目里怎么做绩效评估？就像上面提到的霍桑效应，其实只要考核什么，就能得得到什么。「考核什么得到什么，同时往往是以失去其他作为代价」在传统项目里常见的考核指标有：需求变更次数、Bug数、交付时间、是否有维护性良好的代码、可扩展的架构、可用的文档、干系人满意度等等。

那在敏捷项目里考核指标应该有哪些呢？

我一直都在思考，究竟什么样的人适合敏捷，或者说敏捷思想更适用于那些人？最近有了些自己的想法，举个例子：为啥富士康的员工在工作时需要严格执行员工管理，上下班严格打卡（迟到早退要扣工资），吃饭上厕所都要严格控制好时间；而国外谷歌公司员工可以不受公司约束的上下班，可以带着小孩去上班或在家办公，这个例子可能觉得有点极端。那就拿我们国内都是搞IT的的公司，有些公司必须要求上下班考勤，而有些公司却不注重考勤，但往往不注重考勤的公司产出更高呢？我认为导致公司做出这种选择的原因是不同的人处在不同的需求层次上。马斯洛的需求层次理论里把需求分为五类：生理需求、安全需求、社交需求、尊重需求和自我实现需求，依次由较低层次到较高层次排列。这也类似赫兹伯格的双因素激励理论提到的：保健因素（职业安全感、薪水、身份、工作条件、政策等）和激励因素（有挑战性的工作、成就感、个人发展、认可度、责任心等）。我这里不讨论这两个理论的相似和区别之处。我的观点是敏捷考核应该是通过考核环境中的激励因素，来促进团队释放知识型人才的生产力。

是不是也可以理解成：采用传统管理主要是追求保健因素（生理需求、安全需求、社交需求）的人还比较多？而能采用敏捷管理是因为处于激励因素（尊重需求、自我实现需求）的人比较多了呢？ 希望有其他观点的小伙伴可以和我深入沟通交流，这个点困扰我很久，今天算是针对这个困惑把我的想法表达出来了。