pexels-martin-lopez-1117132.jpg 前幾年有部名為「一屍到底」的日本電影,使用「一鏡到底」及「戲中戲」的拍攝手法,由於成功營造前後劇情的反差效果,加上演出逗趣,因此瞬間爆紅,在全球創下3000萬美元票房佳績,成為小成本電影的成功典範,甚至被譽為「神片」。最近拜讀該部電影相關的書籍,發現它的成功並非偶然,雖然投入的資源、成本極少,拍攝時間亦不長(僅有八天),但不論事前的企劃準備、臨場應變等,都極需要良好的管理與團隊合作,絕對可以做為專案管理的學習教材。

低成本管理

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

如期如質是專案的唯一目標,但多數都達不到這樣的境界,那麼,執行專案管理對我們有什麼幫助? 或許從以下的角度切入,能讓被專案dead line追著跑的你釋懷一點...

1.減少過程中的慌亂感,讓自己多一點時間做事,而不是到處救火或時時刻刻開會。同時也可以塑造臨危不亂、先知的專業形象。

victor 發表在 痞客邦 留言(0) 人氣()

專案執行過程最為人詬病的問題,就是用戶或sponsor持續追加需求,導致範疇不斷變更、膨脹。變更的原因有很多,最常見的情況是專案初期PM就無法明確定義範疇,也沒有讓團隊成員、用戶及sponsor都充分理解專案執行的邊界在哪裡,當邊界模糊,對於新增的需求自然也缺乏約束力,無法排除在專案之外。

在《專案管理知識體系指南》(PMBOK® Guide, A Guide to the Project Management Body of Knowledge)中,雖然有定義專案初始階段的任務,包含確認專案範疇、展開WBS...等,但如何有效界定範疇、用何種圖表來呈現,就需要靠PM自己想辦法。為了讓團隊成員及相關利害關係人都能理解專案範疇,我自己習慣使用UML中的Use Case Diagram加上流程圖的形式來輔助說明。UML是一種軟體開發的統一塑模語言(Unified Modeling Language),用來為即將開發的系統進行塑模分析,簡單來說,就是在開發前建立一個模型概念,以統一的圖文規則來表述系統架構、功能等。而Use Case Diagram是其中一種圖形工具,從高層次的角度辨識系統所應提供的功能,在圖形的繪製上,通常會有Actor(通常為某個角色,例如系統的使用者)、Use Case(使用案例,或可想像為操作行為、或者執行的功能),以及兩者之間的關聯,其中Actor和Use Case之間常為一對多關係。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

主公.jfif

在過去,領導者多半擁有強烈的性格,以及類似東方傳統父權的權威感,但隨著資訊發達、社會氛圍轉變,新世代的領導者也逐漸發展出不同的風格,其中一種類型會謙虛地廣納意見,不以自我為中心,偶而甚至會暴露自己的缺點,尋求部屬協助,我們稱之為懂得「示弱」的領導者。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

在日常工作中,尤其跨團隊協作時,難免會遇到已經談定的事情破局,或者本該對方處理的任務卻被甩鍋(註1),這時候內心鐵定很想用力問候對方。不過,最近看到一些有趣的論點,原來經常性的「甩鍋」其實是一種認知失調,之後只要遇到被甩鍋的鳥事,內心想著「這個人勢必失調得十分嚴重」,心裡就著實舒坦了許多,還不由得替他感到辛酸呢。

根據腦成像的相關研究顯示, 人類在意識到自己做錯事情的時候,腦袋內的某個區塊就會啟用,而且這個區塊和生理疼痛的腦區是相同的,當這種類似疼痛的感覺過度強烈時,大腦就會啟動保護機制。身體碰到疼痛和恐懼時的反制行為是逃避,因此當大腦過度刺激時,將眼前所遭遇的責任推卸掉,就是大腦認為最簡單有效的方法。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

製作時程表對於專案管理而言,可以說是一項基本但又容易犯錯的工作。何以說容易犯錯? 因為和風險管理一樣,隨著時間推移,工作時程、任務之間的關聯也會有所變化,如果沒有經常檢視、校正,就無法有效掌控潛在的問題。

今天就以前陣子才剛結束的奧運會為主題,將「舉辦羽球競賽」作為專案任務來簡單說明。製作時程表的方式很多,例如專業的Microsoft Project、免費的GanttProject軟體,或者使用Excel自己建立,只要能充分表達專案任務的時程規劃即可。我個人使用的簡易時程表如下圖,最左方欄位為負責人,橫向以時間軸表示,可以依據專案的規模、預計掌控的程度來決定每一格時間單位(天、周、月),不同的色塊則是表示不同的工作任務,並且在最右側欄位顯示目前進度(也可以在任務色塊下方用其他顏色依完成比例標示進度)

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

pexels-photo-6801648.jpeg

