DevOps的邏輯思維與技術

正確實踐DevOps的方法,是先知道自己在哪裡,再設定目標並運用持續改善來達成它。

-符合邏輯的思考

.

0046

DevOps是解決软件开发人员IT运维人员之间的 沟通問題

.

DevOps的定義:

一种重视「软件开发人员」和「IT运维人员」之间 沟通 合作的文化、运动或惯例。也就是解決软件开发人员IT运维人员之间的 沟通問題。

實行DevOs就是在解決組織內溝通的問題,若是溝通順暢了,開發自然變快、運維也就自然的順暢起來,而發布時間也就一直在加速了!

.

0028

演講題目詮釋;我將用一個顧問的角度來看 DevOps.

.

講這個題目的原委

因為推廣DevOps的關係,連續講了幾年的系統思考System Thinking。始終有一種看不見效果的感覺,一種只看見自己的病但別人都無感的現象,學員們到底獲得了什麼,始終讓人存疑?最近;在一場讀書會(研讀的是唐內拉‧梅多斯系統思維)裡突然感覺到這是邏輯思維不夠清楚的問題;才導致大家研究了半天的系統思維卻問題多多。其實是沒能清晰的辨識系統的基本組成元素(元素、連接及目標;組成系統的三要素)所致,自然無法深入去分析系統的運作方式。從基本元素element開始就弄不清楚了,所以;應該從這裡下手也就是奠定邏輯思考的能力。避免由於對邏輯思考上的不足,導致無法順利進入系統思維的領域,所以才想到這個題目: DevOps的邏輯思考與技術

.

0071

從邏輯思考的誤區開始說起,並參考麥肯錫的思維系列文件

 

.

0033

在多變的世界裡要能看見全貌是一種奢望,但它是實踐系統思維的一部份。

.

0035

追求由 Doing DevOps進化到 Being DevOps.

.0035_01

 

團隊成員具有清晰良好的邏輯思維,對團隊內部溝通無礙間接促成組織展現良好系統思維的基礎。

.

0036

對演講內容,做一下概要總結.

.

0035

看見全貌之後首先要衡量自己在哪裡? 如此才能知道自己距離目標有多遠.

.

0038

我們在哪裡決定你在實行哪一種 DevOps的策略.

.

0037

敏捷運用小增量、迭代與反饋來協助客戶解決問題.

.

0039

DevOps 的目的在能夠更快速地提供客戶穩定的產品功能.

.

0042

進行溝通時不可或缺的清晰邏輯.

.

造成溝通不良的主要原因是;模糊的前言與跳躍、不連續的思考方式。

.

0041

以一個專業顧問(麥肯錫公司)的角度來審視如何實施DevOps.

.

0044

其實DevOps在解決 IT 跟開發人員的溝通問題.但大家卻把注意力都放在 Doing DevOps上,反而很少人能做到 Being DevOps.

.

未命名

這裡要談的是「」的問題,也就是成功溝通的邏輯思考的問題.

.

0045

溝通就像在玩傳接球的遊戲一般,只是球被換成了訊息.

.

0045_01

良好的溝通通常都會有三個基本要素: 清晰的問題具體的答案可以期待的行為反應或理解。

.

0046

團隊存在DevOps中的位置決定著即將面臨的障礙.

.

0029

目前你的團隊正在遭遇哪一種障礙?

.

0047_01這張圖在描述實體層面上的問題。由右往左;是在描述溝通瓶頸的二個Gap在哪裡,它們相關的物件(需求/發布計畫),我們可以由能夠運用的工具語言看出,發布計畫在這裡缺少了專屬的語言,造成溝通上只有文件化的不利情境。由左往右看;則是先確定你在哪裡呢? 團隊是否已經在運用最下層所提供的工具呢? 還是商未採用,抑或是運用得不順暢,可以加以度量並尋求改善。

.

0048範例: 溝通的誤區 PO to 工程師.

.

0049

範例: 溝通的誤區 開發 to 運維工程師.

.

0049_01

溝通訊息的三要素: 問題答案期待對方的反應

.

0048

探討如何由 Doing DevOps 走到 Being DevOps.

.

0051

你是在Doing DevOps 還是 Being DevOps.

追求更快速的開發只是 Doing DevOps,為客戶適時的發掘與更新問題才是 Being DevOps.

.

0052

由 Doing Agile 談起.

.

0052_01

Lean 是數位化的基石.

.

0051從 Doing Agile 到 Being DevOps 是我們實施 DevOps 的終極目標.

.

0052

運用麥肯錫著名的金字塔理論來審視實行DevOps的邏輯思維.

.

0053快速交付是我們追求的實質目標.

.

0054錐形才是合理的金字塔外觀(需求-開發-維運).

.

0056_01

金字塔背後隱含的是業務的作業項目.

.

0055

進一步;運用持續漸進的螺旋式曲線,更能符合由 Doing(實行) 到 Being(成為)逐步過程,而不是段落式的,先做完一個才再去做另一個. 這正符合敏捷的精神;小增量、多迭代、尋求回饋的模式。

.

0056

一個快速發布的思維模式.

.

0059

.

0058

.

0059

.

0060

.

0061

.

0062

Being DevOps 所該關注的不是發佈有多快速,而是在客戶回饋或是回饋之前就自覺的發布更新.

.

0063

.

0064

.

0065

.

0066

.

0067

.

0068

.

圖片 001

.

0071

.

0003

.

0004

.

0005

.

0006

.

0009

.

0010

.

0008_01

影響地圖是敏捷開發裡最適合業務人員介入的一環

.

0012

.

0013業務帶回客戶需求的同時,衍生出第一個版本的影響地圖,它是影響地圖的發起線,它可能只是一行式的影響地圖,就戲稱它為一行式的影響地圖」.

.

0014

一行式的影響地圖就足以取的展開式的較完整的影響地圖.

