当开会人数是3时,沟通次数最少是3*(3-1)/2=3。当开会人数是4时,沟通次数最少是4*(4-1)/2=6。当开会人数是5时,沟通次数最少是5*(5-1)/2=15。...当开会人数是 n 时,沟通次数最少是 n*(n-1)/2,这是可以得到一个炸裂的结论:沟通的复杂度是 O(n2)!也就是沟通的复杂度会随着人数的增加,呈现指数增长趋势。这个结论是悲伤的,悲伤的点在于:
当你试图通过人员增多解决问题时,你可能会把问题更加复杂化!
项目的复杂度比项目的体量增长要快!
如上图所示:直线代表着通过增加人数而带来的劳动力,曲线代表这增加人数带来的复杂度,在 [0,临界点]区间内,问题整体可控,在[临界点,+∞]区间内,复杂度变高,债务出现。(问题:如何找到临界点呢?) 以上的情况还是在信息可靠传输的情况下进行,如果加上损耗因子,我们会得到沟通带来的损耗也是指数级的:如果损耗因子为 k(0<k<1),损耗量:k*n*(n-1)/2,为了弥补这种损耗,往往还要加入更多的沟通才可以解决。这个案例很好地解释了,小团队相比大团队的优势。 如果把人换成系统,这不就是微服务分布式系统的通信问题,在中台设计思路上,偏向于使用领域建模的方式把微服务拆分成边界明确的小模块,提高复用能力,但是这也带来了服务数量爆炸、运维困难的问题。(这真是一种 trade off 啊) 总结:沟通有损和组织成员沟通带来的复杂度,是引起业务负债的另一大原因。
对于运维,要去了解一个系统的好坏,最直接的就是看整个系统的关键监控曲线,比如整体服务的 SLA、关键接口的成功率、超时率等等,身体也是如此,我们去判断自己的身体状态不应该是靠感觉,而是靠数据。对比一个周期与上个周期的数据,才可以说,ok 我身体变好了、我身体不如以前了。 之前有一则新闻:Kernel 和 OS Fund 的 CEO 布莱恩现在每年至少花费200万美元,聘请30多名医生和健康专家监测他身体的每一个机能。对于普通人,我们不可能做到这种地步,但是还是有很多可以操作的方法,比如以下三点即使每个人都可以轻松做到的。