前麵各章在描述微軟的戰略及其具體原則時，我們已經詳細闡述了公司的一些出眾之處。在這一章中我們把這些長處再簡要回顧一下，同時重點突出其中對其他公司有借鑒作用並且能夠幫助微軟在未來取得良好業績的那些方麵。然後討論在我們看來屬於微軟致命的弱點的方麵——包括事實的和潛在的弱點以及它們對其他公司提供的教訓。最後在結束此書時我們將討論微軟麵臨的戰略挑戰，根據產品、市場、科技的發展趨勢微軟將如何實施它最基本的戰略——向未來進軍。
在這最後一章，我們的思想建立在以下幾個對未來的基本假定上。首先，我們相信個人計算機軟件在功能方麵會變得更為豐富繁多，對微軟這樣的軟件公司來說越來越難以生產。新產品將把原先在不同的應用程序、操作係統以及網絡通信產品中的許多特點都集於一身。第二，與此同時，我們相信未來的個人計算機軟件，從用戶的角度看，將會變得更加簡單和可靠。這將使成百萬（甚至上億）的新家庭消費者更加頻繁地使用電腦，處理各種各樣的日常工作事務。第三，我們認為像個人計算機軟件這樣的高科技市場變化得很快，以至於我們無法斷言十年以後微軟是否仍是世界上最具實力的軟件公司。同樣我們無法確信，微軟將成功地保持其在當前市場上所處的地位，並且將其主導權擴展到新的差異很大的市場上，例如聯機服務或多媒體出版方麵。我們堅信微軟不會失敗，它將在目前已有的市場及其他新的市場上積極進取，而且它已經擁有了一大批現存的產品、顧客、標準、技術能力以及組織機構等資源，這些將使它在今後許多年內都屹立於世界上最強大的公司之列。
關鍵的優勢微軟是為數不多的傑出公司之一，在這裏，領導才能、戰略、人才、文化和機會共同作用，創造了一個極其有效的組織。不管讀者喜不喜歡微軟的產品和公司行為，這一點都是不容置疑的。
公司本身我們在此書中列出的七條戰略及相應的七套原則反映了微軟最基本的長處，它們使微軟能夠高效率地運作。我們將其總結如下：
首先，微軟擁有出色的總裁和高級管理隊伍。比爾·蓋茨是一位了不起的領導者，而且還組織了一支有效的“智囊團”來支持他。微軟的經理們了解他們的技術和市場，懂得怎樣利用這些知識賺取金錢。他們和任何公司的最高管理隊伍一樣出色或者比他們更棒。他們還巧妙地根據需要調整機構，使微軟能夠在快速發展和擴張的市場中保持競爭的不敗。
第二，微軟擁有上千個精心挑選過的才華過人的雇員，他們以其才智、技能和商業頭腦聞名，擁有勇於進取、敢於開拓的精神，並且願意為了公司長時間地辛勞工作。他們來自於廣闊的並且越來越多樣化的背景，這就在公司內部形成了多樣性。這些人有能力承擔多方麵的責任，包括確定他們工作所需要的技能，招聘並培訓新人以及協調公司內部不同部門。
第三，微軟表現出了高度有效和一致的競爭策略和組織目標。微軟的雇員們都清楚公司領導者不是單單為了技術而重視技術，也不認為在推出產品時要固守一定的規則和程序。比爾·蓋茨和其他微軟經理們很重視利潤：他們對能帶來利潤的大眾市場感興趣，而且他們相信隻有把有價值的東西提供給顧客才能獲得最大的利潤。蓋茨和其他經理們似乎還知道應該在什麼時候進入哪些新興的或正在發展的市場，以及什麼時候應該轉移注意力。他們趕在技術被淘汰之前就更新技術。他們清楚地了解怎樣不斷培育已經形成的巨大的產品市場和顧客群。他們通過建立標準來維持銷售額和利潤，開發新的市場，而且他們利用標準建立者的地位取得優勢。他們還能看到未來真正廣闊的大眾市場是以新的家庭消費者為中心的。
第四，微軟用一種靈活的、漸進的方式來管理產品開發和完善組織機構。微軟的產品開發係統使小組和個人可以在一個項目期間內改變說明和設計規格，並且針對具體消費者活動的特點通過漸進式的發展來完成產品建設過程。另外，微軟的組織機構也同樣表現出我們在它的產品和項目中所見到的靈活性和漸進性。我們已經看到微軟公司可以比較容易地從一個市場轉移到另一個市場。當技術和市場變化時，微軟不斷隨之調動人員，更新組織，高效率地保證產品、項目和整個組織機構的發展。
第五，微軟顯然在產品開發和其他工作的過程中將高效率和平行工作的能力結合起來。雖然微軟對產品定價相對較低，但公司利潤依然很高，其中部分原因是由於微軟利用它在很多領域內的規模和範圍經濟優勢：它在開發和測試軟件產品中已經積累了大量知識，並且它現在有很多軟件組成部分和工具在不同項目中都是通用的。它生產出數量龐大的新產品，並且把它們輕而易舉地輸送到批發和零售商業渠道。公司從收入中為不斷增長的研究和開發活動提供資金。不同小組依靠同一個中心可用性實驗室，而且還有為尋求顧客支持的中心培訓和工具開發活動。微軟每天都接到成千上萬個電話，這為它提供了寶貴的來自顧客的信息反饋。其他受規模經濟影響的領域包括諸如產品包裝，分發和廣告等活動。同時，微軟的產品開發和其他工作的過程采用將很多任務平行組織起來，使責任和職能交叉重疊，並把人員分在多部門組成的小型組裏工作的方式，從而促進效率和靈活性的提高。
第六，微軟人有一種自我批評、學習並提高的習慣。產品組研究過去的項目，尋找哪些做對了而哪些做錯了，以及下次再碰到類似情況時該怎麼做。和過去不同，現在微軟還非常重視顧客的問題、抱怨和建議，把它們當成值得開采的金礦，進行細致的分析，並且迅速地把這些信息反饋傳送到產品開發組去。微軟越來越多地利用定量措施和計量方法來了解產品、項目以及顧客的反應。各個產品小組也不斷尋找新的辦法來共享技術和構件以減少重複，給顧客提供更加連貫一致的產品係列，並且使公司整體結合得更緊密、效率更高。
第七，微軟人表現了對未來市場的不懈追求。他們並沒有因為成功而變得自滿，而是像理查德·巴斯所觀察到的：“史蒂夫·鮑爾莫幹勁十足地提醒我們，我們過於悠閑了，而競爭形勢卻十分緊迫，因為後麵還有其他和我們一樣饑餓的人們在追趕著我們。”我們還認為“向未來進軍”——我們在後麵將詳細解釋——是微軟自1975年以來行為的準確寫照。比爾·蓋茨和保羅·艾倫最初是在他們尋求當時實際上並不存在的個人計算機編程語言的大眾市場時表現這種態度的。從那以後，微軟趕上了其他新興或發展的大眾市場的潮流，並且還創造了一些市場。蓋茨和他的人員繼續展望幾年後的未來狀況，他們以此來評價諸如多媒體出版，交互式電視和其他為信息高速公路和新消費者設計的產品和服務之類的新想法。
產品開發微軟像任何公司一樣，實際上類似於一個動態的人體係統。它之所以能夠有效運行，是因為微軟人將競爭所需的各種技術能力和市場知識結合了起來，並且把他們的主意付諸行動，雖然很難說其中任何一個因素比別的更重要。然而在這本書裏，我們花了相當的時間談論微軟開發新產品時所采取的戰略、原則，我們認為產品開發是微軟所有事業的中心，公司的存亡和盛衰關鍵在於新產品，從Altair BASIC到MS-DOS，Word，Excel，Windows，Office，Windows NT，Windows95，the Microsoft Network以及更多。
例如，在90年代假如微軟未能推出Word和Excel的新版本，並把它們結合進Office套裝軟件的話，它的收益肯定會下滑。這些產品現在占收益和利潤的一半左右。僅僅為了維持它在操作係統上的銷售額，微軟就必須從MS-DOS邁進到Windows，現在它已經成功地開發了Windows NT的兩個版本，並有初步跡象顯示新產品Windows95將在商業上獲得巨大成功。微軟還必須源源不斷地增添有用功能來說服其成百萬的現有顧客購買產品的新版本，雖然舊版本對於絕大多數人已經夠用。為了保持在未來持續增長，微軟計劃創建種類繁多的結合先進的多媒體及網絡通信技術的消費者產品。顯然，微軟麵臨的一個關鍵問題是公司是否能夠繼續增進其開發能力並且建立更大更複雜的軟件產品和以軟件為基礎的信息服務。就像我們已經指出過的那樣，微軟還必須極大地簡化這些中間產品，從而將它們成功地推銷給世界上數十億的新興家庭消費者。
前麵我們已經論述了微軟一向在產品開發上顯示出非凡的能力，而且公司不斷精益求精地完善和提高這些能力，因此得到回報自然在情理之中。總之，我們認為微軟的產品開發組織是公司的核心和希望，而且由於它蘊含著強大的力量，會繼續獲得巨大成功。
第一，產品開發組織有效地支持了微軟的競爭戰略，即為大眾市場設計產品然後通過提高原有功能或增加新功能的方式來逐步改善此產品。微軟還努力建設行業標準，然後利用這些行業標準在新產品上占據優勢，各產品單位通過生產出一連串兼容的新產品和新版本來支持這個目標，使成百萬消費者每次都支付額外的錢來更新換代。
第二，產品開發組織運作良好是因為它的過程和目的與微軟的文化和目標高度一致。程序經理和開發者有很大的自由，通過對產品設計和用戶反應進行重複試驗來發展產品特性。強調由各個專家單獨做出決定，但在小組中共擔責任、共同工作，從而將官僚式控製減少到最低程度。軟件行業中的老大哥們也許不屑地稱之為“黑客”電腦文化，因為它缺乏對人們和項目到底幹什麼的更加嚴格的控製。但是由於有了我們描述過的同步和穩定技術——即每日構造，裏程碑集成階段，初步測試和內部發布等，就使得個人和小組不僅能夠在一起工作，而且能相對獨立地展開工作。
第三，就像公司的整個組織結構一樣，微軟的文化也同樣促成了這種將效率（即分工結構）與靈活性完美結合的產品開發過程。各部門可以毫不費力地擴大它們的產品組合。每個人也可以自由地對他們所開發的產品做多次修改，並且變更或修改產品開發的過程和工具。然而，從整個公司來看，軟件開發和其他關鍵活動有一個相當明確並有規可循的過程。
靈活性在軟件開發活動中尤其重要，因為在許多項目的初期很難推測產品最終會變成什麼樣以及用戶對產品功能會有何反映。在做成套軟件（與專用軟件相對）時，公司還麵臨另一個問題：即類似於如何在寫出暢銷書後再接著寫出能取悅於那群癡心讀者的續集來。一個單一的高度結構化的開發過程不會一直有效，因為實際上並不存在寫作暢銷書的特定套路：不管這個過程怎麼好，與最終成功關係更大的卻是優秀的創意、實際寫作者、市場時機選擇以及廣告和顧客支持。然而，公司能夠做到的是建立合適的產品開發過程，使它既能提供正好滿足團體對設計試驗所要求的結構體係，還能給他們創造的產品帶來時常迸射的意想不到的火花。這就要求微妙而有效的協調與交流。
第四，微軟的產品開發方式容納了好幾種把吸收信息反饋和學習（特別是從消費者那裏學習）直接引入開發過程的機製。我們可以從對以下二者的分析中看到這些機製：即讓用戶積極參與產品規劃以及利用顧客支持數據來進行特性的選擇和創意。除此之外，它們的身影比比皆是：例如程序經理和開發者廣泛依賴於在可用性實驗室裏將特性原型化，測試者如何努力複製一個產品的功能用途，在重要新產品如Windows NT和Windows95發布前要在顧客基地做大型β測試，以及開發者和測試者如何在他們推出新產品後都要接聽顧客電話作為顧客支持活動之一。
第五，微軟的同步和穩定過程方式使公司能夠將創業早期鬆散結構的小團體方式升級，從而相對迅速且低成本地建立起複雜的軟件係統。微軟的技術也有一些局限，這些我們後麵會談到。雖然現在微軟的許多產品和項目都相當龐大，他們卻仍然繼續像靈敏的小團體一樣工作。我們相信，經過一些改進，微軟能夠繼續提高它的經營運作水平，建立起未來時代的複雜軟件係統。
同步和穩定過程取得的成就在同步和穩定思想背後的各項原則達到了一個艱巨的目標：它們給迅速變化以至於經常處於混亂中的個人計算機軟件開發世界增添了一些看起來很像樣的秩序。這裏沒有什麼神秘的魔術，這裏有的是各種具體的工具和技術，一些嚴格的規則以及掌握了高度熟練技術並且願意遵守這些規則的人才。微軟的整個開發過程幫助各個開發者經常與同一隊伍中其他成員的工作保持同步，並且在構件的發展中通過漸進辦法使產品穩定。就像我們在本書中始終指出的那樣，有很多因素使同步和穩定方式顯著優越於早期更嚴格的順序式產品開發方式。
主要在開發完成後接收顧客信息反饋作為對以後項目的指導借鑒以由不同功能部門的人員共同在一個大型組裏工作為主要方式第一，微軟並不遵循一種順序式的“瀑布”過程，這個變化趨勢在軟件業和其他行業中也開始變得越來越普遍。微軟並不把產品開發和測試當作有先有後的兩個單獨階段，因為如果這樣做的話，一旦事情沒有確切地按照規劃進行，就需要翻來倒去地反複循環修正。相反，微軟的團體是把產品開發和測試同步進行。這個過程就使每個人都充分發揮自己的想象力隨時對設計、編碼和測試進行攻關。它還有些類似於在其他一些覆蓋許多活動及階段的產業中出現的漸進開發和並行工程行為。
第二，微軟在開始構造一個產品的各構件之前並不試圖“凍結”一個完整的說明和詳細的設計。微軟讓說明隨項目進展而不斷變化發展——增添或刪除特性構件，對設計細節進行試驗。因此完整的說明與其說是開發過程的投入，不如說是開發過程的產出。微軟對產品隻有想象性描述而沒有實質的詳細設計或文檔階段，編碼就是他們的詳細設計和文件，這又是一種不正規的“黑客”方式，但是我們認為微軟擁有特別有效的機製使不確定性變化大體處於控製之中。
第三，微軟並不企圖同時構造一個產品的所有部分，即把一個詳細的設計分成小塊，然後把所有分出的模塊或特性構件配發給不同的人和小組。相反，微軟是把一個設計分解為特性構件，把所有特性構件按重要性排序並分組，然後通過3個或4個裏程碑構造各個特性構件群。小組們在第一個裏程碑裏通常致力於最重要的特性構件群，在第二個裏程碑裏專門幹次重要的特性構件群，以此類推。對於特性構件群之間的配合關係不那麼強的產品，項目小組通常會在進度實在來不及的時候舍棄最後一個裏程碑裏的特性構件群。
第四，微軟並不試圖在項目末尾通過一次晚期的大型集成和係統測試階段來把產品的各個部分聯成一個整體。那種落後的方式會在下列情況下發生：即如果一個項目平行地構造產品的所有部分，並且在開發過程中不能使各部分同步或把它們放在一起測試。反之，微軟采用頻繁地進行構造的方式，每天或每星期都使許多個人和小組的工作同步進行；而且應用裏程碑子項目的概念，通過3或4個漸進活動來穩定特性構件的子群。這些做法類似於其他一些公司采用的“並行工程”和“漸進構造”。然而，我們認為微軟優化了這種產品開發方式並使其製度化，因此顯得格外出眾。
第五，微軟並不要求對項目開始時所提出的每個特性構件都完成並完善。相反，尤其是在應用軟件產品中，微軟設置了時間及人員的限製，然後製定出除去最嚴重錯誤的目標。各小組將會把他們在前次項目中不能完成的特性構件等到下一次產品發布時再添加進去，或者消除上次他們沒有發現或無法消除的不太嚴重的錯誤。這樣，微軟就避免了一種常見的困境，即陷於永無止境的修改，添加特性及消除錯誤的死循環中。別的軟件公司也采用多次發布周期，包括處在每年或經常進行“式樣改進”行業中的公司。但是微軟卻在這種開發和營銷方式上更上了一層樓。它甚至想出了年度軟件式樣改進的絕妙主意——從而也有了Windows95和Office95這些名稱。（當然，假如微軟沒能精確地測定出進度表的話，這種每年出新款式的策略也會起副作用。把年份加入名稱之中也產生了在某一年內完成的額外壓力。）第六，微軟並不等到它已經將產品完成並推向市場後再來收集和利用顧客信息反饋。而是在開發的整個過程中，不斷地把顧客信息反饋結合進來。首先是在產品規劃階段對用戶進行分析，然後繼續在可用性實驗室裏對原型進行測試，再在即將發布前把版本送到β測試基地。不僅如此，微軟還做出關於顧客向公司產品支持組織提出詢問的每周詳細報告，並把它隨時送到產品開發組。這些信息對當時正在開發的特性構件和未來的產品設計都會產生影響。
第七，微軟不讓開發者旁若無人地編寫軟件程序。它也不是通過下麵這種龐大團組的方式來構造軟件：小組由設計者、開發者和測試者們組成，他們在相互獨立的部門中順序式地工作，在許多嚴格的步驟和文檔要求之下將工作逐次移交給下一階段。而恰恰相反，微軟是在多功能小組裏開發軟件，將力量合理組織以使大團組像小團組一樣工作。微軟公司有人曾對我們說：“我們花費更多時間去弄明白怎樣從小處著眼去想、去做，而不是好高騖遠，一味求大。”
使大團組像小團組一樣工作微軟的同步和穩定方式還為怎樣組織大型團組——這個在許多公司和行業中都常見的問題——提供了可貴的榜樣。這個常見問題部分的困難原因在於技術上和管理上的培訓不足。大學裏的自然科學和工程學係以及管理學院一般都不訓練學生如何在大型團組裏工作或怎樣控製大型團組。大學裏的工程項目幾乎總是小型的，人們在此學習如何獨立地或在小型組中工作。而許多公司的現實情況是，為了在相對較短的時間內構造複雜的產品，有必要成立大型團組。事實上確實如此；雖然說由技能高超人員組成的小型團組也許是設計任何類型產品的最好方式，不管是計算機軟件程序，汽車或是飛機。我們覺得微軟和其他“年輕”的公司（特別是那些位於像個人計算機軟件這種相對來說是新興產業中的公司），對我們生活的世界提供了許多關於如何管理團體和創新方麵的課程。下列的段落將回到從前討論過的戰略和原則上來，從中剖析出微軟用來提高其小團組開發方式的關鍵因素。
項目規模和範圍限製我們已經討論過微軟如何通過限製產品規模和範圍來使項目小型化。這產生於以下將討論的幾種方法中。
明確而有限的產品想象藍圖微軟力求對每個項目都設定明確的使大團組像小團組一樣工作·項目規模和範圍限製（明確而有限的產品想象藍圖，人員和時間限製）·可分解的產品結構（根據特性構件、子係統和對象來劃分模塊）·可分解的項目結構（特性構件小組和特性構件群、裏程碑子項目）·小團體的構成和管理（許多小型多功能組，享有高度的自主權和責任）·一些“強製”協調和同步的規則（每日構造，“不要破壞構造”的“故障”規則，裏程碑穩定化）·在各功能和小組內部以及跨功能、跨小組的良好交流（共擔責任，同一基地，共同語言，非官僚文化）·產品及過程的靈活性以容納未知因素（不斷發展變化的規範，緩衝時間，發展變化的過程）界限。程序經理與開發者和產品經理合作，並根據顧客支持數據，做出一個簡要的想象性描述，從而為項目確立一個可實現的目標。彼得斯在他1990年的電視講話中說：“你必須有一個明確的目標這樣才能幫助一大群人，一群由100人組成的隊伍，朝一個共同方向前進，並且幫助他們決定做什麼而不做什麼。決定你所為之工作的產品不該成為什麼樣與決定它該成為什麼樣同等重要。”（1）微軟發現與全新的產品相比，在產品的第二、第三或更晚版本中這種目標的明確性更加容易實現。
通常也可以根據“能否賺大錢”來對項目進行特性構件的取舍。如果一個特性“看起來會反響冷淡”，可能隻有幾個消費者，但卻需要6個人花費開發的全部日程來完成，他們就會把它刪去。
人員限製我們已經注意到產品單位的構成限製了在任何一個項目中共同工作的人員數目。微軟實際上是由小的開發中心組成的集合，每個開發中心通常不超過300或400人。每個開發中心代表了一支多功能的產品開發團體，由說明編製、開發、測試、用戶培訓及產品規劃方麵的專家組成。它們的規模比起微軟早期是相對較大的，因為早期微軟隻有幾十個雇員，項目隻有4到5個人。但是若與對手軟件公司經常采用的上簽名或更多開發者相比，就是小型的了。微軟還把其所有的人力集中在推出產品上，而不把建立作為“存貨”的構件和技術或者將過程和產品存檔作為重點。這種對推出產品的專注有著正負兩方麵的作用：例如，過程及產品檔案的缺乏會迫使團體重新尋求對公共問題的解決辦法。但它同時也給了人們更多的時間來致力於將手頭的產品更好地投入市場。
時間限製現在項目對人們能夠花費多少時間在某一特定的活動上設置了更加嚴格的界限。通常對於已有產品的新版本來說是在12到24個月之間。但全新產品的推出時間要長得多（例如Windows NT3.0或Microsoft Exchange）。我們已經談過為什麼操作係統比應用軟件更難以在一個可預測的時間框架內構造完成。（因為操作係統需要廣泛的測試來覆蓋所有可能出現的用戶使用情景，而且在項目超期時很少有可以刪除特性或功能的機會。）但是，設置時間限製——至少是在內部，能幫助人們把他們的創造性集中於完成產品的一個可運行的版本，即使它並不“完美”或者還不適於正式投放到市場上去。項目在以後還會有時間做進一步的完善和優化。
因為項目將特性構件按重要性排序，並且在項目進行中始終集中於開發一個過得去的產品，這樣應用軟件項目在時間不夠時就可以隨時停下來，並且仍然推出一個可以麵向市場的產品。過去微軟的一些項目經常拖延上幾年之久，而現在則顯著不同了，許多應用軟件產品的第二或更晚的版本在原先估計的出品日之後一兩個月就推向市場了。然而對於全新產品或操作係統的主要改進來說，微軟的成績就差得多了。如果與其他項目中的構件（例如在Office最近幾個版本的一些構件）有相互依賴關係，困難也同樣會增加。
可分解的產品結構產品結構在將大團組分解為小團組方麵扮演了決定性角色，這也許比它在對項目所占用資源的總體進行限製中所起的作用更為重要。模塊化在軟件業和其他許多工程領域是常見而必要的，絕大部分公司也都通過特性構件，功能，或子係統來設計產品。微軟在過去並沒有充分重視建立一個高等級的與其產品中的源代碼相分離的結構。然而，情況在發生變化，微軟的開發小組（包括開發OLE，Office和Cairo及其他）越來越以可分解產品結構和共享構件的概念進行思考。微軟的各小組還通過每日及每周構造過程以及裏程碑穩定化來有效地協調並同步各個構件的開發。
根據特性和功能劃分模塊我們已經說過微軟怎樣把應用軟件產品分解為特性構件；操作係統不僅包括特性構件，還包括叫做功能構件或子係統的部分。由於這些構件中許多會發生相互作用，項目必須在某一時候把它們放在一起測試；小組可能獨立地設計許多特性構件或功能構件，這樣就可以把一個相對較大的項目拆散為一些小項目。
根據子係統和對象劃分模塊微軟逐步把特性及功能編排成動態鏈接庫（DLL）子係統或對象鏈接及嵌入（OLE）構件，使多個產品可以共用。這些子係統和對象需要在初始規劃和設計階段進行廣泛地協調來規定它們的技術細節和界麵。采用共享的子係統和對象來設計產品，並且設計出可以共享的編碼，需要在開發過程中進行許多次調整。一般來說，這些構件又進一步使項目可以細分為相對獨立工作的小組，至少在開發階段是如此。
可分解的項目結構我們已經論述過微軟如何依照產品結構來劃分項目結構。這種做法不僅幫助各小組創造出設計方麵符合邏輯且高效率的產品，而且造就了人員分組符合邏輯且高效率的項目組織結構。
特性和構件小組項目包含幾個特性小組或構件小組。每個小組集中構造組成產品設計的一個或幾個特性或功能。因此人員分組的結構體現了產品的結構，而且保持小組的總數和各小組規模都較小，以形成一個更加緊密組合的產品。
特性（和構件）群微軟將特性按照它們的重要程度和技術上相互依賴程度進行優先排序，然後分為各組群。項目在一個時期隻致力於一個組群，由各小組平行地建立最優先組群中的各個特性和功能構件。
裏程碑子項目特性和構件小組在行進到下一個裏程碑之前對每個構件群都走過了開發（設計和編碼），測試和穩定化這樣一個全部的周期過程。結果是經理們不必再去控製那種龐大項目：例如在18或24個月內要平行地構造一大堆特性構件。他們隻需從每日項目管理的角度出發，目標是在三個月的時間內建立一些特性構件。
裏程碑可能看上去比那種同時開發所有構件然後隻在項目末尾進行一次性集成並測試完成的方式要花費更多的日曆時間。然而，即使在常規的公司中，軟件構件也經常容易在項目進行中產生很大的變化而難以事先進行精確的規範。與原始規範的不同則使產品在後來難以再進行集成和測試，除非嚴格地控製各人和小組的構造。裏程碑方式使任何規模的團組都能像小團組一樣行動，能夠改變設計或省略掉構件的細節。他們享有這樣的自由是因為他們可以在一個項目中多次將產品的主要部分穩定化——而不是等到太多的變化已潛入產品中而使集成和穩定變得幾乎不可能了。
小團組的構造和管理根據將產品劃分為特性（甚至將特性再劃分為子特性）的原則，項目可以將產品任務分為各個部分，每個部分由一些人完全負責，而且通常能在幾星期或幾個月內完成。
小型多職能組我們已經說過每個小組的核心組是如何由一個程序經理和3到8個開發者，再包括一個特性小組領隊組成的。在核心組基礎上擴展形成的小組還包括一個平行的與開發者數量相當的特性測試者隊伍。
自主權和責任克裏斯·彼得斯曾說過“當你使組織退化，或是說將組織中每個人責任壓得很低的時候，大團組是會奏效的。他們會工作得很好而且非常具有競爭力。（2）另一種辦法是給經理們（例如小組長）更多的責任和權威來使他們嚴密指揮小組成員的工作。而與前兩者恰恰相反，微軟給予每個小組，以及每個人，相當大的自主權和責任。這就遵循了要雇傭能獨立工作和學習的傑出人才的一條原則。自主權和責任使每個小組能夠相對獨立地工作，例如，個人和特性小組負排安排和維持他們自己的進度表。此外，他們做修改變化時很少受到規則的限製——個人和特性小組“擁有”他們的特性群，項目還可適當根據要求裁剪過程和工具。
一些強製實行協調與同步的嚴格規則性雖然微軟的小組享有可觀的自主權，項目在一些關鍵時候還要依賴嚴格的紀律來保證各小組能夠協調他們的工作。
每日構造幾乎所有的項目都做其產品的每日構造。開發者可以隨心所欲地愛什麼時候工作就什麼時候工作，以及願意參與加入多少次產品構造就參與多少次。然而，當開發者登錄他們對產品的工作時，他們必須在某一個特定時間前登錄，通常在下午（2：00或5：00）。在此之後項目就產生了一個新的構造。受前任智囊團主管戴夫·馬裏茨之類人的激勵，產品組像以色列軍隊一樣嚴格地遵守構造紀律。每日構造的過程迫使各個單獨的開發者及小組盡可能經常地使他們的工作同步。開發者把寫入他們的代碼拖延得越久，他們就越有可能與其他特性發生衝突而使構造失敗。
不要破壞構造小組發現代碼中的問題後就得通過不斷的測試來創造一個新的構造，這個過程中既有自動的也有手動的，並且給每個開發者都配備了“夥伴”測試者。一旦他們決定登錄其工作，必須遵守的一個關鍵規則就是他們不能破壞在各特性構件及功能子係統之間的結構界麵或相互依賴關係，或犯任何其他使構造失敗的錯誤。導致破壞構造的開發者必須立即消除障礙，這些“有罪”之人可能還必須負責總領第二天的構造或者支付巨額罰款。戴夫·湯普森說明了這條規則的嚴厲程度：“我們對此要求十分嚴格：你最好不要破壞它，你必須十分小心地進行編碼。”
裏程碑穩定化在某些結構約束和經驗型項目限製下，個人和小組可以自由地對新產品的構件設計進行變更或者修改其特性群。各組在結尾時幾乎總是改變了他們的最後出品日。然而，在項目進展期間，經理們認為人們超過了中期裏程碑的截止日期是不能被接受的。
在各技術專長和小組內部以及相互之間的交流有好幾個因素促進了在項目中的各技術專長和小組內部以及它們相互之間的進行良好的交流。
共擔責任和任務我們已經討論過雖說有一些職能專門化和人員分工，微軟是如何通過模糊這些區分來使人們共擔責任和任務的。程序經理和產品經理共同起草產品的想象性描述；程序經理和開發者一起確定產品的特性構件；開發者和測試者共同測試代碼；程序經理，開發者和測試者在新產品發布之後都要接聽顧客支持電話，為顧客解答問題。
同一基地開發主要的開發工作都在微軟總部進行，一些收購活動除外。這就便於小組成員在麵對麵的會議中交流從而迅速解決問題（比爾·蓋茨堅持這種會議交流，雖然他對電子郵件情有獨鍾）。
一個共同的語言項目都依賴一個共同的開發語言（主要是C語言）。應用軟件項目還采用微軟內部的“匈牙利”命名法慣例。許多開發者認為匈牙利命名法使他們更容易理解對方的代碼，即使在沒有單獨設計文件的情況下。這一做法促進了代碼共享和問題的解決。
開放的文化微軟的文化離鬆散聯合起來的業餘高手程序員的世界不是太遠。這裏的人們憎恨政治上的“爭權奪利”以及官僚主義的規章和手續，不必要的公文檔案，或過分正式的交流方法。結果是，個人和小組具有在他們認為重要的事情上的快速作戰能力。
借助產品及過程的靈活性適應變化對於一個公司來說，往往很有必要使產品和過程充分靈活以適應未預見的變化或容納個人或小組可能采取的創造性行為。在經理們給予個人和小組獨立行動的擔負重大責任的工作環境中，以及身處科技和市場需求都迅速變化的產業中，尤其需要如此。
發展變化的規範我們已經描述了產品經理和程序經理如何在項目開頭做出一個想象性描述和特性優先排序表。一些組（例如Excel）寫出所有或絕大部分特性構件的長篇詳細的功能描述。然而，各小組並不覺得被這些描述鎖住了手腳，特性構件的規範和細節都可以隨著項目的進程而發展變化。最終的特性可能會有變化或增加了20%-30%，這得依據開發過程中工作的進展狀況，競爭對手在幹什麼，以及項目成員得到了何種信息反饋而定。
緩衝時間微軟的項目進度表中留出了一部分作為緩衝時間：在應用軟件中大約是20%，在係統項目和全新項目中達到了50%。緩衝對於適應未預見的變化十分有用；這些變化可能來自於沒想到的特性構件變化，難以排解的錯誤，或其他沒想到的問題（它們似乎總會發生）。經理們把這些緩衝時間安排在介於每個裏程碑之間及最後發布之前。麥克·梅普爾斯解釋說項目需要弄明白是哪些因素總愛發生變化而擾亂進度。許多耽擱是來自於像他所稱的“你所不知道的事情發生了。結果很大程度上小組對各個不同的項目都同樣地盲目自信和缺乏了解。一旦你能弄明白是什麼因素總在搗亂，則幾乎隻需例行加上一個常數。因為他們總是把需花費的時間低估了x%。”