我决定发表这篇博客文章，总结潜在Zerocracy客户在开始考虑从传统管理转向微任务时表达的最流行的担忧。博客文章将定期获得新内容，并将用作我们销售前端的参考教程。
谁将承担非常昂贵且耗时的工作，将较大的任务分解为微任务？
我们没有专门的角色负责这个。程序员使用我们自己的专利待审的方法，也就是Puzzle Driven Development，将较大的任务分解为较小的部分，如M28中解释的那样。
看起来你的管理模式很大程度上依赖于架构师。如果他/她犯了严重错误会发生什么？项目会有致命后果吗？
事实上，在Zerocracy中，架构师是一个技术独裁者。然而，他/她的决定都被记录下来，并经过定期审查，如M2所解释的那样。
看起来，为了雇佣Zerocrat来管理我的项目，我必须改变我的程序员，因为我的现有团队习惯于在传统的按小时支付模式下工作。这是真的吗？
是的，很可能大多数程序员无法适应，如果你迅速转向按结果支付和微任务，你必须让他们离开。除非你按结果支付每个人，Zerocracy才能运作，如M3所解释的那样。然而，如果你过渡缓慢，你可能会挽留住一些最好的开发人员，如M62和M35所建议的那样。
Zerocrat如何知道谁必须处理特定的微任务？看起来这个决定只能由人类做出，而不能由人工智能做出。
Zerocrat有自己的多因素选举机制，决定哪些程序员最适合特定的任务。决定基于他们以往的表现以及当前项目和整个项目池中的工作负载。此外，由于我们管理的每个项目和每个GitHub仓库都是单技术，如M6所建议的那样，即使随机分配任务，也可以安全地将任务分配给程序员。
看起来，您的微任务模式中的自由职业者只对通过微支付获得的短期收益感兴趣，而不关心项目的未来，并且没有承诺长期留在项目中超过几天。这不是一个风险吗？
确实，自由职业者只关心他们个人在他们个人微任务范围内的结果。他们可能拒绝任何任务，甚至在任何时候离开你的项目，因为他们失去兴趣或出于其他原因。然而，我们相信这种自由会使您的项目更加强大，因为从一开始，您就准备好应对高员工流动率，管理系统知道如何处理这种情况。
看起来，您的方法可能在小型项目中效果很好，风险较低，人们可以自由进出而不会对项目造成严重损害。但是，较大的项目需要更稳定的团队和参与者更好的承诺。
首先，如M15所解释的那样，必须将大型项目拆分为较小的子项目，以便管理。其次，无论全职招聘还是外包，都无法像Zerocracy中的微任务可以做到的那样保证高可管理性，参见M22。
当项目刚开始时，如何预测微任务的数量？谁以及如何估计项目的持续时间和预算？
即使我们不提前报价项目并且通常不预估它们，如M60所解释的那样，微任务使估计更加准确和精确，如M27所解释的那样。从项目开始的时候，每周我们会请一个项目参与者重新估计工作范围。然后，我们将收集到的估计和我们的统计数据汇总，以预测项目的未来，以时间和成本为标准。
看起来微任务只有在工作范围非常明确定和程序员清楚知道该做什么的情况下才能奏效。在我们的项目中通常不是这种情况。我们无法将我们的范围确定到微任务的程度。
每个程序员有责任确保这些微任务被正确描述并且其范围清晰。M37解释了程序员如何处理不确定性。
看起来自由职业者可能很容易失去工作重点，并做一些对项目当前阶段不重要的事情。您如何确保他们足够专注？
确保团队专注于产品范围的特定领域是架构师和客户的责任。M59解释了如何做到这一点，以使团队保持控制和专注。
看起来微任务只适用于初级程序员，他们处理原始工作片段没有问题。高级程序员不会喜欢这个，并且不会留在项目中。
Translated by ChatGPT gpt-3.5-turbo/42 on 2024-05-27 at 01:18
