Photo by Viktor Talashuk on Unsplash

前陣子在幫產品經理整理從2019年的新產品研發專案零零總總將近30多個新產品,各產品究竟花了多少開發經費。這些資料四散各地。我大概花了20分鐘彙整給他。他非常驚訝怎麼有辦法在這麼短的時間內找齊這些資訊。我就回他「當在不同的專案,把類似的東西放在類似的地方,這件事情就很容易了」。我想分享我帶的專案都是如何系統化整理專案資料,讓往後查詢很方便。

大致上有三大重點

  1. 資料夾索引化
  2. 整理扁平化
  3. 檔名清楚化

資料夾索引化

資料夾索引化的概念取自於圖書館。為了讓書籍整理方便,使讀者能快速找到書籍,圖書館建立了一套系統將各種購入書籍賦予一個代碼數字,並依照這些代碼整理書架。這套系統只要持續使用,後面進來的新書就會自動知道該去哪個書架。或是讀者按照索引編號,去該號碼的書架上便可以找到該類別的書籍。這樣的系統會節省很多找尋與歸類的時間。下圖是台灣某圖書館的分類索引規則。

--

--

最近公司在整理一些過往新產品研發的銷售成果與檢討。歸納出幾個很有趣以及我認為可以透過一些方式改善的點 首先來談談實體產品的困境我碰過的大致會有三種 開發時間很長 初期不確定性高,後期變更成本高 產品沒有受到當初預期的客戶迴響 我逐一來解釋這三項 實體產品研發從開案到正式發表所需時程少至半年,多至2年。實體產品通常需要經過好幾個階段的驗證。以我在的熱融膠產業來說,單是在實驗室階段要找到對的化學配方可能要花3個月至半年。再來還要經小批試產與大量試產又會花數個月。如果原物料是台灣自產的,交期時間還可以接受。但如果是國外進口,那時間就會驚人地疊加上去。如果產品方向沒有抓對,很有可能花了一年半載上市結果不是市場要的東西,這就會是一個失敗的產品專案。 多數產品專案在初期都是需求不確定性很高。很多時候客戶只是丟出一個很主觀感受的需求,例:要手感軟一點、更有彈性一點、更有質感一點,這類需求有時很難用數字或是特定測試方法去量化成果。或者面對一個需求,有很多種潛在解決方案但不知道哪個會是客戶在性能與成本上最終能接受的。而實體產品的研發另一個困難點在於規格特性有時環環相扣,如果是在很專案後期才提出變更,要付出的變更成本幾乎是等於整個打掉重練,回到實驗室階段。

想提高實體產品開發成功率,你可以試試以下方式
想提高實體產品開發成功率,你可以試試以下方式
Photo by Jason Goodman on Unsplash

最近公司在整理一些過往新產品研發的銷售成果與檢討。歸納出幾個很有趣以及我認為可以透過一些方式改善的點

首先來談談實體產品的困境我碰過的大致會有三種

  1. 開發時間很長
  2. 初期不確定性高,後期變更成本高
  3. 產品沒有受到當初預期的客戶迴響

我逐一來解釋這三項

實體產品研發從開案到正式發表所需時程少至半年,多至2年。實體產品通常需要經過好幾個階段的驗證。以我在的熱融膠產業來說,單是在實驗室階段要找到對的化學配方可能要花3個月至半年。再來還要經小批試產與大量試產又會花數個月。如果原物料是台灣自產的,交期時間還可以接受。但如果是國外進口,那時間就會驚人地疊加上去。如果產品方向沒有抓對,很有可能花了一年半載上市結果不是市場要的東西,這就會是一個失敗的產品專案。

多數產品專案在初期都是需求不確定性很高。很多時候客戶只是丟出一個很主觀感受的需求,例:要手感軟一點、更有彈性一點、更有質感一點,這類需求有時很難用數字或是特定測試方法去量化成果。或者面對一個需求,有很多種潛在解決方案但不知道哪個會是客戶在性能與成本上最終能接受的。而實體產品的研發另一個困難點在於規格特性有時環環相扣,如果是在很專案後期才提出變更,要付出的變更成本幾乎是等於整個打掉重練,回到實驗室階段。

最糟的就是當初設想的產品規格,以為可以打到客戶的需求。結果做出來的產品叫好不叫座。市場反應沒有想當初設想的那麼好。那些研發成本等於是打水漂。

解決以上問題可以使用三個方式來處理

  1. 設定贊助客戶(Sponsor customer)
  2. 採用最小可行性產品(MVP)取得回饋
  3. 同時進行幾個解決方案

設定贊助客戶

首先談贊助客戶的設定。我們發現有明確單一的贊助客戶產品成功率會比較高。主要是因為當贊助客戶願意承諾參與產品開發時,他未來要採用該產品的機率會上升。再來有個贊助客戶在,對於產品需求的精準度會更有把握,能將他的考量完整評估而提高產品滿意度。遇到意見分歧時,可能也比較容易站在該客戶的觀點快速收斂定案。

若很清楚知道客戶的時程,並以客戶時程為基準作為專案時程展開的依據,會更容易讓該新產品導入客戶的供應鏈系統,加速該產品開始銷售的時間點。因為有個具體要達標的里程碑時間壓力在,也會多了負責該客戶的業務盯緊,開發團隊更能戰戰兢兢面對專案工作,將其重要等級放較高順位。最後在掌握產品營收及研發投資報酬率的掌握也會比較高。

最小可行性產品(MVP)取得回饋

再來談最小可行性產品 MVP。最小可行性產品的概念就是用最少的資源及最快速的方式產出一個概念性或小實驗成品,讓客戶可以看看、摸摸、試用,並回饋使用後意見。

如前面所說,很多時候客戶自己提出的需求其實都一知半解。我曾碰過一個 case 是客戶拿著很久以前跟別家公司買的東西,因為原廠商倒了,希望我們複製一個,但他連當初設計規格都遺失,所以只能提供買的東西以及應用情境。於是我們在做簡單的材料分析後,就運用手上有的東西先做兜出一個長得很像的小樣品先給客戶試試看。再依據客戶使用後的回饋,做進一步的規格調整迭代,最終做出一個他非常滿意,也比之前便宜的產品。

MVP 的做法可以讓產品更貼近客戶的想法,並降低埋頭苦幹結果做出不是客戶要的東西之機率。也因為客戶持續收到樣品並參與其中的研發過程,他也會很期待能使用到該成品(除非你端出來的東西一直都無法讓他滿意)。

同時進行數個解決方案

最後一個建議就是務必要有多個解決方案同時進行。俗話說不要把全部的雞蛋都放在同一個籃子,換到產品研發就是不要只有一個方案。這是降低失敗機率的方式。在開發成本允許下,盡量能有越多不同的解決方案。甚至在專案開案評估專案成本時候,也記得多估一些第二、三方案的研發成本。

多數實體產品研發最終都要經過一個從實驗室放大到試量產階段。然而實驗室數據再怎麼美好,放大之後都會發生不如預期的結果。有時再怎麼調整也無法重現期待的結果。這時若有第二、三方案同時進行,就可以把注意力轉移到備案上讓專案繼續進行下去,而不用打掉重練。降低修改的時間成本,也更能讓產品準時推出的機會提高。這招在我帶新產品研發專案這幾年屢試不爽。

以上是我這幾年經歷過數十個產品研發專案,覺得可以有效提高產品研發成功率的方式供讀者參考。若有讀者有其他建議,也歡迎不吝分享。

記得「Follow」我的 Medium,讓我提供更多優質文章給您。如果覺得這篇文章不錯,也請不吝掌聲拍手。你的拍手是我寫作的動力。

--

--

Photo by Chrissie Giannakoudi on Unsplash

這篇要來講講 PMBOK 翻譯專案是如何顧好翻譯品質。

由於志工來自四面八方,有人是在 N 年前取得 PMP 證照而有的是近期。為了要讓大家都回顧一下 PMBOK 的內容,以及作為小組剛組建磨合,需要先嘗試協作一點東西,在 6 月底專案剛開跑就安排了一系列的讀書會,指派各組負責不同章節彙整簡報內容向全部志工報告培訓。用這樣的方式幫大家找回對第六版的記憶。而第七版在 7 月上線後,針對自己未來要負責翻譯的章節,也做一次相同活動。這樣除了自己對負責的內容有初步了解,在聽取別組製作的簡報,也可對第七版整本書有大略了解。

