从康威定律和技术债看研发之痛

向作者提问
蚂蚁金服高级技术专家、支付核算技术部负责人、成都研发中心技术团队创建者之一,先后负责或参与资金运营平台、类营销类支付工具等数个平台建设;之前有数年电信业务研发经验,涉及BSS|OSS|针对性营销等平台。个人感兴趣的方向:高并发、稳定性模式;内建质量、技术型管理。
查看本场Chat

所谓康威定律

有一位叫康威的人,提出一个观点:设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。其实,这里的系统并不局限于软件领域的系统。康威对其定律又做了具体解读:

  • 组织沟通方式会通过系统设计表达出来。
  • 时间再多一件事情也不可能做得完美,但总有时间做完一件事情。
  • 线型系统和线型组织架构间有潜在的异质同态特性。
  • 大的系统组织总是比小系统更倾向于分解。

组织沟通方式会通过系统设计表达出来,沟通成本随着团队成员的增加而以几何级数增加。线型系统和线型组织架构间有潜在的异质同态特性,这句话说白一点就是,你需要构建什么样的系统,就搭建什么样的组织结构。下面我们会融合案例来看看这些逃不过的原则。

所谓技术债务

技术债务是由Ward Cunningham在1992年的报告中创造的一个比喻,被定义为当我们有意或无意地做了错误的或不理想的技术决策所累积的债务。它和金融债务非常相似。一个人贷款了就会产生债务。如果他定期还款,那么所创建的债务是可以接受的,不会产生进一步的问题。但是,如果他不还款,就会以利息作为惩罚,并随着不还款次数的增加而增加。如果这个人很长一段时间不能支付任何款项,那么应计利息使得他更难以偿还债务。在极端情况下,该人不得不宣布自己破产。

为了快速做业务,采取简单粗暴的方案是大家表示支持的。临时方案的毛病不在于这2个月临时了,而在于这个临时上线之后,再无人管了,俗称“有人生、没人养”。1年如果做5个临时方案,就等于欠了5笔债务。欠债并不可怕,怕的是没有偿还计划,或者借口没有时间,或者借口等业务不那么高速发展的时候。吊诡的是好的业务一定是永远都没有时间的,而差的业务确实不用发展了,因为被下线了,或者整个公司close了。So,珍惜高速发展的业务,记得去更换引擎,偿还债务,欠的,迟早要还的。有关技术债,推荐当当史大官人在周评比中名列前茅的文章:当技术宅遇上技术债,我个人觉得是这方面有调皮有调性的好文章。

以三个case来看看研发活动之痛

一次接入效率优化

以真实的X业务为例,在去年年中的时候,一个全新模式的业务接入需要多达10天,历经17个环节,8个团队。如下图所示。

enter image description here

我们确定了几个策略以期带来改变:

  • 减少协同
  • 减少环节
  • 提升效率

为什么要减少协同呢?我们前面讲过,组织沟通方式会通过系统设计表达出来,沟通成本随着团队成员的增加而以几何级数增加。关于沟通成本,人月神话给出了很简洁的答案:沟通成本 = n(n-1)/2,n=项目成员。如果按一个团队1个成员作为接口人参与跨团队协同,那么8个团队的沟通可能就达到87/2=28;而3个团队的沟通值算下来是32/2=3。

为什么要减少环节呢?环节越多,涉及的组织和团队就越多;减少组织协同必然要减少环节。有报道说某市一家工厂的一个基建项目,在申报过程中,一共盖了745个公章。流程如此繁琐,必然会影响办事效率。软件研发亦是如此。

我们再来看一下提升效率!减少环节,减少协同,自然效率就高了;有哪些减少协同的方式呢?

我们来看一些例子:如果一个团队有3个team在协作,而每个team都是前端、后端、测试职责分明,那么需要协同的环节必然就会很多。比如team1后端开发交付测试、team1后端进行验收测试、team1和team2进行功能联调等等。

enter image description here

