Codus Interruptus 别再浪费时间 云企业战略博客

省时妙计：别再浪费时间了

关键要点

在面对新需求时，很多人常常抱怨“我没有足够的时间”，之后便讨论如何优先处理。然而，问题不在于缺乏资源，而是我们如何使用宝贵的时间。实施更有效的决策，减少无效工作，以及利用适当技术，可以大幅提升工作效率。通过消除瓶颈和不必要的等待，我们能显著提高团队的生产力。

“别浪费时间；时间太宝贵了，我们不能保证明天会来。”凯瑟琳普尔西法

在新需求面前，“我没有足够的填空”是常见的抱怨，接着往往会提到“我们需要优先处理”。我发现，问题或许并不是缺乏资源，而是我们对时间的使用不当。

一种稍显调侃的指标官僚质量指数BMI，可以用来量化这个问题。我的理解受到了许多公司如麦当劳长久以来采用的管理指标的启发单位生产小时。单位生产小时是衡量直接为顾客结果做出贡献的活动的时间，如准备食物或开发电子商务应用中的增值功能。不直接为顾客结果做出贡献的时间则被称为非单位生产小时，这些活动虽然可能是必要的，如清点库存或遵循合规要求，但并未直接创造价值。理论上，组织应优化单位生产小时，通过减少非单位生产活动的时间来实现。

BMI 的公式如下：

在这个公式中，NVA 表示员工在参加状态会议或协商所需数据访问权限等活动中所耗费的非增值时间。W 是在增加价值活动恢复前所花费的时间例如，等待决策或基础设施团队处理项目关键路径上所需的计算实例。Total 是员工在一段时间内可用的总时间。

BMI 是一个直观的衡量组织浪费的指标，但很少被量化。对此，没有单一原因。了解 BMI 可能被视为不“具有领导气质”，因为这需要毅力和关注细节，似乎比公布又一轮组织重组更枯燥。领导者可能对组织的有效结果缺乏理解，而员工可能缺乏心理安全感，无法分享他们的时间实际如何被使用，这无疑是个不幸的情况，因为这些员工往往能提供如何通过官僚主义效率低下来浪费时间的最佳见解。哈佛商业评论 指出，另一个问题是，被忙碌所困扰的信念，即繁忙是一种生产力和重要性的伪衡量。

尽管这些问题适用于任何角色，但我们可以着重讨论一个我有所经验的角色：开发人员。虽然研究表明技术技能总体匮乏，但问题不仅限于此。关于开发人员生产力的公共报告存在着较大的差异，但大多数都同意，开发者花在开发上的时间不到三分之一。有报告显示，真实的数据甚至不到每周五个小时！

那么，我们该如何解决这个问题呢？

编码助手

自然的倾向是寻找一种神奇技术来解决生产力问题。幸运的是，有一些解决方案可以提供帮助。如果你曾是一名开发人员，你可能还记得花费数小时研究如何编写某个特定功能，或者花费数天调试代码，却发现只是少了一个分号或是一个未声明的变量。AWS 最近发布了 Amazon Code Whisperer，这是一款生成型 AI 编码助手，帮助开发人员将更多时间花在安全地开发上，而不是试图在公共领域寻找通常不可靠的答案。它让我重新投入实践，帮助开发简单应用的时间减少了25，即使在使用我从未使用过的云服务时也是如此。对于经验丰富的开发人员，生产力提升的初步报告显示从30到57不等。

隐藏的浪费

虽然编码助手是一项显而易见的胜利，但这只是开发人员生产力冰山一角。历史提醒我们，新的技术只有在工作方式发生改变时才能真正发挥作用。技术能够加快开发者在代码中的工作，但如何才能扩大可用时间呢？

消除被精益实践者称作的浪费，始于对工作如何“真正”完成的好奇心，以及以高度可见的方式进行映射。我们在麦当劳为一种产品做了这个练习，发现从构思到生产之间有超过160个交接环节。开发团队的工作虽然是两周的冲刺，但整个过程包含了几个月对我们领导者来说隐形的工作！每个人都在忙碌，但没有人对加速整个过程负责，这是一个只有在完整画面被呈现时才能显现出的问题。

消除浪费

我最喜欢的三种消除浪费的方法是：加快决策、允许健康重复、消除瓶颈。这与构建松耦合架构相似，改善这些领域使团队能够更自主地运作，这是我们在 AWS 努力追求的目标，我们坚信“依赖是缺陷”。

