曾經有一位大佬分享他組建技術團隊的心得，當時我問了他一個問題：請問你組建的團隊是專案型組織，還是職能型組織。但是大佬似乎對於這個問題沒有特別直接的回答，所以在這篇部落格中，我想跟大家討論一下這個問題。
一）職能型組織和專案型組織
職能型組織和專案型組織確實容易混為一談，雖然二者都是為實現某種目標而由相互協作的個體組成的群體，但專案型組織則側重於短期任務的實現，而職能型組織卻長期存續。
在職能型組織中，團隊以固定的組織架構形式，共同承擔一個或多個專案。團隊成員是一個相對穩定的組織單元，可以充分發揮職能組織的資源集中優勢，也容易依託組織中的專家資源，實現資源共享和知識體系的傳承，不僅能確保專案的快速推進，也能有利於公司的長期發展。當然，職能型組織也容易形成內部小團隊，當需要跨組織共同完成任務時，由於權力和利益分割的問題，容易陷入各自為政的局面。
而專案型組織則是一切工作都是圍繞專案進行、通過專案來創造價值。專案組織是一個專門型組織，他的存在的唯一價值就是完成專案。它的優點是目標明確，任務單一，能夠基於現有資源實現對需求的最大化響應。它的缺點是成本低效（由於專案存在的唯一價值就是不擇手段完成專案，有時可能會造成專案成本和資源的浪費），專案間缺乏知識資訊交流，因為知識的積累需要花不少時間，這可能會對專案的進度造成不利影響。
在專案型組織中，根據專案經理對專案資源的控制能力，又有強矩陣，弱矩陣，均衡矩陣的說法。但雖然強矩陣是對專案經理來說最為舒服的一種管理形式，同樣也算最有可能造成資源浪費的形式。
這兩種架構各有優缺點，例如職能型組織內部實現對資源的複用和知識的共享，如果能夠加上專案型組織優秀的執行能力，顯然是一劑良方。
二）軟體開發模型對團隊造成對影響
眾所周知，軟體開發模型有三種，瀑布型，迭代性，增量型。雖然這只是三種軟體開發模型，看似不會影響研發技術團隊的溝通形式，但實際上已經無形中已經深入人心，如康威定律一般，默默的改變了一個小團隊自身執行的系統架構。
例如，在瀑布型專案團隊中，團隊之間傾向於通過文件交流，遇到問題首先想到的是優化文件或流程，似乎是一種組織間低效溝通的標誌。而敏捷型專案則有助於打破專案組內部對於文件的依賴，單從這一點上看，就能給團隊帶來不錯的生態體系。
當然，無論哪種模式都並非一定正確，例如精密宇航技術都研發，如果用敏捷，估計得玩完，但網際網路專案的開發實踐，用瀑布模型，似乎用響應太慢了。
雖然將團隊管理和專案管理混為一談是技術管理者很容易陷入的誤區，但也得承認，在某些常規軟體開發過程中，靈活的運用從敏捷專案管理過程中帶來的一些方法，確實也能夠有效的推進團隊之間關係的進一步融洽，從而構建更加自驅的專案團隊。
三） 敏捷專案管理提供對框架
個體和互動 高於 流程和工具
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計劃
也就是說，儘管右項有其價值，
我們更重視左項的價值。
而敏捷宣言所提倡的這幾點，都是有利於推動團隊構建的實踐手段。
1、站會
在敏捷專案管理過程中，站會是一種最基礎的實踐，團隊成員每天早上圍著白板站成一個圈，然後再依次回答三個問題：
1、我完成了什麼。
2、遇到了什麼問題。
3、今天計劃完成什麼。
站會的主要特點是改變了傳統專案管理中由專案經理控制整體專案的模式，改成由團隊成員共同參與，在這種情境下，每個人都獨立的承擔其一部分職責，雖然有Scrum Master或產品負責人組織，但實際上團隊成員並未向任何人彙報。
2、敏捷卡牌
傳統專案管理模式中，工作量的估算一般都是由主要開發者拍腦袋、或專案經理拍腦袋，而採用了敏捷卡牌，則使工作量的估算多了許多群體決策。
在敏捷卡牌實戰中，大家採取這樣的實踐手段：
1、首先使用某個比較易於評判的功能，作為評估標準.
2、用該標準去評估其他功能的工作量。
3、通過團隊群體決策，判斷其他任務的工作量，如果多個人評估的結果相差較大，則說明需求未澄清，則澄清需求點，繼續評估。
這種實踐有助於打破團隊間資訊障礙，使得功能點的執行更加易於開展。
3、反思回顧會
在專案過程中最難的大概就是經驗知識的傳承。而在敏捷專案迭代完成後舉行的反思回顧會，也恰好是這樣一種有利的手段。在反思回顧會上，大家討論我們上一迭代有哪些事情做得好，希望繼續保持，哪些事情做得不好，希望改善，有何改進計劃。
對程式設計師來說，普遍不善於交流，而反思會則給了大家“吐槽”的機會。當然，在實際召開過程中，專案組織者可以儘量減少發言，儘量讓團隊成員多發言的方式，讓團隊成員能夠自發的提出問題和對應的改進建議，而不是成為個體的一言堂。
四、結語
對於團隊而言，最重要的莫過於打破溝通障礙，讓團隊的成員都能獲得儘可能多的表現機會，而依託敏捷專案管理提供的許多框架，則可以成為這樣的利器，為構建團隊帶來便利。