.

0014_01

一個有里程碑、有替代方案及事後評估衡量產出數據的影響的圖範例

.

圖片 003

將加強邏輯思考是為欲達成的目標,排列出影響地圖,並對交付做出預估度量

一個理想的影響地圖;應該有設定里程碑,並做到事前預估與事後衡量,並在回顧檢討時考量是否採用替代路徑

.

註: 以上是即將余4/30發表於中國大陸 DevOps線上峰會主會場的一場演講內容.

節錄一下重點:

一、正確的DevOps思維;應該是審視你現在組織的狀態,再去尋求此刻應該克服的既有障礙。

二、由 Doing Agile 走到 Being DevOps,是一種系統思維的方式,它是在客戶回饋或更早之前就自覺的發佈更新的方式。

三、在技術上;藉由麥肯錫顧問公司金字塔原理,以清晰的邏輯思考來克服組織溝通上的障礙。

四、推廣業務敏捷化「一行式的影響地圖」

 

 

 

系統思維下的 DevOps 和 Agile

.

0002

主題: 系統思維之下的 DevOps 與 敏捷

.

0003_01

大家所面對的 DevOps在範圍上都有一些差異,但重點是先知道自己現在在哪裡?

.

0004_01

.

0005

簡單的說明一下系統思維常見的誤區

.

0007

避開誤區的思維方法 – DIE 法則

.

0011_01

總結一下系統思維

.

0012

DevOps vs. Agile

.

0013

參考自 Guru99 網站,我只是做了一下翻譯

.

0013_01

業務、產品部門與開發部門有許多協作的工具

.

0003_02

但運維人士 Ops Guys 缺少一種與大眾溝通的共同語言

.

0016

運維俱有前移與後移的雙向能力,敏捷只有前移功能

.

0021

知道自己現在在哪裡,才能思考該從哪裡開始,因此實踐 DevOps從定位開始

.

0023

不斷的讓自己處於透明、檢核與調適的情境才是應付多變環境的方法

.

0042

讓團隊從看板開始,是一種絕佳的透明方式

.

0043

強調多任務但單工作業的精實七大原則

.

0044

提一下喬梁老弟的持續交付2.0的雙環觀念

.

感觸

從2010年起,我年年參加多種 DevOpsDays 的聚會,卻始終等不到運維人士專屬的共同語言被發明出來,拿它來讓 DevOps 工作運行的更加順暢。雖然這個語言到現在還不見蹤影,但是相信不久的將來一定會有的。

對於需求而言;我們有「使用者故事」User Story可以拿來描繪客戶的種種需求,甚至有影響地圖Impact mapping、用戶故事地圖 User Story map或使用者情境圖來協助分析、製作、探討需求。更有「測試案例」test case、測試計畫來協助開發人員守住程式功能或產品的品質。但至為重要的運維端到目前為止,仍然只有發布計畫Release Plan 來做為溝通的文件,少了一種大家容易溝通的共同語言,讓 Ops運作起來,少了一種融入整個開發到運維的通識協作語言。

.

0013_01

一個好的需求遠遠勝過開發團隊做一大堆無關痛癢的工作

大家都知道;一個好的需求遠遠勝過讓開發團隊做一大堆無關痛癢的工作,因此協助製作、發掘需求的工具、技術一直再出陳更新,再多也不為過。

.

0015

但是PO所端出來的需求Listing,仍大多落於"校驗活動“的象限。

但大家都知道;需求能夠落在"差異化活動“象限中,才最有意義。

.

感觸抒發於至 中華電信 演講主題為「系統思維下的 DevOps 和 Agile」前夕。

.

 

如何與自己對話

活化思考

傾聽自己內心的低語和牢騷有助於提升自我認知的能力(Awareness覺察),連帶也會提高與他人之間的互動力。

-船川淳志

活化思考的利器,就是一問多答。

-問題,不會只有一個解答

 

.

自我回饋

在Gmail 設定 ”自我回饋” Tag

.

運用寄信給自己來與自己對話

我總是在演講時要求學員做到自我回饋,這是個人達到敏捷化的基礎,也就是「寄信給自己」。做法是;只要在email系統裡設定自我回饋的標籤(Tag), 接著只要點一下;便可以輕易的察看這些寄給自己的信件的「自我回饋」的訊息了。

 

目的是拿來反覆驗證、追蹤之前的解題方案或是想法如何? 這是一種運用在經過一段時間的間隔後,透過時間延遲的效應讓自己的思維有機會沉澱一下,然後再從新思考一次問題的方法,它讓我能重新的來面對問題一次,又多一次機會試著從不同的角度來思考解答。依據的是「反覆思考就會又答案」的理論。(註1. 活化思考的七個提示,參考自日籍作者,船川淳志的著作《一個人以上的思考術》)

 


我會有這種運用email 來做自問自答的習慣,最初只是為了把查詢自 Google上所得到的各種不同答案加以整理起來,讓他們重疊在一封郵件裡實在是再適合不過的做法了。它不但可以記錄下整個解題的過程,也能讓自己看到在怎樣的查詢條件下,所查詢到不同的解答。然後;一在地重讀它又可以進一步的增強記憶,對學習新事物也很有幫助。

久而久之卻發現,除了查詢資料的整理之外,也可以拿來像鬧鐘一樣的提醒自己,讓自己不容易遺漏事情。便開始嘗試紀錄事務的提醒。除了提醒;便是可以用文字來和自己對話,真是一點壓力都沒有,你可以坦承的檢討自己知道什麼、沒弄清楚什麼、接下來該計畫些什麼。雖然閱讀者是自己,但千萬不要因為是自己,就不在意是否打了錯字或是語意含糊不清,其實;這種做法最適合拿來檢視自己所寫下來的文字是否合乎邏輯了,幾次以後;便養成了在做演講之前的自問自答的課題。它可拿來檢視自己演講議題的整個邏輯程序,是否讓別人容易了解,又會產生什麼樣的疑問。

