首頁

2017年8月7日星期一

[Meetup 筆記] Seven shades of Delegation 賦權的七度色階

Agile 敏捷開發的一個目標係建立能自我組織的團隊,團隊成員能夠獲得更大的空間發揮自己的才能,自發地朝向共同目標努力。要建立出這樣的團隊需要權力下放(Delegation),更準確地說是賦權/充權(Empowerment)。但若然團隊成員習慣被管理、按指令辦事,胡亂下放超出團隊成員能力範圍的權力只會造成混亂而已。箇中平衡該如何拿捏呢?

講題:Self-organisation and transparency: Delegation Poker
講者:Herbert LEE, Agile Consultant , Palo IT
主辦:Agile Hong Kong
時間:2017/07/25 晚上
場地:銅鑼灣 WeWork Tower 535



「自我組織的團隊是在一個安心範圍賦權,去憑自己的能力、自行作出決策,以達成團隊的目標。」(A Self-Organizing team is empowered to make their own decision with their ability to achieve the goal within boundaries.)

這個星期二晚上,講者Herbert 透過工作坊帶領參加者體驗如何利用Delegation Poker,來幫助團隊找到這個「範圍」,以有序、漸進的方式去賦權。

賦權其實並非權力下放與否的二選一。在「緊握權力」或「全權委託」之間尚有不同程度的賦權。一套Delegation Poker 共有七張紙牌,代表賦權的七個層級,例如:

  • 1號牌Tell ──代表由主管全權決定指示團隊該做什麼
  • 7號牌Delegate ──代表全面授權團隊成員自行做決定

而光譜的中間:

  • 4號牌Agree ──就代表由主管和團隊成員共同做決策。


Delegation Poker: 7 levels of delegation


工作坊首先請參加者組成小隊,各自選定某個企劃情景,譬如辦公室搬遷、招聘新成員,並訂出數個企劃的關鍵事項,諸如預算、時程等等,填寫在Delegation board和計分表上。Delegation board的矩陣縱軸是企劃的關鍵事項,橫軸是賦權層級;而計分表的矩陣縱軸也是關鍵事項,而橫軸是隊員的名字。

Delegation Board


然後小隊就每個關鍵事項商討合適的賦權層級。商討過程大致如下:

  1. 包括隊長在內,每位隊員各自思考自己認為合適的層級,從自己一套Delegation Poker 中選定代表該層級的牌。
  2. 所有隊員都選好後同時亮牌。
  3. 選擇了級數最低和最高的隊員,陳述自己的觀點。
  4. 最後小隊決議這個關鍵事應有的賦權層級,記錄在Delegation board 上,也將隊員選擇的級數登在計分表。


這過程將討論焦點放在收窄分歧上。以上過程只是簡化版,尚可加入一些規則作出調整,令決議更為合理,例如:若果選擇賦權層級最高的隊員只係少數派就不會得分。

Score sheet

另外,所有關鍵事項的商討完成後,將每位隊員的分數加總,能看出隊員對賦權的態度。分數越高,表示隊員越希望獲得更大程度賦權;分數越低,表示隊員更傾向於管理和被管理。

摘要


  • 賦權並非二元抉擇,而是有不同程度的層級。
  • 不同情景和事項需要的賦權程度也有不同。
  • 賦權是一個有序、漸進的過程。


參考資料


2017年3月28日星期二

當我們談論完工時我們在談論什麼


星期一的專案進度會議快要完結。Development Manager, Doris 急不及待回去處理自己枱頭上那疊應徵者履歷;Lead Developer, Liz 心想原本要和自己pair programming 的Jo 應該已經自己一個人開始寫code 了;Product Manager, Peter 數小時後就要坐上飛往馬德里的航班;不過Pat ……Project Manager, Pat 對議程可是很執著的。

「所以,」Doris 總結道「開發團隊現已可以每星期出一次產品發佈。就等Pat 確認已經通知我們的客戶,我們便可以實行每週發佈──即是說你可以讓客戶更快用到新功能和程式修正。」

「事實上,」Liz 插嘴說「新流程容許我們每日發佈甚至按『Story』發佈。我們沒有必要再每隔一段日子集合多項程式更新才一次過發佈。」

「對、對,非常好,」Pat 開始說「可是客戶跟我們簽訂的發展大綱和發佈日程原訂是兩星期發佈一次的。我正向他們爭取每週發佈,部分人也同意了。不過刻下我們有個更重要的事項要商討……」

「Come on, Pat」Peter 打斷她「能夠更快要到新功能和程式修正,他們大部分人高興也來不及吧?」

