如何當一個技術 PM？從工程師角度來看 PM 需要具備的能力

Arihant Kumar Jain 是一位印度資深後端工程師，這篇文章摘要他在《An Ideal Technical Product Manager, Extract from an Engineer’s Diary》對於技術 PM (Technical Product Manager，簡稱TPM) 的建議。「我們往往不會珍惜好的人或產出，直到體會到賽的。」這句話是我出社會後幾年的心得。遇到神隊友不但可以把事情做得又快又好、甚至還可以偷學幾招 ; 遇到雷隊友不但把事情做得又慢又鳥，甚至還可能被拖下水。

什麼樣的專案適合使用敏捷式專案管理？

前陣子有位學員來電，「老師，我是以前上過您敏捷式專案管理課程的學員，我在您的網站上有看到，您有在輔導企業導入敏捷式專案管理，我想邀請您到我們公司，輔導我們用 Scrum 敏捷方法來做專案...」對方向我介紹完他們公司後我才知道，原來他是這家新創軟體公司的共同創辦人。「請問一下，你們目前在專案管理上是有遇到什麼樣的痛點？為什麼會想用 Scrum 敏捷式方法來管理你們的專案呢？」我接著這樣提問。

讓大腦重新開機：在這 4 種焦慮超載困境下，我的心智重啟策略

當我們的電腦使用久了遇到問題時，有時僅需重啟即可解決。同樣地，我們的大腦和自身行為模式也可能需要類似的「重新開機」。雖然大多數人（包括我自己）無法徹底重置自己的生活或環境，但通過一些簡單的方法來讓大腦或某些負面習慣重啟，可以是重新獲得動力、恢復生產力，以及打破惡性循環的有效途徑。

導入敏捷方法，就可以不用寫文件！？

「老師，我們的供應商說，他們已經改用敏捷方法來開發我們的產品了，而且現在是在做 Prototype，所以不需要、也沒有文件可以給我們了，跟他們說這些文件是最後結案一定要的，他們還是不交，這樣對嗎？我該怎麼辦？」這是一位學員在我敏捷課程結束後的提問，這個問題其實可以分為兩個層面，一個是供應商的這種說法到底正不正確？另外一個則是更為深層的問題，為何這家供應商膽敢用這樣的態度來頂撞客戶？我們就先來談談「文件」這檔事好了。

化解職場上的對立，你需要掌握「敘事」的能力：先塑造「虛擬大魔王」，再與對方「協力打怪」！

溝通和表達常是許多上班族希望提升的能力，畢竟在職場上，說話技巧、表達能力好的人，往往相對容易獲得資源。不過講到溝通與表達，多數人想到的無非是鍛鍊口才、說話結構，或部分人會琢磨「聲音表情」，但反而比較少人留意到一個可能更重要的面向，那就是「敘事」。所謂「敘事」，指的是你怎麼陳述這件事情，尤其是搭建話語背後的情境。

不滿主管沒關係，但「消極抵抗」卻是最笨的方式

在這篇文章中，我要回覆一位朋友來信提出的問題。因為信件內容蠻長的，所以首先，我快速做個統整。這位朋友服務於醫院內某個專業單位，這個單位本來是獨立作業，並由他來領導單位業務，但某天醫院高層突然安排其他單位的主管「空降」，直接管理他們這個單位，以及另一個同樣被整合的單位。在他看來，新上司不僅對他們原本的業務強加干涉，甚至也沒做什麼實事，但為了凸顯自己，對外老愛獨攬功勞。

《時間管理的 30 道難題》讀後心得與作者專訪的重點整理

我覺得《時間管理的 30 道難題》這本書裡面，就像提供了一個「時間管理的百寶箱」，讓每個人都能找到適合自己使用的方式。背後的最主要原因，就是因為作者 Esor 提供了很多他「實際用過」、非常實用且貼近人性的小技巧。Esor 把他花費多年累積的實戰經驗與智慧總結，透過他平常在部落格分享時那種「平易近人」的口吻，不藏私地全部分享出來。