功能:  1). 資料整理和傳遞。2). 增強學習  3). 鬧鐘及事務提醒。 4). 思維邏輯的檢核。

(自己也因此;增廣了不少見聞)。


.

選擇面對自己

在跟自己對話的過程裡,一開始總是會感覺到自己的無知,然後隨著透過各種查詢的方式,一直加進來的各種資料與解答,慢慢的越來越多累積下來的知識。有時候追到最後;即便沒得到太多突破性的答案,也能換來相當的滿足感。久而久之;信裡面不是只有問題的解答了,開始有一些提醒自己該怎麼做事的警語,或是一些好的概念,一些想要提醒自己的、或是提醒學員的佳句,也不經意地累積了起來。這種寄信給自己的動作,透過自我對話的行為,讓人開始經常面對自己(出現錯別字時,其實應該更加在意,它隱喻了你在這裡會犯錯,而現在有機會先修正了,錯誤自然而然地消失,慢慢的讓自己變得更嚴謹了)。

.


人遇到痛苦一定會學習逃避,這是本能。逃避之後確實暫時變得比較不痛苦了,然而,痛苦並沒有因此而得到解決。解題;就要從面對自己開始。


 

依靠它來增加自己的覺察力

覺察Awareness是程式設計人員最不可或缺的能力。寫程式是一種寫越多就越不容弄清楚自己都寫了些什麼的工作。我稱之為程式設計人員的「困境」,程式行數越多我們落入的困境就越深,因為我們越難覺察自己都寫了那些邏輯,是否產生了矛盾的地方,而這些矛盾的地方便是日後會遇見的缺陷,也就是通稱的Bug。而覺察正是偵錯時最重要的元素。(就是客觀偵錯的基礎)

 我教導程式設計人員寫好程式的第一個要素是覺察(也就是先學debug後學寫程式),它是你集中注意力、聚精會神、頭腦清晰時就會產生的東西。讓我們看看《簡明牛津詞典》Concise Oxford Dictionary對覺察(aware)所下的定義:「神智清醒、非無知、有知識。」我最喜歡《韋氏字典》Webster’s的補充說明:「覺察指的是:機警觀察或詮釋他人所見所聞與感覺後所得到的知識。」這正是程式設計人員運用清晰邏輯來解題的利器。

 

大部分的programmer都有一種強烈的自以為是的思維,這種過分自我中心的意識會使人扭曲看清自己真面目的能力,也看不清楚身邊的人,我們也極少能從同事、下屬甚至是朋友、家人口中聽見坦白、客觀的回饋意見(請參考: 卡普曼戲劇三角 – 心理學界的系統思維)。為了獲得回饋以便能夠提前知道錯誤來進行自我修正,為此我常年來運用寄信給自己的方式,養成了一種「自我回饋」的能力。目的就是想要盡力的維持自己覺察的能力。有時人們會稱它為自我概念

 


自我概念 Self-Concept 即一個人對自身存在的體驗。它包括一個人通過經驗、反省和他人的反饋,逐步加深對自身的瞭解。自我概念是一個有機的認知機構,由態度、情感、信仰和價值觀等組成,貫穿整個經驗和行動,它能把個體表現出來的各種特定習慣、能力、思想、觀點等組織起來。


 

結語

在回顧會議裡,團隊有秩序地進行自我反省的動作,省思自己哪裡做得好,那些地方沒做好,依據回顧檢討的方式來改善自己。但自省並不能使你擁有更好的洞察力;要知道你的經驗往往是你自我認識的敵人;而他人又總是避免誠實地說出對你的看法。所以培養自我洞察的能力至為重要。我就是運用這種寄信給自己然後再反覆來回信的方式,用來加強思維以增進自己的洞察力的。


請問;收到自己寄來的信的時候要回覆嗎? 要如何回它呢?

答: 一定要回覆,而且要用心的回,不可以語意不清或有錯別字,你越是用心收穫就越多。


 

透過「寄信給自己,再回信給自己」,能夠觸發你的自我察覺能力。除了提升判斷資料正確性的能力之外,多做這種練習自然會進一步提升你的洞察力(驗證一個問題擁有多個答案的強化性思維能力)。

.

我找到答案了 跟「我找到許多解答,後者將活化你的思考能力。

-持續搜尋正確解答的思維

.

寄信給自己不是PO文,PO文只會慢慢地將人洗腦成自戀又自大的 nobody。覺察的道路不會都是喜悅的,更多的是痛苦之後的體悟。請避免在信中稱讚自己,雖然那樣做可以讓人覺得快樂一些,但卻只是自我感覺良好,一種逃避面對事情的態度。

開始寄信給自己吧!

開始回信給自己吧!

 

註一、船川淳志的著作一個人以上的思考術

活化思考的七個提示:

  1. 思考裡是沒有界線的: 反覆的思考就會有答案。
  2. 一問一答、一問百答: 正確的答案只有一個。
  3. 正反面思考的建議: 看事情一定要正反面都看。
  4. 琢磨自己的用詞: 建議一個人玩接龍遊戲。
  5. 改變思考模式:刻意選擇擴散和收斂、反應迅速和條理分明、抽象和具體。
  6. 永遠保持冷靜: 對於看不見的問題提出三個疑問 Why? So what? What if?
  7. 認識妳自己: 提升自我認知能力。

個人看板篇 – 一個人如何施行敏捷

.

這篇文章是為了配合91App新進人員的敏捷訓練課程,融合了敏捷開發Scrum及精實看板Personal Kanban,並運行在《單核工作法》上,所製作的一個人實施敏捷-個人看板篇。內容包含: 看板運行說明如何實踐個人看板(youtube影片)、簡化版的個人scrum 運行及單核工作法的原則說明。目的是為了提升個人的工作效能。