如果尝试进行能力合并,就是全栈型团队,那么可能的模式就变成下图所示:

enter image description here

全功能团队虽然也有编写代码、单元测试、接口测试、集成测试等环节;但跨越组织的沟通已经减少了很多。

我们再尝试一种变化,因为设计系统的组织,等于组织内和组织间的沟通结果。

enter image description here

这个组织沟通图背后的架构关系可以如下示意:

enter image description here

总结:组织关系和架构息息相关;沟通成本往往由于组织协同方太多造成;应该从外部视角来组合组织关系;尝试通过抽象、构建通用组件来尝试达到能力复用;尝试对于用户或者内部客户提供统一受理界面。

重复的轮子

软件开发领域有一个流行的原则:DRY,全称是Don’t Repeat Yourself,我们一般翻译为:不要重复造轮子。关于要不要造轮子,有一篇非常精彩的文章:使用开源项目的正确姿势,都是血和泪的总结!

我们抛开其他,尝试聊聊轮子与组织的关系。首先,如果是同一个boss下面,已经有一个轮子了,兄弟团队用还是不用?如果不用,boss肯定要跟你算账!尽管你背后在骂这厮做得有多烂,你还得用。如果是不同组织的轮子呢?就不一定了,如果是一个业务研发型团队,是没有时间去造中间件轮子的了,但是可以搞些common-tools之类,这些也可以作为创新产出去交差。而且我们是绝对对同类产品表示嫉妒的,要千方百计证明对方很low,我解决了世界级难题。当然另外一个团队也是这样向老板汇报的。最终这些轮子越来越多,很难推广,也无法解决全部问题,因为问题域很广,没有银弹。

我们以下面这个案例来说一下。如下图所示:

enter image description here

  1. 提需求给基础平台
  2. 自己做能力升级
  3. 找找有没有别的轮子

方案1是最好的,专业的事情交给专业团队;方案2是不得已而为之;方案3是折中解决方案。也就是方案3优于方案2,但我们习惯于做方案2,造一个轮子,因此形成了鄙视链。

enter image description here

你需要构建什么样的系统,就搭建什么样的组织结构;这句话有一种逆向作用力。为了满足xx领域的监控能力,我们在基础平台的基础上引入了xx实时计算,xx指标管理,xx模型;那么我们成立了一个团队A来做这事;做着做着,我们就形成了一种认知,团队A就是解决这个问题了,而且我们很强大;我们致力于解决更多的类似问题;后来我们发现团队B、团队C也是通过自然生长解决类似问题的。那么问题来了,从公司角度看,A、B、C做的事情应该合并;从各具体组织看,会不断证明别的团队做的会满足不了我的需求,我是应该留下来的团队。

总结:你要什么样的系统,要搭建什么样的组织结构;一旦搭建了这样的组织结构,可能带来逆向作用力,从而导致重复建设、效率低下、部门墙,且最终可能都没有对一个问题域打穿,给合作伙伴或者客户提供了非一站式的解决方案,陷入各自为政。

在提出解法前,我抛些原则:协同、赋能、动态组织。首先明确一个动态组织的概念,组织是为业务或者某些目标服务的,组织应该具备灵活性、动态性。一个长期稳定的组织,可能没有活力,或者没有寻找新的挑战空间。其次,协同原则,意思就是孤胆英雄不能成事已然是IT界的共识了,孤胆团队同样难以成事。经常有人讲站在巨人的肩膀上,登高望远。所以一个组织要明确自己的目标,而且明确多少事是协同哪些干系方去拿到;一定有很多不用自己做的事情,笨不是理由,没看清楚会让团队泥足深陷。赋能,是基于协同这个共识来的,中间件团队要赋能业务研发团队自不必说,业务研发团队之间也可以相互赋能。那些共性问题,没有必要重复造轮子。这里引入了一个非常关键的因素,就是考核!团队A的主管如何看待A这个团队,他可能就把某工具做成当目标,其实团队A的主管的主管的目标是达成5秒的异常检测能力,他并不关注监控的一部分能力是谁提供的。OK,基于以上的讨论,可以给出一些解法,但不限于此。

