從東京奧運停辦與否，探討專案的風險決策

在工作上，專案多少都遇過進退兩難的窘境，可能是產品發表日將近，開發方面卻遇到龐大的阻礙 ; 也可能是產品的先期實驗結果不符預期，已投入的研發作業面臨繼續或中斷的決策。這些問題就好比2020東京奧運，先是因為新冠肺炎疫情嚴峻而延期至2021年，但直至2021年5月，日本的疫情並沒有趨緩的狀態，奧運能否順利舉辦仍是未知數，這對於主辦單位而言是一個莫大的考驗。

職場筆記、會議記錄、反省日記如何避免寫過就忘？

「避免寫過就忘」，正向目的就是：「希望自己寫下來的東西，在需要這個資料時可以有效地拿出來使用，並且看得懂自己寫下來的筆記、用得上自己寫下來的筆記。」從正向目的來看，我們需要完成兩個具體成果：1.「如何整理？如何找？」才能在需要的時候，記得並找得到自己寫過的筆記。2.「如何寫？」才能要用的時候，看得懂、用得上自己寫下來的內容。

產品PM必懂！「流程圖」的畫法及變形應用

一個產品從發想到形成規格，勢必經過一段演進的過程。嚴謹一點來說，應該會有User Story、 Functional Map、Flow Chart、Wireframe、Prototype ...等產出，最後彙整成一份完整的產品規格書，而本篇文章將依據我過去的工作經驗，以及收集各方資訊後，分享一些製作Flow Chart ( 流程圖 ) 的心得。

敏捷團隊的精實秘訣

近年來許多軟體開發相關企業導入敏捷管理，期望可以提升開發效率，事實上敏捷團隊之所以敏捷的主要原因來自於精實的運作 — 包含組織結構與需求範疇。後者可透過MVP ( Minimum Viable Product ) 的概念實踐，意思是將產品或功能切分至最小可執行的單位，開發完成後立刻放到市場上測試是否可行，並且反覆驗證調整。由於專案範疇變小，自然有機會縮短完成時間，展現出敏捷的結果。

要培養「會思考」的團隊，主管千萬別做這件事

曾經有位經理問我：「我的團隊都沒有創意，我怎麼讓他們多想想不同的解決辦法？」我建議他讓我參加他的團隊會議，在會議中，我觀察了十分鐘，我就知道答案了，究竟我發現了什麼？我發現張經理是一位認真負責講究效率的主管，員工只要問問題，他就立刻給答案。所以我觀察的十分鐘內，團隊一共提了六個問題，張經理也都依序立刻給了答案。看起來張經理很享受不斷給團隊答案的成就感，而團隊也很習慣直接帶問題來得到張經理的答案......

工作愈忙愈要「離開前歸位」， 4 個小步驟幫助未來的自己減少拖延

我們其實很習慣，當要離開目前工作時，保持目前做到一半的狀態就離開，因為我們想說下次打開應該可以直接進入工作吧？或是當下真的很忙，因此想要省下這兩三分鐘的離開前整理時間？但我們沒想到的是，常常一次不會只進來一個工作，這樣累積下來，於是很多個工作都打開在做到一半的狀態，結果就是愈來愈混亂。

如何合理預估專案任務工期？

新手或是被指派陌生案子的PM在專案規畫時，很常碰到的問題是不知道要為任務設定多長工期。一來可能是沒經歷過、二來或許也因為複雜度的關係，不知該如何下手。可以參考以下做法: