項目經(jīng)理應(yīng)該知道的97件事

1、 HYPERLINK /showbook.php?id=100743&v=art o 查看原書 項目經(jīng)理應(yīng)該知道的97件事以往的軟件開發(fā)模式是先了解用戶的要求，然后再在極度神秘的環(huán)境下進(jìn)行編程測試。畢竟，用戶根本不知道我們在做什么，對吧？直至項目結(jié)束，我們的魔術(shù)師才會匆匆登場，揭去魔法布，然后期望用戶會對我們卓越的產(chǎn)品驚嘆不已。然而用戶此時的通常反應(yīng)是： “咳，好吧，我知道你們花了很多功夫，但我們真正需要的是”今天，項目成功的秘訣就是盡早向用戶展示任何可以展示的東西。如果能在項目啟動早期，而不是當(dāng)整個項目都結(jié)束的時候，就能發(fā)現(xiàn)項目中存在的問題，那該有多好??！隨著項目時間的推進(jìn)，變更項目的成本越

2、來越高。重新編碼、重新測試以及改進(jìn)當(dāng)前軟件的時間，加上整合外圍代碼進(jìn)行集成測試所花費的時間都會大大拖延項目進(jìn)度。如果變化非常重大，還可能危及時間和成本底線，需要經(jīng)過變更控制委員會一個漫長的批準(zhǔn)程序。在一些細(xì)小環(huán)節(jié)上做出的編程決策，或許對于軟件開發(fā)人員和項目經(jīng)理而言道理十足，可當(dāng)軟件投入使用后卻有可能給用戶造成巨大的混亂。我知道曾經(jīng)有一個大型的培訓(xùn)公司，花了500萬美元重新設(shè)計它的訂購軟件系統(tǒng)。此前，項目編號同訂購產(chǎn)品之間的匹配存在一定邏輯性。例如，4125可能是學(xué)生手冊，4225則是配套的學(xué)生練習(xí)盤，4325可以代表教師手冊，4425則是營銷宣傳時使用的課程大綱等。你可以在同一屏幕上訂購4X2

3、5系列的所有項目。 PHR，即 Professional in Human Resources（人力資源專家） ，是由美國認(rèn)證協(xié)會（American Certi- fication Institute）推出的在國際范圍內(nèi)比較權(quán)威的人力資源管理知識體系認(rèn)證資格。編者注每天，全球 140 個地方的行政助理一遍遍地反復(fù)訂購?fù)惒牧?，并很快記住了項目編號。一旦知道了學(xué)生手冊的編號，他們無須查看就可以立即鍵入其他項目的編號，這樣一來，訂購過程十分快捷。在重新設(shè)計時，不知何故，這個項目團(tuán)隊居然忘記考慮實際情況下真人是如何進(jìn)行訂購的。新的設(shè)計方式中，項目之間沒有邏輯關(guān)系。項目 6358 可能就是4125 曾

4、經(jīng)代表的學(xué)生手冊，而其配套的學(xué)生練習(xí)盤現(xiàn)在是 8872，而同一類教師手冊又是 3392。現(xiàn)在，不僅用戶不得不逐項查詢并試著“忘記”舊的編號和系統(tǒng)，而且同類產(chǎn)品的不同項目也會分別出現(xiàn)在不同的頁面上。行政助理們很憤怒。訂購過程慢得就像是蝸牛在蠕動。該項目最后遠(yuǎn)遠(yuǎn)突破了它的時間和成本底線。作為項目經(jīng)理，你應(yīng)該盡早并經(jīng)常讓軟件開發(fā)人員和用戶交談。2. 避免打地鼠式開發(fā)軟件項目經(jīng)理經(jīng)常面臨及早交付產(chǎn)品的巨大壓力。時間是關(guān)鍵。你如何才能快速完成任務(wù)呢？假設(shè)你的團(tuán)隊有兩名程序員，伯尼和羅布。兩人都很能干，知識面相同，編程語言技巧也相當(dāng)。你發(fā)現(xiàn)在開發(fā)過程中伯尼實現(xiàn)軟件功能的速度遠(yuǎn)遠(yuǎn)超過羅布。當(dāng)伯尼著力于快速完

5、成編程時，羅布正花時間寫代碼并對其進(jìn)行重構(gòu)。羅布對變量和方法的命名更擅長。一旦寫的程序能夠運行起來，他就把這個程序分成幾小塊?，F(xiàn)在他要寫測試來確保該程序的每一塊都能按照他的意圖運行。當(dāng)他覺得結(jié)果比較滿意時才宣稱實現(xiàn)了功能。但是假設(shè)你并不知道上述這些細(xì)節(jié)。如果你只看他們誰先宣稱實現(xiàn)了功能，那么很明顯伯尼表現(xiàn)得更好，對嗎？幾個星期之后，你向客戶演示這些功能。像往常一樣，顧客喜歡你已經(jīng)完成的功能，但現(xiàn)在需要你做一些改動和完善。你讓軟件開發(fā)人員修改這些代碼。當(dāng)你把新改進(jìn)的功能帶回給客戶時，他們試用了羅布實現(xiàn)的功能，對他做出的改動十分滿意。 重構(gòu)就是改動代碼，完善其內(nèi)部組成結(jié)構(gòu)而不改變其外部功能。它改進(jìn)

6、軟件產(chǎn)品設(shè)計。重構(gòu)代碼是回過頭去完善以前倉促創(chuàng)建并測試的某項可用的功能?，F(xiàn)在需要進(jìn)一步對該功能進(jìn)行內(nèi)部改進(jìn)，以便長期使用，也使日后增加功能更為方便。遺憾的是他們發(fā)現(xiàn)伯尼實現(xiàn)的功能有些奇怪。當(dāng)伯尼編寫好新的功能后，一些以前能使用的功能現(xiàn)在卻不能用了。客戶把這些作為缺陷標(biāo)記出來，然后你讓伯尼來修改。客戶又一次測試這些功能，結(jié)果后來新增的功能也不能用了。這到底是咋回事呢？如果你有孩子，就會知道發(fā)生了什么。伯尼創(chuàng)建的是一個打地鼠式的應(yīng)用程序。打地鼠是一種游戲，孩子們拿著一個木棒敲打幾個孔中隨意彈出的地鼠，他們會很驚奇接下來是哪個地鼠彈出來，而且還樂此不疲。然而，在修改應(yīng)用程序的時候如果總有壞代碼不知從

7、何處隨意彈出，那可不是好玩的事情。那會令人沮喪，結(jié)果也難以預(yù)料，并且它會減慢產(chǎn)品開發(fā)速度。伯尼一開始就全速沖刺，只是南轅北轍了。 盡管羅布從一開始就表現(xiàn)得較慢，但實際上他編寫的代碼更勝一籌。事實證明，他的節(jié)奏是可持續(xù)發(fā)展的。由于最初編寫的代碼就有較好的質(zhì)量，所以，他才能更快地做出可行的改動。而且他早期編寫的測試能隨時帶給他反饋信息，讓他了解自己新寫的代碼是否與原有應(yīng)用程序的其他部分兼容。 當(dāng)估計某一功能的實現(xiàn)時間時，不要只考慮最初寫代碼所花費的時間，還要加上提升、調(diào)整和改進(jìn)這些代碼所需的時間。寫高質(zhì)量的代碼和測試都需要花時間。從短期來看，這似乎是一種損失，然而它帶來的卻是長期收獲。問問自己，你

8、是想要速度還是想盡情享受可持續(xù)發(fā)展的樂趣。3. 一詞不慎壞大事哪一個詞會讓你錯過最后期限？答案是“任何一個詞” 。在開發(fā)一個將以非英語語言發(fā)布的產(chǎn)品時，你將給項目帶來許多新的風(fēng)險和限制。有些風(fēng)險和限制是技術(shù)性的，且顯而易見。例如，如果你的產(chǎn)品將投放日本，那么它必須支持適當(dāng)?shù)淖煮w。如果不支持，那么，即使英文版運行得很完美，日文版的產(chǎn)品也無法運行。但是，字體兼容性不受你的控制。你和團(tuán)隊需要特別注意的倒是一些特殊的翻譯譯法，并在編碼前就要考慮到這些因素，確保開發(fā)活動遵循有關(guān)國際標(biāo)準(zhǔn)，消除這類問題。僅僅是轉(zhuǎn)換成其他語言版本也會影響到你何時做何種決定。通常情況下，產(chǎn)品本地化（日語、瑞典語和德語等）與英語

