死亡之旅

用戶評論 (總計7條)

•   　　這首先是一本教讀者審時度勢的書。對於一個死亡之旅的項目，如何去判定？看項目發(fā)起人，項目發(fā)起的背後真正原因。遭遇這樣的項目時，是戰(zhàn)還是離？“具體情況具體分析”，看你的上司是誰，是一個什麼樣的人，這是一什麼樣的項目，神風(fēng)特攻隊？自殺還是醜陋的？還是？
  　　決定留下來，一定要明確真正的目標(biāo)和真正的需求，要與干系人談判、溝通、發(fā)佈這個目標(biāo)。這個目標(biāo)會遭到很多人和因素的干擾，項目經(jīng)理就要排除這種干擾。需求是可以分類的，變化的、動態(tài)的，要捕捉它。
  　　死亡之旅的目標(biāo)是在有限的資源（時間、人力、技術(shù)、資源）下，完成可用的交付，而不是過程。任何不能促使這個目標(biāo)實現(xiàn)的活動、技術(shù)，都是不值得採用的。
  　　團隊的形成是有規(guī)律的，是一個動態(tài)的，追求的是“動態(tài)平衡”。團隊的產(chǎn)出率有其上限，“人月神化”是不存在的。
•   　　在軟件工程的圖書中，《死亡之旅》是本相當(dāng)奇特的書。它并沒有講一個軟件工程方法，而是在講一種軟件工程實施中的現(xiàn)象。
  　　
  　　“死亡之旅”（Death March或者譯為“死亡行軍”）項目是這樣一種現(xiàn)象：在軟件開發(fā)中，軟件要素的制約與軟件目標(biāo)存在一倍及以上的差距。這些要素可能包括人才、時間等方面。如果你接到了一個需要一個5人團隊半年時間才能完成的項目，卻被要求三個月完成。這個時候，你的團隊就在死亡行軍了。在這本書中，作者對死亡之旅現(xiàn)象產(chǎn)生的原因、環(huán)境以及身處死亡之旅項目中的人的種種遭遇、困難、行為都有介紹。
  　　
  　　
  　　為什么會產(chǎn)生這種死亡之旅項目？
  　　
  　　這個話題就足夠討論很長時間，書中也討論了很多可能的原因。結(jié)合我個人的項目經(jīng)歷，我認為現(xiàn)實環(huán)境中最容易出現(xiàn)的原因是管理層的盲目自大，還有一線開發(fā)者沒有話語權(quán)。從某種層面來說，這兩種原因通常都會同時出現(xiàn)。管理層永遠都是容易盲目樂觀的，特別是進行內(nèi)部管理時。由于身處高位，他們都通常更容易獲得來自中層管理者的過多樂觀匯報。如果管理者自認為曾經(jīng)從事過基層技術(shù)工作，那就更容易自認為對技術(shù)了如指掌，一切都盡在掌握?！罢夷銈儙讉€低效的程序員來搞只是因為老子沒時間”。實際上項目的復(fù)雜度總是比從外面看上去更高的。一個簡單的原因是一個系統(tǒng)需要應(yīng)付所有可能的輸入，甚至異常情況。而外觀上人們只能看到簡單的關(guān)鍵路徑。對于習(xí)慣了在線付款的你根本看不到支付系統(tǒng)在背后為多少種信用卡異常編寫了代碼，因為你可能一輩子也遇不上數(shù)據(jù)庫異?；貪L。所以，一個技術(shù)出身的領(lǐng)導(dǎo)者更容易作出愚蠢的決定，確信那些明顯脫離實際的項目資源評估。因為他們像其他高管一樣樂觀，卻比其他高管更自信，所以，很多“悲劇”就上演了。
  　　
  　　對于書中提到的其他客觀因素，我倒不太認為會很嚴(yán)重得引發(fā)死亡之旅項目。企業(yè)的競爭壓力確實在增加，但如果意識到這是個死亡之旅項目，理智的高管也不太可能做出決定，因為這很有可能導(dǎo)致投資損失，并且耽誤那些本可以爭取到的市場機會。當(dāng)然，如果由于政治原因做出決定，除了自認倒霉沒有任何話好說。
  　　
  　　
  　　如果不幸遇到死亡之旅項目，作為項目經(jīng)理或者一線研發(fā)工程師，你還有什么可選擇嗎？
  　　
  　　走為上計。我認為書中提出這個方案是很嚴(yán)肅的。出現(xiàn)這種很不理智的決定本身已經(jīng)說明了整個組織存在著過于草率或者不夠客觀的決策，存在著很大的風(fēng)險。如果確實出現(xiàn)了這樣的問題，一走了之沒什么不好，只是很多時候我們走不了。
  　　
  　　挺過難關(guān)。這是最常見的一個選擇。一般情況下，作為下屬，無奈得忍受上級決定已經(jīng)成為習(xí)慣。你可以有一些可選擇的方案來減少困難。例如對一些項目的不重要因素降低要求；想辦法激勵團隊或提供更高待遇。（換幾個更有效率的工程師？申請獨立的工作環(huán)境？提高團隊伙食？）在死亡之旅的路上，除了路途中的艱難，還有可怕的終點審判。要學(xué)會通過一些方式讓管理層更好地接受這個結(jié)局，也是挺過死亡之旅的關(guān)鍵因素。
  　　
  　　還有第三種選擇嗎？也許有，但是幸運的人畢竟是少數(shù)。軟件開發(fā)是一個有伸縮性的工作，核心的制約是開發(fā)人員的工作效率。如果有辦法通過所有可能的方式提升開發(fā)效率，甚至在總體上提升一倍，那么你就真正贏得了死亡之旅的全程！有哪些因素可以考慮？
  　　
  　　 減少開發(fā)人員的無關(guān)工作（填寫毫無意義的工作報告；減少開發(fā)人員被郵件和電話打斷的機會）
  　　
  　　 在制度和團隊風(fēng)格上打消成員的內(nèi)心障礙（例如“反正要加班，不如白天少干點”）
  　　
  　　 切實得激勵團隊成員，讓大家忘掉項目的不明朗前景
  　　
  　　 識別項目障礙并小心引入工具
  　　
  　　真的會有將團隊生產(chǎn)力提高一倍的可能嗎？是有的，但機會不多。團隊的改進空間有限，在巨大的壓力下又不能付出過多的學(xué)習(xí)成本，所以希望不大。同時，加班和工具對提升團隊產(chǎn)出的影響也不可能達到如此大的比例（想想老生常談的“沒有銀彈”）。
  　　
  　　所以想擺脫死亡之旅項目真正的希望還是要靠更了解軟件工程規(guī)律的管理層和決策體系，更有說服力的評估方法和敢于指出問題的組織氛圍。
  　　
  　　同步發(fā)表在我的博客 http://hi.baidu.com/thinkradar/item/84a588936fe0771f336eeb5b
