第二部分有效開發

第10章面向客戶的開發

很多例子都可以證明，并非所有開發人員提出的方案都適合客戶。如果對比客戶對開發速度和需求實現的認可，就會發現需求實現才是最重要的。如果客戶不喜歡產品，他們就不會付款，而你的開發速度與此無關，次品終究是次品。所以即使你的上司，管理層，客戶，市場人員，客戶都盯在開發速度上，你應該理智的認知速度與需求的關系。

本章中穿插介紹了一些有助于維系良好客戶關系的常規做法，其他一些特殊的方法，可以參見第三部分“最佳實踐方法”。

1客戶對于快速開發的重要性

項目成功的第一要素是客戶參與。

造成進度延誤，成本超出，達不到預期功能的前三個因素分別是：缺乏與用戶的溝通，需求說明不完備，中途變更需求說明。你可以通過面向客戶的開發方式來克服這幾個問題。以下是項目中需要花費精力去維護客戶關系的非常重要的理由：

l良好的客戶關系能夠提交實際開發效率。

l良好的客戶關系能讓客戶感覺開發速度較快。

2面向客戶的開發方法

面向客戶的開發方法可以分為四個方面：計劃，需求分析，設計，實現。

1．計劃

使用以下方法可以增加客戶對項目的滿意度：

1)選擇恰當的生命周期。

2)弄清楚項目最終是讓誰滿意。

3)建立有效的客戶溝通渠道。

4)力爭采取雙贏的方案。

5)進行風險管理。

2．需求分析

需求分析中最具挑戰性的問題是如何獲取真正的需求。

3．設計

在需求分析階段的工作可能完成得很好，也可能完成得不好。因此在設計階段還應該進一步實現面向客戶的目標。

在系統設計階段，應該允許客戶偶爾提出需求變更。在開發中甚至不允許出現對項目目標沒有影響的變更，這種缺乏靈活性的做法是項目的一大弱點。

4．實現

3合理控制客戶的期望值

軟件開發中的諸多問題，尤其是關于進度的爭執，大都來源于客戶對項目抱有過高的期望值。

造成過高期望值的原因之一就是進度計劃。許多項目在需求和資源都不清晰的前期，便由客戶指定了進度計劃。因此協助用戶在制作進度計劃時，樹立現實的期望是項目成功的關鍵之一。

努力弄清客戶的期望值，可以減少大量的矛盾和額外的工作量。因為客戶并不愚蠢，只是對軟件開發沒有充分的認識，所以培訓客戶以使他們更好的理解軟件開發過程，是PM以及開發人員應該承擔的工作，這項工作使得控制客戶的期望成為可能。

以任何理由(為使有爭議的項目上馬，為項目爭取足夠的資金，為獲得項目的開發權)使客戶對項目進度，費用或功能造成不切實際的期望，都將給項目帶來不可克服的風險。這點在孕育之家二期表現非常明顯，我為了獲得項目的開發權，而給商務和客戶對費用產生了較高的期望，而給項目帶來了非常大的風險。

如果期望過高，即使項目運作良好，也會看起來處于困境之中，即使開發人員做的很好，也總像一個失敗者。

期望過高也將損害團隊的可信度，破壞同客戶的關系。

因此輕易的許諾，在項目初期也可能會令各方滿意，在長遠來看是非常有害的。

第11章激勵機制

開發人員，過程，產品，技術，在快速軟件開發的四維中，開發人員是最優可能縮短項目開發周期的。而激勵機制又是影響開發人員生產力最大的因素。

在許多項目中，管理層都是撿了芝麻丟了西瓜，以士氣大減的代價去換取微不足道的方法改進或預算節省，這樣實際上大大減低了開發人員的積極性。

本章將闡述一些激勵開發人員以提高生產速度的方法。

人的內在動力來自三個方面：感受到工作的意義，對工作成果的責任，以及了解工作的實際結果。

工作中有5個方面對提高工作動力有所貢獻：

l技術的多樣性。使工作不至于枯燥。

l任務的完整性。進行一項完整的工作，能讓人對其更加關注。

l任務的重要性。

l自主性。能按照自己的工作習慣處理工作的自由度。

l工作反饋。

1．開發人員的典型動機

