(硬體)產品經理一二三 (專案拆分)

其實就是大家說的Work Breakdown Structure (WBS)

但這不是已經談到爛的東西嗎，我說的肯定跟別人不一樣。我會用產品開發案為例，當然也有像是調研類的服務專案，但是這種類型專案，任務執行的順序及相依性，相對來說沒那麼高，所以還是用「產品開發專案」為基礎進行說明。

基本上立項審查通過後，不一定會馬上分派人手，但至少會有一個專案首席工程師(Lead engineer)，跟專案經理一同把時程表完成，而且過程越快越好，才能趕上週會的報告，跟高層報告「專案已經就緒，以下是里程碑......。」在整體架構還不完善，而且有些工作，還要找時間跟執行者討論內容，負責工程師有可能自己也拿不準需要花多少時間，太早就要壓死日期，而且後續完全沒有商量的空間，只會消磨工程師的鬥志，變成大家喊芭樂拳。
當然，我們可以理解有些專案，就是要讓經驗不足派來練兵用的，一開始部門經理就溝通清楚，把工程師需要學習的部分，在專案結案後，成為一份書面報告，或是採分享會形式。那這種練兵專案，不確定性會比較高，在初期就先有這份預期，較能得到關係人的理解與包容，同時也不會打擊新手的自信心。

要拆解工作，首先必須列出所有該做的，就是整理一份清單。有些工程師很排斥，覺得這文書很麻煩，但是光列出清單，就對整理思緒有非常大的幫助，同時也能釋放腦力，讓你更專注於一些需要創造力的事物。這些清單包括像是待製作物清單、待研究主題清單、待解決問題清單、待添購工具清單、打聽信息對象的清單等等。

這份清單應該是一份動態的文件，因為內容難免會有疏漏及重複，雖然大家都說MECE，但是面對沒有執行過的專案，初期很難判斷究竟少了什麼，而在你越接近的時候，才能看得越清楚。

如果在部門分明的組織，那基本上可以用階段來驗證工作是否完成，品質是否達標，以及是否能夠繼續前進到下一階段。但是如果設計、品管、組裝都落在同一人或部門身上，這種球員兼裁判的檢核，可能導致前段發生的問題，沒有浮上水面，而是到後期的組裝跟測試時，才會比較明顯。

我們先談用階段來分，這邊用四大步驟：設計->採購->組裝->測試，當然設計之前，可能還有需求分析定義這些，我們先不管，而且很多公司哪給你那麼多時間釐清需求，就弄個開發需求單，要客戶填回，需要什麼規格、性能、尺寸、接頭、溝通協議。有些客戶，他只有很粗略的概念，此時可以考慮先用最快速度做個工程原型機，再從原型機去進行討論，有時候會是比較有效率的做法。但是所有的工作還是要在專案範疇之內，專案範疇又在專案目標之下，如果客戶看了決定的方向，與初期立項的目標已經差距太遠，也是要重新檢討，並擬定新合約。

一般在跟高層檢討所有專案，常用階段軸，然後分別標示不同專案，在階段軸上目前對應的位置，有的人會加一個完成度多少%，但是因為產品比較先進(或是太老舊，拆開才發現已經不能用)，有些任務要到比較後期才會發現原來沒有規劃到，就會產生完成度不進反退，老闆會先一愣，接著發現他臉色不大好看(笑)。

即便只有單一專案在看，我個人不喜歡用階段來分，因為每一階段會設置一個階段閘門(project gateway, PG)，如果是有專案治理(或專案指揮)的單位，就會要求在各階段提交報告，如果不通過，可能專案就停止進行，或是至少要求把短少的部分先補上，不要落後太多，甚至通過的檔案要鎖住，不能再進行更動。在專案管理中，確實應該階段性的去管理進度是否達成，但是很多專案時程都非常趕，要把所有審查都做完，才能打包進入下一階段，在執行上非常不實際，很多時候都會偷跑，設計還沒完成，更別說通過審核，就要把已經確定不會更改的部分，趕緊發包採購，所以在早期能辨識出交期長的零件非常重要。但是這樣做，就失去了分階段管理的初衷，更不用說很多公司，根本沒有設立專案治理這樣的部門，在每道閘門盡到把關的責任。

如果你負責的是一件活動或發布會之類，可能沒有太大的差別，但是如果你正在開發一款沒有人做過的產品，建議你以終為始的方式思考，也就是說交付物是成果，如果要達成某個成果，需要那些資訊、材料、工具、工序。

有些人會覺得專案是否完成結案，不就是以交付物為認定基準嗎，但是很多時候，人還是會傾向以一件物品逐漸成形的「階段」來思考，這樣既是階段又是交付物的拆分，就會變成複雜且旁人難以理解的結構。

