点击上方“中兴开发者社区”，关注我们

每天读一篇一线开发者原创好文

▎作者简介

作者魏来是敏捷教练，有5年的敏捷实践经验和多年的管理经验，擅长团队SCRUM和项目级敏捷的研究。本文主要是针对开放性做了一些深度思考，尝试从道法术例器等层面展示：如何把开放性的思想运用到日常管理工作中去，建立一个开放性的组织架构和组织文化，以达到提升组织创新能力和组织效率的目的。

一、道-为什么要开放？

在谈开放性之前，先抛出几个大家都熟知的概念：热力学第二定律与耗散结构。
热力学第二定律：又称“熵增定律”，表明了在自然过程中，一个孤立系统的总混乱度（即“熵”）不会减小。
热力学第二定律表明：封闭的系统必然会由于熵增失去活力，最终走向灭亡。
耗散结构：耗散结构是指处在远离平衡态的复杂系统在外界能量流或物质流的维持下，通过自组织形成的一种新的有序结构。
耗散结构理论表明：开放的系统通过与外界不停的交换能量，让系统的熵能够减少，从而保持活力。其中适应物理学中的激光就是耗散结构的典型，当外界输入的激发能量较低时，原子象在一般光源中那样独立无规律的发射光子，每个光子的频率和相位不同，整个系统处于无序状态；而当外界输入的激发能量达到某一临界值时，就会突然发出单色性的方向性很强的激光光束，使整个系统成为有序状态。生物和社会系统都是耗散结构，要吸收养料排出废物，不断进行新陈代谢才能生存，一个城市需要输入食品、燃料、日用品或各种原料，要输出产品和排掉废弃物，才能存在下去，保持稳定的高度组织化的有序结构。因此耗散结构论的理论和方法对于自然现象和人类社会、生态系统等等都能适用。
参考耗散结构理论，我们如果想让一个公司、部门、团队等人类社会组织充满活力，那么必须让这个组织开放。之前喜瑜总也提过，为了更好的生存我们要建立更多开放的圈子，我们内部的圈子比如各类COP、外部的圈子比如中开社，目的就是通过建立圈子让组织更加开放。组织进化最终形态的青色组织也就是由各种圈子组成，已经没有实际的层级关系。

二、法-开放的原则和方法？

开放其实就是指和外界进行能量/物质的交换，是一个双向的过程。对于一个软件开发项目来说，其本质就是信息的转换（把用户的需求转变成计算机所能识别的二进制代码）。所以对于软件开发组织的开放性指的是在软件开发过程中和外界进行信息的交换。
谈到信息，做通信的同学都知道，我们的通讯系统就是基于信息论构建出来的。那么到底是什么是信息呢？有一种说法叫“信息是不确定性的消除”，如果结合之前我提到的开放去理解，不确定性消除之后，不就变得有序了吧，这个也就是我们说的耗散结构所最终达到的充满活力的状态。
所以再引申一下：开放的原理就是—让信息尽可能在组织内/外进行流动
继续思考下去，如何让信息尽可能流动呢？这个时候我们抽象一下，把软件开发当成一个系统去思考。《系统之美》中提到系统应该有目标、连接、要素，其中目标最关键，他决定了系统行为。连接最重要，改变连接会改变系统行为，而且目标也是通过连接逐层传递的。
按照上述的思路去理解开放的方法就是：增加连接的数量，提升每个连接的带宽、注入更多有效的信息。

三、术-如何开放？

按照上文的思路，我们可以通过如下几个方面展开：
1）建立更多连接
建立更多连接对于管理者来说，比较重要的方法就是，给大家创造一些渠道，能够让大家通过这些渠道/平台可以低成本的建立连接。从技术的角度看，做的比较成功的就是阿里的淘宝，卖家和买家之间通过淘宝这个大平台能够自由的建立连接。从连接的分类看，连接又包括外部的连接和内部的连接。建立外部连接的方式，就是我们要提供各种机会让大家去参加各种外部的大会/活动，在上面进行交流、学习和分享。建立内部连接的方式，就是通过各种cop组织来策划更多的活动/黑客松/分享等活动，给来自不同项目/部门/中心的人员以更多的交流机会。
2）拓展每个连接的带宽
信息传递的带宽，取决于信息传递的方式。常见的信息传递方式有：邮件、IM、文档、电话、wiki、易秀、视频、远程会议、面对面沟通等。我们大部分人沟通习惯于采用邮件、文档的方式进行传递，这样的传输方式属于异步窄带半双工的方式，传递的信息非常有限。所以要想提高连接的带宽，我们要在成本可以接受的情况下尽量采用wiki、会议以及面对面的方式来进行信息的传递，这个本身也是敏捷提倡的一种方式。
3）注入更多有效的信息
一般来说我们在软件开发团队中传递的信息有：外部目标、内部计划、用户需求、流程规范、知识技能、进度风险。信息注入最有效的方式，就是可视化和透明化，比如我们常见的SCRUM板、WIKI、CI、度量等，用的都是类似的思路。
首先要加强用户需求、外部目标的传递，告诉所有人做这个事情的原因是什么，大家做的事情和我们外部目标的关联是什么，而不是简单告诉大家要这么做。其次加强内部计划（VCG）、进度风险的传递（度量系统），通过让大家获取到更多关联的信息，这样能够及时识别问题和风险，快速进行消除。再次通过流程规范的可视化（看板上的DOD），让大家做事情的流程规范是什么样的，怎么算是把事情做好。最后通过各种角色模型的评估让大家了解自身的知识技能要求和差距，通过COP能够提升各类角色的能力。
通过上述三种手段，我们能够让信息充分的在组织内流动，从而提升组织的活力。

