敏捷方法的成功密技（五）：Scrum 的三種角色

在上一篇文章《敏捷方法的成功密技（四）：Scrum的理想與現實的障礙》中，我們談到了Scrum明確定義的三種角色，Product Owner產品負責人、Scrum Master 大師，以及Development Team開發團隊，接下來我們就一一來看看。

《BCG問題解決力》選摘：深挖問題，找到兼具可解性與影響力的Sweet Spot

雖然對問題追根究柢很重要，但在實戰中，並不是挖得愈深愈好，而是必須找到一個 Sweet Spot（甜蜜點），也就是─這個有待解決的問題，需要有足夠的影響力（impact），而且也是你能夠解決的。舉個簡單的例子：假設你的好朋友發燒了，你該怎麼解決他的問題？

敏捷方法的成功密技（四）：Scrum 的理想與現實的障礙

在上一篇文章《敏捷方法的成功密技（三）：Scrum如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？》中，我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題，則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。除了流程架構這個「外功」，還有一個更為重要的「內功」，那就是團隊成員的組成。

如何繪製「專案工作時程表」？

製作時程表對於專案管理而言，可以說是一項基本但又容易犯錯的工作。何以說容易犯錯? 因為和風險管理一樣，隨著時間推移，工作時程、任務之間的關聯也會有所變化，如果沒有經常檢視、校正，就無法有效掌控潛在的問題。今天就以前陣子才剛結束的奧運會為主題，將「舉辦羽球競賽」作為專案任務來簡單說明。

敏捷方法的成功密技（三）：Scrum 如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？

在上一篇文章《敏捷方法的成功密技（二）：專案管理的「溝通斷層」》中，我們談到了為什麼客戶／用戶的需求總是這麼難捉摸，為何我們要先談這個問題呢？理由其實很簡單，在這個溝通的鴻溝沒有被妥善處理、弭平之前，所有後續的努力與投入都會事倍功半，形成「產品客戶不愛，團隊熱情不再」這個賠了夫人又折兵的窘境。那該怎麼做才能「盡可能」地弭平這個溝通鴻溝呢？

專案人力管理三部曲

「團隊凝聚力」這種東西雖然無法被量化，也無法具體描述它能帶給專案什麼實質的成果，不過多數人應該都會同意，團隊互助及向心力，絕對是一個高績效專案背後不可或缺的支撐力量，當團隊內部運作不協調時，即使成員的工作能力再怎麼強大，做起事來也綁手綁腳。

別讓專案吹破了牛皮！如何及早避免專案中的潛藏危機？

有些時候專案失敗並非刻意隱藏事實導致問題爆發，而是當下的時空背景會讓人忽略了一些星星之火，倘若專案正巧處在一個危險平衡的狀態下，那麼任何一點點失誤可能就產生牽一髮動全身的影響。不過，專案執行的過程中，確實有些舉動可以避免日後出現重大問題。