其一

過去這一年，我針對 monitoring 議題發表兩次演講：〈Whoscall 的 Realtime Monitoring 經驗分享〉及〈Monitoring 改造計畫：流程觀點〉，可看出那段日子我的關注重點。

Monitoring，在傳統 value stream 來看，是偏向 Ops 這一端，發揮空間狀似沒有像 Dev 那麼寬廣。

其實不然。站在 monitoring 這個制高點，幫助我更深刻體會 lean thinking 及 TOC 都很注重的 “flow”。

以此視野看系統，我看到某些 services 問題，需要從研發環節下手，甚至是要將 QA 或 QC 意識放到研發者心中，才有顯著改善的可能。

像《鳳凰項目》主角 Bill，也是從 Ops 位子出發，進而掌握 TOC 聚焦五步驟系統思考的要領，替自己開拓更寬廣的舞台。

這就是我所說的：

其實，每一個位子都有可能發光發熱，重點仍在於是否有自覺進行「換位思考」及「系統思考」。

有自覺，你的一年工作經驗，就有別人 N 年的價值；反之，你的 N 年工作經驗，就只有一年的價值。

--- Quote: 2016-08-20 Tweet

有系統思考的習慣，才有較大機會聚焦在最核心的環節去看問題、想對策。



其二

我在〈從限制理論看 DevOps〉演講中提了一個概略的激發方案：「採取可提升研發價值的 DevOps 手法」。但單靠這一個激發方案，仍然不夠，一下子就會遇到負面分歧的挑戰。

像軟體研發這種腦力密集的知識工作者，注意力是稀有資源，需要善加保護；加諸過多規條，不見得是好事。尤其面對這一群都稱得上是 senior 等級的研發者，任何改變措施更是要放在刀口上。

每個解決方案都是在產生新的現實，新的現實就是我們從沒有想像過的
新的可能性。我們進行一項改變之後，應回頭查看新的改變所帶來的影響，並看看所有相關事項能否配合並運作良好。
--- Quote:《抉擇》pp. 198–199

有換位思考的習慣，才有較大機會策劃出阻力最小的槓桿解。



其三

我選擇 "test double" 作為現階段最希望研發團隊強化鞏固的環節，不只為了品質，也為了日後一些 microservices 軟體架構精進措施，會以此手法為基礎。正好公司最近也想對內部技術分享的形式做一些改變，我就把這兩件事合併處理：以 test double 作為技術分享的題材，一舉兩得。

針對這二合一事項，我開給研發團隊的閱讀清單是：

Part I / 如何提升軟體的可測試性：

Part II / 五種 Test Double 技巧：

我著重在鞏固 QA 及 QC 的意識。至於要不要 TDD，要放在單元測試層次還是 API 層次，我不認為是現階段該考慮或規範的重點，我讓各專案自己決定。

融入既有流程，抓大放小。



其四

多篇文章、或多篇章節的閱讀材料，傳統的做法是：分配章節，輪流報告。

不過，大家都知道，憑一己之力先啃過、或是輪到自己要負責上台報告的章節，最有機會讀到心坎裡。

最近嗜讀《如何閱讀一本書》的圈子，也有這種感想：

要怎麼看懂自己不理解的東西？一種常見的作法是請教別人書中的意義，或是透過閱讀其他書籍來了解 [...] 這種透過「外力」增進理解力的方法，在《如何閱讀一本書》的定義，都不算是「真正的閱讀」。

依據書中定義，真正的閱讀（閱讀的藝術）代表：「一個憑藉著頭腦運作，除了玩味讀物中的一些字句之外，不假任何外助，以一己之力來提升自我的過程。」這個標準好高。

--- Quote: 〈閱讀的目標〉
有了「導讀者」，那週不是擔任導讀者的人就會變得比較鬆懈，反而收穫最多的是擔任導讀的人。 [...] 如果真的要參加有導讀者的讀書會聚會，為了避免這種現象，我會建議先將書看完後再去參加，將你的心態調整跟導讀者的角色一樣，你去參與反而可以跟導讀者做更密切的交流，提出你不一樣的觀點或是問題。