.

0001

目的在追求個人效能的持續優化

.

0001_01

因為使用方便的電子看板卻損失了: 視覺化思維、機會教育、團隊聚焦、…

.

0002

如果你站在看板前,卻不知道要看些什麼的時候? 請試著運用「系統思維」來視覺化團隊的工作. 將看板視成一個迴路系統,然後將精實原則拿出來考量一番。

看著看板上的紀錄,思考著回顧會議時可能提出來討論的種種重點。接著想想看板上是否需要調整什麼地方 …,  看板系統就自然形成迴路了。

.

0003_02

看板規則簡單,主要在透過處理Queue的行為,以優化我們的效能 

.

0004

敏捷就是小增量、多迭代、尋求回饋

.

0005

Scrum 定義角色、會議及產出物形成一種應變需求變化的框架

SCRUM輕量化的流程選擇了讓團隊有較大的自組空間來做應變,短短的Scrum Guide只有簡潔的規範,目的是讓團隊在嘗試實踐中循著持續改善的路線前進,這便是一種小增量多迭代尋求回饋的作法。

.

0005_01

結合「看板方法」+ Scrum框架 來實踐「單核工作法」的 個人一日Sprint

個人的效能為出發點,我們在看板上視覺化自己的日常工作,並融入scrum的運行理念,以便於聚焦的「五件事清單」為增量,配合著單核工作法在專注與全景模式下持續切換進行,然後在每一個迭代完成後尋求回饋,調整檢視中間突來的插斷,在調整我們的步調繼續進行學習與改善。

.

0006

將一天的工作在 專注模式 全景模式 中持續切換,以追求效能.

突如其來的插斷,可以先置於"集草器清單" 待回顧時再進行檢視決定何時進行除草作業。

.

0007

運用專注的工作來提升自己的效能

.

0008

整點時間之間切換專注地工作與全景休息、客觀觀察的模式,(集草器清單表;好比scrum及看板的遺漏清單;目的是對突發需求的捕抓以避免遺漏)

單核工作法;就是在優先順序評估和專注狀態之間切換 :
》在全景模式中, 放眼整個地平線上的任務:從現在開始的一小時最好用來做什麼?
》給單核專注時段設置一個固定的長度 (整點時鐘) 有助於保持良好的節奏。

.

0009

配合單核工作法的個人看板設計

  • 代辦事項: 包含了個人健康、興趣、家庭事務及公司工作。
  • 5件事清單則在全景模式時進行填補、判斷。
  • 檢核欄位: 提供自我檢查,
  • 另外次欄位提供 等待 的暫存區,因為真實世界等待難以避免的。
  • 最後的完成區,提供夜晚上床睡覺前的回顧動作,並藉由email來記錄結果,以便形成持續改善。

.

0010

未在台上市的「單核工作法」圖書

.

0011

你可以結合看板用戶故事地圖Scrum的框架,高效的進行個人的工作

.

0012

時間急迫不是害你事做不好的重點,去做不重要的事才是浪費你精力及效能的元凶.

.

0013

刪掉那些浪費你時間的元兇,養成高效能的好習慣

.

0014

沒有上市以前的需求都只是半成品

.

0015

讓團隊一起做需求排序,勝過於拼命趕工

.

0016

要珍惜時光就要做工作的優先排序,保持科學精神減少直覺行事

.

0017

.

0018

.

0019

.

0020

專案開始之初,首重看見全貌 – 系統思維

.

0021

看見全貌後,先知道自己在哪裡? 距離目標有多遠?

.

0022

夢想也可以是目標,只要它有可實行的步驟,就有機會達成

.

0023

由內往外,先問 Why? 再問 How? (Why so / so What)

.

0024

敏捷的思維架構在小增量、迭代、回饋上頭

.

0025

計畫可以帶來信心,但執行敏捷時要以實務的變化為依歸.

.

0023_01

養成高效的第一個好習慣: 以積極負責的態度面對生活

.

0027

全部資料圍繞在這三個主題: 單核工作法、Scrum 及 看板方法.

.

0028

.

0029

單核工作法實施步驟

.

0031

生活中該做、想做的事情就好比陳列著需求的 Product backlog

.

0032

五項任務清單就好比計畫會議後的產物 Sprint Backlog

.0033

 

一次專注於一件事,正是精實看板所謂的單工作業

.

0034

整點時間的切換休息可以讓我們敏捷的調整工作的優先序,回饋則形成系統迴路

.

0035

切換成全景視窗讓我們在休息時又有重新排序工作(接受干擾、插斷)的機會

.

我們都懂得要求PO對需求進行排序,卻忽略了對自己生活事項的排序。

-我們是自己生活的PO

.

0030

記得刻意練習所教我們的嗎? 先了解自己的狀態去適應環境,也就是先自覺 Awareness.

選用的方法(提升效能的方法或工具)必須適應環境;要根據自己最新的個人經驗,一 點一點調整。沒有放之四海皆准的方法。

.

圖片 005

一種避免偏頗解讀的有效方法

看板上展現的是工作流程,對團隊而言是他們做事的文化,對個人而言是你處事的方法。所以不論你是面對自己的看板或是想要了解別人的看板,都應該避免一種錯誤的解讀,也就是產生偏見。上面的 D.I.E 模式正是用來避免偏見的有效方法。

Chris Argyris 克里斯·阿吉里斯 跟我們說: 「人類有自己編撰故事然後再自圓其說的傾向。」也就是「左手欄」的誤解。為了避免對事務有錯誤的解讀,運用 D.I.E 模式可以協助我們思考。

1. 首先;就自己所看見的進行描述 Description(思考的方式是;這是什麼? 也就是試著描述自己看見了什麼) ,

2. 然後進入解說階斷Interpretation(也就是站在團隊的立場思考,這對他們意味著什麼?),

