這次專案管理的主題,想要和你分享我過去在職場上常被提出來討論
或產生歧見的三個議題。

1. 做人 vs. 做事
2. 過程 vs. 結果
3. 品質 vs. 時間


在學校,考試幾乎都會有標準答案,這樣老師才知道如何評分,
到了職場,卻很少有標準答案,到處充滿了灰色地帶和潛規則。

不過,就我的觀察,在特定的身分和立場,經歷了多年的職場歷練和過去的經驗教訓,
卻累積了許多根深蒂固的"標準答案":

  • 有關係就沒關係,沒關係就有關係
  • 老闆只問結果,不問過程
  • 出貨迫在眉睫,先犧牲品質,再事後補救

站在這些人的角度和位置,他們的理解和堅持都沒有錯。
如果能跳脫自己的原有的位置,用老闆或對方的角度看同樣的事情,可能會有不一樣的答案和做法。

當一個不可多得的機會和舞台出現,這些標準答案,也許會讓你我無法勇於做出改變和嘗試,限制了自己未來的發展,在平庸中度過之後職場的生涯。

底下,我就針對所列出的三個議題,用我過去在職場發生的案例和商業發生的事件,跟各位說明我的觀點。
相信對於剛踏入專案管理的職場工作的你,有所幫助。

1. 做人 vs. 做事

做人是建立彼此的信任,為別人加值,贏得對方的尊敬。(Earn the trust and add the values to others)
做事是發揮自己的專長,建立專業形象,贏得對方的肯定。(Do the right things and do things right)

以專案管理這個角色,面臨最大的兩個挑戰,在我認為,就是有責無權和不確定性。
而專案成敗的關鍵,在於有沒有在對的時間,找到對的人,做對的事情也同時把事情做對。
那麼,做人比做事重要囉?
這也許會讓你心有戚戚焉,對於只會出一張嘴,很會討好老闆的同事,做事品質和風評不好,位置卻做得很穩,這樣的負面例子多少會影響工作的心情。

我講講我的看法:
1. 先做人,再做事。
讓雙方可以在互信的基礎上,彼此合作
2. 愈資淺,讓做事增加你的專業力;愈資深,讓做人增加你的影響力。
用比例原則來說明每個階段做人和做事的變化:
(1) 剛進職場的新鮮人(3年內): 做事80%,做人20%
(2) 漸入佳境的職場達人(3年到10年): 做事50%,做人50%
(3) 資深老鳥 (10年以上): 做事20%,做人80%

很少職場新鮮人,一進公司就是做跨部門溝通協調的工作,或是做決策和風險管理,
大部分都是從最基本的工作和例行性的事做起,
除了部門的內部會議的討論和直接合作的同事溝通,其實很少有機會和不同部門開會或大老闆報告專案進度。

溝通者 vs. 執行者

我記得自己做了幾年手機工程師後,直屬主管開始給我訓練新進人員的機會,也開始代表部門,參加跨部門的技術討論會議,發現自己對於這個部分的工作,做得很得心應手。

那時候Windows Mobile 手機已經逐漸式微,android 已經成為主流,
部門大主管決定改組,把windows mobile 做應用程式部門的主管和工程師和併到我們的android部門,

這位空降主管負責對外溝通和開會,我的工作內容也變成寫程式和解bug為主。
印象很深刻,一周有好幾天除了早上和同事問早之後,整天都面對電腦寫程式,沒有講到一句話,等到寫好程式要請主管或同事code review,講的又是很技術的細節,見樹不見林,無法對於專案的時程、範疇和風險有全面性的了解。

我發現自己工作時並不快樂,也了解寫程式不是我最擅長也不是我最想做的事,因此開始萌生要做專案管理的念頭。

上面的案例說明了一個重要的事實,
在職場愈資深的工作者,通常扮演溝通者的角色,而愈資淺的工作者,大多扮演執行者的角色。
溝通者,要比執行者更要知道怎麼做人,而執行者要比溝通者,更要知道怎麼做事。

