先建秩序，再量效能。大多数团队度量体系失败的原因是：在混乱中铺指标，逼着团队在废墟上造假数据。
你铺的那些指标，为什么没用？
我看过太多团队的度量仪表盘——几十个指标花花绿绿，但没人看、没人信、更没人根据它做决策。
问题出在哪？度量应该在治理之后，不是治理之前。
团队的需求入口都没统一，你统计"人均需求交付周期"——这个数字有什么意义？统计的是混乱的程度，不是效能。
GCR的做法是反过来：先建五条生命线的秩序，再把度量当镜子用。镜子不治病，但让你看清楚哪里有病。
五个维度，16个指标
GCR的效能度量体系覆盖五个维度：需求、迭代、交付、缺陷、工单。每一条生命线都有对应的量化窗口。
需求维度（3个）
- 需求积压数：当前需求池里待处理的需求总数。积压过多意味着入口失控。
- 需求平均停留时长：一条需求从创建到进入排期的平均耗时。越长，说明需求评审和优先级决策越慢。
- 僵尸需求占比：超过3个月未更新的需求占总需求的比例。超过30%就该清理了。
迭代维度（3个）
- 迭代交付率：当期迭代内完成交付的需求占规划的比例。目标≥90%。
- 准时交付率：迭代周期结束前完成交付的比例。目标≥85%。
- 需求变更率：迭代内变更的需求占规划的比例。目