9、版本的開發(fā)是同時進(jìn)行的，只是具有一定的滯后。滯后的時間可以是幾天，幾周，甚至幾個月。盡管如此，在某個時間點，外文版的翻譯必須要“趕上”英文版。在測試和審查階段，你需要確保：英文版里的內(nèi)容都可以被準(zhǔn)確翻譯過來； z翻譯過來的內(nèi)容同英文版是真正相符的； z翻譯版產(chǎn)品的運行沒有瑕疵。 z這里有一個問題。這三項事情可能是在英文版完成并批準(zhǔn)后才進(jìn)行測試的。在測試和審查本地化的版本時，你總會發(fā)現(xiàn)不止一個具有挑戰(zhàn)性的問題無法得到解決，除非回頭去改變英文版產(chǎn)品。然而，要知道，在英文產(chǎn)品里最后一分鐘所做的一個相對簡單和低風(fēng)險的改變，如改寫句子（這只需要幾秒鐘來編碼） ，卻往往需要好幾天時間來運行和重新測試所有本

10、地化的版本。這可能需要額外花費數(shù)千美元，尤其是當(dāng)你正和一家國外的公司簽訂翻譯合約時。經(jīng)驗不足的軟件開發(fā)項目經(jīng)理常犯的這個錯誤很簡單。他們就是低估了對英文版進(jìn)行意外更改所造成的影響有多嚴(yán)重。為了預(yù)防這種情況發(fā)生，你可以采取以下兩項主要措施。在進(jìn)度表最后加一個“本地化緩沖區(qū)” 。 z 進(jìn)度表的截止日期意味著與項目計劃中的英語產(chǎn)品相關(guān)的所有工作都必須在這個有效期限內(nèi)結(jié)束。在目標(biāo)結(jié)束日期之后做的任何改動，都必須符合非常具體、非常嚴(yán)格的標(biāo)準(zhǔn)，只有達(dá)到這個標(biāo)準(zhǔn)才可以“進(jìn)入”返工隊列。這個版本的任何變化都不可避免地引起其他外文版作出相應(yīng)變化。把這些任務(wù)排序，讓功能的質(zhì)量控制和英文文本的質(zhì)量審查分開來做。 z

11、這其實很簡單，甚至可以復(fù)制所有英文文本到一個電子表格里去進(jìn)行校對。這樣一來，如果有措辭不清楚的情況，我們就能立即發(fā)現(xiàn)它，而不必等到測試可運行的產(chǎn)品時才發(fā)現(xiàn)它。于是我們可以提前作出必要的改動，可能就不需要對所有其他的語言版本都進(jìn)行返工了。4. 讓項目發(fā)起人自己寫需求項目失敗并不是只有美國公司才遇到的問題。根據(jù)幾年前一家日本領(lǐng)先 IT雜志社進(jìn)行的調(diào)查，如果按照質(zhì)量、成本和交付期的標(biāo)準(zhǔn)來衡量，日本企業(yè)實施的項目中，超過 75% 都被認(rèn)為是失敗的。跟大多數(shù)其他國家一樣，在日本，項目不能達(dá)標(biāo)的首要原因幾乎總是需求定義太差。處境最危險的公司是那些業(yè)務(wù)分析能力較差的公司。由他們來做軟件開發(fā)這樣的技術(shù)項目時，

12、成功就被委婉地歸為“不可能發(fā)生的”事項。這一結(jié)果表明，要發(fā)現(xiàn)、識別并定義一個軟件項目的真實需求有多么困難。既然是這樣困難，很多項目所有人，如客戶、項目發(fā)起人或公司主管，就期望項目經(jīng)理能自己定義和細(xì)化這些對軟件的要求。項目所有人很少會提供指導(dǎo)或明確他們的需求。既然是一個軟件項目，而自己可能又不懂軟件開發(fā)，所以，他們認(rèn)為沒必要來親自定義自己的期望。而對于軟件項目經(jīng)理而言，他通常沒有權(quán)力或時間來自己發(fā)現(xiàn)、選擇項目需求并排定優(yōu)先級，尤其是當(dāng)該項目可能涉及多個利益團(tuán)體時，大家對軟件完成后應(yīng)實現(xiàn)的功能可能會有相互沖突的設(shè)想。項目經(jīng)理要在項目實施前花時間與資助該項目的人交流，幫他們準(zhǔn)確定義各自想要的功能。要

13、能夠迅速完成項目且只有少數(shù)錯誤，而且需要的預(yù)算盡可能地少，這難道不是最重要嗎？但你又不能一箭三雕。哪些資源和技能對創(chuàng)建所需軟件而言是至關(guān)重要的？資助人是否給團(tuán)隊提供了這些資源？軟件如何用于運行基礎(chǔ)架構(gòu)或為公司賺錢？時間期限是切實可行的嗎？這些時間限制是不是被寫進(jìn)客戶合同，是否綁定到某個重要的節(jié)假日，是否據(jù)此精心制作了一份營銷計劃？如果在需求定義階段沒有認(rèn)真、具體地考慮這個項目要創(chuàng)建什么，那么，這個項目可是岌岌可危了。請記住，項目所有人需要傳達(dá)的是他們想要這個軟件做什么，而不是程序員將如何著手生成這一結(jié)果。說服項目所有人，他們必須自始至終參與這個過程。步調(diào)一致的需求計劃可以明確地將商業(yè)意義、項目

14、目標(biāo)和項目結(jié)果聯(lián)系到一起。否則，該項目不能產(chǎn)生他們所期待的令人滿意的結(jié)果。 失敗的軟件項目對項目所有人傷害最大，因為是他們資助了這個項目，是他們一直期待著能靠這個軟件賺回投資。5. 要簡單，不要復(fù)雜我的微波爐只需要有一個按鈕，即“增加一分鐘” 。要燒開一杯水喝咖啡，我得按下按鈕三次；要融化奶酪餅干，只需輕輕點擊一下；為了加熱玉米粉餅，我按“增加一分鐘” ，到點后過 15 秒鐘再打開門。只有一個按鈕的微波爐會通過產(chǎn)品規(guī)劃委員會的認(rèn)可嗎？可能不會?？纯次业哪桥_微波爐上的功能選項（都是從未用過的） ，我就知道，產(chǎn)品規(guī)劃委員會喜歡復(fù)雜而不要簡單。當(dāng)然，他們可能會給“復(fù)雜性”冠以“功能豐富”的頭銜。沒有

15、人從一開始就樹立目標(biāo)：生產(chǎn)的產(chǎn)品就得極盡復(fù)雜。復(fù)雜性總是意外出現(xiàn)的。假設(shè)我有一塊涼比薩餅需要熱一下。根據(jù)制造商的說明，我應(yīng)該按“菜單”按鈕。我現(xiàn)在面臨的選擇是“速熱”和“再熱” 。 （嗯，我猜應(yīng)該選擇“再熱” ，雖然我有點餓了。速熱會比再熱快嗎？） “飲料” 、 “面條” 、 “比薩餅” 、 “盤菜” 、 “醬”還是“湯”？ （我選擇“比薩餅” ，盡管它上面確實有醬并且它也放在盤中。 ） “熟食 / 新做”還是“冷凍”？ （當(dāng)然都不是，它只是吃剩下的外賣比薩餅。我猜應(yīng)該選擇“熟食 / 新做” 。 ） “一塊” 、 “兩塊” 、 “三塊”還是“四塊”？我不知道這樣的盤問將持續(xù)多久，所以我按取消，