「也許是這樣,但我們得按程序辦事。他們很多都有自己的change management group ,發佈太頻密會對他們造成問題的。事實上我知道有個跨國企業的Change Manager 寧願我們轉回去每月發佈。但正如我所講,我們有個更大的事項還未商討。」

Doris 和Liz 交換了一個了然於心的表情,她們知道接下來要發生甚麼。

Pat 板起臉來,「什麼時候,各位先生女士,我們什麼時候才可以完工?」

於是乎那個歴史悠久的戲碼又再上演……

「你說『完工』準確來說是指什麼?」Doris 問。

「你非常清楚我說的完工是什麼意思,Doris,我們都合作多久了?」Pat 頓一頓道「今天是3月14日,專案計劃原訂1月31日完成的,即是說我們遲了差不多兩個月了。幸好我預留了四個星期的緩衝期但到了現在我們要逾期了而我得向管理層提交事故報告並且要請求延期。他們首先就會問:還要花多久?你們什麼時候才完工?」

「等等,」Peter 被惹惱了「你同意過利用緩衝期的,本來我們在1月28日發佈時就可說是完工了,但是是你自己同意我們應該繼續的,我清清楚楚記得你說你在backlog 裡看到「增加營利的良機」而且每個人都會覺得緩衝期被花掉是當然的。」

「也許是這樣,Peter ,但我們需要劃一條分界線,不可能這樣子無止境繼續下去。」

「你說不能繼續下去是什麼意思?」Liz 緊張地問「你是不是知道些我們不知道的事?」

「Liz,我和所有高層都私交甚篤,我可以向你們保證這團隊沒有任何人會被裁員 。」Doris 為人勤懇,她知道Liz 被上一個僱主在聖誕佳節毫無預兆地裁走,至今仍有心理陰影。

「其實技術上來說,Doris ,這個專案完結後整隊人都會等待委派。不過我預期所有人都會立刻投入到緊接其後的下一個專案。」Pat 不像Doris 那樣能夠察言觀色「因此我必須再問一次:你們何時才能完工?」

Liz 對他們的發佈流程充滿信心:「如果你那麼想完工的話我們可以星期四完工。下一次的發佈訂在下午三時,我們可以說那天就是完成日。事實上,你想的話我們大可以說三日前就已經完工,現在就開始下一階段。」

「Pat ,」Peter 開始說「這個專案有這個專案的產品功能,下個專案有下個專案的產品功能,這些功能都是同一個產品的,坦白講,我不在乎你要如何劃這條分界線。所有工作都是我負責的,而客戶只要收到他們要的功能,根本不會在乎這些。」

「也許是這樣,但我們得按程序辦事,而這不是為了趕工期而是……」

「不是趕工期?一分鐘前你才跟我們說要趕工期!」正如大部分的編程員和測試員,Liz 覺得Pat 令人煩厭。

「工期確實重要,Liz ,因為越遲完工成本就越高,而管理層已經指示我們要減省成本了。當新專案開始就會有新一個成本代號和新一個預算。所以,什時候,拜託,什時間才會完工?」

正當Doris 要指出不管用哪個成本代號都是花同一筆錢時,Liz 先插話。

「我們還剩下多少預算?我們就繼續直至預算用盡吧。」

「Liz,我重申,我們要節省成本,那樣做節省不到成本的。」

「那我們何不將餘下要開發的功能放到下一個專案?」

「Liz ,這是不道德的!這會令下一個專案的範圍未開始就蔓延失控,增加成本並且冒不能如期完工的風險。」

「但Pat ,下一個專案不論什麼完工日期都可以做到,因為會實行每週發佈。當工期快到或預算用盡時,我們就算完工。分別只是Peter 如何排工作的優先次序。」

當提到自己時Peter 覺得有必要插話「Pat ,認真的,你說的『完工』是指什麼?如果是工期的話那麽Liz 是對的。」

「Peter ,這個專案有承諾要交付什麼項目的。」

「對,Pat,而且我們都交付了。」

「不,我們沒有。」

「你在說那些McAnderson 的顧問們放到原初業務需求文件的產品功能嗎?那些從未被加進『應有清單』而在十二個月前當我被委派時就剔除的那些?」

「不,不是那些,不過我頗清楚Pira 系統中見到那個,你們叫什麼來着,待辦事項的backlog。」

「事實上Pira 已經許久沒更新了,我們沒在用。」Liz 啐道。

「你應該要更新的,職責文件中有提到這是你的工作,我記得當中特別提到Team Leader 有責任……」

