老師，你會不會跟我一起罵老闆？

「老師，你剛剛教的東西對我們公司來說沒有用啦！我們老闆都嘛不聽我們說，都嘛直接壓結案日期，都沒得談的！你說，碰到這樣的老闆該怎麼辦啊？」

如何讓您組織的專案治理「如虎添翼」？

某天早上，一位管顧夥伴 Line 我：「老師，我們接到一個 case 了，想跟您保留 x 月 x 日的日期，不知道老師那天有空嗎？」我看了看行事曆，那天剛好有空檔，於是回覆她，「可以，那我就把那天保留給你們囉！」

「請問客戶端的主要痛點是什麼？」我接著問。

為什麼我們會需要專案溝通管理？

您可能會認為，一個專案規劃完成之後，接下來應該就是，每個人按表操課就行了，是吧？其實不一定！有些較為簡單的專案可能可以，然而，大多數的專案卻沒有這麼簡單！

《EZ敏捷式專案管理》入門一日班簡章（６或７Hrs）

《EZ專案力》專案管理實戰兩日班簡章

專案談判力：如何看清「局」、引導「勢」、掌握「節奏」

[承上篇]

「高天，看樣子你們是還沒有頭緒，對吧？」

「ㄜ，是還在調查啦！」高天不想承認我的說法，所以拐彎抹角地這樣小心回答我。

專案管理工具（排程、WBS、Gantt chart）

從簡易功能的 Excel 範本，到專業的排程軟體！

專案談判力：團隊搞不定，專案經理你該怎麼辦？

「安迪（化名），BTS（Bug Tracking System）上那個 xxxx 號系統隨機當機的 issue，到底處理得怎麼樣了？上次你們說廠商已經解了，結果 QA 驗證測試還是沒通過，問題根本就沒有被解決！從上次 issue 被 reopen 之後至今，都已經快兩週了還沒有任何進展，這樣下去不是辦法，會出不了貨的啊！」

「我也沒辦法啊！我已經催他們很多次了，他們就是這麼牛皮啊！」我想像，在電話那頭的安迪現在應該是兩手一攤的模樣…

一個被演講重新激活的「危機處理專案」記憶（３）

[承上篇]

上篇文末，我問到，為什麼小綠（Android）都已經在市場上翻天覆地好幾年了，這個時候才爆發這樣的事件呢？

原來，此時市場上開始出現雙核心 CPU（中央處理器）的行動裝置。許多的程式設計高手們開始摩拳擦掌、躍躍欲試，企圖將行動裝置的運算能量盡可能地、無限制地釋放出來，看看在行動裝置上的各種應用，尤其是影音、遊戲等需要高運算能力的應用，到底能有多流暢，是否可以達到部份桌上型電腦的效能體驗！

一個被演講重新激活的「危機處理專案」記憶（２）

[上一篇]

一切都是因為小綠！

一個被演講重新激活的「危機處理專案」記憶（１）

「威廉老師，我想邀請您來擔任我們７／１９晚上演講活動的講者，不知道您的意下如何？」

《其實你懂專案管理》系列文章總表

其實你懂專案管理（一）：專案的啟動與大總管（專案經理）的指派
其實你懂專案管理（二）：專案聖旨（專案章程）的頒布與利害關係人的辨識
其實你懂專案管理（三）：利害關係人的需求和溝通
其實你懂專案管理（四）：需求（Requirement）釐清與範疇（Scope）界定
其實你懂專案管理（五）：「交付標的（Deliverable）」導向來挖掘專案必要的產出
其實您懂專案管理（六）：用工作分解結構（WBS）來管理專案所有「交付標的」
其實你懂專案管理（七）：WBS、RAM、專案人力資源（Human Resource）管理
其實你懂專案管理（八）：品質（Quality）和等級
其實你懂專案管理（九）：風險（Risk）管理
其實你懂專案管理（十）：整合變更管理（Integration Change Mangement）與 WBS

敏捷方法的成功密技（十二之二）：Scrum 如何精準估算用戶故事的點數？

[承上篇]

敏捷方法的成功密技（十二之一）：Scrum 如何精準估算用戶故事的點數？

在上一篇文章《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》當中，我們談到了怎麼將點數／心力（Point、Effort）大小不一的各個用戶故事，依照用戶故事的優先級先後，排進衝刺（Sprint）內去實做。也談到了如何拆解肥大的用戶故事為數個小故事，以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿，以最佳化該衝刺的負載規劃。

可是，這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義！那麼，實務上，我們到底應該怎麼來估算用戶故事的點數，才能稱上「夠精準」呢？

敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？

在上一篇文章《敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？》當中，我們談到了衝刺（Sprint）目標，雖然名義上應該由 Product Owner（產品負責人）來制定，但為免團隊根本就不 buy-in，或是團隊實在是無力可達成，故，實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論，來制定各個衝刺的目標，這樣才像一個符合 Scrum 精神的「團隊」！

敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？

在上一篇文章《敏捷方法的成功密技（九）：Scrum 的衝刺目標怎麼訂？》當中，我們談完了衝刺（Sprint）目標的制定技巧，但是，這些衝刺目標，到底該由誰來制定呢？我們先來看一下這樣的一個場景…

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

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

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

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

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

[承上一篇]

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

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

在上一篇文章《敏捷方法的成功密技（六）：Scrum Master  並非你想像的那般卑賤！》中，我們談到了 Scrum Master 這個角色，其實最好是由一位開發和管理經驗豐富的人來擔任，工作經歷不足的菜鳥，是很難勝任得好，更很難以服眾的。