PMBOK 第七版總共370頁,如果只交由一人翻譯的話或許要一年才能出版。但如果是由一個百人團隊來處理,4 個月便可搞定。但問題是一百個人翻譯,就會有一百種翻法,格式、用詞、標點符號都各做各的。這樣翻譯出的成品可能比看原文還更煎熬。

為了要讓百人團隊翻譯出來的東西看起來像一個人翻的,勢必要做很多規範讓整個團隊來遵守,以確保大家的產出不會偏差太多。因此在這專案裡,除了前一篇提到的 scrum 流程與自組織運作外,在翻譯內容也做了必要的規範。大致上分成3種:

  1. 標準詞語表
  2. 詞彙表(Glossary)
  3. 格式與翻譯規則

標準詞語表

PMBOK 裡頭有許多用詞或專業術語在書中不斷地被提到。為了確保大家對這些用詞的翻譯一致,勢必要彙整出來並統一中文翻譯,在翻譯過程碰到時就會用對翻譯。標準詞語表就像是一本中英辭典,是團隊在翻譯時需參照甚至務必遵行。比如說 project team 這詞,可能會翻專案團隊、專案小組、項目隊伍等等五花八門的中譯。這時就要強制統一翻成「專案團隊」,讀者才不會翻了幾頁發現一詞多譯,看得眼花撩亂。

--

--

Photo by Hannah Busing on Unsplash

這篇要來說明參與翻譯工作的翻譯小組、整合組和審委各自有什麼不同角色要扮演,也會談到整個團隊歷經塔克曼( Tuckman ) 團隊發展過程的紀錄。

翻譯小組一組會有 13 名成員大致上可分為三種角色:

組長 — 處理跨組事務及組內協調事項。負責主持上篇文章提到的scrum各項會議,也要確定組織用的文件格式。

翻譯成員 ( 9 員) — 將英文翻譯成中文的第一線工作人員,也要對其他成員的翻譯章節互相初步檢查。

品管與定稿品管 QA ( 3 員) — 擔任品管及定稿品管 QA 都有 TOEIC 800 等級的英文實力,故擔任產品內容的校閱潤飾。第一線翻譯人員互相檢查後,就會給品管再做一次審查,最後再給定稿品管(也就是我)看過。完成後就可以準備 Demo 交付。

--

--

這一個月來在忙碌的事情是我接了一個志工專案,負責將俗稱專案管理聖經 “PMBOK” 最新第七版的內容翻譯成繁體中文。在接下來幾篇文章我會一一詳述這整個翻譯專案如何運作,做為自己往後回顧的紀念。

首先先來談 PMBOK 到底是什麼。

PMBOK 全名是 Project Management Body of Knowledge,中文翻「專案管理知識體系指南」。是由總部在美國的國際專案管理學會 Project Management Institute (PMI) 所出版的。內容是集結專案管理領域的專家,撰寫一本適合當代商業環境,有效率管理專案的教科書。同時 PMI 也推出兩個專業證照 ,PMP 跟 CAMP 。取得這證照需要考試,而考試內容就是基於這本指南。

PMBOK 第一版是在1996年出版,大概4~5年會更新一次。而最新的第七版則是在2021年7月正式上線。PMI 授權在各國家的專案管理學會分會翻譯成當地的語言,而在台灣的專案管理學會分會 (PMI-TW)也在6月底正式啟動這個翻譯專案,號召了百位海內外的夥伴參與翻譯,以分組方式進行。

這版 PMBOK 跟前一版比起來少了一半的厚度。最主要是因為第七版的內容再也不執著於死板板的架構流程 (俗稱 49 個 ITTO),反而是回歸到做專案的初衷: 用專案執行將價值帶給客戶。書裡也提到專案經理該有的特質(12 原則)、專案執行該注意的各個面向( 8 大績效領域),及最後詳列各項工具讓專案團隊去挑選使用。這樣的好處是可以讓專案更有彈性,依據專案性質與利害關係人的需求去客製化專案規畫與執行方式,讓專案團隊不會被流程綁住,反而能為客戶盡力做出對他們有價值的產品。