不同的人會因為不用的因素而得到激勵；同一個因素會應該開發人員，管理人員，普通人的身份不同而影響不同。以下是對于三種身份的動機順序表：

開發人員更容易受到發展機遇，個人生活，成為技術主管的機會以及同事間人機關系的影響。而不容易受地位，受尊敬，責任感，與下屬關系及受任何程度的影響。

與管理人員相比，開發人員較少關系責任感或受認可程度。如果要激勵開發人員，則應該強調挑戰性，自主性，學習并使用新技能的機會，職業發展以及對他們私生活的尊重等。

2．最重要的五個激勵因素

踹一腳并不能產生動力，只能產生被動行為。所以在設置激勵機制時，不僅要讓開發人員表面上動起來，更要調動內在的動力。

激勵開發人員的最重要的五個激勵因素是：成就感，發展機遇，工作自主性，個人生活和成為技術主管的機會。

1．成就感

1)自主權

自主是激勵的一種方法。當人們為實現自己設置的目標而工作時，會比為別人工作更加努力。如果讓開發人員自己決定工作進度，你不必過分擔心他們是否在努力工作，而是應該關注一些諸如過于樂觀的進度，自愿加班太多等問題。而那些都不是激勵的問題。

2)設定目標

設定切實可行的目標是激勵的另一種方法。在設定目標時，需要注意一些問題：第一個問題是目標一定要可行，不要定的不切實際或者太遠。第二個問題是目標不要同時設置太多。

2．發展機遇

最聰明優秀的人才必定會流向鼓勵個人發展的企業。

3．工作樂趣

工作的樂趣是造成質量比進度更可能有效地激勵程序員的原因之一。

4．個人生活

個人生活因素對開發人員的影響是管理人員難以理解的。與之對應的就是責任感，責任感對管理人員的影響也是開發人員難以理解的。

對一個公司來說，想要用個人生活作為激勵，就必須做出實際計劃使開發人員有時間享受個人生活，比如安排假期，同意開發人員在工作日偶爾外出。

5．成為技術主管的機會

3．利用其它激勵因素

1．獎賞和獎勵

2．對業績的評價

正確進行業績評價，具有很大的激勵作用。對業績的評價是管理者能提供的，最貼切最重要的工作反饋。不論是正面還是負面的評價，都能長時間的影響下屬的表現，因此業績評價應該經過高度權衡才做出的。

4．士氣殺手

1．保健因素

當保健因素不具備時，將產生不滿情緒。然而保健因素達到一定程度后，并不能提高積極性。這些保健因素包括：合適的光線，適合的空調，足夠大的桌子，安靜的環境，好用的計算機，高效的通訊設備，自由的上下班時間等。

2．管理操控

有些管理者試圖以虛假的最后期限的方式來實施項目控制，而大部分開發人員對此非常敏感。

3．執行計劃的壓力

一個根本不可能的最后期限，帶給開發人員的是積極性降到最低谷。極少人會明明知道不可能還會拼命地要實現目標。

4．缺乏對開發付出努力的表揚

通常的理解是這樣：人們既然不能親眼見到開發人員正在如何工作，也就不會認為他們做了很多工作，從而覺得計劃出現阻礙是開發的責任。然而真實情況是開發人員正在努力的自我激勵，勤奮工作，加班加點。當開發人員被誤解為磨洋工時，他們就會覺得沮喪，而降低工作效率。

所以當你的項目出現一些問題后，應該適當表揚開發付出的努力。

5．干涉技術決策

如果管理人員干涉自己并不在行的技術決策，一定會在項目組內成為笑料。而絕大部分人不會受到一個自己不尊重的人的激勵。對非技術型管理人員來說，干涉技術決策是一個非常嚴重的錯誤。

6．開發人員沒有參與同自己有關的決策

開發人員沒有參與同自己有關的決策，似乎說明管理層對開發小組不夠重視和關心。如果要保持開發人員的士氣高漲，必須讓開發人員參與決策。下面是一些典型的場景：

新的計劃討論會。產品設計。過程優化討論會。來了新的開發人員。

7．生產率障礙

如果環境阻礙了開發人員的生產率，管理人員應該設法消除障礙，是開發小組可以集中精力在開發工作上，而不是應對環境。

8．低質量

項目管理者如果堅持為了苛刻的計劃而降低質量要求，那么開發人員會感到沮喪。低質量的產品剝奪了開發人員的成就感。