「OK 、OK ,確是有待辦事項」Peter 同意說「不過……都些可有可無的事項,我們是這幾天才從滿是垃圾的『應有清單』中提升到『須有清單』的。 我寧可將這些事項剔走,畢竟下一專案開始時還有更值得做的事。」

「我亦必需指出」Peter 續道「所有仍在待辦清單的事項都是專案開始後才追加的,即是你所謂的『專案範圍蔓延』。若然你看一下McAnderson 最初擬訂的事項──而我又未刪去的話──我們六個月前就完工了。」

「Peter,決定什麼事項應該加進來什麼應該剔走並不是我的工作,那是你和CEO Harry 決定的。我的工作是確保專案完成。那我再問一次,你們到底什麼時候能完工?」

不過Doris 也加入戰線了:「事實上,Pat,管理開發是我的工作,而我必須再向你問清楚,你說的完工到底是指什麼?」

「你不是指工期,因為你已經將專案延期而且可以再請求延期。另一方面我們可以這個星期四完工也可以上星期四就完工。日期根本無關重要。」

「你也不是指人員何時會離任,因為沒有人會被裁走,而且第二天都會留下來在同一間辦公室、寫一個程式、做同一件產品。」

「而你也不是指專案範圍──那個『我們要造些什麼』,因為McAnderson 給我們的範圍一開始就不對,所有他們要求做的,不是已經完成就是已被取消。Peter 很樂意將餘下的事項放到下一個專案,或更樂意將它們通通剔走。」

「又如果,但願不是,我們是尋求產值最大化的話,那我們就應該立刻將這個專案餘下的所有事項通通排除然後現在就開始下一個專案,因為所有餘下的事項都不會比下一個專案八成的事項更有價值。」

「所以Pat ,在你再問任何人「何時會完工」之前,可以請你先解釋清楚你說的「完工」究竟是什麼意思嗎?」



(譯自 What do you mean... Done? 作者 Allan Kelly )

2017年3月16日星期四

「領袖訓練營」其實是山寨版成人禮

近日有中學生發千字文控訴學校安排參與的領袖訓練營侮辱和虐待學生,引起社會關注。究竟為何這些訓練營要仿效軍訓?又為何內容往往涉嫌侮辱和虐待學員?

軍隊及紀律部隊的入伍訓練、大學的迎新營、宗教團體的入教儀式、古代部落和傳統社會的成人禮,其實都是人類學所謂「通過儀式」(Rite of Passage)。這是個體從一個群體轉到另一個群體的過程,其社會地位、責任、權利亦隨之改變(常常是提升)。「通過儀式」包含三個階段:

分離期

個體離開所屬群體,與原來的身份、地位、人際聯繫切割。切割包括實質的,例如入營或入宿訓練學校;也有象徵性的,例如剃頭、換穿制服或OCamp Tee。

轉型期

這是個體脫離了原屬群體,又尚未加入新群體,模糊不明、迷失的階段。為了令準成員作加入新群體準備,在心理上認清自己不再是原來群體的成員、不再享有以往的身份地位,準成員往往要接受各種肉體上和精神上的磨練,去抹除準成員原有的自我認同,以便植入新群體成員的身份認同(也就是所謂洗腦)。

重整期

這階段常常以一項超出準成員能力範圍的艱難試煉為標誌,例如數十公里長跑、從高崖躍下、獨力獵殺一頭猛獸等等,讓準成員以此證明自己具備加入新群體的能力和決心。成功挑戰的個體會於儀式上,在新群體成員的見證下獲接納成為新成員,其自信心和對新群體的歸屬感皆會大幅提升。但若果挑戰失敗,個體便要帶著不光彩的恥辱退回原屬群體。


相對傳統社會,人人必會經歷數個「通過儀式」,現代傾向個體主義的社會結構改變,令「通過儀式」少了很多(例如,任何人達到法定年齡就會自動被判定為成年人。)。有意見認為「通過儀式」對年青人的成長很有裨益,於是藉模仿軍訓的內容去設計訓練課程,以重建年青人成長過程所欠缺的「通過儀式」──也就是坊間常見的「領袖訓練營」。

不過這種山寨式「通過儀式」都存在一個重大盲點。前文提到「通過儀式」是「個體從一個群體轉到另一個群體的過程,其社會地位、責任、權利亦隨之改變」。但很明顯單單上過「領袖訓練營」是不可能有社會地位、責任、權利的改變,更甚者可能連新群體也沒有。欠缺這些社會元素的冒牌「通過儀式」,就空餘沒有目的磨練、洗腦和挑戰失敗的恥辱

你還相信年青人需要這種「領袖訓練」嗎?