第六版的教材更像是採用瀑布式規劃的專案,對於很嚴謹的大型專案如營造業來說是很適合。但現今更多的是中小型專案,根本不需要採用這麼大規模的東西。因此將規劃方式下放給專案經理跟團隊去思考怎樣做才是最恰當的,就是這一版的核心觀念。所以嚴格說,這版的內容更像是專案管理的心法教學,而非流程教科書。

對於有實務經驗的人來說,這本書會是個很棒的教材,因為流程模糊的空間剛好可以用自家組織的流程架構去填補,而教材有提到的內容更可以加強專案經理弱的領域,缺什麼就有該領域的心法去填補。但這本書對於完全沒接觸專案管理或手邊沒有管理流程的初學者來說是蠻痛苦的,因為這版並不會跟你說做專案的步驟一二三怎麼做,需要仰賴其他課程或是書籍來補足這塊,或是看前一版了解專案該如何執行。

下篇文章我會講整個專案的運作方式。

記得「Follow」我的 Medium,讓我提供更多優質文章給您。如果覺得這篇文章不錯,也請不吝掌聲拍手。你的拍手是我寫作的動力。

--

--

最近一個月呈現完全頹廢狀態。無意間看到了魔獸世界的廣告,就不小心回鍋了。大學時代曾經沉迷一陣子,後來當兵開始工作後生活上的忙碌讓我沒空可以沉浸在這虛擬幻想世界裏頭。

這次的回鍋讓我有機會慢慢思考這遊戲為何可以撐17年還有約480萬活躍玩家 (雖然每年以14萬人遞減)。

魔獸世界是在2004年爆雪娛樂推出大型線上角色扮演遊戲 (MMORPG)。內容建立在一連串史詩的故事內容與正邪的對抗。為何這遊戲可以這麼的長壽,我自己是覺得有以下三點:

  1. 沉浸式的故事敘述

在魔獸裏頭,每個任務的開始都會稍微描述一下故事背景,要請你做什麼事情,以及獎勵是什麼。

--

--

Photo by Elena Taranenko on Unsplash

前陣子在公司碰到一個狀況。我們公司的 QC 部門一直比較薄弱。多數時間是在針對客訴做 troubleshooting 回應。前陣子 QC 部門進行改組,把原本分散各部門的 QC 人員整合成一個部門,也指派了一位新主管。但他們對於自己要擔任的職責範疇 (R&R) 仍在重新釐清。

前陣子我有兩個新產品開發專案準備收尾,正在進行最後規格定稿。基於禮貌下就拿給 QC 部門過目一下。開發過程中都有 QC 人員受邀開會,會議記錄也有 CC 他們,他們很少在會議中提出疑慮。所以我心想 QC 應該對產品開發內容皆核可沒問題。萬萬沒想到 QC 主管劈哩啪啦給了一堆質疑意見,有的意見甚至可能會動搖到規格而被迫延遲專案。我完全沒預期到 QC 主管如此突然的大反應。

對這問題一直百思不解,後來尋求了一些前輩的意見,才解了我的疑惑。原來雙方在意的區塊不同。我在意的是產品研發沒重大問題,讓新產品準時發表,專案如期結案。而 QC 主管他要確保的是產品萬無一失,最好零缺點,以避免往後客訴麻煩。我跟他聚焦的重點不同。在目標上的出入就會造成兩方似乎在互相扯後腿的現象。雖然從更高的角度看,兩邊都是在為公司好。

更深一層分析,癥結點在制度設計上, QC 不需共同承擔專案時程責任專案過程中也被放在旁觀審核者角度,而不是產品或專案的擁有者(owner)之一。換句話說,在專案過程中 QC 無需持續檢視研發中的產品可能會有何品質疑慮及提醒研發團隊。他們被賦予的責任是只需在專案最後階段做審核人。若品質審核發現有任何問題,直接卡住產品要求團隊再回去釐清修改就沒自己的事了。但這一切其實是可以在研發過程中,早期發現早期處理的。

後來與主管跟 QC 部門討論後我做了一些調整

團隊與責任調整

直接將 QC 人員升格成核心專案成員,增加他們在專案裡的責任承擔。新增的責任有:

  1. QC 成員參與所有專案文件的制作工作

2. 參與專案定期會議。在開會過程中詢問 QC 人員有無任何品質方面的回饋,並及時將這些需求納入規格開發考量。

3. 參與產品試產並與生產部成員共同檢視試產成果。

交付物審核

QC 主管須負責交付物里程碑之前的審核。以往 QC 主管都是在產品正式發售後,產品出了問題才跑來詢問這產品到底是什麼,怎麼做出來的。為了避免這種狀況,現在 QC 主管也必須要納入利害關係人管理名單中,確保 QC 主管也有參與到產品開發過程並負起一部分責任。

當他做審核的時候,由於他的部屬同事已積極參與了,理論上資料審核都能很快完成。若發現有問題之處,那就是集眾人之智而發現的缺失,不容易發生任何人被指責當箭靶。QC 主管也必須代表QC部門參與交付物里程碑會議。

以上經驗供各位讀者參考。當碰到似乎別人來找碴,阻撓自己的工作進度時,可以先想一想,是否為制度設計不良導致的結果。或許修改一下,讓目標方向一致就可以減少這些不必要的衝突。

記得「Follow」我的 Medium,讓我提供更多優質文章給您。如果覺得這篇文章不錯,也請不吝掌聲拍手。你的拍手是我寫作的動力。

--

--

最近因為在台灣的一連串公衛事件發生,許多比較有英語能力的人就去爬文看他國的做法是什麼,然後反問台灣政府為何不能照做。下面的留言就會有一長串的留言在爭吵。其實這種現象很常發生在我們的身旁,小至為什麼隔壁王太太使用某個藥方治療她的症狀有效,怎麼我用就沒效。大至為什麼那家企業用這個策略方法成功,可是我公司用了問題反而更多。 很多時候我們在考量這些建議抉擇時只見到結果,但忘了去看背後還有很多要考量的因素。若是要考量別人的作法是否適合自己時,記得要先去考量兩個層面: 目的與條件 目的 目的顧名思義就是做這個抉擇想要得到什麼成果,為何要做這件事。每個人做其抉擇都有想要達到的目的。就算是同一個抉擇,不同人做也會帶著不同的目的。舉個例子,選擇去墾丁海邊玩。有的人目的是為了玩水,有的人是為了看海,有的人是為了看帥哥美女。當帶著不同目的時,雖然都是去海邊,獲取的東西會不同。 再舉一個比較生活的例子。都是買一隻台積電股票,每個人的目的就會不同。有人打算想放長期投資、有人看上它的穩定季配股息(雖然殖利率蠻低的)、有的是想炒短線。帶著不同目的投資時,就會需要用到不同的評估方式。而這可能是別人不會主動告訴你的。

別人的成功作法不一定適合你
別人的成功作法不一定適合你
Photo by Diego PH on Unsplash

最近因為在台灣的一連串公衛事件發生,許多比較有英語能力的人就去爬文看他國的做法是什麼,然後反問台灣政府為何不能照做。下面的留言就會有一長串的留言在爭吵。其實這種現象很常發生在我們的身旁,小至為什麼隔壁王太太使用某個藥方治療她的症狀有效,怎麼我用就沒效。大至為什麼那家企業用這個策略方法成功,可是我公司用了問題反而更多。

很多時候我們在考量這些建議抉擇時只見到結果,但忘了去看背後還有很多要考量的因素。若是要考量別人的作法是否適合自己時,記得要先去考量兩個層面: 目的與條件

  1. 目的

目的顧名思義就是做這個抉擇想要得到什麼成果,為何要做這件事。每個人做其抉擇都有想要達到的目的。就算是同一個抉擇,不同人做也會帶著不同的目的。舉個例子,選擇去墾丁海邊玩。有的人目的是為了玩水,有的人是為了看海,有的人是為了看帥哥美女。當帶著不同目的時,雖然都是去海邊,獲取的東西會不同。

再舉一個比較生活的例子。都是買一隻台積電股票,每個人的目的就會不同。有人打算想放長期投資、有人看上它的穩定季配股息(雖然殖利率蠻低的)、有的是想炒短線。帶著不同目的投資時,就會需要用到不同的評估方式。而這可能是別人不會主動告訴你的。

