工程師的自我修煉

有些 PM 覺得跟工程師溝通很痛苦，甚至大腦會不時冒出這樣的想法：「明明只是修改一個小地方，為什麼總有各式各樣的理由拒絕跟拖延，就算答應修改，做起來也是一副心不甘情不願的樣子。」

「我們學了很多方法，但在實務上卻各種出包。」我想這應該是很多開發團隊的心裡話，儘管大家都能看見問題，也嘗試導入各種方法試圖解決；但很多時候別說進步，有時甚至還會走回頭路，筆者剛好透過這個主題整理團隊過往遇到的問題；不過解決方案是否有效、會不會衍生新的問題，就看之後的連載了😅

在過去的文章中有提到，為了提高團隊成員在 Scrum 的參與度，我們改成輪流擔任 Scrum Master 的機制，但這樣真的有效果嗎？而且 Scrum Master 跟 PM 的工作高度重疊，要如何區分兩者的權力與責任呢？

在流程不明確的狀態下，團隊成員只能憑藉自己的直覺做事；如果彼此對一件事的認知不同就容易造成誤會，甚至爆發不必要的衝突。

如果公司的專案很多，README.md 又沒有寫好，那後續接手的人會非常痛苦；如果公司專案的規模很大，README.md 又缺乏維護，那這個專案已經半隻腳踏進棺材。

隨著公司的擴張，會有越來越多人加入團隊來分擔你的工作 😊，此時你需要準備交接文件📄，以保證他們會成為團隊中的神隊友 😎 而不是讓你增加工作份量的豬隊友 🤕，這篇文章我會列出個人在交接時會準備的東西🧰。

在職場上，通常是一對多的場合會用到簡報（PPT）；一但用到它不外乎幾個情境：「談判、說服、解釋」，這篇文章不是叫你製作精美的簡報，而是從觀眾的角度去探討，怎樣的一個簡報能最清楚的傳達訊息。

有時我們覺得某個框架、套件很難用，常常寫到一半就卡住；除了可能是它本身設計的問題外，很多時候是因為沒仔細看官方文檔，導致我們拋棄好用的現成方案，選擇了一條孤獨難走的道路。