向上/向下管理 (managing up)的重要性

"向上/向下管理"重要嗎? 我用工作職場上發生了兩個案例,來說明。

公司有位同事A工作一段時間,發現自己和老闆雙方有代溝,
老闆是以硬體為主的思維,她講的卻是軟體溝通,好像兩條平行線,沒有交集。
久而久之,想要做以軟體為主的工作,後來她提出要轉部門,卻被她老闆回絕,告訴她如果無法留下來在原部門,就只能選擇離職。
她心懷不平,因為她的同事都認為她的表現都很不錯,但是為什麼老闆沒有肯定她的能力,給她轉調部門的機會?

因為她有想要轉調到我的部門,有跟她聊一聊,發現她的部門內部沒有例行性的會議,所有專案進度都是每周透過e-mail 寄給老闆。當她和老闆有不同意見時,她會很直接的表達自己的想法,老闆認為她不需要做其他部門的工作,卻求好心切的幫忙,踩到老闆的底線。

聽完之後,我給她一個建議,就是要試著做向上管理和溝通,定期或不定期,讓老闆知道自己工作的狀況,需要甚麼支援和請示她這樣的決策,老闆是否認同。
在同事眼中,她很會做事,相處也很不錯,但是老闆的眼中,她做事能力很強,卻常常做事方法無法如老闆的意,加上雙方沒有用對方聽得懂的語言做溝通,彼此的關係就無法產生好的連結。

另一位是我之前職場上的小主管B,他就非常擅長做向上管理,
只要是老闆的信件,他幾乎都在很短的時間做出回應(通常不會超過半小時),下班後也是如此。PM 發出來的要求和問題,他也會很快的初步分析後,指派給我們下面的工程師。
有一次老闆還拿他的出差報告當範例寄給大家,希望能夠向他多學習。

不過對於向下管理卻是負面的示範,
其他部門的主管都還是要寫程式解bug,而他只負責做工作分派和開會,不寫程式。
我們底下的人在加班時,他還是很準時下班。

這樣的做法短期內大家都看在眼裡,默默忍受,一直到組織改組,發現同事都不想要跟他,他下面也沒有人可以指派,最後他只好轉到另外一個部門,在那裡重新開始。

2. 過程 vs. 結果

在商場和職場上,"成敗論英雄"是再理所當然不過的事了。
現在我任職的公司,在會議室貼的標語的第一句話就是"最重要的是結果"。

如果是這樣,為什麼還是有人會堅持"過程比較重要呢"?
我的觀察是,會提出這樣的觀點的人,通常是建立在做出這樣的行動,需要付出很大的代價,成功的機率非常低的客觀條件下,你仍然勇敢的跨越舒適圈,即使最後失敗了,也可以從中累積經驗和能力。比如說創業,追一個條件超好的女生或很少人做的事情(比如說徒步環島、沒有政黨奧援下投入選舉或絕食抗議)

我的觀點是,採用正當和正確的過程,帶來長期正面的結果,才是雙贏的局面。

底下用兩個案例作說明: 

1. 食安問題 (黑心油事件)

近幾年食品安全的問題逐漸受到重視,因為黑心食品的使用,引起社會大眾的關注和抵制。
令人印象深刻的,就是2013年的台灣的黑心油事件,大統對外宣稱是百分之百的西班牙進口特級冷壓橄欖油,裡面卻添加低成本葵花油及棉籽油混充,摻雜銅葉綠素調色。
就結果論,這樣偷工減料的確可以帶來巨大的利潤,但是過程卻是不合法的,也欺騙了消費者。最後業者負責人也為此付上代價,被判刑12年。(資料來源: wiki:2013年臺灣食用油油品事件)

2. 禮拜天不營業的速食店,做到第一名 (Chick-fil-A)

