第二部分有效開發(fā)

第10章面向客戶的開發(fā)

很多例子都可以證明婆咸，并非所有開發(fā)人員提出的方案都適合客戶。如果對比客戶對開發(fā)速度和需求實現(xiàn)的認可芜辕，就會發(fā)現(xiàn)需求實現(xiàn)才是最重要的尚骄。如果客戶不喜歡產品，他們就不會付款侵续，而你的開發(fā)速度與此無關倔丈，次品終究是次品。所以即使你的上司状蜗，管理層需五，客戶，市場人員轧坎，客戶都盯在開發(fā)速度上宏邮，你應該理智的認知速度與需求的關系。

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

1客戶對于快速開發(fā)的重要性

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

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

l良好的客戶關系能夠提交實際開發(fā)效率煞赢。

l良好的客戶關系能讓客戶感覺開發(fā)速度較快抛计。

2面向客戶的開發(fā)方法

面向客戶的開發(fā)方法可以分為四個方面：計劃，需求分析照筑，設計爷辱，實現(xiàn)。

1．計劃

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

1)選擇恰當?shù)纳芷凇?/p>

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

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

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

5)進行風險管理媒抠。

2．需求分析

需求分析中最具挑戰(zhàn)性的問題是如何獲取真正的需求弟断。

3．設計

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

在系統(tǒng)設計階段，應該允許客戶偶爾提出需求變更苍匆。在開發(fā)中甚至不允許出現(xiàn)對項目目標沒有影響的變更刘急，這種缺乏靈活性的做法是項目的一大弱點。

4．實現(xiàn)

3合理控制客戶的期望值

軟件開發(fā)中的諸多問題浸踩，尤其是關于進度的爭執(zhí)叔汁，大都來源于客戶對項目抱有過高的期望值。

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

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

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

如果期望過高攘须，即使項目運作良好漆撞，也會看起來處于困境之中，即使開發(fā)人員做的很好于宙，也總像一個失敗者浮驳。

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

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

第11章激勵機制

開發(fā)人員奉件，過程，產品昆著，技術县貌，在快速軟件開發(fā)的四維中，開發(fā)人員是最優(yōu)可能縮短項目開發(fā)周期的凑懂。而激勵機制又是影響開發(fā)人員生產力最大的因素煤痕。

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

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

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

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

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

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

l任務的重要性望侈。

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

l工作反饋脱衙。

1．開發(fā)人員的典型動機

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

開發(fā)人員更容易受到發(fā)展機遇鹃锈，個人生活，成為技術主管的機會以及同事間人機關系的影響瞧预。而不容易受地位屎债，受尊敬，責任感垢油，與下屬關系及受任何程度的影響盆驹。

與管理人員相比，開發(fā)人員較少關系責任感或受認可程度滩愁。如果要激勵開發(fā)人員召娜，則應該強調挑戰(zhàn)性，自主性惊楼，學習并使用新技能的機會摘符，職業(yè)發(fā)展以及對他們私生活的尊重等尉辑。

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

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

激勵開發(fā)人員的最重要的五個激勵因素是：成就感蒿往，發(fā)展機遇，工作自主性棕诵，個人生活和成為技術主管的機會裁良。

1．成就感

1)自主權

自主是激勵的一種方法。當人們?yōu)閷崿F(xiàn)自己設置的目標而工作時校套，會比為別人工作更加努力价脾。如果讓開發(fā)人員自己決定工作進度，你不必過分擔心他們是否在努力工作笛匙，而是應該關注一些諸如過于樂觀的進度侨把，自愿加班太多等問題。而那些都不是激勵的問題妹孙。

2)設定目標

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

2．發(fā)展機遇

最聰明優(yōu)秀的人才必定會流向鼓勵個人發(fā)展的企業(yè)。

3．工作樂趣

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

4．個人生活

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

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

5．成為技術主管的機會

3．利用其它激勵因素

1．獎賞和獎勵

2．對業(yè)績的評價

正確進行業(yè)績評價稍味，具有很大的激勵作用。對業(yè)績的評價是管理者能提供的荠卷，最貼切最重要的工作反饋模庐。不論是正面還是負面的評價，都能長時間的影響下屬的表現(xiàn)油宜，因此業(yè)績評價應該經過高度權衡才做出的掂碱。

