#反求諸己

我想特別 highlight 這一段，給所有的工程師朋友參考。

「科學家為什麼不能只寫 "行內人"懂的東西？幹嘛花力氣跟行外的一般人講解我在做什麼？一部分的原因是，你的研究(經費)是受到大眾支持的(稅金)，你需要好好的跟你的老闆(繳稅的大家)介紹你在做什麼，有什麼重要性，有什麼意思。當大家不能體會你的重要性，就是你的經費要結束的那一刻。

反過來說，當大家從這些科普書籍科普文章中知道這些研究是有趣而且重要的，自然就有可能出現支持科學研究的音量，產生正向循環。

就像Weinberg說的，你要溝通的對象都跟你一樣聰明，只是沒有受過這方面的專業訓練。你要用對方聽得懂的話跟他們溝通，而不是用自己的行話自己說自己的，然後抱怨我講的很認真為什麼大家都聽不懂。」

簡單的三段，字字珠璣！

➀ 你想要公司、老闆、PM、PO、stakeholder 來支持你引入的變革，來支持基礎建設的投資，不能一直怪他們不懂，不能只怪他們短視近利，覺得他們聽不進去。

能做的是，鍛鍊自己的表達能力、溝通能力、觀察能力，甚至還要培養自己的 creadit 以及跟他們的 trust 跟 relationship。因為這也是我們該做的事，不是只有技術。（這甚至稱不上是政治）

➁ 正向循環，一樣，如果沒有開始，沒有引入一個新的增強或減弱，來推動因果循環，就不會改變現狀，無法推動正向循環。這也是為什麼，我們通常會提： Show, Don't Tell。

一旦你先額外投入做出了一些我們彼此都關心的成果，搭配第一點的換位思考跟表達能力，正向循環的起點才會萌芽。

你都願意提前、額外投入心力開始去做出一些成果，也證明了你的動機，你的行動就是對這樣變革最好支持的證據。

➂ 其他人不是笨蛋，講行話只是一種「知識的詛咒」的現象，一切至少先反求諸己，看自己還有哪方面的能力可以提昇的（尤其是軟技能面的軟實力）。

同時也別忘了觀察力，因為真的仍有可能，你身處的單位或組織，在你竭盡一切能力都無法力挽狂瀾時，不要浪費自己的生命跟青春了，有學到東西、累積到經驗，去尋找更能讓自己發光發熱的舞台吧。

最後，如果你的過去一直都是在抱怨，每一間公司都沒有舞台讓你發揮，都無法讓你力挽狂瀾，通常就是：要嘛你判斷力有問題，從對公司的選擇就出錯了。要嘛你能力還有問題，不管是軟實力或是硬實力。

反求諸己，怪環境、怪他人總是比較簡單的路，然而那就是會讓自己停滯不前的路。

我想到之前跟 Odd-e 國外的同事聊到 coaching 或 training 費用定價的相關事情，有一句話我印象很深刻：

「當然你還是有可能會因為市場競爭，而需要降價、降低自己的bar 來獲得生存。

但永遠都別忘了，金字塔上層的需求一直都在的，我們接觸不到，不意味著它不存在。

而是我們還未擁有足夠的能力、資格，去服務他們，讓他們看見我們的能力足以滿足他們的目標。

永遠不要忘了讓自己持續精進，避免歸咎在環境、市場、他人，而是看自己還有哪些方面要調整、改善、學習。」

這一直都與 敏捷 中的「務實」相呼應著，反求諸己，往往是最務實的作法。

我還記得 Daniel 在培訓所作最後的 retrospective 時針對 action 的部份都會強調一點：「在沒有任何其他人的幫助下，可能是你的老闆、主管、產品經理或你的團隊成員，你能在未來一週，做點什麼改變與應用所學。」

那個前提就是立個旗子，讓自己先少點藉口。

有時，成果失敗了，不是真失敗。沒有行動，以及慣性把失敗的原因歸就在他人與環境上，才是導致失敗的根本原因。

[你還在跑集體心理治療的 Retrospective 嗎?]

有些剛接觸敏捷的朋友, 看到公司在開 retro 會議
他好奇的問到這個會議有用嗎?
感覺好像是集體心理治療

我就詢問他說為什麼會有這個想法
他說到每次 Scrum Master 召開這個會議時
會用到不同的引導方法
像是 4L, ORID, 帆船法, Good/Could be better....
看起來 Scrum Master 好厲害, 引導功力好棒

可是每次會議都是在收集問題
雖然有些 action item
但是下次也沒有聽到那些 action item 的處理狀況
事情提了沒有被處理
這樣下次還有人要提嗎?
感覺只是每次讓大家宣洩一下不滿

就算有講一下上次 action item 的執行狀況
但是下次可能就在沒下文了
很多東西真的能改一次就好了嗎?
沒有持續討論改進, 真的會有成果嗎?

你們的回顧會議也是這樣嗎?

敏捷宣言明年就 20 年了，從敏捷宣言簽署者之一 Ron Jeffries 在 2 年前講出這樣的話，自然是很夠份量的。
　
敏捷宣言其實是站在「軟體產品」的角度，解決人、協作、組織、文化上的根本問題。
　
然而，軟體產品中最核心的本質「開發與交付」其實是在更前面的 extreme programming （極限編程，簡稱 XP）就被帶出來了，而且這件事並沒有因為敏捷宣言而改變。
　
為什麼這個世界上大部分的「人」（也就是不只開發人員）大部分搞 scrum 類型的框架弄不太起來，而真的弄得起來的人，你可以說他們不用 scrum 可能軟體的交付速度、品質也不會差到哪去。
　
那是因為核心還是 XP 啊。他們用 scrum 類的協作方式，可以改善他們需求、溝通、協作上的浪費，用 LeSS 可以帶著全局思考的角度，避免局部優化的浪費。
　
但大部份畫虎不成反類犬的公司在敏捷轉型過程，這些軟體產品開發的本質才是他們的核心問題，他們用 scrum 初期好處就是透明，然後發現組織存在更多這樣的問題，但大部份的角色（包含開發人員）對極限編程的實踐、精神都是迴避跟鴕鳥的，他們寧可喜歡兩週裡面開開 daily meeting, retrospective, planning, review (然後也沒有比較扎實的 refinement)，至少他們覺得自己「在 scrum」，失敗了在賴給它就好了。
　
如果你是個開發人員，至少你可以跟其他開發人員先從 #極限編程 的實踐做起，至少你會開心一點，而且累積在自己身上的，誰也帶不走。
　
等到你有這樣的能力，你能選擇跟這樣的團隊在一起工作，屆時你們要解決的，就只剩下協作的問題了，那時你們自然就會去搞 scrum 類型的方式來解決你們瓶頸的問題。
　
看到了嗎？這就是 20 年前，一群技術大神聚在一起寫敏捷宣言的背景啊...他們都是技術大神，技術問題基本上對他們來說是不存在的，他們弄敏捷宣言就是因為技術對他們來說不是問題了，自然要扭轉一下世人過去瀑布類型方式的問題瓶頸。
　
來源：https://ronjeffries.com/articles/018-01ff/abandon-1/
　
簡體譯文：https://mp.weixin.qq.com/s/UbG5XNXrSWdMBdao0RXIwg
　
講那麼多，持續整合、pair programming、單元測試、重構、測試驅動開發、讓需求單位早點提供 feedback 或參與，大家做了多少呢？