enter image description here

如上图所示,中间件团队可以把监控平台做成内部开源模式,是完全开放,还是提供基础能力层,开放层这样具体的细节且不讨论,其他业务团队都可以贡献代码,业务团队的优势是离业务场景很近,有具体的场景驱动;这样还可以解决A、B、C团队的优先级问题,全部List给中间件团队,不知道猴年马月了。

enter image description here

如上图所示,业务团队A和中间件团队可以持续共建某些基础能力,可能业务团队A是需要赋能的大户,而且所需要的成本很高,故长期共建。基于我们说的协同、赋能、动态组织原则,业务团队A在完成使命后可以在对应的组织内重新确定新的目标。同时,赋能原则,共建的成果,可以为业务团队B、C服务。对于业务团队B而言,可能投入1-2个人,搞上2个月自己的需求就满足了,那么他们就撤出。

平台发展vs业务发展

最近陈康贤写了一篇谈演进式架构的文章,我记得大致是对于成熟的业务领域可以采用平台式架构。我非常认同。之前也有一些大咖提出架构是演进出来的,而不是设计出来的。总体来讲,演进是必须的,前期设计做多少合适是值得探讨的。我个人的一个衡量标准是对于方案A、B进行评估,如果方案B可以更通用,而付出的成本在可接受范围内,优先选择方案B。不做BDUF是大家的共识,而艺术在对于“度”的把握。

许多人都会面临一个问题就是平台发展vs业务发展。按理说平台应该随着业务一起发展,但是如果每个需求都是堆砌式地上线,那么就是构建了一个一个的烟囱。我们期望的是在一段时间后,相似度高的、同类型需求可以拥有快得多的上线能力。

关于平台发展和支持业务,以及不同场景不同阶段的业务架构原则我有几个观点。

  1. 架构方案和业务形态息息相关。
  2. 架构是演进的、发展的;架构没有最好,只有适合。
  3. 技术债要做清偿计划。
  4. 不要在下雨天去补屋顶。

架构方案和业务形态息息相关

我之前亲身经历了一条产品线,完全是试错型的产品线。我们在设计之初,对于模型共同层做了抽象,后来五花八门的产品长在上面,公共的内容越来越少,反而导致了系统调用链路增加;代码编写的复杂度增加。1年后,这条产品线全线关闭!从这个case来看,最适合的就是满足业务快速试错,可能烟囱式架构是最合适的;甚至产品之间有一些代码重复,但各team各司其职,是最快反应,是最小的研发响应单元。对应到康威定律的组织和架构关系,也是依赖最少的组织,沟通成本最低。

enter image description here

如上图所示,烟囱型架构在不确定产品线的试错有优势,对应的组织构架也应以简单、快速响应为特征。

架构是演进的、发展的;架构没有最好,只有适合。

我再举一个例子来说架构演进这事。随着业务发展,上了规模,类似的诉求会凸显,因此沉淀为越来越多的平台。如下图示意:

enter image description here

除了需求相似性、平台要求相似性导致的架构发展以外,还可能有,我们对领域本质认知的升级。比如在支付宝渊源的发展过程中,我们先后使用过红包、实时优惠、商户优惠券等产品。这是烟囱式架构发展下的产物。下图示意为一个红包产品的展示。

enter image description here

行业也有其他类似券的东东,如下图所示:

enter image description here

如果简单地看,券和红包是两类东西。但是,我们在产品上形成了如下定义,就可以视作一类东西,则可以对它们进行统一的抽象和管理。

券定义:

  • 是一种票据,作为券发行方和拥有方之间的凭证,具有一定的价值和法律效应。

相关干系方:

  • 券的发放方(提供权益)
  • 券的拥有方(享受权益)
  • 劵的发放工具(是券发行方向拥有方发放券凭证的工具)

