一个让我至今记忆犹新的项目是：团队连续三周平均工时超过 10 小时，但交付速率反而比正常排期慢了 40%。当时如果只看工时填报系统，所有人都像劳模，但当我们把工时的帘子掀开，发现 65% 的额外时间花在了“等测试环境”、“修跨模块的接口兼容性”和“需求确认”上。
这不叫工作，这叫空转。研发管理的刀刃从来不该对着人卷了多久，而该对着“工作在哪个环节卡住了”。
一、盯工时的管理，往往在掩盖系统的无能
工时管理有一个致命的诱惑力，，它把研发这种高度不确定的认知工作，伪装成可以计件衡量的线性劳动。当一个管理者不知道怎么评估技术决策质量，不知道怎么判断架构复杂度，不知道怎么识别等待和依赖时，他最容易做的就是打开工时看板，看谁的格子颜色不够绿。
但我观察过几十个研发团队的效能数据后发现：团队交付速率下降的第一因素几乎从来不是“人不够努力”，而是产出流动被阻塞了。 也就是说，关键不在人，而在阻塞点。
1. 高工时常常是阻塞点的症状，而非勤奋的证明
在 PingCode 服务过的几千家产研团队中，有一个被反复验证的模式：如果不解决阻塞点而单纯补工时，交付速率曲线会呈现“先平后跌”的形态，，加班前两周看上去稳住了，第三周开始继续往下掉。
原因很简单：一条堵着的管道，你往里灌再多的水，只会让压力变大，不会让流速变快。研发过程也完全一样。当代码审查环节积压了 3 天，或者测试环境被两个项目抢用，你让开发再多写 4 小时代码，并不能让功能更快上线，，只能让未完成的工作堆得更多。
2. 阻塞点才是研发效能的“血栓”
我做研发效能诊断时有一个固定动作：不看工时表，而是把从“需求提出”到“交付上线”的全流程拉出来，然后仅做一件事，，统计每一步之间的等待时长。这个数字往往比任何人预想的都触目惊心。
常见的情况是：开发实际编码时长只占需求交付周期的 30%～40%，剩下 60% 以上都是各种等待。
如果等待占比超过 50%，任何工时管理都只是在一个打滑的传送带上让所有人跑得更用力而已。
二、产出阻塞究竟藏在哪里：不是肉眼可见的“人闲着”，而是系统里的“假忙碌”
大多数管理者以为的阻塞是“有人没事干”，但真正的阻塞长得完全相反，，每个人都在忙，但产出根本不流动。
以下几种是我反复碰到的阻塞类型，它们共同的特点是“工单在工作流里流转得很快，但工作本身并没有向交付移动”。
1. 依赖型阻塞：你的下一环，在等别人
最常见的场景是：后端开发完成了接口，前端需要联调，但接口文档没有更新，或者测试环境被另一个项目占用。这时候前端的工时是满的，，他在“读代码”“尝试绕过”“写 mock 数据”，，但这部分工时对交付进度的贡献几乎为零。
这种阻塞的关键信号是：看板上“进行中”的任务数量急剧膨胀。我已经不再相信“并行能力强”这种说法。每当我在一个团队看到人均并行任务超过 3 个，我第一反应不是“他们好高效”，而是“他们已经被阻塞逼到用切换任务来填充工时了”。
2. 决策延迟型阻塞：需求在等人拍板
很多需求可以在评审会上讨论 2 小时无结论，然后挂在那里“待澄清”3 天。这 3 天里，开发人员会填上其他任务的工时，所以管理者在工时表上看不到任何问题。但站在交付视角，这条需求线的流速降到了零。
这类阻塞的病灶不在研发，而在上游。如果只盯着研发人员的工时，你永远发现不了产品决策瓶颈；你只会觉得“开发做得慢”，然后继续压工时，结果当然是越来越慢。
3. 质量债务型阻塞：修旧 Bug 占用了做新功能的时间
还有一种隐性阻塞：团队看起来在紧锣密鼓地修 Bug、改问题，每天工时拉满。但如果你把 Bug 的来源做一个分布，可能会发现其中很大一部分不是本迭代产生的，而是因为之前赶工留下的代码质量问题在持续“付利息”。
这本质上是过去的产出阻塞延续到了现在，，当时的决策是“先上线再说”，结果技术债务阻塞了后续的新功能开发。一个永远在处理质量债务的团队，就像一个永远在还信用卡最低还款的人，，一直在付钱，但永远还不清本。
三、怎么找到真正的产出阻塞点：不看工时，看流动
我自己的做法是：暂时忘掉人，只看工作项。
以下这套判断逻辑不是理论推演，而是我在多个团队反复验证过的诊断路径。
1. 先看 flow metrics，而不是工时报表
我不会一上来就看谁加班多，而是拉出三个最直接的指标：
- 周期时间（从需求明确到交付上线的总时长）
- 流动效率（实际工作时间 ÷ 周期时间）
- 在制品数量（同时处于“进行中”状态的工作项总量）
这三个数据联合起来，比任何工时表都更诚实。
- 如果周期时间长但流动效率不低 → 问题可能出在需求拆分太大
- 如果周期时间长且流动效率低于 20% → 一定存在严重等待，需要定位等待点
- 如果在制品数量高且周期时间持续恶化 → 系统过载，需要立即限制并行任务数
这三句话，是我可以在任何一个研发团队当场站住脚的判断。不需要了解业务、不需要认识人，只需要看数据。
2. 用价值流图把“等待”显形
拿出一张纸，把团队从“需求确认 → 开发 → 代码审查 → 测试 → 部署”这几个阶段画出来，然后在每两个阶段之间标上一个数字：平均等待时长。
这个动作只需要花 20 分钟，但效果几乎是立竿见影的。有一次我在一个团队画完这张图后，CTO 沉默了 30 秒，然后说：“我一直以为是开发慢，原来开发只要 3 天，测试等了 8 天。”
当他意识到这一点之后，立刻明白：加 2 个开发不如解决测试环境的问题。这就是从盯工时转向盯阻塞点的关键转折。
3. 建立阻塞的可视化信号
在我的实践中，要求团队在任务卡上明确标记“阻塞原因”是一个低成本但高回报的管理动作。
阻塞原因大概就可以分成几类：
- 外部依赖未就绪（如第三方接口、审批流）
- 等待评审/代码审查
- 需求不明确、待澄清
- 环境或资源不可用（如测试环境、设备）
- 技术难题（需要架构支持）
当这些信息持续被记录和统计，管理者就能从“这个人怎么又没填工时”的思维惯性里跳出来，转而关注“为什么阻塞类型中‘等待环境’占到了 60%”。这两种关注方向，对团队效能的影响是完全不同的数量级。
四、不同团队的阻塞特征不一样：别用同一把尺子量所有问题
以下是我在不同阶段团队身上看到的典型阻塞分布差异。它并不是严谨的研究模型，而是实战里的经验规律，供你参照而不是照搬。
1. 初创期小团队（5～15 人）
最常见的阻塞是决策层堵在大脑里，，创始人或技术负责人是唯一的产品决策中枢。需求排队等拍板，开发做完一个功能后不知道下一个做什么。
这时候强行上敏捷工具、加日报、压工时完全没意义。核心解法只有一个：把决策权有意识地往下放，哪怕先放一小块。
2. 成长期中型团队（30～80 人）
这个阶段最典型的阻塞是跨职能等待。前后端、开发与测试、产品与开发之间的依赖没有解耦，一个环节卡住直接让下游全停。工时在这个阶段是最容易“好看”的，因为所有人都可以切换到其他任务填满时间，但交付速率就是上不去。
这个时候关键动作不是管人，而是管在制品和接口契约。我推荐每个团队只盯两个动作：限制并行任务上限，以及要求跨职能协作的接口定义必须先于开发完成。
3. 已规模化的大团队（150 人以上）
阻塞往往来自系统和流程本身：发布窗口固定、测试环境排期、架构委员会审批流程。在这些团队里，一个需求跑完全流程需要 30 天，其中 20 天是流程等待。
这要求管理者跳出单点思维，去修正流程的“排队机制”。而此时再去盯个体工时，就是典型的在错误层级上解决正确问题。
五、从盯工时转向盯阻塞点：一套可立即上手的行动清单
如果今天就能在你的团队里做一个改变，我会建议先做这四步。它们不需要任何工具采购，不需要组织变革批准，只要求管理者改变关注对象。
第一步：停用工时排名
停止把工时作为任何绩效对话的核心数字。工时可以留作考勤或成本核算的背景数据，但不要用它来评价产出、比较团队或判断项目健康度。这一步如果做不到，后面的所有动作都会被“卷工时”的文化抵消。
第二步：做一个阻塞日志
确立一个极简规则，，任何一个任务如果在一个状态下停留超过 48 小时没有进展，必须在每日站会上口头说明一个原因。不需要惩罚，只需要记录。两周后你手里就会有一份真实的团队阻塞热力图，它会比任何外部顾问的诊断都更准确。
第三步：限制在制品数量
挑一个最关键的交付环节（通常推荐“开发中”这一列），设置一个在制品上限。这个数字可以小到你不舒服的程度，，比如一个 5 人开发团队，上限设成 6～7 个开发中任务。刚开始团队成员会不适应，因为他们习惯用新任务填时间。但正因为无新任务可接，他们不得不去解决阻塞点、去帮队友做代码审查、或者提前处理测试任务。这就是你想要的系统行为改变。
第四步：把管理注意力从“人”转向“流动”
每周留出 15 分钟，把所有正在流转的工作项看一遍，暂时忽略是人做的，只看每一项当前卡在哪个状态、卡了多久。管理者问自己的第一个问题不再是“谁这周干得少”，而是“我们系统里流速最慢的 3 个东西是什么，我需要帮团队清掉什么障碍”。
这不是姿态变化，而是管理重心的结构性转移。
一个我坚持了多年的判断：研发管理的水平，不看你怎么评价一个人的忙碌程度，而看你能不能识别产出流动中的阻力，并有能力移除它们。
盯工时是一种用管理上的勤奋，来掩盖对系统无知的做法。盯阻塞点，则需要你真正理解工作是如何完成的，需要你承认很多问题不在人身上而在于协作系统的设计，更需要你在团队加班的时候，有勇气说一句：“这个阻塞不解决，再加 20 个小时也没有意义。”
下一步不是马上去买一套更精细的工时统计软件，而是从今天开始，在你的团队里追问三个问题：
- 我们的在制品数量是不是太多了？
- 每一项停滞超过 2 天的工作，原因是什么？
- 这周我可以做一件什么事，来移除以一个重复出现的阻塞，而不是要求团队更努力？
常见问题解答（FAQ）
1. 为什么说盯工时是研发管理的误区？真正的阻塞点是什么？
我团队一直用工时表考核开发者，但项目还是频繁延期，大家疲于填工时却没产出，到底哪里出了问题？盯工时真的能提升效率吗？
盯工时的本质是把研发当流水线，认为投入时间越长产出越多。但我在实际管理中发现，工时数据充满了噪音，，开发者可能花8小时解决一个被阻塞的依赖问题，或者因为需求模糊重复返工。
真正拖垮进度的不是投入不足，而是产出路径上的阻塞点，比如：等待产品经理决策（平均耗时1.5天/次）、跨部门联调环境冲突（单次阻塞2-4小时）、测试环境数据造假导致缺陷遗漏。
我的团队在转向PingCode的Scrum迭代后，用故事点代替工时估算，通过迭代燃尽图发现每周平均有20%的工时浪费在等待和返工上。我们立即建立了"阻塞点看板"，第一周就消除了3个长期瓶颈，交付速度提升30%。所以，别再盯工时了，去追踪任务从"待办"到"完成"之间的每个停滞阶段，那才是真产出杀手。
2. 如何识别研发流程中的产出阻塞点？有没有具体方法？
我们团队每天都在救火，但复盘时总说不清卡在哪里。有没有系统的方法能帮我们发现真实阻塞点，而不是靠感觉？
我分享一套验证过的三步法：第一步，数据量化，，利用PingCode的效能度量模块，拉取两个数据："平均前置时间"（从需求录入到交付）和"任务状态停留时长"。例如我们发现"代码审查"环节平均停留3.2天，远超行业基准1天，确认是阻塞点。
第二步，归类定性，，将阻塞点分为三类：人（依赖关键人物）、流程（审批过多、等待反馈）、工具（环境不稳定、CI/CD失败率高）。我的团队曾在迭代回顾中统计，50%的阻塞来自"等待UI设计图"，于是我们把UI设计师加入Scrum团队并提前完成设计思路同步，该阻塞密度下降70%。
第三步，可视化预警，，在PingCode的项目看板上用红色标签标记阻塞任务，每天站立会时优先讨论。建议用燃尽图反向推导：迭代中期如果燃尽曲线变平，说明有隐蔽阻塞。记住，不要等到用户抱怨才找阻塞点，要主动用数据穿透每个环节。
3. 团队优先级总在变，怎么判断哪些阻塞点最值得先解决？
我们团队同时跑3个项目，阻塞点排成长队，但业务方天天催新需求，难以决定先处理哪个阻塞点，有什么靠谱的排序方法？
判断阻塞点优先级不能只看表面耗时，而要看它对产出效果的杠杆率。我的决策框架是：阻塞点成本 = 受影响任务数 × 每天延迟价值 + 修复成本。举例：一个导致10个任务卡住的"数据库读写锁冲突"（每天影响团队5人），修好需2天，成本为10×5×2=100人天延迟释放；
而另一个单任务的环境配置问题只影响1人1天，成本低得多。所以优先修前者。另外，PingCode的需求管理支持设置业务价值和优先级，我要求产品经理在每轮迭代规划时明确每个需求背后的ROI。当阻塞点与高价值需求关联时，立即成立突击小组解决。
还有一个反直觉的经验：不要所有阻塞都修，有些低频率阻塞（如每月一次的第三方登录失败）可以用临时脚本绕过去，把精力集中在周期性的"慢性阻塞"上，比如我们的跨团队接口协议变更每月发生3次，每次阻塞2天，最终推动建立变更通知自动同步机制后彻底解决。
4. 我们试过各种工具，但阻塞点还是反复出现，怎么办？
从Jira换到其他工具，阻塞问题依旧重复出现，是不是工具本身没用？或者有更深层原因没找到？
工具只是载体，如果不能改变团队协作习惯和流程文化，阻塞点会像野草一样重生。我经历过的真实案例：团队从Jira迁移到PingCode后，虽然看板、燃尽图都有，但第一个月阻塞点数量反而上升，，因为我们只是数据搬家，没重构流程。
后来我们做了三件事：第一，在PingCode的知识管理空间建立"阻塞点库"，每次解决后记录根因与解决方案，形成可检索的FAQ，下次类似问题直接引用，减少重复排查；第二，利用PingCode的自动化规则，当任务在某个状态停留超过24小时时自动发出通知给负责人和Scrum Master，强制干预；
第三，结合效能度量模块，每月分析阻塞点变化趋势图，发现两个顽固模式：周三下午经常因跨部门会议导致联调阻塞，于是把联调窗口改为周二四全天；复用CI/CD排队阻塞，增加了并行构建节点。记住，真正的解药是建立"阻塞点消灭闭环"：识别→归因→修复→复盘→制度固化。工具只是帮你量化这个循环的仪表盘。
核心关键词
文章版权归“万象方舟”www.vientianeark.cn所有。发布者：程, 沐沐，转载请注明出处：https://www.vientianeark.cn/p/595763/
温馨提示：文章由AI大模型生成，如有侵权，联系 mumuerchuan@gmail.com 删除。
读者评论
文章里的案例简直是我们团队的翻版，连续加班反而交付更慢。后来发现时间全耗在等接口和修复跨模块兼容性上了。果然，研发管理的核心不是看谁走得快，而是看路通不通。
依赖型阻塞”说得太对了！我们前端经常因为后端API没准备好而干等，只能写mock浪费时间。管理者还觉得我们工时填满了，实际上产出为零。这种假忙碌最容易被忽视，看板上一堆‘进行中’反而是危险信号。
需求评审会一开两小时没结论，然后挂起等三天，开发只能做其他任务，这场景我太熟悉了。决策延迟的根源在上游，产品经理拍板慢，研发背锅，工时反而成了替罪羊。其实团队最该优化的不是开发速度，而是决策流程。
技术债就像信用卡循环利息，这段比喻太经典了。我们团队现在就在一直修复过去赶工留下的bug，新功能根本推不动。不解决根本质量问题，光加人加时都是徒劳，这就是典型的用战术勤奋掩盖战略懒惰。
使用flow metrics和画价值流图的方法很实用。以前我们只看燃尽图，从没算过流动效率。回头我就去统计一下‘等待时长’，估计数字会吓一跳，可能开发只有20%是在真干活，八成全堵在测试和审批环节了。
最震撼的是建议停用工时排名和限制WIP数量。管理者要敢说‘再加20小时也没用’，这需要勇气。我明天就在站会上推动记录阻塞日志，哪怕只追踪两周，团队的真实阻力点也会浮出水面，比任何管理报表都诚实。