老谭推荐从康威定律和技术债看研发之痛
Posted 菜根老谭
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了老谭推荐从康威定律和技术债看研发之痛相关的知识，希望对你有一定的参考价值。
老谭导读：
康威定律在我的文章中出现的频率是很高的，不论是在思维修炼专辑还是在产品研发相关专辑（✨文末有相关文章推荐），我认为所有的管理者，特别是最高管理者都应该深刻理解康威定律在研发管理，甚至企业管理中的重要性，它表达了人、事、物的本质关联关系。
本文之所以推荐给大家，的确是文中内容也是自己深有感触。两年前接任研发负责人以来，除了前人的成果，但更多的是遗留的债务。为什么一直想统一技术体系，却一直统一不了？为什么一直强调不重复造轮子，为什么还不得不造轮子？为什么偌大的团队，却没有厚实的平台积累？这两年做的累，比期望的要慢，因为治理难于新建，也因为一开始忽视了组织体系的重要性。季度会刚过，现在的体系已经开始靠近我期望的样子，技术体系已经基本统一，平台也在夹缝中诞生了，也开始统一了几块的业务线，人员虽然一直都很紧张，但结构已经向我想要的方向发展。
让我按照自己的想法去构建符合我管理需求的研发组织是一件很幸福的事，虽然还有很多事无法自己掌控，但已经开始有了幸福的感觉了。接下来让我们消除技术债的影响，走向一条快速发展的技术快车道上吧。
本文节选自头条号：大数据架构
康威定律由 Conway 在 1967 提出，其主要观点是：设计系统的架构受制于产生这些设计的组织的沟通结构。
其实，这里的系统并不局限于软件领域的系统。康威对其定律又做了如下具体解读。
◎ 组织沟通方式会通过系统设计表达出来。
◎ 时间再多，对一件事也不可能做得完美，但总有时间做完。
◎ 在线型系统和线型组织架构间有潜在的异质同态特性。◎ 大系统的组织总是比小系统更倾向于分解。
也就是说，需要构建什么样的系统，就搭建什么样的组织结构。
接入效率优化
以真实的某个业务为例，在 2018 年年中的时候，我们负责的一个产品需要接入一个全新的业务模式，经过初步评估，整个过程多达10天，历经17个环节，涉及8个团队，如图1所示，我们期望在此过程中提升整体效率。
图1
面对以上情况，我们确定了几个策略以期带来改变：减少协同、减少环节、提升效率。
为什么要减少协同呢？前面讲过，组织沟通方式会通过系统设计表达出来，沟通成本随着团队成员的增加以几何级数增加。关于沟通成本，在《人月神话》中给出了很简洁的答案：沟通成本=n（n-1）/2，n=项目成员。如果按一个团队1个成员作为接口人参与跨团队协同，那么8个团队的沟通就可能达到87/2=28；而3个团队的沟通值算下来是32/2=3。
为什么要减少环节呢？环节越多，涉及的组织和团队就越多，减少组织协同必然要减少环节。流程越烦琐，就越会影响办事效率，软件研发亦是如此。减少了环节，减少了协同，效率自然就高了。那么有哪些减少协同的方式呢？
我们来看一些例子。如图2所示，如果一个团队有3个团队在协作，而每个团队都是前端、后端、测试职责分明，那么需要协同的环节必然很多。团队 1、团队 2 和团队 3都会分别进行团队内部的前后端开发联调、交付测试及验收测试等，且相互之间需要进行联调及联测。
图2
如果对这3个团队进行功能合并，就会形成全栈型团队，可能变成、如图3所示。
图3
全栈型团队虽然也有编写代码、单元测试、接口测试、集成测试等环节，但跨越组织的沟通已经减少了很多。
如图4所示，我们再尝试一种变化，因为设计系统的组织等于组织内和组织间的沟通结果。
图4
这个组织沟通图背后的架构关系可以如图5所示。
图5
总之，组织关系和架构息息相关，太多的沟通成本往往由于组织协同方太多造成，应该从外部视角来组合组织关系，尝试通过抽象、构建通用组件来达到能力复用，尝试对用户或者内部客户提供统一的受理界面。
02
重复的轮子
在 软 件 开 发 领 域 有 一 个 流 行 的 原 则 ：DRY （ Don’t RepeatYourself），我们一般将其翻译为：不要重复造轮子。
这里抛开其他，聊聊轮子（或称产品）与组织的关系。首先，如果在同一个领导下已经有一个轮子了，那么兄弟团队用还是不用这个轮子？如果不用，则可能无法过领导那一关，尽管你不喜欢用这个轮子，却还是得用。如果是不同组织的轮子呢？就不一定了。如果是一个业务研发型团队，则可能没有时间去造中间件轮子，但是可以搞些 common-tools之类的轮子，这些也可以作为创新产出去交差。而且我们可能会对同类轮子采取怀疑态度，会想办法证明自己的轮子更好。当然，另一个团队也是这样向领导汇报的。最终，这样的轮子越来越多且很难推广，也无法解决全部的问题，因为问题域很广，没有银弹。
这里有个案例，有三个业务团队都需要一套监控系统，已知目前有一些相对成熟的产品，但是都无法满足自己的个性化需求，如图6.10所示。
图6
在这个案例中，关于各个团队如何实现自己的定制化监控需求，有如下3个方案。
◎ 方案1：向基础平台提需求。
◎ 方案2：自己做能力升级。
◎ 方案3：找找别的轮子。
方案1是最好的，专业的事情交给专业团队来做；方案2是不得已而为之的；方案3是折中的。也就是说，方案 3 优于方案 2，但我们习惯于做方案 2，造一个轮子，因此形成鄙视链，如图7所示。
图7
“你需要搭建什么样的系统，就需要搭建什么样的组织结构”这句话有一种逆向作用力。为了满足X领域的监控能力，我们在基础平台的基础上引入了X实时计算、X指标管理及 X模型，还成立了一个业务团队 A来做这件事，进而形成一种认知：业务团队 A就是来解决这个问题的，而且很强大，业务团队A致力于解决更多的类似问题。后来发现业务团队B、业务团队C也是通过自然生长解决类似问题的。那么问题来了，从公司的角度来看，业务团队 A、B、C 做的事情应该合并；
从各团队的角度来看，他们会不断证明别的团队做的产品并无法满足自己的需求，自己才是应该留下来的团队。
总之，你要搭建什么样的系统，需要搭建什么样的组织结构，一旦搭建了这样的组织结构，就可能带来逆向作用力，从而导致重复建设、效率低下、部门墙，且最终可能没有打穿任意一个问题域，还为合作伙伴或者客户提供了非一站式的解决方案，陷入各自为政的矛盾中。
在提出解决办法前，这里先抛出一些原则：协同、赋能、动态组织。
首先，明确一个动态组织的概念。组织是为业务或者某些目标服务的，应该具备灵活性、动态性。一个长期稳定的组织可能没有活力，或者没有新的挑战空间。
其次，协同原则。一个组织要明确自己的目标，并明确有多少事是通过和协作方协同合作共同完成的，否则会让团队泥足深陷。赋能，是基于协同这个共识而来的，中间件团队要赋能业务研发团队自不必说，业务研发团队之间也可以相互赋能，对于共性问题，没有必要重复造轮子。这里引入了一个非常关键的因素，就是考核！业务团队A的主管在考核业务团队A的绩效目标时，将自己的团队做出哪些工具作为目标是不正确的，业务团队A的主管的主管的目标可能是达成5秒的异常检测能力，并不关注监控的一部分能力是谁提供的。所以，基于以上内容，可以给出一些解法，但不限于此。
如图8所示，中间件团队可以将监控平台做成内部开源模式，暂不讨论其是完全开放的，还是提供基础能力层的，其他业务团队都可以贡献代码，业务团队的优势是离业务场景很近，有具体的场景驱动。这样还可以解决业务团队 A、B、C 的优先级问题，如果全部把需求提交给中间件团队，则完成的时间就成了未知数。
图8
如图9 所示，业务团队 A 和中间件团队可以持续共建某些基础能力，可能业务团队A是需要赋能的大户，而且需要的成本很高，所以长期共建。基于以上协同、赋能、动态组织原则，业务团队A在完成使命后可以在对应的组织内重新确定目标，同时，为业务团队 B、C服务。对于业务团队 B而言，可能只需要投入 1～2个人，做上两个月就可以满足自己的需求了。
图9
平台发展vs业务发展
软件行业有很多大咖提出：架构是演进出来的，而不是设计出来的。笔者比较赞同这种说法。总体来讲，演进是必需的，前期设计做多少合适是值得探讨的。一个衡量标准是对于方案A、B进行评估，如果方案B可以更通用，付出的成本也在可接受的范围内，则优先选择方案B。不做BDUF（Big Design Up Front，臃肿的预先设计）是大家的共识，而艺术在于对“度”的把握。
许多人都会面临一个问题：是先发展平台，还是先发展业务？按理来说，平台应该随着业务一起发展，但是如果每个需求都堆砌式上线，就构建了一个个的烟囱。我们期望在一段时间后，相似度高的同类型需求可以有快得多的上线能力。
关于平台发展和业务发展，以及不同场景、不同阶段的业务架构原则，这里给出几个观点。
◎ 架构方案和业务形态息息相关。
◎ 架构是演进的、发展的，没有最好，只有适合。
◎ 技术债要做清偿计划。
◎ 不要在下雨天补屋顶。
笔者之前经历了一条产品线，完全是试错型的产品线。我们在设计之初对模型的共同层做了抽象，后来五花八门的产品长在上面，公共的内容越来越少，反而导致了系统调用链路增加，以及代码编写的复杂度增加。1年后，这条产品线全线关闭。从这个案例来看，最适合的就是满足业务快速试错，可能烟囱式架构是最合适的，甚至产品之间有一些代码重复，但各团队各司其职，是最快反应的最小研发响应单元。对应到康威定律的组织和架构关系，这也是依赖最少的组织，沟通成本最低。
如图10所示，烟囱型架构在不确定产品线的试错方面有优势，对应的组织构架也应以简单、快速响应为特征。
图10
这里再举一个例子来说说架构演进这事。如图11所示，随着业务的发展，类似的诉求会凸显，因此沉淀为越来越多的平台。
图11
其中，除了有需求的相似性、平台要求的相似性导致的架构发展，还可能有对领域本质认知的升级。比如在支付宝发展过程中先后使用过红包、实时优惠、商户优惠券等产品，这些都是烟囱式架构发展下的产物。如图12所示为一个红包产品的展示。
图12
行业也有其他类似“券”的产物，例如京东红包、苏宁红包、滴滴打车券、滴滴打车红包、微信红包、电信充值红包、大众点评红包等。
简单来看，券和红包是两类东西。但是，我们在产品上形成了如下定义：如果可以视作一类东西，则可以对它们进行统一的抽象和管理。
所以，当前阿里所推崇的中台架构，其实是一个企业发展到一定阶段的架构诉求，开始的分散是激发创新活力，赋予人更多的潜能；但长期的分散和自治，必然带来巨大的治理成本，和在大战役中的组织执行力的缺失。
今日新冠疫情保卫战，中国的表现和国外自由分散的民主国家相比，一目了然。
●
●
●
●
以上是关于老谭推荐从康威定律和技术债看研发之痛的主要内容，如果未能解决你的问题，请参考以下文章