券形式:

  • 以介质分类:纸质券、电子券
  • 以使用方式分类:入场券、礼品券、提货券、代金券、红包、打折卡、满减卡等

可以把券作为基础产品,在业务形态上可以包装为打折卡,满减卡等用户感知的产品或者是营销工具

技术债要做清偿计划

前一段,参与了一个关于技术债务的讨论。技术债务确实一个惹人讨厌的东西,业务逼着你跑,你不跑不行,可能跑着就累死了;你停下来歇会儿,搞搞技术改造,又可能被业务压力压死了,反正都是死!关于技术债务我提了4个观点:

  • 由于技术人员水平不行,意识不够,所以越写越烂。
  • developer都有一颗积极向上的红心,但是他们不知道如何做才是好的。
  • 上行下效,没有靠谱的Leader,架构师,大家都是懒惰的,不想去还债。
  • 有华为的朋友表示,永远的业务压力,我没时间;其实所有公司都一样滴,赶着交付,哪有时间去清偿。

关于债务清偿,也总结了务实接地气的几个思路:

  • 构建质量保障体系,让我有勇气动手动刀。比如接口测试、单元测试,通过CI持续反馈,这样我有50%的勇气来做重构。
  • 对于遗留系统,没出问题的地方,你不要动它。出问题的,修复并补充测试代码。如果更进一步,对于高危的功能和模块可以做定向增强。
  • 招募优秀的工程师,好的作风和习惯可以影响整个团队。
  • 抓住痛得不行的时候大作文章。平常说持续集成,可能团队成员没有感受到好处,出bug了,再回顾看看;copy-paste代码总有一天不能满足更复杂的需求,这样从心理认同上,大家觉得必须重写了。抓住这样的机会,构建品质高一些的代码和质量防线。改变一个人是非常难的,抓住这样的机会很重要!

不要在下雨天去补屋顶

马老师有一金句:不要在下雨天去补屋顶。做软件研发,做架构也是一样的。当一些重点战役型项目让你喘不过气的时候,你去做理想架构无异于找死。这里一个观点就是技术、架构始终为业务,为商业服务。无论从走出舒适区,还是从架构发展来讲,一定要找准时机来做架构升级。这个升级是基于对业务本质的不断认知,否则就是南辕北辙。我们团队曾在一次重要架构改造的过程中,架构方案确定比新业务来临早了3个月,这样刚好通过一个小业务的切换,快速上线。然后在战役打响的第二个月新架构派上用场,3个月的时差足以改变许多东西。

因此,我们要记住,不要在下雨天去补屋顶!补屋顶包括偿还技术债务,包括架构的升级改造!

总结一下:康威定律及其推论告诉我们,要什么事情,设定什么样的组织结构;同时做不同的事情,要允许动态弹性组织结构,不要被组织束缚;再进一步,跨越组织,立足协同、赋能可以做出更大的组织成效;技术债务这事不要等到下雨天才偿还,做业务和平台架构发展平衡的艺术取决于在一定时间和环境下的目标,技术人员不要永远处于被驱动的状态!研发之痛,是一个复杂的调试性问题,没有银弹!

关于组织与架构,插播一个广告,由中生代&TechPlus举办的年度大会(上海)已开启报名通道,CTO一席谈、架构、FinTech诸多大咖,齐聚一堂,共襄盛举!扫码可以了解详情!

enter image description here


本文首发于GitChat,未经授权不得转载,转载需与GitChat联系。

