結構化的思考、做事、成長

作者 | 承風

引言

在每年自評、彙報、工作中總會感受到一些結構化帶來的問題：

老闆問我當前做的事情怎麼樣了，我講了合作中的難點、視覺風格問題、業務情況、代碼質量。。。工作的進展，說了半小時，老闆還是get不到我做的事情的情況和價值。是老闆不在意這件事、還是我語言表達能力不行？
我這一年做了很多事情，都有一定產出，但是跳出細節來看，發現對業務、對團隊價值都不大。是我做得不好、還是運氣不好做的事情不好？
最近流行codeless，我打算研究下可視化搭建；團隊業務涉及到流程編排，我打算研究下TMF。。。一年下來折騰了不少成果出來，似乎老闆也沒有很認可。是我不討老闆喜歡還是做的事情沒價值？

這些問題，根據我自己工作經驗的總結，認為大都是對結構化認知不足和踐行不佳導致的。

第一個問題：對事情的認知和表述結構化方面存在問題 - 結構化的思維相關問題
第二個問題：做事兒多而雜不成體系 - 結構化的工作模式問題
第三個問題：學習和成長缺乏重點 - 結構化的能力建設的問題

建立結構化的思維，以結構化的模式驅動工作，以結構化的體系構建自身的能力，小到寫PPT、大到為業務提供更大價值，都是非常值得我們使用的模式。

阿里巴巴數字供應鏈事業部高級前端技術專家，承風，為大家分享他在建立和踐行結構化思維過程中的方法論。

關於結構化

Structured：建立中心（問題、目標）。以中心的核心要素對中心進行分解，形成分類子結構。以一定的範式、流程順序進行分類子結構的合理分類、減少非關鍵分類結構；對關鍵分類子結構進行分析，尋找對策，制訂行動計劃。

同理，逆向的順序，對多種雜亂的內容，進行分類、剪枝、歸納彙總成一箇中心。我認為也是結構化。

有很多相關的書籍：

領導者之劍:成功人士的5大突破思維技巧、金字塔原理、極簡思考:來自世界頂尖諮詢公司的高效工作法。。。

也可以參看很多結構化的應用方式：結構化面試、結構化金融產品設計、結構化系統開發方法。。。從多行業多領域的使用可以反思和加深自己的認知。

在工作中認知和踐行結構化

結構化的理論是簡單清晰的（道的層面總是比較簡潔），但實際應用中如何進行結構化、最有效的使用結構化卻有很多經驗（術的層面總是多變的）。在此結合我個人的經驗給出一些建議：

建立中心

當我們接手一個業務需求、面對一項挑戰的時候，應當先思考這個需求的核心目標是幹嘛的。

結構化的建立中心

思考的過程也是結構化的，我通常會分解為兩個子結構進行

這個業務需求當前的目標是什麼。（事的維度）
- 目標是快速完成上線試一試業務效果：目標事的維度為高效穩定上線。
- 目標是建立後續業務鋪開的基礎方案：目標事的維度是強架構設計下的核心與功能拆分方案。
為什麼需要我來做。（人的維度）
- 是因為我工作量還有buffer所有承擔這部分：目標人的維度是完成職能範疇內的工作。
- 是因為我在這方面技術比較擅長：目標人的維度是利用事情強化自身能力和使用能力把事兒做好。

沿中心上行

對單個業務需求而言，從事、人兩個維度建立起的中心即其核心，是最主要部分，建立一顆結構樹的基礎。但我們不應當停止於此，還應當向上推導：這個需求在整個業務的範疇內，是在哪一層次，哪一分類的。即應當更高層面、或整體業務和行業發展，對這方面業務是怎樣的期許。（價值的維度）

一個團隊接手某項業務或需求，其背後都會有思考。我們是期望藉著這個業務打造一個平臺，提升整體行業的表現；還是突擊這個業務方向，佔領局部的商業藍海。。。
接到一個需求時一定要思考更大層面這事的價值，才能更好的判斷優先級、做事模式。

例如：我們做採購系統，當前需求是，提供採購單列表，按總價範疇搜索單據的能力。按結構化的中心建立，它是：高效穩定上線（事）、我職能範圍內的工作（人）。

如果止步於單個需求建立的中心，我們後續的分解應當是如何快速搞定、如何更穩定。。。
如果我們繼續向上構建樹，我們可以和產品、使用者深度溝通下為什麼要做價格搜索
- 管理員期望能看到高價訂單的情況。那麼這個需求的上一個中心節點應當是：管理提效。
- 繼續向上，是基於什麼原因需要做管理提效？因為防止貪腐、提高工作效率。那麼上一個中心節點應當是：降低成本。
- 依次向上，直到抵達整個業務的目標。比如總結覺得，我們的業務是構建一個集成高效的集團採購系統。
再以此反思：
- 降低成本是不是當前工作的重點？團隊是否有足夠的架構設計和人員組織來支撐？
- 下一步到到管理提效層面，訂單的搜索是否真的是當前最佳的提效工具，因為用戶如何定義高價格？他執行這種搜索式查閱工作是否真的是有效不遺漏的？查閱到了訂單有問題他能做什麼？。。。我們會發現這個需求背後更多的問題。我們也可以沿著更大的中心樹，去思考是否構建更好的方案可以更根本的解決這個問題。
再回過頭來看當前的任務，是否真的是高效穩定上線（事）、我職能範圍內的工作（人）。或者當前最緊急的部分（用戶直接需求嘛）是高效穩定上線（事）、我職能範圍內的工作（人），但後續更要做更多的其他的根本性解決方案。

