Shunze 學園 >同班同學 >佑邦通訊 > 《轉載》獨孤木專欄 之 People Management 哈囉,還沒有註冊或者登入。請你[註冊|登入]
« 上一篇主題 下一篇主題 » 顯示成列印模式 | 增加到我的最愛
發表新主題 發表回覆
作者
主題
yonkov
班導師


註冊日期: 2003 10
來自: 火星
文章: 51

yonkov 離線
《轉載》獨孤木專欄 之 People Management引用回覆 編輯/刪除文章 搜尋由  發表的其他文章 回報給版主 IP 位置 回此頁最上方

《轉載》People Management(上)

假設你是公司的高階主管,為了縮減這一季的費用,來讓損益表好看一點,
以便於讓你手上高額的stock option更值錢。因此你推行了費用刪減計劃。
目標當然是瞄準最大宗的薪資費用啦。經過你睿智的決定,決定一律砍25%。
此計畫一出,果然屍橫遍野,不但員工薪資費用立刻下降25%,還有許多
員工紛紛遞出辭呈。如此一來,削減費用當然獲得了偉大的成果。這時候
專案經理布魯斯跑到你的房間。

布魯斯:至高無上的主宰,我該怎麼辦?我手下最好的五個好手,柏德,
強森,歐尼爾,馬龍,跟喬登都提出辭呈了,這樣下去,我們delay超級久
的地雷專案一定會再度delay了。全知全能的老闆,我該怎麼辦呢?

在這個性向測驗回答『A.什麼?五虎將全部都要走喔,那公司完了嘛,我
也要辭職了。』的人,這種人缺乏正面積極的工作態度。只能當工程師,
或是在組織圖上完全看不到的基層職員。

回答『B.看來我錯了。這個措施有一些不好的邊際效應。可是這是每個主
管都會犯的錯。』的人,適合在香港努力拍武打片,到好萊塢當大明星;
或是擔任美國總統,找女實習生來退火。基本上這種人在市場上的前途大
好,不適合在企業裡面任職。

回答『C.我來找找公司裡面還有誰可以解決這些問題,此外我會先試著把
這些人好好談談,勸他們留下來。』的人適合當project leader(不是manager
喔),這些人會願意拿比較少的薪水,掛一個很呆的頭銜,就可以為公司賣
命。是要努力利用的員工。

只有回答標準答案『D.我知道你有很多問題,不過,你有沒有什麼backup
plan?』的人,才有資格擔任公司的高階主管。只有高手中的高手,主將
中的主將才可以臉不紅氣不喘地,把他所創造出來的問題,絲毫不露任何
痕跡地,推到部屬的身上。

所以專案經理都應該為下列事情規劃backup plan:

*公司可能會遭到恐怖份子駕飛機進行自殺攻擊,以致於整個專案小組成
員全部殉職。而所有的source code都隨著大樓被炸毀了,完全沒有備份。
請專案經理想出如何在72小時之內,趕上原有的進度。

*有三隻怪獸正要入侵地球,可是無敵鐵金剛的駕駛柯國隆先生已經接受
了優退方案,所以不會繼續在卡通片裡面工作。因此現在只剩下木蘭號可
以防衛原子光研究所。可是木蘭號的駕駛莎莎小姐,今天因為生理期疼痛
不已,所以她請了生理假。為了宇宙的愛與正義與和平,請想出如何在沒
有駕駛的情況下,以兩顆木蘭號胸前的木蘭飛彈擊退三隻凶狠的怪獸,以
保衛全地球的安全。

好吧,有經驗的人都知道,沒有人會去做全部組員都罹難的這種backup plan
。這多難寫啊?大部分的plan,都是建立在有些人願意留下來的假設上。軟
體公司如果要能長久發展,怎麼讓人才願意留下來,會是非常重要的關鍵。

project做到一半,如果有關鍵人物要離開,剩下的人,通常就會開始一段
刻骨銘心的旅程。當然,這是在這些人還願意繼續留下來的假設之下才會
成立。做過專案的人都知道,任何一個成員,如果在事情做到一半的時候
離開,接手的人即使花加倍的力氣,都還不見得可以在原有的時間內把事
情做完。

如果是這樣的話,如何做好people management,讓有才能的人可以放到適
當的位置,並且願意留下來,就應該是高階主管最重要的任務。(作者註:
後來我想一想,帶領公司往正確的方向發展,可能會比這件事還重要一些。)

不過對於大部分的公司來說,people management都是很弱的一環。找不到
適合的人才,找到了人又待不久,高流動率似乎是這個業界的常態。在優秀
人才這麼稀少的狀況下,照理說要怎麼樣讓這些優秀的人才發揮最大的功用,
就應該是件很重要的事情。不過對於大多數的公司來說,在people
management方面,做錯的事情遠比做對的多。因此我想在這章談談我所觀察
到大多數公司在於這方面,常見的一些問題。

** 壓力越大,生產力越高 **

對於很多主管來說,壓力跟生產力之間是成正比的。壓力越大,生產力就越
高,這就跟越用力拍打皮球,皮球就會反彈的越高是同樣的道理。當然,邏
輯能力比較好的人馬上就會發現,把兩件風馬牛不相干的事,扯在一起類比
,這需要非常小的腦容量。還好對於大多數主管而言,這一點並不是問題。

在某次整個開發團隊的status review meeting中,我們聽到這樣的對話。

吉娜 :布魯斯,我從你的status report中可以看到,你打算把上線的日
期往後延兩個月。可是我看你的team,根本下班時間一到人就都
走光了,從他們的time card看來,根本就沒有人在加班嘛。你是
不是該給他們一點壓力?

布魯斯:整個project team經過前一段時間的趕工,現在士氣已經很低了。
我並不想在這個時候給他們壓力。

吉娜 :喬安娜(客戶部門主管)已經打電話告訴我,他們打算禮拜六日來陪
你們加班。晚上還要幫你們準備晚餐,還要幫你們準備睡袋,這使
我不得不正視這個問題。如果我們都沒有人可以配合加班的話,他
們一定認為我們的工程師沒有紀律。俗話說的好,『沒有功勞,也
有苦勞,沒有苦勞,也有疲勞。』如果喬安娜對我們有這樣的期許
,我們一定得要做出回應。這樣雖然看起來project的delay已經是
事所難免,可是最少在客戶面前,我們還是可以表現出我們的專業
與用心。

布魯斯:好吧,我可能會安排大家輪流晚上留下來加班吧。禮拜六日我會自
己到場湊人數…

吉娜 :話也不是這樣說,你還是要想辦法多給他們一點壓力啊,把生產力
都給擠出來。

布魯斯想,又不是在擠牛奶,如果牛已經沒奶了,一直擠會被牛給踹死。更
何況是人:…

從上面這個例子看來,當管理階層找不到比較好的事來改善生產力時,就會
傾向施加壓力,讓專案成員無止盡的加班。這樣一來,即使到最後失敗了,
最少也死得比較好看一點。這通常就是主管們,會莫名其妙地施加壓力最主
要的理由。

我們小時候讀古書,有讀到一句話:『取法乎上,僅得乎中。』很多主管對
於這句名言的解讀就是,如果你把deadline設成一個不可能完成的時間,那
麼即使你沒有達到這個完美的deadline,事實上也不會晚太多。根據同樣的
推論呢,只要我下定決心要成為一夜千次郎,即使我沒有達到這樣高的
service level,還是可以順利地晉升為一夜十次郎。

工程師天生就喜歡挑戰。如果你詳細觀察工程師的生態,你會發現,任何時
候你想要工程師主動去解決一個問題,只要宣稱這個問題根本無解,或是說
你找了非常多的高手,大家一點頭緒都沒有,真正夠格稱的上是工程師的人
,就會捲起袖子,開始動手來解決這個問題。

因為工程師有這麼奇怪的天性,所以很多主管就覺得『取法乎上』這種做法
應該所以是很可行的。只要我宣稱這個deadline是不可能達成的,就會有工
程師願意焚膏繼晷的努力工作。通常會得到這樣的推論:『如果我們施加壓
力,例如設定一個不可能的deadline,這樣子一定可以產生激勵作用。壓力
越大,生產力越高。』

關於這個問題,科學家嘗試做過適度的電擊是否會增加生產力的人體實驗,
不過在找不到願意參加實驗的自願者之後宣告失敗。在找不到人類的情況下
,他們做了動物實驗。電擊老鼠以後,的確會跑的比較快,不過會有一個副
作用是老鼠也會死的比較快。

關於施加壓力是否可以增加生產力,歷史上也有很多例子。比較有名的例子
算是韓信的背水一戰,士兵因為不想掉到河裡而努力作戰,結果後來就打贏
了。很多主管也認為可以效法這種做法,所以通常就會在原本已經艱困的環
境下,製造更多的障礙。例如要求一個非常不適任的專案經理,來帶領一個
已經快要滅頂的專案。

然而結果通常是出乎他們意料之外。最常看到的結果是員工的辭職風潮像旅
鼠的大規模遷徙一樣。員工有了危機意識,發現苗頭不對,絕對不會去想怎
麼樣拯救公司,而是會開始去寫履歷表。所以你會發現許多主管會嚷嚷,怎
麼這年頭年輕人一點抗壓性都沒有…

施加壓力通常會有很短期的效果,生產力會迅速上升一陣子。問題是如果持
續的施加壓力,生產力就會降到一個穩定的水平。等到有人受不了時,生產
力就會開始往下降。一直到有人受不了而離職時,團隊的生產力就再也回不
來了。

<智力測驗> 現在有一個大型的project正進行到一半,然而此時有關鍵人
物正醞釀離職,請問剩下的工作會由誰分擔呢?請問有能力找到更好的薪
資待遇的人是否會願意同甘共苦呢?

答案很簡單,能力好有地方去的人早走了,只有沒有地方去的人,或是平時
就喜歡被滴蠟燭,被人用皮鞭抽打,具有自虐傾向的人,才會願意留下來收
尾巴。

當然施加壓力還有另外一種做法。基本的想法,就是繃緊的弦容易斷,所以
要用的時候就要繃的很緊,不用的時候就可以放的很鬆。這個方法的好處是
通常施壓力只有一個很短的時間,所以會有一段生產力突然往上升的時期。
最常施壓力的時候,也是某個里程碑接近的時候,一旦達成某一個里程碑以
後,生產力通常就會直線下降一陣子。一般而言,在這樣專案下的團隊可以
存活比較久,可是如果當你開始嚴重落後進度時,一旦上緊發條,可能就只
會越繃越緊。

我個人是覺得施加壓力其實負面影響非常大。每個人的生活不會只有工作而
已。你還有家庭、愛情、友情、健康…很多個層面要一起考慮。在工作上承
受了過大的壓力,以致於沒有辦法兼顧生活的其他層面。長久下來,員工一
定會走人。

況且施壓力在短時間內meet某一個milestone,通常會需要付出長期的代價。
才會得到相同品質的產出。最常被縮減的時間是什麼?測試。接著呢?答案
是detailed design。這些流程的刪減,通常可以讓你在比較短的時間內,就
把coding完成。要程式設計師交出一個長的很像可是骨子裡全然不是那麼一
回事的東西,通常不是什麼難事。Meet某一個milestone,可以讓你有個像是
系統的東西,來完成對於某些大頭目的demo。可是接著要付出的代價通常都
非常慘烈。做專案就像是跑一百公里的馬拉松一樣,才過了五十公里,就開
始用百米衝刺的速度前進,一定會心臟病發。

當然,有些人會用這樣的論點來推論。如果你這一百公尺可以保持這樣的速
度,那為什麼你下一百公尺不能保持這樣的速度。你應該要有discipline。
如果你這兩百公尺可以保持這樣的速度,為什麼你這一公里沒有辦法保持這
樣的速度?為什麼你沒辦法整條路都保持這樣的速度?好吧。聽到這種話的
話,deadline就會是你真正的死期了。先幫自己買個保險吧。你們專案在時
間內做完的機率絕對比樂透中獎還要低。

** 數字管理 **

雖然數字不會說謊的,可是解讀數字的人會。所以怎麼引用正確的數字,推
導出根本無關的結論,就是一門很高深的學問。

我們在估計專案大小,或是報價時,最常用的單位就是man-month。也就是一
個人努力做事一個月的生產力。然而使用這個數字,卻會有很多不好的效應
發生。第一個就是直接會有人月= 生產力的推論。

**人月 = 生產力 **

對於很多使用者來說,如果專案進度delay了,最直覺的想法,就是要求加多
一點人手。對他們來說,寫程式就跟蓋房子一樣。大部分的客戶都不知道要怎
麼蓋房子,當然也不知道要怎麼寫程式,可是感覺起來,好像多找幾個人,就
會比較快一點。跟建築業比較不同的是,客戶通常還會希望能夠找到幾個比較
強的人,希望透過這些人的加入,可以加速整個專案的開發。對於客戶來說,
人月是跟生產量成正比的。

軟體雖然算是蠻新的工業,不過關於這方面的討論,大概也有三四十年的歷史
了,畢竟schedule delay,一直都是軟體產業被人詬病的問題。很多學者做過
研究,發現人月是跟生產量不一定會成正比。有些讀過書的人,就會聽過所謂
的人月迷思:

『Adding manpower to a late software project makes it later.』
(作者注:引自The mythical man-month. Chapter 2 page 25)

簡單的說,就是當project已經delay的時候,加人手不見得可以解決問題。主
要的原因有幾個:

1.新人需要時間學習才能上手
2.新人一開始參與的時候,會需要對這個系統有經驗的老手來加以指導,這會
減少老手投入開發的時間。
3.人數增加後,溝通的成本會呈幾何級數地增加。
4.生一個孩子要花十個月,即使找來十個人,也不可能一個月就把小孩子生出來。
5.人數變多了,可是現在可以讓他們做的工作一下子沒有這麼多,專案經理得要
想辦法生工作讓這些人都有事做。這樣子反倒會讓專案經理沒有心力專注在真
正該做的事情上。

6.如果有人沒事做,就會很害怕自己被裁員,就會做一些看起來像是工作的事情
。或是做一些抵銷別人工作的事情。

所以呢,有讀過書的主管(或是有聽過的也算)就會知道,增加人手只有對於那種
人手超級不足的專案有效。這就是大名鼎鼎的人月迷思。所以呢不可以一開始就
主張增加人手…即使要也是等到客戶要求以後再說。

好吧,我們可以不要一昧地增加專案的成員數目,可是我們還是要針對專案進行
規劃啊,不然怎麼估計出schedule與成本呢?所以通常就會先把現在有空,可能
可以參與這個專案的人列出來,假設這些人都會參與這個專案。然後開始進行規
劃。

這下子問題來了,每個人工作能力都不一樣。所以用人月來估計工作量怎麼克服
這種能力上所造成的生產力差異?有兩個菜鳥,應該跟兩個專家不一樣才對啊。
所以就會有人開始量化所有東西。例如超人的能力超強,所以他工作一個月,就
會有十個人月的生產力;可是溫蒂就不同了,她這麼菜,工作能力這麼差,工作
一個月大概只有0.142857個人月的生產力。

結論就會是:如果超人沒有辦法接這個案子,我們就找十個凡人來就好了。

你可能會argue,超人這種大師,絕對擁有自己獨到的創見與充分的經驗。畢竟
一個莎士比亞這樣的天才,不是十個凡人加起來就可以取代的。

沒錯,不過這表示你沒有掌握管理這門藝術的精髓。

吉娜 :超人,我知道你很忙。沒有辦法全程參與這個案子。可是我們現在已經
火燒屁股了。我想了很久,我想要麻煩你每天,抽出半個小時的時間,
來教導這十個平庸的programmer。我不求他們有你一半的功力。你可以
把你一甲子的內力傳輸給他們一點點,只要他們每個人有你十分之一的
功力就可以了。我想你每天再花一點點時間指點一下他們的迷津,就可
以讓他們用十個人的力量,來彌補你沒有辦法join的生產力。

超人想,我要花多少時間,才能讓每個人都有我十分之一的功力啊?可是…我還
能說什麼呢?:臣當鞠躬盡瘁以謝先主知遇之恩。

主管最常用的手法,就是讓超人在各個專案之間流浪,想盡辦法把他榨乾。於是
乎久而久之,宇宙間就會又多了一個累死的諸葛亮。主管常做的事情,就像是不
讓莎士比亞自己去寫作,而是找十個二流的作家,要求莎士比亞去教導他們,期
待他們在分工合作之後,可以寫出相同的文章。

你覺得好笑嗎?數字可是不會說謊的喔。

用數字來表示生產力,最大的問題就是人的生產力被一個數字來代替,完全沒考
慮到團隊中比較人性的層面。布魯斯跟大衛合得來,可是布魯斯就是跟尚恩合不
來。人與人之間長久工作的默契,以及因為相處以及共同的信念所產生的化學作
用,都會影響一個團隊的整體表現,這些東西都很難用數字來量化表示。

另一個問題就是人月會跟成本化上等號。

人月 = 成本

對於很多懂會計的人來說,他們可能沒聽過The mythical man-month。可是每個
人每個月要領薪水,員工的戶頭會多一筆錢,公司的戶頭會少一筆錢,這是千真
萬確的事實。所以人月就會等於成本。

專案人力總成本 = Σ專案成員月薪 * 支薪月數

一增加人手,專案成本馬上就提高。所以除非增加人手可以讓專案開發加速,降
低支薪的月數,否則專案成本一定直線飆漲。

既然隨著資訊的發達,所謂的人月迷思已經被很多資訊業界的主管聽到了,所以
呢,他們已經在實務上研擬出一套還沒聽說有什麼不好的對策。

這套對策通常包含下列兩個步驟:

* 增加每天上班工作時間

* 將非工作日改成工作日。

這個策略的假設在於『增加專案成員的工作時間,能夠生產出來的有效產出也
會隨之增加。』用簡單的話來說明就是:『想盡辦法操死現在這幾個鳥人,要
他們無止盡的加班,就可以把進度給趕上。』

台灣大多數的軟體公司,都會宣稱是採取責任制,通常還會伴隨著不是很嚴苛
的打卡制度。這個制度的特點就是公司會宣稱他不在乎你一天工作幾個小時,
只要你把事情做完就可以離開公司,所以不會有任何加班費。接著你的老闆會
給你一天絕對做不完的工作。然後要你在一天之內把事情做完。所以一天工作
十幾個小時是家常便飯。

另外一個策略,則是會想辦法要求你假日到公司加班。有些主管會採取溫情攻
勢,有些則是採用高壓政策。反正就是威脅利誘,要員工無償到公司加班。

這個策略對於老闆來說,顯而易見的好處就是

1.不會有人數增加後,溝通的成本增加的問題。因為被操的都是同一票人。
2.沒有需要訓練新人的問題,也沒有任何老手的時間被浪費在訓練上。

因為有無償加班這回事,每天工作二十小時,就算後面這十個小時產出只有
原先的一半,那也有十五個小時的產出。所以只要逼員工加班,支薪月數應
該可以降低,所以成本可以下降。

這種做法無異是殺雞取卵,可是通常都要等到大牌中的大牌,被工作壓得粉
身碎骨,只好提出辭呈後,才會有人出面摸摸頭。要你不要工作的太辛苦。
畢竟在軟體公司裡,大多數人的真正價值,只有在他提出離職申請時才會顯
現出來。你只要還沒有想走的念頭,都不會是一個值得頭痛的issue。

當然有人不會單單從加班費來思考,而會從另外一個層面來推論:
如果我們可以用便宜的人員來開發,一定可以減少開發的經費。

吉娜:布魯斯,聽說大陸的薪水大概只有台灣的五分之一。CEO已經指示日後
我們的專案要全部outsource到大陸去。這樣一定可以降低我們的開發成本…

異地開發的壞處很多,即使現在internet非常發達,很多事情不在同一個辦公
室,大家對於工作的態度與品質的看法不同,就是一個很難跨越的鴻溝。然而
大多數人,只看到遍地便宜的勞工,異地開發的成本,常常會被嚴重地低估。
開發軟體需要非常緊密的溝通。異地開發可以省下來的費用,可能是要拿很多
無形的東西做代價。表面上看起來公司會因此而賺到錢,可是除了有形的人員
出差到另一個國家要花的旅費與薪資加給以外,花在彼此溝通的時間與經費,
花在架設相同的開發測試環境的精力,這些被派到異地出差的人,可能會受不
了長途跋涉就有了離職的念頭,或是開發時間因為異地開發以至於拖長了好幾
倍的時間…這些不良的效應,常常都會被忽略。

另外一個負面的效應,則比較少被提到。如果外國的工作者會搶現在公司裡面
成員的飯碗,現在你所僱用的這夥人,心裡面會做何感想?Hello,外國人,
歡迎來搶我們的飯碗?更不要提一旦專案出現狀況,出現在兩地之間的爭吵,
諉過,相互攻訐…

除了使用便宜人力來異地開發以外,另一個常常有的推論如下:

如果員工沒有處於忙碌狀態,這等於是公司花錢請他來當大爺。這就會造成資
源的浪費,這個員工簡直就是在搶公司的錢。所以每個人必須在上班時間內,
隨時處於忙碌狀態。

結論通常就是:Keep everybody busy。

(待續)

2003-10-15, 17:53 yonkov 的個人資料 把 yonkov 加入好友列表 發送Email給 yonkov 瀏覽 yonkov 的網站 MSN : yonkov@mail.com
yonkov
班導師


註冊日期: 2003 10
來自: 火星
文章: 51

yonkov 離線
《轉載》People Management(中)引用回覆 編輯/刪除文章 搜尋由  發表的其他文章 回報給版主 IP 位置 回此頁最上方

《轉載》People Management(中)

Keep Everybody Busy
------------------

吉娜:布魯斯,我看那個溫蒂,上班時間一直在玩ICQ,下班時間一到
人就跑得跟飛的一樣?這樣不行喔。

布魯斯心想,溫蒂不是在寫操作手冊的嗎?系統根本就沒有寫好,她要
忙什麼?況且她已經去支援總機啦。:我會跟溫蒂好好討論這個問題。

吉娜:我們不允許有人idle。公司的財務這麼吃緊,每一分每一毫都要
妥善運用。如果有一個人idle在那裡,公司等於就少了一份生產
力。這樣我們怎麼對股東交代呢?

我小時候也覺得這種理論是正確的。領人家薪水,本來就要在上班時間
鞠躬盡瘁嘛。所以要讓每個人都要發揮最大的生產力。問題是經驗越多
了以後,就越不這樣認為。我通常看起來最沒有生產力的時候,都在思
索一些可以改善生產力的問題。有些時候花太多時間去做,就會花太少
時間去想。此外,對於最沒有生產力的員工來說,你最沒有辦法找事情
給他們做。因為什麼事情他都做不好。

為了要讓這些人不處於idle狀態,你要找個有經驗的人來帶他。結果就
跟找個人揹個六十公斤的沙包去跑步一樣。沙包是會跑了,可是終究是
個沙包,一放下來就不會動了。

那也就算了。問題是這個揹沙包的人就會鐵定跑不快。跑久了還會陣亡
。所以有些時候,讓沒有能力的人閒著,其實對於整體生產力是有幫助
的。況且如果manager的重點都擺在怎麼讓這些沒有生產力的人發揮生產
力上面的話,他就不會有時間花在怎麼讓這些有生產力的人可以工作的
更好,更愉快。這對團隊會是好事嗎?我不這樣認為。

另外一個keep everybody busy的壞處在於

公司會試著同時接下超出他產能可以負荷的工作。以追求每一部份的資
源運用的最大化。

因為工作總會有要交接的階段,軟體開發尤其是如此。分析做完了做設
計,設計做完了以後就寫程式寫測試個案。系統分析師寫完分析文件交
給下一關以後,就會比較空閒。通常我們就會幫他另外找事情做。所以
通常就會有很多個專案同時在進行。

為了要不讓任何resource idle,如果有一個專案的schedule發生變化,
就會有人暫時沒事做。所以通常就會接下超過現有人員可以承受的專案
,這樣就可以確定任何時候,每個人都有事情做。所以呢,我們就會有
一個超出我們產能的需求要去滿足。而resource就會隨著工作的進度變
得紛亂,到最後變成嚴重不足。

Resource不足時,你就會讓比較貴的人力去做比較廉價的工作。所以高
階主管變成要自己等候在影印機前面去影印,因為沒有工讀生可以使喚


在有工讀生的年代,影印一張紙的成本等於租影印機的成本攤銷,加上
工讀生的薪水。現在影印一張紙的成本,等於租影印機的成本攤銷,加
上昂貴工程師,甚至是高階主管的薪水。這好像怎麼算都不划算。問題
是在資源不足的情況下,這種事情總是一而再再而三的發生。而我們從
損益表上,只會看到砍掉了一個工讀生的薪水。因為那些砍不掉的人,
薪水會一直掛在損益表的費用部分。至於他們領薪水做什麼事情,這不
是損益表關心的重點。

Keeping everybody busy的最後一個壞處在於multi-tasking:

「一個人在同一時間內,要處理多個不同的工作。」

Multi-tasking
-------------

開發軟體其實是一種經過思考然後消化的活動。一個人必需要花時間
去了解並思考目前所面臨的問題,依照你的經驗,去整理你的想法,
最後以各式各樣的模型,還是程式語言,來描述這個轉化的結果,才
能順利地找出解決方案。這跟做愛差不多,你需要培養情緒,經過前
戲愛撫之後,加上身體健壯與感官刺激雙重配合之下,才能順利地做
完你想做的事情。

然而對於某些關鍵的工作來說,我們常常會需要某個重要的超人參與
專案的開發。問題是超人通常都忙著拯救世界,所以多半只能在很短
的時間內,蜻蜓點水地幫忙一下,或是指點一下迷途的羔羊。這個時
候問題就來了,對於客戶來說,如果發現超人只是偶爾拯救一下地球
,馬上就會有不斷的抱怨。

如果一個應召女郎,跟客人辦事到一半,忽然說:『對不起,我要轉
檯,隔壁桌來了另外一個老主顧。』就硬生生地中斷這個快樂的過程
,跑去接待另一個客人。你想這個客人會高興嗎?還會高興地付你錢
嗎?有經驗的人告訴我們,最少你也要完成一整個回合,才可以抽身
。否則等你回來時,雙方還得要重新培養情緒,才有辦法繼續辦事下
去,更不用提心裡的那股不爽了。

然而在許多軟體公司裡,就是不停地上演這齣戲碼。他們先打著美女
的招牌,要求比較好的價碼,等到要辦事時,再派一個年華老去的大
姊來陪你。每次客戶問美女在哪裡?軟體公司就把美女找來坐坐檯。
這也就算了,更狠的是,他們還要求客戶準時付美女加上大姐的坐檯
費。