根據2016年美國前五十大的速食餐廳QSR 50(Quick Service Restaurent)的統計調查,
每家店平均收入最賺錢的公司,是一家專門販售以雞為主食的速食餐廳(Chick-fil-A: 福來雞),2,200家的連鎖店,每家平均賺進4.4百萬,以多出1.4百萬美金營業額,領先第二名的Whatsburger 競爭者(請參考附表: QSR50 average sales per unit (Thousand) in US 2016 (Top10))。


資料來源: QSR 50


在台灣我們對於以雞肉為主的KFC(肯德基)速食店很熟悉,但在全美前50大的速食業者,規模比Chick-fil-A 多出兩千家,營業額只佔第13名,每家店營業額 1.06 百萬,也大幅落後Chick-fil-A 4倍之多。

是甚麼原因,讓Chick-fil-A有如此卓越的成績(結果)?

在我認為,是來自創始人的核心價值和採取更高的標準和作業流程,和競爭對手,產生了明顯的區隔。

Chick-fil-A 的創始人,是Samuel Truett Cathy,因為他是基督徒,
因此在星期天、感恩節和聖誕節,都堅持不營業。
同時一直致力於不銷售含有施打抗生素的雞肉為目標,預計2019年要把比例降為0。
目前官方網站的資料是已經超過70%的雞肉食品都不含抗生素。
很難想像,比起其他對手,一年有50多天不開店,逆向操作不購買施打抗生素的雞,
卻比別人更賺錢。

提供美味的雞肉料理,只是基本的服務,真正與眾不同的,正是這樣的經營理念和執行過程,獲得了美國消費者的認同和滿意。
2018年六月份的報導,顧客滿意度87分,是所有餐廳的第一名。
https://clark.com/shopping-retail/food-restaurants/chick-fil-a-best-restaurant-customer-satisfaction-2018-report/

Chick-fil-A 在乎過程,不以賺錢為目的,結果卻出乎意料的好。
也許下次去美國旅遊時,可以到Chick-fil-A 餐廳光顧,享受美食和感受其企業文化。

3. 品質 vs. 時間

在測試工程師的眼中,品質的堅持是他們的職責,扮演出貨前的最後一道防線。
但出貨前,總會有一些不可預期的問題發生,要解還是不解,就變得要在時間和品質兩個關鍵因素,做出抉擇。
我在做專案管理時,請測試工程師提出甚麼是出貨前非解不可的問題 (gating issue),
總是得到一致的答案,所有open fatal issues 都是gating (卡關).
這樣的答案只是把系統的資料撈出來,對於危機處理,沒有實質上的幫助。
一開始我會一一發信給相關單位,定期review,要盡快解決,但是沒有一次出貨前能夠全部解完。

曾經有一位專案管理者(PM) 跟我聊到如何看待測試工程師對於品質把關,不願意退讓的態度,
他很巧妙的把測試單位(QA)比喻成車子的剎車,而PM就是車子的油門。
遇到嚴重的問題,QA就要發出緊訊,就像剎車,讓車子停下來。
當狀況排除後,PM就要通知大家,這個功能恢復了,就像車子踩油門繼續前進。

但如果QA對於所有的open fatal issues,都不同意放行。
就像車子一遇到所有的狀況,就一直剎車,車子是開不遠,甚至無法前行。
這樣就只會造成產品延後出貨。

後來專案管理做了一段時間,才開始知道PM要有智慧判斷怎樣的狀況才是真正的gating.
底下從我過去產品的經驗,真正的gating,分三個部分說明:

1. 認證法規相關的問題,要第一優先處理

以Android手機為例,Google GMS認證是一個必要的門檻。
從準備測試機台到送交給Google 審核以及解決測試出來的相關問題,都需要預留足夠的時間。我記得我第一次負責android 手機軟體專案管理,CTS 問題一直到出貨前一周才解決,忘了預留一個月的時間讓Google TAM 去審核,造正常流程走出貨就會被影響。
後來是直接連絡Google TAM,請他優先處理這個專案GMS認證審核,才解決這次的危機。

