在修訂版中新增了6章，探討的內容包括：以往不認為是問題的領導問題、開會的文化、由不同世代所組成的混合團隊，以及，我們最常用的工具不見得是助力，可能反而是阻力。此外，作者為整本書做了修訂，以切合當今的開發環境與挑戰。任何管理軟體專案或創新組織的人，都可以從本書得到非常寶貴的建議。 如果您每天有看不完的電子郵件、辦公室吵得要命、加班是常態、還有開不完的會……別再忍耐了，您應該看這本書！ 《Peopleware》是每一位經營軟體團隊的人都該讀的書，而且每年都要再讀一遍。打從二十多年前第一版問世以來，在軟體開發領域有關社會和人的問題上，本書的重要性一直有增無減。欲打造更人性化、更具生產力的工作場所，這是唯一的道路。不但要買來讀，而且要列為辦公室的必需品，並確保一定的庫存量。 ——Joel Spolsky，《約耳趣談軟體》作者 近年來，軟體工程領域的一大貢獻是DeMarco和Lister所寫的《Peopleware》，其基本論點是「我們在工作中所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題」……我由衷地推薦這本書。 ——《人月神話》第19章 如果您讀過《人月神話》還不過癮，這本暢銷二十餘年的專案管理聖經《Peopleware》將可滿足您工作上所有的需求。 《Peopleware》1987年一出版就引起轟動，因為它一針見血指出了團隊管理的問題點——如何管理天馬行空、但能力特強的腦力工作者。書中強調，腦力密集產業（知識型企業，例如軟體開發、研發工作、或所有創意型工作）的核心是人，不是技術，應該給予這些工作者充分的自由與信任。傳統的勞力密集產業管的是員工的「身體時間」，而腦力密集產業要管的是員工的「腦力時間」。如何帶領好這些腦力工作者，適才發揮，就是這本書的重點。 本書讀來辛辣而幽默，加上務實的建議、作者豐富的專案經驗，帶動了一股熱潮，Peopleware在軟體業也成了專有名詞，它和《人月神話》共同被譽為軟體書中「兩朵最鮮豔的奇葩」。《人月神話》關注的是「軟體開發」本身，而《Peopleware》關注的是軟體開發中的「人」。書中的經典名言： ◎人在時間壓力下不會把工作做得更好，只會做得比較快，結果被迫交出低品質的產品，自尊心降低，最後辭職不幹。 ◎團隊殺手一覽表：防禦式管理、官僚作風、實體隔離…… ◎讓團隊產生化學作用的方法…… ◎容許建設性的混亂，過度強調秩序只會排擠人才。 ◎給員工一個足夠安靜、不受無謂干擾的辦公環境。 ◎知識工作者就像自由電子，無為而治才是最有效的管理。 ◎終極的管理罪惡，就是浪費員工的時間。例如儀式性的會議。 如何真正發揮人才的力量，這本書做了最佳建議。對於今天越來越重要的知識型產業、創意產業，這本書都值得參考。對於管理者來說，每年都應該重讀一次。 【專業推薦】 「《Peopleware》從很久以前，就是軟體工程方面我最喜愛的兩本書之一，它以大量的真實經驗做為立論基礎，其中多數都做過定量分析。許許多多、各式各樣的專案納入反省、淬煉之後，得到的並不是刻板的結論，而是我們看了真的會感同身受的鮮活案例。本書論點非常正確：軟體專案所面臨的，絕大部分都是社會性的問題，而非技術性的問題。其中，有關凝結團隊、工作環境的見解，使我的思維和教學完全改觀。到了第三版，更是精益求精。」 ——Frederick P. Brooks, Jr.（《人月神話》作者，北卡羅萊納大學教堂山分校計算機科學Kenan講座教授） 「我強烈建議你為自己買一本《Peopleware》，再買一本給你的老闆。假如你就是老闆，就買來送給每個部屬一人一本，再買一本給你的老闆。」 ——Ed Yourdon（軟體業知名作者及顧問） 「當一本書所探討的內容像軟體設計一樣多變，還增訂到第三版，你就知道作者取材，一定得深入問題的本質，結合我們讀者的親身經歷去追根究柢，而不是大家所看到的表象。本書引導人們，乃至全人類，合而唯一！很了不起，非常難得，作者以新增的章節，完成了第三版，實在令人敬畏。」 ——Lee Devin和Rob Austin（《The Soul of Design》和《Artful Making》作者） 「……作者以900多位程式設計師與分析師參與研究所獲得的實際經驗做為立論基礎……全書富含真知灼見與新穎做法，使讀者與管理者可以從新的、更好的角度來看待重要議題……本書傳達的訊息相當重要，是每一位軟體管理者及軟體管理顧問的書架上都應該要有的一本書。」 ——T. Capers Jones 「作者談的都是保證精彩的議題，包括時程預估、空間需求、安靜的工作場所、電話、團隊的催化劑、工作場所中的樂趣、開放的心態、徵人時的面試，以及其他許多主題。」 ——Albert L. LeDuc，《CAUSE/EFFECT》 「狄馬克和李斯特兩人都很會說故事，而且對於專案管理觀察入微。」 ——John H. Taylor，杜邦公司 「……讀起來很有趣，這是因為作者是從其顧問工作所經歷到的歷險故事來進行分析，並提供解決之道，也由於其中的忠告都有紥實的學識做為後盾，使得這本研究精闢的書極具說服力。」 ——《PC World》 「透過一個個精選範例、突如其來的反諷、審慎的推理，甚至提供數據，李斯特和〔狄馬克〕毫不留情地顛覆了許多傳統智慧……即使你不同意作者們的話，也能享受他們的敘述方式，進而深入思考。好好讀完這本書，然後把書交給你的老闆，或者，只要你敢，就交給你的部屬。」 ——Alan Campbell，《Computing》，倫敦