3. 接著才試著做出評價 Evaluation(也就是對你而言這意味著什麼?)

.

如何問出好問題?

.

問問題

市面上有好多講授如何提問的書

.

如何問問題?

有工程師問我:「如何問出好問題?」,他說他已經讀了好幾本問問題的書了,但還是有同事反應給他每次問問題時都讓人抓不到重點? 實在讓人不知道該如何回答他,建議他再去看一下教人問好問題的書。

.

問不出好問題,其實是邏輯思維的問題?

.

為什麼在問別人問題時,別人會反過來倒問你到底是想問什麼呢? 你一下子由提問者轉變成被問者,角色的轉換讓你瞬間不知應該如何回答(這說明了你的問題是否不夠具體?請反思問題的本質)一旦出現這種尷尬的場面時,你心裡想的可能只會是盡快化解這種讓人不安的情境,很少時候你能靜下來好好思考要如何來回答別人沒弄懂你想問的問題,到底哪裡把他們弄胡塗了。

 

關鍵是;一次只問一個重點

一次問一件事,這是重點。盡管你的附加說明可能有些冗長,別人也可能沒有耐心聽完,但這些說明應該只是你剛剛所提出問題的論證而已,不應該反客為主,讓人誤以為它們也是問題。

 

麥肯錫的金字塔原理正是用在這裡,讓清楚的邏輯思維很快令聽者弄懂你所想闡述的問題,是一種先講結論然後接著才是用演譯或歸納的邏輯來支撐你的結論的描述。這種方式能夠讓聽者很容易的在他腦中建立有關問題的邏輯輪廓(樹)。建立理解你所想要表達的論點。

 

其次是;要預設提問

應該事先想好,你的陳述會引起別人產生什麼樣的疑問,就是先為對方著想。反過來提問的人,通常只是想弄清楚問題的方向,確認他所聽到的和所聯想到的事物有沒有跑歪了,跟你的問題是否有所偏差,沒有太大關係,是你那瞬間想多了。

這便是講清楚問題的「前提」;也就是事情的前情提要。

.

亞里士多德所謂的「結論,可以從叫做『前提』的已知事實,『必然地』得出的推理」。

.

聽「前提」與「跳躍式思考」是溝通不良的主要因素

前情提要過於冗長的時候人們會容易出現不耐煩的現象,也容易忘記他剛剛想到的問題解答,自然倒過來再問你囉。這是溝通不良最多的一種起因。然後你要避免跳躍式的思考,即便對方的應答突然引起了你許多的聯想,要避免多主題的交談方式,會讓聽者跟不上來,或是自以為是地也開始聯想起來。這是溝通時的二大弊病,也就是一定要把前提說清楚,尤其是一些專有名詞或簡稱,要避免假設對方一定也很清楚它的定義。跟避免主題跳躍式的交談方式。

 

若是面對面的提問方式,可以參考梅拉賓法則,一種溝通法則,是梅拉賓在1971年所提出:述說一個人對他人的印象,約有7%取決於談話的內容;輔助表達的方法如手勢、語氣等則占了38%;肢体動作所占的比例則高達55%。即人際溝通=7%文字 + 38%語氣語調 + 55%非語言信息(動作及神態)。正是讓他人容易理解我們在說些什麼的好方法。

 

若是採用遠端的提問方式,不論是文字或是視訊,那麼傾聽的邏輯就變得十分重要了(請參考 邏輯傾聽)。

.

向別人問問題的時候,在思考如何整理自己說的話、怎麼說或怎麼寫之前,一定要先確認自己的問題(主題),以及你希望得到的反應是什麼。

– 先弄清楚自己的問題

.

邏輯樹

運用簡單的邏輯樹把系統問題拆解分支成較小的單位

.

邏輯樹 – 使用分層的架構來協助思考

由上往下,從較小的單位繼續去拆解問題,推演出一層一層的因果關係,接著再運用黃金圈的理念找出核心問題Why 與解決策略 How,以減少遺漏。在請教別人問題之前,自己可以簡單的運用邏輯樹的分層架構先想過一遍,讓自己更理解問題也自然讓聽者更容易理解。

.

階層化的看事情,避免重複、遺漏、離題

難以被人一次聽懂的溝通說話,往往是看起來就是一團混亂」,例如你說理由有五個,但說了半天讓人總覺得好像這些理由都很相似(重複)。或是只說了三個理由,然後就打住了(遺漏)。或是說明理由的時後繞了太長的路,失去焦點了(離題)。邏輯樹可以讓你用分層的方式加強聽者的記憶成效。為了增強說話者的說服力,在提問前先簡單的畫一下問題(主題)的邏輯樹,給自己想清楚的機會,或許自己搞懂了自然就不用在問別人了。若是沒想通;此時在問別人問題,自然會更能讓人抓到重點。宜多練習熟能生巧。

.

消除重複、遺漏、離題的技術 – MECE分析法。

MECE: Mutually Exclusive Collectively Exhastive. 互不重複,全無遺漏

.

最後;來總結一種「好的提問方式」

首先;自己先確認要傳達的問題,然後確認傳達後希望得到對方什麼反應,之後再去想自己認為問題的答案是什麼(畫一下簡單的邏輯樹)。如果問題的複雜度偏高了,這時候可能有太多的參考資料,也就不是一、二個問題可以說清楚的,這時候能夠把它寫下來,用訴諸文章的方式或許是一個更好的選項。

.

0016

確認一、這是真正的問題嗎?  確認二、我期待對方有什麼反應?

.

為自己的溝通技巧評分一下;對方是否做到如你預期的反應了呢 ?

.

註:

  1. 邏輯與溝通 – 請參考 邏輯思考的技術
  2. MECE 分析法:

巴巴拉· Barbara Minto 女士在麥肯錫的金字塔原理 The Minto Pyramid Principle書中所提出的一個重要原則。