先了解目的才能比較理解為何對方做這樣的抉擇,而不是只看作法但不問目的。

2. 條件

條件的意思是手上有什麼資源可以利用以及整體局勢是怎樣的。也就是俗稱「天時地利人和」的狀況怎樣。企業會評估手上有多少資源,所在的商業環境,來為企業目標訂定最適合自己的企業策略行動。資源比較多的大企業能使用的策略及規模會比小而美的企業要多。

如果談到個人的條件可以分為內在跟外在:

內在條件又可分為有形的與無形。有形的條件如名下資產、現金、車子房子等。無形的條件像是工作技能、口才、專業知識經驗等。外在條件像是社經地位、信譽、人脈關係等

這些條件會決定可以做什麼樣的事情。如果只有1萬元的預算,不可能做百萬元等級的選擇。硬要做一些超出自己條件能力的抉擇只會讓自己陷入麻煩。

舉個之前有名的戴勝益演講。他說到月收入未達五萬不要儲蓄,要拿來拓展人際關係。單看這句話就照做的話肯定會出問題。首先要想一想自己到底有沒有本錢做這件事。不做儲蓄這件事情代表戶頭只留很少錢。那萬一有緊急事故需要急用錢,但戶頭沒錢也沒有家人朋友可以金錢支援時,會讓自己陷入困境。戴勝益有底氣跟條件容許他這樣做,但我們可能沒有。因此做之前要仔細思考做這件事的目的以及自己有什麼條件。他的講這句話目的是要鼓勵年輕人交朋友建立人脈。所以接下來我們就要思考這個目的到底是不是自己需要的,以及自己投入多少錢才恰當,而不是盲目地把全部的錢都砸下去。

因此當別人建議一個成功做法給自己時,先記得先問一下他當初做的目的跟時空環境條件是怎麼一回事。如果都跟自己很相仿,那可以參考斟酌使用。如果是個天差地遠的背景,感謝對方的好心就可以了。

記得「Follow」我的 Medium,讓我提供更多優質文章給您。如果覺得這篇文章不錯,也請不吝掌聲拍手。你的拍手是我寫作的動力。

--

--

前幾天跟一位朋友討論到工作。他主要的工作是在政府機關作為發包承辦人,然後要代替主管盯緊外包商,每天就是找外包商問進度。當外包商出包的時候,要一起想解決方案。但他一直覺得好像沒有一個核心業務,感覺很像在打雜。他喜歡把一件事情做到專精的感覺。 後來我跟他以「三年後,你的工作還在嗎?」 書中提到的工匠與總管概念來跟他說明。 工匠: 能獨立產出一件作品,不管是實體產品或是軟體服務。他的產出與貢獻能具體被定義。 總管: 出一張嘴指揮團隊成員分工協作完成一件作品。他自己的產出就是團隊的產出,但是屬於個人的貢獻很難定義。 很多人從事專案工作覺得沒有成就感。整個執行過程中,自己的貢獻無法跟事情的成果連結在一起,會有不踏實感及不知工作意義在何處。我想針對 PM 帶來什麼價值這件事情來談一談。 首先做 PM 這工作能帶來的價值講白一點就是帶給利害關係人「安心感」。 主管把一個專案交給 PM 負責,知道他能把案子從零帶到完成,不會闖出無法收拾的殘局。團隊成員知道跟著這 PM,可以信任他不會亂給方向而浪費團隊時間跟精力。外部包商知道跟這 PM 合作要戰戰兢兢,該做的事一點不能少。客戶知道跟這個 PM 合作,自己需要的東西都能合理地被記錄處理,但想佔便宜也不容易。

專案管理的價值在哪?
專案管理的價值在哪?
Photo by Sharon McCutcheon on Unsplash

前幾天跟一位朋友討論到工作。他主要的工作是在政府機關作為發包承辦人,然後要代替主管盯緊外包商,每天就是找外包商問進度。當外包商出包的時候,要一起想解決方案。但他一直覺得好像沒有一個核心業務,感覺很像在打雜。他喜歡把一件事情做到專精的感覺。

後來我跟他以「三年後,你的工作還在嗎?」 書中提到的工匠與總管概念來跟他說明。

