Work on stuff that matters:
- work on something that matters to you more than money
- create more value than you capture
- take the long view.
Tim O’Reilly
最近在跟车载座舱中的紧急通话ECALL功能时，发现最开始的设计方案完全没有考虑到硬件与软件的复用。由于这个方案跨了两个中心的部门，ECALL的初始方案设计中竟然为ECALL增加了额外的一套录音与播放系统，不仅增加了硬件成本，也加大了软件开发的投入，而这样音频系统在座舱SoC上早就已经有一套了。如今，团队又不得不重新提出一个所谓降本的方案，以减少成本。这种系统设计的方案不禁让我联想到软件设计中著名的康威定律(Conway's law)：
1 |
|
翻译过来，康威定律是说，在任何一个组织中诞生的系统, 在很大程度上会被设计成一个跟这个组织(沟通)结构类似的架构，就是说在系统设计的时候，我们自觉或不自觉的构建出了一个跟自己所在团队结构类似的系统框架了。关于康威定律，有一个更为直观的说法来自Eric Steven Raymond:
1 |
|
对于汽车这样一个由诸多复杂零部件构成的系统来说，实际开发中涉及到主机厂、各级供应商，跨团队的合作与开发会特别多，所以容易出现这类系统设计的事故，举几个我知道的例子吧:
- 自动驾驶团队在选摄像头型号时，只考虑方便训练机器学习模型的类型，没有考虑其他系统，比如座舱控制器也有可能需要行车数据，导致后期在车型上开展类似功能时十分痛苦，做出来的效果跟其他厂商比也差强人意
- 同属一个业务的功能，如
CarService，由于应用端与系统开发分属在两个团队， 应用的开发在需要提供接口给第三方业务调用时，基于系统的API做了第二次封装，与现有的封装业务属性上基本重合了 - 不同团队在同一个平台上、同一个系统上同时进行开发，大家在同样的事情上重复的投入
那么，我们不禁要问，为什么人们在跨团队合作时会出现这种事后看起来啼笑皆非的情况，做出让人难以置信的决策了？想了想，大致有如下两个原因:
- 团队中经常出现屁股决定脑袋的事情，不同部门之间协作容易变成抢业务的情况，尤其是业务存在重叠时更是如此
- 做技术决策或者方案设计时，相关的专业人员没有深度参与其中，导致很多声音被埋没了，没有被听见
从这两点上，我们不妨来推演下，如何避免跨团队设计方案时出现康威定律中的诅咒。一个公司在发展初期，人员比较少，很多业务在大公司都是几十个人承担的，在这里可能就一个人忙前忙后。这样大家做沟通与决策的成本相对而言比较少的。等到公司规模不断扩展，团队人员快速增加，沟通成本增加的同时，也带来了业务分配的问题，最后发现可能有多个团队在做类似或者相同的事情。
这类问题初期还容易比较根治，到了后期涉及到的人员多时就很难了。业务的重叠或者人员的冗余，说到底是公司技术体系的构建不合理，没有充分做到复用：人员的复用，团队能力的复用，系统设计的复用。所以，理想汽车的CEO李想在讲到公司的组织架构时(视频可以在哔哩哔哩上搜索到，值得看看)，就特别提到了公司体系的建设与构建-我想这大概就是尽可能去做到组织中各个团队不同业务的解耦，尽量避免重复造轮子，增加系统复用的程度，从而提高组织效率，从根源上减少开发成本。又或者，公司初期在组织体系上做的不够完善，欠了债务，那么等到团队初具规模时，一定要下定决心做重构，重新梳理不同业务部门的职能与负责的事情，尽量避免这种团队与业务的耦合扩散到无法收拾的程度。
关于第二点，在做系统方案设计时，专业声音被淹没的问题，由于涉及到不同专业背景的人，所以可能更难处理。对于一个想要在激烈市场竞争中获得胜利的团队，要想做出更好的产品，做出更明智的决策，让团队成员都有机会发声，强调高效、平等的沟通，打造专业、追求极致的文化氛围之外似乎没有更好的选择了。这是一个系统工程，也是一个想要长期取得领先定位的团队必须要思考面对的问题。只有从方方面面去构建高效、专业、极致的组织文化，才有可能避免这种专业声音石沉大海的问题。
总结
这里借这康威定律讲了自己在系统设计与组织构建中的遇到一些问题，实际上这些问题的原因可能比我看到的要更为复杂多样。系统设计涉及到公司组织架构、技术能力、团队管理、产品定义等多个维度，要想做好其实是一个非常有难度而有挑战的事情。每个想要做好产品，为用户创造价值的团队都需要认真考虑康威定律可能带来的影响。有关康威定律，Martin Fowler写了一篇文章介绍了如何在软件开发如何应对，值得参考下Conway’s law。