點選上方“中興開發者社群”，關注我們

每天讀一篇一線開發者原創好文

▎作者簡介

作者魏來是敏捷教練，有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運作，達到組織是一個動態變化的過程。小產品負責人剛開始可以是研發內部，然後發展到售後、效能部等公司內的其他部門，最終能夠推廣到外部社群。通過該方式，可以通過聚集全世界的力量來一起進行產品創新，最終達到我們要建立一個開放生態系統的目標。

五、小結

本文通過作者對於開放性的理解，從道法術例層面，講述了為什麼要開發，以及開放的方式和方法，結合自身的專案和部門舉出了一些自己在開放性上的一些探索。文中所有內容都是一些我基於當前認知的一些經驗總結和思考，並不代表是正確的，所以希望大家在閱讀本文之前帶著懷疑的態度去思考，也歡迎大家一起來探討開放性這個話題。