開發者的最佳體驗: 心流狀態

心流Flow是一種絕佳的體驗,也就幸福的感覺。

Mihaly Csikszentmihalyi

前言

我一直以為「心流」是可遇不可求的一種情境,所以才沒有深入去研究它,而且感覺上它是屬於心理學的東西,身為工程人員大可忽略它。直到看到心流是一種最佳的體驗時,才恍然大悟,自己一直在追求良好的開發者體驗(DevX),其實讓開發者容易進入心流的狀態(它不是情境),然後盡力的去維持這種狀態讓它不要受到中斷,便是王道。這對開發效能與開發者的精神狀態都是一種絕佳的體驗,可以稱之為開發者的幸福之道。

(本文要探討的是如何讓開發者更容易進入心流的狀態。)

何謂心流Flow?

心流(Flow)是心理學中的一個概念,最早由匈牙利心理學家米哈伊·契克森米哈伊(Mihaly Csikszentmihalyi)先生於1975年提出。心流狀態是指人在完全投入某項活動時所經歷的一種高度專注、充滿熱情且完全沉浸的經驗。在這種狀態下,人們會忘記時間、疲勞,甚至忽略身體需求,只是完全投入於當前的活動中,這種情形出現在「工作上」的比例勝過休閒育樂。

從科學(神經科學)的角度來看,心流的解釋前提是我們要主動關閉大腦的前額葉皮層的一部分功能,心流的過程是大腦分泌 “去甲腎上腺素"和"多巴胺"等六種激素,它們不斷深入,心流的愉悅感則來自這些激素,而這些活動增強了我們的專注力和動機。

撰寫程式時一定有進入心流的體驗,只是維時不長

我們或多或少都聽過心流(Flow),都聽過也都有過類似的感覺,但卻很少有工程師專注於此。我們總是把技術與潮流當作第一要務,卻忽略了開發工作中人的感受這一個最重要的部分。「心流」是一種全神貫注在工作中達到渾然忘我的境界時的感受,因此又被稱為「最優體驗」。在心流中你會忘去了時間,明明工作了很久,但就是不會覺得飢餓也不覺得累。既然被稱為是一種最優的體驗,自然是開發者體驗(DevX)所應該研究的東西,也是程式設計人員應該盡力去追求的一種狀態。開發者若能夠越頻繁越輕易地進入心流的境界,開發效率自然會更好而所寫出來的程式品質也會更佳。這是所有管理者所追求的,也是開發者體驗 DevX所想要達到的。

心流,就是一個人全神貫注於某件事而渾然忘我的境界。

Mihaly Csikszentmihalyi

要怎麼進入心流呢?
原則是工作的挑戰性與你的技能必須相匹配。
【前置要素有】
注意力集中、有吸引你的目標、擁有即時的回饋、你必須全神貫注、並達到忘我狀態。

為了追求效能,我們應該設法讓開發者在工作中進入心流的狀態,一種精神專注的狀態,米哈里教授認為當工作的挑戰與個人的技能能夠相匹配時,便容易進入心流的狀態,並稱之為「心流模型」。下圖是教授在TED演說時所採用的圖示,原圖是黑白的圖像(這裡採用網站上的彩色圖示)。
圖一、心流的模型圖示

解讀:

在這個模型中,兩個主要的軸線: 挑戰水準(Challenge Level)縱軸和技能水準(Skill Level)橫軸,被用來界定不同的心理狀態。這個模型描繪了當人們在他們的技能水準和面臨的挑戰之間達到一定的平衡時,他們最有可能進入心流狀態。

  • 心流(Flow):當挑戰和技能水準達到均衡時,個體可能會體驗到心流狀態,感受到完全投入和享受當前活動的感覺。(這是這張圖示最容易被誤解的地方,因為挑戰和技能位置在右上角,容易讓人以為都要達到相當高的水準時,會產生心流,但其實挑戰和技能水準能夠相匹配才是重點而不一定都要屬於高水準時才會產生心流狀態,請參考下圖)。
  • 焦慮(Anxiety):當挑戰水準高於個體當前技能水準時,個體可能會感到焦慮。這是軟體開發人員最常碰到的現象,也就是主管沒有做培訓或技術衡量就直接指定工作給工程師去負責,這種焦慮感經常發生在coding不順時。
  • 無聊(Boredom):當挑戰水準低於個體的技能水準時,個體可能會感到無聊或不感興趣。
  • 掌控(Control):當技能水準高且挑戰適中時,個體可能感到他們完全掌控了情況(人們在這個時候反而容易產生疏忽,對程式設計人員而言,有機會重構過去所寫過的程式時,由於過度的有把握反而不經意的新加入許多功能,以至於產生過度重構的現象)。
  • 放鬆(Relaxation):當技能水準高而挑戰水準低時,個體可能會感到放鬆。
  • 覺醒(Arousal):當挑戰略高於技能時,個體可能會感到興奮和激動,這可以是積極的壓力。這正是OKR所想達成的目標,也就是自我激勵的效果。
  • 擔憂(Worry):當挑戰略高於技能,但個體還未達到焦慮的程度時,他們可能會先體驗到擔憂。
  • 冷漠(Apathy):當技能和挑戰水準都低時,個體可能會感到冷漠或缺乏動力。對無知的好奇可以打破這種冷漠的感受。

這張圖強調了為了實現心流狀態,個體需要找到技能和挑戰之間的平衡點。但是上面這張圖太容易被誤導了,我們還是來看一個將心流理念對照到專案開發上頭的簡單案例(參考自《心流》一書,第四章)。

圖二、強調心流將出現在開發者技能與挑戰相匹配下

運用上圖說明專案開發的心路歷程,心流理論可以被運用來描述開發者在不同階段的經驗。

專案啟動階段A①與心流:在這個階段,在還不熟悉相關專業知識之下;開發者就像初學者一樣,可能對新技術、新框架或新語言充滿好奇心。初期的挑戰可能是學習和理解專案需求,並開始搭建基本架構。此時,即使任務相對簡單,開發者也可能會感到滿足和投入,因為這些任務與他們當前的技能相匹配。正所謂好的開始讓人心情愉悅。

開發階段A②與心流:開發者的技能隨著時間逐步提升,他們可能會尋求更複雜的任務來挑戰自己,比如實現更複雜的功能或解決更難的問題。如果挑戰不足,許多功能都能由外部輕鬆獲得(例如AI自動產出程式碼)開發者可能會覺得工作重複而感到厭倦。

測試與問題解決階段A③與心流:當專案進入測試階段,開發者可能會面臨各種意想不到的問題和錯誤。如果這些問題超出了他們的能力範圍,他們可能會感到焦慮和壓力。這個階段的動機可能來自於解決問題和改進專案的願望。但隨著開發時間的消逝,想要及時完工的壓力反而容易造成開發者的焦慮情緒。

專案上線與維護階段A④與心流:在專案最終階段,開發者需要確保專案的穩定和優化性能。這時,他們的技能必須足以應對這些高層次的挑戰。心流體驗可能來自於成功部署專案並見證其運行的成就感。動機可能是專業的成就感、客戶滿意度和產品的市場成功。

在整個專案開發過程中,維持開發者的動機和挑戰之間的平衡是至關重要的。一方面,他們需要經常學習新技能和技術以保持競爭力;另一方面,挑戰需要與他們的技能水平相匹配以防止工作變得過於重複或壓力過大。理想的狀態是保持一個讓開發者感到既挑戰又能夠掌控的環境,從而使他們更有可能經常進入心流狀態,這樣他們不僅能夠提高工作效率,也能夠享受工作過程,並在專案開發中取得成功。

理想的狀態是保持一個讓開發者感到既挑戰又能夠掌控的環境,從而使他們更有可能經常進入心流狀態,這樣他們不僅能夠提高工作效率,也能夠享受工作過程,並在專案開發中取得成功。

動機的重要性

上圖在心流渠道中;想要表達的是在心流渠道內「動機漸增」的觀念,主管必須依據程式設計人員的技能適度的調配任務的困難度,參照心流模型來理解工程師在不同情境下所可能出現的心理體驗(透過1對1的會議或是敏捷的各個會議,把它當成檢核的項目),經由指導或調整的活動來促進心流的發生。當開發者出現冷漠或無聊的狀態時,自然就會缺乏工作的動機,這種情形常常會出現在資深的技術人員身上,此時主管往往會給予較高挑戰或是將專案成敗整個採用交付重任的方式,指定交由他負責的方式,但這是一種不好的處理方式,可能反而會招來技術人員感覺孤單而缺發團隊意識,引發離職的念頭,同時也讓他無法發揮本身的技能而失去產能。這種情形之下,我以為動機是真正的罪魁禍首,

  • 要怎麼樣讓程式設計人員進入心流的狀態?

讓程式設計人員進入心流狀態,需要創造一個有利於專注和創造性思考的環境。心流狀態,或稱為「在區域中」(in the zone,註2.),是一種完全沉浸於當前活動的感覺,並且在進行活動時感到既快樂又充滿成就感(也就是意識掌控挑戰的結果)。

  • 清晰的目標:確保有一個清晰且具體的目標。程式設計人員需要知道他們的目標是什麼,以及如何達到這個目標。
  • 減少干擾的環境:創造一個安靜且無干擾的工作環境。這可能意味著關閉不必要的通訊應用、電子郵件提醒,或者在辦公室內設置一個不被打擾的時間段。或是盡可能將會議轉變成文件記錄的方式,來避免中斷心流。
  • 適度的挑戰:工作的難度應該與程式設計人員的技能水平相匹配。太難或太容易的任務都可能導致挫敗感或無聊,從而妨礙進入心流狀態。這一點與敏捷開發最能配合,在每個衝刺(sprint)的開始時或每日的站立會議時,我們都有一次檢驗挑戰與技能匹配度的機會,Scrum Master 若能善用激發內在動機的能力,更能協助開發者進入心流的狀態。
  • 及時的回饋:進行任務時,能夠獲得即時反饋,可以幫助維持專注和動力。這可以通過程式碼審查(即時的 code review)、測試或者實時的進度更新來實現。
  • 消除外部壓力:盡量減少截止日期和其他外部壓力的影響。雖然一些壓力是不可避免的,但過度的壓力可以導致焦慮,妨礙心流的產生。
  • 自我照顧:保持良好的身體和心理健康狀態對於進入心流至關重要。這包括充足的睡眠、健康的飲食、規律的運動以及時間管理。
  • 學習與成長:鼓勵學習新技能和技術。掌握新技能不僅可以提升工作效率,也能增加面對挑戰時的自信心,從而促進心流狀態的產生。

團隊中每個人進入心流的條件可能略有不同,因此了解自己在什麼樣的條件下最容易集中注意力和創造性思考是很重要的。透過嘗試不同的策略,找到最適合自己的方法,並努力去營造它。

小結

我們總是把心流看成是一種可遇不可求的狀態,因此而忽略了刻意去追求它的探索,其實;程式設計本質上就屬於需要相當專注的工作,程式員是一種十分容易進入心流的工作者,所以主事者(管理者、SM甚至人資)都應該刻意去營造一種環境,讓開發者容易的進入心流的狀態。而主事者更應該依據挑戰與技能的心流模型圖,來判讀開發者此時所產生的感覺是否恰當,怎麼作呢?

作專案討論時,先問問看他準備怎麼作?

在整個開發的過程中,刻意的去注意每位開發者的情緒 (請參考圖一、心流的模型圖示) 。必要的時候問他一下「現在的感受是甚麼?」。然後再拿來與模型相對照,就可以知道目前他最需要的協助是甚麼了,例如: 如果他感到焦慮,則明顯的遇到了難題,這時候協助他提升技能可以讓他順利的覺醒,提升工作效率。當他感覺工作過於輕鬆時,適度的調整工作範圍,加入一些挑戰,能讓他對周遭的事物更能夠掌控,也提升了他的高度。

心流的體驗即幸福

良好的生活品質能讓我們感覺得幸福,而生活的品質來自於(1)我們如何體驗工作以及(2)我們與他人的互動關係(註3.)。這二者正是團隊開發的基礎,重視開發者體驗就必須在日常活動中多多創造心流的體驗,也就是購專主於自己的工作,又能於他人進行良好的互動。雖然在經歷心流體驗之後自我們會變得比過去更複雜。而這種自我漸趨複雜的過程則稱為成長。乍聽起來變得複雜了帶有負面的味道,但是它還有另一個層面的意義,意味著不同部件的整合。就像是一部引擎是眾多零件所組合而成的,每個零件都有它獨特的功能,但是只有彼此相連結時,才能發揮出更好的性能。除了感受這種樂趣之外,還能增添我們的自信心,讓我們發展出更好的技能。

敏捷和心流

敏捷和心流之間存在天然的契合點,但在實踐中要實現這兩者的協同效應仍面臨挑戰。 例如,團隊成員可能因為技能不匹配、目標不明確或反饋機制不充分而難以進入心流狀態。此時每日晨間的站立會議便都是一種檢核的機會點,ScrumMaster可以觀察團隊成員的精神狀態,了解到阻礙他們進入心流的種種因素,藉此反應給主管或是運用引導來協助工程師調整挑戰或是提升技能,以更容易進入心流狀態。

敏捷開發以Sprint為週期,並鼓勵團隊成員在每日站立會議時以搶工作單的方式進行開發作業,主動選擇工作(挑戰),這一點讓工程師更容易進入新流的狀態。所以可以持續的觀察工作的挑戰性與工程師的個人技能是否匹配進行調整,某些挑戰甚至可以藉由團隊成員的互助來達成,就更有意義了。而SM 正可以以協助開發人員進入心流狀態為依歸(看來SM比任何人都更應該熟悉心流),並在團隊進行回顧會議時做好檢討與改善,期許團隊能擁有更少的中斷與更長的開發時間來追求開發者絕佳的體驗,也就是心流。

圖三、心流的五大因素

團隊領導和專案管理者需要持續關注團隊動態,確保目標清晰反饋及時,並且任務難度適當,以便團隊成員能夠發揮其最佳性能。上圖中的五個重要因素;是管理者不可忽視的心理狀態,並應該依據開發者所楚瑜的狀態適度的調整任務的挑戰程度,以期望與開發者的技能能夠相匹配,或是給予足夠的學習機會,讓他可以順利的成長。

心流模型與必要因素(Ted 演說)

感興趣嗎? 多做練習自然容易進入心流,註解中包含進入心流狀態的十個步驟。(註4. 參考自戴蒙.札哈里斯先生Damon Zahariades所著《實踐心流的零基礎練習》)

註1. 《心流: 高手都在研究的最優體驗心理學作者: 米哈里.契克森米哈伊    Mihaly Csikszentmihalyi

米哈里先生是美國心理學家,是「全球正向心理學研究的領航者」,四十多年前他觀察到,超過需求門檻的物質條件,再多也不會讓人感到快樂。於是,他開始研究擁有創造力或卓越表現的人們,像是藝術家、科學家、運動員等,釐清是什麼驅使他們不為名聲或財富,而為自我價值感與生命意義而行動。他發現,令人最感美好的幸福時刻,經常發生在一個人遇到挑戰他現有能力的事,他專注地將身心能力發揮到極致之時。在這種狀態中,人們會忘卻時間與自我,猶如進入「自動運轉」模式,由於這種體驗像是自然湧現,所以契克森米哈伊稱之為——「心流」。

這本歷經30 多年歷史的佳作,談的是人類最佳的體驗,但卻經常被忽略,在這裡藉著研究開發者最佳體驗的使命,再次強調它的重要性。

2. 在區: 在心流狀態下,英文通常稱為 “in the zone"。這種狀態描述了個人完全投入於某項活動,忘我地進行,同時感受到高度的興奮和成就感。

註 3. 米哈理教授以為心流能夠提升生活的品質。

註 4. 進入心流狀態的十步驟。參考自戴蒙.札哈里斯先生(Damon Zahariades)所著《實踐心流的零基礎練習》

步驟一、培養並遵循一套進入心流前的預備程序:這可以是一系列的習慣或儀式,幫助你的大腦準備專注於即將進行的任務,比如深呼吸、簡短冥想或檢查工作列表。