9．過分夸張的激勵形式

海報，標語，信口開河以及其他一些打哈哈一樣的激勵行為，不僅不會激勵開發者，還會使他們感覺自己受到了侮辱。

第10章團隊合作

當多個人合作，整體成果比個體成果的和加起來要大時，才有組建團隊的必要。反之，如果大家有沖突，整體會比所有部分相加的總和要小，就沒有團隊的必要了。

所以，并不是所有項目都需要建立團隊。有些項目只需要由多人小組就可以做得很好了，不需要建立團隊。一些項目并不需要達到團隊合作所需要承擔的水平。

1.創造高績效團隊

1.共同的，可提升的愿景或目標

在項目開始運作之前，項目團隊需要“buy in”一個共同的愿景或目標。任何一個高效的團隊對于自己的目標都有清楚的認知。

項目愿景可以使一些小問題的決策得以簡化。

挑戰性的工作。高效團隊從來不為了一個無聊的目標組建。你呈現項目的方式，將決定團隊將它視為挑戰，還是視為困難。

例子：“我們想建立一個市場排名第3往后的，質量低于市場平均質量水準的數據庫產品”。沒有人會為了這個目標而高效工作。或者你可以這樣呈現項目：“我們將建立一個數據庫產品，使我們的市場份額從0提升到10%，市場和生產需要一個絕對可靠的進度計劃。所以我們以內部里程碑和最終時限作為目標，一定要有100%的把握實現它。”這樣的方式，團隊有可能會為這100%的精確目標而奮斗。

2.團隊的成員認同感

團隊的認同感，使得成員把團隊目標看得比個人目標重要，他們從團隊的成功中獲得滿足感。而認同感的來源，就是成員在團隊中有機會實現他們個人無法實現的東西。

3.結果驅動的結構

結果驅動結構的基本特征：

l角色必須明確。每個人在任何時刻都應該對各自的工作負責。責任對有效決策的制定，和對已制定的決策的快速實施十分關鍵。

l團隊必須存在有效溝通系統，以支持信息在成員之間自由流動。

l團隊必須以某種方式監控個人表現并提供反饋。團隊應該知道誰應該受到獎勵，誰需要個人的進一步發展，誰能夠承擔更多責任。

l任何時候的決策制定都要以事實為基礎。而不是以個人主觀意見為依據。

4.勝任的團隊成員

對于快速開發，要以項目目前最需要的技能為標準，其中三種能力最為重要：項目需要的特殊技能；強烈投身于工作的愿望；善于與團隊成員有效合作。

5.團隊的承諾

愿景，挑戰和團隊認同感，結合在一起會使成員可以向團隊做出承諾。

6.相互信任

信任包括四個部分的內容：誠實，開放，一致，尊敬。

7.團隊成員間的相互依賴

8.有效的溝通

團隊應該提供一個環境，讓團隊成員表達他們真實感受，當他們感覺不好時，需要及時提出來，哪怕團隊不得不宣布壞消息。在相互依賴的環境里，一旦成員意識到問題，就可以立馬提出來，也許還有時間補救。而與之相反就是掩蓋錯誤，直到錯誤越來越嚴重而無法掩蓋。這對于快速開發來說，是致命的。

9.自主意識

自主意識與成員從項目經理那里感覺到的信任感有關系。經理信任團隊是非常重要的。這意味著經理不要進行事后的批評或施加強硬的決策。當團隊很明顯都正確的時候，任何經理都會支持團隊，這不叫信任。只有當團隊看上去好像錯誤的時候支持他們，這才叫信任。

10.授權意識

高效團隊需要意識到被授權可以采取任何為獲得項目成功所需要采取的行動。哪怕是抵制組織的不合理要求。

11.小的團隊規模

一些專家認為一個團隊的成員最好少于8到10個人。

12.高層次的樂趣

以下是成功管理高凝聚力團隊的幾個關鍵：

l建立一個愿景。

l創造變化。

l管理團隊。使團隊為團隊的行為負責，而不是團隊成員為他們各自的行為負責。

l以具有挑戰性的，清楚的和支持的方式委派任務。

l將如何完成任務的細節留給團隊。

l當團隊運行不好的時候，想想MOI模式：多數的團隊問題來源于：動機，組織或信息。嘗試清除有關這三個方面的障礙。