加快决策需要创造对决策过程的共同理解，并利用 十条原则 来决定如何将更多决策深入到组织中，运用单向和双向决策的心理模型。决策会被优化为速度和可逆性，而不是伪追求完美决策。

健康的重复往往被视为在组织中追求效率的绝对敌人。在 AWS，我们使用一个双重公式来打破这一传统。“2 gt 0”强调两支团队执行相同任务总好于因拖慢决策或缺乏责任而无人行动。速度至关重要。公式的补充“1 gt 2”表明，随着时间推移，团队的自然愿望会促使他们达成一致，从而释放出更多时间。

消除瓶颈需要坚持不懈和探索新方法的勇气。虽然我们通常倡导两披萨团队，但汤姆戈登在他的 博客文章 中描述了其他补充解决方案。许多开始于思维方式的转变。如果你是一名基础设施领导者，是否允许 自助服务 提供计算实例或存储，例如 Amazon EC2 或 Amazon S3，而不是坚持老式的工单申请？如果你是合规领导者，如何在 CI/CD 管道中 自动化验证？如果你是安全领导者，为什么你的认证解决方案不使用简单的 API 集成来供一个希望使用它的团队？在每种情况下，关键信息是，如何让你的团队更高效地完成工作，更少地变成潜在障碍。

专注

两披萨或两个产品团队并非解决所有问题的灵丹妙药，但从生产力的角度，它们使团队能专注于手头的任务一个有意义的结果，而非任务清单。授权团队交付成果而不是按照经典的模型，在众多孤岛中各自专注于职责和活动，这是相当强大的。同时，这一构想承认了我们通常拒绝面对的一个事实：我们多任务处理能力较差。例如，如果开发人员不断切换上下文，那么解决复杂问题是非常困难的。

在我之前的 博客文章 中，我提到等待他人所带来的浪费。是的，开发人员可以在这个时间开始新工作，但这通常会增加待完成工作的堆积。对于完成一个可能重要的交付价值的项目，这并不是解决不必要等待时间的正确方法。在开发的背景下，这种浪费可以表现为多种形式：例如在继续编码之前等待决策、等待新的计算实例创建，或者等待其他团队完成安全评估或质量保证。

每当有人切换注意力，就会有适应时间和创造性的连续性损失。在一天内同时进行两个无关的活动而不是一个，时间不会对半分配，相反，生产力会下降20如果更添加活动，情况会更糟。相较之下，当开发人员或任何从事任何任务的人处于流动状态时，他们对所追求的成果清晰而专注，完全沉浸于问题中，不受干扰，可以取得更大的进展。

减少无差异工作

对于开发人员数量不足，这里有个明显的解决方案：减少没有明确好处的编码。许多客户转向云技术的原因，正是为了将更多精力放在交付价值产出上。我们越来越多地看到诸如 Amazon QuickSight Q 这类服务，使得创建仪表盘几乎不再需要编码，而 Amazon SageMaker Canvas 提供了直观的创造结果的方法，不需要编码。生成型 AI 和机器学习可以帮助构建测试用例和创建 合成数据 用于测试。显然，如果真正专注于业务问题，而不是某种预设的解决方案，技术甚至是不必要的。

因此，回到最初的问题。你了解自己组织的 BMI 吗？你的员工清楚，当他们被迫遵循不断增加的官僚法规，同时又被敦促提高生产力时，所处的矛盾局面。打造一个环境，让他们分享他们的见解，惊喜地发现这些改变对他们和你交付价值的速度能够产生积极影响。

参考资料

[1] Waytz Adam “Beware a Culture of Busyness” 哈佛商业评论，2023年2月14日。https//hbrorg/2023/03/bewareacultureofbusyness。

[2] Weinberg Gerald M 质量软件管理。纽约 NY Dorset House Pub 1992。

[3] Hamel G Zanini M 人本组织：创造与内部人一样令人惊艳的组织。哈佛商业评论出版社，2020。

[4] “全球代码时间报告”，2021年，https//wwwsoftwarecom/reports/codetimereport。

标签：敏捷、文化、消除浪费、精益

Phil LeBrun

Phil LeBrun 是亚马逊网络服务AWS的企业策略师和传播者。在此角色中，他与企业高管合作，分享经验和策略，如何利用云技术提升速度和敏捷性，同时将更多资源投入客户。在加入 AWS 之前，Phil 在麦当劳公司担任多个高级技术领导职务。他拥有电子与电气工程学士学位、工商管理硕士学位和系统思维硕士学位。