貝爾賓團隊角色理論 (Belbin Team Roles) 是英國 Dr. Raymond Meredith Belbin 教授所提出, 對於團隊組成和管理要怎麼做提出一些作法. 貝爾賓研究後發現, 成功團隊中成員, 通常會包含以下九種角色. 如果這九種角色齊全, 團隊就能運作良好.
- 1月 06 週日 201912:56
認識自己和看清團隊: 貝爾賓團隊角色理論
貝爾賓團隊角色理論 (Belbin Team Roles) 是英國 Dr. Raymond Meredith Belbin 教授所提出, 對於團隊組成和管理要怎麼做提出一些作法. 貝爾賓研究後發現, 成功團隊中成員, 通常會包含以下九種角色. 如果這九種角色齊全, 團隊就能運作良好.
- 9月 03 週日 201721:24
流程設計與跨部門溝通上課心得
這個週末去上了識博管理所開的: 流程設計與跨部門溝通. 之前聽人家說這門課十分有趣, 並且 JB 也鼓勵我來看看. 因此特定找了一個時間來上課.
- 1月 30 週五 201509:25
程式品質與可預設性跟 practice 關聯性的調查
Developer Productivity Report 2013 - How engineering tools & practices impact software quality & delivery
http://zeroturnaround.com/rebellabs/download/?token=80eb432c1d5edfc886f91ad2169c139196a99127&utm_medium=email
- 1月 13 週二 201508:43
相信數字 v.s. 相信人性
最近在準備一份簡報時, 需要研究一下管理學的演進, 發現到泰勒和彼得杜拉克, 這兩個人對於管理的方式, 有著很不一樣的想法.
- 1月 08 週四 201523:10
你衡量什麼就會得到什麼?
通常團隊中, 我們會建立一些指標, 來衡量我們做得好不好. Henrik Kniberg 在 “How do you know that your product works?” 的分享中, 提出了三種常見的方式:
- 6月 19 週四 201407:02
敏捷開發中的客戶角色的演變
在 Scrum Gathering Shanghai 2014 中, 有一場演講的講者是 Alan Atlas, 他之前擔任過 Amazon S3 的開發經理, 那時候他用的就是 Scrum 方法來帶領團隊. 所以那天特別期待他的分享. 這次他演講的題目是: 敏捷開發中的客戶角色的演變. 他利用開發方法的演進, 來說明開發團隊和客戶的關係.
1. 瀑布式開發
客戶? 客戶是什麼東西? 從 waterfall model 中, 你根本看不到客戶在哪. 在這個階段, 開發人員只是自己做得很爽, 只希望別人不要來打擾他, 只要時間一到奇蹟就會發生, 就會做出客戶要的東西.
- 6月 18 週三 201410:57
系統化思考, 那不關我的事啦
目前公司是一個很注重教育訓練的公司, 它舉辦了不少內部訓練, 因此每個員工都有很多機會學習到不同的知識.
在這個過程中, 遇到一件很有趣的事情. 我們一共有三個單位負責不同的教育訓練:
A 單位: 負責辦理內部讀書會的規劃
B 單位: 負責辦理語文訓練
C 單位: 負責辦理內部分享會議, 以及短期和中期的教育訓練課程.
大家都很努力把手頭上的工作給做好, 因此辦了非常多的課程, 看起來似乎各司其職, 大家都很盡責任.
可是老闆卻有很多抱怨, 他說我們員工都跑去參加訓練, 那工作誰要來做?
- 6月 17 週二 201407:04
遊戲化 (Gamification) 的畫布模型
開始當經理後, 常常會聽到一堆企業策略, 可是不管這些策略再高明, 如果你的員工工作沒有熱忱, 不願意投入到工作中, 那一切都是空談.
此外, 現在一心多用的狀況, 已經是很常見的. 同時間會有好多東西, 吸引著你的員工, 像是 Facebook, WeChat, Line 等等訊息, 隨時會讓員工分心去處理.
因此公司的成敗, 在於能爭取到, 員工多少熱忱的參與. 為了讓員工有興趣, 你必須要盡可能地, 打造好玩和吸引人的工作體驗, 這樣你才能打敗對手. 而這個過程就是企業遊戲化.
所以企業遊戲化, 就是要結合遊戲設計, 忠誠方案, 以及行為經濟學, 來讓大家樂於解決重要的問題, 並且提高參與的熱忱.
在 Scrum gathering Shanghai 2014 中, 有一場分享: Reality Healing - 3 個真實遊戲化項目試驗, 就是談他如何在公司中進行遊戲化, 試圖來幫助專案能進行得更順利, 員工的士氣能夠更提升. 其中一種做法, 就是他建立出一個遊戲化的畫布, 來規劃遊戲化要如何進行. 這樣的概念歐美已經有人提了, 你可以在這裡找到 template
http://www.kioskcts.com/wp-content/uploads/2013/12/gamification_model_canvas_poster.pdf
不過, 演講者提出的比較特別, 他的畫布長的像下面這個樣子
- 5月 28 週三 201407:06
成功沒有捷徑, 一切都是基本功
David J Anderson 在 Kanban 一書中提到, 他想出一組成功的方法, 認為如果可以做到這些事情, 專案的執行應該可以成功.
1. 專注于品質
2. 減少同時進行的工作
3. 頻繁的交付
4. 根據交付速度, 來平衡需求的請求
5. 進行優先順序的排序
6. 消除變異性, 以提高可預測性
這些方法是需要照順序來實施的, 這是有原因的. 前面的項目通常都是團隊能夠控制, 或者是能控制的狀況比較多. 後面的項目, 你不太可能只有自己做好就可以, 你必須和其他人配合, 要和上下游的部門一起合作.
改變是困難的, 尤其還要改變別人, 因此你必須要從自己先做起, 或者自己能控制的部分開始, 然後才去考量別的事情.
為什麼會提到這些事情呢? 最近在公司內要和其他團隊, 一起合作開發新的產品. 老大給的時間很短, 可是要做事情很多, 如果大家想要能將產品做得很好, 是件不容易的任務.
根據 David J Anderson 的建議, 如果想要能有所改進, 我想可以先做的, 就是專注于品質的改進, 唯有先確保自己產品有一定的水準, 這樣後面才不會因為大量的 bug, 要不斷的重工 (rework) 去修復, 導致產品 release 時程遙遙無期.
此外, David 也提到, 要改善品質, 不管傳統方法或者是敏捷的做法, 都是能發揮作用. 因此, 不管你用 review, inspection, unit testing, TDD, design pattern 或者是 pair programming, 重點在嚴格落實, 確實執行. 經過一段時間後, 系統品質自然會控制在一定範圍之內.
所以在未來的二個月中, 最重要的是確保以下事情進行順利:
團隊成員需要密切討論合作, 確保大家知道相同的事情, 減少 handsoff 的狀況.
設計要及早檢視, 避免誤解需求, 或者考慮不周的設計
及早測試, 不管是利用自動化或是手動測試, 期待第一時間給與回饋
希望三個月後, 可以很高興的跟大家講, 這樣的做法, 是對專案有幫助. 一定要成功啊 …..
- 5月 23 週五 201407:20
如何解決集體討論的陷阱
上次提到在集體討論中, 會遇到一些問題, 導致效果並沒有很好. 為了解決這些問題, 你可以嘗試這些方法
1. 7 +- 2 人的團隊
盡可能讓團隊不要太大, 這讓每個人曝光機會變大, 都需要發言或是做些事情, 否則很快就會被別人知道自己沒有貢獻.
2. 讓他們有 ownership
不要每次團隊成員就只是扮演聽命行事的人, 你可以讓他們主持 planning meeting, review meeting, 或是 retro meeting. 讓他們有機會自己決定, 或自己處理一些事情.
3. 利用便利貼討論
在使用便利貼討論時, 先讓大家寫個 5-10 鐘的意見, 然後再從非管理階層, 或是不常說話的人, 開始輪流發表. 避免聲音大的人, 或是老闆一下就控制講話的方向.
4. 利用白板討論
把討論的內容發表在白板上面, 讓大家重點集中在白板上面, 而不是對方或是另一個人上面, 也就是不要讓人們直接面對面衝突.
5. Playing poker 進行方式
不是只有少數服從多數的表决, 它讓不同意見的, 不同角色的人能發表, 並且加上遊戲的因素, 使得集體評估的過程, 變得好玩又有效.
6. 不同形式的 retro
為了讓集體討論不會流於形式, 你需要有不同形式的執行方式, 例如 retrospective meeting 便需要很多花招, 這樣大家才不會覺得很悶
http://kojenchieh.pixnet.net/blog/post/354638144
所以我常常說 scrum master 不是只要會 scrum, 帶團康, 跳大腿舞可能樣樣都要具備, 這樣才能引導大家, 做好集體討論的活動 XDDD