16、然后按“增加一分鐘”按鈕。這和軟件開發(fā)有什么關(guān)系？就我而言，A 只有一個按鈕，即“一鍵購物” 。哦，當(dāng)然，我第一次訪問時必須輸入我的地址和我的信用卡號碼，但現(xiàn)在我只要點一下就可以實現(xiàn)自己的沖動購物了。軟件通常要解決復(fù)雜的問題。現(xiàn)在的問題是，那種固有的復(fù)雜問題中有多少是你強(qiáng)加給最終用戶的？你的軟件是不是一個復(fù)雜問題放大器？成功的軟件通常是一個復(fù)雜問題吸收器，因為它首當(dāng)其沖地為用戶承受了復(fù)雜的問題，而不是將這些問題一路傳遞給用戶。作為項目經(jīng)理，你是復(fù)雜問題吸收器還是復(fù)雜問題放大器？最優(yōu)秀的項目經(jīng)理能夠吸收程序員、最終用戶和公司管理層等各方面拋出的復(fù)雜問題。當(dāng)最終用戶提出看似矛盾的需求時，你的任務(wù)就

17、是幫助清理這些需求，而不是盲目地將這些問題傳遞給開發(fā)人員。當(dāng)開發(fā)人員由于技術(shù)原因不能實現(xiàn)需求時，你的任務(wù)就是翻譯（吸收）這個復(fù)雜的問題，并向用戶進(jìn)行解釋，用足夠多的信息幫助用戶選擇另一個途徑。使用你的應(yīng)用程序有多容易？為應(yīng)用程序添加一項新功能有多容易？對一項新功能提出要求有多容易？報告缺陷、部署新版本、回滾不良的版本又有多容易？ 簡單性不會偶然發(fā)生，它需要積極培育。而復(fù)雜性會因你不留意而叢生。6. 償還你的技術(shù)債不管是普通的市民還是成功的企業(yè)，只要他們管理得當(dāng)，債務(wù)就是一種有用的金融工具。它通過對未來利潤的預(yù)支來平衡目前的資金不足。明智地使用短期債務(wù)能夠有效地消除現(xiàn)金大漲大落?？梢坏E用，短期

18、債務(wù)又會成為一個使企業(yè)舉步維艱的沉重枷鎖。在軟件開發(fā)界，為了實現(xiàn)那些“處于危險之中”的里程碑，同時完善大部分需要實現(xiàn)的工作，借用時間可謂是一種有效的策略。沃德 坎寧漢（Ward Cunningham）提出了“技術(shù)債”的概念，就是指在時間緊迫的情況下，開發(fā)人員為實現(xiàn)迭代目標(biāo)或快到截止日期時所采取的一種方法。在那一刻，他們無力用很恰當(dāng)?shù)姆绞絹硖幚泶a，但采取一些捷徑，他們也許能夠讓編寫好的程序“剛剛足以”沖過終點線。即使這套軟件是臨時的、有缺陷的，但只要有效地管理出現(xiàn)的技術(shù)債，這就是一種恰當(dāng)?shù)呐e措。可是，如果這筆債沒有得到償還，它就會變成一個令人痛苦的越滾越大的雪球。如果持續(xù)向未來借債而不償還，那

19、么就會令整個項目變得岌岌可危。要想還清技術(shù)債，最好的方法就是評估在每個迭代結(jié)束前發(fā)生的所有“債務(wù)” ?？梢砸箝_發(fā)人員確定他們想要展開的臨時修改具體是什么，這樣做需要花費多少時間。 迭代是指由一個敏捷項目小組選擇的一段較短的時期（一周、兩周或一個月等） ，在此期間，該小組會開發(fā)并測試由客戶挑選的一個關(guān)鍵需求，并將結(jié)果發(fā)送給客戶以征求其同意或意見。然后，小組會開始下一個迭代，以開發(fā)下一個最重要的需求并（或）糾正前一個迭代中完成的工作。 臨時修改是指對一個在運行的編程問題作快速修復(fù)或解決，但這種解決方案并不是很理想，在時間允許的情況下可能需要重新修改。修改這種不完善的代碼可以稱為“展開修改” 。開

20、發(fā)人員并不需要立刻還清債務(wù)，不過，趁他們對這些捷徑仍然記憶猶新時來估量所需的修復(fù)工作，當(dāng)然是不錯的。一定要發(fā)現(xiàn)要重寫的代碼有什么具體問題，而不只是隨意判斷所需要花費的時間。不要借機(jī)偷懶，這是一種嚴(yán)肅的、保持代碼庫干凈的有效方法。另外，有越來越多的軟件分析工具能自動幫助識別出現(xiàn)“技術(shù)債”的地方，了解代碼覆蓋率、分析耦合性、檢測風(fēng)格偏離等，這些工具或許都可以在你不知情時工作。把留下“技術(shù)債”的地方記錄到問題跟蹤系統(tǒng)，并安排在以后的迭代中解決。只要可以平衡添加新業(yè)務(wù)功能的工作量并同時還清這些債務(wù)，就有可能既滿足客戶的功能要求又不使這些“技術(shù)債”失去控制。軟件難用的原因有很多，但通常都?xì)w結(jié)到臨時修改、

21、文檔不足、依賴關(guān)系不恰當(dāng)、快捷方式以及偏離預(yù)期設(shè)計等問題上。當(dāng)開發(fā)人員最終舉手投降說他們需要在一個系統(tǒng)上重打鑼另開張時，實際情況極有可能是，許許多多沒有償還的技術(shù)債已經(jīng)使他們不堪重負(fù)，債臺高筑之下，他們覺得還不如痛快地宣布這套軟件破產(chǎn)了。只有一直堅持識別債務(wù)并迅速處理它，你才可能總是用“最低補(bǔ)償”來避免接踵而至的混亂。在向業(yè)務(wù)利益相關(guān)者進(jìn)行解釋時，這種比喻說法可謂出奇地管用，能讓他們立刻明白軟件如何會隨著時間的推移而變得無法控制，以及為什么應(yīng)該投入力量保持代碼潔凈。7. 為團(tuán)隊增添人才而非技能我過去采用的招聘標(biāo)準(zhǔn)同我們這個行業(yè)里的每一個人的招聘方式都是一樣的：技能，技能，技能。直到有一天，一位

22、來面試的應(yīng)聘者當(dāng)頭潑我一盆冷水（這當(dāng)然是一種比喻的說法） ，這次經(jīng)歷從此改變了我。當(dāng)時我正期望為團(tuán)隊招納一個有多年微軟工作經(jīng)驗的能人。仔細(xì)翻閱了比爾的簡歷，我覺得他非常適合這個職位。他在所有相關(guān)技術(shù)方面都有六年多的經(jīng)驗。如果我能開出不錯的薪酬，這將會是一件輕而易舉的事。比爾接受了面試。我們先聊了聊，然后我向他介紹了我們手頭上的一些項目，并對他說他是多么適合這個職位。我信心十足地認(rèn)為這次招聘會進(jìn)展得很順利?？墒峭蝗婚g我意識到我會招不到他。我中途停止了面談，問比爾發(fā)生了什么事。我告訴他，他非常適合這個職位，也對他直說我感覺到他不會來。他的答復(fù)是： “理查德，如果我還想做過去六年來一直做的事情，我就

23、會留在我現(xiàn)在的單位了。我聽說你們即將開始一些非常酷、非常新的 Java 項目，所以我才會想來這兒工作，因為我把它看成一個學(xué)習(xí)和成長的機(jī)會。 ”就在那時我才恍然大悟。用“按技能挑簡歷”的方式來招聘新人，對一個要創(chuàng)建團(tuán)隊的經(jīng)理而言，實在是最愚蠢的方法。你知道，我和我的伙伴之所以會進(jìn)入這個高新技術(shù)產(chǎn)業(yè)，正是因為我們希望走在科技的最前沿。我們沒有一個人希望在職業(yè)生涯中重復(fù)使用自己在大學(xué)學(xué)到的那些技能。我們之所以進(jìn)入這個行業(yè)，正是因為這個行業(yè)所涉及的永遠(yuǎn)都是新領(lǐng)域，永遠(yuǎn)都要學(xué)習(xí)新技能和新技術(shù)。但不知何時出現(xiàn)了嚴(yán)重的錯誤。我意識到我們在員工成長上已停止了投資。我們不是在尋找新的人才，我們一直尋找的只是非常