2.團隊為什么會失敗

1.缺乏共同的愿景

2.沒有認同感

3.相互缺乏認可感

4.生產力阻礙

5.低效率的溝通

6.缺乏信任

7.有問題的員工

3.長期的團隊建設

如果能長期保留一個團隊，將對快速開發提供非常堅實的基礎。PMP里，團隊的生命周期按次序是形成，震蕩，規范，成熟，解散。長期保留團隊，將大大縮短每個項目的形成，震蕩和規范期。下面是長期保持團隊的一些原因：

1.更高的生產效率

2.更低的啟動費用

3.較低的個人問題風險

4.減少人事變動

5.時間空閑問題

組織有時不愿意保留團隊，因為假如團隊空閑，他們還不得不繼續付錢。直到有一個項目適合他們來做。這聽起來似乎有道理，但實際上在多數情況下并不劃算。

組織僅僅看到團隊空閑時間的成本，而忽略了每一個項目新建團隊的花費。新建團隊并非是把人集合在一起就完事了。

組織總是忽視了拆散一個高業績團隊帶來的損失。他們寧愿冒一個風險，就是把高業績團隊可能變成一個普通團隊或比較差的團隊。

4.團隊合作指導方針總結

第11章團隊結構

即使你擁有了技術，有動力并且努力的員工，錯誤的團隊結構也會削弱他們的努力。

本章描述了組建快速開發團隊時需要考慮的因素。包括團隊結構中最棘手的問題之一：項目經理與技術領導之間的關系。

1.團隊結構應該考慮的因素

1.團隊的種類

l問題解決團隊

問題解決團隊的重點在于解決一個復雜，沒有被明確定義的問題。例如一組為疾病控制中心工作的流行病專家。對問題解決團隊成員的要求是可信賴的，聰明的和活躍的。團隊結構應該支持這個問題的重點。

l創新團隊

創新團隊的宗旨是探索可能性和選擇性。例如一組麥當勞食品科學家嘗試發明一款新的麥當勞食品。創新團隊成員需要自我激勵，獨立，富于創新和百折不撓。團隊結構需要支持團隊成員的個人和集體自治。

l戰術執行團隊

戰術執行團隊的重點在于執行一個定義良好的計劃。例如一個棒球隊參與一個由教練制定好的戰術比賽打法。這種團隊是以高度集中的任務和清楚定義的角色為特點。戰術執行團隊成員需要對他們的團隊使命有緊迫感，對行動比推理更有興趣，并且忠誠于團隊。

2.附加的團隊設計特征

除了以上三種基本團隊種類，還有四個團隊特征，幾乎可以代表所有有效運行的團隊：

l明確的角色和責任

l監控個人表現和提供反饋

責任感的另一方面是團隊成員能通過某種方式知道他們無愧于團隊的期望。團隊應該有一種機制讓成員知道他們的表現是可以接受還是有待進一步提高。

l有效的溝通

信息必須易于獲得。

信息必須有可信來源。

成員必須有權利在任何時候，正式或非正式提出問題。

l以事實為依據制定決策

3.何種團隊類型最適用于快速開發

組織快速開發團隊的關鍵，是理解沒有一種團隊結構可以適用于每一個項目。

2.團隊模式

本節中描述的各種模式，并非是一個個不相關的集合。在這些模式中，你會發現很多重復或矛盾。你需要結合許多不同的模式中的一些成分，來分析你的項目。這一節中，我們希望使你對用不同方式來構建你的團隊產生更多想法，而不是對所有團隊結構做系統化的陳述。

1.業務團隊

最常見的團隊結構。由一個技術領導帶領團隊，其他成員都有相同的身份。

技術領導通常是在技術專家中選擇，而不是在職業管理者中選擇。

從外面看來，業務團隊的結構是典型的等級層次結構，它通過確定一個人主要負責項目中的技術工作來改善與管理部門的溝通；允許員工在自己的領域內工作，允許團隊自己劃分誰工作于哪一部分。

業務團隊可能適用于所有項目：問題解決型，創新型，和戰術執行型。

但是它的普遍性也是它的弱點。

2.首席程序員團隊

首席程序員團隊，又稱外科團隊。