對客戶而言,這種軟體公司,就好像拿了錢,可是跟你做到一半就落
跑的小姐一樣可惡,等到下一次機會來臨的時候,又需要經過漫長的
前戲,才可以挑動已經冷卻的情慾,這不是令人十分不悅嗎?

即使是對於公司內部的開發團隊來說,老實說,也是同樣受傷害。只
是內傷在心裡,外表看不太出來。對於這些想要聆聽教誨的專案成員
來說,才剛開始覺得有一些領悟的時候,佛祖就跑去別家弘法了。下
次相逢,已是千載以後。這樣子怎麼了悟呢?

所以呢,我們不能忽略專案成員的轉換成本。一般人要把心思轉換到
可以很快地學習超人的想法,是需要一點前置的準備時間,還好除了
超人以外,其他人的時間其實都可以浪費。所以這些凡夫俗子可以花
比較多的時間調整心態,做好接客─不是,是學習的準備。平時多多
研讀經書,佛祖駕臨時,可能會比較容易頓悟。

然而對於超人來說,難道他就不需要任何調整與準備嗎?或許偶爾幾
次的轉換,是不需要太多的前置作業時間來準備。可是如果你讓他同
時在多個專案之間游走的話,還想要一直維持高昂的生產力的話,這
就跟要求一個男人需要連續來個十次,中間還不能有任何低潮一樣地
不可能。更不要說這些專案可能會散佈在不同的地點,同時接太多專
案的話,他有可能會需要從一個地點趕著到另外一個地點去,光是這
些交通時間累積起來,就會是相當可觀的資源浪費。

另外一個嚴重的影響是在於整體的等待時間。超人沒空時,其他人就
得等。其實不只是超人所負責的工作,有些工作只要一delay,project
鐵定就會delay,像這種工作都是等不得的。所以只要這些工作一有些
閃失,專案的開發時間就一定會拖得很久。接著整個專案的開發成本
,一定就會跟火箭一樣一飛沖天。

問題是如果一個人同時間接了很多工作,很容易就會因為分身乏術而
拖垮其他專案的進度。例如某甲可能有A、B、C三個專案的工作。每個
工作都要做10天。他做了專案A5天以後,B這個專案的PM跑來找他,要
他趕快去做B。所以他就做了B專案5天。接著是C專案的PM也來找他,
要他幫忙C專案解決問題。所以他就做了C專案5天。接著專案A的PM就
跑來追殺他,他就再花5天把A專案做完,同樣的戲碼上演下去,他花5
天把B專案做完,接著再花5天把C專案做完。

讓我們看看專案經理對於schedule的估計會死在哪裡。每個專案的PM
都想,如果某甲可以專心一志地去做的話,只要10天就作完了。問題
是現在A花了20天才做完,B花了20天才做完,C也花了20天才做完。依
照常理來說,有哪個PM會抓這麼高的buffer嗎?專案A的PM可能會想,
我抓個10%的buffer,所以這件事情應該可以花11天做完。專案B的PM
可能想是12天,專案C的PM可能抓了15天。好吧,結果是每個專案都會
delay。這還是在每件工作沒有轉換成本的考量下喔。某甲並沒有偷懶
,可是每個專案都會delay。

所以現在我每次聽到『你要花15%的時間在專案A,30%的時間在專案B,
55%的時間在專案C…』的這種說法,就想要打哈欠。數字是不會說謊啦
,不過隱藏在數字後面的理論真的是對的嗎?這樣做下去,真的可以
work嗎?

我小時候在學校裡面學軟體工程時,壓根兒沒聽過multi-tasking對於
專案會有多大的危害。直到到了職場以後,才開始領教到50%在專案A,
25%在專案B…的這種說法。這種分配資源的想法,對於大多數主管來
說,是非常直覺的,畢竟我們從小就是第一堂課上國文,第二堂課上
英文的這樣子長大。我想此刻在台灣的某個專案資源分配會議上,一
定還是會聽到類似的說法。可是符合直覺的事情並不一定是對的。
multi-tasking對於專案推行時的副作用,實在是不容忽視。我蠻好奇
為什麼在軟體工程或是專案管理的課程裡面,居然會忽略了這麼重要
的一個課題。

然而除了multi-tasking以外,我們還想了很多辦法,來浪費員工寶
貴的時間。那就是:

「把員工的時間浪費在沒有意義的事情上面。」


把員工的時間浪費在沒有意義的事情上面
-------------------------------------

會計 :布魯斯,你們部門的那個歐尼爾,已經兩個禮拜沒有填time
card了,這樣不行喔。

布魯斯:不好意思啦,我會趕快催他填。

布魯斯:歐尼爾,你已經兩個禮拜沒有填time card了。趕快寫一寫。

歐尼爾剛好寫程式寫到一半,忽然被電話中斷了思緒:喔。好。

五分鐘後,歐尼爾把上上個禮拜的time card copy一份,日期改一改,
送給了布魯斯。

布魯斯:歐尼爾,你上上個禮拜四不是有請假嗎?還有你上個禮拜不是
有出差到台中嗎?而且你charge的project code都填錯。

歐尼爾:Sorry,sorry。你把它退給我。

歐尼爾花了三十分鐘,仔細check他的email信箱,回想這兩個禮拜的行程
,填好了time card、假單、出差申請單、差旅費報銷單,還把相關的收
據通通都貼好,送給了布魯斯。歐尼爾被打斷了以後,大概花了一個小時
,一天以後,這些東西跑到了會計部。

會計 :布魯斯,你在差旅費報銷單那裡簽錯位置了。你拿回去叫歐尼爾
重寫一張啦。

布魯斯:不好意思啦,我會趕快處理…

衙門越多,官僚習氣就越重。我懷疑現代會計的基本假設,就是『每個員
工都有可能當賊,所以需要內部仔細地稽核。』當組織越龐大,裡面的官
僚越害怕沒有事做會影響工作保障時,就會努力設計出各式各樣的表格,
五花八門的單據,以免你做了一件僭越身分地位的事情。於是乎,即使是
一件小事,也會是每個部門都要會,每個主管都要簽。

當然,這也常常是因為政治上擺不平。每個主管,都深怕與他同級的競爭
者,會接觸到什麼他不知道的資訊,而會因此取得升官發財的秘訣,所以
一定都會想要在決策的過程中參一腳。

所以你用高薪請來的程式設計高手,還有專業經理人,就會拿他們寶貴的
時間,可能是一個小時好幾千塊錢的代價,為了公司一定會發給他們的三
五百塊,在那裡填寫單據或是簽名蓋印章。而這樣做的公司,通常還會對
於他們內部控制制度的嚴謹,感到洋洋得意。

另外一種時間殺手就是開沒有意義的會。公司一大,分權分的越散,就會
有越多人來爭取管轄權,人一多開會是很沒有效率的。特別是主管。有些
主管凡是遇到不是他所負責的業務,總喜歡提供良心的建議,厲害的地方
在於這些建議通常可以悖離邏輯,違反常理。根據我的經驗,只要人一多
,就一定會有人扮演這種神奇的角色。此外,大公司常常會找來沒有決定
權的人開會。看起來有決定權的人,又常常沒有肩膀,就會屈服於更上一
層的壓力。

布魯斯:關於網站的風格,我想請教一下貴公司是否有特定的想法?

西恩(IT部門主管經理):為了爭取時效,我想你們先做三種版面給我們挑
,我們會在下個月的主管檢討會議中,找時間請
高階主管背書。

兩個禮拜後,第一次檢討會議會前會。

西恩 :你們做的這三種版面我看了覺得不喜歡,我想請你們的網頁設計
師再設計幾個比較活潑的版面。

布魯斯:可是這是依據你們現有的網站風格設計出來的啊?

西恩 :我們現在的網站被人罵得亂七八糟的。你們還比照這個?你們要
做這種決定之前,要先問我啊。請你們的網頁設計師換一個比較
生動的顏色。

布魯斯:好吧,下個禮拜就是檢討會議了。我會請網頁設計師加班改出新
的版面出來。

西恩 :辛苦你們了,我們三天後再開一次會前會。我會找使用者方面的主
管琳達,還有我老闆潔西卡列席。

三天後,第二次檢討會議會前會。

琳達 :這是什麼東西啊?你們怎麼用了這麼花俏的顏色?

布魯斯:這是依照西恩的建議,我們希望可以用比較活潑的顏色。

西恩 :我只是建議而已,你們應該依據你們的專業發揮啊。

琳達 :這跟我們現在公司的其他網站風格根本就沒有align在一起。潔西卡
,你覺得呢?

潔西卡想,我應該想辦法罩一下西恩,不然場面不好看。對了,公司好像有
另一個部門有類似的規定:我記得公司的跨部門網站標準訂定小組,應該已
經定義出一份我們公司都應該遵循的網站風格標準。西恩,你是否有提供給
vendor參考?

西恩 :我並不知道有這份標準文件。

潔西卡:下回在做決定之前,可以先來問我。你可以去找跨部門網站標準訂
定小組的喬依思討論。我回頭把她的email寄給你。

