右军：用康威定律打造动态研发团队

2017年1月16日周二晚8点30分，蚂蚁金服高级技术专家、支付核算技术部负责人右军带来了主题为“从康威定律和技术债看研发之痛”的交流。以下是主持人英子整理的问题精华，记录了右军和读者间问答的精彩片段。

问：组织架构上是否有必要单独成立一个技术能力较强的小团队，把控架构方向引导整合技术团队？

答：康威定律告诉我们，要做什么事，设定什么样的组织架构。不同公司不同业务，不同时期的策略不一样，要看当下的痛点是什么。如果贸然成立一个技术能力较强的小团队，那么这个小团队是否为各业务产品线的产出负责？简单来看，对于规模不大的创业团队，采取最简单直接的组织模式为宜，哪里有问题，哪里就有灭火器。

问：怎么说服不是很懂技术的领导给予时间支持重构这件事？

答：领导如果不懂技术，要说服他们做技术改造很难，包括重构。

领导看什么，看什么时间完成！因此，要和老板以及客户干系人约定好交付范围，在交付过程中要不要重构，取决于成本、平台扩展性、工期的综合取舍。工作量是团队评估的，选择了最优方案，告诉老板为什么是最优的就行了。如果算了时间，单纯再增加2周重构时间，老板一定会砍掉，如果你是老板，也会这样决策。

给一个方案，可能重构是细化进去的东西，不要为了重构而重构。

问：作为基础平台部门，如何更好平衡平台升级与业务线产品交付的压力？是不是组建一个平台加业务的综合团队在一定时期比较有用？

答：一切投入都是成本。无论是业务基础平台还是中间件基础平台，不能服务业务就是扯蛋。所以平台升级也是服务业务，可能是更好的服务未来的业务，那么做好ROI评估。重点业务重点支持；次要业务的特性需求可能紧急程度往后放。团队要如何组建取决于目标，比较好的做法是平台具备开放能力，不用让业务线的需求都完全等待单线程来受理。

问：消除技术债务比较好的手段有哪些，对于债台高筑的项目是否直接废弃重新开发了？

答：一切投入都是成本，债台高筑也要看老板是否愿意承担这些成本，让你重新开发一套系统。

关于技术债务，完全消除过于理想。防的效果也好于治，如同身体健康，我们要提倡预防，加强锻炼，然后辅以体检。体检1年1次也是基于成本考虑的选择。

对于软件系统而言，第一层就是做相对适合的设计，比如风险驱动，在考虑平台的前瞻性和通用性的时候做好评估；第二层要有CI、UT等质量保障体系；第三层：fix技术债务的时候，有很多做法，有小模块重构，也有系统迁移。还是质量优先原则，并行运行，逐步切换是比较稳妥的做法。

问：如果产品团队与技术团队不在同一个team，如何向产品团队的人解释偿还技术债的重要性以及相关的工作量？说服他们在产品迭代的周期安排中考虑这一部分的时间要求？

答：还债也不是白还，是为了更好地支持业务，你可以给产品团队一些方案，说明平台能力升级和业务需求的依赖关系。

另外，人员和时间不应被产品完全锁定，是一个沟通协同过程，彼此要相互尊重彼此的专业性。

问：对缩减团队的案例很感兴趣，从8个团队减到3个团队，他们怎么肯同意的呢？或者再推广一下，如何让一个团队承认他们是冗余的，并不重要呢？

答：这里的8减3不是缩减，而是通过研发团队，业务团队的组织调整优化进行了整合。

效率慢了，我们效率快一点。同时其他人也有别的活干。因此，不能告诉一个团队他们是冗余的，不重要的；只告诉他们组织有更重要的事情交给他们，just do it！！！

问：会不会团队数量减少，团队内沟通成本增加？

答：团队数量减少，团队内沟通成本必然有所增加，但是不是同等量级的。大家可以感受跨team工作，跨部门工作，跨BU工作沟通成本的差异。另外，从一定程度上推全栈的角度看，一方面是沟通成本减少，一方面是消除瓶颈。比如前端和测试可能是瓶颈，大量的Java研发人员可能是瓶颈。那么就要解决瓶颈问题。

