阿里高級技術專家:如何結構化地思考、作事、成長?

簡介: 7月9日 19:00-21:30 阿里雲開發者社區首場「Offer 5000」直播開啓!15位團隊技術大牛在線招人,更有《阿里雲技術面試紅寶書》助你拿下Offer!立刻投遞簡歷:https://developer.aliyun.com/...前端

圖片沒法顯
1.png

做者 | 承風 阿里巴巴高級前端技術專家node

導讀:創建結構化的思惟,以結構化的模式驅動工做,以結構化的體系構建自身的能力,小到寫 PPT、大到爲業務提供更大價值,都是很是值得咱們使用的模式。阿里巴巴數字供應鏈事業部高級前端技術專家 - 承風,將會在本文中和你們分享他在創建和踐行結構化思惟過程當中的方法論。web

引言

在每一年自評、彙報、工做中總會感覺到一些結構化帶來的問題:面試

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

這些問題,根據我本身工做經驗的總結,認爲大都是對結構化認知不足和踐行不佳致使的。後端

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

關於結構化

Structured:創建中心(問題、目標)。以中心的核心要素對中心進行分解,造成分類子結構。以必定的範式、流程順序進行分類子結構的合理分類、減小非關鍵分類結構;對關鍵分類子結構進行分析,尋找對策,制訂行動計劃。架構

同理,逆向的順序,對多種雜亂的內容,進行分類、剪枝、概括彙總成一箇中心。我認爲也是結構化。框架

有不少相關的書籍:less

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

也能夠參看不少結構化的應用方式:結構化面試、結構化金融產品設計、結構化系統開發方法······從多行業多領域的使用能夠反思和加深本身的認知。學習

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

結構化的理論是簡單清晰的(道的層面老是比較簡潔),但實際應用中如何進行結構化、最有效的使用結構化卻有不少經驗(術的層面老是多變的)。在此結合我我的的經驗給出一些建議:

1. 創建中心

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

1)結構化的創建中心

思考的過程也是結構化的,我一般會分解爲兩個子結構進行:

  • 這個業務需求當前的目標是什麼(事的維度):1. 目標是快速完成上線試一試業務效果:目標事的維度爲高效穩定上線;2. 目標是創建後續業務鋪開的基礎方案:目標事的維度是強架構設計下的核心與功能拆分方案;
  • 爲何須要我來作(人的維度):1. 是由於我工做量還有 buffer 全部承擔這部分:目標人的維度是完成職能範疇內的工做;2. 是由於我在這方面技術比較擅長:目標人的維度是利用事情強化自身能力和使用能力把事兒作好。

2)沿中心上行

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

  • 一個團隊接手某項業務或需求,其背後都會有思考:咱們是指望藉着這個業務打造一個平臺,提高總體行業的表現;仍是突擊這個業務方向,佔領局部的商業藍海······
  • 接到一個需求時必定要思考更大層面這事的價值,才能更好的判斷優先級、作事模式。

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

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

2.png

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

  • 會讓咱們對當前事情的判斷(中心)更加清晰,也有更好的認知基礎,極有利於與合做方的溝通碰撞和內容創新;
  • 創建更大結構化認知體系的過程,也是深刻業務、擴展認知力的過程。必定要多和老闆、業務方交流,從各自認知的差別性上提高自身的認知能力。

此外,構建更大認知體系,對我的和團隊發展也是有價值的。

  • 不少時候咱們忙於業務實現,都沒有花時間去思考業務的價值。一部分是由於忙,一部分是由於懶,一部分是由於不懂,一部分是由於咱們是來作事拿工資的,而不是帶着願景想把事作好的。這都不是真正能把事情作好的方式;
  • 做爲團隊的一員,咱們不該當只作「花時間、生雞蛋」的極低人效、技術外包的母雞模式,而應當積極的嘗試作「建機器、鋪廠房、出產品」的工廠模式。這對業務和我的的發展纔是積極的做用。

2. 中心的分解

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

下文是一些分解方案的簡介。

1)SWOT

SWOT 分析方法又稱態勢分析法:即 Strengths(優點)、Weaknesses(劣勢)、Opportunities(機會)、Threats(威脅)四類。最先用於進行企業競爭態勢分析,對我的而言用於分析自身的競爭態勢也是極佳的。

3.png