24、具體的精良技能?，F(xiàn)在我要告訴大家，如果你們看到一個雇主在聘用新人時要求其技能達(dá)到精確匹配，那么，這個雇主其實是說： “我們不打算投資你。 ”對于所有努力創(chuàng)建強(qiáng)大團(tuán)隊的人，我要給出的忠告是：請記住你要聘請的是人才而非專業(yè)技能。當(dāng)為敏捷開發(fā)團(tuán)隊招聘技術(shù)專家時，我要找的是什么樣的人才？他們需要具備的優(yōu)良技能不過是在幼兒園里就培養(yǎng)的：能和他人融洽相處嗎？ z能主動合作嗎？ z當(dāng)完成任務(wù)后，會把自己的工作整理以做備用嗎？ z會對新事物感到興奮嗎？ z喜歡學(xué)習(xí)嗎？ z至于技能，我可以教他。事實上在我們的敏捷團(tuán)隊環(huán)境中，學(xué)習(xí)技術(shù)簡單而迅速。然而，教一個成年人如何主動合作幾乎是不可能的。聘用人才而不是技能，這

25、是組建團(tuán)隊的一種完全不同的方式。那些滿腔熱情、打算同我肩并肩一起開創(chuàng)激動人心的未來新技術(shù)的人，才是我想與之共事的人。8. 西蒙，保持簡單項目的利益相關(guān)者往往使事情變得過分復(fù)雜，這是軟件項目失敗的一種常見原因。項目組成員一定有能力完整構(gòu)想該項目的目標(biāo)并完成實際工作?？赡切├嫦嚓P(guān)者卻臆想，只靠幾個簡單的、不可思議的步驟就能完成這個項目。他們以為實現(xiàn)最終解決方案是輕而易舉的一件事情，哪怕這個項目很復(fù)雜。利益相關(guān)者不應(yīng)該把軟件項目建成一個統(tǒng)一、巨大而僵化的怪物，而應(yīng)該讓信息技術(shù)團(tuán)隊把項目建成一棵洋蔥，每長一層就表示成熟一分?，F(xiàn)實世界中沒有其他可供選擇的余地。不論那些需求有多完善，總是難免會有變動。如

26、果你的軟件不夠靈活，不能迅速適應(yīng)不斷變化的需求，那么這個項目甚至在開始前就注定要失敗了。為了讓事情保持簡單，需要牢記下列關(guān)鍵點。讓需求保持簡單 z 。需求分析人員往往會將自己腦海里冒出的某個解決方案同依據(jù)業(yè)務(wù)需要而提出的實際客戶需求弄混淆。雖然實際的需求可能會非常簡單，但是由于需求分析人員和開發(fā)人員之間缺乏真正的理解，會導(dǎo)致雙方的交流并不到位。需求分析人員應(yīng)該用簡單樹形圖寫出需求。根本需求是總體項目的簡單目標(biāo)。細(xì)小枝葉的子級需求被分門別類組成代表父級需求的枝葉。在整個圖中不斷重復(fù)這個過程，直到每項需求都清晰明了?？梢允褂密浖季S導(dǎo)圖工具來依照這種方法記錄需求。只要明確了一個小子集的需求，開發(fā)工

27、作就可以開始了。遵循敏捷開發(fā)過程 z 。一旦確定了一個小子集的需求，開發(fā)小組就可以立刻開始創(chuàng)建原型。只要原型可用，利益相關(guān)者就可以測試并提供反饋信息。客戶的反饋信息能夠確保準(zhǔn)確的需求，同時發(fā)現(xiàn)需求經(jīng)需求分析員從實際客戶傳遞到項目組時有可能形成的交流差異。讓客戶看到原型，也可以幫助檢查開發(fā)人員設(shè)想的相應(yīng)解決方案是否和客戶所預(yù)想的一致。這些差異變成新的需求，于是開發(fā)人員重做原型，接著周而復(fù)始重復(fù)這個循環(huán)。每個循環(huán)周期應(yīng)盡可能地短，通常不超過兩三個星期。定義需求的一個小子集，按照陳述的需求創(chuàng)建一個原型，然后獲得反饋信息，這種循環(huán)能夠確保項目的所有利益相關(guān)者總能達(dá)成共識，且每個人對進(jìn)展情況都感到很滿意

28、。只要認(rèn)真地遵循這些簡單的技巧，每一個軟件項目都可以取得圓滿成功。這里說的成功意味著顧客滿意且軟件實用，而且軟件所提供的有效業(yè)務(wù)功能完全符合創(chuàng)建初衷。9. 你并不是非比尋常的還記得你媽媽說的話嗎？“你是非比尋常的！你是獨一無二的！”其實，所有的媽媽都會這么跟孩子說。相信那個愛的謊言，結(jié)果導(dǎo)致了許多常見的軟件項目問題。我指導(dǎo)了許多不同的團(tuán)隊。當(dāng)按照軟件項目的達(dá)標(biāo)情況進(jìn)行考核時，那些相信他們是“非比尋常”的團(tuán)隊總是無一例外地落在了后面。因為他們自認(rèn)為是非比尋常的，所以有著重塑一切的強(qiáng)烈傾向。他們認(rèn)為： “其他的團(tuán)隊都不可能開發(fā)出實用的軟件，或至少沒有我們這個團(tuán)隊創(chuàng)造的軟件這么優(yōu)秀。 ”他們不從其他

29、開發(fā)團(tuán)隊的錯誤中汲取經(jīng)驗教訓(xùn)，而是悶頭重復(fù)犯著同樣的錯誤。損失都由公司買單。他們把大量時間用在重寫、調(diào)試以及把自己的奇怪想法運用到那些已經(jīng)成為行業(yè)標(biāo)準(zhǔn)的軟件和工具上，以至于他們永遠(yuǎn)都無法完成客戶項目，而這些項目才是他們應(yīng)該出售來賺錢的產(chǎn)品。這些虛幻而神奇的產(chǎn)品本可以像這個團(tuán)隊一樣非比尋常，當(dāng)然，前提是這個團(tuán)隊真的有幸將它們寫出來。聽聽這群獨一無二的開發(fā)人員是怎么說的吧：任何現(xiàn)成的構(gòu)建系統(tǒng)都不可能處理他們“獨一無二”的需求。因此，他們必須為每個新項目編寫一個新系統(tǒng)。不用現(xiàn)成的對象數(shù)據(jù)庫映射工具，他們要寫自己的。網(wǎng)絡(luò)應(yīng)用程序框架？他們信奉： “我們可以做。 ”持續(xù)集成？行。測試工具？我們也能寫。他

30、們當(dāng)中那些最自負(fù)、最癡迷的人甚至還嘗試自己編寫編程語言。 工具：軟件開發(fā)人員用來創(chuàng)建、調(diào)試、測試、分析、追蹤或以其他方式支持高質(zhì)量的軟件開發(fā)的簡單程序。那么這些團(tuán)隊每天都在做什么呢？由于舍棄不用那些通常都可以免費獲得的、功能完善的軟件工具，他們要自己創(chuàng)建那些未經(jīng)檢驗的代碼，由此便出現(xiàn)許多問題，而他們每天就是在解決這些問題。如果是編寫自己的數(shù)據(jù)庫層，他們每天就要追蹤隱藏的缺陷和問題。處理這些邊緣事件所花費的時間非常多，如果他們能學(xué)習(xí)或者修改現(xiàn)有的工具，那花費的時間將會少得多。不那么“非比尋?！?（但卻更成功）的團(tuán)隊之所以會使用現(xiàn)成的工具，那是因為他們準(zhǔn)備解決的問題都是很棘手的。他們需要可靠的工具

