設計「業務」與「技術」方案

三天研發，兩天設計；

【優先做設計方案】

職場中的那些魔幻操作，研發最煩的是哪個？

作為一個數年且資深的網際網路普通開發，可以來說明一下為什麼是：缺乏設計；

面對業務需求的時候，可能都聽過這樣一句話：

這個很簡單，直接開發，三天內上線；

產品聽了流淚，測試見了崩潰，研發眉頭一皺直呼什麼鬼；

如果沒有聽過，那麼職場的經歷可能是不完美的，但是幸運爆棚；

這種魔幻般的神奇操作，邏輯在哪裡？底線在哪裡？唯獨離譜在這裡；

從實踐經驗上來看，產品研發拋開業務設計所帶來的反傷，也許會遲到，但絕對不會缺席；

所謂的簡單業務流程，倉促上線之後，後續補坑的成本可能高的離譜；

相對於完整的研發週期來說，設計、落地、一次性的高質量完成，就是成本最低，效率最高的決策；

對於研發角色，方案設計通常就是圍繞技術和業務兩個核心；

【常用的方法論總結】

在做方案設計時，必然要運用一些基礎的方式方法；

有關方法的經驗總結很多，但是真正常用的並不多，以下只圍繞個人在工作中常用的幾個來分析；

本質：

理解本質的時候，必須明確在一定的空間和時間範圍內，需要有邊界約束；

如果範圍擴大，考慮的因素太多，相互間的影響和關聯過度複雜，脫離實際太遠，很難得出符合現狀的結論；

在工作中時常會說：透過現象看本質，理解不同事物的共性和個性，判斷髮展邏輯；

那麼，如何理解產品研發的本質？

基於業務的供需關係，持續打造優質的產品服務；

這個描述只是個人的實踐體會，對於事物的本質理解，應該簡單明瞭，直擊核心內容；

矛盾

矛盾是指事物內部以及事物之間的對立統一關係，雖然概念很抽象，但現象幾乎是無處不在；

用通俗的方式來理解，就是需求和利益之間的衝突且統一的關係；

以常見的平臺商業形式來思考；

平臺方：希望以低成本的服務獲取更高的營收；

客戶方：希望以低成本獲得更好更優質的服務；

平臺與客戶雙方，都希望低成本付出，獲取更高的回報，矛盾就這樣產生了；

但是，平臺失去客戶，沒有持續生存的能力；客戶本身又依賴平臺服務，關係既統一又存在衝突；

雙方的合作，隨著不同階段的核心問題被解決，即事物的不斷髮展變化，新的問題和矛盾也會出現；

系統

理解事物的全貌，橫向擴充套件的廣度，縱向發展的深度，在時間空間的變化中，以動態的思維應對事物的變化；

簡單的說就是：全面的看事物，系統的解決問題；

以實際的研發案例來分析；

面對並行業務的複雜流程時，比較經典的就是搶單場景，處理的思路有很多種；

如果資源足夠，直接擴充套件以支撐請求處理；

如果資源不足，可以限制請求端的放行比例，伺服器端只處理少量請求；

或者伺服器端對請求非同步解耦，快速失敗掉大量的請求；

所以在面對問題時，不必只片面的看一個方向，圍繞問題的矛盾多方，統籌尋找平衡的解決方法；

週期

在週期現象中，存在事物的發展和演變規律；

即事物在運動、變化的發展過程中，某些特徵多次重複出現；

比較經典的現象就是業務的發展週期：孵化期、驗證期、成長期、成熟期、衰退期、轉型或者消亡期；

理解事物的發展週期，可以在不同的階段把握核心事項，解決關鍵問題；

分治

分而治之是研發的核心能力之一，強調對複雜事物的拆解能力；

隨著技術水平的成長，面對的業務問題也更加複雜，必須具備拆分能力，分而治之；

流程的分段管理；技術與業務的分離；程式碼工程的分層維護；系統的分散式架構；

這些都是研發過程中常用的分治手段；

面對諸多的方法論，首先圍繞幾個基礎方法進行思考和實踐，從而理解其內涵和精髓；

然後，再借鑑其他的方法，形成自己的方法體系；

基於一些核心的方法論之上，再去思考業務和技術的設計，在思路上就會成熟很多；

【如何分析業務】

想要分析業務，首先要深刻的理解和洞察業務整體；

在個人習慣上會考量三個層次：首先理解業務全貌，其次理解負責的業務板塊，最後理解具體的業務需求；

理解業務全貌

理解業務全貌，本質就是明白公司在做什麼，組織架構的共同作業流程，團隊的工作方向；

業務的常規定義：行業的基本模式，運作的流程，具體的事務執行；

在實際的工作中，職級越高越是需要具備對業務全貌的分析能力；

