程式設計師的心酸！(上)

eagle1005

此篇文章是轉載 但是我找不到最原始的週報文章去那訂
知道的人 回一下文或是悄稍話和我說一下唄！


轉載] People management (1/3)


轉一系列從 Java 週報上獨孤木專欄的 People management 文章，看完如果有同
感，
或許可以考慮訂閱一下他們的週報文章(非廣告)。


獨孤木專欄＞ 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。 （待續）

eagle1005

此篇文章是轉載 但是我找不到最原始的週報文章去那訂
知道的人 回一下文或是悄稍話和我說一下唄！激勵

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

＊工程師喜歡新科技以及訓練，遠超過金錢
＊考績
＊肉麻當有趣
＊想當年…
＊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.
(完)