如何看見全貌?

.

0078

專案開始之初,首重看見全貌。但如何看見全貌呢?

.

界定問題 → 構建框架 → 明晰關鍵 效執行 → 檢查調整

 一般的解題步驟

運用一般的解題步驟 + 系統思維 (繪製抽象圖示,再做成個別的簡明 PPT ,最後才是寫成明確的文字稿)

我的解題方式

.

運用系統思維 System Thinking

基於一般的解題步驟,在加入系統思維。要做系統思維,當然是從分析系統開始,只是系統分析(system analysis)這個字眼早就被軟體工程給用掉了,所以如果你想深入探詢系統思維的系統分析方法的話,建議由閱讀麥肯錫顧問公司 McKinsey & Company 的思考解題法開始(註1,系統思維是一種思維的方法,但軟體工程裡的系統分析卻經常把設計涵概了進來,即便是用在軟體開發上頭,也會覺得實在不像是在做系統分析。所以建議你去走一趟麥肯錫顧問公司思考解題法)。

.

如果無法適切的表達出來,你又怎麼能確定自己看見了全貌。

.

要看清全貌,首先要有正確的邏輯思維

正確的邏輯思維必須具有規範、嚴密、確定和可重覆的特點,因為演講的關係我比較在意順序性(演繹性;學員由前一張PPT『前提』的已知事實,『必然地』得出的推理 )。他是人腦的一種理性活動,思維主體把感性認識階段獲得的對於事物認識的信息抽象成一種概念,然後在運用概念來進行判斷,並依此關係進行推理,從而產生新的認識。所以正確的表達出來,讓他人(學員)也可以獲得相同的認知才能確認這個全貌(所謂的專案的全貌,時間的因素也是不能忽略的特性,因此這個全貌只能描繪成當時的全貌,這便是系統思維動態的特性)。我的演講習慣是先運用圖示的方式讓聽眾抽象的看見演講的全貌,然後才按部就班地開始講演。

.

適切的表達出來才是比較難的部分,也是拿來驗證邏輯思維是否正確的好方法。但問題來了,你要用什麼方式來表達呢? 我一向用圖示的方式,把思維畫出來,然後再轉成文字描述。因為身為講師,這也是我準備課程時的方式,也就是先對課程做一幅圖示,然後再分解成片段的 PPT檔,最後在演講前才訴諸成文字的描述。

.

步驟如下:

解題

解決課程題目的步驟

.

範例 1: 題目是 「打開DevOps的后門」,此為2019 年 10/16 的 DevOpsDays 演講

0086

由 1~ 8 的八個不同主題

演講部分: 應該可以在大會釋出的影片上找到(或 youtube)。我演講的習慣是先運用圖示的方式讓聽眾抽象的看見演講的全貌,然後才是按部就班地開始講演。也正是自己解題的過程,這是依循費曼先生所謂的教學相長的方式而來。至於沒講完的事實,就推給時間不夠的現實場景囉!

.

範例 2. 演講敏捷開發 Scrum的動態圖示

0025

演講部分: 這是一份動畫圖示請參考

.

圖片 005

如何解讀看板?

.

避免偏見

Chris Argyris 克里斯·阿吉里斯跟我們說: 人類有自己編撰故事然後再自圓其說的傾向。也就是系統思維裡著名的「左手欄」誤解。為了避免對看板有錯誤的解讀,有一種 D.I.E 模式可以運用。首先;就自己所看見的進行描述 Description(思考的方式是;這是什麼? 也就是試著描述自己看見了什麼) ,然後進入解說階斷Interpretation(也就是站在團隊的立場思考,這對他們意味著什麼?),接著才試著做出評價 Evaluation(也就是對你而言這意味著什麼?)

當沒有我們沒有採用 D.I.E模式就直覺式的反饋出來時,自己的偏見跟引起別人誤解的偏見便容易油然而生(請參考心理思維的卡普曼三角)。

 

註 1.

一、《金字塔原理》-Barbara Minto

