如何協助團隊改善開發體質，成功導入改善的工具或流程
前言
4 月 25 日參加了集英信誠每年都會舉辦的「與大師對談」技術論壇，會後也跟董大偉老師與 Ruddy 老師討論了一下，在團隊中要怎麼引導改變或敏捷開發的相關議題。
也剛好前幾天與好友 Clark 在 plurk 討論串上討論到如何有效影響團隊，如下：
Clark: 做架構不是程式能動照著做就好，還要考慮成員技能、後續維護、專業分工等等面向。
因此這篇文章就只是整理一下，自己在過去的工作經驗是怎麼導入一些流程、開發工法，讓團隊比較能無抗拒地接受或自己改變。
Leader 的思維
Clark 講得相當好：「架構設計還要考慮成員技能、後續維護。」
作一個 leader 最忌諱的就是自己很強，衝很前面，其他人太弱，都是他們的問題，是他們看不懂我的優良設計，是他們能力不夠，所以不能維護。Leader 的價值在於追尋中間的平衡點，既能滿足實務上最基本的擴充性跟可維護性，又能讓成員無痛無感的提昇自己的技能， adopt 這折衷的 solution 。然後一步一步往上拉，整個團隊的技能會慢慢地往上提升， solution 也會越來越進化。
最後讓團隊回頭去看自己前面寫的東西，自己都覺得彆扭，而且自己已經有能力跟自覺進行改善跟修正。
而這中間關鍵點就在成員技能，除非很好運，否則很常碰到其他成員的技能並不是這麼高超（應該說在架構或品質上沒這麼專精），這時候重點是怎麼拉他們一把，讓他們可以接受且樂意改變。並適時且有技巧地拋出一個最適當解（而非絕對的最佳解），最好這個適當解是團隊一起討論出來的，拿來解決現況的問題。
沒有絕對的對錯，最適當解就是當下最佳解
當 teammate 設計不良或無法接受建議時，要明白架構或作法就像 David 老師講的，沒有絕對的對錯。當需要與 teammate 溝通時，可以換個角度跟他說，例如提供一些真的可能會發生的 scenario ，也就是新的需求或可能的需求異動。然後讓他來比較，碰到這樣的情況，他的 code 可能會碰到什麼樣的問題，需要怎麼修改才能 fulfill 需求。
然後提供一個簡單好懂另外一種作法，讓他很簡單就可以懂，然後同樣的需求異動砸下去，會發現你提供一樣簡單好懂的作法，既能滿足原本的需求，也可以滿足新的需求。接著協助他 看他需要什麼幫助，如果他也覺得你提供的方式也可行，修改成本也不高，是不是可以著手進行一些小修改，達到雙贏。如果需要去跟上面溝通，跟其他 teammate 溝通，甚至需要一起 pair 設計，我們都可以協助他。
他的方式並沒有不好或錯，只是大家在交流跟討論過程中，發現有一樣簡單的作法，不會有太大 effort，但可以滿足比較多彈性的情境，都同意也都理解後，再一起來讓產品往那樣的設計方式前進。
如何讓團隊無感地改變
要無感的協助大家改善本質解決問題，其實需要不少時間醞釀就是。我自己的習慣是，你得先分頭了解兩件事：
- 目前的系統架構跟 domain 和需求。
- Teammate 的能力跟脾性。
只有這兩者兼備，才會比較容易知道， teammate 所設計的 solution 問題在哪， Leader 也才可以從需求跟 domain 切入來讓他理解。
而了解他們的個性跟脾性，才會知道他們需要的溝通方式是什麼，了解他們的能力，才會知道，怎麼解釋他們才比較好懂跟接受。
如果自己是團隊的新進成員，只要我還沒把握他們會直接接受我的見解，彼此也還沒有信任的 credit 基礎，我就只會用上述方式的建議，但我會尊重他們的 solution ，不會強迫他們一定要修改成我要的樣子。然後在我負責的範圍中，劃出防火線，讓他們的架構再爛，都會被我的防火線擋住，不會影響到我設計的部分。
接著找時間 retrospective 或部門 weekly meeting 分享一下自己的作法，為什麼自己會這樣做， effort 在哪，好處在哪。慢慢潛移默化跟建立自己專精領域的「權威感」，這個權威不是威勢，而是大家會主動信服你，請求你的建議。因為我只是 participate 這個團隊，只能 bottom up 的引導大家往比較好的設計前進。
團隊文化演進
我比大家好運的是，通常我的主管了解了兩種作法後，會當黑臉的 push 或鼓勵大家要往好的設計方向前進，再賦予我任務去協助大家改變。大家一開始雖會不太甘願，覺得麻煩之類的，但我們的角色就是讓他們可以安全、無痛的度過主管的要求，最好他們可以什麼都不需要改，什麼都不用學，又可以滿足老闆的要求，又可以提早下班。
等到，你先額外付出的心力，贏得幾個 teammate 的信任之後，這些 teammate 在這件事上，就會是你極大的助力，而且是見證過奇蹟的使用者，他們會主動幫你推廣，或是消除其他還沒改變的 teammate 疑慮。就像吃完撒尿牛丸，考試都得一百分一樣。
到那個時候，後面的 teammate 就可以遵循自然淘汰法則，不用你多費心，讓主管去 push 就好。這樣你才會有時間跟心力，再抽出身來，幫已經站你這邊的 teammate ，再協助他們往上拉一個層次。「三國兩國」法則，永遠讓自己在團隊中，先爭取到多數優勢，即使自己需要先「讓利」 。剩下的一國就會被自然淘汰或自然改變。屆時主管可以很有力的說：「大家都可以，為什麼你不行？」或是「大家都這樣做，為什麼你就跟別人不一樣？」
注意：但如果在自己還只是新進成員的時候，還沒有信任基礎的時候，貿然太多改變，那麼反而主管也一樣會跟你講上面那兩句話。
結論
簡單的歸納出下列幾點供大家參考：
- 要成功的改變團隊，一定要讓團隊無感。
- 要團隊改變的重點，不在於什麼流程、工具、工法或是新名詞，而是怎麼讓他們更早下班、更輕鬆工作、生產力更高、解決他們的問題，以及最好可以什麼都不用學和不用改變。
- 要 teammate 接受建議，一定要先瞭解他的問題在哪，要瞭解用什麼方式或說法是他能接受的方式。
- 要先建立信任基礎，包含老闆與 teammate 。
- 要先讓利、謙卑，讓大家知道你的核心優勢與能力，讓他們信服而不是折服，讓他們願意主動請求你的協助。
- 在團隊中要想辦法讓自己處於多數的那一群，否則阻力永遠大於助力。
- 不要只是想消滅反抗你的人，沒了他們，你也做不了這麼多事情。
導入的重點，不在於單向 push ，更不在於由上而下的 push （雖然上面的支持決定了成敗），而是怎麼引起團隊的主動性，讓他們自己想要改變，而我們只是多一點經驗、能力、責任去幫助他們的角色。
最後再強調一次，沒有銀彈，沒有絕對的方式，也沒有絕對的對錯，這一篇只是把我這幾年成功的導入經驗稍作整理提供給大家當參考，希望對大家有所幫助。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