沿當前的中心向上建立更大的結構化的認知體系

會讓我們對當前事情的判斷（中心）更加清晰，也有更好的認知基礎，極有利於與合作方的溝通碰撞和內容創新。
建立更大結構化認知體系的過程，也是深入業務、擴展認知力的過程。一定要多和老闆、業務方交流，從各自認知的差異性上提升自身的認知能力。

此外，構建更大認知體系，對個人和團隊發展也是有價值的

很多時候我們忙於業務實現，都沒有花時間去思考業務的價值。一部分是因為忙，一部分是因為懶，一部分是因為不懂，一部分是因為我們是來做事拿工資的，而不是帶著願景想把事做好的。這都不是真正能把事情做好的方式。
作為團隊的一員，我們不應當只做“花時間、生雞蛋”的極低人效、技術外包的母雞模式，而應當積極的嘗試做“建機器、鋪廠房、出產品”的工廠模式。這對業務和個人的發展才是積極的作用。

中心的分解

建立完成中心後，有多種對中心進行分解的方式。其目標在於將中心拆解為多個內聚的子部分。整體思想是MECE（Mutually Exclusive Collectively Exhaustive）原則，即相互獨立，完全窮盡不重疊、不遺漏的分類。夠藉此有效把握問題的核心，併成為有效解決問題的方法。

一些分解方案的簡介

SWOT
SWOT分析方法又稱態勢分析法：即Strengths 優勢 / Weaknesses 劣勢 / Opportunities 機會 / Threats威脅四類。最早用於進行企業競爭態勢分析，對個人而言用於分析自身的競爭態勢也是極佳的。

（如圖，對團隊數據可視化能力建設的SWOT分析示例）

SWOT分析法四個象限可以分別分類四大獨立的方面，而其中SW部分 - 優勢劣勢一般用於分析內部條件；OT部分 - 機會威脅一般用於分析外部情況。又形成了兩個獨立而全覆蓋的大類分隔。非常有助於看清楚當前的情況。

此外，SWOT形成的象限又可以結合跨大類進行組合分析

SO的關聯部分，是我們做事的重點，重要緊急的。比如Node+可視化能力 =》我們可以構建基礎平臺。
WO相關的部分，是我們必須解決的，很多情況下是我們需要進行專享突破式學習的內容。比如圖形學 + 基礎框架 =》如果我們要做基礎框架這個機會，那麼必須補全圖形學相關知識。
WT部分是威脅到這件事或者成長的部分，必須重視、避免、糾正。比如圖形學 + 多公司發力基礎框架 =》如果我們沒有基礎框架基礎沉澱，又缺乏圖形學相關學習目標或者相關引導，那麼我們就應當放棄做基礎框架。
ST部分是我們直面競爭的部分，如何發揮自身優勢去面對威脅，需要有相關的抓手。比如Node + 成體系的ISV =》ISV肯定會在系統化建設上發力，我們必須使用node的基礎能力提供更加靈活高效的解決方案。

AHP
AHP分析方法又稱層次分析法：Analytic Hierarchy Process，將與決策總是有關的元素分解成目標、準則、方案等層次，在此基礎之上進行定性和定量分析的決策方法。它是一種定性&定量結合，系統化&層次化的分析方法。

第一層是目標，第二層是分解的準則，第三層是實施方案。構建A1...A5與目標相關權重，形成構造判斷(成對比較)矩陣。對矩陣進行層次單排序及其一致性檢驗，再計算B1....B3層總排序權值和一致性檢驗，按照權重結果進行方案優先級的判斷。更多詳細計算內容可參考MBALib。

我們在實際使用中有兩種方式：

以層次建模的模式，對核心目標進行有效分解。即如果某一類分解，無法被賦予權重，則不是一個有效的分解。
根據層次分析建模，對當前事情優先級進行決策。在實際應用中我們即便不去精確計算權重，至少按此結構看各個工作目標與分解的相關性，亦是一種指導。

進行分解的順序邏輯
中心的分解應當使用流程化思維。指的是找出事情發生的內在邏輯，思考的時候可以邏輯順序作為參考。

時間順序：中心執行的步驟、流程等。
結構順序：中心的空間、地理位置、內部外部條件等。
程度順序：中心的輕重緩急、重要性等。
。。。

以XMind為例

（規劃的時間順序分解）

（按相關性進行結構順序分解）

（按照重要性即與魚頭的距離進行程度結構分解）

按照哪種順序進行分解因個人愛好和事情的不同而不一致，沒有優劣之分只有合適不合適。多加應用多做嘗試不同模式，會不斷提升自身思維和行為的邏輯性以更加結構化。