如何看見全貌?

.

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

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

.

居家工作的溝通密技 – 邏輯傾聽

.

解決遠端工作在溝通上的屏障,人們更需要擁有清晰的邏輯思維以及簡明的表達自己思維的能力。

邏輯傾聽 : 一個能夠協助你在電腦的這一端,明辨講者思維不可缺少的訓練

.

0001

.

0002

.

0003

.

0004

.

0005

.

0006

.

0007

.

註:

  1. 邏輯聆聽 Logical Listening 參考: 《一個人以上的思考術
  2. 傾聽,不可思議的力量
  3. 大前研一《思考的技術

.

 

 

軟體產品生命週期

.

為什麼我們無法維持高效「車庫」開發方式?

.

Pdlc

Software Product Life Cycle

.

從 20/80 到 80/20

軟體產品生命週期;一開始是花20%的力氣做到80%的工作量(著名的車庫式開發方式便是如此,典型的人少效率高,產品不完備卻充滿各種潛在的可能),至於開發速度為何在進入市場後變慢了呢(由20/80 變成需要花80%的力氣,卻只能開發出20%的產能,也就 20/80了),撇開開發單位在事務上的浪費,最大的原因無疑是由於系統複雜性的增加所帶來開發速度的變慢(當然再加上開始有維護的負荷了)。

.

複雜度

系統複雜度與開發團隊的浪費是效能的二大指標(Michael Dubakov )

.

主動規劃軟體的生命週期

產品生命週期的理論大家都不陌生,但軟體不比具有實體的器具,例如汽車有明顯的生命週期,車子一直開一直使用總是要維修的,一旦維修的成本越來越高,我們不用想也知道該換車了(老實說,車子不用等到開不動了才會想到要換車,其實當外觀開始有些落伍時,你大概就會想換車了)。軟體的置換則不比硬體,大部分業者都知道這個圖示但選擇忽視它,因為軟體新舊沒有那麼來的明顯,軟體也沒有所謂的大量生產、製造,不管是做一個或是做無數個都是一模一樣的,沒有汰舊的急迫性,同時網路連線做更新又是那麼的方便,讓人容易忽略了產品的市場風險,沒有考量到軟體開發需要較長的時間問題,尤其是一些較大型的軟體(那些個平台式的系統)。為了做到市場的持續性(產品永續經營)唯有相信軟體產品是有生命週期的,唯有提前進行開發作業才可能做到無縫的銜接方式。

讓我們來看一下微軟是怎麼做的。

.

windows version_2

Windows 的發展史

.

MS Windows的每一個版本的開發作業都是並行的。例如: Win98是在Win95開始開發還未上市前,就成立Win98開發團隊,開始開發作業的。那時完全不曉得市場對Win95會有怎樣的反映。但基於摩爾定律的預測再加上軟體開發費時的壓力,唯有提前開發才可能做到市場的持續性。

.

MS Pdlc

Windows的產品生命週期開發方式

.

微軟針對由20/80 轉換成 80/20 的解決方案,就是選擇了相信市場部門所提出的新版本的開發需求能夠讓自己的產品持續佔有市場的作法(以滿足未來客戶的需求為導向),也就是讓產品以一種重疊的開發方式,在新一代產品尚未投入市場時,就撥出少部分的人力投入未來版本的開發作業,這是ㄧ種必需極為敏捷的作法,因爲你的團隊ㄧ直在大量假設的前題下進行開發作業(辛苦可見)。未來當舊版本的維護成本上升到一定程度時,新版本可以隨時推出,因為他們能夠以80/20的開發速度前進。如上圖所示;要維持好的開發效能因素很多,而微軟選擇了重疊式的產品開發方式。請正視軟體版本的生命週期,以主動規劃新版本的功能來取代逐漸複雜化的系統。至於持續的加強重構對維持軟體的生命週期可行嗎? 如第一張圖示,重構只能暫解維運的負荷,對20/80效能不彰的現象難以產生具體的改善作用。

 

同樣身為軟體開發的業者,你呢? 你應該如何來規劃自己的軟體產品呢?

 

簡單一定對嗎?

簡化不能降低複雜度,不是所有的流程都能做成標準作業程序SOP的.

.

cynefin_simple

Dave Snowden 的 Cynefin 框架(關注: (1) 簡單象限)

.

》敏捷團隊常有的謬誤

實行敏捷變革時;管理階層常常害怕去改變一個看起來已經表現得很穩定的團隊。深怕這種和諧的運作模式會因為風吹草動,而被我們給破壞了。

一種不敏捷的思維

.

針對右下角的第一象限,也就是「簡單象限」,我想說的是簡單也不一定都是對的:

情境1. 簡單:有最佳實務的區域

是最適合制定SOP的情境,它的特徵是因果關係很明確、很穩定,事情清晰可見,人人都看得出來原委。正確的因應之道不言而喻。這種情境屬於「已知的既定事實」(known knowns),各方都有共識,因此大家對決策都不會有異議。像是標準元件的生產過程,這類問題向來沒有變化。簡單的情況只需要有一次的經驗就讓人能夠適當的做評估,能夠防患出狀況,只要透過適當的管理與監測就沒問題了。管理人員只要進行分類,大家看了就都有Sense了。也就是說,在評估實際情況後,運用分類的方式,然後對實務作出回應就可以搞定了。是適合制定SOP的情況,提供下回要做的人可以一次就作對,而且還能夠獲得一定效率的產出。例如: 急診室的判斷程序,就屬於需要又簡單又快速的情境。如果出了差錯,醫護人員通常能夠發現問題所在、透過分類(檢視病人的危急狀態來處理不足的情況,一般運用簡單表格即能做到,例如: 急診檢傷與急迫度分級量表  TTAS : Taiwan Triage and Acuity Scale,分類: 第一級、復甦急救第二級、危急。第三級、緊急,病況可能持續惡化,需要急診處置,病人可能伴隨明顯不適的症狀。第四級、次緊急第五級、非緊急)。在這種情況下,現場人員能直接看到處理上述情況的資訊,因此最適合採用「命令控制」的方式來決定工作要項。建議處理程序是: 觀察→分類→因應,指令越清楚明瞭,授權別人作決策,大家就能自動配合的運作起來。在這種情況下,制定好的SOP能省去許多不必要的溝通快速解題達到一定的效果。