首席程序員團隊利用了某些程序員的開發效率是其他人10倍這一現象。一般的團隊結構，將普通程序員和超級程序員放在相同的位置上，你受益于超級程序員高效的同時，也被其他低效程序員拖累。

在首席程序員團隊中，一個超級程序員被認為是外科手術的主刀醫生，由他起草整個說明書，完成所有設計，編寫大部分代碼，最終負責幾乎所有產品的項目決策。

后備程序員是首席程序員的戰友。他作為助手，批評家，技術聯絡人，后備力量等支持首席程序員的工作。

管理員處理管理事務，諸如財務，人員，場地，機器設備等。管理員的存在是為了將首席程序員從大量日常管理工作中解脫出來。

工具員負責制作首席程序員要求定制的工具，運行每日構建的內容。

首席程序員團隊適合創新項目，戰術執行項目。

3.臭鼬項目團隊

臭鼬項目團隊是工程領域不可欠缺的一部分。臭鼬項目團隊有一批有才華的，有創造性的產品開發者，將他們放在一個不受官僚限制的組織中，使他們能放手開發和創新。臭鼬團隊是典型的黑箱管理方式。

臭鼬團隊有利于創建一種緊密的所有權關系，以及調動有關開發人員的特別投入，因為它的激勵效果是驚人的。不利方面在于沒有為團隊進展提供足夠的可視度。

臭鼬團隊對于創造性最為重要的探索性項目非常適合。當你要解決精確定義的問題，或需要執行一個精確理解的計劃時，臭鼬團隊是難得的最快速的結構。

4.特征團隊

特征團隊從每一個部門中抽取一個或多個成員，每個部門的成員還是向自己部門的經理匯報。(類似PMP里的職能型組織)。

特征團隊有授權，責任和平衡的優勢。團隊成員能夠被明確的授權自己負責的領域，因為它包括來自開發，產品，文檔，質量管理等各個部門的代表。

5.搜索救援團隊

搜索救援團隊的重點在于解決特定的問題。

搜索救援團隊特別適合問題解決團隊。但它太基礎，不能支持創造性，太短期，不能支持戰術執行。

6.SWAT團隊

SWAT團隊中，每一個成員都被嚴格訓練成某一方面的專家，他們共同合作，天衣無縫。

SWAT團隊通常是最持久的團隊。他們也許不是用全部的時間來做項目，但是他們習慣在一起工作，并有明確定義的角色。

SWAT團隊非常適合戰術執行團隊。他們的工作不是去創新而是用他們熟知的技術和實踐來執行一個方案。SWAT團隊在解決問題團隊中也很出色，團隊成員相互信任。

7.專業運動員團隊

管理者對于軟件開發者的挑選，就像教練對運動員的挑選一樣認真，可能這對項目的成功更為關鍵。

管理者的角色是清理障礙，使開發者能更有效地工作。

8.戲劇團隊

戲劇團隊是以強烈的方向性和很多關于項目角色的協商為特點的。

導演，是項目的中心角色，他保持產品的愿景目標和指定人們在各自范圍內的責任。

制片人，是軟件管理者，他為項目獲得資金，協調進度，確保每個人在適當的時機到達適當的地點。在項目的藝術方面，制片人通常不會起到作用。

戲劇團隊的優勢是在創新項目團隊中。

9.大型團隊

大型團隊在溝通上存在特殊的問題。類似PMP里溝通路徑條數的計算(n*n-1)/2。

形式化的溝通是大型項目成功的重要因素。所以簡化溝通會對團隊結構有很大影響。

簡化溝通的方式主要是創造某種層次。就是說劃分成小組，小組的功能像團隊一樣，然后小組中指定代表來相互溝通。你可以以多種方式劃分小組：

l建立一系列的業務團隊。

l建立一系列的首席程序員團隊。

l建立特征團隊。

不管小的團隊如何組織，我認為有一個人最終負責產品概念上的完整性是非常關鍵的。這個人的工作是確保把所有團隊的所有成功解決方案拓展成為成功的全局解決方案。

3.管理者與技術領導

在很多團隊項目中，都存在技術領導角色，他是以技術專家的身份為委派這個角色，他并非管理專家。涉及開發和管理兩個方面的只能對于這個人來說，通常是個棘手的問題。