中文版序 湯姆．狄馬克 Preface to the Chinese Edition 前言 第一部　管理人力資源 1　當下，有個專案即將失敗 2　做起司漢堡，賣起司漢堡 3　維也納等著你 4　品質——倘若時間允許r 5　重審帕金森定律 6　苦杏仁素 第二部　辦公室環境 7　傢俱糾察隊 8　「從上午九點到下午五點根本做不了任何事」 9　在空間上省錢 插曲：生產力評量與幽浮 10　腦力時間與身體時間 11　電話 12　把門找回來 13　雨傘步（辦公空間的永恆之道） 第三部　適任的人 14　霍布洛爾因素 15　談領導 16　雇用雜耍小丑 17　好好相處 18　童年末日 19　很高興能待在這裡 20　人力資本 第四部　培育高生產力的團隊 21　一加一大於二 22　黑色團隊 23　團隊殺手 24　再談團隊殺手 25　競爭 26　義大利麵晚餐r 27　敞開心胸 28　團隊形成的化學作用 第五部　肥沃的土壤 29　自我修復的系統 30　與風險共舞 31　會議、個人秀與會談 32　終極的管理罪惡是…… 33　電子郵件之惡 34　讓改變發生 35　組織學習 36　打造社區 第六部　在此工作應是樂事一樁 37　混亂與秩序 38　自由電子 39　霍爾格．丹斯克 索引 譯後記