西恩 :布魯斯,那就請你們依照那個標準來設計網站的新風格。

布魯斯:……..有標準可以遵循當然是最好的啦。(他媽的,有這種東西不
會早一點拿出來?)

檢討會議當天。

大頭甲:這個字體怎麼這麼小?

布魯斯:這是依據跨部門網站標準訂定小組所訂定的標準所設計出來的。

大頭甲:我們這些人年紀大了,都有老花眼了,這字這麼小看不見啦。

大頭乙:對了,你們這個畫面怎麼還要捲動啊?我們這些老頭子要用滑鼠這
樣拉啊拉的,很不習慣也。盡量把內容都放在一個畫面裡面嘛。

潔西卡:對啊,對啊。這個敘述怎麼折行了?你們應該把欄位拉寬一點嘛。

大頭甲:你在點這個,我看看。好,你滑鼠不要動。好,這個滑鼠不要動的
時候,是不是可以出現什麼提示的畫面?告訴人家這個功能在做什
麼嘛。

布魯斯,可是在我們所拿到的標準裡面是禁止這樣的做法啊。

大頭甲:這樣子啊,潔西卡,你回頭幫我call個meeting,我來跟哪個小組的
成員好好討論討論。

潔西卡:沒有問題。

大頭甲:布魯斯,這個功能的提示你們先照著做,我們開完會以後,再告訴你
這個結果是什麼。

大頭乙:現在不是很流行什麼Flash嗎?你們要不要加個動畫?

大頭甲:對啊,我們可以…….

會場陷入了對於動畫效果的討論,大家各自表述自己喜歡的動畫。過了半小
時。終於結束了這個會議。所以布魯斯帶著需要把字放大,欄位加寬,可是
不可以捲動,並且還要加入最新的動畫效果的決議回去。

網頁設計師丹尼爾:這怎麼可能?我們怎麼可能把字變大,欄位變寬,可是
又不要捲動畫面呢?

布魯斯:我也這樣說啊,可是他們說,這是你們的專業,你們這麼專業的網
頁設計師一定可以辦得到的。

丹尼爾:是啊,我還會讓紅海的海水分開哩。…

隔了一個月,大頭們的老大,帶頭大哥來看這個系統了。

帶頭大哥:這個畫面怎麼開這麼久?

布魯斯:這個是因為上次開會決定要做flash動畫,讓我們的畫面更生動活潑
一點。

帶頭大哥:拿掉。我們這是跟供應商之間資訊交換的平台,做這麼多花俏的
東西做什麼?況且我們的供應商的頻寬都很有限啊。

大頭甲:大哥您真是英明。

大頭乙:布魯斯,我們只是要你們增加一些比較好看的效果,可沒有叫你們
要做出這麼大的檔案啊。布魯斯,你們是這個行業的專家,應該知
道不可以使用太大的檔案來佔用網路的頻寬啊。

布魯斯:可是Flash檔的size本來就會比較大啊,要做動畫一定就會有這樣的
結果啊。

大頭甲:我們又不是專家,你應該highlight這個issue啊。

布魯斯:…….

利用讓部屬開無用的會議,接著再用推翻部屬會議的共識,來證明自己的高
瞻遠囑,思慮周密,似乎是許多高階主管調劑辦公室生活的最佳娛樂。類似
這樣的決策過程,可能在現實生活中屢見不鮮。

我曾經在八卦雜誌上看過這樣的報導,唱片公司的企劃人員,為了幫新人取
一個響亮的藝名,經過多次內部開會討論,最後終於提供給老闆三個建議。
結果老闆去找他最喜歡的算命先生,另外取了三個名字,由老闆的小老婆從
算命先生的建議裡面,挑一個最喜歡的,這樣子就成了新人的藝名。接著藝
人大紅大紫,還一再感謝算命先生的神機妙算。

不過這還不是最糟糕的狀況。最慘的狀況是參加那種跨國的會議。某些大公
司特別迷信國外飛過來的consultant。所以在開會的時候,就會請consultant
蒞臨指導。畢竟外國人有洋槍有洋砲,除了人高馬大,船堅砲利以外,大腦
可能也會大一點。因此開會的時候,就會有人先用中文交談,接著為了讓大
腦比較大的外國人也了解會議的內容,就會有人用生硬的英文解釋,接著又
有人認為這個翻譯的人翻譯的不好,就會用更生硬的英文來解釋前面的人所
說錯的地方,最後consultant大概了解狀況以後,就會提出他認為最專業的
建議。

不過因為consultant通常經過層層轉述以後,不是非常了解來龍去脈,所以
他的建議通常就是吃這行飯的人,從小時候開始就已經聽爛了的廢話。接著
呢,就會有狀況外的人,把consultant的廢話,當成是神諭。為了避免大家
的英文太糟糕,就會用中文把consultant的英文再翻譯一次。接著還會有人
繼續指正中文的翻譯。好吧,這種狀況光用寫的手就打字打的很酸了,還要
繼續講下去嗎?

這種會開久了,可以忍住不打瞌睡的人,可以考慮到聯合國上班。每次遇到
這種狀況時,通常我就是負責對話的主角。每次開完這種會議,都會覺得壽
命大概折損一半。

另外一種常見的時間殺手就是過多的文件。SA要寫analysis document,SD
要寫design document,programmer要寫註解,tester要寫test case,test
result跟test report,project manager要寫各式各樣的plan,report,
以及meeting minute;每個人每個禮拜都要寫status report,time card…

軟體業可以說是專門生產文件的工業。生產沒有人有能力看的文件,以及訂
定無聊的標準,要求各式各樣的文件,並寫製作沒有力氣跟著最新的功能同
步更新的文件,就變成了這個業界的常態。在大多數的公司裡,真正必要的
文件可能都沒有人去寫,可是不必要的文件可能會汗牛充棟。而已經寫出來
的文件,大多數都跟不上版本更新的速度。所以內容通常是在描述歷史上的
某一天。而不同的文件,可能講的剛好是不同天。所以文件與文件之間,很
有可能彼此之間還會串不起來。

當然,有很多程式設計師就是厭惡寫文件。必要的文件,對於專案的開發絕
對會有幫助。生產不必要文件所花費的時間,會吃掉撰寫必要文件的時間。
所以在大多數的場合裡,必要的資訊總是被不小心遺漏了,可是不必要與過
時的文件,卻會一而再再而三地淹沒在我們的硬碟中。

有人說過:『錯誤的決策,比貪污更可怕。』對於資源的不當運用,確實是
許多軟體公司最大的問題。然而大多數時候,即使你覺得這樣的措施不好,
你可能還是覺得自己沒有能力改變這一切。要根除multi-tasking,得要建
立多大的共識基礎?要減少施加不當的壓力,高階管理者要更改多少行為模
式?要除去無用的數字管理,得要教化多少腐朽的大腦?要尊重員工的時間
,需要多麼成熟的工作態度?

這些都不是容易做到的事情。所以主管們通常能做的就是採取柔性的訴求,
例如

*鼓吹團隊精神
*激勵
*以身作則

鼓吹團隊精神
-----------

打造一支鋼鐵勁旅,並不是一件容易的事情。不過對於很多主管來說,他們可
以打的牌並不多。公司的人就是那麼多,找來找去就是那麼幾個鳥人,所以呢
,只能把幾個人硬湊在一起,組成一個雜牌軍。通常找人的狀況不外乎如此:

* *在某次的資源調度會議上* *

布魯斯:這個project我現在還需要5個programmer,coding 3個月,測試4個月。
還需要3個tester。

吉娜 :看來我們現在人力吃緊。布魯斯,你有沒有什麼建議?

布魯斯:programmer的話,歐尼爾跟史托雅柯維奇現在有空,我已經問過了。
我還需要3個人,我想要找布萊恩、韋柏跟諾威思基幫忙。

傑克森:不可能,布萊恩最少還要在我的project三個月。

尼爾森:諾威思基最少也還要兩個月才會從現在的project離開。這還是樂觀的
狀況。

艾德曼:韋柏也不行,他已經提出留職停薪,他打算去動膝蓋的手術。他膝蓋自
從上次受傷以後一直沒好。

布魯斯:那怎麼辦?我們還要不要做這個project?

吉娜 :有了,聽說最近剛進來有個叫做艾佛森的工讀生還不錯。

布魯斯:可是我們上次從波士頓找來的那個工讀生華克,根本就不中用啊,會不會
有同樣的狀況?況且說只有艾佛森,這樣也才只有一個人啊。

吉娜 :那先讓艾佛森頂這個位置。尼爾森,你要諾威思基一個月之內加班把那
個案子結掉,不要那副表情給我看。有問題,我負責處理客戶那裡。已
經上線這麼久的案子,沒理由我們要繼續support這麼久。傑克森,布萊
恩只能留一個半月。

傑克森:不行啦,最近這個案子要上pilot run,布萊恩不在,會出大紕漏。

吉娜 :對喔,布魯斯,布萊恩看起來是走不掉了。這樣吧,不然你先把艾佛森
放在你的project organization裡面,我們再找三個工讀生進來。我聯
絡一下華克。