技術領導角色最大的障礙之一，就是在技術與管理之間缺乏明確的職責劃分，通常是職能混亂。

從團隊的角度來看，管理者的角色是減輕技術領導處理非技術事物的職責。從組織的角度看，管理者的角色是控制團隊以和組織的目標保持一致。

第10章功能限定

軟件開發人員和管理者都聲稱了解功能限定的必要性，但是真實情況卻不是這樣，開發人員，管理者，市場人員和最終用戶始終在為已經很龐大的產品填充著更多特性，以至于有人以此為理由為低劣的軟件產品進行維護。

最嚴重的功能限定問題，就是需求蔓延。需求蔓延是指在產品開發的晚期增加需求。

功能限定問題，將帶來成本超支，進度延遲等問題。

在普通功能限定方法中包括三點：

l項目早期控制。制定一個與進度和預算目標一致的功能集。

l項目中期控制。控制需求和蔓延。

l項目晚期控制。剪切部件以適應進度和成本目標。

1.項目早期：功能的簡化

項目早期階段的功能限定主要是不要把不必要的功能引入到產品原型中。有三種方法縮小范圍：

規格說明最小化。

需求提煉。

版本開發。

1.規格說明最小化

需求規格需要詳細到什么程度？傳統的做法是越詳細越好。一個能夠把握更多需求的，詳盡的規格說明書，會避免在項目晚期由于追加需求而引起的時間和費用問題。

傳統規格說明書存在的問題

l浪費。你可以花費時間描述十分詳細的系統特征。比如本來該由開發人員作出判斷的地方：對話框的大小，位置，光標移動次序等。

l退化。項目中期的變更會很快導致需求說明書的過時。維護需求說明書的任務變成了一個道德上的，官僚政治任務，而不是一個有益于項目進程的工作。

l缺乏功效。以十分詳細的方式陳述系統需求，并不能保證系統的成功。系統可以滿足規格說明書，但仍然不能令人滿意。

l過度限制設計。過分的限定軟件，可能會使設計者是實施者浪費大量時間。

一份傳統的，詳盡的規格說明書，能夠讓人感覺軟件開發的目標是開發一個與計劃一致的軟件。但真正的目標應該是在可利用的時間內開發一個最合理的軟件。

寫一份最小的規格說明書

以下是一些最小規格說明書的方案：

l一份簡短的紙面規格說明。要構建的軟件產品的文本描述。最好不要超過十頁紙。

l起程點規格說明。這是一次性的規格說明，寫完后不再變更。主要目的是使開發組，客戶，最終用戶對產品具有共同的視角。一旦目的達到了，這份規格說明就起到作用了，也就不用再維護了。

l用戶手冊式規格說明。用戶手冊是遲早要寫的，而且軟件需要跟用戶手冊保持一致。所以使用用戶手冊來代替規格說明也是一種方案。

l用戶界面原型。一圖勝千言，可以節省大量時間。

l情節串聯板(storyboard)。

l可視化陳述。

l產品主題。產品主題是相對于視覺而言的，是控制功能的一個好的機制。

使用最小規格說明，需要考慮需求的靈活性。像生產一臺波音飛機這樣的項目，由于需求非常嚴格，就不適合使用最小規格說明方法。

最小規格說明的好處

有效使用最小規格說明，可以產生幾個關于時間的好處：

l改進士氣和動機。最小規格說明方法，使開發者更多的需要自己去規劃產品，而當開發者自己規劃產品時，更容易保證產品的成功。這點還是要看情況，主要是考慮團隊人員的水平。

l機會效率。

l減少人力浪費。

l縮短需求分析階段。

最小規格說明的風險

l忽略關鍵需求。

l不清楚或不可能的目標。

l鍍金。

l缺乏并行工作支持。

l增加開發人員對特殊功能的依戀。

l因為錯誤的原因而使用最小規格說明。

最小規格說明成功的關鍵因素

l僅當需求具有柔性時，使用最小規格說明。

l保持規格說明最小化。最小規格說明默認的是，開發者將對它們進行更進一步的說明，當你開始表示懷疑時，趕緊放棄。

l獲取重要的需求。

l采用柔性的開發方法。

l關鍵用戶參與。

l關注圖形化文件。

2.需求篩選

