專案問題多又多 - 預估從來都不準，到底要估什麼

過去在學習專案管理相關課程時，曾聽過一個統計數字 :「專案的失敗率高達百分之八十」，而我自己的工作經驗讓我更篤定的事實是:「幾乎沒有任何一個專案的時程估算是準確的」。既然事前的估算如此不準確，專案的失敗率如此高，為何我們還需要學習專案管理？還需要大費周章預估成本、預估資源、預估時間？

從專案經理專職成產品經理時，必備的四個工作認知

之前幾篇文章可能有寫到，我在 2020 年初在原公司內轉，從線上課程內容製作的專案經理（Project Manager）轉職成為產品經理（Product Manager）。如今內轉已滿一年，加上同時碰到一些組織與營運上的變動，覺得這時間點正好可以來記錄自己接任產品經理後，做了哪些事情、達到什麼效果。

【菜鳥主管成長日記】如何帶團隊高效開會？3招讓開會更有影響力！

最近和朋友 K 聊到工作上的煩惱，他大概在一年前被晉升為組長，負責一個 6 人的小團隊，可是時至今日，還是有件事情一直困擾著他，那就是「和下屬開會」，尤其是他指定團隊開的一些會議，除了會議效果不如預期外，甚至還引起團隊成員私下的抱怨：大家覺得會議太多，又沒有用，所以參會都不積極。

敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？

綜合本系列之前的文章，Scrum 其實就是一個小團隊（約5-9人），利用一個個固定短週期的衝刺（Sprint），跟客戶一同逐步漸進地，完成一個產品，而這個產品的功能，就是由一個個，由客戶主導、撰寫的用戶故事（User Story）來呈現需求的（關於用戶故事的簡要陳述，有興趣的朋友可以先參考一下《能讓需求簡化，還能更省時、更省錢，提供更多價值》這篇短文，容日後有空再專文細述之）。

敏捷方法的成功密技（八）：Scrum 的衝刺時間長短怎麼訂？

一個衝刺（Sprint）的時間長短到底應該是多少才是最好的呢？如果衝刺的時間設定得太長，那麼，應變的彈性就會變得比較小，而如果衝刺的時間設定得太短，那麼，又容易讓開發團隊能產出的成果出問題。怎麼說呢？

敏捷方法的成功密技（七之二）：Scrum 的夢幻開發團隊該怎麼來建置？

接續上一篇文章《敏捷方法的成功密技（七之一）》，除了新領域、新團隊，最有機會嚐試新作法之外，我們也談到了，只要開發團隊夠紮實，產品的開發就能夠打帶跑，因為品質才能夠被掌控得好。怎麼說呢？  

從PM的角度淺談test case的應用

在PMBOK（註1）的定義裡，完整的品質管理計畫包含「品質保證」（Quality Assurance, QA，中文簡稱「品保」）與「品質管制」（Quality Control, QC，中文簡稱「品管」）兩個面向，其中，品保的目的是確保產品交付的品質，例如軟體開發專案中，交付的軟體是否能符合規格文件內所定義的功能。在編制完整的組織內，也可能會有QA這樣的角色（Quality Assurance engineer，即品質保證工程師），協助PM檢驗產品品質。