最近看的幾本書，都是有關於在職場上的軟技能，工程師其實有時候很懶得去做像是溝通、協調、合作之類的事情，除非你打算自由接案到退休，不然學會這些技巧能夠讓你在未來的職涯中過得更輕鬆一些。
這本「橫向領導」英文叫做 Getting It Done - How to lead when you're not in charge，就是在描述當你不是主管身份時，要怎麼帶領整個團隊運作，走到正確的方向。
這件事聽起來很玄，為什麼不是主管還要學習怎麼領導，但正因為不是主管，你才清楚這個專案、團隊運作的方式，因為你就是實作的那個人。
這本書大概用它書背寫的敘述就能概括整本書的內容：
- 參與式領導：提出問題 → 提供想法 → 行動表率
- 工作要素：制定目標 → 系統思考 → 計畫修正 → 激勵管理 → 尋求反饋
摘錄幾個我覺得蠻重要的地方。
工作出現瓶頸怎麼辦？
按照書上所說的步驟我覺得蠻清楚的：收集資料→分析可能的原因→選擇方法→行動計畫→開始行動→紀錄問題→分析原因→調整方法。
我們很難讓別人對他們的思考方式進行思考
提出指責與指正往往是讓事情變糟的開始，因為人們很難承認自己的錯誤，尤其是當彼此職位、地位相等的時候，「你不應該這樣做，…」這種話只會讓對方認為你在針鋒相對，反而讓事情變得更棘手。
在這種情況下，用幾個方式可以突破：
- 用提問的方式，例如：這樣感覺會不會有 xxx 的問題
- 要求佐證與協助：要求對方提出佐證，例如：「你剛剛說這個月的活躍使用者用戶減少了，你有相關資料給我看嗎？」
- 提出假設，讓對方回答你的問題。「如果這樣做，有什麼不好？」
這幾個方式看似平凡，但比直接指責對方來得有效率多了，也可以讓對方知道你並不是在針對他而是這件事。雖然你就是在針對他
把問題記錄起來
我曾經在公司裡頭遇到一個問題，要更新靜態 asset 的時候，雖然照著文件上的只是上傳，卻發現沒辦法成功更新，這件事情花了我兩個禮拜的時間，才知道原來 iOS 與 Android 的設定方式不同，也會因為權限不同的問題導致某些更新沒辦法顯示。
像這類的事情就很值得記錄下來，放在公司的共享檔案中，以防下次有同樣的人踩雷，雖然不容易被記住，但至少你解決了自己和別人的問題。
不要發號施令
跟別人提供建議的時候，一定要說清楚，你並不是在向他們發號施令，而是提供建議讓他們做選擇。沒有人喜歡被批評，被說教，當你有什麼想法的時候，不能用命令口吻，而是要透過各種方式傳達你的想法，可以是社內分享會、部落格文章、文件等等，進而把具體計畫描述給同事們聽，跟大家一起討論。
尤其討論這件事情，重要的不是討論本身，而是有沒有發起討論這件事。
反省
在 scrum 當中有個會議叫做 retrospective 會議，這個會議是讓大家提出這個 sprint 當中有哪些做得好與不好的地方。但這東西其實很容易變成討拍與批鬥大會，大家一股勁兒寫出要改善的地方，最後還是一樣什麼都沒有改變。
這是一件非常糟糕的事，因為如果多次都沒有改變的話，就會傾向把所有的不滿直接放在心裡，工作越做越不開心。
定義目標
如果不知道公司或是產品的目標是什麼，也很容易在同事之間引起衝突，例如對方希望產品快點交付上線；但你卻想好好重構解 bug，雙方對產品的認知不一樣的話，很快就會陷入混亂，對方的程式碼寫得亂七八糟，而你又害怕拖累 deadline 不敢要求對方重寫。
要解決這個問題，最快的方法就是定義目標，如果目標是在短期內將新功能上線的話，那麼就要在程式碼品質與開發時間之間作抉擇。
小結
我覺得如果是真的有在好好思考自己的職涯，或是有認真在思考工作上面的事情，上述這些事應該或多或少都成為習慣了吧，對比較有經驗的工作者來說算是複習以及比較系統性整理了平常大家都會做的事。
不過現實與理想總是有差距，就算你努力做好上述的事，還是有可能有針鋒相對、堅持己見、一意孤行的豬隊友出現，這時候就相當推薦大家「Driving Technical Change」這本書，他把豬隊友分成幾個類型，並且教你遇到每個類型的豬隊友應該怎麼應付。