2021年5月,台灣新冠肺炎確診數激增並進入3級警戒,同時也爆發疫苗不足的問題,至同年6月底,全球防疫排名(註1)更從最優的第5名一路滑落到44名,被笑稱是防疫吹牛,讓台灣在國際間顏面盡失,國人也一度陷入恐慌,在擔心疫情加劇封城的心理壓力下引發搶購潮。疫情爆發的原因有很多,我們無需過度批判,但從「吹牛」這個不名譽的稱號卻是值得省思的,是什麼原因讓我們在「佳玲」(註2)光鮮亮麗的外表下,潛藏巨大的隱憂? 在我們日常的專案運作中,是不是也有這種暴風雨前的寧靜? 是我們總是報喜不報憂,還是專案的生存遊戲中有什麼看不見的地雷?

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

鬼滅之刃

動漫【鬼滅之刃】2020年在台日掀起一波熱潮,劇中的鬼殺隊是經過選拔編制的團隊,負責斬殺惡鬼保護人類,其中主要人物性格鮮明,各自擁有不同專長,角色及任務配置十分明確。從專案管理的角度來看,R&R(註1)雖然是個看似簡單的佈達任務,卻充滿不少眉角需要注意,有時也對專案後續的執行帶來不小影響。本篇文章以【鬼滅之刃】的角色設定當做啟發,來探討專案角色與職責分配的重要性。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

BurndownChart_ideal.PNG專案執行的過程中,經常需要透過各種圖表來向利害關係人說明進展,針對不同的階段或對象,所使用的圖表也有所差異。在敏捷軟體開發專案中,常用一種稱之為「燃盡圖(Burndown Chart)」的方式來展示進度。

燃盡圖是用來表示剩餘工作量的圖示。以下圖為例,藍色線段代表基準線表示每一天預估的剩餘工作時數,假設完成某一項任務所需的時間為300小時,在不考慮任何變數影響的情況下,剩餘工作時數會隨時間等量遞減,直到表定完成的日期時,剩餘時數等於零。紅色線段為實際運作後所繪製的曲線,每天消耗的時數不固定(如藍色長條圖所示),因此線段會出現波動,在起初的5天內,紅色線段位在藍色下方,代表實際的情況較預期落後,直接第5天後,進度開始超前,並且在最後一天完成任務。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

Apro13.jpg前一陣子重溫了《阿波羅13號》這一部經典電影(註1),內容是描述NASA於1970年4月執行的登月計畫,發射後兩天因氧氣罐爆炸造成太空船嚴重毀損,三位太空人不得不使用登月艙作為救生艇逃脫,最後克服種種困難成功返回地球,被稱作登月計畫中「最成功的一次失敗」。閱讀過一些相關書籍資料後,發現電影算是相當鉅細靡遺根據紀實拍攝,在回味經典的同時,也讓我找到許多專案管理上可以效法的地方。

【風險應變準備】

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

在產品開發過程中,為了有效和不同角色溝通,軟體PM經常需要準備各種形式的資料,例如簡報、範例圖、流程圖、表格....,林林總總的資訊,目的就是要確保每個人對同一件事、同一個產品規格有足夠且具體的了解。資料準備越齊全,即便日後經過人員交替、任務交接,也能遵循相同的規則繼續前進,讓影響降到最小。

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

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

AS.PNG一個好的產品從企劃到完成,就好比主廚費心烹煮佳餚的過程,從一開始決定方向、挑選食材、構思做法,到料理時不斷測試口感並調整,最後確認品質、擺盤、出菜,步驟缺一不可。也因此,讓我想到MasterChef Australia(註1)這部澳洲烹飪實境秀的電視節目,該節目透過一連串不同主題的競賽,每周淘汰一位參賽者,直到選出冠軍為止,在過程中,可以看到不同參賽者對同一種主題或料理的詮釋,在口味、擺盤等各個面向皆有差異,但執行時所展現的精神卻與產品及專案管理思維不謀而合。

從專案管理的角度來看,廚師製作料理的過程,符合專案「在有限時間、資源內,交付特定產出」的基本定義,節目單位所設計的題目,則可視為sponsor的專案章程,它定義了料理的概念(可能要求參賽者複製經典異國料理,可能是針對某個季節、某段回憶去發想),也提供可選用的食材,相當於專案的基本方向及限制條件。在這初步的範疇之內,便是廚師可依照自己的想法去發揮創意的空間,而他們接下來所展開的工作,約略可以歸納為以下幾點 : 

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

DSC_0222.JPG職棒場上有一句名言 : 贏球治百病。意思是說球隊若是能贏球,很多缺點都可以被忽略,相反的,一旦球隊處於戰績低迷狀態,團隊向心力(也就是所謂的休息室氣氛)就會成為重要的檢討項目。

團隊建立的過程大約會歷經幾個階段 : 

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

pexels-lukas-669610.jpg在產品的生命週期中,必須先歷經新創期、成長期後,才能進入穩定發展的成熟期,但多數新創產品在進入成熟期之前,就紛紛失敗退出市場,這些失敗的寶貴經驗,都是下一個新產品茁壯發展的養分。我曾經待過兩家新創公司,過去的職涯也參與多次大大小小的新產品、新服務開發,這裡列出幾個我認為導致產品失敗的關鍵,一方面讓自己作為警惕,另一方面也提供給大家當參考,避免重蹈覆轍。

