弥合工程师与管理者在开发者生产力认知上的差距。软件工程管理者都希望开发者尽可能高效地工作。但在现实中我们也常常听到开发者抱怨许多原本为了提升开发者生产力而引入的系统、工具和流程实际效果却适得其反甚至让他们更难专注于真正有价值的工作。为了找出这种认知错位的根源我们面向开发者社区开展了一项小规模调研希望了解开发者究竟如何看待自己的生产力。对于工程领导者来说理解这些结果非常重要。高质量代码的持续交付和开发者的士气、工作满意度以及整体绩效密切相关。工程管理的最终目标是帮助开发者发挥出最佳水平。这也意味着管理者不能只从报表和指标出发理解开发者生产力更需要理解开发者自身对生产力的真实感受。开发者生产力为什么越来越重要预算充足、团队快速扩张的日子已经过去至少在当下是这样。全球软件开发团队都面临着相似的挑战预算收紧、效率审查加强、强制返岗以及大规模裁员带来的不确定性。在这样的行业环境下理解开发者生产力不只是为了“让开发者做得更多”更是为了帮助管理者创造更好的工作环境让团队在资源更有限的情况下完成更多真正有价值的工作。同时这也有助于发现当前研发流程中的浪费环节。例如如果某些工具或耗时耗力的会议正在挤压开发者的专注时间那么减少这些干扰就可能带来双赢企业节省了成本开发者也能获得更好的工作体验。对于一些跨部门协作频繁的团队来说借助Worktile这类通用项目协作系统将任务、项目、文档、日历和审批等信息统一管理也能减少重复沟通和低效会议让团队把更多时间留给真正重要的工作。很多管理者可能没有意识到一些看似能提升生产力的机制比如频繁的进度检查会议实际上可能会降低开发者的工作效率。反过来真正有效的流程设计也能帮助管理者看清哪些机制确实在提升开发者生产力。通常来说更合理地安排协作会议或者设立无会议日往往会对开发者生产力产生积极影响。因为这些做法能让开发者把更完整的时间投入编码而不是在一场场会议之间不断切换上下文只能用碎片时间推进工作。当然每个团队的情况都不同。最好的方式仍然是通过一对一沟通直接询问工程师哪些因素最影响他们的工作状态哪些流程真正帮到了他们哪些机制正在消耗他们的效率开发者和管理者一样都希望提高生产力调研显示当开发者感觉工作进展顺利、节奏稳定时他们的幸福感和满足感最高。换句话说开发者希望自己更高效管理者也希望他们更高效。双方的目标并不冲突真正的问题在于双方对“生产力”的理解并不完全相同。对开发者来说生产力往往和“心流状态”密切相关。所谓心流状态指的是工程师完全沉浸在工作中保持高度专注并持续高效产出的状态。这并不是一句空泛的说法而是一种真实存在的工作节奏。开发者只有在这种状态下才更容易发挥出自己的最佳水平。当开发者频繁受到打扰或者被复杂流程阻碍而无法进入心流状态时工作就会变得混乱、繁琐也更容易令人沮丧。同样重要的是开发者需要感受到自己正在对代码库、团队乃至整个组织做出有意义的贡献。一位开发者在调研中说道“我希望自己能对团队或整个组织产生影响。缺乏生产力、工作量不足或者长期从事琐碎工作都会让我感到沮丧。”另一位开发者也分享道“如果我无法保持高效我会觉得工作变得更难也更难享受它。当我效率很高时一天过得很快而且我也很享受自己正在做的事情。”当开发者长期感觉自己效率低下时挫败感和不满情绪会不断累积进而让他们变得消极、缺乏动力甚至逐渐失去对工作的热情。对于希望打造优秀开发者体验、持续交付高质量产品的团队来说这显然不是一个好信号。如何衡量开发者生产力团队层面的生产力通常更适合用量化方式衡量而个人层面的生产力往往更需要结合定性视角来理解。大多数组织在衡量开发者生产力时更关注指标驱动的方法例如代码变更数量、故事点数、已完成工单数量等并将这些结果逐级汇报给高层管理者。然而调研显示开发者在判断自身工作效率时往往会使用更偏定性的标准例如自己在计划内工作和计划外工作上分别花费了多少时间是否拥有足够的专注时间是否真正推进了重要事项。在不同场景下同时使用这两类方法仍然很有必要。例如通过比较六个月前和现在每个迭代周期交付的故事点数可以观察团队生产力随时间变化的趋势判断团队整体效率是在提升还是下降。与此同时当团队层面的生产力指标没有达到预期时一些更定性的线索可能更有价值。例如开发者是否花费了大量时间处理临时问题、调试突发故障或者反复向同事解释背景知识。对于希望系统化衡量和提升研发效能的团队来说PingCode这类智能化研发管理工具可以将目标、需求、项目、开发、测试、发布和 Wiki 知识沉淀等环节打通让研发过程中的数据更自然地流转起来帮助管理者在团队指标与个人体验之间建立更完整的观察视角。何时使用团队层面的生产力指标衡量开发者生产力最传统的方式是从团队层面进行评估。对大多数团队来说这通常意味着使用故事点数、迭代速度、已解决问题数量或完成工单数量来衡量团队在某个迭代周期或时间段内的表现。这些宏观指标是评估团队整体绩效的重要组成部分。通过持续追踪故事点数或交付速度决策者可以了解团队的长期发展状态并获得更稳定的速度数据从而更准确地估算未来的交付周期。此外团队层面的指标也能帮助管理者观察团队成员休假、人员变动或其他产能影响因素对交付节奏造成的影响。但问题在于团队层面的指标并不能完整反映开发者的真实感受也不适合简单地用来评价个人绩效。如果一对一沟通只关注“你这周交付了多少故事点”管理者很可能会忽略许多重要信息。开发者可能在那一周参加了太多会议可能缺乏足够清晰的优先级可能被大量临时事务打断也可能遇到了某个重大技术障碍。因此除了团队层面的量化指标管理者还必须关注更细微、更定性的生产力信号。何时关注个人层面的开发者生产力团队由一个个具体的人组成。每个人的动机、家庭情况、压力承受能力和工作节奏都不同。因此采用一刀切的激励方式很难真正激发所有成员的潜力。从个人层面思考开发者生产力往往比单纯从团队层面观察更有价值也更容易得到可执行的洞察。个人层面的衡量维度可以包括专注工作时间、投入明确优先事项的时间、发布新功能所需时间以及被计划外工作打断的频率。同样需要注意的是基于团队指标的生产力衡量有时会滞后于个人层面的生产力问题。也就是说当团队指标已经明显变差时问题可能已经持续了一段时间。因此管理者有必要更早关注个人层面的生产力信号以便及时发现潜在风险。衡量个人生产力可以从哪里开始对于开发者来说生产力具有很强的主观性它取决于个人经验、工作内容和所处环境。以下是一些开发者对生产力的理解。第一能够在不受干扰的状态下专注完成任务。“对我来说高效意味着能够很好地专注于当前任务比如开发新功能或修复错误。”第二能够稳步推进而不是反复倒退。“在主要优先事项上持续前进避免因为质量问题而频繁返工。”第三能够感受到自己的工作产生了业务影响。“真正重要的是业务影响。这与故事点数、提交的 PR 数量或代码提交次数无关这些指标有时会产生误导。关键在于它对业务指标产生了多大推动作用。”第四能够看到代码库中真实、可见且有意义的改进。“我喜欢看到代码库中出现可见的改进比如代码差异中的变化以及最终成功部署上线的功能。”从这些回答中可以看到几个关键主题开发者希望拥有较长时间的专注工作环境不被频繁打断希望直观地看到自己对代码库产生的影响也希望理解自己的工作如何为公司的整体目标做出贡献。对于管理者来说理解这些主题有助于和开发者围绕生产力展开更深入的对话。管理者应当带着好奇心发问而不是只用指标下判断。例如在一对一沟通中你可以询问开发者他们的日程是否被重复会议或临时任务占据每周是否有足够的专注工作时间他们是否能看到自己对代码库的贡献他们是否理解自己正在做的事情如何影响团队和业务目标这些基于好奇心的问题能帮助管理者更准确地理解开发者的真实状态也能帮助管理者找到提升个人生产力的具体切入点。将这些个人层面的洞察与团队层面的量化指标结合起来才能更全面地理解团队的生产力状况。当然并不是每个人都能遇到主动提出这些问题的管理者。在这种情况下开发者也需要学会为自己争取空间主动表达自己在专注时间、工作影响、流程阻碍和个人成长方面的真实感受。最后想说的提升开发者生产力不能只看团队层面的数字也不能只依赖个人感受。团队层面的指标能够展现整体表现并为交付预测提供依据而个人层面的信号则有助于解释这些指标背后的原因。真正有效的开发者生产力管理需要把两者结合起来既关注团队整体交付趋势也关注每位开发者能否进入心流状态、完成有意义的工作并清楚看到自己的贡献。只有当管理者真正理解开发者如何看待生产力团队才有可能建立更健康、更高效也更可持续的软件交付方式。