硬體產品專案管理經驗分享 - 時程 (schedule)

不論專案或是產品, 通常都有俗話所謂的 deadline 或是market window 限制. 基本上 PM 被賦予的任務就是得到目標後 (明確 or 不明確 :P 的目標都有可能), 在指定的時間內, 協調公司內外部 resource (錢, 人員, 組織), 達成指定目標. 所有的 resource 投入, 都是為了在某個時間點取得某個成果 (working sample/demo/trade show/shipping/etc). 錯過了時間點, 後果通常都很嚴重. 通常影響 schedule 最大的是 scope 變更, 但這裡不討論 scope 變更的問題.

這幾天又在 HBO 看到 "大敵當前 (Enemy at the Gates )" 這部片子, 這個戰爭電影有一句還蠻經典的對白:

Vodka is a luxury we have. Caviare is a luxury we have. Time is not.
-Enemy at the Gates, Nikita Khrushchev

意思是說, 我們可以享用 (一般老百姓沒有的) 伏特加跟魚子醬, 但是唯一沒有時間可以浪費 (Time is not luxury we have). PM 可以協調找到資源, 但是永遠缺時間. 假你錯過時間, 可能產品失敗的機會或隱藏的成本, 一般來說會呈現 "幾何" 倍數增加. 要有一個重要概念: 最後一個月追加 30% 的預算跟 delay schedule 東西 marketing/sales 預估少賣 30% 的量, 到底是哪一個損失比較大. cost 觀念不是只有 PM 要有, 同時專案裡的人對 cost 要有相同共識.

Schedule 這個東西 "看" 起來很簡單, 不過就是做一件事需要多少時間, 把所有需要的時間按照發生的先後順序調整一下就好 (跟 programming 很像, 不是嗎 XD ). 問題來了:

* 如何知道做這個軟/硬體或做這個 project 一共有哪些事情 (scope 有多大)
* 這些事情對應的 function 組織及負責人是誰
* 如何知道這些事情需要多少時間
* 如何分辨這些事情出錯造成的風險跟衝擊有多大
* 遇到問題的應變跟通知對象

這一部分其實就是大部分 Developer 踏入 PM 領域的第一項 "技術" 門檻, 因為瞭解組織跟認識 API/function block 一樣, 都需要時間跟精神. 同時, 跟 "人" 溝通不是 下 command 給電腦, 不是馬上有結果 or 每次結果如你預期一樣. 當然某個程度來說, 做產品/專案有一點像 coding, 只不過 coding 的對象是組織而不是 library. 當然, 你對組織/流程/工具越熟, 就越能有效率跟機會達成原先設定的目標. 根據不同的成長經驗, 每一個 PM 都有每一個 PM 不同的風格, 下面是我覺得一開始比較重要的:

* 了解並釐清公司內部組織跟流程規範

每一間稍具規模的硬體公司, 都會有標準的流程或是 follow 公司訂的 ISO 流程. 認識這些流程是了解硬體相關專案管理的第一步. 台灣從純代工的 OEM 到現在佔世界 3C ODM 跟 OBM 的重要地位也有幾十年了. 從微利的代工開始, 所以設計到製造其實分工很細, 流程本身相對於很多其他產業來說也嚴謹許多, 每一個細節為什麼這樣做都有其歷史原因. 一般來說, 因為其實細節太多, PM 可以了解或不了解, 不懂可以問, 但最好不要用猜的.

* 總共有哪些重要項目, 哪些時間是固定的, 例如 (但不限於):

a. 每一個階段 (EVT/DVT/PVT or 不同 flow 階段) 的 check point 時間, 跟 check point 對應的 check item 是什麼.
b. BOM 裏面的關鍵零組件備料時間 (採購通常會提出一個安全反應時間, 有一些例如: 發 PCB gerber 到交貨時間, 常都是固定的天數)
c. 硬體產品認證時間 (Lab 會評估如果 sample "軟" + "硬" 體都沒問題, 多少時間可測完)
d. 每一個關鍵硬體功能的需要驗證時間 (從發出需求給 vendor, 到 sample 驗完)
e. 採購的作業時間
f. 整合測試的 cycle time, 例如發行軟體測一個 round 需要多少時間
g. 量產從 RD 到 PE 到工廠的技轉時間
h. 工廠的前置作業時間

* 產出重要文件需要的時間請放入 schedule 中

文件通常不是交付或驗收標的物, 所以很多人就忽略文件的重要性. 一般 Follow "標準" (ISO/CMMI) 流程的專案 (如果公司跑 ISO/CMMI/PDM 的話), 會產出一堆的文件, 用這些必然產出的文件當控制點是蠻方便作法. 但是因為跑流程, 有額外的文件負擔, 許多小規模的專案, 常只產出少量文件或完全沒有文件. 因為口說無憑, 進行到後段經常會很難收尾. 如果該產出的重要文件, 我個人覺得還是要放入 schedule 計畫中比較好. 有時前面為了省一些寫文件時間, 後面會浪費更多協調溝通時間.

* 將預先設定好的 milestone, 跟必然產出的文件項目放入 project 管理軟體

用最簡單的例子: product spec 展開後可以有-> hardware design spec + software design spec, 接下來又有各有對應的 verification citeria 跟 factory test item. 這有一定會產出的 item, 可以像樹狀圖一樣依照分類 (軟體/硬體/測試/etc) 先放到 project schedule 軟體, 這樣對整個 project scope 跟各個事件的相依性會清楚很多. 當然, 如果最後畫的出 critical path 更好, 不過在現實世界的互動裡, critical path 會隨專案進行變動的 ;)

* 保持溝通透明與順暢

專案越大, 協調溝通的人越多, 溝通透明跟順暢就越重要. 透明是盡量讓溝通過程中造成的誤解減少, 原則是對事不對人, 記得傳遞訊息的目的是解決問題. 順暢是讓專案成員願意主動傳遞訊息 (不論是好消息還是壞消息). 專案進行中有意識 or 無意識自我過濾訊息, 通常是災難的開始. Schedule 很多東西是看不到的, 通常事情都是發生問題, 才能從 schedule 看到 delay. 溝通的透明跟順暢讓這些看不出的問題, 影響 schedule 的程度減少, 同時縮短下對策的反應時間.