標籤: 專案管理

對於專案管理的理論, 網路上有很多的探討. 無論是理論, 方法, 教育訓練, 證照, 書籍, 工具, 甚至甘苦談都有豐富的資源.

如果這個專案是拿現成的技術開發一個已知的東西, 那麼專案要面對到的就是資源, 規格, QA,…等等的問題. 反覆進行需求分析, 規格制定, 設計, 驗證的流程, 理論上就可以把計畫做到最好, 而且還很容易就可以 Google 得到完整的介紹.

但學生有一事不明 (相聲 "二論典故" 中令人難忘的台詞）, 為何很少看到人家討論非典型的專案呢？ 像是：1. 賽局導向的專案, 2. 永遠做不完的專案.

首先來看賽局導向的專案.

就拿 iphone/iPAD 來說, 每次的專案看起來都相當成功. 但是 non-Apple 呢？就算是規格比 Apple 好, 價錢更便宜, 但還是賣得不如 Apple 好. 所以每個開案的人只好去看 Apple 在做什麼？原本應該獨立的思考的 "需求分析" 變成了賽局理論, 主動攻擊往往變成了被動抄襲, 所以創新這東西就不見了.

大家都有 Android, 我們只好也出個 Android. 別家都有漢堡＋薯條＋可樂的套餐, 誰還敢堅持只要把漢堡做到最好, 其他都不重要呢 (Subway?)？ 光是做出不流俗的決定就得有過人的勇氣和說服力, 否則連案子都開不成, 更別說專案管理了.

所以我總覺得, 賽局毀了專案管理的第一步. 而 "一直產出不停止" 的專案, 又顛覆了專案管理的最後一步.

我們在上專案管理課程的時候, 老師都會強調: 計畫書要寫到結案才算完整. 如果一個專案是 3 個月搞定, 那麼當然也沒啥問題, 專案可以照書養.

然而, 放眼 3C 產業, 大多數產品都是以 "永續經營" (誤) 的方式在開案的. 做 PC, NB, 手機的, 常常都在複製過去的成功模式. 彷彿每個專案都是獨立的個體, 但是除了更新零組件規格, 真正的創意非常地有限. 小筆電的異軍突起算是一股清流了, 不過做著做著, 大家也曾經以為小筆電可以永續經營下去, 直到被 iPad 打到. 因此不結案的專案之一, 就是自我複製的專案.

第二種不結案的專案就是反饋太強的專案. 創業的第一代產品, 往往是求快 (time-to-market), 趕快求獲利, 以避免燒錢. 第一次上陣, 產品可以改良的地方當然很多. 第一代產品如果成功了, 第二代產品的目標很可能就是 cost down. 但 cost down 的產品往往都淪為墊檔, 因為等到東西做好, 市場的規格已經提升了.

延續這樣自我修正 – 強力反饋的思路, 產品很容易變成一代規格強一代成本低. 且不說螃蟹公司所在的 IC 設計業, 即使 M$ 的產品也差不多是這樣.

Windows 初出茅廬, 是為第一代. 第二代 Windows 乏善可成, 沒人記得它有何特色? 但 Windows 3.1 讓世界驚艷, 從此奠定了微軟的霸業! Win95 馬馬虎虎, 不過很會當, Win98 還可以用, 2nd edition 之後就變穩了. Window 千禧年版爛到世人完全忘記它. 而後來的 Win XP 不錯, Vista 很爛, Win7 挺好.

當 "永續" 專案中的每一次的產出都會影響公司營運的時候, 前後世代的專案竟然發生了交互作用, 互相影響, 這個狀況同樣超出我們平日所知的專案管理範圍. 所以我把它列為例外二之二.

和大客戶做 project 有一個煩惱的地方, 就是大家的術語很多, 而且他們不會跟我們做培訓, 只好自己去搞清楚. 為了避免麻煩, 我把收集到的術語全部列出來備用.

術語	意義	備註
Stage 1	找出產品的賣點
VPD	Value Proposition Debriefing
CRS	Commercial Requirement Specification
Stage 2	決定做什麼？怎麼測試驗證？
AA	Assignment Agreed
CVT	Consolidation Verification Test
Stage 3	正式動手
ME	Mechanism Engineering
EE	Electrical Engineering
PPC	Project Plan Commitment
EVT	Engineering Verification Test
DVT	Design Verification Test
PTR	Pre Try Run
Stage 4	產品驗證
PV	Product Validated
PVT	Production Verification Test
DMT	Design Maturity Test
TR	Try Run
Stage 5	工程樣品完成
IR	Industrial release
PMT	Product Maturity Test
Stage 6	商品化完成
CR	Commercial Release
Stage 7	出貨
FMS	First Mass Shipment

美國經濟學家舒爾茨 (Theodore Schultz) 說, 物力投資增加 4.5 倍, 利潤相對增加 3.5 倍. 人力投資增加 3.5 倍, 利潤將增加 17.5 倍. 那麼我們做 project 是不是人愈多愈好呢? 從專案管理上來說, 答案正好與此相抵觸! 原因是專案管理要達到的是有限資源下的最大產出; Schultz 的重點是最大產出下的資源需求. 一個要量入為出, 一個要量出為入.

對股東而言, 追求的自然是利益的極大化. 但是要他們繼續增資, 這就有點困難了. 畢竟從荷包裡掏錢, 手就是會比較軟. 因此在公司的管理上, 股東傾向於只做有限資源能夠做到的事, 以免偷雞不著著蝕把米, 偷一窩雞不著還倒貼一鍋飯. 公司經理人承上啟下, 於是乎專案管理大行其道. 大家對於專案管理就是 "花費有限的人力, 財力, 資源, 時間達到目標" 也都能朗朗上口. 只要目標設定正確, 也常常更新 KPI (Key Performance Index), 我想專案管理的確是兼顧股東的恐懼與貪婪的最佳解決方案.

假設股東對於技術或是生產都是無知的, 那麼他們唯有信任專業經理人一途, 而專業經理人只好相信底下的技術人員, 包括財務, 銷售與工程等等團隊. 如果大家的目標都一致, 應該也正好吻合高階經理人心目中的目標, 於是這個成果會讓整個管理團隊都滿意. 若是大家看法不同, 有人想著追求技術領先, 有人想著立刻產生盈餘, 這樣就算整體成果還不錯, 內部的滿意度應該是相當地低, 畢竟每個人的目標都沒有完全達到. 更不用說把私人的利益擺在優先地位的團隊成員, 即使是身在最完美的團隊, 還是會持續抱怨工作太忙, 收入太少, either or both.

馬歇爾 (Alfred Marshall) 提出的供需法則說到,  供給愈多, 就要買更多的設備, 請更多的工人, 因此總成本會愈來愈高.  而客戶的滿意度會隨著時間或是競爭對手的出現而逐漸下滑 (邊際效應), 導致需求下降. 為了提升供給的品質與數量, 投入的人力或是設備都需要增加. 在 IT 業裡面, 要維持原有的產能其實成本很低, 大概就是 debug 而已. 此時節省下來的人力又可以被回收在新技術上的開發. 舊技術的涵蓋面愈廣, 穩定度愈高, 可以抽調出來再利用的人力也就愈多, 因此其人力成長可能是一個憋嘴曲線 (和微笑曲線相反).

但是, 客戶滿意度終究會再度下滑. 或是套句中國的老話: 不進則退, 想要永續經營, 應該不會有只需要留 1~2 個人 maintain 這回事. 畢竟新技術應該又是高階人才密集的東西, 舊技術的初期門檻是投入 n 個人, 新技術的初期門檻將會是 "擁有新技術" 的 x 個人, x 不一定與 n 有關係, 但是這 x 個與 maintain 舊產品的 1~2人不可混為一談, 好比說以前需要會寫  c 的 N_i 個人, 後來成長到最多 N_p 個人, 最後留 N_m 個人 maintain. 新產品需要會寫 c++ 的 X_i 個人. 如果原有的 N_p – N_m 個人確實是人才, 那麼他們應該學得會 c++ 的技術, 否則就要轉職到只需要用 c 的公司或行業去. 而 n 系列技術一定與 x 系列技術在時間上是有重疊的, 因為市場的領先者必須要再度改變遊戲規則, 才不會發生 "終於被全世界都追上" 這種大悲劇.

當然, 任何一種技術都有生命週期. 等到末日降臨, 最後就會出現只需要 1~2 個人的狀況. 比方說, "拍立得" 相機終究是掛掉了. 但是從汽車業到電腦業, 這種世代交替的典範轉移似乎還沒有發生, 甚至沒有跡象要發生.