布魯斯:我不要華克啦,他根本就不能算是一個developer,頂多算半個人。不
過我倒是聽說他同學皮爾斯還不錯啦。

吉娜 :那你把華克、皮爾斯、跟艾佛森放到project organization裡面,這樣
加上歐尼爾跟史托雅柯維奇,你就有五個人了。如果諾威思基可以加進
來,這樣就有六個人了。

布魯斯:可是華克、皮爾斯、跟艾佛森都是工讀生。這三個人頂多算一個半,加
上諾威思基我也只能算半個,這樣還差一個人。

吉娜 :有了,我找一下馬龍好了。他前一陣子想離職,我去勸勸他,請他再多
幫忙這個案子。

布魯斯:如果馬龍能來那就太好了。那我只剩下tester有問題…

很多時候,如果討論已經變成了誰是一個programmer,誰只能當半個,這種組隊
的方法,大概也組不出什麼夢幻團隊。

由於可用之兵有限,每個人的才智又有所不同。所以很容易就有勞逸不均的狀況。
主管如果對於每個人的能力了解又不清楚,就會把不對的人放到不對的位置上。接
著能做的通常是:

* *在某次專案的kickoff meeting上* *

布魯斯:我們的專案,有很多人都是初次合作,包含了華克、皮爾斯、跟艾佛森,
他們都是各國立大學的高材生。我想我們一定要請大家相互配合,發揮
團隊精神…

* *一個月後的專案進度檢討會議上* *:

布魯斯:馬龍,看樣子這些年輕小夥子還要麻煩你多指點一下。

馬龍 :那個華克,根本整天都在混,整天在哪裡混時間,不曉得在幹什麼。還有
艾佛森,做事情莽莽撞撞,不照規矩來。上次還不小心蓋掉我寫好的檔案
,還好我local有備份。

布魯斯:馬龍,既然我們是個team,你又資歷這麼深,就只好多麻煩你幫忙啦。我
們現在在同一條船上,你就發揮一下團隊精神,幫他們一把,我看皮爾斯
還不錯。

馬龍想,發揮團隊精神也沒領比較多錢,誰還管這些人這麼多:是啦,這個小子還
不錯。不過可惜可以來的時間有限。

布魯斯:是啊…

又過了一個月。

艾佛森:那個布朗在畫的是什麼圖啊,根本整個設計都不對,我們的功能才會有
這些問題。他到底懂不懂UML啊?

馬龍:這跟UML一點關係都沒有。布朗寫的spec已經夠清楚了,整個東西會寫錯都
是因為你沒有跟其他人好好討論合作的關係。

艾佛森:你怎麼可以這麼說?這樣說一點都不合理。我要求你向我道歉。

布魯斯從桌子底下踢了馬龍一下,看了馬龍一眼,求他先閉上嘴:艾佛森,你先
把你找到的問題列出來,現在布朗不在,單單聽你這麼講,我們根本也不知道事
情到底真相是什麼。我只知道tester找出了很多問題,而這些程式都是你寫的。
這不一定是誰的問題,可是我得要知道我們該怎麼解決現在面對的狀況。現在你
先整理出來你發現的問題。

艾佛森不發一語地走了出去,大力地關上了門。馬龍:布魯斯,你為什麼不讓
我講話?

布魯斯:為了維持團隊的和諧啊。馬龍,我知道你一直都是對的,可是你這樣
子會讓場面變得很僵。只好請你相忍為國了…

大多數人對於團隊的想法,其實都深受軍教片之害,那種要絕對服從命令,誓
死效忠,一個口令一個動作的團隊,其實在現實生活是不太容易存在的。大多
數團隊,都有那種好說話的人,跟不好說話的人。

好說話的好好先生其實跟個單細胞生物差不多,原則上他們會信奉『君要臣死
,臣不敢不死』的這種理念。所以只要跟他們鼓吹一下『要有團隊精神!』,
『犧牲小我,完成大我』『成功不必在我』這種觀念,就願意配合進行不可能
的任務。

不好說話的人通常都自認才高八斗,當然實際上並非總是如此。這些人的特點
就是原則很多,不願意配合。所以通常鼓吹團隊精神只會被他們嗤之以鼻。我
比較建議先吹捧幾句以後,再使用激將法。大凡自視甚高的人,多半都受不得
激。

鼓吹團隊精神,在企業內部通常就是把不好說話的人所推託出來不想做的事情
,交到好說話的人身上。這好像不是什麼很好的分工方式吧。

另外一個常有的想法就是要維持團隊的和諧。好像所有的衝突都不可以浮到檯
面上來,以免影響每個人對於團隊的信心。事緩則圓、相忍為國是這類主管常
掛在口上的名句。

這不禁使我想起很多黑幫電影。在很多這類型的電影裡面,兩個幫派之間起
了衝突,通常就是為了要搶地盤。對砍了一陣子以後,常常會有很多黑道大
哥出來講情,要大家賣他們一個面子,一笑泯恩仇。不過看了這麼多電影,
還沒看過有哪兩個幫派真的就從此風平浪靜。

為了強調團隊的和諧,變成鄉愿俱樂部,其實帶來的壞處遠大於好處。他只
會鼓勵人把事情掩蓋下來,而不是去尋找真正的答案。我個人覺得衝突是每
個團隊成員彼此利害關係不同,必然會有的結果。問題不在怎麼壓制衝突的
發生,而是在衝突產生時,怎麼樣可以找到一個解決的方法。不過對於大多
數的主管來說,要人家賣他一個面子,好像比真正解決問題來得省事多了。
反正我已經請你們要互助合作了,你們沒有團隊精神,怎麼能怪我呢?

團隊精神其實是需要長時間的相處以後才會產生的。人並沒有辦法plug &
play,即使可以,你在音效卡後面接螢幕,畫面絕對還是一片空白。我個人
覺得,專案經理需要製造彼此互助合作的機會。怎麼把對的人放在對的地方,
再讓這些人可以慢慢融合成為一個團隊,絕對是一個軟體專案經理人的首
要任務。光是講幾句要有團隊精神,大家要同舟共濟,這是無濟於事的。

此外,站在組織的立場上來說,我們對於團隊合作到底提供了什麼實質的
獎勵?如果只是『我們在下一次調薪時,會考慮這個因素。』或是頒發幾
張優秀團隊獎狀,其實誘因遠不及發給獎金、股票、認股權來得有效。如
果沒有實質的獎勵,團隊的成功與個人絲毫無關,這樣子的話,人們怎麼
會有動機想要協助團隊的成功呢?

(待續)

2003-10-15, 17:53 yonkov 的個人資料 把 yonkov 加入好友列表 發送Email給 yonkov 瀏覽 yonkov 的網站 MSN : yonkov@mail.com
yonkov
班導師


註冊日期: 2003 10
來自: 火星
文章: 51

yonkov 離線
《轉載》People Management(下)引用回覆 編輯/刪除文章 搜尋由  發表的其他文章 回報給版主 IP 位置 回此頁最上方

《轉載》People Management(下)

激勵
----
對於工程師無效的激勵方式,我還真知道不少。

*工程師喜歡新科技以及訓練,遠超過金錢
*考績
*肉麻當有趣
*想當年…
*Vision、Mission Statement …

工程師喜歡新科技以及訓練,遠超過金錢


---------------------------------------------------------------
布魯斯:最近project team的士氣有點低落。

吉娜 :那我們來個內部訓練好了。我請佛祖來開示一下好了。

布魯斯:這倒也是可行。什麼時間比較恰當呢?要不要用禮拜三下午四點?

吉娜 :不要佔用上班時間。我想就是禮拜天下午四點開始好了。大家可
能會早一點到,還可以加班…

工程師先天就充滿了好奇心,喜歡嘗試新東西,試試看他所了解的新玩
意兒。只要有新的東西發表了,例如某某標準,或是新的工程技法,某
個軟體的新版本,新的程式語言…他們都有興趣去了解一下。

對於很多主管來說,這好像就代表了工程師喜歡新科技以及訓練遠超過
金錢。所以講到要激勵員工,通常最直覺的想法,就是來個訓練吧。為
了要省錢,最好還是利用週末還是晚上的時間,做個內部教育訓練,讓
老鳥來帶菜鳥。

其實工程師受了訓練,接受了新科技,不是為了現在看得到的薪水,就
是為了將來轉換新工作可能會獲得的加薪。基本上都跟金錢可以畫上等
號。當然不可以排除有些人會純粹想要科技上的進步,跟智力上的發展
,不過這種人大部分會留在學界,開發一些不切實際的東西。對於一般
職場上的工程師來說,如果在追求技術上的創新之餘,可以順便多賺點
錢,應該是沒有人會反對的。

考績
----

布魯斯:奇德,我知道這一陣子你已經很忙了,可是這個案子現在看起
來趕不上進度,我想得要請你禮拜六日都到公司來加班。

奇德 :什麼?去年我才因為加班太久,心情不好打老婆出氣,結果上
社會新聞。你還要我假日過來加班?你是想要讓我老婆再變成
沙包嗎?老實說,這個案子會拖這麼久,都是史考特一開始沒
有調度好。

