最近除了純技術的書之外，也開始看一些比較軟技能的書籍，這一本是最近看過最有感觸的一本書，一般談管理跟領導的書，很少會跟你說如果同事拒絕你的提議應該怎麼辦，講道理又講不通，很容易就變成惡性循環。
在開發上很有可能會有技術過時、不合時宜等等的情況發生，也就會有想要改變技術線、框架、部署方式的想法。
不過想要讓整個團隊接受你的想法往往需要很多考驗，也時常會有你花了很多熱情、心思與時間在「佈道」，結果團隊完全不理你，甚至認為你在忙什麼。
雖然技術不好用，bug 層出不窮，但至少還過得去大家也就不想改變了，久而久之你也變成了沒有熱情的工程師，每天寫爛扣得過且過就好。
這本書對那些拒絕改變的人歸納了幾個 pattern，雖然不是一讀完就可以馬上應用，但我覺得比起起來軟技能的書籍，這本書更真實，因為在職場上更容易遇到這樣的事情，而不是大家都能夠有效溝通。
說服別人接受自己的想法這樣的事情，不只在軟體開發領域上，在其他領域也會發生，只是在軟體開發上更加頻繁。想要將自己的想法傳遞給團隊知道，往往並不是先思考計畫再行動，而是自然而然就有的偏好或意見。
但是人們有許多類型，並不是所有人都對你的技術引入、汰舊換新樂見其成，你有可能很盡力地在做對整個團隊來說很棒的事，但不被其他人認同。
因此怎麼推廣才是重點，當你的熱情與改變逐漸傳播在整個團隊當中，也更容易讓其他團隊成員支持你，這本書提供了許多有效的做法和建議。
七大類型
這本書將拒絕改變的人分為七大類型：
-
The Uninformed：無知者。他們不知道相關的技術知識或話題
-
The Herd：從眾者。隨波逐流，沒有特定立場的人
-
The Cynic：宗教狂熱，書上用非常貼切的方式形容他
They're that kid in college who always asked your professors annoying questions to show how smart they are.
因為他們喜歡到處看技術，求廣不求深，所以會用奇怪的故事或經驗嚇唬你
-
The Burned：激進派。因為之前的失敗經驗而對某個技術、框架強烈抱持反對態度，所以他們寧願用現有的方案
-
The Time Crunched：沒時間。沒有時間學習新知識、技術。
-
The Boss：你的上司。他們會拒絕你的提案往往是因為他們不懂技術。
-
The Irrational：無理者。他們會想盡辦法拒絕你的提議，只要一個論點說不通就馬上換下一個，他們是以上類型的綜合體。 面對無理者最好的方式就是直接無視他。
前置作業：定義問題與解法
在引入新技術之前，最重要的是定義問題與解決方法，來確保你現在正在解決對的問題。例如你希望引入自動部署方案，但自動部署是否能夠解決現在的問題呢？或是因為頁面的狀態複雜，希望引入 SPA 的架構，但是否能夠有效解決狀態複雜這件事呢？
在引入技術之前，要先想清楚問題以及想要達到的目標，這不僅是否要引入新技術有好處，未來面對同事、上司們的質疑，他們可能也會有類似的想法。
你可能是錯的
每個人都有犯錯的時候，所以在面對質疑的時候不要覺得對方在阻饒你（至少剛開始的時候），而是他們或許都有各自的考量。我在剛引入自動部署的時候，也曾經向同事諮詢為什麼要將編譯過後的 hash 當作 git tag 標記？難道不能換成對應的版本號碼嗎？一問之下才發現那是過去追蹤 hash 的方法，也因此我也稍微修改了作法，讓整個自動部署可以自動記錄編譯過的 hash，也成功讓同事支持我的作法。
一些技巧
對於每個類型的人，本書都有提出一些技巧來應對。
變成專家（Gain Enterprise）
在引入一項技術、工具之前，要先確保自己對這門技術已經有足夠的理解，這樣才能應付別人的問題。光是大略看看文件跟 Q & A 是不夠的，至少要對這門技術要足夠的掌握。為了達到這件事，你可以：
- 找尋其他專家
- 教學
- 使用它（在自己的專案中）
實際行動
- 看完整份文件
- 在相關的技術論壇上看看人們是怎麼討論這門技術的，以及是否能夠回答他們的疑問
- 開始寫關於這門技術的部落格
宣傳（Deliver your message）
將你的方案推薦給其他人，同時不要將他們想成敵人，而是邀請他們一起參與。想要成功獲得對方的支持，有幾件事情很重要：
- Be a Person, Not a computer：人是有情緒的，指出對方現在的方案是錯誤的沒有辦法有效溝通，反而有害。比起直接跟對方說你是錯的，不如用這個工具、方法更有效率與產能。
- 熱情：你會想要引入新技術，是因為能夠讓整個作業變得更簡單、快速，而不該只是你用起來比較舒服而已。
- 用建議取代命令，像是：「你有考慮過xxx 嗎」
- 先聆聽：在團隊間或許也有一些成員採用過不同的方案，可以在行動之前先詢問他們的經驗。例如在引入 CI 的時候，就有發現大家曾經用過 CircleCI，但後來放棄了，詢問之下才發現如果利用公司內部的 CircleCI 伺服器需要申請權限。
實際行動
- 練習怎麼做 pitch
- 試著聆聽自己講了什麼，如果是別人你可以被說服嗎？
另外在這邊我想要補充，目前在日本工作，如果想要讓對方更加信服你的方案，說對方的語言會更有說服力，例如同樣的方案講成日文，就比英文來得更有說服力，因為對方更容易看得懂。
展示（Demostrate Your Technique）
比起講話與單純看文字，直接展示效果是最直接的方法，為此你可以做簡報、做 live coding、做個 POC 等等，都是很好的方式。
People believe what they are shown more than what they are told
那麼要怎麼找到時機呢？你可以自己找個空檔時間讓大家聚在一起，或是在 Code Review 上展示自己的解法。
提供折衷方案（Propose Compromise）
有時候尋找折衷方案是必要的，或許不能夠百分之百照著自己想要的方式進行，但至少可以找到一個權衡的方案。
建立信任（Create Trust）
這是在上述技巧當中比較難做到的事，因為建立信任這件事情並不好達成，並不是你做了 ABC 之後就可以得到信任。但這件事有很大的效益，一旦對方信任你，你就越容易推動技術上的改變。雖然沒有特定的方法建立信任，但有幾個原則可以參考：
- 不要說謊
- 勇於承認錯誤
面對面的討論
在網路上討論（非同步），往往會因為時間、環境的關係沒辦法清楚表達自己的意思，也會讓討論變得窒礙難行，久而久之雙方會因為溝通不良而喪失耐心或彼此的信任，這時候就可以考慮面對面溝通來解決問題。
一些策略
- 忽略無理者（The Irrational），因為跟無理者辯論往往是白費唇舌，他們只是想要阻饒你引入新技術而已。
- 專注在願意幫助你的人
- 適時尋求協助
- 幫助上司解決問題：上面有提到上司會拒絕你往往是因為他不懂技術，因此要用你的方案提高了多少生產力跟減少多少 bug 來談。
後記
之前在職場上也遇到類似的情形，熱情滿滿地與團隊們分享自己想要做的事情，結果對方也都興致缺缺，甚至質疑為什麼要為了這種事情忙了好幾個禮拜，那時候覺得相當沮喪。也有遇到類似無理者的同事，只深信自己的技術與做事方式等等，讓自己覺得很難融入整個團隊。
剛好前同事推薦這本書，短短的 100 多頁，大概一個禮拜的通勤時間就看完了，不過裡頭提的內容跟方法都很實用，非常推薦大家來讀讀看。
倒也不是一夕之間就有改變，或許在職場工作許久的工程師都已經知道怎麼應付這些情況也說不定。
不過工程師有時候會因為麻煩跟懶，所以就不去學習怎麼和人溝通，但殊不知在協作上人佔了很大的因素，如果想要未來的職涯更輕鬆一些，就不得不學習怎麼處理人的事情。
這並不是看完後就能夠馬上應用的教學書，畢竟如果要累積信用跟練習以上的建議，都需要不少時間，但如果用對方法，慢慢讓自己的熱情與責任感顯現出來，久而久之團隊也會跟著受到影響的。