早期從產品中刪除一個功能是縮短軟件進度最有效的方法。因為每刪除一個功能，與之相關的需求，設計，開發，測試，文檔等一系列工作都能刪除。需求篩選比最小規格的風險要小。

l排除完全不必要的需求。

l簡化比實際需求復雜的需求。

l使用更容易的操作，代替原來的操作。

使用需求篩選，一定要注意一個現象：早期你將100條需求，篩選到70條，那么你只需要70%的工作量即可完成工作。但是后期，70條需求又變成了100條，那么這個項目將要付出比原來更多的工作量。

3.版本開發

另一種刪除需求的方案，是從當前版本中刪除。

2.項目中期：功能蔓延的控制

當你制定了一個規格說明書后，你可能認為該產品功能已經在你控制之下，其實不然。在開發過程中，還有將近25%的需求變更。

1.變化的根源

最終用戶，會因為需要額外功能，或需要不同于設計的功能，或在系統建設過程中獲得對系統的進一步了解，而希望變更需求。

市場人員，會因為他們以功能驅動去觀察市場，而要求需求變更。

開發人員，會因為他們對系統存在著感情和智力上的投資，而要求需求變更。例如他們正在開發第二版，他們就會希望對第一版中存在的不足，提出變更。

各種人員會因各自的原因希望變更。以下是一些造成需求變化的原因：

l迷人程序綜合癥。公司A準備研發一款商業封裝軟件，就在完成研發的前幾周，B公司的產品進入市場了，并且包含A公司的產品沒有考慮到的功能或特性，這時A公司決定延長進度，參考B公司的產品功能。就在快要完成的時候，C公司的產品也進入市場了。結果A公司下一輪的需求變更開始了。

l不清楚或不可能的目標。如果目標不清楚，那么不同開發者對同一目標將會有差距非常大的實現方式。

2.變更的影響

3.完全停止變更的行為

當你借口不允許或不希望變更，而不允許必要的變更時，也是需求失控的一種形式。

4.變更的控制方法

任何變更管理計劃都要瞄準以下幾個目標：

l在適當的時間里，允許有助于產品生產的變更。不允許其他變更。

l允許受到變更影響的當事人，對變更的進度計劃，資源和產品的效果進行評價。

l向每一個計劃變更的干系人通報對它的影響的評價，以及是否接受變更。

l提供與項目內容有關的審查結果。

面向用戶的需求實踐

面向用戶的需求采集是獲得真正需求的較好的工作方法。

變更分析

對變更說不的最好方法是，提供有關變更對費用，進度的影響。

版本２

在未來的版本中考慮變更，也是可行的方案。但一定需要記錄成資料。

短的發布周期

之所以版本２的方式能夠得到客戶的認同，關鍵因素是因為他們得到了他們希望的內容將在產品中出現的承諾，盡管不是在當前實現。所以短的發布周期，將建立客戶信心，讓他們相信他們關心的內容最終將會加入到產品中。

變更控制委員會（CCB）

變更控制委員會已經被證明能夠有效地組織大項目中的需求蔓延，并且對小項目也有效。

1)結構。典型的CCB由在產品中具有利害關系的每一小組的代表組成。如開發，質保，測試，客戶，市場和管理等等。

2)變更分析。CCB的功能是對每一變更進行分析。典型的分析就是從多重約束的各個端開始：產品范圍，進度，成本，質量。

3)鑒別分類。CCB有權對每一變更進行接收和拒絕。

4)打包。CCB也能夠集合小的變更，一邊開發者能夠打包處理它們。因為一連串變更，如果不經整理就傳到開發，將付出比較大的代價。

5)官僚機構問題。CCB在人們印象里被描繪成為了過度官僚的機構。是因為CCB在對變更說不時，更多地是在說明他們的許可權，而不是在強調他們的分析結果，已經他們能夠給出的方案。

3.項目后期：功能裁剪

即便你在前期和中期的功能限制都做得比較好，由于一些原因，項目還是落在了計劃的后面。

當你到了這種地步，利用功能裁剪，去除一些低優先級的功能是最有效的方法。

這個方法的缺陷在于：當你到了項目后期，其實你已經花費了被剪切功能的設計，文檔和部分實現工作。甚至還要剝離一部分已經完成的代碼。

為了避免這些缺點，你可以提前做好計劃，選擇支持晚期功能裁剪的生命期模型。