怎麼讓工程師們願意學習？

這是我覺得很重要的問題，因為我覺得太多人選擇蹲在自己的舒適圈了，還有太多人擠進了相對穩定的公司，每天就是日復一日，年復一年的做重複的事，變成了 IT 業界的公務員。當新創事業的工程師是拿命在拼，那些穩定的公司的工程師卻是佔好了位置，準備養老。

我覺得這很糟糕，當我們在抱怨台灣低薪、不尊重專業、不懂軟體的時候，我們的軟體工程師又拿出了什麼態度、什麼專業來交換呢？

Ruddy 老師在 agile tour 2016 的 talk，說，把故事說好，讓 developer 們感到好奇，然後去面對那些很煩的事情，然後反覆的做 retro。再補上 soft skill 的十步學習法。

還有，每次遇到 Daniel 的分享，我也都會問這個問題。Daniel 大概的回答是，學習是在一次又一次被羞辱的過程中發生的，所以要“不要臉”。可能偶爾他會提到 T 型人、兀型人甚至是梳型人。我覺得這超有道理。在現在這種一直在變的社會裡，還想靠一種專長、一種語言就想混飯吃到退休的，應該是不存在了的。

然後前幾天有機會遇到微軟負責全球導入敏捷的長官，有跟他聊了一下，我也拿這個問題請教他，感覺他有想了一下，然後說，應該要先從尊重 developer 開始，試著理解 developer 的難度，不要再去壓他 schedule，不要再逼他做不合理的事情，然後因為他是人，他應該也會開始學著進步。

所以又回到了雞生蛋蛋生雞的問題了，到底誰先？ 是 PM 或管理者們要先尊重 developer 們，還是 developer 要先 show, don’t tell？是某個人先引發出 developer 的好奇心，還是 developer 自己先去找個東西來用十步學習法學一學？

這...我好像也說不清楚...(或許畫個 CLD 來分析…?)

但我想到了三件事：
1. Steve Jobs 的訪問
提到了 Teamwork is depending on trust.

2. Dr. Suess 的 Bee Watcher

這故事是呂毅老師上課時講的，大意是說，修道士在討論他們怎麼知道蜜蜂有沒有在努力工作，於是他們決定推派一個修道士去盯著蜜蜂，看蜜蜂有沒有努力工作；那我們怎麼知道這個修道士有沒有努力地盯著蜜蜂呢？於是再派另一個修道士去看著這個修道士；那我們怎麼知道這個修道士有沒有努力盯著那個修道士盯著蜜蜂呢？...

是一個你會覺得，他媽的，有完沒完的故事... XD

3. 之前在臉書上看到的博弈理論。

我們要更相信對方，要進行反反覆覆的溝通，讓誤解降低。我們在面對問題時，我們的選擇決定了最後的結果。

當然，好奇心是正確的，不要臉是正確的，梳型人是正確的，尊重 developer 也是正確的。

但是假如我自己來回答這個問題，我的答案會是：

信任

不只是工程師。信任，會讓每個人願意學習，也就成長了。

敏捷不就是不斷學習嗎～ ㄎㄎ