问：在分布式项目中，通常会划分为各个能力中心，在项目联调过程中常常会出现各组联调人难以协调、bug归属混乱的情况，比如一个问题在不确定归属的情况下，连该找谁定位都相互推诿，该怎么解决这种情景？

答：推首问责任制，或者设定主架构师，主系分，主测试负责人等。有一个人为全局负责。优秀的人往往具备跨组织解决复杂问题的能力。

问：如果已经积压了技术债务，还有很多的业务需求的压力，而且已经工作负荷很大了，是否有办法向上管理，说服老板把业务需求延期一下，去清理技术债务呢？

答：站在老板的视角，让老板理解，包括需求延期，可以尝试，但因人而异。

我的观点，还是站在业务视角看问题，如果债务不还还能过，紧迫程度就还好。

另外，对于研发人员，我们还要证明一件事，你如何证明同样的需求，你做第二个，第三个比第一个快呢？这里的效率提升可用于一定程度的还债。

问：创业公司初期各种原因会有很多技术债务，中期又会面临快速发展，人员不足，这期间如何更好地组织管理偿还债务？

答：还债看公司发展，业务发展。比如业务高速发展，老板又融了钱。不还债无法支持第二年的数倍业务压力；如果产品方向不明，烟囱型架构挺好的，支持老板快速关闭产品线，寻找新的市场。

总之，技术债务是技术的事情，但是技术支持业务是老板也关注的，要获得老板支持。

问：Team Leader的远见性，基本上能够决定了整个团队的技术远见性，至少在实际工作中会有这样的情况，一线码农如何引导呢？

答：这里的远见包括业务的理解，反映到架构的设计。我们的开发人员要理解架构设计的意图，包括平台发展的方向。

通过架构评审，系分评审等环节来对齐架构与设计目标的一致性。

另外，一线码农并不把自己当着成简单的执行者，如果他们真的善于思考的话，他们也会有自己的一些观点，但是受限于他们的视野以及他的知识背景，并不理解你做什么事儿。

你要给他们讲清楚来龙去脉，包括方案的碰撞。

问：请问能详细介绍一个系统或业务做得比较好的组织的沟通方式和组织结构吗？比如支付宝在不避免谈“责任”的前提下，由于减少沟通环节而造成的后果，有没有好的处理办法增加组织凝聚力，保持上下同欲？有没有实践经验，技术团队建设又有什么特点？

答：比较好的组织结构，我的文章有提到：

• 平台开放—共建；

• 动态组织，比如一块地两个部门老抢，说不定这两个team应该合并或者调整，组织弹性保持按季度这样的调整规模。

团队建设不是本次讨论范围，可以参阅我的公众号：流浪不是我的初衷，里面有篇文章讲构建高效异地研发团队。

问：所谓“强将手下无弱兵”，可往往是“强将手下尽弱兵”。怎么将非一流个体打造成一流团队？

答：Team Leader的责任是成就团队，交付产品。强将手下尽弱兵，或者说这将也强不了，打造一流团队，提几点浅见。

• 招聘高潜力的人才，招聘强兵。

• 培养苗子，形成示范效应。如同一片池塘，总有些荷花是先开的。

• 对于一些创业团队，工资不高，愿意跟随的人未必是最厉害的。那么共同的使命和远景很重要，大部分是可以塑造的，形成产品文化，质量文化，而这些依赖一个好的领头人，来构建土壤，而不仅仅是一个人去上阵杀敌。

问：在保证质量和进度的前提下，怎样减少团队的加班时间？

答：不鼓励为了加班而加班，质量和进度都保障，不需要加班了；往往是保障不了，短期内加班是一种办法；长期看从消除重复，创新问题解决方案上面看看。

团队自己评估成效，重要的是【完成】的定义。个人因为成长意愿看书，学习是可以的。

