系統思維下的 DevOps 和 Agile

.

0003_02

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

.

從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. 互不重複,全無遺漏

.

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

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

 

註:

  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效能不彰的現象難以產生具體的改善作用。

 

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