所谓康威定律。一个叫康威的人提出了一个观点：设计一个组织，设计一个系统，就等同于组织内部和组织结构之间的沟通。其实这里的系统并不仅限于软件领域的系统。康威对他的定律给出了具体的解释：一个组织的沟通方式将通过系统设计来表达。不可能用更多的时间做一件事，但总有时间完成一件事。线性系统与线性组织结构之间存在着潜在的异质同态特征。大系统组织总是比小系统更容易分解。组织沟通方式会通过系统设计来表达，沟通成本会随着团队成员的增加呈指数增长。线性系统与线性组织结构之间存在着潜在的异质同态特征。说白了，你需要建立什么样的制度，你就可以建立什么样的组织架构。下面我们就结合案例来看看这些逃不掉的原则。所谓技术债务技术债务是WardCunningham在他1992年的报告中创造的一个比喻，定义为当我们有意或无意地做出错误或次优的技术决策时所累积的债务。这与金融债务非常相似。当一个人借贷时，他就产生了债务。如果他定期还款，那么所产生的债务是可以接受的，不会造成进一步的问题。但是，如果他不还款，他将被处以利息，利息随着不还款次数的增加而增加。如果此人无法在较长时间内支付任何款项，则应计利息会使他更难偿还债务。在极端情况下，此人必须宣布自己破产。为了快速做生意，大家都支持采用简单粗暴的方案。临时方案的问题不在于临时做了两个月，而是这次临时上线后就没人管了，俗称“有人养，有人养”。如果你在一年内做了5个临时计划，那就意味着你欠了5笔债。负债并不可怕，可怕的是没有还款计划，或者借口说没有时间，或者借口什么时候业务发展没有那么快。矛盾的是，好的业务肯定永远没有时间，而不好的业务因为下线或者整个公司都关门了也不需要发展。所以，珍惜快速成长的生意，记得换引擎，还债，欠的，早晚是要还的。关于技术债，推荐当当网在每周评价中排名第一的文章：当一个技术极客遇到技术债，我个人认为是一篇在这方面有调皮和调性的好文章。举三个案例看看研发活动的痛点。一次性访问效率优化。以真实的X业务为例。去年年中，接入一个新的商业模式，用时多达10天。团队。如下所示。我们确定了几种策略以带来变化：减少协作，减少环节以提高效率为什么要减少协作？前面我们说过，组织的沟通方式会通过系统设计来表达，沟通成本会随着团队成员数量的增加而呈几何级数增长。关于沟通成本，人月神话给出了一个非常简洁的答案：沟通成本=n(n-1)/2，n=项目成员。如果一个团队的一名成员作为接口人参与跨团队协作，那么8个团队的沟通价值可能达到87/2=28；3个团队的沟通价值为32/2=3。为什么要减少链接？环节越多，涉及的组织和团队就越多；减少组织协作必然会减少联系。据悉，某市某厂基建项目在申报过程中共加盖公章745枚。如此繁琐的流程，势必会影响工作效率。软件开发也是如此。让我们来看看提高效率吧！减少环节，减少协作，自然效率就高；减少协作的方法有哪些？举几个例子：如果一个团队有3个团队协作，每个团队都是前端，后端，测试职责明确，那么必然会有很多需要协作的环节。比如team1后端开发交付测试，team1后端验收测试，team1和team2联合功能调试等。如果尝试合并能力，是一个全栈团队，那么可能的模型就变成了下图所示：虽然全功能团队也有编写代码、单元测试、接口测试、集成测试等环节；但组织间的交流减少了。很多。让我们尝试另一种变体，因为设计系统的组织等于组织内部和组织之间沟通的结果。这张组织沟通图背后的架构关系可以表示如下：总结：组织关系与架构密切相关；沟通成本往往由过多的组织合作者造成；应从外部角度结合组织关系；尝试通过抽象和构建通用组件来实现能力的复用；尽量为用户或内部客户提供统一的验收接口。在软件开发领域有一个流行的原则：DRY，全称是Don'tRepeatYourself，我们一般翻译为：不要重复造轮子。关于是否造轮子有一篇非常精彩的文章：使用开源项目的正确姿势，是血泪总结！我们抛开其他的不谈，试着谈谈轮子和组织的关系。首先，如果是同一个boss下，已经有轮子了，兄弟组用还是不用？不然，老板肯定找你算账！就算你在背后骂这家伙有多烂，你也得用。不同组织的轮子呢？不必要。如果是业务研发团队，没有时间去造中间件的轮子，但是可以做一些common-tools之类的，这些也可以作为交叉施肥的创新输出。.我们绝对嫉妒类似的产品。我们必须千方百计证明对方低。我已经解决了***问题。当然，另外一个团队也是用同样的方式向老板汇报的。最后这些轮子越来越多，很难推广，也解决不了所有问题，因为问题域很广，没有灵丹妙药。让我们以下面的案例为例。如下图：向基础平台提供升级自身能力的需求，看看有没有其他的轮子。方案一最好，专业的事情交给专业的团队；选项2是最后的选择；选项3是一个折衷的解决方案。也就是plan3比plan2好，但是我们习惯做plan2，造轮子，从而形成鄙视链。你需要建立什么样的制度，就需要建立什么样的组织架构；这句话有反作用力。为了满足xx领域的监控能力，我们在基础平台的基础上引入了xx实时计算、xx指标管理、xx模型；然后我们成立一个团队A来做这件事；这样做，我们形成了团队这个认知，A团队就是解决这个问题的，我们很强；我们致力于解决更多类似的问题；后来我们发现B队和C队也通过自然成长解决了类似的问题。那么问题来了。从公司的角度来看，A、B、C的工作应该合并；从每个具体组织的角度来看，会不断证明其他团队所做的不能满足我的需求，我应该留下来。总结：你想要什么样的系统，你想要建立什么样的组织架构？这样的组织架构一旦搭建起来，可能会带来反作用力，造成重复建设、效率低下、部门壁垒。最终可能没有合适的突破问题域，为合作伙伴或客户提供非一站式解决方案，陷入碎片化。在提出解决方案之前，我抛出一些原则：协作、授权和动态组织。首先，明确动态组织的概念。组织服务于业务或某些目标。组织应该是灵活和动态的。一个长期稳定的组织可能没有生命力，也可能找不到新的挑战空间。其次，协同原则意味着孤军奋战是IT行业的共识，孤军奋战也难成大事。人们常说，站在巨人的肩膀上，才能登高望远。因此，一个组织必须明确自己的目标，明确需要与哪些利益相关者合作获得多少东西；肯定有很多事情不需要自己去做。赋能是基于协作的共识。不用说，中间件团队可以赋能业务研发团队，业务研发团队也可以互相赋能。对于那些常见的问题，没有必要重新发明轮子。这里介绍一个很关键的因素，就是考核！A队的主管如何看待A队？他可能会以制作某种工具为目标。实际上，A组主管的目标是实现5秒异常检测能力，他并不关注谁提供了部分监控能力。OK，基于上面的讨论，可以给出一些解决方案，但不限于此。如上图所示，中间件团队可以将监控平台做成内部开源模型，无论是完全开放还是提供基础能力层。openlayer的具体细节不讨论。其他业务团队可以贡献代码。业务团队的优势非常贴近业务场景，以特定场景为驱动；这样也可以解决A、B、C团队的优先级问题，所有列表都交给中间件团队。如上图所示，业务团队A和中间件团队可以继续共同构建某些基础能力。可能A业务团队是大玩家，需要赋能，需要的成本高，所以会长期共建。基于协同、授权和动态组织的原则，业务团队A可以在完成任务后在相应的组织中重新定义新的目标。同时，赋能原则和共建成果可以服务于业务团队B和C。对于业务团队B，可以投入1-2人，工作2个月后满足他们的需求，以及然后他们会撤退。平台开发vs.业务开发最近，陈康贤写了一篇演化架构的文章。我记得成熟的业务领域可以采用平台架构。我非常同意。一些知名人士还提出，架构是演进的，而不是设计的。一般来说，进化是必要的，早期的设计是否合适值得讨论。我个人的一个标准是对选项A和B进行评估，如果选项B可以更通用，并且成本在可以接受的范围内，则首选选项B。不做BDUF是大家的共识，艺术在于对“度”的把握。许多人面临的一个问题是平台开发与业务开发。按理说平台应该是随着业务一起发展的，但是如果每一个需求都堆起来在线上，那就是一个一个搭建的烟囱。我们期待的是，经过一段时间后，相似度高、类型相同的需求，可以有更快的上线能力。对于平台开发和业务支撑，以及不同场景下不同阶段的业务架构原则，我有几种看法。架构解决方案与业务形态密切相关。架构在演化和发展；没有完美的架构，只有合适的。技术债务需要还清。不要在下雨天修补屋顶。建筑方案与业务形态密切相关。之前亲身体验过一条产品线，完全是试错产品线。在设计之初，我们对模型的公共层进行了抽象。后来各种产品在上面生长，公开的内容越来越少，导致系统调用环节越来越多，代码编写也越来越复杂。一年后，这条产品线彻底关闭！从这个案例来看，最适合的是满足业务快速试错的需求，或许烟囱架构最适合；产品之间甚至存在一些代码重复，但每个团队、每个部门的职责是响应速度最快，研发响应单元最小。康威定律对应的组织结构关系也是依赖最少的组织，沟通成本最低。如上图所示，烟囱式结构在不确定产品线的试错中具有优势，相应的组织结构也应该具有简单、快速反应的特点。架构在演化和发展；架构没有保证，只有我再举个例子来谈谈架构的演进。随着业务的发展和规模的扩大，类似的需求会越来越突出，所以平台会越来越多。下图表明，除了需求和平台需求的相似性导致的架构发展，还有可能是我们对领域本质的理解的升级。比如在支付宝圆圆的开发过程中，我们用到了红包、实时优惠、商户优惠券等产品。这是烟囱式建筑发展的产物。下图是一个红包产品的展示。业内还有其他类似优惠券的东西，如下图：简单的看，优惠券和红包是两类东西。但是，我们在产品上形成了如下定义，可以把它看成是事物的一个范畴，可以对它们进行抽象和统一管理。债券的定义：是一种票据，具有一定的价值和法律效力，作为债券发行人与债权人之间的凭证。相关方：优惠券发行方（提供权益）优惠券所有者（享受权益）优惠券发放工具（向优惠券所有者发放优惠券的工具）优惠券形式：按媒介分类：纸质优惠券、电子优惠券按用途分类：入场券、礼券、送货券、抵用券、红包、优惠卡、满减卡等。被包装成打折卡、满打折卡等产品或营销工具。前一段技术债做清算计划，参加了一个关于技术债的讨论。技术债确实是一件很烦人的事情。商业迫使你奔跑。如果你不跑步，你可能会筋疲力尽。如果稍作停顿，搞技术改造，可能会被业务压力压死。反正他们都死定了！关于技术债，我提出了4个观点：因为技术人员的水平不够好，意识不够，所以越写越烂。开发者都有一颗积极向上的心，只是不知道如何做好。没有可靠的领导者或架构师。每个人都很懒惰，不想还债。一些华为朋友说，我没有时间承受永恒的商业压力；其实所有公司都一样，抢着发货，哪来得及还钱。关于债务清偿，我也总结了几个务实、脚踏实地的想法：建立质量保证体系，让我有了动刀的勇气。比如接口测试，单元测试，通过CI持续反馈，让我有50%的勇气去做重构。对于遗留系统，如果没有问题，你就不要碰它。如果有问题，修复并补充测试代码。再进一步，可以针对高风险的功能和模块进行针对性的提升。招聘好的工程师，好的作风和习惯可以影响整个团队。抓住疼痛难忍的时候大惊小怪。通常说到持续集成，团队成员可能感受不到好处，如果出现bug，再review；copy-paste代码也不会有一天满足更复杂的需求，所以从心理上来说，大家觉得一定要重写。抓住这个机会，构建更高质量的代码和质量防线。改变一个人很难，抓住这个机会很重要！不要在下雨天修补屋顶。马老师有句金言：雨天莫补屋。软件开发和架构也是如此。当一些关键的战役型项目让你喘不过气来的时候，做理想的架构无异于找死。这里的一个观点是，技术和架构永远是为商业服务的，为商业服务的。无论从走出舒适区的角度，还是从架构发展的角度，都必须找准时机进行架构升级。这种升级是基于对业务本质的不断认识，否则适得其反。我们团队当时正在进行一次重要的架构转型，架构方案比新业务到来早了3个月就确定了，所以恰好通过一个小的业务切换快速上线。然后新架构在竞选的第二个月就派上了用场，3个月的时差足以改变很多事情。所以，一定要切记下雨天不要修屋顶！修屋顶包括偿还技术债务，包括升级结构！总结一下：康威定律及其推论告诉我们做什么，设置什么样的组织结构；同时做不同的事情，允许动态灵活的组织结构，不被组织所束缚；此外，基于协作和授权的跨组织可以提高组织效率；技术债不能等到下雨才还，业务和平台架构发展的平衡艺术取决于特定时间和环境下的目标。技术人员不应该永远被驱赶！研发的痛点是复杂的调试问题，没有灵丹妙药！【本文来自专栏作者张凯涛微信公众号公众号（凯涛博客）公众号id：kaitao-1234567】点此查看作者更多好文
