The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
“你现在在做什么？”——当你从老板口中听到这个问题时，要小心：你正在与一个微观管理者打交道。让我们保持忙碌是这些人的主要目标，这也是他们如此令人讨厌的原因。相反，有效的管理者会确保我们是“高效”的，也就是说，我们的成果满足他们的期望。他们并不关心我们为了实现这些成果做了什么——他们管理的是项目，而不是我们。而使项目可管理的第一步是将其范围分解为更小的部分。
想象一下，你想重新设计你的公寓，为这个工作有几千美元的预算。你雇了一群人，并提前把所有的钱都给了他们。他们让你在两个月后回来，一切都会准备好。你说“好”，然后等待两个月。我相信你已经知道我要说什么了——这个项目很可能会在某种程度上失败。在最糟糕的情况下，你将永远见不到这些人，他们只会偷走你的钱。在最好的情况下，他们会做一些看起来“不错”的事情，但不如你期望的那么好。
为了增加获得最佳情况的机会，你会做些什么呢？没错，你会实施微观管理：每天都去拜访他们，问他们那个著名的“你现在在做什么？”的问题，当他们变懒散时推动他们，控制、支配、烦扰他们，保持“掌控”，当他们错过或忘记时玩弄罪恶感的牌，用尽一切办法来惩罚他们。
你这样做并不是因为你邪恶。你只是知道，否则他们会糟蹋你的公寓，会忘记事情，会错过某些东西，会犯错，会花费比预期更多的时间和金钱，会选择错误的面料，会购买你不喜欢的家具，以及其他许多你很清楚的事情，如果你曾经与室内设计师和房屋建筑商打过交道的话。
你越积极，获胜的机会就越高。
这并不是因为你邪恶。你并不邪恶，你只是愚蠢（不是指你个人，亲爱的尊贵读者，但你懂我的意思）。
问题在于这个项目不可管理。这就是为什么你必须采取最后一招——微观管理。为什么这个项目不可管理呢？因为它的范围没有被分解成各个部分。它包含一个名为“重新设计公寓”的庞大任务。
可管理性的一个关键成功因素是著名的0/100规则，要求任何任务要么“进行中”，要么“已完成”。中间不能有任何东西。当这样的规则存在时，任务可以委派给执行者，他们可以对任务的完成负责，可以被信任。
我们无法将我们的单个大任务“信任”给执行者，仅仅因为它太大而无法被信任。如果他们失败，失败的代价将太高。我们必须用一个微观-视角进入任务中，从内部管理它，烦扰它的执行者，而我们本应该信任他们。我们所做的微观管理是不可避免的，因为范围没有被分解。
范围分解主要是为了解决这个问题：使项目更可管理。我们需要在范围内有小任务，以便能够委派它们，永远不需要进入其中检查发生了什么，谁在做什么，为什么以及在哪里。
我们把范围分解成的任务越小，越好。
在我们的项目中，我们将项目范围拆分成每个任务为30分钟。这可能听起来对你来说太过极端，但对我们来说很有效。我们称之为微任务。我们大约七年前开始实行微任务化。我们尝试了不同的任务大小，从10个小时到15分钟，但最终定为30分钟。
当任务更大时，我们就失去了可管理性，只能回到宏任务管理方式。当任务更小时，上下文切换的开销变得非常烦人。
根据我们的经验，一位资深程序员如果全力以赴参与一个项目，一天可以完成6-10个任务。这意味着他们花费3-5小时在工作上，而其余时间则用于做其他事情。这比我们通过传统的宏任务管理方式能够实现的工作时间利用更加高效（这是我个人的观察）。
如果您决定选择微任务化，您很可能会遇到与我们面临的相同或相似的障碍。以下是其中的一些以及我的建议，如果有一天您决定将“开发移动应用程序”任务分解为2,500多个微任务，这些建议可能会有帮助。
分心。程序员习惯同时做许多不同的事情：他们编写代码、帮助他人、观看YouTube、浏览Facebook、在Reddit上发誓，并阅读我的博客。起初，他们大多数人不会喜欢在他们面前有明确的任务的想法，因为这会给他们的工作时间带来结构，并使其对管理层更加可见。他们会告诉你，除了你那该死的任务外，他们还有许多其他事情要做。我们通过按结果付费和禁止闲聊来解决这个问题。
懒惰。就像公寓设计师一样，程序员也喜欢被付钱而无所事事。谁不喜欢呢，对吧？他们会告诉你，他们的工作比你想象的要复杂，他们需要更多的时间，他们需要先调查问题，阅读文档也需要很多时间，等等。他们简直被传统的宏观任务宠坏了，在那里他们按月薪被付钱，没有人真正监控他们的成果。他们习惯了成为办公室奴隶。我们通过按结果付钱来解决这个问题，懒惰的人就会自动离职。
责任。微任务将使个人的成果可见。当任务庞大时，人们倾向于以团队合作的方式完成，很难确定谁对失败和成功负责。较小的任务强调错误，并让人们为其“付出代价”。不一定是现金，但肯定是以某种方式。大多数程序员会发现这个概念非常新颖和困扰——他们之前几乎从未为自己的错误付出代价，也从未有过自己的任务。责任总是分散在整个团队中。我们通过给予经济奖励和惩罚来解决这个问题，从而使他们非常有动力并准备面对失败。
怨恨。这是最常见且最烦人的问题之一：他们会告诉你他们“不是猴子”。实际上，他们会将上述所有问题相结合，说解决这些问题的正确方式是给予程序员自由，让他们做好自己的工作，因为他们足够聪明，不需要来自上级的任何管理。他们说这些话时很真诚，没有任何操控的意图。问题在于他们习惯了宏观任务，并且认为这是唯一正确的方式。我试图通过撰写这篇博客文章来解决这个问题。
可能还有其他问题，但这基本上是我们面临的问题的详尽列表。
显然，任何方法都有其利与弊。对于我们来说，微任务似乎是最有效的管理范式。然而，根据我们的经验，它并不适用于任何地方。在某些地区，我们无法成功应用它。
UI/UX。在过去几年里，我们主要与服务器端的Java/Ruby/C++项目一起工作，没有太多机会将微任务应用于UI/UX工作。然而，无论我们尝试过什么，都从未真正奏效：图形设计师们无法将任务分解为更小的部分。
客户。我们尝试将从客户那里获取需求的任务进行分解，但失败了几次。也许是我们的客户愚蠢（我对此表示怀疑），也许需求过于复杂，或者我们的系统分析师不够专业。总之，我们意识到这样的任务必须作为一个完整的工作来完成，不能进行任何分解。
消防。当交付速度成为最重要的关注点时，对于我们来说，微任务化并不起作用。调度和指定任务的额外开销花费太多时间。当某事真的很紧急时，我们必须采取传统的宏任务方法，只要“让其运行”。然后我们再回到微任务化。
除了编程、单元测试、手动测试、性能/负载测试、集成测试、部署、代码审查、文档编写，甚至培训之外的其他任务都可以通过微任务来管理，并且必须通过微任务来管理。
微任务的最重要好处就是项目变得更加易管理，正如上面所提到的。下面是更详细的分解：
我们付出更少。尽管我们程序员的小时费率比许多其他项目可负担的费率要高，但我们严格降低了开支。几年前，我进行了一次相对详细的分析，结果显示我们的项目比传统项目节约成本高达30倍（！）。
动力很高。尽管常见的刻板印象是小而孤立的任务会让执行者失去动力，但我们看到的反应却完全相反：当终于可以在明确定义和明确界限内独立地进行工作时，程序员们都感到兴奋。然而，并非所有人都能理解和享受微任务。根据我的个人观察：只有25%的人能够理解和享受微任务。其他人要么不够专业，要么被办公室奴役宠坏了，在那里几乎什么都不用做就能受到很大的尊重和丰厚的奖励。
流动不是痛苦的。为了使微任务成为可能，管理层必须学会如何明确、明确和快速地指定任务。当达到如此高的透明度、形式化和灵活性时，项目变得不那么依赖专家。我们不再担心失去人员，因为我们几乎可以通过任务跟踪系统和项目文档了解到关于项目的所有需要知道的信息。
更容易并行处理。将较小的任务委派给更多的程序员更容易。在某些项目中，我们有时同时拥有超过40名程序员，而任务数量相对较少（最多200个）。
指标工作。当一个程序员每周完成40-50个任务，而另一个程序员只完成5-10个任务时，这确实有着一定的含义，需要记住所有任务几乎都是大小相等的。我们使用这个指标（和其他几个指标）来做出组织和纪律方面的决策。在宏观任务环境中，几乎没有人力资源指标真正起作用。
质量是可强制执行的。大量的小任务意味着我们不断地频繁关闭它们。每次关闭都是质量控制的重要节点。这正是我们有能力说“不”，拒绝违反我们质量标准的可交付成果的地方。对于程序员来说，对于大型任务来说，这个“不”要痛苦得多。
风险是可以接受的。对于整个公寓重新设计失败的风险来说，我们无法接受，因为成本太高——几千美元。然而，接受厨房灯安装的风险是完全可以负担得起的。即使它掉落并损坏，我们只需要花几美元买一个新的。我们不需要控制“装灯人”，我们有奢侈的选择去委托和信任。
程序员获得的好处与我们的好处重叠。如果他们足够专业和积极，他们会发现与微任务一起工作是高效和有效的，这些任务总是明确定义且有适当的报酬。
现在我们常听到关于微任务的最典型抱怨是：“这只适合那些不介意成为代码猴子的初级程序员。”老实说，几年前我们开始尝试XDSD的时候，我也是这么认为的。但我很快发现，最专业和自我激励的开发者们喜欢微任务，而那些不够成熟和技术水平较低的同事们则发现难以跟上节奏。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 21:36