4．士氣殺手

1．保健因素

當保健因素不具備時，將產生不滿情緒慎冤。然而保健因素達到一定程度后疼燥，并不能提高積極性。這些保健因素包括：合適的光線蚁堤，適合的空調醉者，足夠大的桌子，安靜的環(huán)境披诗，好用的計算機撬即，高效的通訊設備，自由的上下班時間等呈队。

2．管理操控

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

3．執(zhí)行計劃的壓力

一個根本不可能的最后期限宪摧，帶給開發(fā)人員的是積極性降到最低谷才沧。極少人會明明知道不可能還會拼命地要實現(xiàn)目標。

4．缺乏對開發(fā)付出努力的表揚

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

所以當你的項目出現(xiàn)一些問題后，應該適當表揚開發(fā)付出的努力非剃。

5．干涉技術決策

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

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

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

新的計劃討論會猴伶。產品設計。過程優(yōu)化討論會塌西。來了新的開發(fā)人員他挎。

7．生產率障礙

如果環(huán)境阻礙了開發(fā)人員的生產率，管理人員應該設法消除障礙捡需，是開發(fā)小組可以集中精力在開發(fā)工作上雇盖，而不是應對環(huán)境。

8．低質量

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

9．過分夸張的激勵形式

海報庵寞，標語狸相，信口開河以及其他一些打哈哈一樣的激勵行為，不僅不會激勵開發(fā)者捐川，還會使他們感覺自己受到了侮辱脓鹃。

第10章團隊合作

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

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

1.創(chuàng)造高績效團隊

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

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

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

挑戰(zhàn)性的工作拧廊。高效團隊從來不為了一個無聊的目標組建监徘。你呈現(xiàn)項目的方式，將決定團隊將它視為挑戰(zhàn)卦绣，還是視為困難耐量。

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

2.團隊的成員認同感

團隊的認同感问麸，使得成員把團隊目標看得比個人目標重要往衷，他們從團隊的成功中獲得滿足感。而認同感的來源严卖，就是成員在團隊中有機會實現(xiàn)他們個人無法實現(xiàn)的東西席舍。

3.結果驅動的結構

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

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

l團隊必須存在有效溝通系統(tǒng)稠肘，以支持信息在成員之間自由流動福铅。

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

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

4.勝任的團隊成員

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

5.團隊的承諾

愿景序无，挑戰(zhàn)和團隊認同感验毡，結合在一起會使成員可以向團隊做出承諾。

6.相互信任

信任包括四個部分的內容：誠實帝嗡，開放晶通，一致，尊敬哟玷。

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

8.有效的溝通

團隊應該提供一個環(huán)境狮辽，讓團隊成員表達他們真實感受，當他們感覺不好時巢寡，需要及時提出來喉脖，哪怕團隊不得不宣布壞消息。在相互依賴的環(huán)境里抑月，一旦成員意識到問題树叽，就可以立馬提出來，也許還有時間補救谦絮。而與之相反就是掩蓋錯誤题诵，直到錯誤越來越嚴重而無法掩蓋。這對于快速開發(fā)來說层皱，是致命的性锭。

9.自主意識

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

10.授權意識

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

11.小的團隊規(guī)模

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

12.高層次的樂趣

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

l建立一個愿景诅岩。

l創(chuàng)造變化讳苦。

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

l以具有挑戰(zhàn)性的，清楚的和支持的方式委派任務式廷。

l將如何完成任務的細節(jié)留給團隊咐扭。

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

2.團隊為什么會失敗

1.缺乏共同的愿景

2.沒有認同感

3.相互缺乏認可感

4.生產力阻礙

5.低效率的溝通

6.缺乏信任

7.有問題的員工

3.長期的團隊建設

如果能長期保留一個團隊蠕趁，將對快速開發(fā)提供非常堅實的基礎薛闪。PMP里，團隊的生命周期按次序是形成俺陋，震蕩豁延，規(guī)范，成熟倔韭，解散术浪。長期保留團隊瓢对，將大大縮短每個項目的形成寿酌，震蕩和規(guī)范期。下面是長期保持團隊的一些原因：

1.更高的生產效率

2.更低的啟動費用

3.較低的個人問題風險

4.減少人事變動

5.時間空閑問題

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

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

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

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

