說起來，還有人記得可憐的Eric嗎?

他曾有個專案因為一開始的定位不清，以至於後來花了很多時間累得要死卻只落得被罵的下場。 但自從那次血淚的經驗後，Eric學到教訓，並決定之後所有的專案他都要好好的準備個詳細的Project Charter(專案授權書)並取得高層的認同與授權。 他想，應該可以從此脫離悲慘的命運吧。

如此，又過了幾個月。

這次，他被授權帶領一個全新的案子。 他們公司其實一直都不大，之前大多是幫手機廠接單做些小開發或小設計。 幾年前雖然想弄些自有品牌的東西，但其實一直沒有明顯的成效。 而在新總經理上任後，更開始想嘗試些不同的東西，所以還成立了一個新的部門。 而Eric被新授權的這個案子是新部門的第一個案子，要協助外部客戶開發一台使用新通訊協定的無線基地台，讓筆記型電腦、PDA或是其他手持設備能透過WiFi的方式來連上網。 這次，當然目標就很清楚，清楚到可清清楚楚白紙黑字的寫在合約上。 甚至連規格、經費上限、專案的時間也好都因為有合約，所以詳細到似乎不可能再有爭議。 也因此，他很輕鬆容易的寫了一個完整的Project Charter。 在其中他定義了：

1.專案的目標
2.專案對應內部組織哪些長期策略與目標
3.專案完成後的交付項目
4.專案內的組織架構為何
5.資源需求
6.成本
7.以及時間

最後又花了一些時間跟高層反覆討論、說明、並確認解釋清楚，終於讓CEO大大的簽了字。 一切做完，Eric想說自己應該可以高枕無憂、遠離這些非技術的東西，好好的把心思花在案子的技術面吧？

可惜的是，專案之神似乎並沒有站在Eric身邊；案子開始才沒多久，突然Eric又一次的手忙腳亂了起來。  
開端其實是一個看似微不足道的小事。

負責一個主要發訊元件的工程師是個熱心且努力的年輕人。 他剛自學校畢業沒多久，老覺得自己沒甚麼經驗。 這次居然Eric讓他擔任這麼重要的工作，他覺得很被重視而想好好表現。 也因此，在他閱讀規格書時，他發現客戶給的規格看來似乎不太正確。 而為了確認到底目前一般規格是甚麼，他還特別花了幾天加班，翻了好些資料，努力要在工作時限內找出資料並自己嘗試解決…

在這年經人熱情的驅動下，奇蹟居然發生了!! 他努力搜尋到所有相關的規格數據；可是，為了對應這些數據他也稍微修改了一些設計。 而更了不起的是，他除了認真上進還是個謙卑的年輕人；他覺得「為善不欲人知」，想說「也就只是兩三天晚回去一些嘛，不需要特別邀功」。 所以改好設計這件事情，就完全沒有跟任何人提過。

喔，到這裡都跟Eric沒甚麼關係。 最少在這微不足道的小事後，專案又順利的推進了一個月。
大家興奮的開了模、生產了零件，部分元件發包出去請別的廠商製作或購買。 終於，第一台原型機(Phototype)嘗試要組裝了!

可是，這時大家發現出了個大問題。 因為組裝起來卻根本不能動。 看來看去好像都沒甚麼問題，但就是不成功。 Eric當然最緊張了，趕快想了解是發生了甚麼事。 只是團隊雖然急忙檢查卻一下子還不確定成因，只知道似乎是某個主要的發訊元件有問題。 這時候，組裝不起來這件事情Eric上面的直屬經理聽到風聲了，也已經差人來請Eric去辦公室解釋。

到了辦公室，Eric因為自己掌握的資料並不充分，所以沒辦法清楚解釋。 但因為害怕老闆責罵他，硬著頭皮說他其實已經掌握大部分的狀況。

「目前只是生產過程中的小錯誤，應該是元件壞了。 只要那個元件重新出一次，問題就能解決了。」
「我們還在開發階段嘛，總是會有些品質問題。 別擔心，下禮拜這問題就會不存在了」Eric這樣回報給他老闆。

老闆說，「好吧，那我給你一個禮拜，下禮拜你要把問題解決。」
「另外，晚點給我個書面報告。 我還得向我的老闆解釋哩。」

Eric答應後，也就驚險萬分的離開了他老闆的辦公室。