问：平台交给产品线的发布TAG，产品化项目中遗留问题较多，因为平台承载多条产品线是客观原因，但平台版本因为不直接面对市场，时间多了很多藏在地毯下垃圾，技术债务，心理上觉得还有产品线在守门，这种情况产品线如何搞定平台部门？

答：平台产品有基础产品能力，产品化项目有个性需求，面对市场。

平台也要尝试懂市场，重点支持某些产品线，同时因为更了解业务，才能做出合适的决策，来构建好平台。

如果人不变，压力不变，打法不变，就没有破题，要创造变化。

要创造变化，发掘变化，比如倾斜到某一条重点产品线，四平八稳可能问题更大。

问：在大公司中，技术研发的价值怎么被肯定，尤其产品/运营主导的业务，对外出口大多都是产品为主，如果产品用力过猛，就很容易把技术的一部分事情给做了，技术成了产品对外输出个人能力的工具了，这个算是问题么吗？

答：产品或者运营主导的公司貌似不少，产品把技术的事情做了，关键看有没有做好。如果研发真的找不到事情做，可能老板应该扩张产品线了。

我见过的情况是，产品的需求里面都做数据库设计了，但是我可能跳过不看，因为他们根本没有考虑性能问题。

问：现实中负债经营其实未必坏，债务太轻反倒可能是杠杆使用不足。技术债有类似的性质么？

答：一切都是成本，你要还债，就要付出成本。所以在什么时间还，要做决策。

问：是不是产品经理有好的产品需求规划有利于技术债务的减少？或者说，技术债务的根源之一就是需求的大量涌入呢？

答：好的需求规划，某种情况下会减少债务。但是研发从需求分析到架构到设计，到实施，有一系列过程。技术债务有技术储备不足的原因，有计划中的债务。

债务不用怕，关键在于有计划，在合适的时间，并掌握主动性。

问：也有技术团队与市场脱节的情况，怎么防范？是说产品主导，技术团队成果不显著，甚至被产品部门抢事情的反面。技术主导，但是提供的服务反倒阻碍产品部门的情况也存在，这种情况怎么办？

答：一切为客户服务，缺了谁都玩不转。技术主导不是闭门造车，要反映到客户的需求本质，问题被解决。

问：而且由于不直接在产品中体现，往往不能很快表现出来，等发现走错路了已经病入膏肓了

答：部门要有情商啊，产品部门抢技术的荣誉？我们都是一根线上的，一荣俱荣。

问：项目上线后进入日常版本中，一般一个月上一个版本，日常版本中架构师基本不介入，架构设计其实在项目上线前关注，此后基本都是产品说话。他们承接甲方需求，直接对接开发组，日积月累的需求，日积月累的债务。堆砌业务代码。后边若有人离职，都看不懂写的什么鬼。这种情况怎么解决？

答：有什么样的组织，就有什么样的问题。架构师在日常研发过程中不参与；但是也要有人来cover 整体系统的健康度。架构发展，比如开发组有没有这样的人呢？康威定律说了，要解决问题，首先改变组织流程。产品是需求方，他不负责代码的坏味道，但是有人得负责。

问：减少团队数量来提高沟通成本，但这个和康威定律是矛盾的。康威定律不是说大系统倾向于拆分。那就是说总有一种组织形态是最佳临界点，是最适合当前架构的？或者说是最适合设计当前系统？再或者说是提供满足客户价值的系统。客户的需求是变化无常的，那组织的重构也必然是一种常态。不知道这么理解对不对？

答：我的文章提了几个观点，我再提炼一下。

• 你要什么样的结果，就搞什么样的组织；

• 什么样的组织，必定会反过来影响某些结果；

• 我提倡组织是动态的，因为目标和协同方可能变化；

• 分和合都是不同时期的决策，过犹不及。

（以上内容转自GitChat，版权归GitChat所有，转载请联系GitChat，微信号：GitChat，原文：《右军：用康威定律打造动态研发团队》）

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF931BE00001DE2F104818901564