過於相信SOP的危機,在簡單的情況下會發生什麼問題呢?

要注意的是,當事情被過度簡化時,細微的錯誤可能被忽略了。而產生無人去檢視細微情況所衍生出的複雜性,當大家都依據SOP行事時,表面看起來精簡的情境,就更可能因為發現時已經惡化到一定程度了,由於小現象的持續累積而轉變成難以控制的風險。(例如: 日本福島第一核電廠事故的啟示)

 

由於管理人員的成見(習慣)影響,人可能是簡單型情境發生大問題的主要因素。這裡指的是成見,人們受限於過去的經驗、訓練和成就所建立的觀點或習慣,無法採用新的應變思考方式,因此當事情發生時,往往會出現制約反應(習慣抑制了正常的行為應變)。

.

》敏捷團隊經常存在的一種謬誤

「團隊一旦穩定下來了,就要避免去改變它」

實行敏捷變革時;管理階層常常害怕去改變一個看起來已經表現得很穩定的團隊。深怕這種和諧的運作模式會因為風吹草動,而被我們給破壞了。

.

一個成熟的開發團隊,往往因為想讓事情看起來進展順利,他們也確實的做到了,團隊成員一心想要維持這種狀態,便容易開始忽視了一些小情況的變化,刻意不去面對它、忽視它,而遭致團隊成員的誤判,這是敏捷團隊養成期的典型現象。因此在 Cynefin架構中,簡單的情境緊鄰著混亂的情境,就是這個道理。一個穩定的團隊可能因此誤踏火坑。 例如,許多原本占有市場的科技產品,突然間被競爭對手的科技取所而取代之,便是忽略了細微的問題會累積成巨變的現象。

.

Cynefin Framework 是用來協助領導人對問題做快速判讀的。

.

養成自組織的團隊

讓團隊自己做決定,領導人必須避免凡事都要巨細靡遺的管理方式,而要視當時的情境,適時掌握事態的發展,才能察覺問題的變化。也就是說,部門員工日常在簡單的情況下運作,就儘量授權讓他們獨立處理可能發生的任何事情。對那些有豐富經驗的人(高效率的工作人)。領導人更應該設立一個回饋管道,讓有意見的人可以透過適時的回饋管道進行回饋,因為問題過於簡單而被忽視的災害狀態。

.

簡單管理而非簡化。  – Stephanie Borgert

.

結語

我們應該用不同的視角去看待不同的問題,也不應該一直使用相同的處理措施在解題。簡單化容易帶給我們的一種問題,便是大意。SOP標準作業程序讓人反應快速卻容易輕忽了情境變化時的細微徵兆,他違背了就事論事運用不同視角看待事物的原理。上圖中的 Cynefin 框架,將問題分成五種不同情境來看待。目的是說明在不同的情況下,我們應該採用不同的解題思維。例如右上角象限的「繁雜區域」,這是專家最有發揮空間的區域,解題方式是觀察→分析→因應,經驗在這裡就顯得最為值錢。

 

人們愛好簡單,因為它容易預測、明確得讓人沒有顧忌。它經常是看到問題就想到解答了,容易給人一種幸福的感覺。但如果你遇到複雜的事情時,只是想辦法簡化它希望經由簡化來解題,其實簡化並不能把複雜變得簡單的,也就是說當你遇到複雜的事情時阿什比定率(*1)才是你應該關注的。Cynefin 跟我們說;透過探索、觀察再來因應,才是遇到複雜問題時應該採取的措施。

 

情境1;簡單 Simple:有最佳實務的區域,處理方式: 觀察→分類→因應.

情境2;繁雜 Complicated:專家最適用的區域,處理方式: 觀察→分析→因應.

情境3;錯綜複雜 Complex:約束靈活的區域,處理方式: 試探→觀察→因應.

情境4;混亂Chaotic:快速因應的區域,處理方式: 行動→觀察→因應.

以及 5.  無序

其中「簡單」擁有了最大的陷阱…

.

0008

整理過的 Cynefin Framework

.

這篇文章講的是簡單的壞話,真是不容易。但話說回來,混亂的時候,往往是具有領導力者的最佳發揮時機。人們在混亂情況下,會比在其他情況下,更容易接受新事物和命令控制式的領導的。

.

阿什比定率(*1)

又稱為 必要多樣性定律,是指自然界,只有多樣性才能摧毀多樣性。換句話說:就是只有複雜度更高的多樣性,才能勝任摧毀另一多樣性的功能。

 

.

 

.

顧問工作的第一堂課

第一堂課

問題識別」是顧問工作的第一堂課,方法是運用迴圈審視的方法.

.

業主最常問的是「你覺得問題出在哪裡?」

.

問題識別」是顧問工作的第一堂課

這裡提供我做顧問時很常採用的方式,迴圈審視法來尋找問題:

迴圈審視法: 一種針對工作流程是否形成迴圈的審視方法(system thinking loop)

別誤會,這裡說的不是系統因果循環圖 Causal Loop Diagrams. 這只是我常常引用的方法,它十分簡單是基於一種系統思維的方式(形成系統迴圈)來審視企業、組織或團隊運作流程時的缺失的方法,提供給大家做參考。

