小心定律就在你身邊 – 五個系統設計常用的定律

讀到每个程序员都该知道的五大定理5 laws every developer should know),感覺這些可以應用在系統設計上的定律,應用在社會和人生上也没有違和感。

文中提到的五個定律分别是

  1. 墨菲定律 Murphy’s law
  2. 高德納定律 Knuth’s law
  3. 諾斯定律 North’s law
  4. 康威定律 Conway’s law
  5. 帕金森瑣事定律 Parkinson’s law of triviality

1. 【墨菲定律 Murphy’s law】

“只要有可能出錯,就一定會出錯。”
“Anything that can go wrong will go wrong.”

如果殺人祭天有用,就殺吧。但如果換另一個人還是有可能出錯,這時獵女巫是没有用的,系統性問題要用備源、防呆、容錯、再確認等等機制處理。

舉例:從 815 大停電談「系統的崩壞」 閱讀全文 小心定律就在你身邊 – 五個系統設計常用的定律

五育中消失的群育 – 談如何團隊合作

今天聽實習生們四個月實習的心得分享,蠻多的共通收穫是『第一次以團隊方式把事情做出來』,即使之前在學校有專題團隊,但也是各自分工不合作,大家分派工作最後再組合起來。而在實習過程中,成員利用 Scrum 的方式,及時了解每個工作的進度,互相支援遇到的問題,密集的分享和學習,還有一群很雞婆的哥哥姐姐們噓寒問暖,都是之前沒有的體驗。

回想我們從小都聽說要『德智體群美』五育俱全,但我之前也從來不知道群育是什麼,頂多就是玩玩團康,組組球隊。學校不但不鼓勵還懲罰合作的行為(比如作弊 XD)。但不能怪老師,我想除了投票『服從多數、尊重少數』,老師也沒有受過如何教導團隊合作的訓練。

我也是在這幾年在 Scrum 中找到答案,除了快速迭代、適應變化這個優點外,我覺得 Scrum 的重點價值是以團隊為主體運作,讓團隊取得個人所沒有的特性,比如團隊比個人反脆弱、團隊比個人的視野更廣、盲點更少。但要讓團隊有這些特性不是容易的事,我認為有三個觀察點:

  1. 成員是否都能安心的表達自己想法?
  2. 成員的個性與觀點是否夠多元?
  3. 團隊有沒有好的決策模式?

閱讀全文 五育中消失的群育 – 談如何團隊合作

多維度的思維模型 – 領導者的蜕變心得

我在​領導者的蜕變一書中最大的學習是:不同思維的階段有不同的修練,需要不同的協助。

書中說對如何識别思維,和如何提升思維解釋的很詳細,他把思維模型分為四種:以我為尊、規範主導、自主導向、内觀自變。

而我的記憶力不是很好,每次要說概念這都說不清楚,剛好最近又跟伙伴瞎扯到多次元,如星際效應三體等等不同次元的互動情况。因有互相印證的地方,又容易記,就分享給大家我的 Mapping table。

  • 以我為尊:一維
  • 規範主導:二維
  • 自主導向:三維
  • 内觀自變:四維


要靠高維度協助低維度升級,因低維度無法理解高維度,就像小朋友(三維)撕漫畫(二維),漫畫上的角色没辦法理解發生什麼事,只會覺得外星人出現。

而我認為至少要二維願意往三維的思維才適合跑敏捷。

【如何幫助思維升級】
一維到二維:提供具體範例和操作方法(守)

二維到三維:協助重新定義和質疑權威(破)

三維到四維:引導揭露假設與質疑應然(離)

四維以上:持續探索未知觀點

【不同維度的思維】
一維思維【直線】:只有『我』的觀點,跟我不一樣的觀點不存在,如直線以外都是未知。

二維思維【平面】:我和他人的直線構成平面成為『我們』的觀點,跟我們一樣就是對,不一樣就是錯,就如同紙的兩面。

三維思維【立體】:眾多個不同觀點交錯形成『我、他人、情境』立體化的思維,可以從上下左右多個角度思考並保持主體性,可運用别人的觀點强化自己的論點。