清理

事業是無限的，人力總是有窮、認知高度總是不夠的。我們不能把分析出的所有點都做好，也不是分解出的所有層次都真正有價值的。那麼針對分解的產出物，應當以數據挖掘的物料準備類似的邏輯進行前期處理，來提高效率、去除噪聲。常用的分別為：

泛化：過度細碎的層次應當抽象總結到更高層次，以進行更有效分類。
補漏：針對中心，某些關鍵決策子層級缺失，應當補充完全。
剪枝：針對中心，與中心緊密度關聯較低或無可操作性的部分應當去除，以降低整體分析複雜度。

泛化
例如我們要提高部門的研發效率，日常工作收集了一些反饋：開發環境不穩定天天搶日常部署，jar包衝突屢禁不止，經常有人push origin -f，前後端聯調確定字段巨麻煩，對當前業務webx用起來不夠順手迅速。。。

這些問題都可以歸納到“研發效率提升要解決的點”這個分支下，但細碎的陳列讓對問題的解決顯得沒有重點，後續遇到其他問題也沒辦法進行有效的區分。

泛化一般是這樣的模式：我們有一些用戶年齡，分佈為10、14、35、42、55、72歲。可以抽象成年齡分層 - 青少年（10、14）、中年（35、42）、老年（55、72）。降低數據量提高內聚性。

針對上面的研發效率問題，我們可以按照研發工作的主要方面，泛化相關的問題：對當前業務webx用起來不夠順手迅速（研發架構）；搶日常部署、前後端聯調（研發環境）、jar包衝突、強制提交（研發態度）。

在結構化中，不是越深、越細的結構是越好的，很多時候越內聚抽象的結構反而更有利於進行後續實操改進工作的開展。

補漏
例如我們要提升前端研發效能。通過調研、學習和思考，認為需要進行幾方面的結構化建設：

高效的研發環境
- 極佳的研發工具
- 穩定的研發環境（缺失）
- 可測試和追述的代碼表現
- ...
平臺技術驅動研發
- 核心能力不斷沉澱
- 非核心能力能無侵入的快速定製（缺失）
- ...
合理的團隊人員結構
- ...

進行結構化的梳理可以更清晰的看出針對目標，哪些部分是我們缺失的。因而針對缺失部分的重要性和緊迫程度，可以更合理的安排工作，而非一味的在較強的部分進行優化、或者各種事情東打一槍西放一炮。

同理，對個人技術成長而言，整理針對當前行業發展下當前技術環境下個人能力的要求點，進行結構化分層和缺失標註，也是指明自身學習方向的好手段。

剪枝
在我們進行中心的層層分解時，我們即便做到了歸類，也總會生產一些特別發散的點。針對這些點，我們應當進行非關鍵分類結構的減少，即剪枝過程。

通常需要進行剪枝的部分

是和其餘結構關聯不大的部分
針對當前核心問題是非主要相關的部分
兼顧該部分的成本比產出的效果更大

例如我們要通過只狼，一個牛逼的手柄花費的代價，和其對核心目標的提升是不對等的。如果要兼顧該子結構，可能對自己身體和心理造成更大的負影響，放棄是明智的選擇。

我們在安排自身的學習成長也是類似的，是否需要報個昂貴的視頻課程，是否需要深入研究TMF源代碼，都應當看對當前自身的學習目標的結合度、性價比來做決策，是去是留。

結構化中，要果斷剪枝，保持專注、保持可行性。

小結

結構化是一個非常簡潔的理論


建立中心；

以中心的核心要素對中心進行分解，形成分類子結構；

以一定的範式、流程順序進行分類子結構的合理分類、減少非關鍵分類結構；

對關鍵分類子結構進行分析，尋找對策，制訂行動計劃。

我們在思考、做事、成長時應當隨時使用，對於梳理複雜問題、進行決策支撐都有很大好處。

最後回答下最開始的問題：

老闆問我當前做的事情怎麼樣了，我講了合作中的難點、視覺風格問題、業務情況、代碼質量。。。工作的進展，說了半小時，老闆還是get不到我做的事情的情況和價值：按照事情核心目標的達成情況，各子部分重點問題和解進行結構化的講述，兩分鐘說清楚。

我這一年做了很多事情，都有一定產出，但是跳出細節來看，發現對業務、對團隊價值都不大：先建立團隊當前業務的核心目標，分解目標達成所需的各個部分，自身努力在某個部分上做深，或者補全當前缺少的部分，或者強力推進將團隊目標向上拔高一層更大的目標。

最近流行codeless，我打算研究下可視化搭建；團隊業務涉及到流程編排，我打算研究下TMF。。。一年下來折騰了不少成果出來，老闆卻不提名我晉升：先確定自身技術能力提升的目標，分解到需要提升的各個部分，針對不同部分向老闆強求從事相關工作、在當前工作內嘗試和深耕，從深入一個部分到橫切一個面的能力提升，晉升自然水到渠成。

關注「Alibaba F2E」
把握阿里巴巴前端新動向

引言