步驟二、找出你的精力巔峰時段:識別一天中你最有精力和最能集中注意力的時段,並在這些時段安排最需要創造力和專注力的工作。

步驟三、打造不會令人分心的環境:確保你的工作環境盡可能減少干擾,比如關閉不必要的通知,使用耳機屏蔽噪音等。

步驟四、定義清楚的目標:為即將從事的任務設定具體、可衡量的目標,這有助於指引你的專注方向和努力。

步驟五、確立內在動機:找到一個個人意義重大的理由來進行任務,內在的動機比外在獎勵更能驅動長期的專注和參與。

步驟六、做到單工處理:一次只專注於一項任務,避免多任務處理,這樣能夠幫助提高效率和質量。

步驟七、選擇具挑戰性(但是做得到)的事情:任務應該足夠挑戰,以促使你伸展自己的能力,但又不至於過於困難導致挫敗感。

步驟八、充分休息後,保持放鬆和清醒:保證充足的休息,確保你在工作時保持精神體力充沛,這有助於維持高效的工作狀態。

步驟九、運用心流時間工作法:可能是指采用像番茄工作法之類的時間管理技巧,這些方法通過設定工作和休息的固定周期來幫助人們保持專注和高效。

步驟十、創造回饋循環:為自己的進步和成就設定反饋機制,無論是通過自我檢查、同儕評估還是客觀指標,都能有助於你瞭解自己的表現,並根據反饋進行調整。 要實踐心流,重要的是找到適合自己的活動,持續不斷地練習和調整,以保持挑戰和技能之間的最佳平

軟體開發的復盤

軟體開發可能復盤嗎? 我們不大可能把程式碼倒過來重寫一次,即便真的重寫它了,這樣做有用嗎? 意義是甚麼?

復盤;是圍棋術語,本意是對弈者下完一盤棋之後,重新在棋盤上把對弈過程「擺」一遍,看看哪些地方可以有不同甚至是下得更好的地方。這種把對弈過程還原且進行檢討、分析的過程,就是『復盤』。為何下完棋之後要進行復盤呢?

因為重來一次可以學得最多

人們常常把復盤掛在嘴上, 誤把總結或記錄當成了復盤(註7. 復盤的誤區). 例如: 在處理Bug的時候,老闆總會要求我們一定要復盤,目的當然是避免它再一次發生,從追蹤到是哪一個功能出問題,是哪一段程式碼,又是誰負責的,修正後把它詳細的紀錄下來,做成案例避免下一次再發生。這樣算是復盤了嗎? 不是的,這樣只是針這個BUG進行了檢討,這樣做並不是復盤,因為復盤應該是全面的,自己親身經歷的,對於過去自己所做的假設的確切回顧,然後是確認自己學到了甚麼,將經驗轉化成自己的能力,這才是「復盤」;也就是以學習為目的,其他都是其次。

復盤的基本要素

它是你親身經歷的、而且事情剛剛過去、它驗證了什麼? (註1. 參考自邱昭良先生的《復盤+》)。這是對於一般事件所謂復盤的基本要素,但對於軟體開發它適用嗎? 要如何進行呢?

程式碼審核(Code review)是程式復盤的基石

大家都知道Google對程式碼有非常高的編碼標準(註3,Google程式碼審核指南)。Google的程式設計風格指南規定了C++、Java、Python、JavaScript和公司內部使用的其他程式設計語言的規範。這些指南定義了諸如空格和變數命名之類的細節,以及程式碼庫中允許使用哪些語言特性和程式設計慣用法。在你提交任何程式碼變更之前,必須至少有另一位軟體工程師對其進行審查,協助你進行 Merge的動作,驗證你所做的變更是否符合樣式約定,程式碼是否具有足夠的單元測試覆蓋率,以及是否符合Google的編碼標準。這種行為造成了團隊的協作,也打破了工程師獨自完成任務的危機(* 註2. 避免一個人的開發團隊)

圖一、Code review 是工程師靠程式碼與團隊進行互動的活動

一般code review時有二個需要驗證的地方,一是察看程式碼的 coding style 是否符合公司或團隊的規範(這個交給 AI 就搞定了)。另一個就是程式碼的行為;驗證它是否足夠簡潔且安全的解決了需求的要求。(註 4. Code review 的效益很多,請參考)

程式碼審核的行為規範應當由團隊共同來制定。但仍有幾個基本的問題值得討論。

  • Code review 時程式碼應該能有多長?

也就是請問程式碼審核人員(Reviewer)多長的程式碼你可以做好審核呢?

我的習慣是4頁(也就是4個電腦螢幕,假設每頁 30行,30 X 4= 120行的程式碼),超過了我就不想看了直接退件。(註5. 寫程式的對象是我進行調整的依據)

  • 看自己寫的程式碼容易,看別人的難

要下標題,說明這一段程式碼在做甚麼? 解決了那些問題。

圖二、Why? 應該列出需求(要解的問題)而非自己以為的功能
  • 要提供情境,運用紅、黃、綠燈的顏色說明自己對這串程式碼的看法。例如: 黃色;表示有疑惑沒有太多把握,請求審核人員協助驗證。
圖三、用紅、黃、綠燈的顏色表示情境

軟體開發為何要進行復盤呢?

目的是為了學到最多,同時透過程式碼審核(code review)的運作規範,讓團隊成員能夠相互協作起來,並落實專案開發流程與進行知識的分享。

圖四、需求決定開發效能

傑拉爾德・溫伯格說:『需求是設計前的質量』。這句話的意思是需求的可測性決定了程式在開始設計前的品質。

上面這張圖示,描述了程式開發的解題過程。描述程式設計人員的解題步驟與需求的排列順序不見得會一致,開發人員與需求撰寫人員的解題方法是不一致的(註 9.)。因此;程式設計人員應該對需求開發的種種盲點與疑惑先進行釐清,或是對核心部分以先行製作MVP的方式來進行驗證。在程式人員釐清開發盲點與疑惑後務必在與撰寫需求的人員進行需求的排序,以產出對專案最具有價值方式來進行開發作業。這正是程式開發團隊(Team)與需求撰寫者(PO)應該做復盤的部分。

圖五、上半部是開發順暢的部分,下半部則是不順暢的地方(後面是分數)

【 說明 】 這是一位程式開發人員在專案開發過程的體驗歷程圖,在第一個Sprint裡做了5次的 PR(Pull Request,註8.),其中第四次的不愉快程度最高達到-5分,需要進行復盤。另外;在整個專案的開發過程中,最不愉快的是位於中間下半部的-8分的PR,因為連續測試沒有通過(這裡或許有甚麼蹊蹺存在),也值得復盤,再來是已經Release 之後,遭遇Bug修復的這一次 -7分的不愉快,損失慘重,應該要復盤。復盤的時機點;是當開發遇到不順暢的時候,或是專案完成之後,都是回過頭來檢討學習到甚麼的好時機點。

小結

程式碼在開發作業中的code review 行為是團隊復盤的第一個情境,程式撰寫人應該負起說明程式碼情境的責任(對程碼做標題說明 WHY? 解決了甚麼需求的問題),審核人員則應該針對解決問題的方法給予回饋,以提出”如果 …會怎樣”就是what if 的提問方式來做回答,目的在造成當事人的反思,這樣做或許可以促成當事人想到更好的解題方案,或是避免掉將來可能產生的缺陷中。在必要時進行面對面的溝通,對學習更有幫助,形成教學相長。

復盤的第二個情境是針對需求的復盤

由於需求的來源是針對使用者的操作情境而來,它的排序方式是以協助使用者順利完成任務為出發點。而程式設計人員則是以整個專案開發的技術範疇為主,它思考的是盲點與疑惑(疑惑 Question,具有明確的答案(解法)但程式員目前還不知道如何撰寫程式的部分。而盲點Problem,則是指那些看起來就很困難、沒有標準答案的功能要求,要怎麼解題是沒有標準答案的,程式人員只能設法思考如何來解決這個難題的地方)

無論是疑惑或是盲點,都是程式設計人員依據需求的陳述和自己所擁有的經驗、技能進行評估後所產生的概念,中間難免會做了許多的假設,這一點;就好比對弈時猜測對方為什麼會下這步棋時的動機一般,需要事後印證來學得正確的經驗。復盤可以讓我們學到最多。當然針對核心部分的MVP開發作業的驗證,也是很值得復盤以充分學習了解的地方。

檢討與復盤的誤解

檢討的目的是不貳過,也就是不想再重複發生相同的錯誤。

復盤則是以學習為主,重點再找出更適合的做法。目的在於回顧和評估一個專案、事件或情況的過程和結果,以便於從中學習和改進。換句話說,就是從錯誤中學習。

圖六、二種復盤的情境

》》》題外話,我經常在Scrum的回顧會議時,常常會問工程師:

如果再讓你重寫這段程式碼,你會怎麼做呢? 這次你需要多少時間?

目的是用來提醒工程師反思開發過程用的(也希望他把方法講出來,讓團隊都能學習到),它不是復盤。是用來提醒工程師,小心第二系統效應(Second-system effect, Frederick Brooks 《人月神話》)。Brooks的解釋如下:

描述重寫功能時反而容易遭遇的困難,

當我們在重寫功能時, 因為看到了可以改進的地方, 因此促使我們忽略第一次開發時的謹慎態度轉而為更加勇敢的去嘗試, 因此而造成了程式的複雜性增加,

又以為自己作過了,由於過度的自信, 容易過度設計,使得工時反而容易延誤了.

因此,重作一次不見得會更快,但如果你因為完全按步就班的重來一次,速度變快了,卻反而失去了創新的意義。

由於意外填加功能而延遲了開發時間,卻學到了最多。

Brooks認為在完成一個小型、優雅而成功的系統之後,人們傾向於對下一個計畫有過度的期待,可能因此反而建造出一個巨大、有各種特色的怪獸系統。