從老闆的辦公室回來後才發現，事情根本沒這麼簡單。 不能用的原因在於這個發訊元件設計變更後，傳遞出去的訊號無法被其他模組辨識，而其他模組是完全根據客戶原始規格做設計的。 所以根本不是Eric在老闆辦公室所謂的生產錯誤，完全是設計被改變了。 就算該發訊元件重新生產也還是有同樣問題；可是如果改回原本設計的規格雖然可以整合，但產品似乎會跟目前業界標準不相容「真奇怪，其他元件的設計人員不知道為何似乎沒注意到這問題?」Eric心裡嘀咕著。 如果現在來改其他週邊原件的規格，要從新設計不說，更還要重新生產；偏偏有些東西還是外包商幫忙做的，還要協調大家改。

Eric發現這狀況後，當下開始害怕了。 可是豪語都發下了，好像也很難一下子收回來。 所以慌亂中，他只好請了幾個要好的同事，要大家先腦力激盪想想有沒有甚麼快速的解決方式。

這場腦力激盪會議，除了Eric以外，還有Frank，以及Amy。 雖然這幾個人專案經驗並不是十分豐富(包含可憐的Eric也一樣)，但Frank是資深的採購，其中Amy則是個超會精打細算但也超好心的歐巴桑業務助理。

她在一片哀聲嘆氣的男人中，專心看著下周的審查要件。 提出了這麼一句話：「嘿，你們看你們看，也不是沒有方法。」
Amy眼睛發亮繼續說：「不如我們先拿個既有產品的機板放進去…」

Frank插嘴：「不能這樣吧!! 這種事情人家一打開就會破功啦….」

Amy打斷他：「唉呀，幹嘛這麼死腦筋? 下週的檢驗，要審查的要點只是確定實際產品的外型設計以及訊號可偵測。 又還不是很正式的審查，Eric簡報做好些應該還是可以蒙混過去的啦~~」

Amy繼續說：「要求只是這樣，那裡面放任何既有產品的機板都可以做到。 等過了這里程碑，後面我們再想辦法吧？」
「我老公的公司一些舊型機種的控制軟體甚麼的我或許還可以幫你搞到喔!」

Amy的老公是在類似公司擔任RD主管的工作。 這樣做當然是犯法的，但Amy是個常常不想太多的好心歐巴桑，平時還真滿照顧這群在她口中稱為小朋友的同事們。 但老實的Frank當然完全不能接受這種作弊的思維，所以反而跟Amy爭辯了起來。

至於在旁聽著這些爭論的Eric心想「現在時間真的不多了。」
「要重新設計根本來不及，其他的修改方法也緩不濟急，現階段似乎真也沒辦法想這麼多。」
「好吧!! 也只求能先過了這關，後面再慢慢改。」

甚至就算只是要作弊拿個別家的機板放進去，一個禮拜恐怕還不夠哩。 管理的軟體介面(這樣使用者才能在電腦上改設定)恐怕都是得重新寫過，不然要是測試時管理介面上出現別家公司的商標那像甚麼話？ 就算能”取得”人家韌體/軟體的原始檔，要改，還要測試也不是三兩天的事…想了就讓人頭大。 但時間緊迫也沒辦法，這週也只好請所有組員放下手邊的開發工作，先來做些偷龍轉鳳的事情。

還好，一個禮拜後，Eric終於弄出一個可以簡報的東西。 只可惜因為時間太趕，電腦上的管理介面還寫不週全，只有一兩個畫面可以顯示，其他根本沒時間做(事實上一整個禮拜大家幾乎沒回家，就為了做這次的簡報)。

不過，他倒做了個漂亮的簡報，最後小秀了一下實機還有介面時雖然有些亂。 但他也在會議上解釋說介面的不週全是開發階段必然經歷的一些小混亂，但最少目前已經達到里程碑的要求了。 而因為大家都很相信他，加上大家也理解開發期總會有些不夠完美之處，Prototype的產物總是有些不順利。 所以這次會議並沒太多刁難，就讓他過關了，只要求他下次要好好展示電腦端的管理介面。 甚至老闆會後還跟他大力的握了握手說：「這新部門的第一款作品就靠你啦!!」

講的Eric不知道是該高興還是該擔憂…..
可是接下來一個月，事情變得更棘手了….

 

(待續)

附帶一問，到底這整個問題的發生根源是那案子缺乏了「甚麼」呢?
如果你是Eric，你能做甚麼樣的選擇？
如果已經發生了? 或在專案前如何預防?

 

PS 故事純屬虛構啦。 但因為我都是工作空檔或是半夜寫的，寫得很快以至於有些情節或是技術上的東西可能未必全然合理。 就純做概念溝通用吧。

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。