的理念強調(diào)企業(yè)以業(yè)務(wù)流程為中心進行運作、打破傳統(tǒng)的部門隔閡、增加客戶價值和企業(yè)效益（降低成本）。以業(yè)務(wù)流程為中心取代職能分工，成為管理的首要原則，圍繞流程建立起來的組織具有更高的敏捷性、效率和效益，呈現(xiàn)出扁平化、網(wǎng)絡(luò)化的特征。
然而重新思考圖6-16所示的全功能團隊，你會發(fā)現(xiàn)，在很多情況下，在最低層級組建上圖所示的全功能團隊并不現(xiàn)實（什么是最低層級？意思是該單位不會再有下級單位），出于溝通效率的考慮，一個單位的成員不能夠無限擴大，在傳統(tǒng)的管理書籍中（法約爾），這個約束甚至被建議為5人。在很多制造型企業(yè)里，這個人數(shù)實際上是大大超出這個限制的，原因就在于標(biāo)準化。然而，在知識密集型企業(yè)里，因為并沒有一致的標(biāo)準能夠遵循，單位成員之間必須面對面溝通以協(xié)調(diào)彼此的工作，那么單位規(guī)模必須足夠小，小到便于所有成員能夠做到適宜、頻繁和非正式的溝通。所以，對于一個軟件項目而言，一個小于10人的全功能團隊是最適合的，一旦團隊規(guī)模超過20人，那么就必須進行再分組。對很多軟件開發(fā)而言，他們需要的人數(shù)遠超20人，那么這種最低層級上的全功能團隊就不再適用。
如果工作流程上的各個單位構(gòu)成順序依賴的關(guān)系，則是次優(yōu)解。在這種情況下，每個單位僅僅對其上一個單位產(chǎn)生依賴，單位之間的協(xié)調(diào)較少。如圖6-17所示，可以看出這是一個典型的以職能進行分組的組織，這樣的分組至少看上去并不壞，但是現(xiàn)實卻是：這是一個相當(dāng)沒效率的分組。原因就在于該分組基于一個重要的假設(shè)：開發(fā)流程中的任務(wù)是可以分階段完成的即瀑布開發(fā)模型?，F(xiàn)實中，這個假設(shè)卻是完全不成立的，這些任務(wù)聯(lián)系的如此之緊密，以致于在這些單位之間不得不時時發(fā)生大量的協(xié)調(diào)。于是該分組實際是下圖6-18的樣子，最差解！
如果工作流程上的各個任務(wù)需要跨越多個單位進行反復(fù)協(xié)調(diào)溝通，那么則是最差解，稱之為交互式相依。在我觀察過的一個組織里邊，測試人員發(fā)現(xiàn)軟件缺陷后的第一反應(yīng)不是走過僅僅一屏風(fēng)之隔的開發(fā)小組里進行溝通，而是先填寫在線的缺陷跟蹤系統(tǒng)，然后再打開即時消息工具，給開發(fā)人員發(fā)消息：有缺陷，缺陷號是xxx。組織在進行分組時，必須尋求將協(xié)調(diào)和溝通的成本降至最低。
工作方法相依性。
即使用相同工作方法的人員分到一個單位，通常也就是職能分組。這種分組的好處在于能夠激發(fā)方法的互相交流，也就是專業(yè)性，同類專家分到一起之后，他們能夠互相交流，提高各自的專業(yè)水平。在現(xiàn)在公司里，經(jīng)常能夠看到不同團隊成員之間的非正式交流，這里，其實是公司整體的文化氛圍為這種交流提供了便利。實際分組時，需要在工作流相依性和工作方法相依性間做出權(quán)衡。
規(guī)模相依性。
第三個標(biāo)準與經(jīng)濟規(guī)模有關(guān)?？紤]這樣一個例子，軟件的測試需要真實的硬件環(huán)境進行模擬，而這些硬件比較昂貴，那么一個最經(jīng)濟的方式就是成立專門的測試部，統(tǒng)一購買一批硬件，統(tǒng)一對所有的軟件進行上線前測試。同理，由于DBA比較昂貴，公司不可能為每個團隊都配備一名，所以DBA不屬于任何團隊，其是共享的。
社會相依性。
第四個標(biāo)準與具體的工作沒有關(guān)系，與人的社會性有關(guān)系。如果領(lǐng)導(dǎo)沒有頭暈，他是絕對不可能將兩個水火不容的人放置到一個單位內(nèi)的（帝王除外，那叫帝王術(shù)）。
以上就是組織進行分組的四種標(biāo)準。歸納一下：如果工作流相依性意義重大而又難以納入標(biāo)準的話，那么組織就應(yīng)該嘗試以市場（項目）為基礎(chǔ)進行分組，這樣便于相互調(diào)節(jié)和直接監(jiān)督；如果工作流不規(guī)則，標(biāo)準化能夠涵蓋工作流相依性，如果方法和規(guī)模相依性意義重大，那么組織應(yīng)該積極尋求專業(yè)化，以職能進行分組。
最后，我們討論一下大規(guī)模軟件團隊的分組，在上面我們提到，一旦人員規(guī)模超