布魯斯:唉,史考特的調度有問題,這個我們都知道。不過他現在人也
走了,就不要再扯這一段了。這樣子吧,雖然我們沒有加班費
,可是你的配合度這麼好,今年打考績時,我一定會記得會好
好補償你。

大多數人有關打考績的經驗,就跟要他們不穿衣服,赤裸裸地站在台上
接受檢驗差不多。大多數的人會這麼緊張的原因,主要是在於他們誤解
了這件事情進行的方式,以為考績跟他們一整年的表現有關。其實大多
數的主管也是視打考績如畏途,所以多半都是憑著印象,隨隨便便交差
了事。如果一年打一次考績,通常越接近打考績時候的表現,會越具有
影響力。

如果你只能拿考績來激勵員工的話,其實指的就是你並沒有提供其他實
質的鼓勵。所以只好給他一個可能可以升官發財的夢。這種激勵通常對
於菜鳥會比較有用。對於老鳥來說,只要被騙個一兩次,就會學乖了。

肉麻當有趣
----------

布魯斯:鄧肯,這個案子現在真的要靠你大力幫忙了。除了你,沒有別
人有辦法…

對於某些母性比較堅強的主管來說,激勵員工跟哄小孩差不多。所以通
常會用對於這個年齡層的人來說,會顯得有些噁心的話,企圖激勵員工
。聽到這些話,我常常會雞皮疙瘩掉滿地。

: 『你是最棒的。』(是啊,要不要給我一個乖寶寶貼紙?)

: 『公司要是沒有你,那該怎麼辦?』(還是會活的好好的啊。)

: 『只有你才辦得到。除了你,沒有別人有辦法。』
(這連白痴都辦得到。是你只叫得動我。)

: 『我們公司是從哪裡找來像你這麼優秀的員工?』
(是啊,可是怎麼會領這麼少的薪水呢?)

當老闆信奉這一套時,你就會多了幾個肉麻的朋友,只要他心血來潮,
就會時時拍出奇怪的馬屁。如果他跟你不熟還裝熟時,這就會更尷尬了
。他會問候你的家人,成長的環境…然後徹徹底底地把這些資訊遺忘。

布魯斯想,我應該要關心一下小組成員,對了,應該問候一下他的家人
:鄧肯,你說你太太是在做什麼的?

鄧肯 :我太太在學校當老師。

布魯斯:當老師,哪很好啊。有寒暑假可以放。工作一定很輕鬆。

一個禮拜後。

布魯斯(完全忘記他曾經問過任何問題。):鄧肯,你太太是在做什麼的?

鄧肯也忘記被問過這個問題:我太太在學校當老師。

布魯斯:當老師,哪很好啊。

又過了幾天。

布魯斯想,得要了解一下專案成員的家庭背景:鄧肯,你結婚了嗎?

鄧肯想,你不是最近才問過我嗎:我太太沒有換過工作啊,她還在
學校裡面當老師。

布魯斯想,咦,難道我問過這個問題而且忘了?不妙,趕快轉移話題:
喔。你這個禮拜進度怎麼樣。

當然,有時你會遇到真正很棒的主管。他會清楚記得你的生日,你老婆
的職業,你的嗜好,以及你女兒的音樂發表會,而且他還會尊重你家庭
生活的時間。不過,在資訊產業中,這種主管跟鳳毛麟角差不多。

想當年…

會採取這種奇怪的激勵方式的人,通常也是各類教條的愛護者。例如
『天下沒有不是的父母』、『玉不琢,不成器』、『棒頭出孝子』…。
依照出生年代的不同,通常會有下列不同的誇大版本。

遠古時期:『現在的年輕人啊,一點兒苦都吃不得。想當年,蔣委員
長領導我們抗戰的時候。(這時候要立正站好)那時候,我們整天在重
慶被日本鬼子轟炸。常常防空洞一躲啊,就是一個星期。日本鬼子一
炸啊,就是一個星期。一整個星期沒闔眼啊,要換你們現在的年輕小
夥子,我看早就不行啦。你看你們這些人好命的哩。現在不過是加個
班,就一副沒擔當的樣子,要遇到戰爭啊,我看你們只能舉雙手投降
了啦。』

中古時期:『現在的年輕人啊,一點兒苦都吃不得。想當年,我們要
讀書啊,是歷經千辛萬苦。每天打著赤腳上學,便當盒裡面就裝著白
飯配著蘿蔔乾,晚上唸書沒錢可以點電燈,還要去抓螢火蟲,螢火蟲
不夠亮還要把牆壁挖個洞跟隔壁借點光。每次要註冊了,就要跟街坊
鄰居借錢去繳學費。你們這些年輕人啊,一點挫折都受不了。不過是
加個班嘛。要知道,有班可以上已經多好啦。現在誰不去大陸啊,大
陸的人工這麼便宜,每個工程師都很拼。聽說他們一天睡不到一個小
時,只要有錢賺啊,二十幾個小時都在工作。你們不學學人家,將來
怎麼跟他們比啊。遇到大陸的工程師啊,我看你們是鐵定失業。』

近代:『現在的年輕人啊,一點兒苦都吃不得。想當年,我們要跑程
式啊。還得要把程式都打在卡片上。光compile啊,就要排隊等個一
兩天。拼錯一個字啊,就要再等個一兩天。哪像你們現在這麼方便?
按個鍵等一會兒程式就compile好?你們真是身在福中不知福啊。現在
要寫程式已經比我們那個年代好太多了。你看看你們寫出來的那是什
麼程式嘛,bug一大堆。』

現代:『現在的年輕人啊,一點兒苦都吃不得。我們前幾年在做那個
人事薪資系統,要上線前啊,大家整整三個月,每天工作十八個小時
,早上八點出門,晚上兩點回家。不誇張喔,整整三個月,包含禮拜
六禮拜天。現在你們不過是一天工作十四五個小時,還不到一個月,
就一直哇哇叫,一點抗壓性也沒有。你們不知道,比起我們當年啊,
實在是好命的太多啦。』

基本上呢,這種激勵的方式呢,就是先告訴你一個父母雙亡,無力葬
父,只好委身青樓的弱女子悲慘故事,希望你能夠覺得你的命,其實
比別人都好。讓你明白,別人這麼慘都沒去跳樓了,你不過是因為加
班時間太多,沒時間陪老婆,因此跟老婆吵架的小小個人際遇不算是
什麼。接著就是要告訴你,在以往那個年代,有一些人,即使身處逆
境,也會跟逆流而上的小魚一樣努力往上游,才會完成偉大(?)的成
就。你應該效法這種精神,為公司做牛做馬。所以禮拜天加班,請務
必準時到達。不過身為管理階層的我呢,有更重要的事情要思考,所
以就不奉陪啦。畢竟我已經苦了那麼多年,媳婦熬成婆,總該輪到我
享清福吧?

我是不知道有多少人會被這種故事激勵啦。古人悲慘的故事,當做是
上班時候的消遣,聽聽當然無妨,這就跟看連續劇的意思是差不多的
。不過如果我是當事人,切身的問題絕對還是比較重要。女朋友生氣
,男朋友翻臉,小孩子認不得爸爸,都會比加班趕進度來得重要。況
且大多數時刻,長時間加班的效率其實都非常低落。如果一個專案經
理不能認清楚這一點,只是一昧地要求team member長期加班,只是看
到工作時間延長,好像生產力也跟著增加的假象,總有一天會嚐到高
流動率的惡果。

Vision, Mission Statement …
-----------------------------

有些企管顧問非常強調Vision,Mission Statement…這些東西的功用
。他們覺得,如果我提出一個宏觀的vision(願景),並且很清楚地告
訴每個員工整個公司的mission statement(公司宗旨。我個人覺得比
較像是任務的宣言),員工會受到宏觀願景的吸引,而願意做出超高品
質的工作。

這種顧問舉出來的例子,通常是某某公司因為有了偉大的願景,因此
整個公司的人都受到這種偉大願景的指引,願意犧牲奉獻努力工作。
最後終於獲得前所未有的成功。

原則上呢,我覺得成功的公司擁有解釋歷史的權利。他們想要讓成功
看起來比較理所當然一點,找些理由來為自己的臉上貼金也是很正常
的現象。

我在不少公司待過。每一家都是立志要成為世界上第一流的企業。每
家公司的願景,大概都是像這個樣子:『我們要集合世界上一流的人
才,開發世界上一流的產品,然後拿著吸塵器到世上每個人的口袋大
吸特吸,直到所有鈔票都被我們吸光為止。接著要拿我們賺來的錢的
百萬分之一,出來造橋鋪路做善事順便抵稅。』按照企管顧問的說法
,因為我們有捐款助人的那個部分,員工就會被這種世界大同的偉大
使命所吸引,然後受到前所未有的激勵,就願意無償地長時間加班。
例如賣彩券的公司都會強調買樂透可以幫助社會資源重新分配,彩券
盈餘還會提撥出來做社會福利,這樣員工就會忘記他們是在鼓吹賭博
,而是在從事一項崇高的行業。