迴圈審視法:是一種針對既有工作流程是否形成迴圈(一個系統System)方式的審視方法。只要組織或團隊的行為(process)有地方沒有形成迴路,也就是有流程沒有構成一個系統,基本上它就是有問題的地方,也就是能夠改善的地方。至於要先改什麼地方? 或值不值得去改善,那就要看(業主)對問題的輕重緩急如何排序了。

.

系統一定要形成迴圈嗎?

是的;系統思考的核心概念是「回饋環路」feedback loop,它指的是一個系統的輸出(output)會回過頭影響系統的輸入(input)並且形成迴圈的現象。

.

例如:

  • 跑 Scrum 是一種迴圈方式。如果少了展示會議,便沒有取得回饋,少了回顧會議就沒有檢討到底學到什麼。如果 Scrum 做得不好,沒有取得效果,通常是這幾個會議執行得有缺陷是最容易出問題得地方。

scrum

Scrum 的四大會議迴圈圖示

.

  • 運行看板時,遵循由左往右的方式進行單工式的拖拉移動,它並沒有形成一種迴路的方式(缺少了 Sprint 的觀念),因此就需要定期的來做檢討工作,或是看到完成的欄位累積了一大堆已完成的工作單卻沒有進行回顧的動作時,便可以運用招開回顧會議的方式,開一次團隊自我檢討的會議,把它們正式的清除掉,以便繼續容納接著完成的工作單。這便形成了一種系統式的迴圈,當團隊的工作配合看板的透明化特性,再加上團隊能夠在回顧會議之下進行調適,形成了一種持續改善的工作形式,便得以發揮看板方法的威力。

.

看板

對看板加入定期回顧形成迴圈

.

沒有Sprint 怎麼實踐 Scrum 呢?

常常遇到團隊的開發模式是一種沒有迭代的方式,開發作業少了累加的現象,大部分需求都是一直做下去,直到專案完工。這會自然形成一種Waterfall 的思維,損失慘重,無法對(周遭的)變化產生應對,久而久之便會對變化採取忽略的態度,這對產品是一種損失,對開發人員的專業知識的獲取也是一大損失。因為少了逐步累進的效果,更難以形成對專業知識的養成(形成專家),而敏捷就是要解決這樣的問題,解決之道是;首先要把需求的增量變小,再加上對(尋求)客戶回饋的檢核動作,讓團隊面對客戶的回饋主動去進行討論(自組織式的調適行為)去應對它。如此便能自然形成小增量、迭代與尋求回饋的迴圈模式了。

.

  • 實行敏捷化的企業,最常犯的便是執行一種沒有形成系統迴圈的流程。例如: 需求開發流程(團隊自我回顧是團隊的小系統,形成團隊自我成長的迴圈,如上面的例子一、二。但對於組織而言,系統指的是組織層級一個較大的迴圈,Less稱它為實行OnePBI,也就是組織級的需求排序陣列)。組織常常會忽略針對需求的成果進行檢討回顧以便能形成系統的迴圈(才符合DevOps持續改善的原則),因此必須對OnePBI的實施流程形成迴圈。

 

改善的處理方式,是在決定要實做需求前先進行估算(不是指工程師對開發時間的估算,而是當做了這個需求之後,對市場所回饋的投資報酬率估算,估算不準沒關係,可以經由持續修正來改善它),實作時再在執行開發當中進行估算的調整工作,在做完發布上市後再來做回顧,並於運行一陣子後(時間延遲)再做檢討改善,這樣便可以形成一個系統化的審視迴圈。符合系統思維的模式。

.

需求

將組織級別的需求開發加入迴圈

.

結語

我在做顧問時很喜歡用這種方式(迴圈審視法)來診斷問題,它又簡單又能很快找到問題。其中一個很大的原因是它符合系統思維(形成迴圈才是一個完整的系統),另外,是組織或團隊可以據此達成持續改善。換句話說;就是當我結束顧問工作後,他們仍然能夠因為有形成迴路的方式,而能夠獲得持續改善的機會。

迴圈審視法應用步驟:

  • 針對既有流程繪製迴圈圖,讓它形成一個系統,無法形成迴圈就是有問題。
  • 形成迴圈後再來思考是否能夠持續進行改善,這一點必須奠基在衡量上頭,有量化的依據你才能知道自己改善了多少。

.

缺少科學精神

科學精神」;大部分公司的經營者都少了這樣東西,也就是做任何事時;必須建立於收集可觀察、可經驗、可量度的證據,且合乎明確的推理原則。這才符合科學精神。但大部分的CEO都憑直覺在做事相當的不科學,以至於我們去顧問這些公司時,很容易就能看到問題,但經驗與感情卻牢牢的牽絆著他們的思維,一旦我們(顧問)所提出的解題方法被批評為唱高調時,你的建議就好像從來沒發生過一樣,他們不會在意花了多少顧問費,他們很少會用科學的精神去探討如何才能達成,大多數反而選擇逃避。平白的浪費了許多機會。深不知它比敏捷化還要基礎還要重要嗎?

 

「科學方法」指的是檢查自然現象、獲取新知識或修正與整合先前已得的知識,所使用的一整套技術。為了合乎科學精神,這方法必須建立於收集可觀察、可經驗、可量度的證據,並且合乎明確的推理原則。

.

量化你的改善效果或許是做顧問時的第二個課題,但我總是漏掉它。

必要時可以繪製出CLD圖示(因果循環圖 Causal Loop Diagram)對增量或減量做分析。

.

系統思維

系統思維是一種途徑協助人們從宏觀角度了解系統,包括了整體結構、模式及週期。相對於笛卡兒及其他人的還原論、哲學分析,它傾向整體主義。因為它關心的是整體及其各部分之間的關係。迴圈審視法是基於系統思維的。

※ 如何開啟系統思維 ?

從看清系統的結構和行為之間的關係開始,先看清楚它是如何運作的,然後再試著去解釋出現問題的表面現象,探究問題的根本原因。