四維思維【單形】:利用别人的觀點升級自己的思維系統。相對三維而言,四維不利用别人觀點强化自己論點,甚至會改變每次的互動模式,不惜把思維系統曝露在風險中。

初一十五不一樣 – 引導後的結論是正確答案嗎?

相信每個問題都有正確答案,這是我受過理工訓練後最大的恩賜,也是最大的業障。所以我剛剛接觸引導的時候,最大的疑惑是『花了這麼多時間引導和討論,但這結論真的是正確的嗎?』

比如說討論主題是『有效團隊合作的要素有那些?』,可能有些結論是强勢領導加服從紀律,有些說是僕人式領導加自由發揮,有些要素可能還互相矛盾,比如和同事有深刻的私交超友誼更好,相對於下班後絕對不要跟同事碰面卸下面具露出真面目。甚至可能同一群人討論出來的結論,三天後再討論一次的結果又變了,那到底哪個是正確的答案呢? 閱讀全文 初一十五不一樣 – 引導後的結論是正確答案嗎?

適合敏捷式組織的架構:全員參與制(Sociocracy)、認可決、雙連結

1c02089開始跑敏捷後會開始遇到一些跟傳統科層式組織格格不入的地方。科層式的組織架構的優點是中央決策,可以最大化命令與控制的力道。但在敏捷中強調的是讓第一線人員做出決策,傳統的組織就變成一個綁手綁腳的設計,所以如何讓組織架構成為產品開發的助力就是一個大問題。

當初第一個找到的其他組織模式是弄合制Holacracy),也買了專門討論 Holacracy 的書 – 無主管公司 – 研究一下。看完後的第一印象不好,主要有兩個原因,第一個原因是作者一直強調要用就要整套用,All or Nothing。換句話說是要組織整體打掉重練,跟我看情況挑戰、摸著石頭過河、小步快跑的哲學不和。

第二個原因是太太太複雜了也太太太嚴謹了,從營運、角色定義、每個人職權、到會議如何開都有規範,還一定要規範出來,跟敏捷大家不分彼此一起把事情搞定的原則違背(有興趣的朋友可以參考弄合制憲法,我最討厭規則連看都懶的看 XD

總之就是喜歡他的初衷但設計不對胃口,就擱下來了。直到參加新加坡的敏捷年會,聽到 Jutta Eckstein 主講的 Sociocracy – A means for true agile organizations。聽到興趣就來了,因為 Sociocracy (沒有正式中文翻譯,Wiki 上翻成全民政治,我偏好稱為全員參與制,簡稱全參制。)強調的是大原則,沒有制式的方法跑,給很大的彈性,可以進階的嘗試導入。 閱讀全文 適合敏捷式組織的架構:全員參與制(Sociocracy)、認可決、雙連結

Scrum 中一個 Sprint 要排多少工作量? – 談談『成年人』

my_workload

最近台灣 Scrum Community 的 FB 社團非常熱鬧,有很多深度的討論,應該是天氣太冷了大家呆在家裡沒事做 XD

這個討論串談到一個Sprint應該排 80%,100% 還是 120% 的工作量?,被 John 點名了一定要扯淡一下的啦。 以下是我的回應:


今年有幸參加 Gerald Weinberg 和 Esther DerbyProblem Solving Leadership (PSL)工作坊,到現在還沒寫心得,因為太多點了不知如何寫起 XD

就說說其中一件與『成年人』有關的事件好了,在第二天的其中團隊活動結束後的 Retro,有一個夥伴出來分享,他說他很自責,因為他知道正確答案,但沒能說服團隊依照他的方案走,所以後來團隊失敗了。 閱讀全文 Scrum 中一個 Sprint 要排多少工作量? – 談談『成年人』

一回生、兩回熟 – 公司內開放空間會議第二彈

今年中內部討論要不要辦開放空間會議Open Space Technology)時,就決定今年至少要辦兩次,讓參與者可以比較兩次的差異性。所以在六月第一次舉辦後就接著安排九月的開放空間,第一次的主題是:『What can we do to support each other grow? / 我們要做那些事情來相互支持成長?』,而這次的主題定為:

我們要如何在接下來的三個月創造最大的影響?  
How can we create the most impact in the next 3 months?  