交付物是個名詞，是各種成果的結合，所以我傾向於再向下分解成名詞，所以我不會寫「優化設計」，而是「設計優化改善建議書」。那難道所有產出都應該變成一份文件嗎，在某些公司可能會說：「是的，每件事都有對應的文書(文檔)」，這個我覺得跟知識管理放在一起討論。任何的產出，它不只為了應付眼前的專案，累積起來是可以做為後續專案的參考，千萬不要忽視它的價值。

講到這裡，雖然用名詞，用交付物進行拆解，但是可能帶來兩個問題：

基於以上兩點，我後來會在名詞前加上動詞，以人們習慣的〔動詞+名詞〕型態出現。看的人大概知道如何執行，也能估算應該會花多少時間。

後來我也發現加上行動的一個好處，保護工程師。舉個簡化的例子，某天你叫小明把一個石頭往東搬十步，隔天又說要往西搬十步，第三天問說為什麼石頭還在原地，成果被行動抵銷，不能因為沒出成果就認定小明偷懶。
很遺憾，這不是一個笑話，而且曾經一再發生，也造成上下之間的對立。在軟體業，可能任何一個改動會留下log，但是在製造業，有些工作並不是凡走過必留下痕跡。在計劃表上〔動詞+名詞〕，就能看出中間因由。

不過加上行動，也有可能帶來壞處，你的成員可能變得相當被動，無法自發性思考：如果要達成某個成果，需要那些資訊、材料、工具、工序。
我實在很討厭這種，認為專案經理應該把所有事都列清楚，然後每天追著人逐項檢核，跟個保姆一樣督促孩子。但是會發生這種情形，表面上是成員的態度問題，我更傾向解讀為績效考核問題，讓工程師對公平性產生懷疑，不願意做工作範圍以外，所謂不產生價值的事；也有可能是組織架構的問題，讓大家搞不清楚到底該算誰頭上，HR就會以「都是為公司好」，「多做多學，能者多勞」之類的言語安撫，但是還是沒有觸碰問題的核心。

一般WBS炸開到第三層就好，但是有時會有再向下炸開的必要性，如果你像我碰到一個大主管，是個微管理的擁護者，或著該說他骨子裡就不相信亞洲人，認為抓到機會一定會偷懶，所以要把「超過2小時」的活動，全部列在WBS上。但是WBS規定得越精細，偏移的可能性越大，不只成員疲於紀錄，專案經理更是經常需要糾偏。我比較傾向是以一個星期為單位，這星期就是要完成這麼多事情，你高興請假，沒問題；某天下午懶懶的不想做事，我也OK。成熟的人，要能自己做決定，並為決定負責，有本事就拖到最後一天，然後連續拚24小時完成。

很多人在做計劃時，只有把合約上，必須要交付的進行計畫，卻沒有對自己在管理專案的過程，具體應該負責哪些事，產出哪些東西一併放上去。可能只會有溝通計畫，每周要開一次專案會議，結案要寫結案報告這些。但是我還是建議，既然是專案的一部份，也應該與其他事項平等看待，這樣在進行的過程中，如果碰到需要交接給其他人時，對方也能清楚了解，身為專案負責人該有的權責。如果你是以階段拆分任務，很容易就會漏掉專案管理的部分，因為你就像空氣一般的存在，很重要但是沒存在感。

為了讓每篇別那麼死硬，之後我都會在最後加一小段趣談，內容都是我夢到的，如有雷同，純屬巧合。

產品部很常要去大陸出差，人家去上海昆山，偏偏我去的城市，常令我不禁懷疑：整座城只有我一個台灣人。一天才兩班飛機，機場的門一打開，就看到一片黃的建築。當時可能有點霧霾，嚴重的時侯連對街的房子都看不見，是完全看不見。乾冷的風打在臉上，雖然有點疲憊，搭中國的國內線，延遲四個小時都不算誤點。我搭上計程車，報了酒店名字，開了一會兒到了一座橋附近，司機大哥說前方在修路要繞道，所以得加收錢，要價人民幣60元。一方面我在外的交通開銷都可以報帳，又想到在這地方起衝突，萬一對方拒不載客，扔我一人在零下2度的路邊攔車，這想想還是算了。我就回說：「50元，但是要給收據，要報帳用的」，總是多少要留點顏面，不能說什麼都完全接受。司機也答應了。
酒店入住後，我拉住一個很年輕的服務員，我問說：「從機場到這裡，一般打車多少錢?」他回：「頂多15元，要穿過這座城，25元應該就夠。你被橫著宰了。」其實用看電影「人在冏途」的心態去看待這些事，就不會有那麼不愉快。像我也曾因買不到票，只能選搭二等座，有這些經驗回想起來也蠻好的，比起埃爾法接送，我倒喜歡這種很草根味的人跟事。
順便教上一招，女孩子都應該學起來，保護自己。進飯店後拿個杯子掛在門把上，就算前台有串通壞人，拿備用鑰匙想偷偷開鎖，門把一轉，杯子肯定掉下來，至少可以起到警示的作用。