　　「Peopleware」專案是怎麼產生的？三十多年前，我們一起從洛杉磯飛到雪梨，要去講授軟體工程的系列課程。在橫越太平洋的漫漫長夜中，我們都睡不著，於是整夜都在討論我們當時所負責，或因客戶的關係而接觸的案子，話題圍繞在嚴重的系統複雜性。我們之中有一個人——已不記得是誰——把討論的內容做了一番整理，並下了一個註腳：「或許……系統運作的主要問題，技術性的成分還沒有社會性的成分來得多。」 　　這個結論，過了好一會兒才被接受，因為這跟以往我們所想的完全不同。我們，以及同在高科技產業奮鬥的每個人，都深信技術就是一切，不管什麼問題，都一定可以用更好的技術來解決。然而，要是所面臨的問題根本是社會性的（sociological），那麼，更好的技術似乎就幫不上忙。例如，一群人工作在一起，卻彼此不信任，即使有很棒的軟體或工具，也起不了作用。 　　這個想法一搬上檯面，我們就開始尋找範例，很快就非常清楚，在我們大部分已知的專案中，社會性的複雜完全阻礙了所有真正要克服的技術挑戰。此外，我們也面對一個惱人的事實：儘管內心深處，可能早就明白社會性的問題比技術性還大，我們兩個都不曾基於這樣的觀點來從事管理。沒錯，我們有時會用一些措施，來幫助團隊更加合作，或釋放團隊的壓力，但這些作為，似乎從來沒有完全融入到工作中。 　　假如早一點認清人性面比技術面影響還大，我們會採取怎樣不同的管理方式呢？我們開始列出清單，利用手邊的馬克筆和透明膠片，把一部分清單內容加到投影片上，很輕率地就想著把這些點子實際呈現給雪梨的聽眾們。管他的！不論在美國或歐洲，雪梨都遠在半個地球之外，假如我們在澳洲搞砸了，回家後誰會知道？ 　　隔週，雪梨的聽眾馬上就被Peopleware的素材所吸引，並且帶有一點懊惱（顯然我們倆不是唯一以為光靠技術就可以管理的人），最棒的是，他們又補充了很多自身的例子，我們樂得引用。 　　從早期的海外嘗試到1987年本書初版問世，之間的差別，就在於後者累積了大量的工作調查和實證研究，這一切都是為了確認在工作環境的影響方面，哪些只是猜測（本書的第二部），以及，為了證實在團隊的動態學和溝通方面，我們所提出的一些較為激進的建議（本書的其他部分）。 　　拜《Peopleware》前兩版之賜，我們成了情報交換中心，匯集了許多技術專案中屬於人性面的想法，也因此督促我們必須持續擴展自身的想法。在這個第三版的新章節中，探討了以往不認為是問題的領導問題、會議文化、由看似格格不入的不同世代所組成的混合團隊，以及一個逐漸為大家所認清的事實，也就是我們最常用的工具不見得是助力，可能反而是阻力。 　　第三版的編輯和製作，歸功於Dorset House的Wendy Eakin和Addison-Wesley的Peter Gordon，同時，也要感謝我們大西洋系統協會長期共事的夥伴——Peter Hruschka、Steve McMenamin、James Robertson與Suzanne Robertson——為這三十年來的構想、腦力激盪、爭論、共餐，和友誼。 ——湯姆．狄馬克 緬因州坎登（Camden, Maine） ——提摩西．李斯特 紐約州紐約市（New York, New York） 2013年2月 第15章 談領導 　　在工作上，領導十分罕見，但到處都在談領導。公司總愛談領導。 　　他們所談的，通常都是怎樣巧妙地運用職權，達成特定的目標。身負領導之責的是管理者，所以他們把管理者送去接受領導力培訓，教他們學會運用自身權力，指揮底下的人辦事。由此看來，領導是依著組織階層由上而下發生的——在上的是領導者、下面的是追隨者。你被組織圖表中某個職位比你高的人領導，你又領導著一群職位比你低、直屬於你的人。 　　把領導當成壓榨的手段 　　一張令人敬畏的「激勵」海報寫著：「領導者的速度，決定整體的速度。」這種領導，就是用來壓榨員工的，意在拉高做事的量，而非做事的質。你之所以被領導，是為了叫你更賣力工作，做久一點，別再打混。 　　第一次世界大戰初期，有位年輕的俄國記者列夫‧達維多維奇‧布隆施泰因（Lev Davidovich Bronstein），把他在前線所觀察到的領導狀況，寫成報導文章寄回家鄉。這些信可能遺失過，但由於他後來易名為托洛斯基（Trotsky）並成為知名的革命家，這些信遂被保存了下來。其中一封信觀察到，除非提供配槍，否則年輕軍官完全無法帶領部屬上戰場。用槍領導，意味著你是站在後方「領導」，而這正是壓榨式的領導。在工作場合中，槍，換成了權力和職位。 　　服務型的領導 　　然而，最好的領導——會讓人津津樂道，由衷感激和敬佩的——往往不是透過職權，而是發生在象徵權力的官方階層之外。 　　每週，我都會去我家附近的球場打兩、三次網球，魅力十足的麥克帶領我們這群同好，他就是我們的領導者。決定配對的人是麥克：誰跟誰一組、誰對抗誰。進行調度的人也是麥克（一共16個人要安排在4個球場），我們每打完一場，接下來三場都會跟不同的人搭檔，他每次都配得很好，一場球打半個小時下來，望向球場另一端，看到的都是5比4、6比6、7比6、5比5這類比數。他有個大嗓門，遠在三個球場之外，都還聽得到他的聲音。約定打球時間、協調球場時段、有人離開時找人遞補，麥克都做得很好。沒人叫麥克做這些事，他自己跳出來做，他的領導無庸置疑；由他當頭，大家都對這份好運感到敬畏。他沒有什麼報酬，但是贏得了我們的感激和尊敬。 　　——狄馬克 　　在這個例子當中，領導並未從我們身上榨取任何東西，它是一種服務。像麥克這類人的領導，努力才會有成效。有時候他們會指出努力的方向，但他們主要是扮演催化劑，而非指揮官。他們就是有辦法施展這種魔法。 　　為了不靠職權來領導——沒人指派你當頭——你必須像麥克那樣： 　　主動站出來。 　　使自己看起來適任。 　　預先做好必備的功課。 　　讓每個人的價值極大化。 　　保持幽默和高度的善意。 　　這些都有助於營造領袖魅力。 　　領導和創新 　　在組織中，能夠不靠權力來領導的人，他們也會有能力創新，擺脫組織給予的限制。創新跟領導絕對有關，領導也跟創新分不開。缺乏其中一種，必然導致另一種的枯竭。 　　創新這件事，說與做的比例比領導更誇張。在大部分公司，管理高層都會談論有關創新的一種有趣遊戲，政策宣示如下：「為了生存，我們需要創新，這非常重要，重要到再怎麼強調也不為過，不，各位，創新真的、真的很重要，這是大家的責任，事實上，這可能是每個人最重要的責任，聽好，全部給我回去好好創新。」唉！ 　　沒人會花任何時間創新，因為每個人都百分之百忙碌。 　　不管何種創新，顯然都不受歡迎，因為都需要改變。 　　真正的創新，影響層面可能超出創新者所屬的領域，他可能會被質疑從下層來管理組織，對此，管理高層通常抱持疑慮。 　　此處的重點是，就算最棒的創新，也需要一點反叛，才能成功——反叛式領導（rebel leadership）。創新者本身不必然是偉大的領導者，但某個人必須是。在這個過程中，反叛領導能給創新一些時間——讓某位關鍵人物脫離常規工作（對你而言，這或許構成了建設性違規），以推動一個尚未成形的願景——不論何種組織再造，為了換取創新的實現，都必須有這種強力的支持。 　　由於從來沒有人知道下一個創新會怎樣改變組織，因此對於應該給這位關鍵的煽動人物多少權限，人們總是猶豫再三。這也就是為什麼服務型的領導，總是在沒有被正式許可的情況下運作。 第21章 一加一大於二 在職場上，我們往往會濫用團隊一詞，把被指派在一起工作的任何一群人都稱做「團隊」。但這其中有許多根本不像團隊，他們彼此對成功的認知都不一樣，也感受不到任何團隊精神，總覺得缺少了什麼──缺少的是我們所謂的凝結（jell）現象。 　　凝結團隊的概念 　　一支凝結的團隊，就是已經緊密結合到整體力量大於個別力量總和的一群人。這種團隊的生產力超過同樣一批人處於非凝結狀態下的工作成果，同樣值得一提的是，他們從工作中所得到的快樂也超乎你預料工作本身所能給予的。有時，即使公認為超級無聊的工作，凝結的團隊也照樣能樂在其中。 團隊一旦開始凝結，成功的機會便大幅提升，而且在追求成功的道路上勇往直前，管理這樣的團隊儼然是一大樂事，你大部分的時間只是在幫他們清除障礙，把路開好，免得旁人礙手礙腳：「他們來啦，各位，請讓開點，抓好你的帽子。」你不需要用傳統觀念來管理他們，他們顯然也不需要加油打氣，他們本身就充滿幹勁。 之所以會有這樣的效果，說來並不複雜：團隊與生俱來就是圍繞著目標形成。（想想運動團隊：沒目標它還能存在嗎？）團隊在凝結之前，其中的成員或許各自擁有不同的目標，但逐漸凝結之後，他們都會接受共同目標。企業目標之所以格外重要，便在於該目標對團體的意義，即使目標本身對團隊成員來說可能是任意的（arbitrary），他們還是會精神抖擻地盡力達成。 　　過分樂觀的管理 　　有些經理人可能受不了前面的論點，他們對於任何促使員工接受企業目標的計策都非常反感，為什麼要在這上頭煞費苦心呢？畢竟，員工如果夠專業的話就該接受老闆的目標，這也是受雇條件，這才配叫專業呀。 相信員工會自動接受組織的目標，正是管理上天真、過分樂觀的象徵。任何人認同組織目標的歷程其實都相當複雜，例如，某個你所認識的資料庫專家卻更喜歡自稱是一位父親、童軍領隊、或當地教育委員會的委員，你不會覺得這有什麼好驚訝的，他在扮演這些角色時，總是會做出設想周延的價值判斷。如果他來上班時不再做價值判斷，那才令人驚訝呢。他會的，他會持續地檢驗一個個對他個人熱情與忠誠的要求。在組織裡工作的人們會持續密切觀察組織的目標，而其中大部分都會被認定為專制、任意的目標。 身為老闆，此時陷入了兩難局面：你或許接受了企業目標（以低於75萬美元的預算，在明年四月前完成專案），而且是心悅誠服地接受，然而，你的部屬可沒那麼熱中。你很失望，他們的冷漠對你來說可能有如背叛，不過，等等，你自己對企業目標所抱持的強烈熱情，有沒有可能是源自於專業以外的部分？你的老闆或高層難道就沒有耍些小手段，好讓企業目標變成你的目標？若達成公司的使命，肯定會為你帶來更多權力與責任：「今天是阿魯巴專案，明天就是征服全世界！」組織裡所有更高的職位對每一位管理者都非常管用，都可以誘使個人接受企業目標，唯有最下層，也就是真正執行工作的人，這一招無效。我們除了倚賴「專業精神」之外，沒有什麼可以保證大家會朝共同的方向邁進。老天保佑。 系統的建立是一種任意性的目標，但團隊接受了，團隊正是圍繞著這個目標而形成的。從凝結的那一刻起，團隊成員付出心力的真正焦點就是團隊本身，身在團隊，為的就是要一起追求成功，以及達成目標的喜悅，只要在一起，隨便什麼目標都行。要求他們把對專案的注意力轉移到公司利潤上，不會有任何幫助，反而會使成功變得微不足道，並且失去意義。 對於達成目標具有強烈動機的經理人可能會注意到，達成目標的並不是團隊，而是團隊裡的人，事實上，所有為達目標所需的工作項目都是由團隊裡的個人來執行，這些項目大部分都是由單獨工作的個人所完成的。 我們的工作多半都不太需要真正的團隊合作，但團隊還是很重要，因為團隊的作用在於把大家導入同一個方向。 　　團隊的目的並不在於達成目標，而在於統一目標。 　　當團隊朝目標邁進時，團隊成員會因方向更正確而更有效率。 　　凝結團隊的特徵 　　凝結團隊誕生時，有一些顯著的徵兆，最明顯的就是低離職率，在專案期間，工作已律定明確正在進行，事情沒有做完，團隊成員不會想去任何地方。原本很重要的事物（金錢、地位、升遷），到了凝結後卻變得不再那麼重要，人們當然不會為了多一點點薪水這種老掉牙的理由而離開團隊。 　　凝結團隊通常有強烈的認同感，那些為業界津津樂道的團隊都各自擁有生動活潑的名稱：奇異的「Okie編碼人」（Okie Coders）、杜邦的「四人幫」（Gang of Four）、辛辛那提瓦斯暨電力公司的「混沌小組」（Chaos Group）。團隊成員可能有固定的口頭禪、許多共同的玩笑，可能有明確的團隊活動的地方，可能會一起吃中飯，或下班後一同去酒吧裡鬼混。 好團隊也會有優越感，團隊成員自命不凡，自認比世人優秀，他們趾高氣昂、以霹靂小組自居的態度，惹得團隊以外的人很不高興。 凝結團隊通常認為產品共同擁有，參與人員喜歡把自己跟大家的名字一起放進產品，或成為產品的一部分，每個人都熱中參與同儕審查，接近完工時，也會用產品圖片來布置團隊空間。 凝結團隊的最後一項特徵，就是明顯樂在其中。凝結團隊就是令人感到很健康，互動輕鬆、自在而溫馨。 第2章 做起司漢堡，賣起司漢堡 產品開發工作在本質上就跟產品製造不同，但從事開發工作的經理人，其思維還是常常承襲了製造業的管理哲學。 假如你是一家速食連鎖店的經理人，採取以下促進生產力的措施相當合理： ● 絕不容許錯誤，盡量讓機器（人力機器）的運作平穩順暢。 ● 嚴禁員工上班時間打混摸魚。 ● 將員工視為可替換的機器零件。 ● 盡可能維持穩定狀態（甚至不准思考如何運作得更快，或怎麼停下來）。 ● 程序標準化，一切都按規矩來。 ● 不必實驗──那是總部的人該做的事。 倘若你從事的是速食業（或任何製造業），以上做法相當合理，但你不是。把「做起司漢堡，賣起司漢堡」的心態帶到開發領域，後果恐怕不堪設想，不但打擊部屬士氣，還會使他們不再專注於手邊真正的問題，這種管理風格與開發工作完全格格不入。 要有效管理腦力工作者，就必須採取與上述幾乎相反的措施，接下來便是我們提供的相反方案。 　　允許犯錯 　　對大多數腦力工作者而言，偶爾犯錯是工作中既自然又健康的一部分，但卻經常與聖經裡所講的罪惡劃上等號，這個心態要費很大的功夫才能改變。 醞釀不容許出錯的氣氛，只會使人產生防衛心理，不再敢嘗試可能導致不良後果的事。當你嘗試將流程系統化，引進嚴苛的方法論（methodology），使部屬為了避免犯錯而無法做出任何重要決策，便助長了這種防衛心理。你為禁止犯錯所採取的措施，或許能提升一點點技術水平，但團隊社會學將深受其害。 相反的做法就是鼓勵犯錯，偶爾不妨問問部屬曾經走過哪些死胡同，並讓他們知道「一個也沒有」並非最佳答案。要是有人對死胡同津津樂道，請恭喜他──這正是公司看中他的原因之一。 　　管理：膚淺的定義 　　管理很複雜，以致於很難給它下一個簡單的定義，不過，我們在倫敦一場專業協會會議上遇到一位資深經理人，他倒是把這一切看得很單純，並用一句簡單的話總結了他的想法：「管理就是踢屁股。」這相當於說，管理者負責所有思考，底下的人只需照辦。這對製造起司漢堡也許可行，但對靠腦力而非勞力工作的人卻行不通，在這種環境裡的人必須讓腦子運轉順暢，踢他屁股或許能讓他動一動，卻無法促使他發揮創意、發明與思考。 就算踢屁股真能提升短期生產力，長遠來看卻可能沒什麼用：對任何員工來說，自己的衝勁已低到得靠上司助其一「腿」之力，再沒有比這種感覺更令人洩氣的了。 踢屁股管理最大的悲哀，在於根本多此一舉。你很少需要採取嚴厲手段才能讓部屬工作下去，因為大部分的人都熱愛他們的工作，甚至你有時還得想辦法讓他們少做一些，以便完成更多有意義的事（請參考第3章）。 　　我們沒有時間思考工作，只有時間做工作 　　 當你奉命完成一項工作時，你的時間有多少比例會用在實際去做這項工作呢？絕對不是百分之百。應該會把一些時間用在腦力激盪（brainstorming）、調查新方法、想辦法避免做次要工作、閱讀、技能訓練，甚至打混。 我倆都認為，當年我們自己擔任經理人的時候，也都沒有把這件事做對，我們花太多時間去嘗試把事情做好，卻沒有足夠時間提出一個關鍵問題：「這件事真的該做嗎？」穩定狀態的起司漢堡思維，讓我們連嘴上說說關於工作的想法的時間都沒有，只知全心全意做事。若要為沒時間思考找藉口，則此藉口通常是時間壓力──但是難道有不受制於時間壓力而完成的工作嗎？ 當風險升高時，多思考的重要性就大幅增加。遇到真正困難的工作，就必須學習以更少時間做事，而以更多時間思考工作本身。工作越艱險，團隊成員學習良好互動與相處融洽就越重要。如果專案訂了一個不可能達到的完成日期，那更不能不經常進行腦力激盪，甚至還得舉辦專案餐會或類似活動，以促進團隊成員更有效率地合作。 但這些都是天性，大家都知道，也會這麼做，是嗎？錯。我們一心一意做事，而只有不到5%的時間是花在規畫、調查新方法、訓練、讀書、預估、編預算、訂時程與安排人力（5%是來自於分析系統開發專案的結果，不過應該也適用於更廣泛的情況，甚至所有類型的受薪工作者）。 　　 第10章 腦力時間與身體時間 一如第9章提及的IBM聖塔特瑞沙辦公室研究，建築師麥丘及其同僚曾在動工前，試圖了解開發人員在從事不同工作模式時所耗費的時間。根據他們的結論，典型的員工一天工作時間分配情形如表10.1： 表10.1開發人員如何運用時間 工作模式 耗費時間百分比 單獨工作 30% 與另一人工作 50% 與另兩人或更多人工作 20% 從噪音的觀點，此表的重要性不言而喻：員工一天之中有30%的時間對噪音很敏感，其餘時間則是噪音的製造者。由於工作場所中，有單獨工作的人，也有在一起工作的人，工作模式衝突在所難免，而單獨工作的人所遭受的干擾最大，雖然他們在任何時候所占的比例都不高，卻不能忽略他們。一個人真正做工作的時間是在獨處時，其他時間則多用於次要活動、休息和聊天。 　　神馳 　　當一心一意埋首工作時，人會進入一種理想狀態，心理學家稱之為神馳（flow）。神馳是一種有如冥想、深深沉醉其中的狀態，人在這種狀態下會產生一股陶醉感，而且時間是在不知不覺中流逝：「我埋首工作，一抬頭，已過了三個小時。」不會有累的感覺，工作似乎是順其自然地往前進展。想必你一定經常處於這種狀態，我們在此就不多贅言。 並非所有工作者都必須進入神馳狀態才具有生產力，但從事工程、設計、研發、寫作或其他類似工作的人，則必須處於神馳狀態，因為這些需要高度集中精力的工作，只有進入神馳狀態才會做得好。 很不幸，神馳狀態並不像開關一樣說打開就能進入，進入主題之前需要緩慢地沉澱，先投入十五分鐘或更久的專心，而且在這段心靈洗滌的期間，你對噪音和干擾會特別敏感。干擾多的環境會讓人很難或無法進入神馳狀態。 就算已進入神馳狀態，仍然會被針對你而來的干擾（例如，你的電話）或頑固的噪音（「注意！呼叫王小明，王小明請撥分機……」）而中斷神馳。每次中斷，就必須從頭再來一段心靈洗滌，心靈洗滌的時候，你並沒有真正在工作。 　　除了喪失有效的工作時間，伴隨而來的挫敗感也很要命。一次次試圖重返神馳狀態，卻每次都被打斷，員工不會有好心情，處於箭在弦上不得不發之際，卻落得硬生生被拉回現實，渴望專注思考卻不可得，還得不斷把心力用在適應現代辦公室強加在他身上的各種混雜指令間的切換。 這種情況若經常發生，大概所有人都要準備找新工作了。身為管理者，你也許比較不能體會無法進入神馳狀態的挫敗感，畢竟，你大部分的工作就是干擾別人──這就是管理──但為你工作的人需要進入神馳狀態，任何妨礙都會有損其工作效率與滿足感，此外，也會增加完成工作的成本。 第30章 與風險共舞 　　在我們的書《與熊共舞：軟體專案的風險管理》（Waltzing With Bears: Managing Risk on Software Projects，中譯本經濟新潮社出版）當中，提到了兩種極端不同的行為：一端是冒險，卻不做風險管理；另一端是過分保守，使得任何雄心壯志都變得不可能。目前，我們看到有越來越多組織，在管理上同時犯了這兩個極端的錯誤：所承擔的風險，都是毫無意義的一類，而另一類象徵創新價值的風險，卻避而不碰。 　　本書立論的前提——我們所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題——用在風險的領域上最貼切不過了。風險管理的技巧已經廣為人知，要是無法做好，原因很可能是跟組織的政治和文化有關。 　　面對風險，別只是逃避 　　首先值得一提的是，專案有風險是好事，因為這通常是有價值的特徵。風險很小或沒風險，卻真的還有價值的專案，早就被別人做光了，到今天還剩下的，都是有風險的專案。 　　想像一下，你承接了一個專案：邦諾書店（Barnes & Noble）僱用你來為它的電子書閱讀器Nook建置一套軟體。你面對的挑戰是：你的頭號競爭對手亞馬遜（Amazon）已幾乎搶占整個市場；你起步太晚；你的裝置跟別人相比，沒有特別的優勢（在相同技術背景下）；你根本還沒開始跟出版商談電子版權；你可能永遠跟不上亞馬遜可供應的電子書數量。你怎麼辦呢？ 　　實際上，當時在那個位子上的人們，是在冒一個巨大的風險。他們決定提供一種競爭者還沒想到的東西：電子書借閱系統。但想想落實這一切所要做的事：不只要和出版商協商，還得跟圖書館、作者合作；要建立並實作出網路借閱通訊協定；要為讀者開發軟體，當借期一到，得把書設為逾期；還需要一套版稅系統，用來把版稅支付給作者。風險，風險，又是風險，就算承擔了這些風險，航行在未知的水域上，還會有另一個風險，就是到頭來發現根本沒有市場，天曉得到底有多少潛在的借閱需求？ 　　在此案例中，這些風險都已值回票價：Nook異軍突起，已在市場上佔有一席之地。 　　思考一下，你專案的風險列表看起來如何。可能有很多東西都搞錯方向，而管理這些東西卻佔掉了你工作的一大部分。我們敢打賭，假如你肯擬訂——很隨興地——一份所有風險的簡單列表，其中一定有重要但被你忽略的風險。 　　那個我們不想去管理的風險 　　我們不想管理的，通常就是會導致失敗下場的風險。假如你和你所帶領的團隊，必須和遠在幾千英哩、十多個時區以外、連聽都沒聽過的城市裡的一家承包商打交道，當然，你會把承包商無法履約這一條，擺在風險列表的最前面。不過，如果是你自己的團隊完成不了自身所負責的目標，這種風險又當如何？你當然會擔心，或許午夜夢迴都會嚇出一身冷汗，之所以不把這部分放進風險列表，原因可能是它看起來像是失敗主義，引進了一個讓自己無法履約的風險。畢竟，找你來，就是要保證能夠履約，這是你的職責。 　　為了了解為什麼不管理這種風險是很危險的，你必須仔細思考風險管理的初衷：並非把風險變不見，而是當風險發生時，能夠啟動合理的紓緩（mitigation），而紓緩作為是必須規劃完善、預先備妥的。 　　惡名昭彰的丹佛國際機場（Denver International Airport, DIA）自動行李處理系統（Automated Baggage Handling System, ABHS）就是一個例子。當局做出了必須如期完工的重大決定，根本不把無法履約（延期交貨）視為風險，因為這種事根本就不允許發生，所以它不可以是風險。結果，此一風險因為管理上的命令而被輕易放過。 　　假如它有被管理，就勢必要預先規劃出一套人工或半自動化的備援方案，到時新系統做不出來，行李還是可以搬運。可惜它沒有做，結果一延宕，機場也被迫延後啟用，資金因為卡在功能不齊備的機場一年多而衍生的成本，最後高達數十億美元。 　　等風險成形，到了啟用日期還交不了貨，這時才開始做紓緩規劃也來不及了。從另一方面來看，倘若事先能備妥紓緩方案，靠著舊式、暫時性的人力和小貨車來搬運行李，機場就能啟用，就算軟體系統延宕，除了令人不太滿意之外，也不會有更多損失。若是能這樣的話，丹佛國際機場的自動行李處理系統也就不會眾人皆知了——除了參與過該專案的人之外。 　　如果風險發生的機率非常低，不去管理就非常合理；但如果風險發生的結果「光用想的就很可怕」，還不去管理，就很沒道理。 　　為什麼無法履約的風險常常沒人去管理 　　當結果被界定為一項挑戰時，辦得到（can-do）的思維經常凌駕於風險管理。為了挑戰，人們挺身而出，大家都喜歡挑戰，也擅長證明自己具備克服困難的能力；唯一不想做的，就是花時間規劃並為自己的失敗預做準備。時間很寶貴，尤其當必須在時程緊迫下完成挑戰時，更是如此；時程越要緊，就越沒有時間做紓緩規劃，也越少人會做。 　　這還不算太糟。假如管理者和他的團隊不做風險管理，總要有其他人去做。在這種情況下，最棒的專案經理會說：「瞧，我們很樂意面對這項挑戰，交付日期頗令人擔心，但我們會盡全力達成。盡全力還達成不了的風險，我們沒空管理，但有更適合的人去管。針對延期交付的後果，除非已看到做好了專門的規劃，否則我們不能把這個案子視為挑戰，那比較像是一場愚蠢、不顧一切的賭博。」 　　把想要的結果塑造成一項挑戰，是許多中階管理者和長官們擅長的伎倆，挑戰經常被包裝成一個證明自己卓越的機會。不過，他們所嘗試的，有很多並非驅使團隊走向卓越，而是要團隊用低廉的代價完成專案。滿荒謬的，專案可帶來的收益越有限，以廉價完成的重要性就越高。這沒什麼好驚訝，以廉價完成來掩飾糟糕的收益，並不是什麼高明的激勵手段，於是，負責專案的長官們或許會這麼說：「這次的任務非常重要，所以我們一定要在一月一日前完成。」其實真正的意思是：「這次的任務非常不重要，所以我們在一月一日之後將不再投入資金。」 　　這是一種假挑戰，但團隊和團隊領導者可能並不知道這一點，因此可能扛下緊迫的交期，並為此全力以赴。而趕工過程中，所有的風險管理都是做假的。 　　假挑戰通常都具備同樣的特徵：收益很小（這是因為組織過分保守，不願承擔任何真正技術風險的後果）、時程風險很大（卻往往未受到管理）。歡迎同時光臨這兩個極端。 第四部 培育高生產力的團隊 請你回想在過去的職場生涯中，最讓你樂在其中的一次工作經驗。那次經驗為什麼讓你樂在其中？答案再簡單不過，「挑戰」。良好的工作經驗通常伴隨著某種程度的挑戰。 現在，請再回想那段期間，特別令人愉快的回憶。就像錄影一樣在你腦海中播放，也許是一場會議、一段閒聊、通宵熬夜，或熬夜後的早餐。假如你也像我們一樣，這些回憶既鮮明，又出乎意料地完整，那你甚至還能聽到當時的聲音，以及每個人所講的話，還可以看到大家臉上的表情，整個情境依舊清晰。現在，請將腦海中的錄影凍結，仔細檢視停格的畫面，挑戰在哪裡？我們敢打賭，這段回憶裡根本沒有挑戰，就算有，也只是遠處背景的一部分。 　　最令我們回味無窮的，是前景部分的團隊互動，當一群人結合成一個有意義的整體時，整個工作的本質便大為改觀。這份工作的挑戰相當重要，然其重要性並不在於挑戰中或挑戰本身，而在於它使我們一起專注於某些事物。挑戰是促成我們同在一起的媒介，最佳工作小組的成員總能樂在其中並發揮到極限，團隊互動就是一切，這是使人堅持下去、全力以赴、克服艱難的原因。 當團隊結合在一起時，人們的表現會更好，也會擁有更多樂趣。第四部分我們將探討成功凝聚團隊的概念，以及有助於形成這種團隊的做法。

作者：湯姆．狄馬克(Tom DeMarco)、提摩西．李斯特(Timothy Lister) 譯者：方亞瀾、錢一一 出版社：經濟新潮社 書系：經營管理 出版日期：2014-12-23 ISBN：9789866031632 城邦書號：QB1120 規格：平裝 / 單色 / 336頁 / 14.8cm×21cm