相信他们，就可以完成工作！
敏捷宣言中有十二项原则。 第五个人说：“围绕有动力的人建立项目。 给他们提供所需的环境和支持，并相信他们能够完成工作。” 我不同意。 强烈地。 这个公式建议以二进制的方式对待人：他们要么是积极进取的，就是被信任的，要么……是什么？ 他们必须放手吗？ 根据我的观察，这种心态非常典型，并导致管理不善和项目失败。 相反，我们的人员管理必须更多地迭代并且不那么僵化 。
几天前，我在Instagram上发布了我最近有关软件工程的书Code Ahead的引用 。 我的一位读者提出了一个有趣且非常典型的回答（有点打磨）：
我为什么首先要受到惩罚； 如果我的错误无法原谅，他们应该解雇我，而且我相信这比受到惩罚然后再待在他们身边要少羞辱。
当我开始谈论软件团队中的奖惩时，几乎总是听到这句话。 我听说这很丢脸 ，程序员永远都不应受到惩罚。 相反，正如Samir所建议的那样，当他们犯了无法原谅的错误时，应将其开除。 因此，我们要么100％相信他们，要么当发生错误时，我们……解雇该死的混蛋，无论如何他还是没用！
好吧，这也许是人性的一部分：首先我们爱，然后我们恨，而我们越爱，我们就越恨 。 但是这些情绪与专业项目管理有什么关系？
正如威廉·爱德华兹·戴明 （ William Edwards Deming）多年前所建议的那样，良好的管理总是与一个简单的“计划-执行-检查-执行”周期有关。 无论我们管理什么和由谁管理，我们都必须先计划 ，让我们自己和我们的员工来完成工作，然后检查结果，将其与我们的计划进行比较，最后根据发现采取行动 ，对计划进行纠正。 然后，我们返回到计划部分，然后循环重新开始：
众所周知，这就是必须开发软件的方式。 许多年前，我们都意识到瀑布模型是个坏主意，在瀑布模型中 ，所有事情都是预先计划好的，然后按照计划实施，而在项目进行过程中并没有改变。 一个更好的主意是提供软件增量 ，从而改变每次迭代后的图纸和技术规范。 这样可以保证更高的质量，对错误的更快反应以及更好的可预测性。 很明显吧？
我们为什么不对人做同样的事情？ 为什么我们要先激励他们，然后再信任他们……直到他们变得完全不可信 ？ 我们不能定期检查他们的表现并相应地更正我们的信任吗？ 为什么它们对我们“伟大”或“无用”？ 为什么我们不能在每次迭代后根据错误和成就对它们进行评分？
让我们看看如何将敏捷建议的公式应用于PDCA连续体：
- 计划：找到个人并激励他们
- 要做：相信他们，他们就能完成工作
- 检查：
- 行动：
似乎缺少了两个重要的部分。 我们不会检查我们是否仍然可以信任他们，他们是否仍然有动力，他们是否有兴趣完成工作，以及是否该更换他们中的一些人。
为什么这样？ 我们在害怕什么？
此外，为什么程序员在定期检查结果时会感到羞辱，从而导致微小的奖励和惩罚，而同时又发现单个“无法原谅”的错误会被炒鱿鱼呢？
我有一个答案。
因为在大多数情况下，他们的经理人都很虚弱和愚蠢 。 他们根本不知道如何逐步奖励和惩罚程序员。 他们不知道如何逐步衡量人的进步。 他们的控制工具基于内和恐惧：他们将程序员聚在一起， 洗脑 激励他们，然后让他们害怕犯下无法原谅的错误。
确切的错误是什么，没人真正知道，这是经理的个人决定。 可能是单元测试失败， 会议错过，电子邮件不礼貌或在办公室喝酒。 规模非常大，到那时程序员将被解雇，没人知道。 甚至经理也无法解释。 在大多数情况下，决定是情感和个人决定 。
您知道范围管理中的一个非常典型的错误是使用0/100完整性规则来处理大型任务：它们“甚至没有开始”或“完全完成”，而中间没有。 您可以用小任务来做 ，而不能用大任务来做，因为这将导致缺乏控制力和更大的失败风险。 您必须将范围分成较小的部分，然后应用0/100规则。
人也是一样。 您不能信任他们0/100：要么完全信任他们，要么解雇他们。 这太冒险了。 您必须将他们的信任度和动机分解为较小的部分，并逐步增加您的满意度和挫败感。 你是怎样做的？ 通过微积分和微罚 。
能怎样？
翻译自: https://www.javacodegeeks.com/2019/05/trust-them-get-job-done-not.html