行業分析並非普通玩家所能理解的，需要極其頂級的思維和知識儲備，以及對各個資訊的統籌分析；

作為研發來說；

應該理解業務的投入和營收，並且能意識到這種模式是對映到產品設計或者服務中的；

必須理解業務模式所對應的產品矩陣設計，各個核心功能的流程和路徑；

理解負責的業務板塊

個人的工作習慣，並不是常規的流程機制；

明確自己負責的業務板塊，把握工作重心，不同階段中調整能力的輸入（學習）和輸出（生產價值）策略；

產品矩陣的設計與業務模式有直接關係，也是梳理自己工作板塊的核心依據；

對於產品來說，常見的拆分有兩種；

例如以埠為依據劃分的C端和B端，以系統為依據劃分的業務應用和資料應用；

對於業務來說，拆分的模式則更加靈活；

在運營概念上可能有多個業務線，但是對於研發來說，各種業務線之間存在諸多的流程互動；

對於個人來說，可以從業務、技術、資料三個基礎的方向梳理，或者根據具體的運營模式梳理；

理解業務全貌和個人的負責板塊，以此明確工作重心和方向；

理解具體的業務需求

理順業務全貌與自己負責板塊，更偏向於內在的務虛方向；

研發對於職場的真正價值，還是在於各個版本的具體需求實現；

分析具體的業務需求時，依然有一個對齊的過程；

將具體的業務需求向業務全貌對齊，理解其價值所在；

將業務需求向自己的工作板塊對齊，理解自己的價值所在；

實現版本的業務需求，既要對齊大的業務框架，也要理清需求本身，把握版本落地的質量；

【理解技術架構的演進】

對於技術規劃來說，通常分為：業務和技術兩個方向；

可以分析一個複雜系統的迭代過程，從而理解技術方案在規劃設計上的演變規律；

橫向擴充套件

從架構的概念來描述：單服務、叢集模式、分散式服務、系統級分拆；

橫向擴充套件，其對映的是業務流程和模式的複雜度，隨著業務的不同發展階段，需要進行不同級別的服務拆分；

縱向擴充套件

從單個系統架構的縱向來分析：展現層、應用層、業務層、元件層、儲存層；

縱向深入，其對映的是業務邏輯的複雜度，在縱向上進行分層設計，可以降低邏輯管理的難度；

業務研發

基於常規的分散式系統來看，業務研發在演變的過程中，也會拆分為應用級業務，公共業務兩大板塊；

應用業務實現的是具體需求場景，而公共業務則是大多數應用都依賴的基礎業務能力；

技術研發

基於常規的分散式系統來看，合理的架構設計，必然會追求技術與業務的分離；

在程式碼工程的分包上，可以獨立封裝技術層面的元件應用，以便於統一維護和升級；

在服務級別上，可以將元件服務拆分為業務（側重業務解決方案）與技術（側重技術解決方案）兩個層次；

分析業務，把握技術架構的演進歷程，將二者進行統籌結合，就是方案設計的主線；

【統籌技術和業務方案】

設計研發方案，自然需要把握業務的整體，規劃技術架構，確保業務和技術雙線推進；

方案的核心則是圍繞當前階段的具體業務需求，設計實現流程、目標、指標；

業務和技術的演進

分別把握整體與階段的核心目標，作為方案設計的基礎指導原則；

從業務整體上看，系統建設與技術架構應該圍繞大的業務目標去考量，支撐或者驅動業務發展；

從業務階段上看，把握當前階段的業務本質，關鍵問題與核心矛盾，在版本需求中有序解決；

業務和技術的流程

分析業務的運轉流程和特徵，對映為技術的實現過程，作為方案設計的核心思想；

業務的運轉流程，圍繞客戶、產品、組織共同作業來設計，側重於場景的分析；

業務對映的系統流程，將業務流程和特徵轉化為系統實現的流程，側重於兩者的統籌分析；

核心邏輯的實現流程，圍繞具體需求，設計邏輯時序圖，側重於關鍵問題的分析；

業務和技術的目標

圍繞具體需求，設定相應的目標和指標拆解，作為方案執行結果的考量標準；

版本需求立項之時，就對結果有明確的預期，目標貫穿業務需求的完整週期，在組織共同作業中是關鍵導向；

指標用來衡量目標達成的執行過程和最終完成度，側重於對目標進行驗證；

綜合來看，對於業務和技術的方案來說；

有業務的整體思考，技術的系統性架構，具體需求的核心設計與落地執行，以及目標和指標的衡量標準；

最後，回到工作實踐中來，做事雖然有很多方式方法，但是從來沒有絕對的標準；

業務也好，技術也罷；

在週期演進的過程中，始終受到組織架構和團隊人員的最根本影響；

所以在輸出業務和技術方案時，要圍繞環境的真實現狀，做出相應的調整優化，把握核心即可；