DevOps 的金字塔原理與技術
金字塔是由許多三角形所組成的
金字塔原理 = 邏輯思維的金字塔
這裡的「金字塔原理」指的是麥肯錫顧問公司用來訓練內部員工，由芭芭拉·明托 Barbara Minto 女士所開發出來的一套邏輯思維工具。現在拿出來強調邏輯思維的目的；一是因為 DevOps 的本質就是要解決 Dev 跟 Ops 之間的溝通問題。而要解決溝通的問題基本上自然是要有清晰的邏輯思考。其二是我們正逢疫情時期，大家都有遠距、在家工作的機會，因此人與人的溝通模式改變了，因此特別拿出來強調邏輯思考在溝通上的重要性，希望大家在進行溝通之前能夠先構思好自己所想要表達內容的金字塔結構，讓一個清晰的邏輯結構成為我們用來成功溝通的橋樑。
試著回想：
跟公司顧問之間曾經有過的接觸，跟顧問溝通是不是額外輕鬆呢? 是不是很快就搞定了呢?
三個進行溝通時的課題：問題、答案 和 期待對方的反應
溝通三要素：問題、答案和期待對方的反應
溝通其實不只是人跟人之間的交互行為，更重要的是目標，也就是人跟人之間所要討論的事，要討論的「事情」才是溝通的重點，也就是問題是什麼?。產生不良溝通的原因，經常是雙方一再強調自己的意見立場，也就是對事的看法，人們總以為一再地強調自己的答案，多說幾次對方就會聽清楚了。例如: PO 跟開發工程師說客戶要一個更大的按鈕。 開發工程師跟維運工程師說我何時要發布，需要什麼樣的配置? 這二種陳述的方式；乍看起來都沒有問題也都合乎邏輯，但其實講的都是答案，並沒有把真正的問題講出來，因此都屬於一種不良的溝通方式。構成一個好的溝通方式，首先需要先確認二件事:
- 一、先確認真正的問題。
- 二、我們預期對方給予怎麼樣的反應。
像上面的二個例子；講了答案，卻忽略了問題沒先說清楚，所以可能誤導了解答。第一個例子 PO 沒說清楚客戶的目的是什麼? 是什麼原因造成客戶要求一個更大的按鈕。第二個則是開發工程師沒有跟運維工程師說清楚這次發布所要解決的是什麼問題。其次是；問題弄清楚了以後，我們預期對方給予的反應是什麼，表明清楚了對方也才能知道要如何來配合。
專注於答案的陳述卻忽略了要先探討真正的問題
好的溝通；要先確認問題，然後要弄清楚期待對方的反應是什麼。
DevOps 在解決開發團隊與 IT 維運團隊之間的溝通問題
隨著組織的持續發展，在不同時期下，有著不同的問題需要去面對。團隊在首次接觸敏捷開發時，待解決的問題常常是需求變來變去很難做規劃依循，這個時期應該以形成團隊自組織為目標，建立起團隊的內聚力，問題自然能迎刃而解。而當團隊運行的是精實開發的看板方法實行時；此時待解決的則是效能、浪費 … 的效率問題，同時應該克服跨部門溝通，以此為為目標。一旦當組織中業務團隊也加入了運行 DevOps 的行列時，此時待解決的便是 Biz - Dev - Ops 的溝通問題了，組織此時應該將目標設定在解決客戶與未來的客戶的溝通上的問題。
不論是作何種溝通，基本上都應該以清晰的邏輯思考為基礎。
Agile – Lean – DevOps 關係圖示
需求與發佈是實行 DevOps 時的二個障礙
介於 PO 與開發工程師之間的是需求的溝通問題，而介於開發工程師與運維工程師之間的則是發佈的問題。敏捷為需求的溝通提供了一種共同的語言，哪就是著名的「使用者故事」User Story，它不是規格文件而是啟動溝通的一種共同語言。反觀；在開發工程師與運維工程師之間就缺少了這種共同語言，發布文件是規格文件，並不能觸發更深一層的溝通，他把討論寫死了哪來溝通呢，因此我們缺少一種在 Dev 與 Ops 之間的共通來促進相互之間的溝通作業。
金字塔原理提供一種清晰的邏輯思維讓溝通變得更容易
我們可依簡潔的一橫一豎來說明金字塔原理，「一豎」是；結論先行，以上統下。「一橫」則是歸類分組，邏輯遞進。則一橫一豎簡潔的說明了問題、總結是什麼，而歸納與演繹則都說明在下面，它們以三角形的方式排列出來。
「一豎」是；結論先行，以上統下。「一橫」則是歸類分組，邏輯遞進。
結語
溝通是「人+事+人」的問題。真正的目標是弄清楚事情的問題，因此再溝通開始時就能先弄清楚問題，才不至於雞同鴨講對不上來，浪費了許多時間作說明而沒有達到目的。弄清楚問題就好像一個好的前言，它讓雙方都能迅速的站在一致的位置上，開始進入解題的模式，這才是好的溝通。這裡採用了麥肯錫內部訓練所用的金字塔原理。模仿電影一代宗師的口訣: 一橫一豎。電影裡想強調的是「功夫兩字一橫一豎，只有站著才是對的。」而運用在說明金字塔原理時則是；「一橫」則是歸類分組，邏輯遞進。「一豎」是；結論先行，以上統下。目的是簡單的說明金字塔原理是一種重點突出、邏輯清晰、主次分明的邏輯思路、表達方式和規範動作。而他的基本結構正是：中心思想明確，結論先行，以上統下，歸類分組，邏輯遞進。 先重要後次要，先全局後細節，先結論後原因，先結果後過程。
最後針對自己過去常用的圖示作一說明，想強調 DevOps 的進化過程應該是循序漸進的，絕不會是階梯式的進階過程，也就是說它不應該是做完了敏捷化再作精實，然後在精實化之後再來追尋 DevOps，一種階梯是的過程。如下圖；左上角的圖示容易給人誤導，誤以為實行 DevOps 是一種階層式演化的感覺，但其實他想表達的是涵蓋範圍，而非一關一關的進化程序。重新畫成中間的螺旋圖示想表現的就比較是合理的 DevOps 進化過程。橫軸標為 成為…Being，縱軸是依循規範的 執行…Doing。
參考
- 金字塔原理：思考、寫作、解決問題的邏輯方法 - 為 芭芭拉．明托 Barbara Minto 女士所著。
- 邏輯思考技術 - 作者為： 照屋華子．岡田惠子，此為談邏輯思考的日本暢銷書。