系統思考及換位思考,一例
其一
過去這一年,我針對 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 / 如何提升軟體的可測試性:
- Quality Attribute Scenarios(11):Testability
- 如何提升軟體的可測試性(一)
- 如何提升軟體的可測試性(二)
- 如何提升軟體的可測試性(三)
- 如何提升軟體的可測試性(四)
- 可測性模式(上)
- 可測性模式(下)
- 脆弱的測試案例
Part II / 五種 Test Double 技巧:
- Test Double(1):什麼是測試替身?
- Test Double(2):五種替身簡介
- Test Double(3):Dummy Object
- Test Double(4):Test Stub
- Test Double(5):Test Spy
- Test Double(6):Fake Object
- Test Double(7):Mock Object
我著重在鞏固 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
這條路,自己也在不斷思考及實驗。共勉之。