2016年2月6日星期六

[Youtube 筆記] A/B Testing 的六個心得

A/B Testing 是網絡應用――尤其電子商務網站――常用的測試,目的是透過抽樣測試來獲得使用者數據,為採納何種系統改動的決策提供依據。系統改動可以是頁面排版設計、按鈕的顏色和描述文字,甚或購物流程的變更。其原理為利用測試工具隨機將部份使用者發配到不同的系統改動試版,再觀察各試版和原版的使用者行為,例如註冊比率,來比較改動的效果。
(錄像截圖)

這段錄像是Google Venture Startup Lab 2013 上一個題為"A/B testing done right"的演講。講者是網站分析工具Optimizely 的創辦人,過去曾於Google 和奧巴馬競選團隊工作。



演講上他以自己工作過的個案為例子,分享了採用A/B 測試進行系統改進的六個心得:

(錄像截圖)

1. 先釐清成功基準,而且是可量化的。


例如,改進目標是提升註冊人數,不加思索的話會以為要優化的是註冊表格,但將網站訪客轉換成註冊用戶的瓶頸,可能其實是由其他頁面跳到註冊頁面這個環節上。那麼要改進的應該是引導訪客註冊的按鈕,而量度指標就會是該按鈕的點擊率。
(錄像截圖)

2. 先探索再焠鍊


A/B 測試是一個篩選方案過程,故此測試應盡量探索各種改進的可能性供篩選,以免鑽牛角尖而錯過最佳方案。
source: https://blog.intercom.io/criticism-and-two-way-streets/


3. 削減選項 Less is more. 


過多選項會令人無所適從。減少選項更能引導使用者採取行動。
(錄像截圖)

4. 用詞很重要,尤其是Call To Action


那些呼籲使用者註冊、購買、捐獻的按鈕或連結的用詞,對使用者是會否行動非常關鍵。
(錄像截圖)

5. 失敗要早


那些我們以為會帶來改進的變更,並不一定都是正確的,有時候甚至會適得其反,尤其是變更有違使用者的習慣。採用A/B 測試能在正式採用前及早發現那些錯誤的變更。
(錄像截圖)

6. 今天就開始


越早採用A/B 測試越早受益。



2016年1月17日星期日

[Meetup 筆記] 如何繪畫別人看得懂的軟件架構圖?──Simon Brown 的C4 Model

作為軟件開發者,你試過看不懂別人的架構圖嗎?或是自己嘔心瀝血徹夜畫的架構圖,別人卻看不懂?

講題:The Art of Visualising Software Architecture
講者:Simon Brown (個人網站
主辦:Agile Hong Kong
時間:2016/01/15 晚上
場地:Odd-e 在上環的新辦公室


上星期五晚出席了一個關於軟件架構視覺化的講座。講者Simon Brown 多年從事系統架構的顧問和培訓工作,也會到世界各地演講,著作有Software Architecture for Developers 和The Art of Visualising Software Architecture 。其題為"The Conflict Between Agile and Architecture - Myth or Reality?" 的演講在Software Engineering Institute 主辦的SATURN Conference 2013中,獲參予者票選為"Architecture in Practice" Presentation Award 得主。

軟件開發者常要畫架構圖,但沒人看得懂……


講者Simon 首先提到敏捷開發有賴良好溝通,但在他工作和開辦工作坊的經驗中,發覺很多開發者無法有效地講解自己的構想,想傳達的資訊往往像卡在他們的腦袋裡。雖然開發者常畫圖來幫助講解,而軟件工程界也制訂了諸如UML 的建模語言和製圖規範,不過事實上大部分人都覺得UML太複雜所以很少用,尤其是高階的架構設計圖。

於是很多開發者以自己的方式畫了令人不明所以的系統架構圖。有些圖使用了意味不明的顏色和圖形(這個粉紅色的虛線想表示什麼?),有些則過多實作細節(User → UI → Calculation Engine → Data Reader → ……),有些將架構(Architecture)、運行(Execution)、部署(Deployment)等不同面向的內容混在同一幅圖裡(Import Service, cron, UNIX VM instance, …… )。結果這些「設計圖」徒令本來要說明的構想更難理解。

C4 Model - 地圖的類比


針對上述情況,Simon 認為"A common set of abstractions is more important than a common notation.",提倡C4 Model (Context, Container, Component, Class),將系統架構分成四個層級的抽象化。一個系統會有一個Context 以及各種使用者和其他外部系統,Context 由多個Container構成(例如web app, mobile client, database, etc.),每個Container 包括數個Component ,而Component 由class 組成。