> 三天研發，兩天設計；

# 01

【優先做設計方案】

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

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

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

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

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

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

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

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

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

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

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

# 02

【常用的方法論總結】

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

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

- **本質**：

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

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

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

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

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

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

- **矛盾**

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

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

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

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

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

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

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

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

- **系統**

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

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

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

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

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

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

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

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

- **週期**

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

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

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

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

- **分治**

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

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

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

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

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

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

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

# 03

【如何分析業務】

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

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

- **理解業務全貌**

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

![](http://img.blog.itpub.net/blog/2023/02/09/4c94cc14f3828e5c.png?x-oss-process=style/bb)

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

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

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

作為研發來說；

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

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

- **理解負責的業務板塊**

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

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

![](http://img.blog.itpub.net/blog/2023/02/09/f0c79a29342c1286.png?x-oss-process=style/bb)

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

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

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

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

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

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

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

- **理解具體的業務需求**

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

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

![](http://img.blog.itpub.net/blog/2023/02/09/fc9feacc947dc79b.png?x-oss-process=style/bb)

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

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

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

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

# 04

【理解技術架構的演進】

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

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

- **橫向擴充套件**

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

![](http://img.blog.itpub.net/blog/2023/02/09/5f2a909cec22dbd2.png?x-oss-process=style/bb)

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

- **縱向擴充套件**

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

![](http://img.blog.itpub.net/blog/2023/02/09/16d0a05ceab6e067.png?x-oss-process=style/bb)

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

- **業務研發**

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

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

- **技術研發**

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

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

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

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

# 05

【統籌技術和業務方案】

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

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

![](http://img.blog.itpub.net/blog/2023/02/09/373ce4ac2244e5eb.png?x-oss-process=style/bb)

- **業務和技術的演進**

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

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

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

- **業務和技術的流程**

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

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

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

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

- **業務和技術的目標**

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

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

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

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

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

# 06

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

業務也好，技術也罷；

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

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

**Gitee主頁**： https://gitee.com/cicadasmile/butte-java-note

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

相關文章