31、，因此他們的注意力集中在軟件項目的解決方案上，而不是試圖為一個已經(jīng)滿滿的工具箱再裝入一個工具。這和有效的軟件項目管理有什么關(guān)系呢？不要讓你的程序員白費力氣做重復(fù)工作。如果他們跑來跟你解釋他們的問題是多么非比尋常，你就直接向他們點明，他們的媽媽在做出“你是非比尋?！钡脑u價時可能言過其實了。對可以利用的資源要做到了解透徹、信息靈通，引導(dǎo)團(tuán)隊使用高品質(zhì)的開源或商業(yè)工具?！胺俏野l(fā)明不可”綜合癥使許多杰出團(tuán)隊脫離正軌。千萬不要讓你的團(tuán)隊也在此出軌了。 邊緣事件：只在極端情況下（例如，最快或最慢的速度，最多或最少的數(shù)據(jù)量，或者最老或最新的瀏覽器接口）出現(xiàn)的問題或情況。通常是指將精力集中在瑣碎且耗時的事情上

32、，卻忽略了重要的編程業(yè)務(wù)量。10. 隨時間滾動12 年前，我的團(tuán)隊作為某家圖形設(shè)計公司的分包商受邀開發(fā)一個網(wǎng)絡(luò)應(yīng)用程序。我們同客戶沒有直接的聯(lián)系?？蛻魧⑺械男枨蠖紓鬟f給總承包商，然后總承包商再通過一連串隨意的電子郵件將這些信息轉(zhuǎn)達(dá)給我們。 有一封電子郵件和我們的藝術(shù)家應(yīng)該使用的屏幕分辨率有關(guān)。以前的標(biāo)準(zhǔn)一直都是 640480，但最近的研究表明網(wǎng)站應(yīng)該支持高達(dá) 800600 的分辨率。今天最常見的屏幕分辨率為 1024768。 ）盡管這是一家經(jīng)驗豐富的設(shè)計公司，它卻向客戶陳述了這樣的正式要求（我們從來沒有見過）：每一頁的布局符合固定的 800 像素寬和 600 像素高的標(biāo)準(zhǔn)。如果我們看到了這一

33、要求，肯定會立即進(jìn)行更正如下： “每頁的布局符合固定 800 像素寬的標(biāo)準(zhǔn)，而支持的顯示器分辨率最高為 800600。 ”我們做過許多網(wǎng)站，知道寬度是最重要的方面。用戶討厭水平地滾動網(wǎng)頁，而垂直滾動則被看做是使用瀏覽器的一種現(xiàn)實情況，甚至是一種有利條件。然而，很顯然，這條寶貴的真理從來沒有被轉(zhuǎn)達(dá)給客戶。這個網(wǎng)站客戶為每個網(wǎng)頁都提供了大量的內(nèi)容。結(jié)果，只有極少數(shù)的網(wǎng)頁能夠在分辨率為 800600 的 15 英寸顯示器上被完整地縱向瀏覽。必須垂直滾動網(wǎng)頁。作為終端用戶的客戶并沒有認(rèn)識到，如果想在單個屏幕上顯示這種超量的內(nèi)容，我們必須是超人才能實現(xiàn)這個奇跡，于是他們非常失望。他們指責(zé)我們的主承包商，

34、那家設(shè)計公司。反過來，這家設(shè)計公司便拒絕付錢給我們。據(jù)他們的說法，我們“沒有滿足書面要求” 。有了這次經(jīng)驗，我認(rèn)識到粗制濫造的書面要求的危害性，也知道別人怎么利用它來對付你。永遠(yuǎn)都要用文檔記錄下你的設(shè)想，并堅持與最終用戶而不僅僅是中間人來審查并簽署這些需求，這一點相當(dāng)重要。幸運的是，敏捷項目管理實踐緩解了這些問題。由于認(rèn)識到開發(fā)人員和最終客戶面對面接觸的重要性，我們已經(jīng)開始共同創(chuàng)建用戶故事，開始根據(jù)他們提供給客戶的商業(yè)價值而不是需求清單來排定各項功能的輕重緩急。一到兩個星期的迭代過程意味著我們必須有早期和頻繁的反饋意見，意味著我們有機(jī)會闡明客戶的期望。12 年后，我?guī)缀跤龅搅艘荒Ｒ粯拥那樾?，?/p>

35、個客戶希望在每個頁面上顯示大量內(nèi)容，但同時也高度關(guān)注垂直滾動。幸運的是，按照我們?nèi)缃竦捻椖窟\行方式，再根據(jù)以往的經(jīng)驗教訓(xùn)，我們沒有重蹈覆轍，而是迅速解決了這個問題，實現(xiàn)了客戶的期望。11. 你們的問題，我不買單我們公司正在使用的培訓(xùn)軟件已經(jīng)滯后了五次升級，再不及時升級，供應(yīng)商都不再提供支持。我們的項目就是與這家供應(yīng)商進(jìn)行合作，將培訓(xùn)軟件升級到最新版本，然后培訓(xùn)我們的用戶使用最新版本的軟件。我們對工作作出了兩項聲明，一項概述了用戶培訓(xùn)協(xié)議，另一項明確了培訓(xùn)軟件升級的費用上限。在獲得我們的數(shù)據(jù)后，供應(yīng)商開始了遠(yuǎn)程開發(fā)和測試腳本的過程，以便轉(zhuǎn)換數(shù)據(jù)并應(yīng)用第一次升級。腳本一旦通過供應(yīng)商的測試，就會遷移

36、到我們的開發(fā)環(huán)境，我們要進(jìn)行用戶測試。在這五次接踵而至的升級過程中，每次都要重復(fù)這個過程。測試期間，我們會把遇到的所有問題都記錄下來，待供應(yīng)商重寫、重測他們的源腳本后，我們再重新測試這些問題。每次升級工作，用供應(yīng)商的工作時間乘以聲明中約定的費率，計算升級費用。進(jìn)行升級時，我們會發(fā)現(xiàn)應(yīng)用升級程序的錯誤，這些錯誤和我們用來安裝升級寫的客戶腳本并不相關(guān)。我們會仔細(xì)記錄每一個問題，打印屏幕界面，并提供一步步的細(xì)節(jié)，說明我們發(fā)現(xiàn)的是何種問題，也告知了我們是在哪里以及是如何發(fā)現(xiàn)每個問題的。我們還要提供證明文件，說明供應(yīng)商最早許諾過的軟件功能。該供應(yīng)商堅持認(rèn)為軟件是“按設(shè)計要求”運行的。后來我們發(fā)現(xiàn)，遇到的

37、這些小 bug 只是冰山一角，它們還有更嚴(yán)重的后果。它們暴露出軟件的基本功能存在嚴(yán)重的問題，甚至是在升級以后還存在問題。 腳本是指在計算機(jī)編程中由一個程序而不是計算機(jī)處理器執(zhí)行的程序或指令序列。腳本可以用來控制軟件應(yīng)用而不用改變應(yīng)用程序的核心代碼。過了一段時間，供應(yīng)商承認(rèn)我們發(fā)現(xiàn)的問題中有幾個確實沒有“按設(shè)計要求”運行，它們的確是 bug。由于約定了“費用上限” ，雖然他們?yōu)榱诵薷淖约旱漠a(chǎn)品，不得不做大量的工作，但是除了合同中約定的“上限”費用，他們并沒有額外收取我們?nèi)魏钨M用。在項目的這個階段，為了滿足關(guān)鍵的最后期限要求，我們的注意力完全集中在軟件的安裝上。只能顧及一個問題到底是“按設(shè)計要求”

38、運行的還是一個bug。顯而易見，如果我們當(dāng)初明確記錄了供應(yīng)商修復(fù)每個 bug 所花的具體時間，那么我們可能都無需支付合同約定的上限費用。當(dāng)與供應(yīng)商談判合同時，應(yīng)該明確約定雙方（即供應(yīng)商和你的項目團(tuán)隊）的時間要按遇到的具體問題進(jìn)行追蹤記錄。這樣一來，軟件項目經(jīng)理就能有準(zhǔn)確的記錄，如果問題與合同項目要解決的問題無關(guān)，而是出在供應(yīng)商的原產(chǎn)品上時，軟件項目經(jīng)理就能夠減少費用的支出。12. 如何發(fā)現(xiàn)優(yōu)秀的 IT 開發(fā)人員軟件項目經(jīng)理都知道，項目的成功取決于擁有出色的開發(fā)人員。你如何識別千里馬呢？面試新應(yīng)聘者前，和最好的開發(fā)人員交談一下。讓他們重申一下所需要的具體知識。具有特定開發(fā)生命周期的經(jīng)驗、掌握具體

39、方法或重要工具箱，以及擁有某方面領(lǐng)域知識（比如國防工業(yè)或制藥行業(yè)） ，這些是開發(fā)人員最好具備的條件還是必須具備的條件？要對其知識進(jìn)行評估。你應(yīng)和可信任的開發(fā)團(tuán)隊代表共同參與面試，還要附加理論測試。一個優(yōu)秀的軟件工程師能夠立刻修復(fù)“模擬”的語法錯誤，并且不會精神緊張。他不需要看大量文檔，也無需逐字閱讀就可以看懂別人的代碼，了解它的意圖。當(dāng)面對有問題的程序時，應(yīng)聘者應(yīng)該能夠迅速找出問題，然后既能以“極客開發(fā)人員”的語言也能用非 IT 背景的利益相關(guān)者能聽懂的語言描述它。我們招聘編程技術(shù)人才時都認(rèn)為其技能“越多越好” 。但是我們?nèi)绾谓缍ā岸唷?？盡管應(yīng)聘者可能擁有豐富的知識，但是這個人可能還沒有掌握有

40、效應(yīng)用它的技巧。在面對真實世界苛刻的項目時，一個剛畢業(yè)的大學(xué)生或剛培訓(xùn)過的開發(fā)人員，想要使用從課本上學(xué)到的理論知識時會很吃力。當(dāng)最后期限一步步臨近，所剩時間無幾，而客戶和其他利益相關(guān)者又施加了強(qiáng)大的壓力，你除了有基礎(chǔ)知識之外還需要足夠的經(jīng)驗。你和團(tuán)隊?wèi)?yīng)該要求應(yīng)聘的開發(fā)人員編寫一段代碼供你們審讀。在分析了代碼，并且與你信賴的開發(fā)人員討論后，你才會知道這個人的方法和風(fēng)格是否適合你的團(tuán)隊。還要考察應(yīng)聘者對待工作、同事、客戶和利益相關(guān)者的態(tài)度。我曾經(jīng)和一個被稱為“吹風(fēng)機(jī)”的開發(fā)人員共事。傳說當(dāng)他感到不滿時，他就會用他的大聲吼叫吹干人們的頭發(fā)。他是一個優(yōu)秀的開發(fā)人員，但是對于整個項目團(tuán)隊而言，他卻是有害

41、無益的。編程世界正朝著敏捷開發(fā)方向發(fā)展，跨職能溝通和軟技能將越來越重要。開發(fā)人員將會與公司中其他部門的人組成小團(tuán)隊一起工作。你未來的新隊友若總是處于不受控制的自由狀態(tài)，你跟他合作還會順暢嗎？招聘軟件開發(fā)人員時需遵循以下簡單指導(dǎo)原則。審查他們是否掌握開發(fā)生命周期的正確知識、方法、工具，以及他們對 z所在行業(yè)（領(lǐng)域）的熟悉程度?？疾焖麄冊诠ぷ鳝h(huán)境下應(yīng)用知識的能力。 z測試他們的溝通能力和社交技巧。 z尋找對工作有正確態(tài)度的人既渴望創(chuàng)造出高端產(chǎn)品，又能接受項目 z的限制條件。是否有證據(jù)表明他們能及時且在預(yù)算之內(nèi)生產(chǎn)出“切合意圖”的產(chǎn)品？不管你的應(yīng)聘者多么有風(fēng)度而且多么懂技術(shù)，都要始終核實發(fā)證機(jī)關(guān)的資

42、格證書和前任雇主的履歷條目。聘請階段小心謹(jǐn)慎可以防止未來很多問題。13. 優(yōu)秀與普通的天壤之別首次承擔(dān)軟件項目的項目經(jīng)理在認(rèn)識開發(fā)人員的技能方面容易犯錯誤，我們下面就要揭示這種錯誤。首先，要明白真正優(yōu)秀的軟件開發(fā)人員比普通開發(fā)人員要高效得多。事實上，統(tǒng)計數(shù)字表明，真正優(yōu)秀的開發(fā)人員要比差的人員好上幾個數(shù)量級，也就是成百上千倍。這里要強(qiáng)調(diào)的是，一個熟練的程序員不只是略高于平均水平，熟練與否的差異是巨大的。新上任的軟件項目經(jīng)理做產(chǎn)品開發(fā)計劃時，這個認(rèn)識對他們意味著什么呢？經(jīng)理們?nèi)菀族e誤地認(rèn)為，假使不能得到最好和最聰明的人才，普通開發(fā)人員也是可用的。但是開發(fā)軟件并不像挖溝，在挖溝時即使最差的挖土機(jī)也

43、能挖出一個洞。在軟件開發(fā)中，今天編寫的程序會成為明天的基礎(chǔ)。如果你讓普通開發(fā)人員建設(shè)基礎(chǔ)，那么為了繼續(xù)前進(jìn)，真正優(yōu)秀的開發(fā)人員就不得不返工修復(fù)缺陷。雇用中等或普通的開發(fā)人員會減緩項目速度。常常是，讓一個差的開發(fā)人員離開團(tuán)隊比新加入一個優(yōu)秀的人員作用還要大。再聯(lián)想到在延期項目中加人會使項目延期得更長，你就可以理解為什么大多數(shù)企業(yè)發(fā)展緩慢。沒有經(jīng)驗的軟件項目經(jīng)理可能會爭辯著說，因為增加更多的倉庫人員會使貨物裝車更快，所以增聘程序員也可以縮短軟件項目所需的時間。 速度：在敏捷軟件開發(fā)中使用的一個術(shù)語，用以表明一個團(tuán)隊或一個團(tuán)隊成員在項目中的速率，即在給定時間內(nèi)一個程序員能完成多少工作量。這是行不通的

44、。為了讓新人跟上進(jìn)度會花費時間，并且還會使其他程序員脫離既定任務(wù)。此外，溝通渠道會隨著成員的增多而增多。對于一個只有兩人的團(tuán)隊來說，只有一個渠道：貝齊 蘇與比爾。增加邁克后，就會猛增到三個渠道。繼續(xù)加人，渠道的數(shù)量還會繼續(xù)以指數(shù)速度增長。計算公式是 n(n-1)/2。在 12 人的團(tuán)隊中，你有 12(12-1)/2個渠道，或者說你作為一名項目經(jīng)理必須維持 66 條關(guān)系。再增加一個人，就會變?yōu)?78 條溝通渠道需要監(jiān)管。用普通開發(fā)人員建設(shè)軟件項目的想法體現(xiàn)了兩個項目誤區(qū)：1）你可以通過增加人員來縮短項目時間；2）普通開發(fā)人員以平均水平生產(chǎn)普通代碼（bug 成群，偏離任務(wù)）也是可以的。實際上，普通

45、開發(fā)人員會拖累整體生產(chǎn)力，并且使項目花費的時間比實際需要的更長。怎樣解決這種情況呢？一是給優(yōu)秀的開發(fā)人員強(qiáng)有力的工具，你將更快獲得高質(zhì)量的軟件。二是要認(rèn)識到擁有普通開發(fā)人員對項目沒有幫助，并且照顧差的開發(fā)人員會消減優(yōu)秀開發(fā)人員（他們是工藝師）的生產(chǎn)力。軟件開發(fā)太復(fù)雜，它不是一個裝配線生產(chǎn)過程。想要更快地開發(fā)軟件怎么辦？花額外的錢聘請和培養(yǎng)優(yōu)秀的軟件開發(fā)人員。這將在短期和長期（維護(hù)代碼時）都給你帶來回報。14. 規(guī)模決定一切項目的規(guī)模、團(tuán)隊的規(guī)模、交付物的規(guī)模和清單的規(guī)模項目中的一切做法都取決于它的規(guī)模。規(guī)模改變著游戲進(jìn)行的規(guī)則。項目經(jīng)理應(yīng)該把項目劃分成易管理的模塊，并與有才能的人分別承擔(dān)這些模

46、塊，項目（在規(guī)?；驈?fù)雜性方面）越大，這一點就越重要。這將確保關(guān)鍵項目成員（包括項目經(jīng)理）在為項目做“體檢”時可以看到全局而不至于迷失在細(xì)節(jié)中。 分布式項目往往比其他類型的項目規(guī)模大，因此，項目經(jīng)理用來管理規(guī)模的策略實際上影響著該項目的底線。這個“大”字讓人浮想聯(lián)翩，它可能意味著 8個人連續(xù)工作 12 個月（你是一個小供應(yīng)商） ，也可能意味著數(shù)百人全年按合同做著維護(hù)工作（對你的客戶而言你是一個IT 巨頭） 。這里有幾個關(guān)于劃定項目規(guī)模的建議，確保每個人都懂得自己那一小塊可以導(dǎo)致整個大局的成敗。把項目盡可能地分成許多獨立的但可掌控的工作流。 確保每個工作流至少有一個負(fù)責(zé)傳送的關(guān)鍵聯(lián)絡(luò)點。 如果可能

47、，盡量讓主要成員在工作流中有交叉，以使整個團(tuán)隊可以共享 大局觀。分別獨立追蹤每個工作流的進(jìn)展（使用任何工具） ，并且定期監(jiān)控節(jié)奏以 掌控整個項目的動向。分別記錄和共享每個工作流的風(fēng)險、問題、承擔(dān)的責(zé)任以及依賴的條件。 定期舉辦小組會議，通報每一個工作流的狀態(tài)。 公布整個項目的進(jìn)度路線圖，包括所有不同工作流的發(fā)布計劃。 積極使用在線工具來共享用戶要求、里程碑更新、錯誤報告、報告時限 以及風(fēng)險。例如，假設(shè)你受托設(shè)計同一網(wǎng)站的三種不同形式（北美地區(qū)、亞太地區(qū)和中東地區(qū)） 。你決定最好是創(chuàng)建三個不同的工作流，每個都有獨立的傳送聯(lián)絡(luò)人。由于三個站點基本上是不同版本的相同網(wǎng)站（相當(dāng)于是中等規(guī)模的定制） ，

48、所以最好讓幾個關(guān)鍵資源在三個工作流中自由移動。這樣他們就可以確保幾個網(wǎng)站的一致性，并可以重復(fù)使用具體實現(xiàn)細(xì)節(jié)。另一個例子是一個項目可以有多個集成供應(yīng)商的。比較理想的做法是將每個融合點（或相關(guān)的幾個結(jié)合點）分離成單獨的工作流，這樣就能多渠道同時工作并且還能縮短傳送時間。每日例會時讓不同團(tuán)隊協(xié)調(diào)整體的傳送質(zhì)量。15. 記錄工作流程，然后 嚴(yán)格執(zhí)行我們試圖把電子郵件從一個平臺轉(zhuǎn)移到另一個平臺，但僅僅因為一個女人結(jié)了婚，我們的電子郵件系統(tǒng)便癱瘓了。該電子郵件流程如下：(1) 新的電子郵件通過新的電子郵件系統(tǒng)發(fā)送。(2) 如果新的電子郵件系統(tǒng)可以發(fā)送，它就把信息發(fā)給正確的新系統(tǒng)用戶。如果不可以發(fā)送的話，

49、該郵件將被發(fā)送到舊的電子郵件系統(tǒng)來投遞。(3) 仍在舊系統(tǒng)中的人給仍在舊系統(tǒng)中的其他用戶發(fā)送郵件時，郵件將會傳送到對應(yīng)的舊郵箱中。然而，如果收件人已被遷移到新系統(tǒng)，那么電子郵件會通過為每個用戶創(chuàng)建的“遷移”轉(zhuǎn)發(fā)地址轉(zhuǎn)發(fā)過去。 有趣的事情出現(xiàn)了。一旦單身薩莉（Sally Single）被遷移到新的電子郵件系統(tǒng)中，她就有了兩個電子郵件地址，一個是 HYPERLINK mailto:sally.single sally.single，另一個是轉(zhuǎn)發(fā)郵件地址 HYPERLINK mailto:sally.single sally.single。所有舊系統(tǒng)的用戶發(fā)送給她的電子郵件都會通過她的“遷移”轉(zhuǎn)發(fā)地

50、址自動轉(zhuǎn)發(fā)到新的郵件系統(tǒng)。當(dāng)薩莉結(jié)婚后，她把名字從“單身薩莉”改為“已婚薩莉” ，她的電子郵件地址隨之改變。然而，新系統(tǒng)中給薩莉的電郵地址重新命名的人忘記改變她在舊系統(tǒng)中電子郵件的“遷移”轉(zhuǎn)發(fā)地址。所以薩莉就有了下列地址。新系統(tǒng)(1) HYPERLINK mailto:sally.married sally.married(2) HYPERLINK mailto:sally.single sally.single(3) HYPERLINK mailto:sally.married sally.married舊系統(tǒng)(1) HYPERLINK mailto:sally.married sally.

51、married(2) HYPERLINK mailto:sally.single sally.single(3) HYPERLINK mailto:sally.single sally.single（結(jié)婚后忘了改變這一條“遷移”轉(zhuǎn)發(fā)地址。 ）當(dāng)舊的通信系統(tǒng)用戶給薩莉發(fā)送郵件時，就產(chǎn)生了一個循環(huán)：1）創(chuàng)建信息并發(fā)送到舊的郵件系統(tǒng)地址 HYPERLINK mailto:sally.single sally.single；2）舊的郵件系統(tǒng)檢查薩莉的賬戶，確保將郵件發(fā)送至轉(zhuǎn)發(fā)地址 HYPERLINK mailto:sally.single sally.single，然后轉(zhuǎn)發(fā)信息；3）新的郵件系統(tǒng)查找電

52、子郵件地址為 HYPERLINK mailto:sally.singlemigrate sally.singlemigrate. 的用戶，但找不到它，因為該地址在薩莉結(jié)婚后改名了；4）新電子郵件系統(tǒng)轉(zhuǎn)發(fā)了未知的收件人郵件到舊系統(tǒng)中；5）舊的系統(tǒng)知道用 地址轉(zhuǎn)發(fā)所有信息，所以又將它轉(zhuǎn)發(fā)到新的郵件系統(tǒng)中；6）如此以來，信息像泡沫一樣堆積，循環(huán)往復(fù)地發(fā)來發(fā)去。信息每循環(huán)一次，公司的免責(zé)聲明就會被添加到消息后。雖然免責(zé)聲明只有 100 字左右，但是當(dāng)每個信息在系統(tǒng)中一分鐘就循環(huán)幾次時，內(nèi)容就會迅速增加。由此顯得薩莉很受歡迎。有這么多的信息發(fā)送給薩莉，其規(guī)模和容量終于導(dǎo)致電子郵件系統(tǒng)癱瘓。這個故事的寓意