四、例-开放性的实际案例

关于开放性，我先举一个大家都熟知的例子，就是Google做的android产品，大家都知道android只所以能够和苹果抗衡，最主要的原因就是它的生态圈比苹果更开放，很多厂商比如三星、小米、中兴、华为等可以利用其开源可以快速的集成手机硬件和定制UI并最终打造成自己的品牌。最终这个生态圈变得越来越大，越来越充满活力。
举一个我所在的XXX项目的例子，当然这个例子正在探索中，虽然还不能说是成功的案例，但是当前我们已经感受到了比较多的好处。在谈XXX项目的开放之前，我先列出几个我之前做的项目痛点，主要列举一下由于封闭导致的问题：
1）前后台耦合比较紧，网元自身业务模型的变化导致网管版本升级。
2）网管自身基于XXX框架开发的，是基于单体进程的J2EE架构，并做了大量的定制修改。平台框架+应用二次开发的软件架构，导致交付非常痛苦。
3）人员思维比较僵化，总是喜欢按照老的套路去思考，还认为自己做的挺好。
4）领域化运作导致本文主义严重，跨领域交付协作困难。
5）网管自身缺乏扩展性，功能的开发只能由开发人员自己去做，非研发人员无法参与。
为了解决这些问题，XXX项目开放的整体思路见下图：

1）通过前后台解耦、open api以及微服务架构，提升技术架构的开放性解决前后台耦合紧、应用和平台耦合紧以及自身扩展性的问题，让变化的更加易变。
2）通过小产品运作、特性团队交付来强化用户思维和产品思维，提升产品竞争力和用户体验。
3）通过文化的开放性，为组织架构开放和技术架构开放提供文化基础，避免架构和组织僵化，让组织充满活力。
4）通过最终能否做到快速的价值交付，检验开放性的效果。
接下来重点讲一下文化的开放、技术架构的开放、组织架构的开放：

文化的开放性：

目前对于建立文化的开放性，部门采取的举措有以下几种方式：
1）管理者要有开放的心态，敢于做最牛的路由器。
对于中心的OKR、部门的OKR，以及来自市场的目标以及计划，只要是能够公开的都会通过邮件或者wiki的方式发送给所有人。希望能够通过该方式，让大家尽量的信息对等。对于一些比较重要的信息，会通过不停的重复/说教让直到大家最终能够理解和记住。
在进行工作安排的时候，不仅会告知大家明确的时间要求，而且也会讲清楚此事的来龙去脉，让大家知道为何而做，以及为什么安排他去做不安排别人。
2）做任何事情都尽可能的公平、公正、公开，不能藏有私心。
对于部门的日常工作，比如岗位晋级、考核等凡是涉及到评选、对比的事情，都要基于公平、公正、公开的方式进行。以岗位晋级为例，部门组织岗位晋级的时候，每次都是公开的方式，将评价标准、计算规则、参评人员、评委都事先发给大家，每个参评人员的材料也是完全公开的。整个过程也是采用公开答辩的方式，由尽量多的评委根据选手的日常工作和答辩表现进行综合评判后，根据计算规则计算最终的成绩，然后根据成绩排名情况确定晋级人员。并且公示每个人员的得分、评语等信息，希望大家通过岗位晋级找到自己需要改进的地方。在结束之后也会召开回顾会，回顾本次认证的过程，对于一些号的建议会在下次岗位晋级的时候进行实施。
以评优为例，对于一些部门优秀人员的评选，比如拼搏创新经常会采用SM推荐，然后大家一起集体投票的方式选择优秀的人员。当然投票的依据是根据部门的考核导向以及评选的规则，目的也是为了尽可能的公开。
总之只要时机合适，我一定会想办法继续扩大能够公开事情的范围。
3）善于倾听和收集反馈，并且对于反馈必定有回应
经常通过各种方式和员工进行沟通，尤其是位于前后两端的员工。比如我常用的方式就是平时吃饭的时候找某个员工一起，聊聊他自己最近的成长和困惑，也同时收集一下他对于部门/项目的建议。 同时每次半年考核之后，我也会找各个团队位于两边的同学做一次沟通，主要了解几个事情：自己过去半年年的工作回顾、个人的成长、自己的职业规划、对于部门/项目的建议、对于我个人的建议，之后我也会给员工我自己对于其工作的一些建议。每次沟通后对于员工给出的问题和建议，我都会尽力想办法去落实，对于改进的内容如果有进展，我会找机会给相关人员沟通，并且定期回顾。
同时部门最近也放置了几个意见箱，鼓励大家给部门提供合理化建议，并针对部门的合理化建议，我们计划在wiki上进行可视化，然后积极的进行改进。
4）运营推广COP，鼓励大家参与COP活动
中心成立专门的运营团队进行COP的运营，目标也是扩大COP的影响力，让COP活动辐射到更多的人，从而吸引更多的人员参与。COP运营团队通过海报/微信群/邮件等方式宣传各种活动，在活动之前进行造势，在活动之后进行总结和分享，基本上每次活动都会放在中开社。同时COP运营团队也积极联合各个COP，加强了COP之前的横向联通，让不同COP之间有了很多交集，增加了各个COP圈子的信息交流，很多人平时在工作中没有交集的人，都通过COP建立了交集。比如最近UX COP组织的前端开发技能培训，让不同部门、不同项目的人员有了更多交流的渠道，原来很多前端的问题都不知道找谁，现在是遇到问题能够快速找到对应的人解决，极大的提高了开发效率。

