「安迪（化名），BTS（Bug Tracking System）上那個 xxxx 號系統隨機當機的 issue，到底處理得怎麼樣了？上次你們說廠商已經解了，結果 QA 驗證測試還是沒通過，問題根本就沒有被解決！從上次 issue 被 reopen 之後至今，都已經快兩週了還沒有任何進展，這樣下去不是辦法，會出不了貨的啊！」
「我也沒辦法啊！我已經催他們很多次了，他們就是這麼牛皮啊！」我想像，在電話那頭的安迪現在應該是兩手一攤的模樣…
一個被演講重新激活的「危機處理專案」記憶（３）
上篇文末，我問到，為什麼小綠（Android）都已經在市場上翻天覆地好幾年了，這個時候才爆發這樣的事件呢？
原來，此時市場上開始出現雙核心 CPU（中央處理器）的行動裝置。許多的程式設計高手們開始摩拳擦掌、躍躍欲試，企圖將行動裝置的運算能量盡可能地、無限制地釋放出來，看看在行動裝置上的各種應用，尤其是影音、遊戲等需要高運算能力的應用，到底能有多流暢，是否可以達到部份桌上型電腦的效能體驗！
原來，此時市場上開始出現雙核心 CPU（中央處理器）的行動裝置。許多的程式設計高手們開始摩拳擦掌、躍躍欲試，企圖將行動裝置的運算能量盡可能地、無限制地釋放出來，看看在行動裝置上的各種應用，尤其是影音、遊戲等需要高運算能力的應用，到底能有多流暢，是否可以達到部份桌上型電腦的效能體驗！
從課程邀約解剖組織主管領導力與當責力
「喂～請問是威廉老師嗎？」
「我是，請問您是？」
「我是XX院XX所的朱小姐，我們想邀請您來幫我們的助教上一個講座課程，不知道威廉老師您X月X日上午10點到12點的時間有沒有空？」
我的心裡此時浮現這樣的 OS，「現在是什麼情況！？連講座的內容是什麼都還沒有談，我都還不清楚我有沒有能力講授呢，就沒頭沒腦地要預約我的時間？」
《其實你懂專案管理》系列文章總表
其實你懂專案管理（一）：專案的啟動與大總管（專案經理）的指派
其實你懂專案管理（二）：專案聖旨（專案章程）的頒布與利害關係人的辨識
其實你懂專案管理（三）：利害關係人的需求和溝通
其實你懂專案管理（四）：需求（Requirement）釐清與範疇（Scope）界定
其實你懂專案管理（五）：「交付標的（Deliverable）」導向來挖掘專案必要的產出
其實您懂專案管理（六）：用工作分解結構（WBS）來管理專案所有「交付標的」
其實你懂專案管理（七）：WBS、RAM、專案人力資源（Human Resource）管理
其實你懂專案管理（八）：品質（Quality）和等級
其實你懂專案管理（九）：風險（Risk）管理
其實你懂專案管理（十）：整合變更管理（Integration Change Mangement）與 WBS
敏捷方法的成功密技（十二之一）：Scrum 如何精準估算用戶故事的點數？
在上一篇文章《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》當中，我們談到了怎麼將點數／心力（Point、Effort）大小不一的各個用戶故事，依照用戶故事的優先級先後，排進衝刺（Sprint）內去實做。也談到了如何拆解肥大的用戶故事為數個小故事，以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿，以最佳化該衝刺的負載規劃。
可是，這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義！那麼，實務上，我們到底應該怎麼來估算用戶故事的點數，才能稱上「夠精準」呢？
敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？
在上一篇文章《敏捷方法的成功密技（十）：Scrum 的衝刺目標誰決定？》當中，我們談到了衝刺（Sprint）目標，雖然名義上應該由 Product Owner（產品負責人）來制定，但為免團隊根本就不
buy-in，或是團隊實在是無力可達成，故，實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論，來制定各個衝刺的目標，這樣才像一個符合
Scrum 精神的「團隊」！
《EZ專案力》資通產品國際品牌大廠七小時企業內訓（推薦度 97%，滿意度 94 分）
這天，是個週日，也是個傾盆大雨的週日。一個本該悠閒在家，陪伴家人的日子，可是，卻因為某些因素，導致這個客戶，不得不把此次的《EZ專案力》課程安排在週日！假如我是這些被指定來上課的學員，心情也一定無法好到哪兒去…
訂閱：
文章 (Atom)