該書是麥肯錫有關商業思考、表達與寫作邏輯的經典培訓教材,作者Barbara Minto是麥肯錫公司的第一位女性諮詢顧問,後致力於向商業人士傳授金字塔原理。這本書為我們總結了一套結構化思考的模型和方法。

二、《麥肯錫方法》

以「金字塔原理」為基礎,《麥肯錫學院三部曲》某種程度上可以看作是對麥肯錫公司邏輯思維體系的具體運用及總結擴充。

三、《麥肯錫意識》

麥肯錫意識則是在《麥肯錫方法》的基礎上,再具體針對解決問題這一重要領域提出了一套結構化的實施模型。

四、《麥肯錫工具》

針對如何解題提出了另一套「TEAM-FOCUS」實施模型,完全是實戰案例的形式。

五、大前研一,思考的技術

大前研一 最具影響力的著作,本書的目的是要提供在這個新世界中的 business man生存下去的必要商業思考方法,向讀者傳達培養這個思考途徑的 know how。

我覺得他是教導讀者正確的邏輯思考方法的好著作。

建議由基礎的《金字塔原理》(The Minto Pyramid Principle) 閱讀到大前研一的《思考的技術》一系列顧問叢書案需要閱讀,學習起來會明確、紮實些。

.

看見全貌之後,接著就該知道自己在哪裡?

0079

知道自己距離目標有多遠.

.

看見全貌

.

專案開始之初,首重看見全貌。

一旦;當你把眼光投注在哪一個要項的時候,實際上你就只看到那一部分,你的思緒將被那一部分的內容所牽動,很難再看見其他的事…

所以我們要退後一步,

不! 有時要退後很多步,才能比較清晰地看見全貌。

(好有趣喔! 退遠了卻反而看得更清晰)

所以要調整範圍,試圖把我們在意的事放進視線可及之處,

淡淡的審視它,不帶一點情緒,就是這樣,我們看見了全貌。

.

開發團隊被抱怨開發速度太慢的案例層出不窮…

0054.png

軟體影響開發速度的因素

其實當你努力的去改善開發環境還有程式,祈求開發速度能夠跟上需求時,其實;還不如從提升需求的業務價值來著手改進會快上很多,請參考"需求分析的設計模式“一文。

.

一旦你看見全貌之後,要怎麼做呢? 

一種全貌.png

演講內容:  DevOps 教战守策:三步工作法 ,內容 PPT 的全貌( XPS展示)

首先;把它畫下來。畫下來不論對自己或閱讀的人都是一種極具價值的事。(上面81張slides的內容如下圖)

.

0002_8

將演講內容整理成 圖示 (演講: DevOps 教战守策:三步工作法 )

畫出來;可以具像化(產生 Avatar)的整理出資料的脈絡,告訴學員運用圖示來回憶上課的內容,當遇到有疑惑的地方時再去細看 PPT的內容會效果會更好。

.

see the whole
整理出來的心得

.

運用工具來協助你看見全貌

系統思維(麻省理工Jay Wright Forrester先生的 System Thinking)能夠協助你以CLD圖式較抽像的方式看見全貌。坊間流行的影響地圖(impact mapping, by: Gojko Adzic )是用來尋找影響路徑,還有著名的是用戶故事地圖(user story mapping, by: Jeff Pattorn 用來記錄陳列需求)則都是用來記錄分析需求的有用工具,但基本上還是屬基於以客戶為導向的開發工具, 這二者還是離不開描述個別客戶的情境示意圖,對看見全貌而言反到狹窄了視野,它記錄的是專案運行下的各個需求分類,已經自我設限而失去了真正的全貌,反倒能夠協助收斂思維便利施工作業,而非全貌探索。

 

.

註:

  • 拉遠原則 (Pulling principle) 

就是在更大的範圍內觀察事物。我們可以試著將一個產品放置在更大的背景環境中去考慮,這樣可以避免見樹不見林的現象。(例如: 坊間一些書籍的試讀軟體,就有這種效果。) 雖然我們這麼去觀察,但還是只看到它的外觀,好的作品,設計者的品味(taste) 卻還是能隱然呈現,尤其是那些優秀的產品。至於內涵的部分,就需要細細的去品味了。

.