第11章團隊結構

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

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

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

1.團隊的種類

l問題解決團隊

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

l創(chuàng)新團隊

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

l戰(zhàn)術執(zhí)行團隊

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

2.附加的團隊設計特征

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

l明確的角色和責任

l監(jiān)控個人表現(xiàn)和提供反饋

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

l有效的溝通

信息必須易于獲得。

信息必須有可信來源咱枉。

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

l以事實為依據制定決策

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

組織快速開發(fā)團隊的關鍵蚕断，是理解沒有一種團隊結構可以適用于每一個項目欢伏。

2.團隊模式

本節(jié)中描述的各種模式，并非是一個個不相關的集合亿乳。在這些模式中硝拧，你會發(fā)現(xiàn)很多重復或矛盾。你需要結合許多不同的模式中的一些成分葛假，來分析你的項目障陶。這一節(jié)中，我們希望使你對用不同方式來構建你的團隊產生更多想法桐款，而不是對所有團隊結構做系統(tǒng)化的陳述咸这。

1.業(yè)務團隊

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

技術領導通常是在技術專家中選擇酿雪，而不是在職業(yè)管理者中選擇。

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

業(yè)務團隊可能適用于所有項目：問題解決型，創(chuàng)新型墓毒，和戰(zhàn)術執(zhí)行型吓揪。

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

2.首席程序員團隊

首席程序員團隊所计，又稱外科團隊柠辞。

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

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

后備程序員是首席程序員的戰(zhàn)友厢破。他作為助手荣瑟，批評家治拿，技術聯(lián)絡人，后備力量等支持首席程序員的工作笆焰。

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

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

首席程序員團隊適合創(chuàng)新項目霹娄，戰(zhàn)術執(zhí)行項目能犯。

3.臭鼬項目團隊

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

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

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

4.特征團隊

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

特征團隊有授權西壮，責任和平衡的優(yōu)勢遗增。團隊成員能夠被明確的授權自己負責的領域，因為它包括來自開發(fā)款青，產品做修，文檔，質量管理等各個部門的代表抡草。

5.搜索救援團隊

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

搜索救援團隊特別適合問題解決團隊。但它太基礎康震，不能支持創(chuàng)造性燎含，太短期，不能支持戰(zhàn)術執(zhí)行腿短。

6.SWAT團隊

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

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

SWAT團隊非常適合戰(zhàn)術執(zhí)行團隊凝颇。他們的工作不是去創(chuàng)新而是用他們熟知的技術和實踐來執(zhí)行一個方案潘拱。SWAT團隊在解決問題團隊中也很出色秉继，團隊成員相互信任。

7.專業(yè)運動員團隊

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

管理者的角色是清理障礙盔腔，使開發(fā)者能更有效地工作杠茬。

8.戲劇團隊

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

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

制片人舀透，是軟件管理者栓票，他為項目獲得資金，協(xié)調進度愕够，確保每個人在適當?shù)臅r機到達適當?shù)牡攸c走贪。在項目的藝術方面，制片人通常不會起到作用惑芭。

戲劇團隊的優(yōu)勢是在創(chuàng)新項目團隊中坠狡。

9.大型團隊

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

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

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

l建立一系列的業(yè)務團隊假消。

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

l建立特征團隊究飞。

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

3.管理者與技術領導

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

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

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

第10章功能限定

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

最嚴重的功能限定問題，就是需求蔓延副编。需求蔓延是指在產品開發(fā)的晚期增加需求队腐。

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

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

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

l項目中期控制环疼。控制需求和蔓延熏迹。

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

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

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

規(guī)格說明最小化。

需求提煉捆昏。

版本開發(fā)赚楚。

1.規(guī)格說明最小化

需求規(guī)格需要詳細到什么程度？傳統(tǒng)的做法是越詳細越好屡立。一個能夠把握更多需求的直晨，詳盡的規(guī)格說明書搀军，會避免在項目晚期由于追加需求而引起的時間和費用問題膨俐。

傳統(tǒng)規(guī)格說明書存在的問題

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

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

l缺乏功效。以十分詳細的方式陳述系統(tǒng)需求坡脐，并不能保證系統(tǒng)的成功泄私。系統(tǒng)可以滿足規(guī)格說明書，但仍然不能令人滿意备闲。

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