Michael
就像下棋一样,走一步,看三步。 什么是远见,这就是。
雨品
技术债,迟早要还。
郑泽安
关于技术债务,我认为无法避免,但可以减少其带来的负面影响,让团队持续良性的发展。在初期,做好基础技术架构和研发规范要求,在项目进行过程中及时发现问题并处理,对团队成员做一些技术提升帮助或者改正其不良习惯。总体来说我觉得项目的行进应该是小步快跑,对于问题不拖沓及时处理,消除债务,减少债务累积带来的重大问题。
右军
明晚付费用户群答疑,关键范围: 组织架构,技术架构,技术债务,协同涉及一点考核范围。以上主题欢迎留言或者联系明天下午的小助手提问。非以上话题,可以加好友到日常群解答。
军哥
请教老师一个问题,作为基础平台部门,如何更好平衡平台升级与业务线产品交付的压力?是不是组建一个平台加业务的综合团队在一定时期比较有用
乐夕
产品模糊,架构懈怠,业务追赶,研发低能,体制僵硬,一大堆垃圾产品倾囊而出。
右军: 这是一个复杂命题,任何一个因子最好一些,结果也有少许改变
马金凯
比较赞同引入考核方式,把重心放在考核上,背负考核时成果质量就会提升,当不同组织的关注点一致时,事情就好做了
风行天下
TeamLeader的远见性,基本上能够决定了整个团队的技术远见性,至少在实际工作中会有这样的情况,一线码农如何引导呢?
曹磊
如果产品团队与技术团队不在同一个team,如何向产品团队的人解释偿还技术债的重要性以及相关的工作量?说服他们在产品迭代的周期安排中考虑这一部分的时间要求?
三旬老汉
学到很多东西,谢谢
江伟
请教老师两个小问题。 请问组织架构上是否有必要单独成立一个技术能力较强的小团队,把控架构方向引导整合技术团队? 怎么说服不是很懂技术的领导给予时间支持重构这件事?
郑泽安
消除技术债务的比较好的手段有哪些,对于债台高筑的项目是否直接废弃重新开发了。
开源社
对缩减团队的案例很感兴趣,从8个团队减到3个团队,他们怎么肯同意的呢?或者再推广一下,如果让一个团队承认他们是冗余的,并不重要呢?
王超Charles
老师好,如果已经积压了技术债务,还有很多的业务需求的压力,而且已经工作负荷很大了,是否有办法向上管理,说服老板把业务需求延期一下,去清理技术债务呢?
ZzZzzz...
创业公司初期各种原因会有很多技术债务,中期又会面临快速发展,人员不足,这期间如何更好的组织管理偿还债务?
李志刚
请问能详细介绍一个 系统或业务做的比较好的组织的沟通方式和组织结构吗?比如支付宝 在不避免谈“责任”的前提下,由于 减少沟通环节 而造成的后果,有没有好的处理办法 增加组织凝聚力 保持上下同欲有没有实践经验,技术团队建设又有什么特点?
李晓时
所谓“强将手下无弱兵”,可往往是“强将手下尽弱兵”。怎么将非一流个体打造成一流团队?
李晓时
在保证质量和进度的前提下,怎样减少团队的加班时间?
武可
技术债和真实债务的最大区别在于,技术债确实很有可能不用偿还。 而且这是个自实现的预言:不偿还 → 短期快,长期慢 → 无法适应需求变化被淘汰 → 不偿还是经济的 → 投入到又快又糙的新产品中… 另外,不要在雨天修屋顶的原则,和抓住项目痛点推进结构改造,其实是有些相悖的。一般来说觉得痛了多少都是在下雨的时候,真等到晴天了,时机也过去了。 说到底,还是要靠决策者对度的把握
Michael
老师好,提个问题,减少团队数量来提高沟通成本,但这个是和康威定律是矛盾的。康威定律不是说大系统倾向于拆分。那就是说总有一种组织形态是最佳临界点,是最适合当前架构的?或者说是最适合设计当前系统?再或者说是提供满足客户价值的系统。客户的需求是变化无常的,那组织的重构也必然是一种常态。不知道这么理解对不对?谢谢
dongquan
学习了,谢谢老师分享
光辉岁月
写的非常好,要反复研读,并运用到实际业务中!
zhenxing
图片全部都看不到了,作者能修正一下嘛,多谢
微信扫描登录