2022-04-06|閱讀時間 ‧ 約 11 分鐘

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

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

工作拆解第一式
要拆解工作,首先必須列出所有該做的,就是整理一份清單。有些工程師很排斥,覺得這文書很麻煩,但是光列出清單,就對整理思緒有非常大的幫助,同時也能釋放腦力,讓你更專注於一些需要創造力的事物。這些清單包括像是待製作物清單、待研究主題清單、待解決問題清單、待添購工具清單、打聽信息對象的清單等等。
「企劃猶如待馴服的獅子,清單則是皮鞭,使獅子乖乖坐下」 Adam Savage
這份清單應該是一份動態的文件,因為內容難免會有疏漏及重複,雖然大家都說MECE,但是面對沒有執行過的專案,初期很難判斷究竟少了什麼,而在你越接近的時候,才能看得越清楚。
小米手機拆解,取自《劉潤 2022商業洞察十問十答》
小米手機拆解,取自《劉潤 2022商業洞察十問十答》

用「階段」為基礎的拆分
如果在部門分明的組織,那基本上可以用階段來驗證工作是否完成,品質是否達標,以及是否能夠繼續前進到下一階段。但是如果設計、品管、組裝都落在同一人或部門身上,這種球員兼裁判的檢核,可能導致前段發生的問題,沒有浮上水面,而是到後期的組裝跟測試時,才會比較明顯。
我們先談用階段來分,這邊用四大步驟:設計-採購-組裝-測試,當然設計之前,可能還有需求分析定義這些,我們先不管,而且很多公司哪給你那麼多時間釐清需求,就弄個開發需求單,要客戶填回,需要什麼規格、性能、尺寸、接頭、溝通協議。有些客戶,他只有很粗略的概念,此時可以考慮先用最快速度做個工程原型機,再從原型機去進行討論,有時候會是比較有效率的做法。但是所有的工作還是要在專案範疇之內,專案範疇又在專案目標之下,如果客戶看了決定的方向,與初期立項的目標已經差距太遠,也是要重新檢討,並擬定新合約。
一般在跟高層檢討所有專案,常用階段軸,然後分別標示不同專案,在階段軸上目前對應的位置,有的人會加一個完成度多少%,但是因為產品比較先進(或是太老舊,拆開才發現已經不能用),有些任務要到比較後期才會發現原來沒有規劃到,就會產生完成度不進反退,老闆會先一愣,接著發現他臉色不大好看(笑)。
即便只有單一專案在看,我個人不喜歡用階段來分,因為每一階段會設置一個階段閘門(project gateway, PG),如果是有專案治理(或專案指揮)的單位,就會要求在各階段提交報告,如果不通過,可能專案就停止進行,或是至少要求把短少的部分先補上,不要落後太多,甚至通過的檔案要鎖住,不能再進行更動。在專案管理中,確實應該階段性的去管理進度是否達成,但是很多專案時程都非常趕,要把所有審查都做完,才能打包進入下一階段,在執行上非常不實際,很多時候都會偷跑,設計還沒完成,更別說通過審核,就要把已經確定不會更改的部分,趕緊發包採購,所以在早期能辨識出交期長的零件非常重要。但是這樣做,就失去了分階段管理的初衷,更不用說很多公司,根本沒有設立專案治理這樣的部門,在每道閘門盡到把關的責任。

用「交付物」為基礎的拆分
如果你負責的是一件活動或發布會之類,可能沒有太大的差別,但是如果你正在開發一款沒有人做過的產品,建議你以終為始的方式思考,也就是說交付物是成果,如果要達成某個成果,需要那些資訊、材料、工具、工序。
有些人會覺得專案是否完成結案,不就是以交付物為認定基準嗎,但是很多時候,人還是會傾向以一件物品逐漸成形的「階段」來思考,這樣既是階段又是交付物的拆分,就會變成複雜且旁人難以理解的結構。
交付物是個名詞,是各種成果的結合,所以我傾向於再向下分解成名詞,所以我不會寫「優化設計」,而是「設計優化改善建議書」。那難道所有產出都應該變成一份文件嗎,在某些公司可能會說:「是的,每件事都有對應的文書(文檔)」,這個我覺得跟知識管理放在一起討論。任何的產出,它不只為了應付眼前的專案,累積起來是可以做為後續專案的參考,千萬不要忽視它的價值。
講到這裡,雖然用名詞,用交付物進行拆解,但是可能帶來兩個問題:
  • 一個是對特定名詞的定義/範疇,每個人認知多少存在差異,如果是有既有文件格式,基本上不會差異太大,若沒有可套用的格式,最後結果很容易有落差,增加溝通成本,還有資料整理的時間。
  • 另一個是你有可能被主管問到某項任務打算如何執行,一般情況我傾向不干涉太多細節,也希望執行的人發揮創意,把如何執行的決定權,賦權給被指派的人。但是這個想法,可能會被認為對專案的掌握度不夠,而應該表現得更加強勢。
基於以上兩點,我後來會在名詞前加上動詞,以人們習慣的〔動詞+名詞〕型態出現。看的人大概知道如何執行,也能估算應該會花多少時間。
後來我也發現加上行動的一個好處,保護工程師。舉個簡化的例子,某天你叫小明把一個石頭往東搬十步,隔天又說要往西搬十步,第三天問說為什麼石頭還在原地,成果被行動抵銷,不能因為沒出成果就認定小明偷懶。 很遺憾,這不是一個笑話,而且曾經一再發生,也造成上下之間的對立。在軟體業,可能任何一個改動會留下log,但是在製造業,有些工作並不是凡走過必留下痕跡。在計劃表上〔動詞+名詞〕,就能看出中間因由。
不過加上行動,也有可能帶來壞處,你的成員可能變得相當被動,無法自發性思考:如果要達成某個成果,需要那些資訊、材料、工具、工序。 我實在很討厭這種,認為專案經理應該把所有事都列清楚,然後每天追著人逐項檢核,跟個保姆一樣督促孩子。但是會發生這種情形,表面上是成員的態度問題,我更傾向解讀為績效考核問題,讓工程師對公平性產生懷疑,不願意做工作範圍以外,所謂不產生價值的事;也有可能是組織架構的問題,讓大家搞不清楚到底該算誰頭上,HR就會以「都是為公司好」,「多做多學,能者多勞」之類的言語安撫,但是還是沒有觸碰問題的核心。
最後我想強調,很多方法在使用上沒有對錯,有人偏好用「交付物」拆解,也有人偏好用「階段」來拆解,只要前後邏輯自洽,且能發揮功用最重要,專案經理自己要很明白為什麼這麼做,任何決定都有它的理由,並且要注意在解決一個問題的同時,是否又同時帶來另一個問題。

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

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

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

分享至
成為作者繼續創作的動力吧!
B2B 硬體產品深耕多年,遊走於業務開發,專案管理,產品部,採購跟品管也是守備範圍,在這邊你可能會看到,硬體公司各個部門的實務(及惡鬥),還有產業軼聞,以及不為人道的秘辛。寫的時候,經常笑著笑著就哭了,沒關係,我的悲劇就是你們的喜劇。
© 2024 vocus All rights reserved.