中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：設計系統(tǒng)的組織，其產生的設計等同于組織之內、組織之間的溝通結構，但其思想的深度遠不止于此，本篇文章中，作者深度地解析了康威定律，并對團隊組織和產品架構設計等方面做出詳細的解釋，如果你感興趣的話，那就一起來看看吧。

“組織形式等同系統(tǒng)設計”——這就是康威定律（Conway’s Law）闡述的一個關鍵思想。Conway’s Law (melconway.com)

其原話是這樣的：

Organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.-MelvinConway(1967)

中文直譯大概的意思就是：設計系統(tǒng)的組織，其產生的設計等同于組織之內、組織之間的溝通結構。

但是其思想啟發(fā)遠不止于此。

本文目錄如下：

1. 團隊組織＆產品架構設計。
2. 溝通成本 = n(n-1)/2。
3. 孤島系統(tǒng)的集成接口量。
4. 康威定律與微服務的合理性。

一、團隊組織＆產品架構設計

面試的時候，面試官問我們有什么要問的，實在想不出的時候，你就問問團隊組織架構吧。

這不僅僅是關乎到自己入職后的匯報協作，同時也是對產品系統(tǒng)架構的預估。

為什么呢？因為組織結構往往代表一種協作分工，而分工的產物就是產品。

所以，團隊組織形式，首先體現在系統(tǒng)上。

比如Apple的產品、微軟等的產品腳骨設計，就能形象生動的理解這句話。

從這張圖也可以看出：

亞馬遜等級森嚴且有序；谷歌結構清晰，產品和部門之間卻相互交錯且混亂；Facebook架構分散，就像一張散開的網絡；微軟內部各自占山為王，軍閥作風深入骨髓；蘋果一個人說了算，而那個人路人皆知；龐大的甲骨文，臃腫的法務部顯然要比工程部門更加重要。

多年前，更有人在《第一財經周刊》嘗試著炮制了一份中國主要的科技公司的結構圖—百度、騰訊、華為、聯想、阿里巴巴、新浪。

結果發(fā)現，它們也是彼此風格迥異(和今天的實際情況已經不一樣了)：華為，技術創(chuàng)新引發(fā)矩陣結構變化；阿里巴巴，馬云的影子無時無處不在；新浪，依托微博畫了一張大餅；百度崇尚簡單；聯想，大小通吃但又左右互搏；騰訊，產品與部門關系千絲萬縷，QQ是所有產品與服務的基石。

這給我們的啟發(fā)就是，想要什么樣的系統(tǒng)，就搭建什么樣的團隊。

比如，如果系統(tǒng)是按照業(yè)務邊界劃分的，大家按照一個業(yè)務目標去把自己的模塊做出小系統(tǒng)，小產品的話，你的大系統(tǒng)就會長成下面的樣子，即微服務的架構：

這個思想，其實就來自于康威定律。

二、溝通成本 = n(n-1)/2

《人月神話》中最著名的一句話就是:

Addingmanpowertoalatesoftwareprojectmakesitlater–FredBrooks,(1975)

之所以這樣，是因為溝通成本 = n(n-1)/2。

溝通成本隨著項目或者組織的人員增加呈指數級增長。舉個例子：

5個人的項目組，需要溝通的渠道是 5*(5–1)/2 = 1015個人的項目組，需要溝通的渠道是15*(15–1)/2 = 10550個人的項目組，需要溝通的渠道是50*(50–1)/2 = 1,225150個人的項目組，需要溝通的渠道是150*(150–1)/2 = 11,175

為什么這樣呢？國外的研究：靈長類的大腦容量和其對應的族群大小有一定關聯：

從而推測出人類的大腦智力只能支持我們維系這么多的關系:親密（intimate）朋友: 5信任（trusted）朋友: 15酒肉（close）朋友: 35照面（casual）朋友: 150再多的化，溝通的問題，會帶來系統(tǒng)設計的問題，進而影響整個系統(tǒng)的開發(fā)效率和最終產品結果。150也就成了很多設計的參標，比如某系統(tǒng)的購物車最大允許200個商品（涵蓋150）。

所以，一個大的組織因為溝通成本/管理問題，總為被拆分成一個個小團隊。每個經理都被賦予一定的職責去做大系統(tǒng)的某一小部分，他們和大系統(tǒng)便有了溝通的邊界。

三、孤島系統(tǒng)的集成接口量

說一個案例：隨著醫(yī)院信息化建設的不斷完善，醫(yī)院逐步上線了 HIS、EMR、PACS、LIS 等多個業(yè)務系統(tǒng)。由于這些業(yè)務系統(tǒng)由不同廠家開發(fā)，各個系統(tǒng)擁有不同的操作系統(tǒng)、數據庫，進而導致不同業(yè)務系統(tǒng)之間需求調用復雜、接口數量多且無統(tǒng)一標準、數據交互效率低下、維護困難等問題。