另外,電信業者制定的標準,要求要通過實驗室的相關測試,也是關鍵路徑。
從手機的耗電、通話的品質、上網的速度和系統的穩定度,都要符合客戶的需求。
甚麼是限制? 甚麼是blocking issue? 在進實驗室前的pre-test,都要掌握,
然後要找到對應的窗口,在進實驗室測試前解決或討論出對應策略。

2. 客戶客製化需求的問題,改動大多不難,但容易出錯,幾乎有錯必改

客戶產品軟體開機的畫面,第三方應用程式的綁定和客人要求新增加的功能,
如果沒有放對版本或實測無法如預期的效果,軟體就必須要重新修改,無法出貨。
甚至一些使用者介面的改動,語言翻譯不正確,放入不預期的應用程式或錯誤的位置,這些客戶通常都無法接受。因此在開發初期要和客戶鎖定範疇(scope lockdown)和提前驗證這一塊,是非常重要的執行策略。

3. 使用者情境考量,和其他benchmark 產品做比較

現在大部分產品在上市前都會有"user trial",透過這些使用者反應產品上的缺點和建議改善之處。經過多數使用者的體驗,在不同的使用者情境,發現一般正常測試流程無法察覺的問題。拿其他競爭者的同級產品做比較,也是一種方法。
如果使用的都是相同的硬體規格,軟體OS也是一樣,但是效能上卻比競爭對手差,就要看是什麼原因造成的?

Bug 解的完嗎? Zero bug policy 是理想還是務實?

有經歷過產品開發的工作者,一定知道bug 是解不完的。
我們最多只能做到收斂,讓bug趨近於0。
曾經我任職的公司的大老闆,提出zero bug policy。
一開始聽起來不可能,從我實際的觀察也是這樣。
後來聽到大老闆解釋這個觀念,是要辨認出哪一個是真正嚴重的問題,
然後用正確的方法,專注把問題解決,然後再解下一個問題。
對於不是會影響到產品目前主軸的問題或是設計限制,並不在範圍之內。

所以簡單一句話,是不是真正要解的bug,由PM或老闆決定。
其實還是無法解掉所有的bug。

過去很多手機公司,採用機海戰術,造成上市時間匆促,開發與測試時間不足,
品質不穩定,但因為價錢便宜或搶先上市,多多少少有所獲利,但長期下來,給品牌形象減分
而現在開始有愈來愈多的公司,採用精品政策,像iPhone般,一年專心做好少數幾款的旗艦級手機,設計出讓人有"WOW"的感受,提供使用者真正想使用的功能,把品質做到更好。

結語: 你得要決定,甚麼時候要追隨你心? 還是要給標準答案?

2005年李開復聽從內心的聲音,從微軟跳槽到Google,卻經歷長達半年的官司,
(我有一篇文章,有專門介紹這段故事,可以點進去閱讀。
)
如果你是李開復先生,能夠重新做選擇,也會做出同樣的決定嗎?

也許會,也許不會。

我想,要依照當時候的你,能不能承受改變後所失去的有形和無形資產以及之後可能會面臨的挑戰。

做人是溝通者的基本功,做事是執行者的硬實力;
過程會影響結果,結果來自於過程;
品質是需要時間的淬鍊,時間的多少會左右品質的好壞;

這三個部分都分享完了,也許你會問,內容並沒有給出一個肯定的答覆。
甚麼時候要追隨你心? 還是要給標準答案?
這個,得要你自己決定。





Axact

Joseph Lee

放棄很簡單,堅持比較難。 已經15年的科技人生,何時會結束? 我沒有答案,但是在職場中卓越,家庭要幸福還有活出口甜,臉甜和心甜的美好人生,是不變的目標。和你們分享我的生命故事,在網路上產生正面的影響力!

Post A Comment:

0 comments: