2011年3月31日 星期四

X計劃

會議室裡老闆與幾個幹部的對話。

「關於 Overhead 的討論到此,相信各位對於部門支出的流向與計算已經瞭解。」

(老闆:得想辦法降開銷,今年度的盈餘目標眼看要出包,大老闆已經暗示要繼續砍成本,這些人到底有沒有危機意識啊! )

「接下來,我們談談X計劃,這個計劃已經完成原型的製作,雖然時程有些微落差,客戶也看過展示,到目前為止我們的投資還不算多,我想聽聽各位的意見。」

(研發部:奇怪了,老闆不是才要我加緊完成Y計劃的嗎,是怎樣,工程師斷斷續續地跑掉,又招不到新人,那來工程師做這些計劃。上次才勸了老闆,在工程師面前當好人,壞人我來當就好了。更慘的是,上次面談的人,公司能給的offer竟比人家現有待遇還差!)

(市場部:嗐!什麼叫些微落差,之前答應的東西都沒實現,客戶早就晾在一邊,不敢再連絡了。最近客戶不知道怎樣,自己送上門來的,要不然,也沒得談。)

市場部先發了第1槍。
「我要說客戶原先的需求目標已經改變了,也就是說,客戶那邊其實也是在試水溫,況且,他也有其他供應商已經ready的產品,我們勉強算是備胎。當然,我會依據現況與這客戶再溝通,另外,下星期我們會啟動其他客戶的拜訪計劃。」

「依照目前的需求,工程師已經完成設計修改,就等量產的時程進來。」研發部的報告。

「所以,目前應該沒有研發人力的投入在X計劃嘍!」

「部份的工程師還是在作些收尾的工作,還有上次老闆交代的新功能,尚未完成。」

「老闆,X計劃其實IDLE好久了,我看等客戶拜訪結束,我們還是需要做個decision。」

(市場部:上次才問了工程師忙些什麼,明明說好,達到上次會議中設定的目標就好了,那想到,老闆e-mail裡一句話,這些人忙到翻掉,更慘的是,做了一堆虛功。幾月前,就跟老闆提過,想省錢的話,最好連原型的製作也省下來,先觀望再說,但當時的決定是做下去再說,眼下看來還是又回到同樣的問題上,只是這一次需要更大的投資了。更不用說,研發部這些傢伙,不曉得還要蘑菇多久,怪的是,老闆居然從來也不問一下 schedule。)

「關於研發部進行中的Y計劃,是很重要的計劃,還是繼續執行。」老闆輕輕帶過。

(研發部:最好是這樣,X計劃最好砍了,或移給其他部門,搞那麼久,還不量產,很多細節早忘了,Y計劃又得K一大堆新東西,煩啊!)

「X計劃量產所需NRE支出,加上人力,大概是XX百萬元。」

「不要管人員支出,只要看NRE就好了,人反正就養在這邊。就這樣,客戶那邊我會去看看,機會如果在,我們還是要做,散會。」

(市場部:剛剛不是還在檢討 overhead,轉得還真快,一下子,人變成不用錢了,最好是!聽來像是工程師也沒別的重要的計劃可做,機會成本啊。依我看人是最貴的,這種計劃的NRE根本就是小錢。)

2011年3月30日 星期三

有趣的學習

這裡是有名的工業研究中心,負責項目的PM正努力地解釋該中心的立場與服務的模式。之後,PM問了一個問題:「貴公司所在產業屬工業應用,為何要進入已經夠擁擠的消費性市場,我以為工業市場利潤會比較高?」

「是這樣的,我們董事長想要投資到新領域,主要還是因為現有業務成長有限,TW人力結構出了問題吧,我們這一行竟然是人力短缺的。」

「瞭解,需要解釋清楚的是本中心的重點是核心技術的研發,一般來說,廠商會接下去作產品商業化的工作,當然我們還是有技轉之後的服務,如果有必要我們可以成立小型計劃、撥出人力為貴公司提供專門的服務。」平淡,下午的會議,總讓人失神、游離。

「是不是可以提供貴中心技轉項目及報價?」

「這類資訊在網站上可以查到的。」PM平穩地答覆。

「可是網站上的資料太簡單、重複、錯置,連絡窗口資訊也是錯誤的,恐怕有問題!」聽的出來有一點挑釁、不滿意的語氣。

當場被吐槽,只見PM臉色轉了一下,還是耐心地答應著,並解釋下一場會議即將開始,暗示送客。

會議結束後,剛剛的對話,讓我想到日前網路上一篇談銷售的文章,如後。

對我來說,這是有趣的學習。

===========================================================================
怎麼能知道自己是否具備做銷售的情緒智商呢?
我沒有考卷,臨時想到幾個問題,大家可以問問自己:

1.你覺得自己有能力在有準備的情況下給大多數人良好的第一印象嗎?

2.你在和一個陌生人交談時,能夠在30秒鐘之內放鬆自己,並且讓對方在5分鐘之內放鬆情緒,和你微笑談話嗎?(只要他不是昨晚跟老婆吵了一架或是剛剛被上司痛罵^_^)

3.你覺得自己有「不卑不亢、寵辱不驚」的底氣嗎,因為你做到第二條時的對象有可能是工廠的操作工、技術組的工程師、車間主任直至年產值數十億的廠長老總。

4.當對方心理在起著微妙變化的時候,比如從警惕到放鬆、從同意到懷疑、從聚精會神到心不在焉之類的臨界狀態,你能敏銳及時地察覺到嗎?

5.對於一件大家都期望你做好的事情,但是你自己知道你的能力必須發揮到120%才能完成,還要搭上大量的私人時間和不喜歡的人溝通,你能要求自己一往無前地做到嗎?

6.對於不喜歡你而你也不喜歡他的那類人,在他對你冷若冰霜的時候,你能始終微笑面對他、從心裡面寬容他、並最終把他變成你的朋友嗎?

7.你有被拒絕10次後仍然可以面帶微笑地踏進客戶辦公室的心理素質嗎?

2011年3月29日 星期二

一杯咖啡學到的東西

咖啡屋的小聚。

聽完專職從事科技顧問的朋友說起他怎麼幫客戶解決生產測試的問題,我的印象是,工廠內大半這一類的問題可能都由產品工程師會去解決,因為問題可能橫跨很多功能單位。

當過IC FAB產品工程師的朋友說:「Product Engineer 像 Wafer Carrier 只是拿著晶圓遊走於各單位,又被批評本職學能太差,什麼都不懂,一句話,就是沒有尊嚴。」

「公司就是要節省成本,只用很少的人,工程師做著技術員的工作,公司也不買分析軟體,只好花3個月,只好拿EXCEL寫一套給自己用,更等而下之者,則是去ㄠ設備原廠技術人員。同樣的技轉,良率就是比人家差,連原廠都搖頭。」

我說:「我的認知 Product Engineer 很重要的,Intel的Grove自傳就說他在Intel的工作就是Product Engineer,向醫生一樣,負責產品問題診斷,是很有挑戰的工作的。」

原來科技顧問值錢的地方,是他把解決問題的Know-How、觀念、方法學,配合品管工具,包裝成整套課程。有訓練課程,又有問題解決的顧問,客戶覺得值回票價,願意買單。

好處:非客制化,非一次性服務,同一套Know-How又可以重複使用於不同的客戶。

2011年3月24日 星期四

Playing Safe

「別碰那技術,上次的專案,就因此造成一堆庫存,最後傷亡慘重!」事實是,庫存可能另有原因,只不過是因採用不同的技術使得報表上顯示的金額較大罷了。

「保平安到退休,乃最佳策略」聽來像是東坡居士的無災無難到公卿。

一般的想法是風險的計算把損失控制在可接受的範圍內,但如果因風險而憚於行動,或只做100%會成功的事,那想必報酬也不大。

如果系統中的每個次系統、元件都依此行動,可能的情況:
一,系統能力萎縮,理論上,系統能力出於最弱的環節,而現在每一個環節都在弱化中。
二,系統內缺乏驅力,只能被動地被大環境壓迫,即使有,也很快的在環節中消失。
三,每次、每一環節皆取法乎下,設定保守的目標,最終系統規模開始遞減。

2011年3月22日 星期二

地震又來了

去年的好景好不容易讓大家鬆了一口氣,年初時,並且樂觀地看待2011。

沒想到才過一季,傳言中的地震又來了,這次,據說是私底下柔性的勸退。

「明天會不會輪到我?」這是很多人私下的疑問,另外,其實心裏很清楚會咬人的是那一隻。

「千萬不要答應,撐得久拿得才多!」

「那是說,如果給你夠多的補償,你就甘願地雙腳開開,還得演出很爽的感覺!」

「搞不好,你不走,你老闆只好每天把你叫來訓一頓,算算付出的代價,覺得還可以!」

「企業無情無義,人才不忠!」前半句是事實,自己得清楚是不是人才。

地震什麼時候來,很難預測,但災後症候群立即顯現,不知道什麼時候才要退去。


註:日本2011/03/11的災難報導中,有一篇文章談到當年蘇聯車諾比事件傷亡數字時,強調心理創傷後遺症的影響遠大於災難中直接死亡者。

2011年3月18日 星期五

日本技師的控訴

這幾日因為日本311地震、海嘯、核災的災情,引起全世界核能發電的討論。網路上看到一篇癌症過世的日本核電廠技師的控訴,主要論點是核能之禍害,文章很長可以看文後的網路聯結。


我發現文章內無關核能的兩件事:一為施工的是胡搞的菜鳥,二是驗收的人根本就不懂,聽來與我們對日本人「龜毛、嚴謹」的印象大相逕庭。




前日與朋友到台北一個商業用處所的裝潢工地去看,現場作冷氣設備的人似乎與工頭起了爭執,原因是送風管末端---即天花板出風口---的施做,工頭說他做了幾十年得過國家品質獎,沒看過這樣做的。作冷氣設備的則私下抱怨這些人都是「土師」不懂設計,胡搞!


再怎麼完美的設計,畢竟還是紙上談兵,到了現場或實作時,無論是來自人員溝通或是出於構想之外的狀況都有可能發生。設計人員的經驗如果不足,或準備不充份,只得在施工現場修改,無論如何,與現場實作人員的溝通、協調是少不了的。

===================================================================
素人(菜鳥)造核電
核電的藍圖,總是以技術頂尖的工人為絕對前提,做出不容一絲差錯的完美設計。但卻從來沒有人討論過,我們的現場人員到底有沒有這種能耐。 早期的工地,總是會叫經驗老道的老師父來做「班長」。他們比那些年輕的監督人員有經驗,並注重名譽,不允許錯誤發生在自己手上。但現在,老師父已幾近凋零。建設公司在徵人廣告上以「經驗不拘」做為求才條件。這些沒經驗的素人,不知道核能事故的可怕,也不知道自己負責的部位有多重要。東京電力的福島核電,曾因鐵絲掉進原子爐,差點發生席捲世界的重大事故。把鐵絲弄掉的工人知道自己犯了錯,卻完全無法想像這個錯會造成如此可怕的事故。這就是現在核電現場的實際狀況。

徒有虛名的檢查官(監督、驗收)


但檢查官通常都沒有真功夫。他們只會讀著整理完善的報告書,聽著建商的精彩報告,看著漂漂亮亮的場地,表面沒什麼大問題就判定合格。這就是核電監督的真相。


在十萬火急的事故現場,排除事故都來不及了,誰還有空去向一個什麼都不懂的三歲小孩說明現在的狀況呢?所以他們不會把檢查官放進現場,所以官員永遠是狀況外。

2011年3月13日 星期日

[BookDigest] UNDER PRESSURE & ON TIME

「e世紀軟體開發術-從軟體開發看科技管理(UNDER PRESSURE & ON TIME, Ed Sullivan, Microsoft Press)」,華彩軟體出版。

讀完書後發現兩個有趣的故事。

一是本書作者工作的軟體公司NuMega,任Development Manager,書中沒有理論性的內容,主要以作者本人的經驗,並輔以NuMega的例子說明專案管理實務上(尤其是new start-up)的作法。NuMega於1987成立於美東(NH) 兩位Founder是王安電腦員工,NuMeg1997被併購。NuMeg有名的產品是供微軟程式開發者使用的除錯工具,SoftICE,及BoundsChecker(runtime error detection)等。 後來原創辦人又開辦mindreef,作SOA(??)相關產品,2008 年賣掉。有些原NuMegam員工後來又加入mindreef,這些人除了戰功彪炳、留名青史外,大概都荷包滿滿。

第二個故事是一家台灣軟體公司,原來本書是微軟出版品而台灣中文版由華彩軟體出版,我從微軟官方網站只找到原文版而無中文版,隨意Google一下發現原來華彩軟體早在2002年因財務問題被大股東(台灣工銀及東元)指控涉嫌掏空公司資產,最後公司負責人、財務長皆遭法院判刑。

網路上一篇文章「戰敗將軍興亡錄」說華彩軟體總計花掉的現金可能高達二十五億元(東元三億五千萬元、工銀二億九千萬元、中視二億六千萬元,及銀行貸款的十七億元),那真是美好的年代( 2000 internet dotcom bubble )。

=================================================================================
  • 優異的定義:
    • 專長
    • 承諾:專注、犧牲
    • 態度:活力、正向、鼓舞、適應
    • 行為:多走幾步
    • 團隊技能:合作,分享,質疑,協助,激勵
    • 渴求知識
  • 人員的貢獻分成三類:最核心、核心、核心外,並依此給予獎勵。
  • 團隊
    • 核心(專案管理,軟體管理,品質管制,用戶訓練,人因工程,發行工程)
    • 支援(產品管理、行銷,軟體支援,測試行政)
  • Schedule Arrangement
    • 定義需求,適用模型(UI),技術可行性(原型),時程,執行
    • Balance
    • Task partition and schedule estimate, 1~2Weeks
    • 重視廣度勝於深度,同時發展系統的每一個部份
    • 不是所有的人都可以互相替代
    • 人員 loading/utilization 100% impossible, 100% ~ 90%
    • Buffer for critical task
    • Target Date -----Resource, Feature, Committed Date
    • Credit of development team 
    • Function: Must Should Optional
    • Baseline: in & lt 2~3 Weeks
    • MileStone: Integration and Stabilization, 1~2 Weeks
    • External MileStone: Alpha, Beta, RC, RTM(release to manufacture)
  • Control
    • Status report and meeting: Daily and smoky test, Issue, Share, Focus, walk the walk
    • Fact oriented, not over analysis
    • Change: What if I don't do it
    • Pressure: Baseline or Milestone missing, external request
    • Overtime: Deadline, Comfort, Encourage, Reward
    • Definition of COMPLETE/DONE
    • Support/Logistic: not to be a BOTTLENECK/HUB of the team
    • Nothing Perfect, 人性弱點
  • Beta Test
    • Set up function domain, duration
    • Issue publish
    • Keep record of feedback
    • Follow up