(下圖顯示的是第一個版本可能存在的位置, 參考自DDD文件,註6. Dan North 提出了刻意發現(Deliberate discovery)

雖然你做了幾回,但依然有著相當的無知存在,而第一個版本可能只在中間。

註1. 參考自邱昭良先生的復盤+》(簡體字,無繁體版)

《復盤+ 把經驗轉化成能力》機械工業出版社(第3版)。

註2. 工程師要避免一個人的開發團隊
因為我們需要借助回饋来驗證自己所做的事情是否可行。
而且,獨自工作時,專案出現低谷時會讓人更加沮喪,更是求助無門。
雖然我大部分時間都是一個人在工作,也有許多講師朋友都是如此,但它大大的限制了我們的創意,因為少了可以給我們刺激的回饋,這麽多年過去了,沒出過甚麼大錯,只能説是幸運吧!還是我們所寫的程式,大多都是無關緊要的了。


雖然在很多情况下,我們必须獨立完成一個項目,但少了回饋也少了反思與激勵,或許省下了協作溝通的時間,但對專案或是個人真的損失更大。尤其是獨自埋頭苦幹往往再看不到風險,而降低了實質上的成就。

面對真正只需要一個人的專案,運用code review的方式來進行協作,或是指定 mentor 的方式來取得回饋。

註3. The CL author’s guide to getting through code review | eng-practices (google.github.io) ( Google 程式碼審核指南 )

註 4. 程式碼審查(Code Review)是軟體開發過程中的一個重要環節,它對於保障程式碼質量、促進團隊協作、以及加強知識分享具有關鍵作用。以下列出了程式碼審查的幾個主要好處,進一步闡述其重要性:

(1) 提升程式碼質量:審查過程中,審查者可以指出程式碼中的錯誤、不一致性、或是潛在的性能問題,這有助於在程式碼合併到主分支前修正這些問題,從而提高了最終產品的質量。

(2) 促進團隊標準化:通過程式碼審查,團隊成員可以就程式碼風格、最佳實踐和設計模式達成共識。這有助於團隊建立一套共同的開發標準,使得程式碼更易於維護和擴展。

(3) 加強知識分享:程式碼審查促進了團隊成員之間的知識交流。開發者可以學習他人的程式碼寫作技巧和解決問題的方法,新成員也可以通過審查過程更快地熟悉項目結構和業務邏輯。

(4) 發現潛在的安全問題:安全專家或經驗豐富的開發者在審查過程中可能會識別出潛在的安全風險,從而防止安全漏洞被引入到產品中。

(5) 促進團隊協作和溝通:程式碼審查過程鼓勵開發者之間的溝通和協作,有助於建立一種團隊精神和互相學習的文化。這種文化可以增強團隊凝聚力,提高整體的工作效率。

(6) 提早發現和解決問題:通過在早期階段發現和解決問題,程式碼審查可以幫助團隊節省時間和成本,因為修正後期發現的錯誤通常比在開發過程中早期發現和解決要困難和昂貴得多。

提升開發者技能:參與程式碼審查不僅可以幫助開發者學習如何寫出更好的程式碼,還可以提升他們進行批判性思考和構建有效反饋的能力,這對於個人職業成長非常重要。

註 5. 寫程式的人是誰,是我進行調整code review長短的依據

遇到越是沒有經驗,越是需要我們一步一腳印照顧的人士,就會更頻繁的進行審核,例如: 當寫程式是自己的親人時,為了避免bug出現時所帶來的痛苦(除非我們替他們寫,否則寫程式時的痛苦是無法避免的,但是! 我們可以運用更頻繁得code review 來解救它),我會更頻繁、更用功的為每頁程式碼做好審核。

註 6. Dan North 提出了刻意發現(Deliberate discovery) 在闡述專案開始之初我們對於專案的無知,應該想盡方法刻意的去學習它,以減少對專案目標的無知程度( 請參考無知的分級 )

註7. 復盤的誤區

  • 我們能夠為他人復盤嗎? 答案是不行的, 因為復盤必須是親身的經歷, 否則便是你或是他人自己的想像罷了.
  • 總結是復盤嗎? 復盤必須以學習為宗旨,因此單純的總結並非復盤.

註 8. Pull Request 是一種通知機制,是將涉及不同功能的程式碼,納入主幹的一種流程。這個過程中,還可以進行討論、審核和修改代碼。Pull Request 是開發者使用 GitHub 進行協作的利器,當使用者提供了程式碼後,讓審議者可以提出議見希望更改在併入官方專案之前,可以得到充分的討論。

註 9. 程式員的專案開發順序,千萬不要依照需求文件的順序,就盲目地依序開發下去,請設計自己的開發順序。應該先解盲點與疑惑,接著針對核心功能製作MVP,最後就是盡可能的完備整個程式開發了。

需求的撰寫者(po)是依照使用者操作介面完成功能的順序,思考如何在過程中協助使用者,而寫下的種種輔助功能,一般會依照軟體的某一項功能操作為順序。並非先考慮困難點,也就是程式的開發限制而做的排序,有關這一點;負責撰寫程式的開發人員應該在做完 Sprint的分析作業之後與PO重新討論一次排序,以追求對專案最有價值的工作先行開發。

從網路知識的誤導到質疑AI的正確性

前言

為了一場演講需要引用最近很紅的達克效應(DK effect ,註1.),卻發現原作者根本沒有把它畫成曲線(附上APA期刊上的實驗數據圖),而網路上廣為流傳的圖示則是來自 Gartner 在1995年發布的技術成熟度曲線(Hype Cycle) 真是一場美麗的錯誤(註2.)。

達克效應實驗圖示(參考自APA期刊)

圖示容易誤導無知

誤導我們的作者立意可能是為了採用圖示的方式來方便說明無知的可怕,但他卻忽略了網路以訛傳訛才是真正的可怕,結果反而置我們於無知之中。因此我們要有懷疑網路訊息的覺察性(Awareness),尤其在這個AI的時代裡,生成式AI增強了無知人士的信心,一旦他完全相信AI而不去求證,也正好是應驗了所謂的達克效應了。

謙虛與自信

達克效應二位原作者的立意是研究關於技能和信心的關係。他們發現,在很多情況下,人們意識不到自己的能力缺失。“達克效應”: 指的是我們在沒有能力的情況下,非常容易過度自信。上圖中的實線是測試前的預估,模糊線是實際測得的分數比。在最初的研究中,那些在邏輯推理、語法和幽默感測試中得分最低的人,對自己的能力高估的程度最高。平均來看,他們認為自己的得分比62%的同組人高,但實際上只比12%的人高。結論是;當我們在某個領域的能力越低,就越可能高估自己的能力。原作中並沒有所謂的”愚昧之巔”和”絕望之谷”這是對程式開發(初學者)學習過程的描述,請參考Why Learning to Code is So Damn Hard

認識到這種傾向之所以重要,是因為它威脅了我們的自我認知,並在各種情境下讓我們容易犯錯,尤其是位於管理的人員,更容易傾向於高估自己的能力。因為越是認為自己懂得多的人,越會高估自己,對學習和更新知識的興趣也就越低。它會妨害你的成長之路。

最大的敵人不是“無知”,而是認識不到「無知本身」

流傳在網路上的「知識」它已經被傳遞多次,也遠遠脫離本身應該具有的準確性;這就造成瀏覽者自己認為所了解事情的結果,因為它已經過一手再一手的加工(經驗)而形成差異和錯覺。

——

下面是我自己犯過的錯誤,是有關「學習金字塔」它其實研究的是Cone of Experience而非學習(我不敢再顯示圖片,因為圖片最容易誤導了)。

網路上盛傳;美國學者艾德格‧戴爾(Edgar Dale)提出了「學習金字塔」( Cone of Learning )的理論:在初次學習兩個星期後:

  • 透過閱讀學習能夠記住內容的 10%;
  • 透過聽講學習能夠記住內容的 20%;
  • 透過圖片學習能夠記住內容的 30%;
  • 透過影像、展覽、示範、現場觀摩來學習能夠記住 50%;
  • 參與討論、提問、發言來學習能夠記住 70%;
  • 做報告、教學、模擬體驗、實際操作能夠記住 90%。

美國緬因州國家訓練實驗室( National Training Laboratories )做過類似的研究,結論跟戴爾差不多。由此可知,閱讀是最沒用的學習方式,而模擬、體驗與實作才是最好的學習方式。這是真的嗎?
—–

但事實上戴爾的理論是 Cone of Experience ,主要是研究不同的「體驗」或「經驗」方式,而非針對「學習效能」做研究,更沒有提出明確的學習效能數據,數據的部分乃是被其他人加油添醋上去的。至於美國緬因州的國家訓練實驗室的研究無法查證,因為沒有人能證明看到過這份研究報告,網上也無法搜到相關研究論文,因此不足以作證據。

學到了甚麼?

現在你知道網路上盛傳的”達克效應圖示”和”學習金字塔的百分比數據”都是嚴重的誤導,然後呢?

重新思考 Think again

試問;自己是怎麼發現”達克效應圖示”有問題的呢? 因為自己要準備一場引用到它的演講,而網路上的曲線圖實在太完美了,我想找到原作者做實驗時一點一點畫出來的原始圖示,就是這樣的想法讓自己開始追究來源,途中發現它參加了哈佛學院辦的"搞笑諾貝爾獎"(註 8.),但疑惑的是二位心理學家都不是哈佛畢業生怎麼會去參加呢,後來才在APA期刊裡看到原始的報告,原來該實驗的數據長成上面幾條線段,完全不是網路上流傳的樣子。又;因為它和初學者程式開發歷程長的太像了,就去追一下”程式開發歷程圖”是怎麼來的,才找到 Gartner的 Hype-cycle 技術成熟圖,解鎖了網路上流傳的知識,就只能稱為「網路知識」,那些參與(歷經)修改的眾多作者們,在立意上可能都是好的,目的也只是在說明他們自己的思維模式,與實際上原作者的實驗結果的意義不見得相符,這一點應該是我們作為閱讀者自己要做判斷的。其實;我的發現一點都不稀奇,因為如果你在做 Google搜尋時多打上「錯誤」二字,就可以找到早就有有心人士給我們的忠告了,而且還會有很清楚的說明,最後還客氣的說成這是一種『美麗的錯誤』,實在是好人一枚,不得不稱讚他們一下,這不就是達克效應所要說的;大師者面對問題總是謙虛以對。正如老子道德經第四十一章所講的:

上士聞道,勤而行之;

中士聞道,若存若亡;

下士聞道,大笑之。不笑不足以為道

讀者;千萬不要一笑置之,而是要問自己從這件事上學到了甚麼?

重新思考(think again),學習一下科學家的精神,探究事實,

人生自然會更美好。

.

假設你走在海灘上,踢到神燈。神燈允諾給你全世界的知識,請問你會怎麼辦?

質疑AI的正確性

我喜歡用神燈的故事來引起聽眾們思考AI對他有甚麼影響。(這個問題如果你還沒思考過,那就先停下來想清楚,在繼續吧!)上面這張圖有二個錯誤的地方,也是希望讓讀者能再深入去思考。錯誤一、神燈的故事應該發生在沙漠中而非沙灘上。錯誤二、神燈不能給你全世界的知識。因為我們都是知識創造者,無時無刻不在創造新的知識,也就是說知識不可能有全部的。因此;神燈不能給你全世界的知識,只能給你截至目前為止的知識,因為知識正在飛快地湧現中尤其是這個時代。

因此;當你問AI問題時,首先要會「質疑AI給我們的答案」夠不夠好(not good enough,上面那張圖的剛剛好先生取名 Good enough正是這個意思)。該怎麼作呢? 我的作法是把它的答案複製到可以驗證的地方,如果是文字敘述,就重新編排(如果是程式,就作測試來驗證它)。讓它的說詞成為自己所能理解的文句描述。有疑慮時就去問另一個AI來作查證,試著扮演一下科學家的角色,假設它的答案不夠好,那更好的答案是甚麼? 試著找出來吧!

由20/80法則推演出來的good enough 觀念

Good enough 效應

義大利經濟學者Vilfredo Pareto發現在19世紀的英國的財務分配中,佔20%的人口享有著80%的財富。它說明了只要是有資源分配地方,你就用得上它。這就是著名的20/80法則(註 5.)。上面的圖示在說明由於AI的出現,讓機會變多了,那些80%的人士;原本沒有能力做到的工作,受到 AI的協助便能夠做到了。這造成了左側的剛剛好先生(這是我虛構的人士,他正好在20/80理論的前端20%左右的人士)現在掉出了原有的舒適環境。這正好解釋了AI出現後將會取代掉你現在的工作的恐懼症的一種說法。你只要維持在那20%的範圍內就不會被取代了,換言之就是鼓勵人們要去追求卓越,而不是作剛剛好先生。

Good enough 效應是雙向的,我們自己應該脫離剛剛好的思維,也要質疑AI所給的答案只是 Good enough而已,所以應該繼續去探索。探索在這裡意味的是更多的學習與創新的機會,因此在面對 AI時我們應該以學習為中心,而不是以獲取知識為主。下面的圖示在說明,我們因為AI的協助,省去到處搜尋答案的時間,就應該把剩下來的時間用在創新上頭,而創新的過程總是由模仿開始它也是一種學習的過程(註6.)。

面對 AI;我們應該以學習為中心

快樂的去創新吧!


註 1. 達克效應(DK effect)

註 2. Gartner 技術成熟度曲線

註 3. 參考自 『達克效應(DK Effect)的美麗錯誤 — — 對無知的無法認知:愚昧之巔、絕望之谷

中間是作者比較 Hype-cycle 與 達克效應的圖示

上圖的背景是我的演講資料(紀錄一下,該演講是Webconf 2023,10周年慶)。

註 4. 另一個網路上的誤導,我也是受害者,順道陳清一下,千萬不要被我從前犯錯的Blog文章所誤導了“學習金字塔的誤解“。該篇文章是談"3+3 scrum教學“。

註 5. 20/80法則又稱為Pareto法則,衍生出許多適用的地方,例如: 花最少力氣,得到最大效果 叫做「80/20法則」。所謂的「80/20法則」,是指在原因和結果、努力和收穫之間,普遍存在著不平衡的關係,譬如80%的利潤由20%的顧客帶來,80%的財富集中在20%的人手中。

註 6. 《奔跑吧,程式員》作者是葉夫根尼·布裡克曼,它是簡體版的繁體書沒有找到。書中以軟體開發的角度介紹了創業公司該如何打造產品、實現技術和建立團隊,既是為創業者打造的一份實用入門指南,又適合所有程序員系統認識IT行業,我很喜歡這本書可惜已經版了,但可以買電子書。

註 7. 《重新思考》(think again)亞當.格蘭特出版的思維佳作。台灣翻譯成 逆思考。是這個多變時代對於網路知識對錯不可多得的思維好書。書中談到每個人都習慣以最舒適的方式思考,不願懷疑或挑戰自我,因為「質疑」會讓世界變得難以預期,甚至威脅到自我認同,於是,我們的成見不斷延續,聰明成為盲點,害怕改變的「順思維」讓我們選擇劃地自限。非常值得一讀。批判思維(critical thinking) 就是名稱聽起來就討人厭,因此不是太受喜歡順勢者的歡迎。

註 8. 搞笑諾貝爾獎由科學幽默雜誌《不可思議研究年報》主辦,授予「乍一看好笑,後又引人深思」的科學領域十大成就。該獎約於每年九月在哈佛大學桑德斯劇場舉行,隨後會有獲獎者在麻省理工學院進行公開演講。評審委員中有些是真正的諾貝爾獎得主。 而搞笑諾貝爾獎每年都會舉辦,但是每次都稱自己是「首屆」(如:The 31st First Annual Ig Nobel Prize Ceremony)。

達克效應的二位作者獲得了 2000年的心理學獎。

Wiki圖片來源

精實價值樹 Lean Value Tree

.

Lean Value Tree,LVT精實價值樹

LVT為 Jim Highsmith 先生在他 2019 年的新作《EDGA:價值驅動的數位化轉型》(註1.)書中所提出的企業轉型 EDGE方法中的一個工具,它是一個用來規劃的工具,可以捕捉和共用組織願景及配合戰略。這裡的EDGE不是縮寫,指的是運用Lean與 Agile的思維來解決Edge of chaos (混沌的邊緣;註2)以適應多變的情境,它的目的是提供給企業一種適應VUCA時代的運營模型。

Jim Highsmith 先生提出LVT的目的是希望幫助企業釐清轉型的願景、目標、投注與舉措,實踐真正的數字化轉型,而依靠的是改變組織文化,而不是依靠構建更大的東西。例如: 去追求更大的敏捷架構等(原書1.2節敏捷是足夠快的關鍵)。


制定個人發展的精實工具

這裡介紹精實價值樹(LVT)的目的,是提供給公司學員在進行OKR設定之前,應該先運用LVT來制定個人發展計畫(IDP: Individual Development Plan,註4.)所做的前置動作。因此,本文會專注在制定個人發展規劃的精實價值樹。但我們還是先來看一下原著的說明。

企業轉型 EDGE方法的實用工具: LVT 精實價值樹

》》》針對組織規劃

•    頂層是「願景」Vision,描述組織在完成成功的投資之後的未來理想狀態,可視為組織的總體指導方向,所有投資都應為其做出貢獻。

•    第二層是「目標」Goal,描述組織達成願景當前階段所要達成的業務目標,體現組織的競爭策略和發展策略。

•    第三層是「投注」Bet,描述為了達成某個目標,當前能想到的最好的點子或創意,是一個假設,有待驗證和調整。(其實敏捷採用小增量、快速衝刺的目的就是一種Bet,目的是為了盡快弄清楚,然後才好持續調整方向。)

•    第四層是「舉措」Initiative,定義為落實一個“投注”所要進行的具體行動,例如: 計畫開發新產品的何種特性。

目標“是一個企業高層所用的可度量的戰略目的,典型持續時間為2~5年;"投注“(投資方案)是一個針對"目標"實現的假設聲明,將商業戰略與產品策略和實施進行分離,允許組織以紀律的方式了解市場,並基於所學到的內容採取行動推進戰略,其典型持續時間為 6~12個月;推進"投注“的工作包含在一個"舉措“(行動方案)中,"舉措"的典型持續時間為1~6個月。

用關鍵成效度量MoS(Measure of Success)來做度量,Jim Highsmith 先生針對企業化規模;以目標、投注舉措上都需要有MoS的度量,並以業務相關的成效結果做為指標。書中是以MoS為成效衡量的指標,但運用在個人身上若能以OKR的方式來解讀的話,除了可以作為衡量指標之外,又多了一種激勵的效果,就更理想了。所以這裡就採用關鍵結果(Key Result)的達成分數來做為衡量成果。拿精實價值樹LVT作個人計畫,實質上又可以稱為IDP: Individual Development Plan:個人發展規劃。是一種 HR所專注的職能。

.

Jim Highsmith稱它為一棵小而美的“樹”——精實價值樹。(註3.)

.

要設定個人的OKR,就從先完成個人的生涯規劃(LVT)開始

在學習設定OKR之前,你得先有人生目標才行,你應該先想好自己人生的願景是甚麼,然後才好在進一步去設定(階段性)目標,接著才是去設定關鍵結果。而不是盲目的去追隨主管或公司領導層的目標。因為實施OKR的目的:「對公司而言是追求成果、效能, 對個人而言則是追求成就與幸福」。所以你在制定自己的 OKR時,除了要對正公司、主管或團隊的目標之外,也應該思考一下自己的人生目標。至於要怎麼思考呢? 這裡推薦LVT的方法,也就是先繪製「精實價值樹」,透過他來檢視自己現行的種種目標(工作、生活上的目標)是否與你的願景有關聯,沒有的話它的急迫性就應該下降些,越是有關聯的,越應該排在前面優先去做。(抱歉;我一開始就假設你對OKR十分熟悉,如果還沒有機會涉略它的話,建議先找一本OKR的書快速瀏覽一下,入門我推薦 Christina Wodtke 所寫的《OKR 工作法 》,進階的話建議 Ben Lamorte 的《OKR教練實戰手冊》)

LVT可用於組織,但是以OKR的觀點而言應該先用於個人

》》》對於個人而言

•    頂層是「願景」Vision,描述個人對於未來所想取得的成就,用來制定(抉擇)指導今天我們所做的種種努力的方向(要知道自己想成為甚麼樣的人是一個動態的目標,隨著年齡的增長,變動是在所難免的,但明確地把它寫下來則是第一步。)

•    第二層是「目標」Goal,對個人而言;是制定階段性的目標,讓完成這些目標能夠協助我們一步步的累積為我們所追求的願景。當然;未必所有的目標都能與願景相符合,因為雜務總是不能避免的,況且我們常常會勉強自己或是為了別人去做一些自己不想做的事,沒有設定目標的工作就無法衡量,因此陳列出來可以做為參考,用來衡量我們為達成目標所做的努力應該是多少。有一句話說得對極了,「我們的人生經常是為別人而活的」,那些為別人而不為自己的時間花費,便可以在這裡看出來。自然也看得出來那些目標是為五斗米折腰而來。

•    第三層是「投注」Bet,是一種完成上面所設定目標的假設,映射到敏捷思維上就是運用對目標(小增量)的假設來作為衝刺結果的衡量與路徑修正的依據。就是以目標為前提當前的機會、創意是甚麼。例如: 試著想想自己接下工作的目標應該如何度量?自己可以投注的機會點又在哪裡?為獲取那樣的機會,應該有怎樣的行動(舉措)?

•    第四層是「舉措」Initiative,對於個人而言;可能是完成一項任務或是學習一項新的技能的行動方案(我準備怎麼做)。在行動之前先靜下心來,想清楚;對於自己的初心還是不是要堅持下去或是應該修正呢?我有多少資源可以運用?我的優勢是什麼劣勢是什麼?如何來彌補? 如果想要一次到位,該怎麼做?靜下來想一想,計畫一下該怎麼開始?

精實價值樹可以協助你建立一顆小而完整的樹狀目標規劃,尖端則指向你的未來願景。它不但能夠聚焦又描述了具體可行的計畫,其實是讓你有機會想清楚,計畫一下該如何來進行你的工作,是運用系統思維(看見全貌)的方式,敦促你擬定工作計畫並開始執行。

個人精實價值樹可以用來做什麼?

  • 進行檢討改善

製作精實價值樹LVT,可以讓你在系統化的看見全貌後進行檢討。

  • 制定OKR的時候?

設定目標關鍵結果時,你有了目標也設定了結果的驗證標準,但是具體上你準備怎麼做卻並未提及。所以你需要有具體的行動方案,而LVT正可以彌補這一缺失。讓你思考針對關鍵結果的指標,你需要投入多少資源來獲得預計設定的成果。

  • 讓你可以同時聚焦長、短期的目標

為願景而設定階段性目標;是針對長期的目標。為階段性目標而設定投資方向,則為短期目標的聚焦。讓你不至於迷失在勞累的工作中,而仍能朝著目標前進,並時時進行改善。

為什麼要使用精實價值樹?

  1. 既簡單又輕量:它非常簡單,不像想一些策略規劃工具,需要花很多時間來培訓學習。願景 – 目標 – 投資方向 – 行動方案,這就是基本邏輯,一點不複雜。
  2. OKR式驅動成效:無論是目標、投資方向和行動方案,都很務實而不是空談。
  3. 讓KR顯示努力的成果,產生自我激勵:運用關鍵結果的設定方式(最佳衡量成果0.7),形成自我激勵。
  • 落實OKR的思維:第四步的行動方案,對應到關鍵結果的設定。例如: 想要KR#1的成果達成0.7的時候;我需要怎麼制定怎樣的行動方案。達成0.5的時候;我又應該怎麼做,才能做到。這個時候預定可行的行動方案便出來了。

※ Bet 在書上翻譯成投注,我用"投資方向“取代,initiative翻譯成舉措,這裡則用採用"行動方案“。目的只是為了讀起來比較順暢而已。


種一棵樹最好的時間是在十年前,其次就是現在。

-Dambisa Moyo

意思是; 只要你興趣還在,可以一直做,什麼時候都不會晚; 種一棵樹最好的時間是十年前,其次是現在。只要你心裡有信念,沒有時間的差距,什麼時候開始都可以。


讓預計達成的KR# 衡量值,對應到 行動方案A/B/C

小結

精實價值樹LVT可視化了OKR的目標設定,同時也解決了設定關鍵結果時沒有思考對應行動方案的作法。如上圖中,KR#1. 達成結果0.7的項目對應方案是行動方案A(預設)。達成結果0.5時的對應方案是行動方案B。思考方式是;我預計要這麼做(行動方案A)才能做到0.7的成果,讓你依據對自己所期待的結果進行反思,我要花費多少資源、要如何去執行才能達到這樣的成果。所以對有挑戰性的工作目標(0.7)的設定就可以做為一個好的預設值,而這也表示了你有接受挑戰的意願。相對的;當你認為這個目標並不是一個重要的工作時,關鍵結果設定的可能值就有可能落入 0.3到 0.5之間了。

繪製 LVT,就是要你在做事之前;先想清楚

我們在開始時先說明了 Jim Highsmith 先生針對組織願景/戰略設定所創建的精實價值樹。接著描述了如何將LVT運用到個人的目標設定上。然後將OKR與LVT相結合。最後再將關鍵結果設定的衡量值對應到 LVT的行動方案層,用來具體化所預定的行動方案。

與願景無關的目標

在繪製了LVT這棵樹後,首先是聚焦;透過可視化的圖形讓我們更容易審視目標與願景之間關聯性或比重,它讓我們思考自己的目標規劃是否與自己的願景有關,如果顯示的是眼前目標與自己的願景無關時,就要思考把這個目標延後或是思考它是否值得我們去作了。拿它來做為目標排序的依據,也就是對未來願景的達成的影響越重的目標,應該先作,自然對我們達成願景越有幫助。這個道理很簡單,運用在組織的業務與產品的開發上也有著相同的作用。

對於個人而言;審視一天或是一週的工作是否與目標有關聯,這是OKR之所以具有強大威力的主因;就是聚焦。大家都知道聚焦有多重要,但偏偏東作一點西作一下,喜歡多工是人的天性,但將很多(不同目標)的工作同時進行。無形間分散了自己的心力,也忽略了自己在聚焦之下;所可以表現出來的能耐。

以終為始;預設行動方案的資源運用

【說明】

前二格欄位是OKR的目標與關鍵指標(key result)的設定它指向未來的願景,我們再針對預期的表現結果(評分之後)再置入「行動方案」的欄位,並為此行動方案對應到評分高低,設置相對運用的資源(時間、精力)。整個行動方案就是針對關鍵結果的表現所設定的,它可能是時數、也可能是知識、技能或是其他對目標具有影響的行為。這種做法可以為OKR設定時增加了實質性的幫助,就是符合系統思維的可行計畫,我們稱之為行動方案(Initiative,舉措)。(有關分數的設定請參考: 註5.)

LVT運用在組織業務上頭,當我們在規劃產品的功能需求的時候,也應該以達成組織願景為依據,尤其是進行多個團隊的協同開發作業時,大家都有自己的目標要攻克,往往容易因此而失去對焦,畫一棵樹讓可視化協助我們對焦。應該對越有幫助的需求先作,把它們陳列出來、透過可視化的圖形,協助我們更容易作業務與開發作業上的規畫或排序,如此也符合先做重要的事(first things first)的原則。


註1. 簡單的說明一下《EDGA:價值驅動的數位化轉型》書中的一些重點:

Jim Highsmith並未像許多敏捷人士一般,紛紛轉向大型敏捷化的流行風潮,它反而在需求不斷增加之下,要求企業將客戶價值放在第一位,以實踐願景為依歸的規劃企業的目標(採用Lean Value Tree),依此確實的實踐敏捷宣言。並細緻到以Mos(Measure of Success) 去衡量投資是否達標,觀點既抽象又十分務實。

  • 再次詮釋敏捷軟件開發宣言:個人和交互高於流程和工具。可工作軟體優於文件說明。與客戶協作優於合同談判。響應變化勝於遵循計劃。
  • EDGE運營模式(Connecting strategy with delivery): Vision & Delivery of Value
  • 數位化要關注的是“更好”而不是“更大”。
  • 響應式的組織(類網頁的響應式RWDResponsive Web Design組織型態):
  • 執行願景/業務戰略 —組織生態系統 —衡量價值 —敏捷交付 —投資組合管理/產品架構。
  • 擴展客戶價值是當下成功的關鍵。提升適應性則是未來的關鍵。
  • In Digital:業務關注客戶價值,技術關注速度/適應性。
  • 技術雷達(替Thoughtworks廣告):適應、試用、評估、持有。
  • 技術債務和變更成本(CoC)
  • 精實價值樹:願景、目標、投注、執行
  • 產品是向客戶傳遞價值的載體。

註2. 混沌的邊緣 (Edge of chaos)

混沌的邊緣是一個用來形容由計算機科學家 克里斯多福·蘭頓 所發現的現象。

混沌邊緣是介於有序與無序之間的過渡空間,假設其存在於各式各樣的系統中。它是一個有邊界且不穩定的區域,會動態的在有序與無序之間進行變化。

註3. Thoughtworks CAC 敏捷教練 一份培訓的文章。

註4. 個人發展計畫IDP(Individual Development Plan)與公司對員工的期待之間的差距 (參考自MBA智庫百科,傳統製作IPD的做法)

當我們放一面鏡子在員工面前的時候,他會清楚地看到自己的優點和不足,以及與理想值也就是公司要求的差距,為了員工的均衡發展,個人發展計劃通常涉及很多方面,以市場營銷人員為例子從幾個角度來設計:

  •   1、 專業知識,主要是市場營銷知識,如市場細分,市場調查,市場分析,市場計劃等相關的技能。
  •   2、 技術知識,從事某個行業的工作所必須具備的技術知識”如技術動態”發展趨勢等。
  •   3、  產品知識,對本企業或本人負責的所有產品有深入的瞭解,能出色地向用戶和潛在用戶介紹本企業的產品,明白與競爭對手產品的差異性,適用性以及優缺點等。
  •   4、 市場知識,如本企業參與競爭的市場環境怎麼樣,競爭對手情況如何,本企業的競爭優勢體現在哪裡,本企業的弱項是什麼?
  •   5、  用戶知識,我們能否清楚地描述目標用戶是什麼樣的人士,他們的各種需要分別是什麼?消費者非買不可的理由是什麼?我們的產品能幫助用戶解決什麼問題?
  •   6、 溝通能力,作為一個市場營銷人員,溝通能力至關重要,表現在幾個方面,如書面表達能力,寫作的文筆,講演的水平,外語水平等。
  •   7、  人際關係,因為市場營銷人員經常處在組織協調核心的位置,所以如何與各種人打交道,如何利用有限的內部資源和外部資源來完成任務將決定工作的效率?
  •   8、組織能力,指舉辦各種内部會議,對外宣傳活動,展覽會,講座,促銷活動的能力。
  •   9、 決策能力,指組織材料,歸納總結能力,分析做事情的優先順序,向公司領導提出建議和初步決策。
  •   10、 對於管理人員來說,還有一個領導藝術方面的衡量標準。不同企業,不同崗位當然可以自己決定其衡量標準。

 綜合以上論述,只要員工通過 “照鏡子" 找到了自己的差距,他們會積極努力改進,並根據改進的優先順序,挑出幾個主要方面重點突破,制訂相應的時間表,這樣就為下一年參加什麼培訓,讀什麼書”上什麼課”參加什麼活動打下了基礎,明確了方向。當然一個好的公司要配合員工的學習,支持他們參加各種培訓和學習,包括提供資金和時間,這是企業人力資源方面的主要投資,比發獎金更有價值。對企業的長久健康發展非常有利。

上面描述;是一種理想的做法,如果能採用更有效的工具,例如運用精實價值樹LVT加上OKR的運用,來進行IPD規劃,透過可視化並經常進行檢驗便成為邁向未來的指標,而不僅僅是一面鏡子,也就成為了既符合精實又敏捷的規畫方式。

註5. 關鍵結果 KR 的評分標準,必須設定成具有激勵作用的指標。參考: 運用OKR來量化Sprint的目標。
0.7是一個最具魅力的標準,因為它值得我們後續的期待。

註. 衡量成功 Measure of Success, 可參考: 什麼是成功的衡量標準?衡量成功的 10 種方法

啟動工程師創意-開發左移


開發為什麼要左移?

藉由開發者提前介入問題的討論來啟發創意。

-工程師的創意


這裡所謂的「開發左移」指的是Developing Shift-Left,讓開發者提前在問題尚未被寫成需求之前,就參與問題的討論與剖析 (而不是將網頁應用程式 web application由前端執行大部分的邏輯運算,改從由後端執行的Shift-Left Development)。當我們遇到棘手難解的問題時,可以運用開發左移來增進創意。又稱之為「Ask your developer?」

創意始於對問題的深入了解

我們經常期望工程師能夠有發揮創意的表現,但卻總是把規格已經定好的需求交給他們,這時候他們唯一能做的事也就是對既定的需求進行拆解罷了,那來創意! 雖然敏捷開發要求工程師在看到需求時,一定要先問Why? 不要在不知為何而作的情境下就一頭鑽入開發工作。但這樣做並不能夠換來創意,若是我們能夠在問題尚未被寫成需求之前,就讓負責開發的工程師能夠參與問題的討論與剖析,不但能夠確認工程師充分的了解問題所在,更能夠讓他有機會參與需求的討論與撰寫,也實踐了「向開發人員提出問題,而不是解決方案。」(註1. 參考自《Ask Your Developer》)

分配問題而非任務

開發左移;我們應該給出詳盡描述的問題,而不是任務導向的片段需求。對於工程師而言;我們應該要藉此觸發他們頭腦裡的智慧和想像力,而不僅僅是要求撰寫程式的技能。讓他們直接的面對問題而非需求文件;此時他們將面對的是無盡的機會,而那是“一個不缺目標的環境”。這是一種充滿創意的思維,也是一種最佳的開發者體驗。

如果我們給的是問題而不是一塊片狀的需求,讓工程師自行去剖析問題,而創意就是這樣會發生的。創意與解題就發生在這種新的工作方式,它讓員工感到快樂,並使他們能夠在工作中充分施展能力,並獲得成就感。(我覺得對孩子們也該是這個樣子)

擁有工程師的背景,看到問題就能即刻去做

LinkedIn 的創始人數只有五人,而且全部都是工程師。Facebook 的創始人數只有2人而且他們只是學生,是後來才成為工程師的。傳奇的亞馬遜創始人傑夫.貝索斯是電機工程以及電腦科學學士。更別提微軟的比爾·蓋茲與保羅·艾倫二位工程師了,當然我們也不能漏掉已故的史蒂夫·賈伯斯更是偉大的創意者。遇到真正想要解決的問題,然後發揮創意努力不懈的思考解題,正是上面這些工程師的寫照,值得後人效法。我們不該扼殺工程師真正面對問題的機會,哪種思維與創意是無價的,雖然創意往往不會在一夕之間就誕生,但如果沒有開始哪來期待呢?

讓工程師介入問題討論

現象可能是: 我們會對一個團隊直接說,『這只是個很初步的想法,這個樣子;大致是我們期待得到的結果或是想要建構的東西。麻煩一下,請把它搞清楚這是你需要承擔的責任』。然後由他們決定如何解決問題。我們可能還需要與他們來來回回地進行多次討論,但(必須明確化)說明這個專案是他們的。

讓開發人員能夠深入了解真正的問題,然後讓他們滿足它,這就是提出問題的意義所在。因此我們應該在問題出現之初,在過程的早期,在定義需要解決的問題時,就將工程師包括在內。所以PO的動作應該是,向工程師或團隊提出問題,並要求工程師根據現有系統(數據結構、程式碼架構)的資料傳遞方式,幫忙找出解決問題的最快方法,而不是向工程師提供已經定義好的解決方案,然後跟他們說甚麼時候要。其中的差異不言而喻,只有擁有解題的充分動機才會有精妙的創意解題

傑出軟體來自對問題的初期創意

這裡所謂的創意;指的是「對一個問題不僅可以很好地解決它,而且還能高效的解決它。」想獲得它;要怎麼作呢? 描述如下:

把怎麼作交付工程師,也就是把責任交給了工程師

結論變成我們向工程師提出問題,問題:「我們會對一個團隊直接說,”這只是一個想法,大致上是我們期待得到的結果長成的樣子。麻煩你把它搞清楚,一切就交給你了”。然後由他們決定如何解決問題。」當然;我們可能得來來回回地多幾次討論,但這個專案的解題方案是他們的了。當他想出了解題的方法時權力也就跟著誕生了,工程師對自己所想出來的辦法,當然會視同是自己的責任,而我們只要確認他能有足夠的權力去完成它便是了。動機才是真正推動他盡心竭力完成任務的來源。那些充滿創意的傢伙(被我們稱頌的技術大牛們),在事後接受訪問時,通常都會直接陳述:『為了克服難題,那是一種瘋狂的行為,我實在不知道自己是如何做到的,但下不為例。』

當遇到棘手難解的問題時,可以運用「開發左移」來增進創意

【說明】

頭腦風暴法(Brain Storming,BS法)、或自由思考法、集思廣益法。是一種腦力激盪的方式,目的是集思廣益;希望藉由群體的智慧,對問題能夠獲得更好的解答。想要開好腦力激盪的會議,需要依據一些規則跟精心的規劃(註2.)。所謂的開發左移;是指在問題出現的初期,讓開發者(或是在額外的邀請專家來參與)與PO(負責撰寫需求的人)一起坐下來思考、討論如何解題。此時PO以提問的方式(客觀引導)來讓工程師能以專家的立場(由形成概念到產出構想請參考水平思考)一同參與思考解題。這裡列一下讓開發者參與頭腦風暴會議的優缺點,值得多加注意:

優點

  • 可以即時提供技術專業知識:可以為討論增加實用性和深度。
  • 系統思考: 工程師通常具有系統思考的概念, 可以從整體和長遠的角度思考問題。
  • 創新思維: 可以提供新鮮和創新的想法。
  • 解決問題能力: 可以為討論提供更實際的解決方案。

缺點

  • 專業術語的困擾: 工程師喜好使用專業術語, 可能會使其他參與者感到困惑。
  • 過分技術導向: 工程師容易更專注於技術層面, 可能忽略要解決的是商業問題。
  • 專注自己的技術: 工程師可能因為本身具有某種技術, 可能會忽略採用其他技術的優點。
  • 時間限制 : 工程師本身經常處於高壓下工作,開會時可能不會全心參與(覺得在浪費時間)效果自然不佳(沒有專注,就不會有創意)。
  • 商業領域知識不足: 工程師在問題領域可能缺乏專業知識,會造成阻礙。
  • 溝通問題: 工程師一般不習慣在人多的會議中溝通或表達自己的想法。
  • 過於專注於實現: 工程師可能更專注於實現需求(因為過往都是收到需求就開工),而非思考可能的選項或創新的解決方案,需要有人進行引導的動作。

小結

遇到棘手的問題時,請去問你的工程師。你可能只需要在一旁靜候就能獲得有創意的見解,或許有時需要你推波助瀾一下,有時候你還需要提供一些支援。而這便是機會,一種藉由改變流程的方式,讓「開發左移」的做法,給予工程師有著創意解題的機會,讓工程師有機會充分發揮他們的聰明才智。而不是僅僅要求他們有足夠的程式開發技能就夠了。這二種方式比較起來;一個只要接收需求,再按需求解題就達成了(技能)。另一個則充滿挑戰,工程師需要自己去面對問題,想出屬於自己的解答(創意+技能),當然要具體完成任務可能還需要團隊其他成員的協助。雖然他有可能是(技術)獨角獸,但團隊的力量更能產出輝煌的成就。

人們總是會喜歡自己的想法,無論它是好是壞。要讓工程師們產生主人翁的責任感,還有什麼比讓他們自己想出解決方案更好的方法呢?當我們這樣做的時候,他們會勢不可擋地向前衝。這是開發者左移的想法來源。而你真正應該在意的是開發人員是否真正了解客戶問題,還是他們只是被要求實現某種解決方案。

.


註1. 參考自《Ask Your Developer》by Jeff Lawson 第四章 代碼之中有創意

節錄一段強調工程師的創意本能

在2020年春,特維利奧調查了全世界大約1000名開發人員,詢問他們和他們的經理如何看待他們在公司中的角色。調查的結果很說明問題。超過66%的開發人員認為他們的創造力高於平均水平,但只有50%的人表示,他們的工作需要高於平均水平的創造力。唔! 這難道不值得深思嗎。那麼開發人員是如何使用他們過剩的創造力呢?許多人在工作之外找到了出路:48%的人說自己的愛好以設計為中心 (如建築、家具、網絡),32%的人說自己在業餘時間創作美術作品 (繪畫、雕塑、陶瓷)。 哦,還有另一個打破刻板印象的結果:開發人員非常熱愛運動!36%的人愛跑步,33%的人愛騎行,28%的人愛打籃球,還有25%的人是徒步旅行者!

對於這樣的開發人員來說,交給他們一份“產品需求文件”,詳細說明要構建什麼將是對他們巨大潛力的浪費。這就是為什麼我們應該:

向開發人員提出問題,而不是解決方案。

註2. 如何開好腦力激盪會議

敏捷開發有需多工具都適合進行腦力激盪,例如使用者故事地圖、影響地圖。一般都交由Scrum master 來主持。但它真正需要依據你的團隊特性,再遵循一些規則才可能做得好。

  1. 確定會議目的: 確保所有參與者都明白會議的目的和期望的成果。
  2. 邀請適當的參與者: 確保邀請的人能夠對會議的議題有所貢獻。
  3. 安排會議時間: 選擇適當的時間, 以確保參與者能夠參加會議。
  4. 安排會議地點: 選擇適當的地點,確保會議順利進行。
  5. 準備好討論議題: 準備好一些議題,讓大家有東西討論。
  6. 使用一些激盪會議技巧: 如使用思考時間, 隨機匹配小組, 提問等方式激發思考.
  7. 確保記錄會議結果: 確保會議結果被正確記錄並整理,以便後續跟進。

而讓開發左移則是另一種獲得創意的方法。

水平思考Lateral thinking

.

敏捷開發經常要求工程師,遇到講解需求的時候,第一件要做的事就是提出疑問(Why?),一定要先質疑,然後透過討論來釐清需求真正的面目是甚麼?拿此來避免誤解和遺漏。但我們卻沒有教工程師要如何去問? 要他們自己發揮,而這需要創意,而水平思考的工具箱(註2.)正可以拿來彌補這塊空缺,以避免限制工程師的開發能力。

運用九宮格思維區分水平與垂直思考

圖中右側顯示的是垂直思考,是有邏輯性的思考方式,又稱為「邏輯思考」,右側的金字塔圖示,顯示它主要是以演繹及歸納的方式來進行(請參考如何問出好問題),因此各個格子之間具有關聯並表現得嚴謹而有序,過程呈現線性的關係,又可稱為有序性的思考或是螺旋性思考。左邊的九宮格呈現的是水平思考,是愛德華先生為了與垂直思考相對應,所以取名為「水平思考」。是運用自由聯想的方式所產出的發散性思維,在九宮格中你可以無序的填入與問題相關聯的種種聯想,向四周呈放射的方向射出,意思就是「你想到什麼就填上去」。沒有一定的填寫順序,主要的思考方式是發散性的思維。這種發散的思考方式會延伸你的思考到達你平時較少觸及的地方,進而孵化出過去沒想過的選項或答案。因此又可稱為創造性思維方式,它經常可以協助我們找到問題的最佳解。

要怎麼開始呢? 你可以依循左側的三個指標,分別是質疑替代方案刺激來做為思考的方向。就是;想到甚麼替代方案就把它填到九宮格中,想提出甚麼質疑,也可以把它填到九宮格中,這便是水平思考了。這些與主題之間有著自由關聯的主題,都是你運用水平思考所獲得的題目,你可以接著再個別運用有序的邏輯思考來做進一步規劃及探索細化的構想。它說明了水平思考與垂直思考是相輔相成的。也就是說;水平思考適合由不同的思考方向來產生新的概念,而垂直思考則適合由既有的概念來產生細化可實踐的構想。

程式設計師擅長邏輯思考,但不能沒有水平思考

是的,工程師不能不會水平思考(Lateral thinking)。水平思考是指對問題進行解決時,能夠從多個不同的方向、角度去思考,而不是僅僅停留在一個單一的解決方案。因為有許多工程問題都十分複雜,涉及到多個不同的系統和技術。因此,工程師需要能夠從不同的角度去思考問題,以便找出最佳的解決方案。


人類的思考方式分為兩個階段:第一階段為“知覺篩選”(perceptual choice),即先在腦中將信息分門別類,再將感知到的事物互相結合,產生各種概念與想法之後便進入第二階段,運用邏輯有效地處理,驗證想法的正確性與可能性。

-愛德華·德諾


此外,水平思考也有助於工程師更好地理解問題的根本原因,並從中學習新知識和技能。同時,水平思考也能幫助工程師更好地溝通和協作,因為他們能夠更好地理解其他人對問題的看法,並從中獲得新的靈感,找出最佳解決方案。

當工程師面對問題時,能夠採用水平思考的方法有許多好處。它能夠提高解決問題的效率。透過從不同的角度去思考問題,工程師可以更快地找出最佳的解決方案。

運用水平思考的優點

寫程式就是邏輯思維的表現

寫程式就是在做邏輯思維的表達,它完全依賴我們的創意設計,我們要先對需求產生概念之後,才可能進行拆解成更細部我們可以實作的功能組件,而寫程式的目的就是要完成各個組件的功能實踐,最終再將他們合併起來形成具體的服務。它完全符合二階段的思考模式,先是進行知覺篩選,然後是運用邏輯有效地處理,來驗證這種想法的正確性。前半段我們需要的是發散的思維,後半段則是嚴謹的邏輯思維。因此水平思考與邏輯思考的關係是相輔相成的,而我們一般卻只強調邏輯思維,而輕忽了起步時的方向是否正確,這正是敏捷開發為何要求工程師在遇到PO講解需求的時候,一定要提問的原因。

水平思考 vs 垂直思考

運用垂直思考,我們可以通過一系列合理步驟得出結論。因為步驟正確,人們對結果的正確性有一種盲目的自信。但無論路徑多正確,出發點都是某種感性的東西,這一出發點影響了過程中所使用的基本概念。例如;想看電影時,合理的邏輯思維是先找到想看的電影,再挑選電影院,然後決定怎麼去。這時候電影院給你的印象可能會左右你的選擇,造成你挑選了距離比較遠的電影院。這便是感性的影響,它是垂直思考所觸擊不到的思維。


在作水平思考時,人們不是因為信息本身而使用信息,而是因為信息能帶來的結果去使用它們。在過程中,我們可能需要在某個階段故意犯錯,才能得到正確的方案;而在垂直思考 (邏輯或數學)中,這種情況是不可能發生的。水平思考正好能夠觸及這種感性的東西。它能夠動搖對刻板結論的盲目自信, 不管得出結論的方式看起來有多麼可靠。這便是水平思考的好處,因此人們經常在考慮到風險時,會運用替代方案或是逆向思考的方式來尋求突破盲目的自信。例如;想看電影時,水平思考可能聯想到"爆米花"、"3D立體螢幕"、"烤雞腿" …,等發散聯想,這時候你可能就更容易選擇到理想的電影院了。

針對問題;先進行水平思考用來看見問題的全貌,然後再作垂直思考解題,可以相輔相成

所以敏捷開發要求工程師,遇到需求的第一刻,就要先提出質疑(先問Why?)。

質疑性的提問容易讓人產生不悅

水平思考可分成三類: 質疑替代方案刺激(註4.《Serious Creativity》)。這裡所謂的質疑,指的是拒絕接受現行做法必然是最佳解的做法,是一種科學的求真精神,讓思考能夠繼續去尋找可行的替代方案。因此它是針對自己內心的思維所提出的質疑,並不是言語對話上的質疑。真正在與人溝通時你必須考慮得更周詳一些(請參考卡普曼戲劇三角)。

尋求替代方案的思維(註1. ),我經常使用的是可視化概念的方法,概念扇和影響地圖(Impact mapping)我都很常用。當人是最大的影響因素時;我會選擇用影響地圖。其它時候我會用概念扇(請參考水平思考的工具),而且經常是在會議進行當中,因為它能讓你在概念構想之間反覆推敲,動態的加深了你思考的廣度和深度。

另外,思考提出替代方案時,你還需要考慮現實的狀態,例如:資金、技術、人力資源、支持和培訓等。


【 水平思考的工具 】

六頂思考帽、創造性暫停、隨機輸入法、概念扇、簡單聚焦、替代方案、概念、抽絲法、設定刺激、 …。

-水平思考的運用工具


從哪裡開始?

想要運用水平思考,要從”刺激”開始,我的習慣是反向思考,透過與常識相反的思考,找出新創意的切入點,它是一種刻意的思緒,能夠促進我們不受常識或定論局限的一種靈活思考(這麼做主要是想擺脫自以為是的想法),直接質疑根本的原因,是探究真理的假設思維。因為我們通常會以過去作為基準來推論事情的原委,結果就是在腦子裡強行關聯過去的結論跟未來尚未發生的事件,這完全是一種自以為是的想法,因此我以為要秉棄這種先入為主的想法,最直接的方式就是朝相反的方向去思考。而這麼做會直接刺激我們既成的思維,讓我們更容易看到主題的本質。


當問題的方向凌亂的時候,我以為”理想化”也會是一個好的刺激,就是不要去看那些林林總總的問題,把過程理想化,然後再反過來看是不是我們真的想多了。這時候採用「左手欄」(註3.)將思維可視化的方式,也經常可以澄清是不是我們考慮太多的原因。


  • 如果正門進不去,就尋找側門,假使計畫行不通,就改變作法。
  • 翻轉危局的解答並不一定在前方,而在你的每一個「想不到」裡。

-《逆思維》,亞當.格蘭特


小結

創意往往讓人意想不到,也就是說它不合乎邏輯,因此我們不能只是用邏輯思維來思考問題,因此我們需要讓思維發散才有機會產生創意。而水平思考就是一種創意思考。你可能會有疑問,為什麼我需要有創意? 不是只有追求新創的公司才需要創意的嗎?

這裡的創意是指向人們在思考、解決問題、或創造新的東西時,所表現出的能力。它可以幫助我們在競爭激烈的環境中脫穎而出,並在不斷變化的世界中保持競爭力。在現今的世界,創意越來越受到重視,因為它可以幫助人們在職場中更加成功。創意可以讓人們想出新的、有價值的想法,從而在工作中更加有效率。此外,創意也可以幫助人們應對變化,並在遇到困難時想出解決方案。

因此,不論是在工作中還是在日常生活中,都有許多原因需要人人都要有創意。創意可以幫助人們在競爭激烈的環境中脫穎而出,也可以讓人們在不斷變化的世界中保持競爭力。更別說天天都在解題的工程師了,我們更需要它。

工程師可以透過以下方式來提升自己的水平思考能力:

  • 學習新的知識和技能:隨著工作經驗、概念的增加我們就自然地更能夠增廣自己的認知,因此透過不斷學習累積更多的知識,充實的專業知識可以增加自己從中獲得更多的靈感。
  • 接受任務的挑戰:挑戰是一種刺激,當接受新的挑戰時,它有助於工程師學習如何從不同的角度去思考問題。
  • 尋求多樣化的經驗:透過多去接觸不同領域和技術可以自然的幫助我們增加對問題的理解。
  • 與他人分享想法:透過參與團隊或社群的討論與他人分享自己的想法能夠幫助我們從別人的觀點來思考問題。
  • 尋找新的解決方案:透過不斷尋找新的解決方案(替代方案),工程師可以增強自己的水平思考能力,總是要思索;解題的方法一定不只一個。
  • 打破常規:逆向思考,透過不斷試驗新的方法和思路能夠幫助我們從不同的角度來思考問題,試想今天嘗試走不一樣的路回家看看。
  • 尋求跨領域的合作:與不同領域的專家合作能夠幫助我們增加對問題的理解。
  • 實踐解決問題的方法:不斷實踐解決問題的方法能夠幫助自己增強水平思考的能力。
  • 尋求不同的資源:使用不同的資源,如研究論文、專家訪談等,能夠提共不同的角度來思考問題。
  • 找出問題的根本原因:透過找出問題的根本原因,可以更好地理解問題,並從中獲得新的靈感。

我們可以經由不斷學習和挑戰自己,以提升自己的思考能力,從而善用水平思考來更好地解決問題。有時候我把水平思考看做是假設思維,做一個假設然後試著去驗證它,對了就給自己獎勵,可以讓日子更好過一些。有時候我把它當成旅遊閒逛一般,將心情暫且放輕鬆下來,在細微的事件上悠哉地進行探索,而忽略成果。其實就是獲得概念、培養概念,有概念候後再來進行學習。

藉由實踐來激發創意

愛德華以為『我們經常在有了一個好的構想時,就以為它太了不起了,人人都會喜歡它、支持它,但現實中幾乎沒有這種事情。』一個構想要成功,一定是有人努力去推動它,有人透過實際的實踐讓大家看見它的價值,所以我們身為工程師,唯有踏實的使構想能夠落實下來,才能彰顯出它的價值來。

水平思考與開發者體驗的聯想

  • 水平思考 (Lateral thinking) 是一種創造性思維方式它強調尋找各種不同的解決方案,而不是只停留在一種解決方案之上。水平思考通常被用於解決複雜的問題,並且需要在多個領域之間進行探索和思考。
  • 開發者體驗 (developer experience, DX) 是指軟體開發者在使用軟體工具、框架和平台時的體驗。它旨在提供給開發者一個順暢、高效、使用起來感覺舒適的工作環境,以便他們能夠專注於軟體開發的核心任務,而不必花費大量的時間在系統管理和配置方面。

雖然水平思考和開發者體驗之間沒有直接的聯繫,但是水平思考的創造性思維方式可能有助於開發者在使用軟體工具、框架和平台時找到最佳的解決方案。此外,開發者體驗也可以促進水平思考,因為如果開發者有一個舒適的工作環境,他們就有更多的時間和精力去思考和解決問題。


不要寫需求給你的開發者,應該給他們你遭遇的問題

-Ask your developer.


.

註1. 尋求替代方案你可以這麼做(我最喜歡用的是影響地圖,因為它以人為出發點,容易做成故事的情節及場景,很有啟發性。再來就是水平思考的概念扇,它們二者都以概念可視化的方式來協助我們進行思考解題)。

  • 要經常去關注最新發展:訂閱行業新聞、去參加社群聚會、或者加入相關的線上社群,都可以讓你增加對新技術的瞭解、新產品和服務,從而為你的任務尋找替代方案。
  • 整理你的需求:透過整理文件是創造基本概念的最踏實做法,但它比較花時間。如果能明確定義你的需求,包括你的目標、預算、時間表、以及最終產品或服務的功能和性能標準。這樣就可以省去不少時間,並且更容易地找到符合你要求的替代方案。
  • 比較評估你的選擇:研究各種替代方案,並評估它們如何符合你的需求。運用列表來整理及比較各種方案的優缺點,以便你能夠做出明智的決策。
  • 測試和驗證:在選擇最終方案之前,建議你實際測試或驗證替代方案的可行性和性能。這可以確保你選擇的方案符合你的需求,並且能夠在實際應用中取得成功。
  • 考慮風險:在尋找替代方案時,要優先考慮風險。因為風險就伴隨著你的策略而來。每個方案都可能有它的優缺點,因此你需要評估選擇哪種方案所帶來的風險。例如,如果你正在尋找新的軟體供應商,你需要考慮選擇新公司所帶來的風險,因為它可能沒有像老牌公司那樣的資源和經驗。
  • 尋找專家幫助:如果你在尋找替代方案時遇到困難,你可以尋找專家幫助。
  • 維持彈性:最後,在尋找替代方案時,要保持彈性。即使你已經找到了一個看起來很好的方案,也要持續檢查其他可能的選擇,以確保你的公司始終保持競爭力。

註2. 水平思考方式的運用工具(參考自誰說輪胎不能是方形?):

六頂思考帽:一次只用一種角度看事情,能夠避免爭辯,更有效地進行討論。
創造性暫停:打斷例行思考的流程,停下來;才能注意到被疏忽的事物。
隨機輸入法:用來打破僵局,當毫無靈感、不知從何下手處理當前狀況時。
概念扇:藉由一連串的定點或提供新焦點,尋找理想的方案及構想。
聚焦:聚焦在沒有人願意思考的問題上,即使是小創意,也能產生驚人成果。
質疑:拒絕接受現行做法必然是最佳做法,繼續尋找可行的替代方案。
刺激:藉由設定踏腳石,扭轉現行的方式思考,找出真正的新興做法。

  • 六頂思考帽
    • 白色思考帽:考慮資料問題
      • 象徵中立而客觀、代表客觀的事實訊息、數據及資料。(不允許表達自己的意見,但允許報導他人的意見)。
      紅色思考帽:直覺和感覺
      • 象徵憤怒、狂暴與情感。代表情緒上的感覺(感情),還有預感和直覺。不需要為自己的感覺辯解,或提出邏輯的根據。
      黑色思考帽:警戒和符合邏輯的負面看法
      • 象徵陰沉與負面。代表邏輯上的否定層面,屬負面思考,指出為什麼行不通的批判。所扮演的是「反證僧官」的角色。
      黃色思考帽:符合邏輯的正面看法
      • 象徵陽光、明亮、樂觀,肯定、建設性、和機會。代表邏輯上的肯定層面,包含著希望及積極肯定的正面思考。一方面重視邏輯與實際,另一方面兼具夢想、幻想與希望。
      綠色思考帽:創意思考,追求創見
      • 象徵生意盎然,肥沃豐美。代表創意、新的想法與冒險。思考者要以「前進」代替「判斷」,向前尋找新的主意、新觀念及新思維。
    • 藍色思考帽:控制思考的過程
      • 象徵冷靜和控制。代表思考過程的控制與組織,思考解決問題所需的思考方式。思考者可以自己組織思考,指揮其他思考帽的運用,監督思考過程,並確保人人遵守遊戲規則。
  • 創造性暫停
    刻意暫停眼前進行的發想過程,考慮是否有替代方案或另一種做法,以檢視先前流暢的思考討論過程中,是否有疏漏
  • 隨機輸入法
    如果從一個不同的點出發,將有較大機會開啟不一樣的型態。可透過隨機詞輸入法,亦能借助物件、圖片、閱讀資料和展覽等。
  • 概念扇
    利用概念層層推出更多替代方案。從思考的目的出發,倒推至達成目的需要仰賴的廣義概念;也就是方向,再從方向倒推至概念,也就是朝該方向前進的「方法」。
  • 簡單聚焦
    通常只有問題困難會被思考與檢視,如果能夠注意他人都忽略的東西,或許可以想出非常有力的創見。簡單聚焦並非嘗試產生新構想,而是將某個點視為潛在創見焦點來檢視
  • 創造性質疑
    思考「這是為一個可行作法嗎」、「為什麼非得這麼想不可」,對於主導概念、假設、界限、必要因素、迴避因素、非此即彼的兩極觀念、持續性進行檢視,是否有其他方式,包含: 忽略型持續性(沒人想過的)、鎖定型持續性(需要配合某些事)、自滿型持續性(因為成功而未重新思考)、時序型持續性(受自身經驗的時序束縛)。
  • 刺激
    透過刺激來跨越型態,為一種主動的運作,而非暫停判斷。刺激來源分為:
    • 自行出現的刺激:任何陳述、評論或事件都能當作刺激,被判定為不可靠甚至荒謬的構想都能用來刺激思考,幫助推出有用的構想。在這種狀況下,刺激可說是自行出現,而非刻意設定的逃脫型刺激法:刻意設定的刺激;選擇當前被視為正常的任何一點,然後嘗試「逃脫」他,可能為否定、取消、捨棄或不再仰賴
    • 踏腳石刺激法:利用刻意的方法設定刺激,包含:
      • 反向操作:將正常操作的方向顛倒誇張:將尺寸設定在大幅高於或低於正常的水準扭曲:隨意改變事物間的關係或順序
      • 如意算盤:提出幻想的美好情況
  • 移動
    從某個構想移動到另一個新構想,包含:
    • 提取原則:從刺激想法中提取某個原則、概念、特色或方面,然後試圖圍繞提取出的東西建立新構想。注意差異:刺激想法和正常情況有何不同,以該差異為焦點尋求新構想。想像每一步:想像刺激想法付諸實行的情況,並在其每一步得出有用的新構想。正面思考:注意刺激想法中正面的地方,藉以建立有用的構想。思索適用情況:尋找刺激想法可以提供若干直接價值的特殊情況,並藉以建立新構想
  • 語層
    將關於某個情況、互不相關的N個句子放在一起,構成一個語層,看看會產生什麼新構想。
  • 替代方案
    即使有合理的下一步,也能夠停下來尋找更多替代方案。設想新的情況來設計新替方案,而不僅滿足於分析特定情況。因此為替代方案界定「定點」很重要,定點可以是目的、組別、相似或概念,我們通常能為一種情況界定幾個定點,然後為每個定點再去尋找替代方案。
  • 概念
    做事的通用方法或方式,以籠統、模糊、非具體的方式作表達。每個概念都需要某個具體的「構想」付諸實踐,我們也能從任何構想「往返」到概念的層面,這種往返往往能激發更多概念。
  • 抽絲法
    圍繞一個創造力焦點,寫下替焦點設計時的基本要求,接著逐項檢視這些要求,但完全忽略創造力焦點的實際脈絡並提出「細絲」,也就是滿足該要求的各種方法。並選擇若干細絲,設法將他們組織起來,藉此得到一個新構想。

註 3. 左手欄 The Left-Hand Column

是由組織學習大師克利斯.阿吉里斯(Chris Argyris)與熊恩(Donald A. Schõn)所發展出來的工具。經過彼得.聖吉等人的改良,在《第五項修練.實踐篇》中有了較完整的練習方法。

註 4.Serious Creativity》中文書名《誰說輪胎不能是方形?:從「水平思考」到「六頂思考帽」,有效收割點子的發想技巧》為 Edward de Bono 在2015年的創作,是目前最完整的水平思考工具書。

敏捷教學甚麼有用?

開發者進行開發作業總是由學習開始的,但我們卻很少去正視它。敏捷開發強調要透明、檢核與調適。因此不應該忽視學習,學習時間不應該平白的讓學習者自行吸收而沒能進行檢核與調適,我們應該設法讓學習變得可視化,學習者變得可見的學習者(註2.),以便讓開發作業變得更敏捷。這裡參考了愛德華·德·波諾先生 (Edward de Bono)所推廣的可見的學習(Visible Learning),我們藉由學習的行為將水平思考(Lateral thinking) 引用在敏捷開發上頭,其中「六頂思考帽」可以運用在重要的頭腦風暴會議,「概念扇」則可以協助我們橫向的捕抓更多構想,而這裡想要強調的「可見的學習」則可以提供我們適時更快速地回饋,讓開發作業與團隊的運作能夠變得更為敏捷。

本文想藉助約翰.哈蒂先生(John Hattie)的實驗數據,讓我們在可視化學習後,可以據此判斷如何改善或是提出怎麼樣的行為讓學習的效果更為有用


可見的學習(Visible Learning)是指通過可視化的方式,把學習過程中的各種信息、數據和結果展示出來,便於教學之間能更好地理解學習情況,並為學習提供直接回饋

-Edward de Bono


圖一、教學就應該以學生的學習為中心: 決定怎麼做才有用?

上圖中,我節錄了《可見的學習與深度學習》中作者的實驗結果,加以排序之後赫然發現,前二項高效的措施正是OKR 關鍵目標設定法的核心觀念,它也正好解釋了實行OKR會如此有效的原因


O 表示目標,KR 表示關鍵結果

目標;就是指你想做甚麼事。關鍵結果;就是指如何確認你做到了這件事。


如果你是老師,你一定想會知道我這樣教能有多少效果? 紐西蘭的John hattie為了解開這個疑問,他對不同因素對教育成果的影響作了定量測量進行了有史以來最大規模的元分析綜合,從而促成了他的著作《可見的學習》。

雖然這些理論未經嚴格的檢驗純屬統計分析的結果,但書中仍有許多見解,值得我們在學習的過程中變得更為敏捷,值得參考。

OKR 為何有用?

讓團隊成員自己設定指標(Key Result),自己衡量具體達成目標的期望值(註1. 0.7的魔術數字),這是一種自我衡量、自我期許的行為,由Hattie 先生的實驗數據可以看出這二種方式的效果最佳,高居教學效果的前二位。而這也解釋了OKR為何有效的原因。人們對自我衡量、自我期許最能收到激勵的效果。由敏捷的角度來看這二種措施,它屬於自組織體系下的自主行為,帶來的是個人價值與目標的對齊,它的效果甚至比回饋所能帶來的效應量(0.73)更好。感覺上OKR給了我們一個實踐自組織時讓價值對齊和自我衡量的好辦法。


如何形成學習者自我衡量與自我期許?

許多家長可能都為了孩子們的成績傷透了腦筋。但實際上;你只要請孩子們列出現在他最想要做的三件事(只要有一個能跟學業有關就好了,不要要求太多),然後在針對這些事每一條列出達成的三個關鍵指標(試著用 chatGPT來訂KeyResult會更有趣些),然後再針對做的有多好來給出0.0 到 1.0之間的評分,就可以了。當然你還要在接下來的時間裡經常提醒他做了哪些項目,進度如何? 能在早餐桌上進行檢核最好,但晚餐或睡前來做也行。這就是效果強大的OKR了。


內在動機的激勵

我們都知道在學習的過程中,運用觸發內在動機的激勵方式能夠造就最佳的學習效果,而OKR正是居於團隊成員對自我期許的效應而來的一種激勵方式。它用簡單的數字來觸發個人的內在動機。運用的方式是讓你自己設定正常工作下可以獲得 0.3的分數,稍微努力一下多用功一些可以取得0.5的分數,如果能夠克服困難達成目標便可以得到0.7的分數,表示我們能夠期待他未來會有更好的表現。而1.0是表彰那些成就非凡超過預期效果人士的分數,通常指的是超過自己能力的極限表現。


士氣是設計的關鍵因素

-Paul Graham


敏捷教學應該要以務實為主

上圖中Hattie先生以0.4 為出發點,陳列了多項對學習具有影響力的措施,將0.4設定為中等的效果,凡是高於0.4的表示這種措施是值得去做嘗試的,它是有利於提升學習效果的行為,值得我們採用。換句話說;它想說明的是甚麼樣的教學措施才更有用?

教學的清晰度對學員學習的影響力大小為0.75。從實質上來探討,教師能夠言之有物而且條理清晰是上課時最重要的事。我們把它衍生到開發作業上,則是mentor 與 technical leader 所提供的協助與資料。再來就是相對地「需求」是否清晰而明確了。因為它是開發者最想要攻克的目標,它成了開發者進行學習時的最大目標, 也驅動了他的學習方向。

回饋的效果僅次於教學內容的清晰度屬於高效果項目

回饋的效應量為 0.73

回饋;我們都想知道我們表現得如何,特別是當我們想要掌握一個新的概念或技能時。例如舞者會看著鏡子試圖找到自己的缺點,就是一種自我回饋的方式,依靠的是自我察(awareness)的能力。但更好的則是來自專家、有經驗者更落實的回饋。

回饋方式的不同也會帶來不一樣的效果,不好的回饋可能會讓我們產生戒心打擊我們的信心,破壞我們的學習情境,好的回饋則會推動我們達到新的理解水準,擊發我們持續改善的動能。回饋的三種時機:

  • 前置回饋: 回饋發生在前置的時間,也就是事情尚未發生之前,我們稱之為前置回饋,通常又被稱為忠告或是建議。它大半來自有經驗者或是專家的建議,通常我們只是點頭接受,但不會實際去實踐,或許將來來自AI的comment 我們會比較重視些。
  • 即時回饋: 過程中的回饋,一般來自夥伴或客戶。
  • 後置回饋: 事後的檢討,如Scrum的回顧會議。

前二種回饋因為事件尚未發生,還來得及進行修正,所以更有價值,但卻是我們經常忽略的(聽不進去常常是因為我們過於有自信,參考達克效應)。後置回饋(敏捷開發的回饋指的幾乎都屬於此類);雖然於事無補但卻能有助於學習,因此失敗的專案若能好好的檢討,通常比成功的專案學到更多,例如:新創失敗時,通常我不會說他失敗了,而是說他這次創業學到了甚麼。

回饋是非常值得重視的,特別是當回饋做得好的時候,這也是回顧會議成為敏捷開發裡最重要的一個會議的原因。從本質上講,回饋意見是“及時、刻意為我所提供的資訊,這些資訊在給出後能發揮最大意義”。回饋不應該僅限於團隊成員,還可以來自家人、同伴和自我 (請參考: 自我回饋)。

對應到回饋的敏捷學習工具

前置學習策略梳理會議是敏捷學習的前置行為,影響地圖則是屬於策略層面的工具,它讓使用者看見概念,是可視化概念的繪製工具。梳理會議則是發生在前一個衝刺開發(Sprint)的邁向未來的會議,它給了團隊成員預先知道的機會,是形成工程師概念的前置學習時機。

團隊共同學習是敏捷學習的重點

具有挑戰性的作業的效應量為 0.57~ 0.72

不是當學生時才會有作業嗎? 開發專案時也要有作業嗎?

好的作業可以牽引我們好的學習效果。如果工程師對新開發作業缺乏相關的經驗時,我們可以藉由做作業的形式引導團隊由淺入深的逐步完成團隊成員對專案學習的深度(例如欲發展微服務架構時,就可以用開發模組功能的API 做為作業,進行練習),因此好的作業練習可以用來開拓團隊成員的技術與相關知識,所以在專案開始之初,進行教育訓練並以要求作業的形式來落實教育訓練,可以有效的提升團隊成員的開發效能(尤其是Queue 或排序的技術或理論,事前的作業探索都非常有價值)。

通過設定目標來激發學習的自發性和自主性,效應量為 0.56

通過設定目標來激發學習的自發性和自主性是自組織團隊的交互信任程度的一種表現,它有著正面積極的影響。它意味著團隊擁有共同的目標,而不是簡單的說“全力以赴”或者是將目標集中在完成任務上就有用的(無效的激勵)。相反的,是將目標集中在學習上,而不僅是集中在做上。當開發的工作淪為要完成無休止的一系列任務時,學習會受到不可估量的負面影響,正如目標被簡化為一系列待辦事項,以便從任務清單中劃掉。藉由讓團隊分享自己所設定的具有挑戰性的學習目標時的承諾(Key result就做這件事),這些目標便更有可能實現。敏捷團隊的檢核(review)會議,強調要由負責的開發人員講解自己開發的那一部分功能程式,並一定開發者自己進行操作的方式來做展示,就是自主性的應用(規定不能交給測試人員來操做也是這個目的)。

教師對學生的期望,影響力大小是 0.43

組織展現對團隊的期望,效應量為 0.43。所有的組織都會對團隊抱有期望。更好的問題是“組織的期望是否被錯誤解讀或者被誤導了”(它是一個不擅長表達的主管就能輕易造成的不幸損失) 教師的期望對學生學習的影響力大小是0.43。讓我們用另一種方式來說明:如果教師希望自己的學生在一年的時間裡能學習到一年的(或更多的)內容,他們可能會怎麼做…。這些期望每天都在傳達給學生,從行為舉止到任務挑戰。當教師計畫學習單元並讓學生參與高品質的學習體驗時,期望需要首先得到考慮。它無形中形成了學習環境裡的一種有利於學習的氛圍。


弱即是強"指的是一種軟體傳播的模式

軟體設計思想的各個方面,其中的一個重要結論就是軟體功能的增加並不必然帶來質量的提高。有時候,更少的功能 ”" 反而是更好的選擇 ”” 化,因為這會使得軟體的可用性提高。相比那些體積龐大、功能全面、較難上手的軟體,一種功能有限但易於使用的軟體可能對用戶有著更大的吸引力。

-Richard P. Gabriel


小結

要拿甚麼來做判斷的依據呢? 這麼做的效果好嗎? 是否值得投入更多時間、資源? 我們可以參考約翰.哈蒂先生(John Hattie)的實驗數據(如圖一)。

時間到了! 會議就一定要結束嗎?

敏捷的會議大都是採用時間盒(time boxing)的方式,也就是時間到了就結束的方式。目的是避免冗長會議所帶來的浪費與勞累。

這造成了團隊經常會害怕超時(當提問過多或是回答佔去太多時間時),請問: 會議到底該不該繼續開下去? 如何抉擇呢? 是斷然地結束會議(符合時間盒的規範),但這麼做可能會造成決策議題的延滯,下次會議又要重新來過的現象,是一種平白浪費的損失。然而;要延長多久時間呢? 延長多久才夠;這和會議想要獲得甚麼樣的結論才應該結束,必須相匹配,正確的做法是挑最重要的一項議題,討論完畢後就結束。相同的道理,敏捷教學甚麼有用? 我們可以依據「約翰·哈蒂的教學實驗數據」評估它的效應量來做為資源投入的標準。

甚麼教學策略是最有效的?

圖一列舉了,作哪些事情比做其他事情更能確保開發者的學習效果。參考它可以確保我們的行動更具效益,而且還能夠因此而避免了許多的問題。但是在你決定怎麼做之前,還是應該視當時的情境為主。例如: 在專案時間不夠的情形下,這時候實施 OKR關鍵目標設定法,雖然可以聚焦,但顯然團隊學要先學會如何設定個人目標? 學習所花去的前置時間就可能過長了,必然會延誤到正常開發作業。所以需要以工程師當前的需求為優先考量。


1. OKR設定分數的意義,表示的是個人對自己的期許。Google 以0.7為考核及格的標準。

0.7 的魔術數字經常被用來設定為及格的標準

2. 可視化學習者的特徵

可視化學習對敏捷教學至為重要,因為開發作業總是時間那麼趕,往往讓工程師一個接著一個的趕著做專案,平白的花了時間在做專案卻沒有落實的學到太多東西,實在有點可惜。工程師若能夠出現下面的特徵,則表示可視化學習的效果成功了,它可以作為敏捷開發時的檢核借鏡。

  •  可以成為他們自己的老師;
  •  可以清楚地表述他們正在學習的內容和原因;
  •  可以談論他們如何學習——他們正在使用的學習策略
  •  可以闡明他們計畫的學習步驟;
  •  可以使用自我管理策略;
  •  尋求挑戰,有復原能力,並且渴望挑戰;
  •  可以設定掌握目標;
  •  將錯誤視為機會,並且很自在地說自己不知道和/或需要幫助;
  •  積極支持同伴的學習
  •  當他們不知道該怎麼做時會知道自己如何改進
  •  積極尋求回饋;
  •  元認知技能,並且可以談論這些技能。

概念扇

為教學、演講進行敘畫的最佳工具 – 概念扇。

.(註2. )


我認為工程師在開發過程中的學習,形成概念應該是最重要的一環。有概念之後你便可以開始思考架構、進行初步設計、甚至做估算。這些屬於高度不確定性的工作,在在都依靠你對開發作業的概念,有了概念之後你才能肯定自己接下來要走的方向,也才能開始大步的朝目標邁進。

開發者體驗即學習,而形成概念是學習新事物的第一步。開發者在概念形成的過程中進行學習,通過聽與看的輸入來進行分析綜合、抽象概括等思維活動,從個別到一般,從具體到抽象,逐步把握這一類事物的本質並產生概念。然後才是瞄準問題進行解題。它實質上就是一個學習的過程,也是開發作業中至為重要的思維活動。

在尋找如何快速形成概念的過程裡,我重溫了艾德華先生的概念扇,再一次體會到它的威力,也讓人聯想到Gojko Adzic的《影響地圖》Impact Mapping, 它們有著異曲同工的外觀及內涵,都能協助我們迅速對問題產生概念,是運行DX時的好用工具,在這裡介紹給大家。

圖一、協助我們明確解題方向的工具

製作概念扇,原則上是從目標開始,然後抓出幾個方向,得出幾個概念,最後想出許多構想。概念扇提供一個框架幫助我們產生更多構想。是一種水平思考而不只是一般的描述或分析。

.

愛德華.狄波諾(Edward de bono)先生 於 1967年提出了水平思考(Lateral thinking)是一種「嘗試以非傳統或看似不合邏輯的方法來解題」的思考方式,愛德華先生強調「看似不合邏輯」的水平思考,不是只能靠天馬行空。就如同數學有各種執行數學運算的具體方法,水平思考也能有系統地產生新想法和新觀念的具體技巧與工具,是一種創意思維,而概念扇正是其一(註1.)。


會議之初,第一要務應該是把概念説清楚。

人們總是急切的想付諸行動而忽略了概念的重要性,造成了許多與會者沒能進入狀況,沒能跟上討論和作意見發表,白白的浪費時間而只能作壁上觀。人們總以為這些含糊、不切實際和不必要的東西,會耽擱或誤導開發作業的時程及方向,平白的損失了有價值的回饋及創意。

水平思考 Edward de bono.


概念扇拓展分析的方向

趕時間時;如果跑錯了方向,不管你跑得有多快,只會距離目標越來越遠。人們犯錯時大多是因為自以為是所造成的,也就是事前沒有進行分析作業或是分析時只朝有限的範圍去思考。然而分析時的正確行為第一個應該是確定目標,而分析後的第一件事則是擬定具體的行動方案。這正是概念扇的特色,它著眼的是如何成就某件事,或是描述成如何從更多角度來思考完成目標的各種構想。它是一個可以幫助我們看見全貌的簡單框架,透過尋求不同的方向(水平思考)來分析達成目標的諸多可行概念,然後再透過概念來思考解題的構想。此時或許有些構想太過理想難以實踐,這個時候你便可以運用概念扇再反推向目標方向而形成新的概念,如此反覆推論的方式,可以協助你展開視野而不會一廂情願地自已為是,限制了自己的思考範圍。這正是概念扇好用的地方 -透過反覆推論產生新概念。

製作概念扇

製作概念扇時;原則上應該從「目的」開始,然後層層往下推,你要自問: 『我要怎麽到來到這一點? 』,從目的向下推至「方向」,再推至「概念」,最後依據這個概念來想出許多可行的「構想」,這正是這項作業的目的。這裡的方向就是水平思考的運用,對同一目的用不同的方向去思考,這裡的方向可以看成是更廣義的概念,概念種類有大有小也有模糊不明的,要落實它們需要在構想與概念之間反覆推論,逐步的將概念扇可視化出來

概念扇看起來條理分明但是我們的大腦不見得會喜歡這種順序而有條理的做法,在製作概念扇時,大腦往往會一下子就跳到一個實際構想上,而經常形成一種反覆跳躍的思維方式,這是建構概念扇時經常出現的方式,不用擔心;它不但無害反而更能牽引出不同的想法。(如下圖中的虛線部分)

【概念扇的三個層次】

  • 方向:你所能想到的最廣義概念,就是你的方向。
  • 概念:做某件事的非具體方法(對工程師而言模型就是這一概念)。
  • 構想:實踐概念的具體方法。構想必須很明確,而且可以直接實行。
圖二、反覆跳躍的思維方式是合理的建構方式

概念扇的運用,對主管而言

在會議前、後進行概念扇的水平分析。如果你已經是那種運用會議來進行管理的人士。每天開著種種的會議,然後總是在會議之初,努力的釐清概念,然後在會議結束前思考如何快速做成總結的辛苦人士。則運用概念扇可以協助你提升能力又能做好回顧的工作。你只要按照概念扇的層次(方向、概念、構想),首先要確認目標,接著判斷方向(這個時候可以直接詢問報告者他所設定的方向,然後與概念扇做比對),先避免去思考細節,先形成一種解題的虛擬路徑,就是概念。最後才是就每個概念形成解題的構想。把原本存在自己腦海裡的種種想法用紙跟筆的方式形成視覺化的紀錄,它是專屬於你的概念扇,它可以協助你在進行說明時更有說服力,也可以拿來做事後回顧讓自己檢討如何做得更好,當然也可以做為分析指導用,如果會議的性質是腦力激盪時,適當的引導報告者,提出不同的問題可進一步觸發新概念或是釐清觀念,當然也可以將概念扇直接畫在白板上,讓團隊一起進行推論,可能會花掉一些時間,但這麼作能夠協助團隊看清事件的全貌。

概念扇的運用,對工程師而言

工程師最怕沒有概念跟只有一種概念。沒有概念就甚麼都不能做;當主管要求我們對專案進行估算時(當主管詢問你準備怎麼做的時候),沒有概念就完全無法作估算了(雖然一樣是在作猜測)。但不要總是依靠經驗,應該先進行學習,直到對開發領域產生概念之後才能作估算(依靠經驗作估算經常是一種陷阱,因為沒有二個專案會長得一模一樣的)。工程師在只有一種概念之下開始開發作業,應該要避免一開始就大量投入工時進行深入的設計或開發,應該先作概念性的驗證,例如: 作產品雛形prototype的方式。這個步驟就是概念扇上的方向判斷層(替代方案)。先作廣義上的思維,正是所謂的;解題的方法絕對不會只有一種,因此就應該先作驗證,先作好壞的取捨,然後才是深入的設計與進行開發。經常看到工程師為理念上的不同而產生爭執,大部分都是盲目的依附著一種概念,就開始深入地進行設計,自然在耗去大量時的時間和精力之後,選擇不妥協的態度,這是形成概念時沒有進行水平思考所致,若能在專案初期先進行概念扇的思維,結果就容易宏觀多了。


如果你遭遇到工程師意見起衝突時,建議你參考限制理論的衝突圖來化解。


有關概念

「人們可以像科學家一樣」:運用構念(constructive)來預測事情,所有的人如同科學家試圖預測並控制事件的發生一樣。我們也想了解周遭的世界,以便能夠預測並控制發生在我們身上的事。如果科學家用不同理論預測不同事件,那麼人們也能以此來望向未來(註)。

-George Kelly

影響地圖與概念扇(都是可視化概念的工具)

小結

如果思緒總是能夠順暢的如流水般的連綿不斷哪該有多好,但很不幸的是我們經常在想要弄清楚大方向時,思緒突然冒出了如何具體解題的細部構想,跳躍式的思維讓我們的思緒無法連貫,此時你便可以運用概念扇的層次結構,把突然湧現的做法先放進構想層,然後再來倒推這個做法(構想)是居於甚麼樣的概念所產生的,屬於怎樣的解題方向? 概念就是這樣被呈現出來的它變得可視化,而可視化的概念就變得容易整理多了。

由完全沒有概念的初學者,到進階為擁有多種解題方向的專家。這不是短時間能夠達成的,但你可以在學習的過程裡持續的補充各種概念(充實基礎知識),例如: 對於參加了一個自己完全沒也概念的會議(註6),一個好的開始方式是,從補足相關知識入手,就是把那些聽不懂或是不了解的專有名詞先查詢一遍,然後在把他們拼湊起來,還有問題就提出來討論釐清解題的方向與構想,藉由方向或構想的串聯來看見概念。這是藉由概念扇的三個層面來探索解題的動作是否符合我們的目標的一種方式。

一般在概念的層面作業是十分困難的,你不能跟鋪路的工人講你希望用路人能夠在經過這段道路時因為有柏油路面而感到滿足,你必須將概念再延伸到構想的層面才行,也就是具體的講出要鋪設的柏油路從哪裡到哪裡、有多長多寬。此時便可以概念扇的思維方式向上或是向下反覆推論(註5)方式得到概念與構想的連線,用來獲得具體的結論。

如圖二所示,我們用虛線的方式來連接突如其來的想法。無論是概念或是構想,我們可以運用往上一層的提問「這有什麼用?」,或是往下一層「可以怎麼做?」來形成連續的脈絡,促發思緒的反覆激盪,以此來獲得更豐富的解題思維。除此之外概念扇能夠:

  • 一、協助我們擁有替代方案。
  • 二、強化概念。
  • 三、順利地改變概念。

如同影響地圖(註4.)一般,概念扇將概念可視化並顯示出替代方案,由原本凌亂的個別點子,拓展成有方向有概念的連線,讓達成目標的路徑擴展為多個解題的路徑。我們可以在觀察概念扇的時候,評估每條路經的難易程度及可行性。這便是看見解題的全貌,一種視覺化概念的工具,概念扇(concept fan)。

範例: 運用概念扇來規劃新的軟體架構,目的是降低系統複雜度   

參考《高效能團隊模式》第二章

.


註1. 愛德華先生所創的水平思考的技巧,包括: 六頂思考帽、創造性暫停、聚焦、創造性挑戰、替代方案、概念扇及概念。

「創造力不是只有某些人才能擁有、某些人只能羨慕的神祕天賦。水平思考是每個人都可以學習、練習和應用的一種創意思考方式。就像任何技能一樣,只是有些人比較出色罷了。水平思考無法讓每個人都變成天才,但是可以讓你在既有的思考能力之外,增添產生新點子的寶貴能力。」

─愛德華.狄波諾

註2. 實踐敘畫運用概念扇的思維,由於概念被可視化了,因此事後在欣賞畫作時,便容易捕抓到講者所想表達的內容。

講者一邊演講,敘畫畫家在聆聽課程的同時將內容抽象的以繪畫的方式表達出來,若能夠運用概念扇的形式作畫(目標-方向-概念-構想)。例如: 以課程的主題為目標逐步地展開,方向就是大綱,一路到如何實踐也就是構想,事後的觀賞者將更容易由淺入深的進行聯想與吸收。

註 3. George Kelly的 個人建構論。他認為:人存活的目的就如同科學家一般,在於對未來的事件 (events) 進行預測和控制,以減少生活的不確定性(追求美好)。他甚至認為,每個人均擁有一套屬於自己的理論,且不斷的測試該理論中的假設,獲得實驗證據,藉以形成或修正自己對事件的概念或建構,使其能有效的瞭解、控制和預測未來的事件,獲得明朗化的生活。一種十分適合拿來描述工程師思維的理論(它完全不考慮人的情緒影響)。

註4. 影響地圖 為Gojko Adzic 2012年所發明的讓概念可視化的工具。

影響地圖 (Impact mapping) 說明了如何把「概念視覺化」 ,提供一種  讓需求視覺化的能力,透過簡單的 Why-Who-How-What 的分析方法,搭配結構化的顯示方式,讓工程師能夠看見辛苦開發出來的功能是對應到哪一個業務的目標上。

註5. 反覆推論是概念扇最有價值得一面

有時候因為概念過於籠統或含糊,便很難形成具體的構想,我們要運用可行務實面與抽象的概念之間進行反覆的推論,讓概念逐步的明確化,越是明確越能形成具體的構想。

註6. 如果你在會議中完全沒有概念,最好的辦法是請求其他參與者(旁邊的人士)給你一個簡單的總結,或是請求主持人為你解釋目前討論的內容。你也可以嘗試自己專心聆聽,迅速用手機做查詢相關名詞的意義,然後提出問題澄清你的觀念是否正確,以便理解正在討論的議題。如果你還是沒有掌握會議內容,可以請求接下來的會議提供更多背景資料或先行資料,以便讓你有更好地理解。

開發者體驗設計,由動機出發

DX設計師不像顧問一般只提供建議,他更像ScrumMaster一樣,更專注於引導。


開發者體驗牽扯甚廣,這是一篇談開發者體驗的文章(註1. 相關文章),出發點是動機,藉由學習者擁有良好的學習動機,以獲得DX設計的良好效果。我認為開發人員也只是普通人,但他充滿了學習和成長的雄心壯志,擁有將工作做到極致的動力,並希望不斷實踐他們掌握的各種技能。

很大部分的動機都會是由內在及外在原因,以一定程度的比例組合而成

.

第一次看到愛德華先生的自我決定論(SDT,Self-Determination Theory),感覺上比馬斯洛先生的需求理論還要更接近敏捷一點。團隊的三個需求都與敏捷習習相關: 「自主」;讓團隊擁有自己的決定權形成自己的團隊文化。「勝任」;讓小增量與多次運作的衝刺方式逐步的增強開發者的學習能力。「歸屬感」;建立團隊成員之間的互相信任感,以共同學習克服障礙來達成任務。相對的;這三者也是促成團隊自組織不可或缺的元素。讓我們又找到一個可以促成團隊自組織的路徑,並足以相輔相成。

居於DX的設計理念,我們可以致力於設計良好的開發環境,讓開發者能夠順暢的進行他們的開發工作。但一個不作激勵的開發團隊,就只是任由工程師們以最低限度的努力來朝著企業的生產目標邁進(愛德華.L.德西)。DX或許可以用引導的方式來協助開發者進行學習,也可以透過Mentor的方式讓教學相長來強化個人的學習效果,但這些都是外在的力量,而真正最有效的方式,應該是來自開發團隊成員的自我激勵(內在動機)效果應該最為顯著。所以好的開發者體驗設計應該藉由團隊自我激勵開始,本文要談的正是如何觸發開發者的學習動機?

外在動機與內在動機

外在動機往往是基於外部所給予的誘因、獎賞所觸發,如上圖,內部動機則居於開發者內心的追求了解(想知道自己工作上的相關知識)、去達成(正視自己所努力的目標、意義)與尋求工作上的動力(刺激)。而我們很大一部分的動機都是由內在及外在原因,以一定程度的比例組合而成。而外在動機;例如獎勵,往往會削弱內在動機,尤其是在獎勵被停止的時候,唯有持續加強內在動機才能持續激勵自己,保持對學習和工作的興趣,過上真正自主的生活。而DX設計;正是要學會如何用支援自主的方式來激勵開發者給出有益的啟示和建議。這裡針對這二問題做解答:

  • 一、如何來激發人們的內在動機?
  • 二、如何轉化外在動機成為內在動機?

.

激發人們的內在動機

激勵需要人們看到他們的行為與期望的結果之間的聯繫,而工具性(instrumental) 允許人們看到這些行為與結果的聯繫(註3. 見《內在動機》ch5.)這裡的工具性指的是組織或體系上的不明確所致,或是處於上位優勢者個人的錯誤管理)。人們必須相信他們的行為將會產生某種結果,否則就沒有動機去做事。這種動機,往往受制於曖昧不明確的組織管理,這是為何外在動機容易實踐但很少能持續表現出高效率行為的原因。(獎勵措施原本是針對低成就動機的有物質需求者的激勵,為什麼反而失效了呢?因為外在獎勵會削弱人們的內在動機)

滿足內在動機的三種需求: 自主、勝任與聯結

自主:激發內在動機的第一個心理需要

人們需要感受到他們的行為是他們自己選擇的,而不是由某些外部來源強加的(行為的緣由),存在於他們自身內部,而不存在於某些外部控制之中。覺得自主;是讓支持自主與設定規則共存,愛德華先生的立場是反對依賴獎賞、要求、威脅、監視、競爭和批判性評估來激勵人們做出行為,但是,他也不反對與強調絕不能放棄規範(規範能帶來一定的紀律)。

勝任:激發內在動機的第二個心理需要

雖然工具性(instrumental,讓人們看到因果,也就是行為與結果的聯繫)對激勵極為重要,但僅靠工具性,還不足以確保人們高水準地參與社會生產。人們還必須對工具性的行為感到勝任,此時工具性才能成為有效的激勵因素。詹姆斯·康奈爾(James Connell) 和艾倫·斯金納 (Ellen Skinner) 總結了這些觀點,他們認為,人們需要具備獲得預期結果的策略和能力。真正的幸福來自對勝任與自主的共同追求。(所以勝任應該包含能力與適合的環境)

聯結(歸屬):激發內在動機的第三個心理需要

“完全投入在做自己的過程中,從而發現自己是完全而真實地融入社會的…”。人們不僅需要勝任和自主,還需要在感受到這種勝任和自主的時候感受到與他人的聯繫。我們稱之為歸屬(relatedness)的需要,即感受到愛與被愛的需要,關心與被關心的需要。

動機;自我決定理論

自我決定論(SDT,Self-determination theory註2.) 假設了所有人都試圖滿足的三種需要:勝任歸屬(聯結性)和自主性。三個與生俱來的需求,愛德華先生認為;如果能滿足該需求,則將會為個人帶來最佳的發展與進步。如果我們僅僅滿足了其中一種或兩種需要(或是一種也沒有滿足到),那我們就無法維持心理的健康。更嚴重的是,如果一個人滿足這三種心理需要的努力受阻,那麼這個人就會產生像饑餓的這種生理需要;在沒有滿足時所表現的那樣,可能先是會以更大的決心去滿足它們,而隨後;再遇到阻礙時可能將導致這種努力的下降減少,進而形成心理失調的狀態,而降低個人成長的動機。

在自我決定理論看來,由於外在動機所提供的獎賞會削弱個體的自主感,因此而導致內在動機的降低。這也是我們在管理上不能輕易運用獎賞來激發團隊效能的最大原因。但是;幸好敏捷開發的回饋機制剛好能彌補這個缺憾,一個職級純粹的正向回饋,不但不會削弱自主性,更可以形成能力感而反而加強哦內在動機。這就是愛德華所謂的動機轉化。因此是當的表揚可以保持人的自主性(例如「你是一個優秀的工程師或主管」),但不應讓他感覺受到有條件的控制性的表揚(例如"你是一個優秀的工程師,確實像我們所希望的那樣」)。

歸屬感;自我決定理論主張,滿足一個人的關聯需要也是發展內在動機的一個重要的促進因素,但是,這種需要可能不像自主和勝任能力的那樣的根本(但它對團隊表現出來的戰力,卻有著巨大的影響)。在團隊中體驗到與他人的一種關聯感,這種歸屬感將營造在(彼此)關懷的氛圍中體驗到滿足感,而更能夠增強一個人的內在動機。所以,如果工程師感受到團隊對他的期望的話,他能更自由自在地發展與學習。

自我決定理論詳細闡明的三種需要對成長和發展來說具有很重要的意義。

21世紀的自我決定論

轉化外在動機成為內在動機

運用外在動機作觸發,再將外在動機轉化為內在動機。按照自我決定理論,假如外在動機能夠內化(internalized)或整合進一個人的自我感知之中的話,那麼,曾經由外在因素所導致的行為就會變成由內在動機所驅動的行為。就像上圖中所描述的動機連續體一樣,內化具有多種不同的水準。最左端是無動機(no motivation)狀態,此時個體要麼不投人活動,要麼僅僅是"過場" 而已(Ryan & Deci,2000,你可能會訝異動機不是只有二種嗎? 但根據卡倫.霍妮(Karen Danielsen Horney )所說的,當我們的能力和自主性的基本需要不能得到滿足時,就會出現第三種動機,稱為無動機狀態。例如,早期的工程師,茫茫然的趕著工作,如果不是明顯的表現出自己的能力有所不足的話,他可能根本就不會去刻意的進行學習。或者,在長官的強迫下,他可能僅僅會表現得"假裝在學習",而沒能真正的由內心的慾望去驅動進行學習。具體表現出來的是,上個月才開發完的專案,相關的專業知識一下子就給忘光了。

圖中間部分是外在動機,它描述了內化的不同水準。四種外部調節從左向右移動的話,行為就變得越來越內化。感知到的歸因點就從外部向內部轉移。當我們為了獲得或者避免由他人所支配的獎賞或懲罰而做出行為時,就會出現外部調節(external regulation)狀態。所以說,如果查理斯為了獲得金錢或是為了避免懲罰而閱讀的話,那他就是處於外部調節中。內部(注入式)調節(introjected regulation)類似於外部調節,行為仍舊受到獎賞和懲罰的驅動。 然而,注入式調節包括由個體經驗所偶然產生出的自主感,稱之為自我捲入(外在動機看似容易引發,但產生的複雜的心理效應卻反而不好管理,宜謹慎使用之)。

在專案的開發過程中,當我們開始出於本身的利益而考慮其價值時,我們就處於所謂的認同調節(identified regulation) 中了,此時的行為仍屬於由外部因素驅動。例如,工程師可能認識到,這是很重要的一項技能,因此樂意花費自己的時間(自主性),用更多的時間進行學習。即使是這種認知,動機仍舊來自外部,但是,此時的目標與僅僅是一種害怕失敗與獲得獎勵對比,就更加個人化了。

最後一種外在動機是整合調節(integrated regulation)。當個體不僅認為這種學習有用,而且也將其整合於自我的感知中時,就產生了整合調節,一般運行敏捷開發的團隊,藉由團隊所形成的自組織文化的氛圍,團隊大部分的成員大都能夠運行在認同調節整合調節之間的層次中。(註4. 21世紀的自我決定論,參考自)

外在動機不全然是不好的,可以透過轉化而成為內在動機

活潑的團隊,本身就是一種激勵。


小結

動機是成功人士不可或缺的原動力,自組織則是成就傑出團隊不可或缺的團隊文化。二者之間的關係,一個是個人另一個則是由多人所組成的團隊,個人的成功來自於持續的自我激勵,而團隊的運作則藉由成員之間的相互激勵來達成目標。愛德華先生的自我決定論點出了我們可以致力於激勵個人動機與培養自組織團隊的方法,藉由滿足個人與團隊的自主、勝任與歸屬感(聯結)三個需求來激發內在動機並藉以形成高效的學習。

傳統上;我們總是問孩子們功課作完了沒?而不是問他作完題目後你學到了什麼?前面的問法,隱含著控制與究責的意味,容易讓人產生疏離感,令人聽了心生畏懼毫無激勵的效用可言。而後面的問法,就把主權交還給孩子,讓他有自主的感覺,有機會說說自己的想法或是總結獲得的經驗(當然抱怨一下也可以吐吐怨氣有益健康),這一點展現了自主效應的重要性。

相同的,我們問工程師程式寫完了沒?做完測試了嗎? 也是錯誤的一種問法,較正確而有意義的問法,應該是; 用這種解題的方式你覺得效能如何?我們應該注意些什麼?

敏捷開發在這裡與自我決定論有著相輔相成的效果,小增量與多迭代能提供開發者落實他的學習效果,而回饋則更能夠提供自我反思的機會,它們對觸發內在動機都有著顯著的助益。也回應了開始時的第一個問題(如何來激發人們的內在動機?),如果我們在進行開發工作時,能夠落實敏捷開發的小增量、多迭代與尋求回饋的開發方式,自然就能借助SCRUM的框架來形成團隊與個人的內在動機。

而實踐透明、檢核與調適的敏捷四大會議正好能協助轉化團隊的外在動機成為內在動機的一種實踐活動。也回答了第二個問題(如何轉化外在動機成為內在動機?),對團隊而言能夠落實招開Scrum 的四大會議(請對照到上圖中的轉化過程;計畫會議;讓團隊成員確實認知我們的開發任務及目標。檢核、回顧會議;讓我們取得客戶的回饋,修正我們的開發方向,有機會精進我們的協作方式,並在自組織的團隊文化的規範下,讓團隊成員有機會相互激勵形成學習的熱情與動力),以培養、觸發開發者動機為優先考量,自然能夠水道渠成順利的將外在動機轉化成內在動機了,這一點看起來好像過於理想化了,但也不禁讓人體會到 Scrum Master的重責大任,與Scrum框架的深層內涵。


常常有人會問沒有Scrum Master 的敏捷團隊損失了甚麼?

我想損失了高效運行敏捷會議所自然而然的形成激發內在動機的機會;是一大損失。反之;DX設計者能夠適時協助團隊做好這些敏捷的會議,也是一大助益。



開發者體驗最適合由資深程式設計人員來擔任,他以過來人的身分扶助開發團隊披棘斬荊的克服開發過程中的種種障礙,協助團隊順暢的完成他們的任務。然而開發的工作是由學習開始,工程師必須要先學會欲開發的領域相關知識後,才能順利開始他們的coding作業。所以我以為開發者體驗設計,應該由激發團隊的動機作出發,因為學習的好壞是開發作業能否順暢的基礎,而內在動機又是學習者進行學習時的最好武器。因此在這裡介紹大家,一種既能夠啟發內在動機又能夠轉化外在動機成為內在動機的自我決策理論(SRT)。DX設計者能透過適時的協助團隊去掌握自主、勝任與歸屬感(聯結)這三個需求,自然能夠順利而高效的完成開發作業。

敏捷自組織團隊與自我決定論三需求有著相輔相成的效果

學習是一種同時兼具外在及內在動機的行為,最容易形成轉化。


成為一個優秀的開發人員

要成為一個好的開發人員所需要的是一種思維方式,一種DX的思維,而不僅僅是擁有好的技能。當他遇到問題時的思考方式,不僅僅是思考如何解題,而是如何進行(做到)更好的協作。


註1. 一些有關DX設計技能的文章

註2. 語出 愛德華 L.德西 著作《內在動機:自主掌控人生的力量
經由內在動機而非外在動機,才是創造、責任、健康行為以及持久改變的核心所在。外部的各種巧妙激勵或者施加的壓力 (以及內部的壓力) 有時的確能使人順從,但這種順從將帶來各種負面後果,包括滋生反抗的衝動。

如果個體所處的社會背景能夠滿足基本的心理需求(自主性、勝任感和歸屬感),它們就會得到積極、同化和綜合性質的發展格局。另一方面,過度控制,非最佳挑戰和缺乏歸屬會破壞自然賦予的固有的實現和組織傾向,因此這些因素不僅導致主動性和責任感的缺失,還會導致痛苦和精神疾病。



其實;自主、勝任與歸屬感(聯結)這三個需求,也深深的隱含在敏捷開發的運作中。它們與是否能夠形成敏捷自組織團隊有著相輔相成的關係。


註3. 見《內在動機》ch5.

明確行為與期望之間的聯繫能夠激勵需要人們看到他們的行為與期望的結果之間的聯繫,而工具性允許人們看到這些行為與結果的聯繫。(不管工具性的缺乏到底是體系、組織的錯還是處於優勢地位的個人的錯),他們就得不到激勵。

註4. Ryan, R. M., & Deci, E. L. (2000). Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. American psychologist55(1), 68.