Denis Ermakov, 在 Techflow 的软件工程师 Denis Ermakov 在 Techflow 的软件工程师

软件工程中的生产力神话

在过去的二十多年里，软件工程中的生产力概念已经演变和扩展到了各个方向，常常带来混乱或矛盾的结果。在我早期的职业生涯中，我曾经错误地认为，工作时间越长，编写的代码越多，活动越多，就意味着更好的结果。但是，这种生产力的观点——从开发人员到团队领导，到工程经理——似乎只会对其本应实现的目标产生反作用，不仅损害了代码质量，还严重影响了开发人员的福祉。在这篇文章中，我将分享我遇到的关于生产力的误解，并揭穿围绕技术行业生产力的最常见的神话。通过个人故事、实际团队经验和研究支持的观察，我将论证真正的生产力与疯狂的加班和更多的“活动”无关，而是与有针对性的专注、健康的工作习惯和平衡的组织文化有关。我希望，通过打破这些幻觉，我们可以重新思考如何管理软件项目和处理创造它们的人。加班的幻觉我遇到的最早的生产力幻觉之一是，长时间加班一定会带来更好的结果。在我的初期工作中，我承担了一个大型的支付系统升级任务，时间非常紧迫。由于接近截止日期，我说服我的团队晚上和周末加班近两个月。但六个月后，问题开始出现。可能是在团队疲惫的晚上编码过程中引入的微妙错误开始出现在生产环境中。这些问题需要额外的时间和资源来解决，但客户的信任也被破坏了。更糟糕的是，这次英勇的加班只因为两名关键团队成员因压力和不满而辞职。很明显，短期内按时完成任务的成功是以巨大的长期成本为代价的。因此，认为时间可以保证生产力的神话被证明是灾难性的。质量时间与数量时间创造力和问题解决能力——现代软件工程中两个至关重要的技能——会因疲劳而大大减弱。多年来使用时间跟踪工具，如RescueTime和Toggl，来研究我的团队的工作模式，得到了很有趣的结果：我们的最高质量代码是在开发人员享受规律的4-5小时无干扰集中时间时产生的。当个人推进10-12小时的工作日时，错误率经常激增，返工可能会消耗更多的时间。在采用更有节制的时间表后，我们看到错误减少，团队满意度提高，最终，交付时间更加可预测。专注的陷阱另一个根深蒂固的神话是，开发人员应该“保持在线”并每分钟都在输入代码才能被认为是高效的。这种误解可能会导致公司实施严格的活动监控系统，痴迷于按键或屏幕时间。我见过一些公司鼓励一种文化，即出现在网上的时间越长就越被认为是致力于工作的标志。这完全忽略了软件开发中那些必不可少的无形活动，例如规划、讨论、研究和概念设计。远离键盘的突破我经历过最引人注目的例子之一是在去年，当时我的团队正在与一个棘手的微服务架构问题作斗争。两周来，我们都在努力调试一个复杂的服务网络。最后，我们休息一下，进行了一次更非正式的对话。在喝咖啡时，我们在白板上草拟了一个解决方案，这个解决方案比我们之前苦苦挣扎的复杂性要简单得多。那些30分钟的对话节省了我们可能需要数月的痛苦重构时间。这是一个强有力的提醒，有效的解决问题往往发生在IDE的范围之外。重新思考生产力指标如果“工作时间”和“持续活动”是有缺陷的指标，我们应该追踪什么？软件工程中的传统生产力衡量标准通常关注表面输出：代码行数、提交次数或关闭的票数。虽然这些可以提供一些高层次的见解，但它们容易被滥用。开发人员可以提交更少的逻辑变化，或者选择更冗长的方法来实现某些事情，以操纵代码行数的衡量指标。一般来说，这些衡量指标不太适合跟踪开发进度，因为许多这些指标会对最小化维护问题产生反作用。更全面的方法在过去的几年里，我的团队和我一直试图找到有意义的输出衡量指标，以确保我们的努力会转化为实际的收益。 新功能的上市时间 我们能多快交付一个对真正的用户有价值的功能？这是衡量吞吐量比原始代码更可靠的方式，因为它让我们考虑交付的功能是否真正有用。 生产环境中的事件数量 低事件率意味着更好的代码质量、更彻底的测试和更好的架构决策。频繁的生产环境事件表明了隐藏的技术债务或开发中的捷径。 代码可维护性评分 我们使用自动化工具，如SonarQube，来检测重复、复杂性和潜在的漏洞。随着时间的推移，评分保持稳定或改善，表明代码更健康，文化尊重长期质量。 团队知识共享 我们不仅关注个人的输出，还检查知识在团队中流动的程度。成对地处理任务，进行彻底的代码审查，并记录重要的架构决策？一个信息丰富的团队可以更集体地处理问题。 客户满意度评分 最终，软件是为用户而设计的。积极的反馈、低支持票量和强大的用户采用率可以是真正生产力的优秀指标。 通过关注这些更广泛的衡量指标，我们不仅鼓励更好的编码决策，还确保我们的优先事项与用户需求和可维护的解决方案保持一致。战略性懒惰的力量我曾经认为，伟大的开发人员是那些每天编写成千上万行代码的人。随着时间的推移，我发现事实恰恰相反。事实上，最佳的工程师会练习我所说的“战略性懒惰”。他们不会直接跳入一个复杂的解决方案，而是会花时间设计或找到一个更优雅的替代方案——一个需要更少代码、更少依赖项和更少未来的维护工作的解决方案。我记得一个项目中，一名初级开发人员花了三天时间编写一个数据处理脚本，长达500行代码。它很笨拙，冗余，但它确实有效。后来那天下午，我的团队中的一名首席开发人员能够展示出一个紧凑的50行解决方案，干净，性能也更好。实现真正生产力的工具和技术建立真正生产力的环境——而不仅仅是简单的“忙碌”——需要合适的工具和组织思维方式。多年来，我尝试了各种框架，并发现了一些可靠的策略： 修改的番茄工作法 传统的番茄工作法25分钟的时间段可能对于深度编程任务来说太短了。我的团队经常使用45分钟的专注块，接着是15分钟的休息时间。这种节奏平衡了长时间的持续关注和必要的休息时间。 看板/Scrum混合 我们将看板的视觉工作流与Scrum的迭代周期相结合。通过利用Trello和Jira等工具，我们限制了正在进行的工作项，并在Sprint中安排任务。这样可以防止上下文切换的过载，并使我们能够专注于完成任务，而不是开始新的任务。 时间跟踪和结果分析 使用Toggl和RescueTime等工具记录时间，为我们提供了对开发人员自然高效时间的洞察。拥有这些信息后，我们为每个人安排关键任务在他们最有效的时间，而不是局限于僵化的9到5时间段。 代码审查和配对编程 协作文化往往比隐士般的行为产生更好的结果。我们经常进行代码审查，偶尔进行配对编程，这有助于我们更早地发现问题，传播知识，并保持代码库的一致性。 持续集成和测试 自动化测试和持续集成管道可以防止仓促、马虎的提交，这些提交可能会破坏整个项目。正确配置的测试快速标记回归，并鼓励深思熟虑、渐进的变化。 建立健康的工程文化也许最有害的神话是，压力和紧张总能带来更好的表现。一些领导者仍然坚持认为，开发人员在无休止的截止日期、持续的冲刺和高风险发布下会表现更好。在我的经验中，虽然紧迫的截止日期可能会带来短暂的努力爆发，但长期的压力最终会导致错误、倦怠和士气问题，这些问题可能会使项目更加倒退。心理安全和可持续的期望我在确保心理安全和开发人员感到舒适地提出担忧、提供替代解决方案和早期宣布错误的环境中看到更好的结果。我们通过定期召开回顾会议来促进这种文化，这些会议不指责个人，而是探索如何改进我们的流程。我们还建立了现实的期望，关于工作时间，允许团队成员休息和休假而不感到内疚。虽然看起来违反直觉，但休息充分和受到重视的团队比那些处于持续压力下的团队编写的代码质量更高。无会议日和专注块在我之前的团队中，引入“无会议星期三”取得了很好的效果。开发人员整个白天都在编码、研究或测试，没有干扰。那些星期三的生产力飙升，团队成员都喜欢那段安静的时间。我们通过在其他日子安排必要的会议来平衡这一点，保持简短以避免陷入冗长讨论的积累中。来自现实世界案例研究的经验教训在更广泛的技术行业中，有很多例子表明，采用平衡的、以质量为中心的模型如何带来更好的产品。像Basecamp（以前称为37signals）这样的公司已经公开讨论了“冷静、专注的工作”的概念。通过限制工作时间和不鼓励加班，他们发布了像Basecamp和HEY这样的稳定产品，具有周到的设计。与高压力创业公司不同，后者会仓促发布有缺陷的功能并损害开发人员的利益。我看到一支团队真正地接受了这一理念。他们重新安排了所有的时间表，加入了休息时间，并对工作时间施加了严格的限制。在一个季度内，开发人员满意度评分大幅跃升——更重要的是，支持票数量大幅减少。重新思考“生产力”的含义最终，我的经历让我定义软件工程中的生产力为：在保持健康的开发环境的同时，为最终用户提供可持续的价值。很容易被伪造的输出所迷惑，例如完全填满的Sprint待办事项列表或长长的提交消息列表。但是，除了表面上的东西之外，坚实可靠的代码需要精神清晰、稳定的合作和周密的规划。平衡的方程可持续成功的公式平衡了明确的目标、合适的工具和关心开发人员福祉和最终用户需求的支持文化。我们可以用三个指导原则来概括这种观点： 有效工作超过延长工作：真正重要的是交付了什么，而不是团队坐在屏幕前的时间有多长。 以结果为导向的指标：监控与结果相关的指标，例如可维护性、缺陷率或用户满意度。 文化持续改进：真正的生产力来自于工作流程、团队合作和代码编写的渐进式改进。回顾、灵活的时间安排、知识共享——这就是使得可持续的步伐在时间推移中成为可能的原因。...