The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
敏捷宣言中有十二项原则。第五项原则说：“围绕积极主动的个体来构建项目。给予他们所需的环境和支持，并相信他们能够完成工作。”我不同意。非常不同意。这个公式暗示着以二元方式对待人：要么他们积极主动并且受到信任，要么……什么？他们必须被解雇？根据我的观察，这种心态非常典型，会导致管理不善和项目失败。相反，我们的人员管理必须更具迭代性，而且更加灵活。
就在几天前，我在Instagram上发布了一段来自我最近关于软件工程的书籍《Code Ahead》（/code-ahead.html）的引文。我收到了一位读者的有趣而典型的回应（稍作修改）：
这几乎是我在谈论软件团队奖惩时经常听到的。我听到人们说这是羞辱，程序员应该永远不会受到惩罚。正如Samir建议的那样，当他们犯下不可原谅的错误时，我们应该解雇他们。因此，我们要么100%信任他们，要么在发生错误时…解雇那该死的混蛋，他无用了！
嗯，也许这是人性的一部分：我们先爱，后恨，而且我们越爱，我们越恨。但这些情绪与专业项目管理有什么关系呢？
正如威廉·爱德华·戴明多年前所建议的，良好的管理始终是一个简单的Plan-Do-Check-Act循环。无论我们管理什么和谁，我们首先要计划，让自己和我们的团队执行工作，然后检查结果的情况，将其与我们的计划进行比较，最后根据发现的情况行动，修正计划。然后，我们回到计划部分，循环重新开始：
我们都知道软件开发必须这样进行。多年前，我们都意识到瀑布模型是一个坏主意，即一切都在前期计划，然后按计划实施，项目过程中计划不发生变化。一个更好的想法是按照每个迭代的计划和规范逐步交付软件。这可以保证更高的质量，更快的错误反应和更好的可预测性。这是显而易见的，对吧？
为什么我们不对人也这样做呢？为什么我们事先激励他们然后信任他们…直到他们被证明完全不值得信任？我们不能定期检查他们的表现并相应地调整我们的信任吗？为什么他们要么对我们来说是“伟大”的，要么是“无用”的？为什么我们不能根据他们每次迭代的错误和成就来对他们评分？
让我们看看敏捷方法建议的公式如何适用于PDCA连续循环：
相信他们，他们会完成工作
Check: —
Act: —
似乎缺失了两个重要的要素。我们没有检查我们是否还能相信他们，他们是否还有动力，他们是否对完成工作感兴趣，以及是否是时候替换其中的一些人了。
为什么会这样呢？我们害怕什么？
此外，为什么程序员会觉得当他们的成果定期受到检查并且会有微小的奖惩时，这是一种羞辱，但同时他们觉得因为一次”不可饶恕”的错误而被解雇是完全可以接受的呢？
因为他们的管理者软弱而愚蠢，在大多数情况下。他们根本不知道如何逐步奖励和惩罚程序员。他们不知道如何逐步衡量人的进步。他们的控制手段基于罪恶感和恐惧：他们把程序员聚集在一起，激励他们，然后让他们害怕犯下一个不可饶恕的错误。
到底是什么错误，没有人真正知道—这是一个管理者的个人决定。它可能是一个损坏的单元测试，一个错过的会议，一封粗鲁的电子邮件，或者在办公室喝酒。范围非常广泛，程序员将被解雇的那一刻，也没有人知道。即使是管理者也无法解释。在大多数情况下，这个决定是情感和个人的。
你知道，范围管理的一个非常典型的错误就是用”0/100完全度规则”对待大任务：它们要么”还没有开始”，要么”完全完成”，中间没有其他选择。你可以对小任务这样做，但对大任务来说不行，因为这会导致失控和更高风险的更昂贵的失败。你必须将范围分解成更小的部分，然后应用0/100的规则。
对人也是如此。你不能完全信任他们或完全不信任他们，这太冒险了。你必须将他们的可信度和动机”分解”成更小的部分，逐步交付你的满意和挫折。你如何做到这一点？通过微小的奖励和微小的惩罚。
How to not hire a bad programmer? #management
— Yegor Bugayenko (@yegor256) June 16, 2019
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:08
