產品經理懂點技術(2)：產品經理真的要懂微服務麼
微服務是由業務驅動的，這就意味着業務規劃的好壞會直接影響系統架構的好壞，糟糕的系統架構還將拖業務的後腿，甚至進入惡性循環。
在上文講微服務架構的由來時，我們引用了馬爾文·康威（Melvin Edward Conway）的一句話
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations
設計系統的架構受制於產生這些設計的組織的溝通結構。
——Conway, 1967.
康威是以為計算機科學家，計算機程序員和黑客，他著名的論文《How Do Committees Invent？》裏面的內容被弗雷德·布魯克斯（Fred Brooks，美國計算機架構師， 軟件工程師和計算機科學家，以管理IBM的System / 360系列計算機和OS / 360軟件的開發而聞名支持包）在他的經典著作《神話人月》（The Mythical Man-Month）中引用了，稱其為“康威定律”。
康威定律可謂軟件架構設計中的第一定律，總結起來又有四條具體定律，我們主要講講其中第一、第三定律。
康威第一定律：
Communication dictates design
組織溝通方式會通過系統設計表達出來
圖片：Manu Cornet
組織的溝通方式，包括業務部門的劃分、合作流程，如果部門間分工混亂、流程無章可循，那麼系統上就只能發現什麼問題解決什麼問題，不能有效的促進業務的發展。只有解決好組織的溝通方式，大家分工明確、流程清晰，才有更好的工作效率，也才有可能做出一個好的系統。
康威第三定律：
There is a homomorphism from the linear graph of a system to the linear graph of its design organization
線型系統和線型組織架構間有潛在的異質同態特性
筆者補充：homomorphism的中文翻譯是同晶（型）的意思。異質同態就是外在不一樣，但是本質結構類似或一樣的意思。
第三定律是對康威第一定律的具體應用，什麼樣的組織架構將會決定什麼樣的系統。反而言之，如果想要一套好的系統，那就得要有一套好的組織架構。
圖片：James Lewis、Martin Fowler 翻譯：iCheer
圖片：James Lewis、Martin Fowler 翻譯：iCheer
根據康威定律，我們就知道了，業務的形態最終會影響到系統的架構。而微服務是由業務驅動的，這就意味着業務規劃的好壞會直接影響系統架構的好壞，糟糕的系統架構還將拖業務的後腿，甚至進入惡性循環。
業務-產品-研發的工作流當我們討論產品方案時，都不能脱離業務，業務是需求最重要的根源，那到底什麼是業務呢？
從詞語定義來説，業務是指某個行業或者某個職務所做的事情，就叫做“業務”，其參與者是人，未來也可能是電腦、機器（AI、自動化），其目的滿足行業、職務的服務對象的需要。
業務方在工作過程中，為了實現更高的產能、獲得更高的回報，就會想辦法去優化整個業務流程，這就產生了“需求”。只要業務想發展、在發展，需求就會源源不斷的產生。
產品經理接觸的需求來源，外部是業務的服務對象：用户；內部則是業務的執行方：老闆、運營、商務、財務、法務、供應商等。業務方將需求告知產品經理，產品經理經過調研論證，將需求轉換為產品方案，輸出可以滿足業務需求的產品需求文檔、原型。
然後，產品將功能的需求提給研發人員，研發最終將這些功能得以實現，於是系統誕生了。業務方使用系統，不斷髮展擴大，產生更多的新需求，於是以此往復，形成業務-產品-研發的需求鏈條閉環。
在這個鏈條閉環裏，業務形態、流程決定了系統最終的形態，而系統形態則推動業務的發展。產品是連接業務與系統的紐帶，技術並不是在瞎逛，而是根據產品的需求去研發系統，技術研發出來的系統會最終決定業務未來的走向。
微服務與產品經理的工作業務驅動：
微服務是技術讓代碼更適應業務發展的產物，是業務驅動下的產物。
微服務的概念需要程序員更瞭解業務的板塊劃分和發展方向，代碼要隨着業務的不斷成熟，按照業務結構進行模塊化、服務化，才能方便業務的發展壯大，這就要求程序員要“懂點產品”。
如果程序員一味的按照純粹的技術方案或者自己拍腦袋定的方向做，那隨着業務的迭代發展，很容易出現“這個需求做不了”的問題，因為代碼被技術方案禁錮住了，無法適應業務的發展，如果要解決，可能就要重構，時間、人力成本將居高不下。
業務驅動的過程，不是一個“理想”、“理性”的過程，代碼講究的是邏輯，是要“不出bug”、“跑得起來”，但是業務的發展是用户、市場需求不斷積累的一個過程，很多需求可能是很主觀的，甚至有時候是“靈光一閃而過”的。需求存在不確定性，這就讓程序員犯難了，那到底要不要按照這個方向做呢？萬一做了用不上要推倒重來怎麼辦？
這時候就體現出了產品經理的作用，對現有業務架構的劃分、對新需求的判斷和歸類，這將直接影響微服務的架構模塊。
產品藍圖：
產品經理可以不懂什麼是微服務，但應該知道自家產品的功能架構或產品藍圖，這既是產品需求篩選、功能規劃的依據，其實也是技術做微服務劃分的重要依據。
產品藍圖（Product Roadmap）是描述產品可能的發展方向，統一利益相關者的意見，計算產品開發預算的強大工具。 但是，想要作出切實有效的藍圖並不容易，尤其是在意外變化頻頻的敏捷環境中。
——《創建敏捷產品藍圖的十個技巧》-carlosmeya
Roadmap通常翻譯為“路線圖”或“藍圖”，目前並沒有一個公認的定義。在這裏，我們認為Roadmap是產品經理進行產品管理的一箇中長期規劃，也稱路標規劃。 為什麼要做Roadmap？簡單説就是，心中有數。
某平台的產品藍圖1 來源：百度圖片
某平台的產品藍圖2 來源：百度圖片
某平台的產品藍圖3 來源：百度圖片
看了上面的產品藍圖，是不是覺得和功能架構圖十分相似？其實表現上差不多，但是產品藍圖還包含了對整套系統的發展方向預期，裏面的很多模塊可能處於“會有的”狀態，隨着業務的發展不斷補全。
有了產品藍圖後，新需求就可以很方便的進行歸類，做版本規劃時也可以看得出距離預期目標還有哪些沒有實現的地方，然後進行補齊。
更重要的是，產品藍圖作為產品設計方向的指導作用，能讓技術對產品未來的完整形態一目瞭然，然後再進行以業務為驅動的代碼服務化，這樣就能讓代碼能適應更長遠的發展需要，避免盲目設計導致最終影響業務發展、需要推倒重來。
通過產品藍圖、產品規劃，產品經理能讓技術瞭解整個業務的未來發展方向，讓技術可以更熟悉產品，知道“為什麼這麼做”、“以後還要做什麼”，這樣在寫代碼的時候可以更有方向的做兼容。
總結微服務其實是技術、產品的目標一致化的必然結果，大家都以如何更好的發展業務去進行工作。產品經理可以不需要深入瞭解微服務下各種配套的機制、利弊的問題，但需要知道，微服務其實是產品架構在代碼層的映射、體現。
一個好的產品架構，將有利於技術框架的成型和發展，反之一個模糊不清、結構混亂的產品架構，將會讓技術也無從下手，只能頭痛醫頭的解決眼前的需求，無法從代碼層面做長遠的兼容、發展考慮。
所以我的觀點是，微服務是技術架構適應業務發展的一個過程，如果從技術的工作上看，讓代碼順應業務的發展其實是個大難事，關愛程序猿人人有責。而產品經理雖然不需要知道微服務的技術細節和實現方法，但應該更多的強化自己的產品能力，多將業務發展方向的事情與技術同事聊聊、科普一下，有利於技術架構更好的發展。
參考文章《Applying Conway’s Law to improve your software development 應用康威定律改善軟件開發》作者：Fausto de la Torre
《CONWAY’S LAW 康威定律》作者：Melvin Edward Conway（康威本人）
《Microservices a definition of this new architectural term 微服務：一個新的架構術語的定義》作者：James Lewis、Martin Fowler，此文有中文譯文版本，大家可以自行搜索
《每個架構師都應該研究下康威定律》作者：楊波
《康威定律》作者：Smah
Dubbo：阿里巴巴公司開源的一個高性能優秀的服務框架，官方文檔：http://dubbo.apache.org/zh-cn/docs/user/preface/background.html
相關閲讀產品經理懂點技術（1）：程序員講的“微服務”到底是什麼？
本文由 @iCheer 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議