工匠: 能獨立產出一件作品,不管是實體產品或是軟體服務。他的產出與貢獻能具體被定義。

總管: 出一張嘴指揮團隊成員分工協作完成一件作品。他自己的產出就是團隊的產出,但是屬於個人的貢獻很難定義。

很多人從事專案工作覺得沒有成就感。整個執行過程中,自己的貢獻無法跟事情的成果連結在一起,會有不踏實感及不知工作意義在何處。我想針對 PM 帶來什麼價值這件事情來談一談。

首先做 PM 這工作能帶來的價值講白一點就是帶給利害關係人「安心感」。

主管把一個專案交給 PM 負責,知道他能把案子從零帶到完成,不會闖出無法收拾的殘局。團隊成員知道跟著這 PM,可以信任他不會亂給方向而浪費團隊時間跟精力。外部包商知道跟這 PM 合作要戰戰兢兢,該做的事一點不能少。客戶知道跟這個 PM 合作,自己需要的東西都能合理地被記錄處理,但想佔便宜也不容易。

要達到以上這些程度,我自己認為 PM 需要為專案做出兩個重點: 透明度及可預測度。

透明度

透明度指的是專案的各方面資訊如實揭露沒被隱藏。不管是專案實際進度、正在處理中的問題或花了多少錢等。各項指標數據都能讓主管或團隊快速掌握。

主管時常被迫要在短時間下決策。在有限時間內,若有越多資訊在手上,做出來的決策品質會越好。倘若 PM 或是團隊習慣或規則沒設好,不知道如何整理這些資訊東丟西丟。找尋肯定會花費不少時間,甚至找不到重要資訊。這就會造成很大的麻煩。

透明度也會讓利害關係人產生安心感。主管不在前線,也沒有那麼多時間跟第一線的人討論收集他想要的資料,因此需委派一個 PM 來代替他執行。若 PM 資訊收集地完整,能如實如期地回報給主管,其實就會給主管很大的掌握感。這種掌握感會轉變成對 PM 的信任感,而信任感在職場當中是項非常珍貴的資產,它可決定你能否往上晉升或承擔更重要的案子。

可預測度

可預測度指的 PM 對於案子的時程或成本變化能掌握住。當需要救火的危機時,適時端出適當的方案。或是在危機還沒發生前就先做預防準備降低其發生機率或是影響。PM 能穩穩地控制好專案便能給上層安心感。可預測度主要是從兩個層面來著手:

  1. 風險管理

風險管理的重點在於辨識風險及規劃風險對應策略。從過往的經驗、專家的建議或是系統性地去發想,把可能會在這專案發生的問題都想過一遍,作適當的風險對應規劃與資源投入處理。若 PM 有做好風險管理,將可預見的風險都列入考量作準備,其實就能像孔明一樣,可預知事情的發生,不會慌張手忙腳亂。風險管理做得好,專案出狀況的機率會少很多,讓專案較能按規劃執行。

2. 動態排程

PM 另一個能增加專案可預測度的工具就是排程軟體。專案變動每天都在發生,一下廠商延遲,一下團隊工作任務調度,一下客戶提出新需求。這些變動都會對時程及成本造成影響。若手上是靠一張 Excel 做規劃,每天光處理這些變動造成的計畫修改就佔去很多時間,根本無法評估這些變動產生的影響,更別提要想各種應對方案。若有個軟體在手,任何變動都可以快速地以軟體計算出對時程的影響為何,也能做模擬情境來想各種對策。

擁有將計畫快速調整的能力,就能提高對於專案完成時間的預測。這對公司整體整體營運也會有幫助。舉個例子: 若企業有做產品 Roadmap,會需要知道各項產品專案預計完成時間,並適時調整 Roadmap 發表時程。這甚至會左右公司的預期年度營收以及年度預算配置,影響非常大。

可預測度提高,起碼在主管詢問案子進展時不會一問三不知,讓主管留下一個辦事不力的印象。

記得「Follow」我的 Medium,讓我提供更多優質文章給您。如果覺得這篇文章不錯,也請不吝掌聲拍手。你的拍手是我寫作的動力。

--

--

Kieren Chen

Kieren Chen

產品開發專案管理 遠距工作 MS Project 排程軟體專家