結果不是重點？

Dec. 08 21:24~22:53

 

如果Teddy沒記錯，Poppendieck夫婦是最早在軟體領域引入精實開發的人，2003年他們出版了成名作《Lean Software Development: An Agile Toolkit》，把精實開發視為敏捷開發工具之一。2010年Poppendieck夫婦出版了《Leading Lean Software Development: Results Are Not The Point》這本書，當時讀完這本書之後，Teddy對於這本書的副標題「Results Are Not The Point」一直百思不解。可能是漏掉什麼重點，為什麼這本書要說「結果不是重點呢」？

上周末上完某公司「Kanban方法與精實開發實作班」企業內訓，因為上課學員太認真，上完課後Teddy體力盡失，今天就學「圓仔」留在家裡吃飯、睡覺、休息。沒什麼精神寫東西，剛好才上完看板和精實開發的課，想說把Poppendieck夫婦的書拿出來再讀一讀，突然好像有一點點理解「結果不是重點」的含意。

***

書中提到，在知識工作中（軟體開發屬於這一類的），成功來自於人和他們工作的系統，結果不並是重點。培養人和改進系統，讓他們有能力可以獲得成功，才是重點。硬坳（超頻）一個系統以求取成果，在短期間或許有效，但長期而言會讓情況變得更差。所以改善的方向應該朝向「培養產生結果的系統和人，而不是強迫系統達成超過當前能力的目標。」

以Toyota「自願自學（voluntary self-study）」的活動為例，老師並不會幫助與指導團隊，而是請團隊先說明他們他們已經思考過的內容，然後給團隊提出進一步的挑戰與尖銳的問題，讓團隊有動力可以持續改進自己的思維。最後，團隊獲得新的想法、實驗他們的想法、收集實驗結果、實踐有效的策略。結果並不會被記錄下來已證明本次學習是有用的，因為重點是參與者學到了東西，而不是他們本次活動的產出結果。團隊成員將帶著改善後的解決問題能力回到工作崗位。

***

在《顧問成功的秘訣》這本書提到，顧問成功最差的作法，就是由顧問直接幫客戶解決問題。Teddy覺得很有道理，所以幾乎不會自己動手直接解決客戶的問題，針對客戶的提問也儘量不立刻提供「參考答案」，更沒有所謂的標準答案，而是希望先用「問答」的形式來引導客戶自己尋找解決問題的能力。但在台灣這種模式真的不容易，工程師都希望你直接不要廢話，立刻告訴他標準答案，很可能是因為大家都認為「Results Are The Point—結果才是重點，至於自己解決問題的能力有沒有提升並不重要，反正有人可以問啊（而且也看不到、模不著）。

有時候，不是員工有這種想法，主管也可能有這種想法，希望學習的過程可以看到「原本問題被解決的程度」來判定此次學習的成果，而可能忽略了員工與整個系統的「容量（解決問題的能力）」是否已被改進。

四年前讀到這段沒什麼特別的感覺，就只是 朕知道了「看過去」而已，過了四年再回頭才有多一層的體悟。

***

友藏內心獨白：所以說學習的歷程是之字形前進。