--- Quote: 〈閱讀筆記 - 如何閱讀一本書／第一章：閱讀的活力與藝術〉

所以，這次在公司的讀書會，我直接去掉輪流「導讀」的角色，要求參加者，每個人都要靠自己的力量，親自讀過每一份材料；而且，要讀出重點精髓。

簡言之，要善用我在〈精讀與泛讀〉一文提到很管用的「提問」及「活化」步驟。帶著「問題意識」去讀，當主動的閱讀者。

因此，這次讀書會，不只讀，還要先寫作業：回答我事前準備的一系列提問。



其五

如果讀的材料，與自己工作的連結薄弱（可能是客觀上來看真的很薄弱，也可能是主觀上誤以為很薄弱），就不易達到預期效果。

為了幫助大家主動建立這樣的連結，這次讀書會的前置作業，要求參加者，每個人都要先針對我設計過的一系列提問，思考每一則問題，並在共享空間上面作答。

Ground Rule 像這樣：

我會準備幾個提問，請大家這幾天，在工作時／工作之餘，針對我準備的幾個提問，找出在你經手的程式中，對應的具體實例，展示給大家看。

這樣比較具體，也比較能和每個人的工作，有最直接的連結。順便也給大家示範一場 code review…

這就叫做 *摸蛤仔兼洗褲* ...

提問加起來，大概要花兩個小時去彙整案例。需要一點點準備時間。請開始吧！

PS. 程式碼實例，請附上 Git URL，方便大家觀摩參考。


以 ORID 層面來說，提問多半屬於 O 及 I 的層面，像這樣：

在〈脆弱的測試案例〉一文，介紹五點測試案例的「光明面」(FIRST)，以及四點單元測試的「黑暗面」。請問，在你經手的專案中：
• 有哪一個例子，或是架構、流程設計環節，有呼應到 FIRST 光明面？請展示出來。
• 有哪一個例子，或是架構、流程設計環節，有碰到黑暗面？請展示出來。

至於 R 及 D 的層面，則多半在讀書會現場，以口頭提問、共同討論的方式進行。


如此設計，果然大大提升 it's show time 的品質。也讓眾人知道，原來隔壁同事的專案，有哪些好的經驗可以參考，有哪些困擾可以幫忙出點主意。

學習型組織，就是這樣子吧。



總結

這一段故事，是為了具體解釋這陣子我講的一堆狀似嘴砲的話：

收到一份履歷，他在某接案公司待了 N 年。
很可惜。在我眼中，這只值兩年呀。

對接案公司無不敬之意。但是，字裡行間，實在看不出反駁我『只有兩年的工作經驗，只不過重複了 N 年』認知錯誤的理由。

•

其實，每一個位子都有可能發光發熱，重點仍在於是否有自覺進行「換位思考」及「系統思考」。
有自覺，你的一年工作經驗，就有別人 N 年的價值；反之，你的 N 年工作經驗，就只有一年的價值。
--- Quote: 2016-08-20 Tweet

•

不是在大公司就一定學得深，不是在新創就一定學得廣。
重點仍在於自己。在於「自己有沒有系統思考及換位思考的自覺及行動」。
在於專業態度。

「專業技能」固然重要，但是，能夠讓自己從流水帳的制式履歷表欄位中脫穎而出的，終究是「專業態度」。 很準。只要針對每一份履歷表，個別客製化追問一兩次，幾乎就能分辨出哪些人有下意識追求「專業態度」的成長。
--- Quote: 〈專業態度的養成〉

•

許多事情，跟你身在大公司還是小公司是低度相關的。心智框架，是要靠自己主動觀察、取經、思考的。
--- Quote: 2016-08-15 Tweet


這一段故事，也是為了替以下這段自己努力的方向，留下一份紀錄：

最常最多思考的，總是環繞在流程、最小阻力、抵制變革九層次，以及我在 DevOps Summit 2016 兩場演講所提的激發方案，在多種應用情境下的衍生變化。
--- Quote: 2016-08-05 Tweet

這條路，自己也在不斷思考及實驗。共勉之。