稍作改變的活動規劃

跟第一次的主題相比,第二次的主題刻意訂的範圍小一點,比較聚焦。有兩個原因,一是因為組織文化比較行動導向,太發散或天馬行空的發想怕大家覺得浪費時間。二是也是為了讓大家了解其實主題或討論結果可以實踐在工作上面。 閱讀全文 一回生、兩回熟 – 公司內開放空間會議第二彈

找出組織無法變敏捷的阻礙 – 團隊共創法實做

14441077_10154328911255751_5785789802293353355_n當敏捷遇上引導的談話發生後,David, Abraham 和 Vicky 就進入了籌備模式,花了不少時間研究如何設計流程,才能讓參與的夥伴可以在表訂時間2.5個小時內得出共識。

當場 Vicky 的引導創造了讓大家安全說話的環境,我自己感覺到大家發言到欲罷不能,如沒有受限於時間因素,命名出來的群組名字有機會更直指核心。由於參加的夥伴來自個個不同組織,有開發團隊、ScrumMaster、Product Owner、主管等等角色,產出的結果應該蠻有代表性。

結論是推行敏捷會遇到以下的阻礙:

1. 現在好好的幹嘛改變
2. 團隊不知道如何建立信任
3. 對敏捷的導入沒有共識
4. (主管/ScrumMaster) 的引導技巧不夠
5. 團隊溝通不夠有效
6. 高層的信任和支持不夠
7. 傳統的績效管理不適用
8. 不知道如何用 Agile 處理(範圍時程)硬梆梆的專案
9. 工程和領域的技能不夠
10. (因資源有限)角色重疊混淆
11. (不知道如何)讓member 感受到結果的價值
12. 缺乏跨界交流的機會 閱讀全文 找出組織無法變敏捷的阻礙 – 團隊共創法實做

敏捷X引導 – 讓Scrum團隊自組織的具體方法

在開始時跑 Scrum 時就自己腦補,所謂引導就是『引誘+誤導』團隊乖乖按照自己的既定方向走 XD。所以去讀了些心理暗示與影響力的書,在會議前先設想期待的結果,設下陷阱讓團隊講出自己的答案。

大多數時候過程都可以按照自己的劇本發生,而當自己預期的答案沒有出來時,就用誘導式問題(Leading Questions)讓團隊就範,讓自己的答案從團隊成員的嘴巴中說出來。如果爭議太大的議題,就先埋好暗樁,適時的跳出來帶一下風向。

(English version published on T.8ytes 英文版發表於 T.8ytes)

在我2014年剛剛開始接觸 Scrum 的時候,覺得 ScrumMaster 是個神一般的存在,不但要幫助團隊了解 Scrum 架構與敏捷精神、支持團隊提升技術能力 、教導團隊如何自組織、移除團隊成長的障礙、協助 Product Owner 產出價值最大的化的 Product Backlog、解決組織中影響團隊運行的阻礙,更扯的是他跟團隊是平行單位,完全沒有叫人做事的權力,乾脆找超人還比較容易 XD

以上職責要一個人全部做到非常挑戰,但一個個分開個別來看,至少都還看得懂要做些什麼。但其中最令我困惑的是提到 ScrumMaster 要引導團隊的部分,而且還特別強調這部分的重要性,但引導(Facilitate)到底是什麼意思呢? 閱讀全文 敏捷X引導 – 讓Scrum團隊自組織的具體方法

敏捷不是天上掉下來的 – 組織演變的過程

545665-bananas-evolution-funny-homer-simpson-monkeys-the-simpsons

這兩年最常被問到的兩個問題:『為什麼要導入 Agile 敏捷?』和『敏捷是最有效的管理方式嗎?』

『為什麼要導入敏捷?』

這問題的答案很簡單,我們開始搞敏捷是因為當時看不到未來。

儘管很多夥伴都取得 PMP 證照,嘗試傳統專案管理的方式。但專案還是永遠趕不上進度,客戶不滿意我們的產出速度,更別提產品上線後一堆Bug,夥伴都操到累翻,主管最怕的事情就是收到離職信,整天都在救火。 閱讀全文 敏捷不是天上掉下來的 – 組織演變的過程