阅读笔记四

 

1、解耦合

经常反馈的问题，异地管理，沟通成本高。想想其实，这不就是系统架构里，所谓解耦合的问题。

系统架构设计，所谓的解耦合，就是每个模块内部尽可能独立，对外接口尽可能标准通用，这样系统间的沟通只需要了解模块接口，无需过度考虑内部细节，每个模块的调整和变动，只要接口不变，对其他模块无影响。管理上，特别是异地管理，多地办公，也需要这样的思维，每个团队内部尽可能独立，对外沟通的接口尽可能标准规范，相关的合作通过尽可能少的接口完成，相对独立运行，这样每个团队，部门内部管理和内部调整，尽可能对其他部门，其他团队没有影响。但现实中，跨级指挥，快速组建跨部门的协调小组也是很常见的，这有利于单一项目的快速资源组织，从具体项目来说，沟通效率变高，但从整体的团队体系来说，就很容易造成指挥混乱，多头管理，如果在同一个地方办公相对还好，如果是异地办公，那么对于相关工作人员来说，面对多头管理，就会存在无法把握任务轻重，混淆工作任务，失去优先级概念等等。在企业具体阶段，面对具体的问题，可能有不同的选择。但强调一下，解耦合这个意识是需要的，企业成长和发展中，多部门协调和跨地区协调会成为常态，如果做不到解耦合，后面的管理问题会越来越多，人员协调会越来越难。

2、复用性

那么另一个常见的管理问题就是重复开发，重复造轮子，重复做同样的事情，带来的人力资源开销的浪费。这其实对应的架构原则就是高复用，通用灵活的组件，可以满足不同类似的诉求。

 

跟字节跳动的朋友聊天，觉得他们的架构还是很有代表性的，技术团队中，核心算法是统一的，不同项目对应的是不同的接口团队，对核心算法有不同的策略调整，这也是系统架构中的一个典型的分层思想，技术架构中，经常这么设计分层，核心逻辑层，接口策略层，应用表现层，管理结构中，对应的就是核心算法团队，接口技术团队，产品运营团队。这样就可以用相对较轻的开发成本满足不同的诉求和产品目标。

一个企业，多个项目并行的时候，基础支撑团队，提供通用性的技术，策略，架构支持，然后是不同的接口对应小组，以及具体的项目产品运营团队。这种三层管理结构既可以满足不同业务独立性的诉求，也可以满足一些重复性工作的复用性的需求。

但现实中，很多项目负责人会觉得，不是自己团队的人，指挥不动，沟通不利，不如放在自己团队里好使。

企业快速扩张的时候，业务发展迅速的时候，这些问题看上去也不算什么大问题，但当企业达到一定规模，增长乏力的时候，算算人力成本，再看看新产品的研发周期和市场快速响应能力，这里的问题就凸显了。

话说，我前文多次提过，今年，巨头休战了，从追求市场占有率转为追求利润率了，对内部的成本管控会更加严格，加上字节跳动的快速崛起，所谓APP工场的示范作用，这种通用支撑多种业务的管理模式应该会被很多巨头学习参照。

3、防范单点隐患

很多创业公司，血淋淋的教训。

从技术来说，诸如数据库被删除，源代码被删除，域名被转移等等，一次事故就导致万劫不复。从管理来说，核心员工离职带来无法挽救的损失。

我们从系统架构来说，有单点隐患的概念，如果存在一个节点，一旦出现故障，会导致整个系统不可用，这个节点就被称为单点隐患，那么系统架构师有很多工作是如何避免单点隐患，通过备份，灾难容错的机制来实现系统高可用性。

 

那么从管理来说，也存在这个问题，而且创业公司基本上都是不可避免地，依赖于核心员工，依赖于核心资产。当然，最大的单点很风险可能是创始人，不过一般来说，创业者会担心的是其他的隐患。

一是有资产管理的概念，所谓核心资产，包括但不限于 源代码，线上数据库，域名管理后台账户和管理邮件，银行账户信息，域名备案信息，企业运营资质，企业相关的产品账户，比如苹果账户，谷歌账户，企业广告账户，比如Facebook账户，百度账户等，企业对外的宣传账户，比如企业微博账户，公众号账户等等等等。对外公开的业务联系方式。核心资产应该具有清单，具有可管理性，特定核心人员离职应能够保证可回收，包括强制回收。

此外，在资产管理这方面，还要考虑到一些意外可能，比如典型的，财务人员被骗，核心管理人员邮件被木马入侵等。并不是说，我用的人很可靠，很值得信赖，就一定不会出差错，要有足够的安全意识。比如说，我都不敢让我老婆在线上管理和操作一些重要资产，当然不是不信任老婆，而是怕她被别人黑了自己都不知道。

人员管理上，做到完全的冗余可能比较难，特别是创业公司，成本也跟不上，但首先要做好资产管理的单点隐患防范，该备份的备份，重要的电话号码，邮件地址，联系方式应该归属于公司所有，账户系统应保持公司可控的超级管理权限。此外人员管理上多留一点心，随时跟外面的优质人才保持关系，随时心理保持一份备选名单，是很有必要的，以及关键岗位尽早培养接班人。尽量不要出现核心人员流失后手忙脚乱，项目崩溃的情况。