一份傳統(tǒng)的咧纠，詳盡的規(guī)格說明書，能夠讓人感覺軟件開發(fā)的目標是開發(fā)一個與計劃一致的軟件泻骤。但真正的目標應該是在可利用的時間內開發(fā)一個最合理的軟件漆羔。

寫一份最小的規(guī)格說明書

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

l一份簡短的紙面規(guī)格說明。要構建的軟件產品的文本描述狱掂。最好不要超過十頁紙演痒。

l起程點規(guī)格說明。這是一次性的規(guī)格說明符欠，寫完后不再變更嫡霞。主要目的是使開發(fā)組，客戶希柿，最終用戶對產品具有共同的視角诊沪。一旦目的達到了，這份規(guī)格說明就起到作用了曾撤，也就不用再維護了端姚。

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

l用戶界面原型。一圖勝千言昏鹃，可以節(jié)省大量時間尚氛。

l情節(jié)串聯(lián)板(storyboard)。

l可視化陳述洞渤。

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

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

最小規(guī)格說明的好處

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

l改進士氣和動機捣炬。最小規(guī)格說明方法，使開發(fā)者更多的需要自己去規(guī)劃產品怠晴，而當開發(fā)者自己規(guī)劃產品時遥金，更容易保證產品的成功。這點還是要看情況蒜田，主要是考慮團隊人員的水平稿械。

l機會效率。

l減少人力浪費冲粤。

l縮短需求分析階段美莫。

最小規(guī)格說明的風險

l忽略關鍵需求。

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

l鍍金厢呵。

l缺乏并行工作支持。

l增加開發(fā)人員對特殊功能的依戀傀顾。

l因為錯誤的原因而使用最小規(guī)格說明襟铭。

最小規(guī)格說明成功的關鍵因素

l僅當需求具有柔性時，使用最小規(guī)格說明短曾。

l保持規(guī)格說明最小化寒砖。最小規(guī)格說明默認的是，開發(fā)者將對它們進行更進一步的說明嫉拐，當你開始表示懷疑時哩都，趕緊放棄。

l獲取重要的需求婉徘。

l采用柔性的開發(fā)方法漠嵌。

l關鍵用戶參與咐汞。

l關注圖形化文件。

2.需求篩選

早期從產品中刪除一個功能是縮短軟件進度最有效的方法儒鹿。因為每刪除一個功能化撕，與之相關的需求，設計挺身，開發(fā)侯谁，測試锌仅，文檔等一系列工作都能刪除章钾。需求篩選比最小規(guī)格的風險要小。

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

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

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

使用需求篩選府寒，一定要注意一個現(xiàn)象：早期你將100條需求，篩選到70條报腔，那么你只需要70%的工作量即可完成工作株搔。但是后期，70條需求又變成了100條纯蛾，那么這個項目將要付出比原來更多的工作量纤房。

3.版本開發(fā)

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

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

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

1.變化的根源

最終用戶芦圾，會因為需要額外功能蛾派，或需要不同于設計的功能，或在系統(tǒng)建設過程中獲得對系統(tǒng)的進一步了解个少，而希望變更需求洪乍。

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

開發(fā)人員，會因為他們對系統(tǒng)存在著感情和智力上的投資糊探，而要求需求變更钾埂。例如他們正在開發(fā)第二版河闰，他們就會希望對第一版中存在的不足，提出變更褥紫。

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

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

l不清楚或不可能的目標豌研。如果目標不清楚瓣距，那么不同開發(fā)者對同一目標將會有差距非常大的實現(xiàn)方式右冻。

2.變更的影響

3.完全停止變更的行為

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

4.變更的控制方法

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

l在適當?shù)臅r間里霜浴，允許有助于產品生產的變更晶衷。不允許其他變更。

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

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

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

面向用戶的需求實踐

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

變更分析

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

版本２

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

短的發(fā)布周期

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

變更控制委員會（CCB）

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

1)結構。典型的CCB由在產品中具有利害關系的每一小組的代表組成伯顶。如開發(fā)囚灼，質保，測試祭衩，客戶灶体，市場和管理等等。

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

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

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

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

3.項目后期：功能裁剪

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

當你到了這種地步孵运，利用功能裁剪秦陋，去除一些低優(yōu)先級的功能是最有效的方法。

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

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