選定一個方向,做客戶要的東西,並且努力保持自己的競爭力,其實
是企業要獲得成功的不二法門。沒有一家公司,是因為vision太差,
所以員工士氣低落,導致生意太差,因此關門倒閉的。然而很多經營
階層,一直認為勾勒出一個遠大的願景,是一件很重要的事情,所以
要一直努力地跑到風光明媚的山川之間去閉關苦修,才有辦法畫出一
塊很大的大餅。

然而對於大多數的公司來說,欠缺的其實不是一塊大餅。而是怎麼去
讓這個夢想實現的執行能力。與其拿一個遙不可及的夢想企圖激勵員
工,不如拿實際成功的成績來激勵士氣。這世上還有什麼比『成功』
更能激勵士氣呢?或許是因為對於這些主管來說,要獲得成功的經驗
太過困難了吧。

以身作則
--------

對於很多主管來說,管理就是要以身作則。所以擔任主管的人,要第
一個到,最後一個走。我小時候看軍教片,那種鐵血班長,跟魔鬼士
官長,就是以身作則的最佳模範。然而軍教片看起來很好的東西,現
實生活可不是如此。例如現在我們已經不玩『消滅萬惡共匪,解救苦
難同胞』這一套了。

很多具有同理心的專案經理,總會覺得大家都在忙,我不可以在旁邊
休息,我應該比大家更忙才對。所以開始到各地去招攬工作。菜鳥經
理常常犯的毛病,就是做自己熟悉的事情。我原本是系統分析師出身
的,就繼續坐著經理的位置,做系統分析的事情。我原本是寫程式出
身的,就繼續坐著經理的位置,寫我想寫的程式。特別是當做這個工
作的人,做得沒有我好時,就更有理由這麼做了。畢竟會被升上經理
,不會是沒有原因的。問題是,當你在身先士卒以身作則時,誰在運
籌帷幄呢?當你在努力寫程式時,誰在做專案經理呢?

真正的管理,其實不是在於要專案經理做個全能的人,team member
看到你很辛苦,確實會認同你的辛勞,不過他們更需要的,是一個可
以傾聽他們的問題,接著幫他們找資源來解決問題的人;是一個知道
該做什麼,並且會適切地調度資源的人;是一個可以引領方向,帶他
們走出重重包圍的人。

當你專注在某個工作,而非整個專案時,那麼負責那項工作的人,是
頭一個受害的人。接著受害的,則是整個專案的團隊。

結論
----

大多數的軟體公司主管,會花很多時間去招募新人。因為他們認為員
工會有高流動率,是一種很正常的事情。因此他們的重點,一直都放
在怎麼去找到市場上最好的新人。相形之下,花在怎麼讓現有人力運
作的更好,怎麼讓員工更喜歡這個工作環境的精力上,就顯得少的可
憐。

軟體開發是一種高度需要思考的工作。安靜的環境,足夠的辦公空間
,以及採用良好的開發工具,確實可以提高開發工作的效率。然而,
減少multi-tasking,以及採用正確的開發流程,並且減少不必要的文
件,對於效率的助益可能會更高。

有沒有什麼比較簡單的原則呢?我個人覺得,要能真正的提高效率,
你得要先尊重每個人的時間。不要花太多的時間,去做不必要的事情
。把事務性的工作,盡量地找行政管理人員幫忙處理。找個工讀生來
幫工程師填寫假單,處理所有要申報的費用,影印所有要列印的文件
吧。每次會議要先規劃議程,沒有必要,不要讓每個人從頭到尾參與
一個會議,先想想這個人出現在這裡,有沒有什麼必要性。沒必要的
話,就放他先回去工作吧。只有你尊重每個人的工作時間,才能真正
打造出一個有效率的團隊。

不過,專案經理並不能只把心思專注在效率上。怎麼樣打造一個適才
適所,運作平順的團隊,並且保持高昂的士氣,才是專案成敗的關鍵
。老實說,我覺得只有每個人都贏的策略,才能獲取這樣的成果。

有什麼策略會每個人都贏呢?讓我來教你。

簡單的說,針對你現在所有的專案,每個專案依據專案的難易程度,
提撥一份專案結案獎金。專案可以順利結案,發給一筆獎金。如果專
案是在預定的時間內完成,就發給另一筆獎金。獎金的金額怎麼定呢
?對於專案結案獎金,我建議直接從專案總價中抓一個百分比即可。
例如,如果專案可以結案,就發給專案成員專案總價的10%做為結案
獎金。

至於在預估時間內完成的專案,要提供的獎金,其實也可以用專案總
價的固定百分比來算。不過對於那些已經做到一半,而且還沒有結案
的案子。我個人建議的方法如下:

(預估最糟的結案日期 – 預訂完成日) / 2 * 所有成員的薪水

這裡面當然會牽涉到『預估最糟的結案日期』『預訂完成日』這個日
期怎麼得來的。還有這個日期是否需要隨著專案的狀況進行調整…等
問題。我個人認為,這些日期都問主管即可。

預估最糟的結案日期:如果這個專案到這天還沒做完,你寧願從現在
開始就不要投任何人進去。

預訂完成日:任何你認為合理,並且希望project team可以完成的日
期。不過要注意如果這個日期完全不可行,那就會失去獎勵的誘因。

其實,這只是一個建議而已,你可以依據實際專案的狀況自己發揮。
只要你把專案的成功,與一個有可能可以得到的獎勵綁在一起,就會
有一個很好的策略。

怎麼樣才能讓優秀的員工想要長久地待下來呢?我想讓員工擁有成功
的經驗,合理的待遇,良好的生涯規劃,發揮才能的機會以及良好的
團隊氣氛,都對於留住人才,有正面的幫助。

人力是軟體公司最重要的資源。只有個人的發揮,與公司的成長可以
密切地契合,軟體公司才有生存成長的空間。找到好的人才,把他放
到對的位置上,並且提供他必要的協助,讓他願意持續地為公司效力
,實在是高階主管最重要的工作。有夢雖然很美,可是強將手下如果
都是弱兵,大概就只能做做白日夢了。楚漢相爭,最後劉邦可以得天
下,關鍵就在於他打造了一個優異的團隊。沒有優秀的團隊,就沒有
良好的執行力;沒有良好的執行力,再多願景也是空談。

話說回來,讀這本書的人剛好是高階主管的機率應該很低。所以對於
大多數的問題,大概都只能默默地承受或是被動的因應,沒辦法做出
什麼前瞻性的思考或是積極的作為。沒關係,恥笑老闆的無能原本便
是一種有趣的事情。如果你是個中階主管,少做一些傻事,就會被少
笑一些。如果你是個小螺絲釘,反正人太菜的話,天生就是要被欺負
的,那就保持著愉快的心情繼續嘲笑老闆吧。我會在這本書剩下的部
分,努力幫你保持愉快的心情。你只要負責嘲笑老闆就好了。

運用數字來進行專案成本與時間的預估,本來就是最正統的做法。只
是在估計的過程裡面,所有的數字要建立在合理的假設上,在專案進
行的過程中,如果要修正你的規劃,就要隨時檢視你原先的假設是否
合理。數字並不是代表專案管理的全部,它只是代表你對於一件事情
要做多久,要花多少錢的一個推論。我個人覺得,我們應該要做的,
並不是先建立一個推論,接下來就拿著這個推論來指引你全部的行為:

『你不是說這個問題,一個禮拜就可以解決了嗎?』

『你不是說SIT只要三個禮拜嗎,現在都已經過了兩個月了。』…

計劃應該只是當成是你在做事情時的參考,一開始規劃好了,把要運
用多少資源也規劃好了,接著當你遇到實際的狀況時,再慢慢修正你
的計劃。我總覺得,當專案過了起初planning的階段,重點就應該放
到team身上,team member的士氣,成員之間是否能夠培養出共同開
發的默契,是否把正確的資源,在正確的時間點,擺在正確的位置上
…這些才是專案進行過程裡面最重要的因子。除非你想寫一個全部人
員都陣亡的backup plan,否則所有專案進行過程中對於計劃的修正,
都應該建立在你對於現有團隊的了解上,而不是直接拿預估人月除以
開發人數得到開發時間。

當然,這樣子做最大的缺點,就是把太多因素綁在主觀的判斷上,別
人就沒有客觀的依據可以來判斷這樣的預測是否可行,也就沒有辦法
進行control,或是risk management。不過專案管理本來就一直在藝
術與工程的兩極中擺盪,那就看你要從哪一個角度來看待這些事情。
當然,這就會跟軟體公司要怎麼樣才會賺錢,或是專案的成敗該用什
麼樣的標準來衡量有關了。Well, that will be another story.

(完)

2003-10-15, 17:54 yonkov 的個人資料 把 yonkov 加入好友列表 發送Email給 yonkov 瀏覽 yonkov 的網站 MSN : yonkov@mail.com
  « 上一篇主題 下一篇主題 »
發表新主題 發表回覆
跳到:

Powered by: Burning Board 1.1.1 2001 WoltLab GbR