管理混乱:授权给你的工程团队
管理混乱:授权给你的工程团队
原文：https://medium.com/hackernoon/managed-chaos-empowering-your-engineering-team-67efb07d712d
我相信工程团队使用 Cobol 和 Fortran '77(比' 66 好得多)开发出最好的现代网站。我相信他们使用笔记卡和 excel 文件，吉拉和特雷罗来组织敏捷产品待办事项，什么都不用。我相信团队有领袖和没有领袖。我相信球队想要做的事情。
虽然有点开玩笑，但我真的相信一个成功的、创新的、不断发展的组织必须鼓励其成员决定他们如何完成工作。相信团队能够找到最能实现他们目标的方法，这当然应该与公司目标相一致。有效的领导者提供愿景、价值观和透明度。领导者必须通过在悬崖边设置比喻性的护栏来保护团队，但在这些护栏之间为团队创造一个开放和肥沃的环境，他们是专业人士，很可能比领导者更聪明(这就是你雇用他们的原因！)，去做自己最擅长的事情。
如果你想做到最好，就别挡他们的路，相信他们！
也就是说，我们如何防止组织陷入混乱，一个团队使用 Clojure，另一个 Haskel，另一个 Go，另一个敏捷，另一个瀑布，无止境？如果我们允许这种混乱继续下去，工程团队将在业务连续性方面遇到严重的问题(糟糕，Bob 这个 Cobol 家伙刚刚离开——这里有谁知道 Cobol，谁，谁，Bueller？)、雇佣和可维护性。另一个极端，也是大型组织经常采用的，是对所有技术的严格审批过程，一直到版本级别。要不要用 Scala 2.11.7？好吧，写一份报告，提交给工程委员会，POC，审查，6 个月后，花几十个小时的时间，也许可以把 Scala 放在限制列表上。也许吧。
但是有一个更好的方法，那就是管理混乱。 ***** 混乱可能是有害的，但如果管理得当，它可以成为工程组织拥抱创新和通过技术推动业务发展的强大工具。当工程团队来找你要求使用 Cobol 时，说:“是的！我支持你。但是，我确实有一些问题。你打算在哪里找到 Cobol 工程师？大型机呢？我这里没有。还有，可以用 Cobol 建网站吗？我不知道。既然这里没有人懂 Cobol，你将如何利用其他团队来获得你所需要的帮助？”如果团队有正当理由，并且已经推理出这将如何驱动产品和团队，允许混乱发生。你通过提出正确的问题、考虑周全以及与业务和产品保持一致来管理混乱。通过给你的团队控制权，你已经接受了可以推动业务和产品向前发展的变化(例如技术栈)。
给你的团队控制权，创造一个良好的工程环境。
你真正要避免的是事后的“哦，是的，我们应该想到的”陈述。例如，如果我们的数据科学团队想要开始使用 MongoDB，而我们的平台团队想要使用 Cassandra，如果他们已经考虑清楚并讨论了为什么每个团队需要使用不同的非 sql 数据库，那就完全没问题。这就是管理混乱。我们不希望在实施 6 个月后进行讨论，并说，“我想我们没有理由不能使用相同的方法。”那只是混乱。
另一个例子是我们敏捷团队的一个成员最近做出的决定。大多数球队要么单独使用吉拉，要么使用特雷罗。然而，我们专业网站的一个团队决定，他们希望产品负责人在吉拉创建用户故事，并在 Trello 对工程任务进行分解和评估。我半信半疑——真的吗，两者都是？那不是很混乱吗？它不是。该团队考虑了复杂性，并确定它对产品所有者和工程师都有效，我很高兴地说他们是对的。
总之，不要害怕变化，不要害怕你的团队做出的决定，也不要害怕管理混乱。
***** 管理混沌在概念上类似于分形组织。以下是 Pravir Malik 对分形组织如何运作的精彩描述:
“在元理论中，组织的所有实例，从最小的，如一个想法或一个人，到最大的，如全球市场和地球本身，都是分形:它们存在方式的本质在比它们自身更小或更大的尺度上重复。然而，有一类特殊的分形，即进步的分形，其中分形阶梯是一种无时不在的表现形式，它催生了本质上真正进步和可持续的组织。在事物的计划中，这类分形是至关重要的，掌握它的复制并充分理解它在创建可持续和动态组织中的影响是一种实际需要。”
作者:杰弗里·伯恩是退休计划的首席执行官和创始人，该计划为每个人制定退休计划。
