【文章內容簡介】 2. 如何發(fā)現(xiàn)優(yōu)秀的 IT 開發(fā)人員軟件項目經理都知道，項目的成功取決于擁有出色的開發(fā)人員。你如何識別千里馬呢？面試新應聘者前，和最好的開發(fā)人員交談一下。讓他們重申一下所需要的具體知識。具有特定開發(fā)生命周期的經驗、掌握具體方法或重要工具箱，以及擁有某方面領域知識（比如國防工業(yè)或制藥行業(yè)） ，這些是開發(fā)人員最好具備的條件還是必須具備的條件？要對其知識進行評估。你應和可信任的開發(fā)團隊代表共同參與面試，還要附加理論測試。一個優(yōu)秀的軟件工程師能夠立刻修復“模擬”的語法錯誤，并且不會精神緊張。他不需要看大量文檔，也無需逐字閱讀就可以看懂別人的代碼，了解它的意圖。當面對有問題的程序時，應聘者應該能夠迅速找出問題，然后既能以“極客開發(fā)人員”的語言也能用非 IT 背景的利益相關者能聽懂的語言描述它。我們招聘編程技術人才時都認為其技能“越多越好” 。但是我們如何界定“多”？盡管應聘者可能擁有豐富的知識，但是這個人可能還沒有掌握有效應用它的技巧。在面對真實世界苛刻的項目時，一個剛畢業(yè)的大學生或剛培訓過的開發(fā)人員，想要使用從課本上學到的理論知識時會很吃力。當最后期限一步步臨近，所剩時間無幾，而客戶和其他利益相關者又施加了強大的壓力，你除了有基礎知識之外還需要足夠的經驗。你和團隊應該要求應聘的開發(fā)人員編寫一段代碼供你們審讀。在分析了代碼，并且與你信賴的開發(fā)人員討論后，你才會知道這個人的方法和風格是否適合你的團隊。還要考察應聘者對待工作、同事、客戶和利益相關者的態(tài)度。我曾經和一個被稱為“吹風機”的開發(fā)人員共事。傳說當他感到不滿時，他就會用他的大聲吼叫吹干人們的頭發(fā)。他是一個優(yōu)秀的開發(fā)人員，但是對于整個項目團隊而言，他卻是有害無益的。編程世界正朝著敏捷開發(fā)方向發(fā)展，跨職能溝通和軟技能將越來越重要。開發(fā)人員將會與公司中其他部門的人組成小團隊一起工作。你未來的新隊友若總是處于不受控制的自由狀態(tài)，你跟他合作還會順暢嗎？招聘軟件開發(fā)人員時需遵循以下簡單指導原則。審查他們是否掌握開發(fā)生命周期的正確知識、方法、工具，以及他們對 z所在行業(yè)（領域）的熟悉程度。考察他們在工作環(huán)境下應用知識的能力。 z測試他們的溝通能力和社交技巧。 z尋找對工作有正確態(tài)度的人——既渴望創(chuàng)造出高端產品，又能接受項目 z的限制條件。是否有證據(jù)表明他們能及時且在預算之內生產出“切合意圖”的產品？不管你的應聘者多么有風度而且多么懂技術，都要始終核實發(fā)證機關的資格證書和前任雇主的履歷條目。聘請階段小心謹慎可以防止未來很多問題。13. 優(yōu)秀與普通的天壤之別首次承擔軟件項目的項目經理在認識開發(fā)人員的技能方面容易犯錯誤，我們下面就要揭示這種錯誤。首先，要明白真正優(yōu)秀的軟件開發(fā)人員比普通開發(fā)人員要高效得多。事實上，統(tǒng)計數(shù)字表明，真正優(yōu)秀的開發(fā)人員要比差的人員好上幾個數(shù)量級，也就是成百上千倍。這里要強調的是，一個熟練的程序員不只是略高于平均水平，熟練與否的差異是巨大的。新上任的軟件項目經理做產品開發(fā)計劃時，這個認識對他們意味著什么呢？經理們容易錯誤地認為，假使不能得到最好和最聰明的人才，普通開發(fā)人員也是可用的。但是開發(fā)軟件并不像挖溝，在挖溝時即使最差的挖土機也能挖出一個洞。在軟件開發(fā)中，今天編寫的程序會成為明天的基礎。如果你讓普通開發(fā)人員建設基礎，那么為了繼續(xù)前進，真正優(yōu)秀的開發(fā)人員就不得不返工修復缺陷。雇用中等或普通的開發(fā)人員會減緩項目速度①。常常是，讓一個差的開發(fā)人員離開團隊比新加入一個優(yōu)秀的人員作用還要大。再聯(lián)想到在延期項目中加人會使項目延期得更長，你就可以理解為什么大多數(shù)企業(yè)發(fā)展緩慢。沒有經驗的軟件項目經理可能會爭辯著說，因為增加更多的倉庫人員會使貨物裝車更快，所以增聘程序員也可以縮短軟件項目所需的時間。① 速度：在敏捷軟件開發(fā)中使用的一個術語，用以表明一個團隊或一個團隊成員在項目中的速率，即在給定時間內一個程序員能完成多少工作量。這是行不通的。為了讓新人跟上進度會花費時間，并且還會使其他程序員脫離既定任務。此外，溝通渠道會隨著成員的增多而增多。對于一個只有兩人的團隊來說，只有一個渠道：貝齊 蘇與比爾。增加邁克后，就會猛增到三個渠道。繼續(xù)加人，渠道的數(shù)量還會繼續(xù)以指數(shù)速度增長。計算公式是 n(n1)/2。在 12 人的團隊中，你有 12(121)/2個渠道，或者說你作為一名項目經理必須維持 66 條關系。再增加一個人，就會變?yōu)?78 條溝通渠道需要監(jiān)管。用普通開發(fā)人員建設軟件項目的想法體現(xiàn)了兩個項目誤區(qū)：1）你可以通過增加人員來縮短項目時間；2）普通開發(fā)人員以平均水平生產普通代碼（bug 成群，偏離任務）也是可以的。實際上，普通開發(fā)人員會拖累整體生產力，并且使項目花費的時間比實際需要的更長。怎樣解決這種情況呢？一是給優(yōu)秀的開發(fā)人員強有力的工具，你將更快獲得高質量的軟件。二是要認識到擁有普通開發(fā)人員對項目沒有幫助，并且照顧差的開發(fā)人員會消減優(yōu)秀開發(fā)人員（他們是工藝師）的生產力。軟件開發(fā)太復雜，它不是一個裝配線生產過程。想要更快地開發(fā)軟件怎么辦？花額外的錢聘請和培養(yǎng)優(yōu)秀的軟件開發(fā)人員。這將在短期和長期（維護代碼時）都給你帶來回報。14. 規(guī)模決定一切項目的規(guī)模、團隊的規(guī)模、交付物的規(guī)模和清單的規(guī)?！椖恐械囊磺凶龇ǘ既Q于它的規(guī)模。規(guī)模改變著游戲進行的規(guī)則。項目經理應該把項目劃分成易管理的模塊，并與有才能的人分別承擔這些模塊，項目（在規(guī)模或復雜性方面）越大，這一點就越重要。這將確保關鍵項目成員（包括項目經理）在為項目做“體檢”時可以看到全局而不至于迷失在細節(jié)中。 分布式項目往往比其他類型的項目規(guī)模大，因此，項目經理用來管理規(guī)模的策略實際上影響著該項目的底線。這個“大”字讓人浮想聯(lián)翩，它可能意味著 8個人連續(xù)工作 12 個月（你是一個小供應商） ，也可能意味著數(shù)百人全年按合同做著維護工作（對你的客戶而言你是一個IT 巨頭） 。這里有幾個關于劃定項目規(guī)模的建議，確保每個人都懂得自己那一小塊可以導致整個大局的成敗。把項目盡可能地分成許多獨立的但可掌控的工作流。 確保每個工作流至少有一個負責傳送的關鍵聯(lián)絡點。 如果可能，盡量讓主要成員在工作流中有交叉，以使整個團隊可以共享 大局觀。分別獨立追蹤每個工作流的進展（使用任何工具） ，并且定期監(jiān)控節(jié)奏以 掌控整個項目的動向。分別記錄和共享每個工作流的風險、問題、承擔的責任以及依賴的條件。 定期舉辦小組會議，通報每一個工作流的狀態(tài)。 公布整個項目的進度路線圖，包括所有不同工作流的發(fā)布計劃。 積極使用在線工具來共享用戶要求、里程碑更新、錯誤報告、報告時限 以及風險。例如，假設你受托設計同一網站的三種不同形式（北美地區(qū)、亞太地區(qū)和中東地區(qū)） 。你決定最好是創(chuàng)建三個不同的工作流，每個都有獨立的傳送聯(lián)絡人。由于三個站點基本上是不同版本的相同網站（相當于是中等規(guī)模的定制） ，所以最好讓幾個關鍵資源在三個工作流中自由移動。這樣他們就可以確保幾個網站的一致性，并可以重復使用具體實現(xiàn)細節(jié)。另一個例子是一個項目可以有多個集成供應商的。比較理想的做法是將每個融合點（或相關的幾個結合點）分離成單獨的工作流，這樣就能多渠道同時工作并且還能縮短傳送時間。每日例會時讓不同團隊協(xié)調整體的傳送質量。15. 記錄工作流程，然后 嚴格執(zhí)行我們試圖把電子郵件從一個平臺轉移到另一個平臺，但僅僅因為一個女人結了婚，我們的電子郵件系統(tǒng)便癱瘓了。該電子郵件流程如下：(1) 新的電子郵件通過新的電子郵件系統(tǒng)發(fā)送。(2) 如果新的電子郵件系統(tǒng)可以發(fā)送，它就把信息發(fā)給正確的新系統(tǒng)用戶。如果不可以發(fā)送的話，該郵件將被發(fā)送到舊的電子郵件系統(tǒng)來投遞。(3) 仍在舊系統(tǒng)中的人給仍在舊系統(tǒng)中的其他用戶發(fā)送郵件時，郵件將會傳送到對應的舊郵箱中。然而，如果收件人已被遷移到新系統(tǒng)，那么電子郵件會通過為每個用戶創(chuàng)建的“遷移”轉發(fā)地址轉發(fā)過去。 有趣的事情出現(xiàn)了。一旦單身薩莉（Sally Single）被遷移到新的電子郵件系統(tǒng)中，她就有了兩個電子郵件地址，一個是 @，另一個是轉發(fā)郵件地址 @。所有舊系統(tǒng)的用戶發(fā)送給她的電子郵件都會通過她的“遷移”轉發(fā)地址自動轉發(fā)到新的郵件系統(tǒng)。當薩莉結婚后，她把名字從“單身薩莉”改為“已婚薩莉” ，她的電子郵件地址隨之改變。然而，新系統(tǒng)中給薩莉的電郵地址重新命名的人忘記改變她在舊系統(tǒng)中電子郵件的“遷移”轉發(fā)地址。所以薩莉就有了下列地址。新系統(tǒng)(1) @(2) @(3) @舊系統(tǒng)(1) @(2) @(3) @（結婚后忘了改變這一條“遷移”轉發(fā)地址。 ）當舊的通信系統(tǒng)用戶給薩莉發(fā)送郵件時，就產生了一個循環(huán)：1）創(chuàng)建信息并發(fā)送到舊的郵件系統(tǒng)地址 @；2）舊的郵件系統(tǒng)檢查薩莉的賬戶，確保將郵件發(fā)送至轉發(fā)地址 @，然后轉發(fā)信息；3）新的郵件系統(tǒng)查找電子郵件地址為 @migrate. 的用戶，但找不到它，因為該地址在薩莉結婚后改名了；4）新電子郵件系統(tǒng)轉發(fā)了未知的收件人郵件到舊系統(tǒng)中；5）舊的系統(tǒng)知道用 @ 地址轉發(fā)所有信息，所以又將它轉發(fā)到新的郵件系統(tǒng)中；6）如此以來，信息像泡沫一樣堆積，循環(huán)往復地發(fā)來發(fā)去。信息每循環(huán)一次，公司的免責聲明就會被添加到消息后。雖然免責聲明只有 100 字左右，但是當每個信息在系統(tǒng)中一分鐘就循環(huán)幾次時，內容就會迅速增加。由此顯得薩莉很受歡迎。有這么多的信息發(fā)送給薩莉，其規(guī)模和容量終于導致電子郵件系統(tǒng)癱瘓。這個故事的寓意：應記錄工作流程，并確保嚴格執(zhí)行。在這個故事里，雖然更名的流程已經記錄好，但沒有得到執(zhí)行。否則，薩莉在舊的郵件系統(tǒng)中的用戶賬號就會隨著她結婚后的新遷移郵件地址一同更新，問題就不會出現(xiàn)。16. 剔除多余的流程成功的團隊做了什么其他人都沒有做的事情？他們不斷質疑自己的流程，并努力消除多余的環(huán)節(jié)。他們毫不留情地對自己的軟件開發(fā)進程進行重構。Il semble que la perfection soit atteinte non quand il n’ y a plus rien 224。 ajouter, mais quand il n’y a plus rien 224。 retrancher。這個法國諺語引自安托萬 德 圣 修伯里，意思是： “完美，不是指無可增，而是指無可減。 ”為什么今天的團隊不應用這個準則呢？為什么隨著時光流逝，最終產品的價值越來越少，而整個過程和副產品卻越來越笨重？為什么代碼行數(shù)在增加，但軟件有用的功能卻越來越少？以下關鍵指標顯示出軟件開發(fā)進程出現(xiàn)了問題：軟件大幅膨脹，出現(xiàn)大量代碼行和無用的功能； 開發(fā)軟件的隊伍的規(guī)模在不斷擴大； 這個過程變得越來越規(guī)范化、教條化、僵硬化； 該團隊正在經歷“規(guī)劃致死”會議； 文件和輔助產品總量以指數(shù)方式增長； 新發(fā)現(xiàn)的漏洞不斷從客戶測試組中涌現(xiàn)。 團隊領導們不斷增加更多流程、更多檢查和更多審查，他們認為日益嚴格的進程將解決這個問題。根據(jù)我的經驗，這絕對不是一個工作進程問題。添加更多的流程只會使團隊更難看清問題的真正根源。為什么大多數(shù)團隊都不敢丟棄那些不能真正幫助他們的流程呢？為什么團隊在一開始就用大量流程，只要能想到的都加上，而不是僅在需要時增加？這可能反映出團隊在最初使用這一流程時并不理解它。或者可能意味著，有人沒有充分了解軟件開發(fā)過程就給團隊套上管理枷鎖。無論是哪種情況，該項目都成了不切實際的計劃，只能變成一堆無用的代碼位。在沒有明白造成項目在膨脹卻沒有增加價值的真正原因時，盲目改變是毫無用處的。在我看來，一個好的項目經理應該正確理解團隊的工作方式。他應該能夠旁觀者清，正確評估每個流程給功能性軟件生產帶來的影響。一個經驗豐富的項目經理應該仔細查看團隊需要去做的所有活動，只保留那些對具體項目成功至關重要的活動。一旦將過去項目中多余的流程去掉，團隊的生產力和工作量就應該很快能提高。談到流程時， “少即是多”是一個非常重要的哲理。17. 矛盾體的需求說明書良好的需求（R）描述一個產品的特性如何解決現(xiàn)有的或潛在的問題。良好的特性（F） ，也稱為功能，被添加到產品中用以處理那些重要的問題。需求是由銷售人員采集或者是由軟件項目經理創(chuàng)建出來的。我們想要在美國之外銷售這個產品（R） 。我們需要提供國際化和本土化 支持（F） 。為了完成一項非常簡單的任務，用戶必須點擊五個按鈕。他們感到失望 并且不會去完成任務。我們需要簡化用戶界面（R） ，并且將按鈕點擊數(shù)減少到兩次以下來完成相同的任務（F） 。另一方面，說明書（S）具體描述了將怎樣解決問題和滿足需求。使用上面這些例子，下面的說明書或許會由系統(tǒng)架構師來寫。我們將抽出所有字符串，包括彈出消息，并且把它們放置在外部資源包 里（S） 。這項應用將會被改進，在屏幕上顯示的所有文本可以從那些資源包里取 出（S） 。創(chuàng)建當?shù)匦枰奶貏e資源包來實現(xiàn)本地化（S） 。 通過點擊按鈕 1,2,3 才能完成的功能將會集成到單獨一個按鈕 A 上（S） 。 現(xiàn)存的按 4 和 5 的功能將被集成到按鈕 B上（S） 。 倘若不分清需求和說明書的界線，就會導致錯誤的人在作決定。導致的結局無外乎兩種，要么是讓軟件開發(fā)人員來決定什么功能對客戶重要，要么是軟件項目經理來告知開發(fā)人員如何構建代碼。無論如何，都只會產出低劣的軟件產品。開發(fā)人員沒有經常和客戶、用戶、市場、銷售人員和潛在合作伙伴