•   　　最近很流行美國大學(xué)的哲學(xué)課程，死亡啦，幸福啦，在書店乍一看到，還以為是這一類的書呢?！端劳鲋谩凡⒉皇侵v那些終極問題的，而是把它落實到具體的生活中，就是那些令人抓狂的項目及其管理上。
  　　
  　　軟件開發(fā)項目是越來越多了，“死亡之旅”類型的項目也愈發(fā)的多起來了。死亡之旅的項目有諸多細分的類型，也有不同的原因所導(dǎo)致。有的是管理層的一意孤行，有的是年輕工程師團隊的自掘墳?zāi)?，有的是突如其來的危機導(dǎo)致，有的則是滅亡前的最后一搏。
  　　
  　　總體來說，對于理性的個人而言，此類“死亡”項目還是“避之則吉”。但是，最后參與其中的，又都各有各的理由。離職的成本太高，要出一口惡氣，妄圖一戰(zhàn)成名，或者是光榮的最后一搏。其實有著眾多的理由讓人參與其中。
  　　
  　　那么一旦踏上了旅程，那就全力想著，怎么能活下來?！端劳鲋谩愤@是很好的求生指南，特別對項目經(jīng)理而言。
  　　
  　　政治上的溝通自然要順暢，還要找到靠山，不然要啥沒啥，和等死沒啥區(qū)別。
  　　
  　　各種談判自然力所能及的去討價還價，總要死的不是那么難看才好。
  　　
  　　挑選成員，必然是要能同心協(xié)力的，共赴黃泉的。不然有人腳底抹油，必然有人死無全尸。所謂不怕神一樣的對手，就怕豬一樣的隊友。
  　　
  　　在開發(fā)的過程中，有些工具要好好采用，例如XP，最佳實踐，但是務(wù)必要有趁手的家伙。有些工具看上去锃亮，拾起來卻不順手，最后讓人拿西瓜刀給切了。
  　　
  　　關(guān)鍵任務(wù)的安排和良好的時間管理在“死亡之旅”中更顯重要。爭分奪秒，運籌帷幄，才可能絕處逢生。
  　　
  　　當(dāng)我剛剛開始閱讀此書的時候，我以為是教大家如何識別死亡之旅，并且腳底抹油的。讀到后來才明白，原來是讓我們迎難而上的。在這不靠譜的世界里，忽悠是多么的重要。但是在忽悠的同時也有有真材實料，否則只能忽悠致死了。
•   　　臺詞控：
  　　快樂在于能夠長時間的為自己認為值得的事情努力工作，不管它是什么。一個人也許能夠從照顧妻兒之中找到快樂，而另一個人則可能在打劫銀行的犯罪行動中找到他，很可能還有人熱衷于數(shù)年投身于沒有明顯成果的純粹的研究工作之中。
  　　
  　　請注意每種情形的獨特個性。任何兩種情形都不會完全相同，而且你也沒理由做此期望。每個人都必須為自己找到雖然需要付出艱苦努力卻能令自己快樂的工作。反之，如果你在為自己尋求假期悠長而且能夠及早退休的輕松工作，那么你就已經(jīng)選錯了職業(yè)。也許你應(yīng)該去表演雜耍，甚至還可以投身政治。
  　　
  　　經(jīng)過仔細分析之后，我找到了一個復(fù)雜的定理用以解釋這種古怪的工作行為的存在：人們都是傻瓜。每個人都是傻瓜，我們的不同在于：我們會在不同的時間對不同的事物成為傻瓜。無論多聰明，你也會花費許多時間去做一個傻瓜。
  　　
  　　只要一起做事的人超過兩個，政治就必然存在。
  　　
  　　幼稚經(jīng)常與缺乏經(jīng)驗相連。
  　　
  　　“英雄們”的存在是人們的要求、需要和期望。如果只有他們才能挽救這個項目，他們就會確立自己在歷史中的地位。
  　　
  　　自尊、完美和真誠是讓神志清醒的人為何會同意參加這樣一個“死亡之旅”。
  　　由于珠峰類型的死亡之旅項目而興奮的不能自拔，那么你需要注意兩件事。首先，你需要提防事先就注定失敗的項目；第二件需要注意的是就是公司管理層口中大肆渲染的挑戰(zhàn)很可能根本就不重要；連續(xù)問兩到三遍“那又怎么樣？”是一個不錯的主意，將你拉回到現(xiàn)實世界?；蛘吣悴环劣梅羌夹g(shù)性的語言向自己的伴侶、“至關(guān)重要的另一半”、父母或向孩子解釋項目，如果你能回答他們問的所有問題，而且最終不覺得愚蠢之極，那么你答可以意識清醒地加入這個項目。
  　　不要忘記政治是此時的一個關(guān)鍵因素，那些因死亡之旅項目的成功而最終贏得聲譽的人并不一定就是項目的參與者。不僅如此，那個建議開始死亡之旅項目的經(jīng)歷很可能根本沒有考慮過項目組成員是否能成功挺過項目，他們很可能只是把重組“危機”用做自己步步高升的墊腳石而已。
  　　
  　　愚蠢的定義就是一次次用同樣的方式做同一件事，卻期待會有不同的結(jié)果。
  　　
  　　項目就像是一場婚姻，開始時，我們通常天真而充滿希望，但隨著現(xiàn)實的慢慢介入，我們不得不重新調(diào)整對這種關(guān)系的期望。讓人們開始一場婚姻的理由有很多，但它們往往沒有邏輯關(guān)系。
  　　
  　　讓項目中的每個成員都明白誰是關(guān)鍵玩家依舊非常重要。明白問題來自朋友還是來自敵人，以及他是否有可能具有政治含義將非常重要，不管你如何回答這個隨意的問題，答案都很可能被帶回到組織內(nèi)部，而且其中的信息常常會被夸張、歪曲和隱藏。
  　　認為所有玩家信息也是項目的一部分，所以最好讓每一個人（支持者、經(jīng)理、開發(fā)者）都了解這些信息。一旦你把任何與項目相關(guān)的信息對開發(fā)者隱瞞不報，項目離失敗就只有一步之遙了。
  　　
  　　聯(lián)合應(yīng)用開發(fā)（JAD）。項目經(jīng)理應(yīng)該努力從主要項目干系人處得到承諾：所有需要得到他們批準(zhǔn)、同意、評審的問題，都必須在24小時內(nèi)得到處理。
  　　
  　　一旦找出項目中的主要“玩家”，確定了項目類型，并且在項目經(jīng)理所希望的承諾水平與成員實際所能提供的承諾水平間進行了溝通，就可以著手開始實際項目工作。
  　　
  　　準(zhǔn)確評估每個項目團隊成員的承諾水平：
  　　1、 在組員看來，哪些事情比項目更重要，以及哪些事情沒有項目重要；
  　　2、 任何承諾聲明都只能表明團隊成員目前的感覺。
  　　
  　　人人都希望事情做得又快又好并且價格低廉。每個人都知道你可以達到以上三個目標(biāo)中的任意兩個。但問題是，你到底想要哪兩個？
  　　
  　　雖然你很可能無法讓他們改變項目的最后期限，但你卻又可能在為項目配備比普通項目要求多得多的人員。
  　　
  　　任何首席指揮官都不應(yīng)該去執(zhí)行連自己都認為有缺陷的計劃，它必須提出自己的理由并堅持對計劃進行修改。拿破侖
  　　
  　　與年薪90000美元的資深程序員相比，20%的加薪對與年薪30000美元的初級程序員更有意義。
  　　
  　　幾乎全部將系統(tǒng)需求劃分為“必須做”、“應(yīng)該做”和“可以做”三種類別。
  　　
  　　在死亡之旅項目中采用全新的陌生過程往往會導(dǎo)致災(zāi)難性后果，即便項目團隊全體成員都一致同意此過程將會有助于項目也不例外。因為學(xué)習(xí)曲線、對過程細節(jié)不可避免的困惑和爭論所帶來的損失往往會超過它帶來的益處。
  　　
  　　無論如何，在多數(shù)死亡之旅項目中，完美的可靠性、可維護性、可移植性并非必不可少，也并不實用，甚至可能毫無必要。
  　　
  　　我們怎樣才能做出“足夠好”呢？
  　　實用主義策略：在不明確的局面下進行定性分析和使用正面收益最大化的藝術(shù)。包括系統(tǒng)化思維、風(fēng)險管理、經(jīng)濟學(xué)、決策理論、博弈論、控制理論和模糊邏輯。
  　　發(fā)展的策略：不但要考慮項目生命周期，而且要用發(fā)展的眼光看待人員、過程和各種資源。
  　　英雄的團隊：團隊中并不都是天才，而是要用技術(shù)熟練的普通人的有效合作。
  　　動態(tài)的基礎(chǔ)設(shè)施：官僚體制和強權(quán)政治的對立面。在這種情況下，高級管理層會重視項目，重視市場，確定并解決項目之間的沖突，而且會在項目與組織的官僚體制發(fā)生沖突時給與項目強有力的支持。
  　　動態(tài)過程：過程能夠在不斷發(fā)展的寫作環(huán)境中對工作提供支持。
  　　
  　　在短期里程碑之后立刻安排半天的小型審計：哪些方法確實有效？哪些方法大大有害？為了達到下一個里程碑，那些應(yīng)該著重強調(diào)？哪些應(yīng)該拋棄？這種自省不但非常有助于項目團隊自身的改善，而且會為日后的死亡之旅項目團隊提供參考。
  　　
  　　避免災(zāi)難往往比追求完美更為重要。
  　　不要為預(yù)想中的“未來”需求做設(shè)計，而應(yīng)該為當(dāng)前需求提供可能的最佳設(shè)計。
  　　
  　　“結(jié)隊編程”重要主題：每個獨立的開發(fā)任務(wù)都有兩個軟件工程師共同承擔(dān)。這樣做有兩個好處。首先，在項目進行的過程中，如果其中一個開發(fā)人被傳說中的啤酒卡車撞傷，結(jié)對編程可以提供寶貴的“保險”；其次，在開發(fā)人以瘋狂的速度進行編碼時，兩對眼睛審查代碼通常會更快、更節(jié)約成本。
  　　
  　　缺乏方法和標(biāo)準(zhǔn)也能把一個項目變成一場死亡之旅。
  　　
  　　天天做就是項目的心跳，通過它你才能確定自己確實還活著。
  　　
  　　
  　　
  　　
  　　
  　　
  　　學(xué)會靜止，將你的注意力從你不喜歡的事物上移開，將注意力放到你希望體驗的事物上。
  　　
  　　
•   非常在理，感同身受！也許是正在一個“死亡之旅”中蹣跚前行，直奔死亡而去的緣故吧。技術(shù)出身的高管更自信，也更愚蠢，的確如此啊。技而憂則仕，飄飄然，一點不記得自己當(dāng)初在一線干活時的辛苦，只覺得自己牛的不一般，反而更看不起一線干活的，覺得比自己當(dāng)年差太多了，在此種心態(tài)下做的決策，可想而知。
•   http://programmers.stackexchange.com/questions/70755/are-long-hours-and-no-benefits-the-norm-for-a-junior-programmer
  這里也有人推薦了這本書
•   [連續(xù)問兩到三遍“那又怎么樣？”是一個不錯的主意，將你拉回到現(xiàn)實世界?；蛘吣悴环劣梅羌夹g(shù)性的語言向自己的伴侶、“至關(guān)重要的另一半”、父母或向孩子解釋項目，如果你能回答他們問的所有問題，而且最終不覺得愚蠢之極，那么你答可以意識清醒地加入這個項目。]
  這段話很精彩

相關(guān)圖書

• 超常規(guī)作業(yè)模式
• 商業(yè)銀行信貸與營銷
• 內(nèi)科門診實用手冊
• 企業(yè)財務(wù)制度論
• 計算機操作與使用
• 物流管理案例與實訓(xùn)
• 體育營銷
• 多媒體技術(shù)與應(yīng)用
• 國際經(jīng)濟法
• 分水嶺
• 簡明科技知識問答手冊
• 中國法理自覺的發(fā)展
• 策劃經(jīng)濟學(xué)
• 近代法律思潮與中國固有文化
• PowerPoint演說家(精要版)
• 計算機網(wǎng)絡(luò)技術(shù)實用教程
• 汽車熔斷器與繼電器速查手冊
• 類型和程序設(shè)計語言
• C語言程序設(shè)計教程與上機指導(dǎo)
• 中國電腦救援中心網(wǎng)經(jīng)典救援案例精粹
• 寶馬
• Windows 2000/XP WDM設(shè)備驅(qū)動程序開發(fā)
• 舊中國海關(guān)歷史圖說
• 數(shù)字視頻圖像處理
• 報關(guān)員資格全國統(tǒng)一考試160分應(yīng)試技巧及習(xí)題精練