53、：應(yīng)記錄工作流程，并確保嚴(yán)格執(zhí)行。在這個故事里，雖然更名的流程已經(jīng)記錄好，但沒有得到執(zhí)行。否則，薩莉在舊的郵件系統(tǒng)中的用戶賬號就會隨著她結(jié)婚后的新遷移郵件地址一同更新，問題就不會出現(xiàn)。16. 剔除多余的流程成功的團(tuán)隊做了什么其他人都沒有做的事情？他們不斷質(zhì)疑自己的流程，并努力消除多余的環(huán)節(jié)。他們毫不留情地對自己的軟件開發(fā)進(jìn)程進(jìn)行重構(gòu)。Il semble que la perfection soit atteinte non quand il n y a plus rien ajouter, mais quand il ny a plus rien retrancher。這個法國諺語引自安托萬

54、德 圣 修伯里，意思是： “完美，不是指無可增，而是指無可減。 ”為什么今天的團(tuán)隊不應(yīng)用這個準(zhǔn)則呢？為什么隨著時光流逝，最終產(chǎn)品的價值越來越少，而整個過程和副產(chǎn)品卻越來越笨重？為什么代碼行數(shù)在增加，但軟件有用的功能卻越來越少？以下關(guān)鍵指標(biāo)顯示出軟件開發(fā)進(jìn)程出現(xiàn)了問題：軟件大幅膨脹，出現(xiàn)大量代碼行和無用的功能； 開發(fā)軟件的隊伍的規(guī)模在不斷擴(kuò)大； 這個過程變得越來越規(guī)范化、教條化、僵硬化； 該團(tuán)隊正在經(jīng)歷“規(guī)劃致死”會議； 文件和輔助產(chǎn)品總量以指數(shù)方式增長； 新發(fā)現(xiàn)的漏洞不斷從客戶測試組中涌現(xiàn)。 團(tuán)隊領(lǐng)導(dǎo)們不斷增加更多流程、更多檢查和更多審查，他們認(rèn)為日益嚴(yán)格的進(jìn)程將解決這個問題。根據(jù)我的經(jīng)驗，這

55、絕對不是一個工作進(jìn)程問題。添加更多的流程只會使團(tuán)隊更難看清問題的真正根源。為什么大多數(shù)團(tuán)隊都不敢丟棄那些不能真正幫助他們的流程呢？為什么團(tuán)隊在一開始就用大量流程，只要能想到的都加上，而不是僅在需要時增加？這可能反映出團(tuán)隊在最初使用這一流程時并不理解它?；蛘呖赡芤馕吨?，有人沒有充分了解軟件開發(fā)過程就給團(tuán)隊套上管理枷鎖。無論是哪種情況，該項目都成了不切實際的計劃，只能變成一堆無用的代碼位。在沒有明白造成項目在膨脹卻沒有增加價值的真正原因時，盲目改變是毫無用處的。在我看來，一個好的項目經(jīng)理應(yīng)該正確理解團(tuán)隊的工作方式。他應(yīng)該能夠旁觀者清，正確評估每個流程給功能性軟件生產(chǎn)帶來的影響。一個經(jīng)驗豐富的項目經(jīng)

56、理應(yīng)該仔細(xì)查看團(tuán)隊需要去做的所有活動，只保留那些對具體項目成功至關(guān)重要的活動。一旦將過去項目中多余的流程去掉，團(tuán)隊的生產(chǎn)力和工作量就應(yīng)該很快能提高。談到流程時， “少即是多”是一個非常重要的哲理。17. 矛盾體的需求說明書良好的需求（R）描述一個產(chǎn)品的特性如何解決現(xiàn)有的或潛在的問題。良好的特性（F） ，也稱為功能，被添加到產(chǎn)品中用以處理那些重要的問題。需求是由銷售人員采集或者是由軟件項目經(jīng)理創(chuàng)建出來的。我們想要在美國之外銷售這個產(chǎn)品（R） 。我們需要提供國際化和本土化 支持（F） 。為了完成一項非常簡單的任務(wù)，用戶必須點擊五個按鈕。他們感到失望 并且不會去完成任務(wù)。我們需要簡化用戶界面（R）

57、，并且將按鈕點擊數(shù)減少到兩次以下來完成相同的任務(wù)（F） 。另一方面，說明書（S）具體描述了將怎樣解決問題和滿足需求。使用上面這些例子，下面的說明書或許會由系統(tǒng)架構(gòu)師來寫。我們將抽出所有字符串，包括彈出消息，并且把它們放置在外部資源包 里（S） 。這項應(yīng)用將會被改進(jìn)，在屏幕上顯示的所有文本可以從那些資源包里取 出（S） 。創(chuàng)建當(dāng)?shù)匦枰奶貏e資源包來實現(xiàn)本地化（S） 。 通過點擊按鈕 1,2,3 才能完成的功能將會集成到單獨一個按鈕 A 上（S） 。 現(xiàn)存的按 4 和 5 的功能將被集成到按鈕 B上（S） 。 倘若不分清需求和說明書的界線，就會導(dǎo)致錯誤的人在作決定。導(dǎo)致的結(jié)局無外乎兩種，要么是讓軟

58、件開發(fā)人員來決定什么功能對客戶重要，要么是軟件項目經(jīng)理來告知開發(fā)人員如何構(gòu)建代碼。無論如何，都只會產(chǎn)出低劣的軟件產(chǎn)品。開發(fā)人員沒有經(jīng)常和客戶、用戶、市場、銷售人員和潛在合作伙伴交流，卻試圖了解什么功能是最重要的。另一方面，軟件項目經(jīng)理常常不是熟練的開發(fā)人員，他們不懂如何最好地去實現(xiàn)功能，不知道他們出于一片好心而提出的不專業(yè)的說明建議會給產(chǎn)品的其他方面帶來什么影響。每個團(tuán)隊都有自己一套獨特的技術(shù)專長。良好的需求具體描述了你正努力解決的問題，并描述了為何一定要解決這個特別問題，這會使程序員在開發(fā)過程中更靈活、更高效和更積極。編碼人員只有致力于解決問題并深入了解這個問題時，才會作出獨立的設(shè)計選擇。他

59、們應(yīng)該只受限于他們已經(jīng)選用的技術(shù)，而不受制于非編程人員制作的教條式的脆弱說明書。仍需要有需求說明書，但是它們可以應(yīng)需而變。只有到了產(chǎn)品開發(fā)循環(huán)的末期，你才能完全理解一開始應(yīng)該如何創(chuàng)建產(chǎn)品。將你努力制作的東西與怎樣去制作它區(qū)分開來。然后，讓訓(xùn)練有素的各個團(tuán)隊成員根據(jù)他們自己在項目中的角色來做決定。18. 商業(yè)價值始終是衡量成功的標(biāo)準(zhǔn)作為項目經(jīng)理，很容易過分注重是否超出了時間、成本、范圍和質(zhì)量的規(guī)定。項目本身很快會結(jié)束，而我們的個人價值就在于我們是否有能力讓這個項目實現(xiàn)上述這些可測量的期望值。我們需要注意到一個事實，即項目是在獲得它附加到組織中的商業(yè)價值時才是成功的。如果我們正在為市場開發(fā)一個軟件

60、產(chǎn)品， “成功”的評價因素是很明確的。我們需要使用項目管理技巧使產(chǎn)品更快地推入市場，那樣我們才能在競爭對手生產(chǎn)出類似的甚至更好的產(chǎn)品之前讓它贏得大量顧客。我們需要在需求枯竭之前將產(chǎn)品銷售給市場中的大部分顧客。我們需要將這個軟件設(shè)計得使顧客易于安裝和使用。它還要易于維護(hù)和更新。許多軟件項目經(jīng)理感到他們的工作僅僅是完成軟件。從組織的投資回報（ROI）觀點來看，如果沒有把項目和商業(yè)需求聯(lián)系在一起，再好的軟件也可能一敗涂地。如果是一個內(nèi)部項目，那么它怎樣才能為組織省錢或賺錢？我們開發(fā)的東西更快、更精簡或者有更好的體系結(jié)構(gòu)，是否我們需要的硬件資源可以減少？或是因為我們能夠更快地接受訂單、處理訂單并且更快