领导工程团队必须懂的几条核心定律
本通讯由以下机构赞助未被封锁.
[网络研讨会]如何停止对经纪人进行“保姆”式
代理可以生成代码。难的是把代码做对，符合你的系统、团队惯例和过去的决策。你最终会在修正循环中浪费时间和代币。
更多的MCP、规则和更大的上下文窗口让代理能够访问信息，但无法理解。领先的团队拥有上下文层，能够准确地为代理提供当前任务所需的信息。
9月23日直播（免费）观看：
- 团队在AI成熟度曲线上卡住的地方以及为何常见的修复方法难以做到
- 上下文层如何解决质量、效率和成本问题
- 现场演示：同样的编码任务，有上下文层和没有上下文层
如果你想最大化AI代理带来的价值，这款游戏值得你花时间。
感谢Unblocked赞助本期通讯。让我们回到今天的思考！
介绍
重要的是要意识到，团队今天面临的许多问题并非新鲜事。我们已经在协调问题上挣扎，错过截止日期，指标不佳，采用“闪亮的新技术”已经有一段时间了。
这就是为什么理解康威定律、布鲁克斯定律、古德哈特定律、霍夫施塔特定律、阿姆达尔定律和阿玛拉定律等定律如此重要且真正永恒的原因。
值得一提的是，在当今人工智能时代，许多关键技能变得更加重要。随着建设速度的加快，更大的瓶颈变成了协调、沟通和良好领导力。
在今天的文章中，米兰·米拉诺维奇博士将分享领导工程团队需要了解的最重要法律。他还将分享这些法律的具体例子，分享他个人的经验。
让我们介绍一下我们的客座作者，开始吧。
介绍米兰·米拉诺维奇博士
米兰他是Microsoft的首席技术官、最有价值球员，同时也是该书的作者之一软件工程定律.他拥有超过20年的工程师和工程领导者经验，涉猎多个行业。
我认识米兰已经有一段时间了，我们偶尔会聊聊各种话题。今天，他很慷慨地分享了这本为本文改编的书籍中的一些重要见解。
交给你了，米兰！
了解具体的软件工程法律对于领导工程团队至关重要
在我20年的科技职业生涯中，尤其是在大公司、大型项目和团队工作期间，我注意到了一些具体的模式。那时，我还是个年轻工程师，还不能很好地定义它们。
后来，当我参与其他项目和新公司工作时，我又注意到了同样的模式。我很快意识到，几乎每家公司都会发生同样的错误。
这是我第一次对他们做了更多研究，立刻发现它们并不新鲜，有些甚至很老，比如20、30年甚至更久（Brooks 1975，Conway 1967）。
让我惊讶的是，当时大多数同事并不知道这些。
第二次接触它们是在写一篇关于工程团队估算和计划失败的文章时。显而易见，许多这些定律起着重要作用，对工程团队的成功至关重要。
所以，如果你想领导一支高效工程团队，我的建议是，了解并理解我今天要分享的法律非常重要。
同样重要的是，随着近年来人工智能的出现，许多法律比以前更重要，因为周期更短，团队更小，许多法律更容易被违反。
让我从第一定律开始！
1. 康威定律
这条法律可能是所有法律中最为人所知的，尤其对于刚入行的人来说，理解和理解起来可能更为困难。
它指出，设计系统（广义意义上的）组织必须生产复制这些组织沟通结构的设计。
让我举个例子。
如果我们有少数工程师分散在不同地方的小分布式团队，系统的架构很可能会是微服务。为什么？因为它反映了团队的组织和沟通结构。
另一方面，如果我们组建一个大团队，可能会有一个庞大的整体。
我记得有一次和一个大团队一起参与一个大型银行项目;系统就像一个庞大的整体，维护起来非常困难。
然后我们坐下来创建了一个新的组织结构，分成子团队，并将单体拆分为模块，使其成为模块化的单体结构。
每个子团队都拥有一个模块。在先重组团队之前，无法将架构拆分为模块。
需要注意的是，我们不应复制他人的结构，例如，Spotify 型号，因为这个模型解决了他们的协调问题，不是我们的。
2. 布鲁克斯定律
这对领导工程团队也非常重要，原因是我们经常遇到项目延迟的情况。
在这种情况下我们可以做几件事，我相信每位领导都尝试过通过增加团队成员来解决这个问题。
这正是布鲁克斯定律警告我们的，后期项目中增加更多人手只会让项目更晚。
乍一看似乎有些矛盾，但仔细想想其实并非如此。当我们为后期项目增加更多人手时，我们会做两件事：
- 我们增加了团队内的沟通和协调渠道数量。
- 我们也从现有团队成员那里抽时间完成工作，因为他们需要部分时间来工作和新员工的入职。
数学很简单，比如团队有8人时，我们有28条通信路径;如果团队有6人，我们有15条。
接下来让我分享一个我的经历例子。
在我们的一个项目中，我们有8名团队成员，而且总是迟到完成截止日期。我们尝试过各种方法，比如用缓冲区做估算、招聘新人等。但我们总是总是迟到完成承诺。之后发生的是，团队里有两个人离开了，突然间效率提升，我们也成功完成了承诺。这让我感到意外，但随着沟通路径从28条减少到15条，显然产生了影响。
我发现还有一种方法可以测量，叫做利特尔定律，其来源排队理论.
利特尔定律（L = λ * W）涉及在建工作、产出和交货时间。例如，如果你的团队每周完成5个任务，而你有20个在进行中，平均交货时间是4周。
如果在当前完成任务，吞吐量保持不变，交货时间是现在的2倍。
所以当你为后期项目添加人员时，进行中项目（WIP）会上升，吞吐量保持稳定。结果呢？是更长的交期，而不是缩短。如果你想加快完成速度，可以在添加人员前减少在建工作（WIP）。
3. 古德哈特定律
这对管理者和领导者来说可能是最相关的。而且由于人工智能的发展，这一重要性正变得更加重要。
该定律规定，一旦一项措施成为目标，它就不再是有效的措施。
许多公司犯了错误，他们衡量某些指标，却把直接输出当作目标。
其中一些例子包括：
- 写下代码行：
- 检测覆盖率，
- 工单已关闭，等等。
这种方法的主要问题在于，当我们把目标附加到产出上时，人们会找到一种方式将这些指标游戏化，变得擅长提升它们，而实际上并不会提升业务价值。
我记得在我刚开始的时候，我们的经理认为更好的工程师是产出更多代码的人，尽管我们知道事实并非如此。
有一次，我们最优秀的同事决定删减1500行代码，简化工资模块中的一个。系统变得更简单更快，但我们的经理却把这视为一个不好的例子。
现在，随着人工智能的使用，我们看到类似的趋势，比如花费AI代币（tokenmaxxing）。花更多代币的工程师被认为更有价值，甚至有些公司为此而成立。
那么，如何解决这个问题？关注结果，而非产出。定义指标，但仅作为代理指标，而非目标或奖励。
重点应放在产生有意义的结果上。这里有一个例子：
单靠“周期时间”这个指标，说明有东西在移动，但周期时间+我们本月发布的产品，以及它是否为用户带来了价值，能告诉我们更完整的故事。
在我们团队中，我们看到了一个很好的例子，当时我们决定从Scrum转向看板，完全移除故事点和估算。
以前，我们总是努力达到速度，并以此来衡量一切，但我们花了大量时间在估算、讨论等上。
当我们移除这些后，团队效率大大提升，也能为用户创造更多价值。
旁注：公交因素
公交因素规定了团队成员的最低人数，其损失将使项目陷入严重困境。
公交因子为1意味着其中一人掌握关键知识;如果他们消失，项目基本上将“注定失败”或停滞。公交因子越高（例如5），项目可能会失去5个特定人员中的任一人，而工作将停止。
它基本上是知识分布和风险的衡量标准。高总线因子是好事（知识共享），低则是坏事（专业单点故障）。
团队应通过分享知识、记录关键系统、进行代码审查和轮换职责来提升校车比例。
让我分享一个我的经验例子。曾经，我们团队中有一位工程师，他是唯一懂得计费系统的人，他正准备休个长假。
这就是Bus Factor 1，问题非常严重。我们决定让他和另一个人搭档，接管系统中一些重要部分，把Bus Factor从1号转移到2号，他不再是单点故障。
我们应该问团队每个成员一个问题：如果X明天离开我们，我们还能继续运作吗？如果不能，那就需要更多的知识交流。
4. 霍夫施塔特定律
我们在Scrum工作多年，定期进行估算会议。过了一段时间，我们发现实际上错过了设定的每个截止日期。
我们知道这一点，也尽一切努力改进，但大多数截止日期仍然被错过了。
这正是霍夫施塔特定律的定义：即使考虑到霍夫施塔特定律，它总是比你预期的花费更长时间。
当我们试图分析这些问题（当时还不知道这条法律），我们发现工作中有许多环节。API集成依赖于别人;有位工程师生病了，我们的一些设计与现实不符，等等。
另外，还有一种叫做九九十规则，这意味着项目的前90%占用90%的时间，后面10%占剩余90%，这是真的。
当工程师考虑项目时，他们主要想到的是前90%，这实际上是实施的核心，例如业务规则。
但最后10%可能也同样耗时，因为他们没有考虑集成延迟、认证、边缘情况等问题。
考虑到这些，我有几个简单的规则要遵循。首先，如果我需要估算一些工作量，我会说：
- 如果需要2分钟，立刻做
- 如果需要“几分钟”，估计大约一个小时
- 如果需要“几个小时”，就估计一天。
另一个重要点是与利益相关者沟通。我们需要对他们保持开放和诚实，这意味着我们不接受任何超过季度的路线图来给出任何估算。
对于所有的估算，我们都应该添加缓冲区来覆盖九十法则。
这里我们还需要提及帕金森法则，因为说明工作会扩展到所有可用时间。所以，如果我们能在一天内完成一件事，但估计3天，可能要花整整3天才能完成。
我所在的团队中，估算花费的时间比实施本身还长。因此，作为领导者，我们需要在项目中同时考虑这两条法律。设定明确目标的短截止日期总比设定较长的截止日期更好。
5. 阿姆达尔定律
这条定律定义了为什么人工智能生产力对每个人来说都不一样。例如，如果我们工作流中有一半是顺序的，那么加速的最大提升是2倍。
如果工作流程是90%并行的，那我们就能提升10倍的效率。
这里的主要问题是，我们常常认为软件开发生命周期（SDLC）=编码，但事实并非如此。
它还包括我们需要完成的工作中的许多其他部分，比如决定构建什么以及如何构建、与产品团队沟通、审查代码、等待各种审批等等。
编码速度现在快了许多，但其他部分保持不变。我发现那些能够提高生产力的团队，反而让“人在”环路“部分变得更小。
在组织层面也是如此。如果我们有一个象牙架构师或CTO需要批准每一个决策，增加更多资源并不会加快项目进度;你只会得到更长的排队时间。
所以，为了改进你的流程，首先要测量顺序部分，因为仅仅增加并行部分的资源并不会带来奇迹。
6. 阿玛拉定律
该定律也被称为炒作周期而且这也是我们在科技领域几十年来一直看到的情况。
我们往往高估了技术在短期内的影响，而低估了长期的效果。
我们从20世纪60年代和70年代开始研究人工智能系统时就看到了这一点;它承诺了通用智能，但效果有限。
我们也经历了几次漫长的人工智能冬季。与此同时，人工智能的研究仍在继续进行（例如，辛顿教授以及他在神经网络方面的工作，当时大家都认为这是一条死胡同），而现在，随着过去几年所有工具的加入，我们见证了行业的显著变化。
通常，最响亮的声音是那些不太使用技术的人。所以，短期承诺并不真实，而长期承诺则是我们无法想象的。
和我们对微服务的做法一样。它被宣传为适用于任何扩展问题的一刀切解决方案，但后来我们有许多复制项目，服务数量超过用户。
我记得在很多项目中只看到微服务架构，经常问自己是否真的需要。大多数情况下，其实并不必要。
对领导者来说，不仅要做正确的决定，还要在正确的时间做对。如果我们错过了时机，那就是错误的决定。
如果我们太早在顶层采纳它，可能会在一切变化时付出代价（这实际上是达克-克鲁格效应).
如果我们完全没能采用它，那么我们就来不及采用大家已经在用的东西了。
我们应该把创新当作预算来对待。我们的大部分路线都停留在经过验证的技术上（见后文Lindy效应），同时对一些被炒作的东西做小尝试。
如果成功了，我们就扩展它;如果失败，就去掉它。
旁注：林迪效应
除了炒作周期，我们还应提及林迪效应，即使用时间越长，使用时间越长。
例如，举个例子，比如1970年代的SQL或COBOL，它被用于全球一半的银行交易。另一方面，我们都见过许多库和框架如今已不再使用。
所以，我们主要选择那些经过验证且已经存在多年的软件。人工智能改变了一件事，那就是替换某些遗留软件变得更加容易。
一个庞大的COBOL代码库没有被触及，因为没人真正理解它。现在有了代理，这变得容易多了。然而，算法、系统设计、架构和数据结构等基础依然非常关键。
所以，现在我们不应该再问这项技术能存在多久，而是问它是否是解决问题的最佳方式，以及人工智能是否能更有效地取代它。
对我来说，我投资于AI难以替代的东西，比如基本面和判断力。
结合使用这些法律
我们应该知道，没有问题只涉及一条定律，但通常涉及其中几条。如果我们的交付很慢，可能有两三条定律影响着这一点。错误的做法是在还没弄清楚具体哪些定律之前就去解决它。
这是我在团队遇到问题时会做的清单：
- 康威定律
我们的团队结构是否符合系统？如果不是这样，我们可能在协调活动中浪费了太多时间。
- 布鲁克斯定律
我们最近有新增人员吗？如果有，可能会导致项目停滞。
如果我们的团队有8、9人或更多，每个团队的产出很可能会下降。
- 古德哈特定律
如果团队达成了目标，但产品没有更好，用户也不满意，那么指标就成了目标。
- 破窗理论以及科技债务
这个问题通常被忽视了。如果代码库处于没人愿意修复问题的状态，那这就是个大问题。即使有人工智能，情况也没有改善。
所以，总结一下，我们不需要知道所有法律。如果团队有问题，我们应该这样做：1）命名部队，2）按重要性排序。如果有截止日期，霍夫施塔特比阿姆达尔更重要。
还要注意，在某些情况下，存在相互矛盾的不同定律;例如，布鲁克斯定律和莱纳斯定律两者都是真的，但语境不同。
遗言
特别感谢米兰与我们的分享！欢迎关注他的分享LinkedIn也请看看他的书软件工程定律了解软件工程中所有重要的法律。
喜欢这篇文章吗？记得💙点赞按钮。
反馈还是补充？记得留💬言。
认识有人会觉得这很有帮助吗？一定要🔁分享这篇帖子。
当你准备好了，以下是我可以进一步帮助你的方法
欢迎联系
你可以在LinkedIn,X,YouTube,蓝天,Instagram或螺丝.
如果你想就某个你想阅读的主题提出请求，可以给我发邮件 info@gregorojstersek.com。
本通讯由像您这样的读者付费订阅资助。
如果你还没订阅，考虑成为付费订阅者，享受完整的体验！
你完全可以在这里找到感兴趣的内容，并在你的具体情况中尝试。告诉我结果如何！话题通常围绕工程相关，比如领导力、管理、开发可扩展产品、构建团队等。
点赞
收藏
点踩
分享