正如人月神話提出的，隨著項目或者組織的人員增加呈指數級增長，溝通成本 = n(n-1)/2，傳統(tǒng)模式下各個孤立系統(tǒng)對接時候的接口開發(fā)最大數量也是N*(N-1)/2。

這就導致實現成本很高，于是出現很多集成平臺。

集成平臺的重要性在于，其不僅能夠在各個系統(tǒng)之間實現統(tǒng)一集成和交互，同時為數據集成提供了可能。

通過將各個系統(tǒng)產生的數據集中存儲并重新組織形成醫(yī)院的數據倉庫，集成平臺為下一步數據分析創(chuàng)造條件，即充分挖掘數據價值進而形成一系列數字化應用支撐智能化決策，幫助醫(yī)院實現真正數字化轉型。

可以說，集成平臺是醫(yī)院數字化轉型的重要基礎。市場出現很多超融合架構承載集成平臺，相較傳統(tǒng)架構具備高可靠、高性能、簡單敏捷等多種優(yōu)勢，將會成為企業(yè)集成平臺基礎架構選型的一個不可忽略的選項。

所以大的系統(tǒng)也會因此被拆分成一個個小團隊負責的小系統(tǒng)（微服務是一種好的模式）。

四、康威定律與微服務的合理性

微服務是指將應用功能最小化，原子化，盡可能減少應用服務之間的耦合，而后通過不同微服務組合出不同的功能，提供給用戶。最大化服務的可重用性。

康威定律其實在半個世紀前就奠定了微服務架構的理論基礎。

如果子系統(tǒng)是內聚的，和外部的溝通邊界是明確的，能降低溝通成本，對應的設計也會更合理高效。復雜的系統(tǒng)需要通過容錯彈性的方式持續(xù)優(yōu)化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的。

帶來的具體的實踐建議是：在對應下衡量微服務的標準，我們很容易會發(fā)現他們之間的密切關系：

• 分布式服務組成的系統(tǒng)
• 按照業(yè)務而不是技術來劃分組織
• 做有生命的產品而不是項目
• Smart endpoints and dumb pipes（我的理解是強服務個體和弱通信）
• 通過MVP的方式來設計系統(tǒng)，通過不斷的迭代來驗證優(yōu)化，系統(tǒng)應該是彈性設計的。
• 自動化運維（DevOps）
• 容錯
• 快速演化

微服務的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統(tǒng)的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統(tǒng)內部，每個子系統(tǒng)就會更加內聚，彼此的依賴耦合能變弱，跨系統(tǒng)的溝通成本也就能降低。

五、小結

康威定律可歸納一些核心觀點，如下：

第一定律：Communication dictates design（組織溝通方式會通過系統(tǒng)設計表達出來）

第二定律：There is never enough time to do something right, but there is always enough time to do it over（時間再多一件事情也不可能做的完美，但總有時間做完一件事情）

第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（線型系統(tǒng)和線型組織架構間有潛在的異質同態(tài)特性）

第四定律：The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解）

六、給我們的啟發(fā)是

人與人的溝通是非常復雜的，一個人的溝通精力是有限的，所以當問題太復雜需要很多人解決的時候，我們需要做拆分組織來達成對溝通效率的管理。

組織內人與人的溝通方式決定了他們參與的系統(tǒng)設計，管理者可以通過不同的拆分方式帶來不同的團隊間溝通方式，從而影響系統(tǒng)設計。

我們要用一切手段提升溝通效率，能2個人講清楚的事情，就不要拉更多人，每個人每個系統(tǒng)都有明確的分工，出了問題知道馬上找誰，避免踢皮球的問題。

你想要什么樣的系統(tǒng)設計，就架構什么樣的團隊，能扁平化就扁平化。最好按業(yè)務來劃分團隊，這樣能讓團隊自然的自治內聚，明確的業(yè)務邊界會減少和外部的溝通成本，每個小團隊都對自己的模塊的整個生命周期負責，沒有邊界不清，沒有無效的扯皮，inter-operate, not integrate。

做小而美的團隊，人多會帶來溝通的成本，讓效率下降。亞馬遜的Bezos有個逗趣的比喻，如果2個披薩不夠一個團隊吃的，那么這個團隊就太大了。事實上一般一個互聯網公司小產品的團隊差不多就是7，8人左右（包含前后端測試交互用研等，可能身兼數職）。

作者：深度，微信公眾號：產品找北

原文鏈接：https://mp.weixin.qq.com/s/blyD6R-pD-rHApRLZv93LQ

本文由@產品找北 授權發(fā)布于人人都是產品經理。未經作者許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議