01

【優先做設計方案】

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

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

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

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

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

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

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

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

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

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

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

02

【常用的方法論總結】

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

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

• 本質：

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

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

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

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

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

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

• 矛盾

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

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

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

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

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

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

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

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

• 系統

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

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

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

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

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

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

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

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

• 周期

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

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

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

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

• 分治

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

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

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

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

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

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

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

03

【如何分析業務】

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

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

• 理解業務全貌

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

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

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

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

作為研發來說；

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

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

• 理解負責的業務板塊

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

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

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

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

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

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

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

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

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

• 理解具體的業務需求

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

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

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

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

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

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

04

【理解技術架構的演進】

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

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

• 橫向擴展

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

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

• 縱向擴展

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

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

• 業務研發

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

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

• 技術研發

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

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

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

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

05

【統籌技術和業務方案】

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

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

• 業務和技術的演進

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

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

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

• 業務和技術的流程

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

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

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

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

• 業務和技術的目標

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

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

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

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

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

06

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

業務也好，技術也罷；

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

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