(對團隊數據可視化能力建設的 SWOT 分析示例)

SWOT 分析法四個象限能夠分別分類四大獨立的方面,而其中 SW 部分 - 優點劣勢通常用於分析內部條件;OT 部分 - 機會威脅通常用於分析外部狀況。又造成了兩個獨立而全覆蓋的大類分隔。很是有助於看清楚當前的狀況。

此外,SWOT 造成的象限又能夠結合跨大類進行組合分析:

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

2)AHP

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

4.png

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

咱們在實際使用中有兩種方式:

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

3)進行分解的順序邏輯

中心的分解應當使用流程化思惟。指的是找出事情發生的內在邏輯,思考的時候能夠邏輯順序做爲參考。

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

以 XMind 爲例:

5.png

(規劃的時間順序分解)

6.png

(按相關性進行結構順序分解)
7.png

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

按照哪一種順序進行分解因我的愛好和事情的不一樣而不一致,沒有優劣之分只有合適不合適。多加應用多作嘗試不一樣模式,會不斷提高自身思惟和行爲的邏輯性以更加結構化。

3. 清理

事業是無限的,人力老是有窮、認知高度老是不夠的。咱們不能把分析出的全部點都作好,也不是分解出的全部層次都真正有價值的。那麼針對分解的產出物,應當以數據挖掘的物料準備相似的邏輯進行前期處理,來提升效率、去除噪聲。經常使用的分別爲:

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

1)泛化

例如咱們要提升部門的研發效率,平常工做收集了一些反饋:開發環境不穩定每天搶平常部署,jar 包衝突屢禁不止,常常有人 push origin -f,先後端聯調肯定字段巨麻煩,對當前業務 webx 用起來不夠順手迅速······

這些問題均可以概括到「研發效率提高要解決的點」這個分支下,但細碎的陳列讓對問題的解決顯得沒有重點,後續遇到其餘問題也沒辦法進行有效的區分。

泛化通常是這樣的模式:咱們有一些用戶年齡,分佈爲 十、1四、3五、4二、5五、72 歲。能夠抽象成年齡分層 - 青少年(十、14)、中年(3五、42)、老年(5五、72),下降數據量提升內聚性。

針對上面的研發效率問題,咱們能夠按照研發工做的主要方面,泛化相關的問題:對當前業務 webx 用起來不夠順手迅速(研發架構);搶平常部署、先後端聯調(研發環境)、jar 包衝突、強制提交(研發態度)。

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

2)補漏

例如咱們要提高前端研發效能。經過調研、學習和思考,認爲須要進行幾方面的結構化建設:

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

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

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

3)剪枝

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

8.png

一般須要進行剪枝的部分:

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

例如咱們要通關只狼,一個牛逼的手柄花費的代價,和其對核心目標的提高是不對等的。若是要兼顧該子結構,可能對本身身體和心理形成更大的負影響,放棄是明智的選擇。

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

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

小結

結構化是一個很是簡潔的理論:

創建中心;
以中心的核心要素對中心進行分解,造成分類子結構;
以必定的範式、流程順序進行分類子結構的合理分類、減小非關鍵分類結構;
對關鍵分類子結構進行分析,尋找對策,制訂行動計劃。

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

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

  • 老闆問我當前作的事情怎麼樣了,我講了合做中的難點、視覺風格問題、業務狀況、代碼質量······工做的進展,說了半小時,老闆仍是 get 不到我作的事情的狀況和價值:按照事情核心目標的達成狀況,各子部分重點問題和解進行結構化的講述,兩分鐘說清楚;
  • 我這一年作了不少事情,都有必定產出,可是跳出細節來看,發現對業務、對團隊價值都不大:先創建團隊當前業務的核心目標,分解目標達成所需的各個部分,自身努力在某個部分上作深,或者補全當前缺乏的部分,或者強力推動將團隊目標向上拔高一層更大的目標。
  • 最近流行 codeless,我打算研究下可視化搭建;團隊業務涉及到流程編排,我打算研究下 TMF······一年下來折騰了很多成果出來,老闆卻不提名我晉升:先肯定自身技術能力提高的目標,分解到須要提高的各個部分,針對不一樣部分向老闆強求從事相關工做、在當前工做內嘗試和深耕,從深刻一個部分到橫切一個面的能力提高,晉升天然水到渠成。
相關文章
相關標籤/搜索