VictorHsu - 作者系列文章
VictorHsu

曾經主修科學,也當過工程師寫過程式,其實最大的興趣卻是是寫文章說故事,目前在網際網路產業擔任PM工作。 自認只是職場上的小人物,但深知專案管理的知識應用廣泛,2011年取得PMP證照後,開啟對專案管理的學習之路,於是結合自身的經驗,以及大眾最熟悉的電影劇情,讓生活、理論與虛構的情節在專案管理的世界裡產生交集,期許能引領更多同好認識專案管理。

善用use case及流程圖匡列專案範疇

專案執行過程最為人詬病的問題,就是用戶或sponsor持續追加需求,導致範疇不斷變更、膨脹。變更的原因有很多,最常見的情況是專案初期PM就無法明確定義範疇,也沒有讓團隊成員、用戶及sponsor都充分理解專案執行的邊界在哪裡,當邊界模糊,對於新增的需求自然也缺乏約束力,無法排除在專案之外。在《專案管理知識體系指南》中,雖然有定義專案初始階段的任務,包含確認專案範疇、展開WBS...等,但如何有效界定範疇、用何種圖表來呈現,就需要靠PM自己想辦法。

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

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

想著常態WFH前,先打破工時紀錄的迷思吧!

防疫期間WFH(Work From Home,在家上班)成了一種趨勢,起初企業們是被動受疫情影響而不得不執行,但隨著WFH的期間拉長,有些企業開始評估常態性在家上班的可行性,例如Google、蘋果就力挺每週進辦公室三天成為主流工作型態。看到這些消息讓身在台灣的我們好生羨慕,但是,在常態居家工作之前,有多少企業還奉行工時記錄?

專案經理的基本苦工:繪製一份「實用」的甘特圖

甘特圖或許是多數PM最常製作的一張圖表,但是有多少人會在專案執行的過程中,持續透過這份資料追蹤、更新時程? 又或者有多少人能從當中看出潛在風險、並適時調整專案步伐呢?PM進行專案時程估算時,常常會犯以下幾個錯誤:

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

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

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

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

敏捷團隊的精實秘訣

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