雖然產品失敗的原因很多,且環環相扣,我還是依自己的經驗,盡量將之歸納為三個關鍵,分別為市場認知、團隊認同、執行力,這篇文章就先來談談新產品在導入前,對市場的掌握程度,產品人或多或少知道,或聽過STP理論,我想從中來進行一些簡單的剖析。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

pexels-andrea-piacquadio-3760810.jpg加利口罩商在2020年9月遭爆進口大陸製非醫療口罩,並且混充MIT醫療口罩在藥局及實名制通路販售,不當獲利,但加利負責人林明進卻反批評政府壓榨口罩商,不但以低於市場價格徵收,且徵用量高、時間緊迫,加利為了達到政府的徵用量,員工只能日以繼夜趕工無法休息。關於加利是否違法,以及政府徵用口罩的過程是否有瑕疵,這點得交由相關單位調查,我們不予評論,但從專案管理的角度來看,當目標時程緊迫的時候,真的只有加班一條路嗎? 或許我們可以從幾個方向來著手。

1. 確認Deadline的可調整性

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

時程估算一向是讓PM頭痛的工作,應該有許多人和我一樣,經常會陷入期望值和估算值的拔河。所謂期望值,是利害關係人對專案完成時間的期望,和可行性無關,通常較為偏向情感導向。估算值則是經過團隊成員討論取得共識的預估時程, 一般來說,時程估算有幾種方式 :

1.專家判斷 : 顧名思義,可請團隊中對該項任務較熟悉的成員來評估,或者尋求專案外部專案提供意見。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

roadmap6.JPG身為產品經理,經常需要製作product roadmap來說明產品的相關資訊,但到底一個好的product roadmap需要包含哪些資訊呢? 工作多年以來,我發現一直很難找到一個明確的定義,似乎每一個主管要求的都不太一樣,大家所繪製出來的roadmap形式也各有不同,直到最近在國外網站上看到一篇相關文章,原文標題為Product Roadmap: Key Features, Types, Building Tips, and Roadmap Examples,看完後覺得心有戚戚焉,決定分享一下我的心得。

首先,什麼叫做product roadmap? 顧名思義,它叫做產品地圖,目的是指出產品所在位置的一份地圖,而它要勾勒的相對位置,是產品願景和公司業務目標之間的距離,因此我們通常會用一條時間軸,再加上幾個重要的產品要素來組成。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

7b1e31a30b9c43d8a5dcd54e3c97735101_activityGrid.jpg這一篇是舊聞新發,來自 馬克 畫作所衍生的發想。

老闆影響專案效率、不受下屬喜愛,這個問題不管在哪一個管理階層都會發生,不論下屬貴為經理、協理、副總等,或多或少也聽過抱怨,只是不同位階的人表達的方式有異,情緒轉換的功力也有深淺之別,謾罵之餘,還是可以學學人家的情緒管理與正面思考的態度。

victor 發表在 痞客邦 留言(0) 人氣()

雖然溝通占了專案管理百分之八十的時間,但這並不代表專案經理的工作就是出一張嘴,因為溝通的方式有很多種,除了當面對談之外,舉凡信件、會議、簡報、文件等,用來將某些事情傳達給另一方的方式,都在溝通管理的範疇內。那麼,專案經理顯然是紙上談兵的高手囉? 事實不然,為了產出足以說服所有利害關係人的資料,專案經理必須將原本雜亂的訊息彙整成有條理的報告,一份60分的簡報或許花不了太多時間,但要完成一份80分的簡報,除了讓數字說話之外,背後要付出的吸收時間就非常多。

我的第二份工作是擔任App的專案經理,當時公司導入CMMI管理框架,因此有數量非常多的文件必須在專案生命週期中產出,和第一份工作放任式管理有著天壤之別,因此也了解到同樣身為PM,在不同的組織管理政策下,會衍生出截然不同的工作型態。

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()

我想聊聊自己的第一份工作,那是一個新興產業的新創公司,由於什麼都是新的,回想起來也特別有意思。

新創公司有一個特點,就是職稱與工作內容通常是不相等的,例如Internet程式設計師的工作,泛指產品開發生命週期中,需經過程式設計師手中的,往上追溯至產品源頭,往下延伸至客戶需求,期間的工作都屬之,同理可證,產品企劃的工作,是指產品開發生命週期中,需經過企劃的,往上追溯至產品源頭,往下延伸至客戶需求,期間的工作都屬之。所以基本上,Internet程式設計師的工作=產品企劃=專案經理=品管=任何你想得到的職務。除此之外,當時的公司在台灣又屬新興產業,於是乎,職務就常出現XX師、XX總監等嚇死人不償命的頭銜,既然無法定義,姑且我們就稱之為新創公司的小員工吧!

文章標籤

victor 發表在 痞客邦 留言(0) 人氣()