其一

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

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

其實不然。站在 monitoring 這個制高點,幫助我更深刻體會 lean thinkingTOC 都很注重的 “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

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