南向的开放：

主要目标是前后台解耦，让易变的更加容易和快速，并且做到模型的变化以及新的网元类型接入不需要升级网管版本。主要的手段有几个：
1）业务能力通过模型去描述，我们引入了netconf协议来描述最复杂的配置模型，并且引入了全领域建模，让所有的网元模型都MO话，从而实现网元基于模型的自管理。
2）接口标准化和插件化，统一南向接入层的对上层APP的接口，屏蔽网元之间的差异。对于差异的部分通过OSGI、模板等技术去解决。
3）模型项目化运作，向管理代码一样管理模型。引入模型CI和度量系统，并且自动对接iDOC。
下面是我们针对所有问题的一个解决方案汇总：

北向的开放：

主要目标是提供开放的能力让3rd APP可以快速定制开发。主要的手段有两个：
1）北向能力的模型驱动，可以将北向的规范转换为模型文件，然后根据模型自动生成北向需要定制的文件。并且北向的接口和模型进行分离，提供北向开通工具，快速定制北向接口，做到北向模型和接口变动之后，版本不用更新。
2）提供基于restful接口的Open API，增加外部的API gateway和API store，用户可以订阅和使用对外发布的API。

东西向的开放：

主要目标是给内部用户提供定制、开放和扩展的能力，同时通过标准接口降低微服务之间的耦合。主要的手段有：
1）所有的微服务都采用标准的restful接口，并且明确每个微服务的接口性能，同时接口的能力必须通过MSB进行注册，服务间通过MSB进行调用。后续提供申明式访问的能力，微服务的调用关系事先声明才能访问。
2）提供APM（应用性能监控）的系统，进行微服务调用链的跟踪。同时通过工具动态生成微服务的调用关系，和系统的微服务的调用申明进行对比，避免出现非正常的调用关系，消除微服务之间的隐式依赖。
3）提供基于OAP和policy平台，并且提供了DevOps的环境，用户可以通过在线开发/设计器灵活定制各种规则脚本，并且在环境上进行调试和上线发布。缩短从idea到产品交付的开发周期，必要的时候可以在现场定制开发和发布特性。
4）提供各种视图和模板定制能力，用户可以快速定制需要的界面和视图，从而满足各种不同用户的需求。
XXX项目通过三个维度的开放，解除了各个方向的依赖，架构上可以支持APP可分可合的灵活部署，从而可以实现类似开源项目的运作方式：每个项目下有若干子项目，每个子项目都可以做到独立的版本发布，整个项目就像在组件市场买东西一样，挑选不同子项目不同版本的组件集成为一个大的版本包。此方式为后面组织开放性中的小产品运作奠定了基础。

组织的开放性：

组织的开放性，以小产品运作+特性团队交付为基本组织形态，以青色组织为最终目标。主要的手段是：
1）小产品化运作，本文不再赘述.
2）特性团队交付，这个是敏捷中多次提到的概念，本文也不做赘述。但是有一点需要强调，特性团队本身和小产品是解耦的，其本身没有产品标签，只是一个开发的资源而已。
通过小产品化运作和特性团队交付，我们希望最后做到：小产品负责人可以类似于谷歌这样，只要有一个好的idea，都可以申请一个小产品开发，在立项通过之后，开发团队可以自由认领该产品的开发。如果该产品成功，会有更多的资源投入，如果失败那么小产品团队解散，会有新的人站出来提出新的idea。加上各种COP运作，达到组织是一个动态变化的过程。小产品负责人刚开始可以是研发内部，然后发展到售后、性能部等公司内的其他部门，最终能够推广到外部社区。通过该方式，可以通过聚集全世界的力量来一起进行产品创新，最终达到我们要建立一个开放生态系统的目标。

五、小结

本文通过作者对于开放性的理解，从道法术例层面，讲述了为什么要开发，以及开放的方式和方法，结合自身的项目和部门举出了一些自己在开放性上的一些探索。文中所有内容都是一些我基于当前认知的一些经验总结和思考，并不代表是正确的，所以希望大家在阅读本文之前带着怀疑的态度去思考，也欢迎大家一起来探讨开放性这个话题。