16｜需求交付周期长，怎么分析瓶颈在哪？

开场先给分析的方法论——价值流分析。交付慢是老板最容易感知的痛，效能团队的核心日常就是这种分析任务。

回答思路

第一步：价值流分析（区分两个时长是精髓）

把需求从「提出」到「上线」切成阶段（需求评审、排期等待、开发、提测等待、测试、发布等待），统计每段的停留时长，画成时间轴找最长块。

注意区分「工作时长」和「等待时长」——开发三天里真正写代码一天、排队两天，问题在排队不在开发。多数「慢」是等待，不是干活慢。

第二步：讲常见瓶颈的识别特征

环节长	病征
需求评审	需求质量差反复返工（提测被打回率高）
开发	并行任务干扰（一人多任务切换，代码当量低但周期长）
测试	自动化率低 + 环境等待
发布	发布窗口稀缺 + 审批链长

每个环节的「病征」讲出来，分析就有了抓手。

第三步：讲数据之外的现场验证

看板数据给方向，去现场看细节（参加一次他们的排期会、蹲一天测试环境的争用）——数据告诉你哪里慢、现场告诉你为什么慢。两个证据链交叉，结论才立得住。

第四步：讲分析产出的形态

瓶颈报告要包含：数据现状、根因、改进建议、预期收益——用管理层能懂的语言（「每月三十个需求天在等测试环境，加一台环境的成本远低于等待的产能损失」）。分析的价值取决于它能不能被决策。

收尾：讲动态性

瓶颈会漂移（测试环境解决了，瓶颈漂到发布窗口）——价值流分析要周期性复跑。效能管理是打地鼠的持续游戏，一次分析管不了永远。

考察重点

维度	说明
企业动机	效能团队的核心日常就是这种分析任务——会价值流分析的人和只会喊「提高效率」的人差一个岗位
过线标准	价值流分析 + 等待和工作的区分
区分度	讲各环节病征、讲现场验证交叉的是真做过诊断的
加分项	瓶颈漂移的动态认知
减分项	拍脑袋归因（「开发效率低」），没有数据方法

来源

整理自知识星球帖《面试情报 07｜研发效能度量与提升 20 题》，返回题库。