曾經，流水線式的工作流程在生產行業大行其道，許多公司也非常推崇，在專案開發中也嘗試推行，尤其是“任何人都不是不可或缺的一部分，只是流水線上的一環”這樣的思想非常流行，總是覺得人是隨時可以取代的，不在意團隊的穩定性。

    這麼多年下來，發現在專案開發過程中，流水線式的工作流是完全不適合的。流水線的工作流，適合的是“由多個相對獨立的重複性工作組合”的流程，不管這個流程多麼複雜、每個工作的技術含量多麼高，只要是滿足重複性、相對獨立的條件，就能非常適應。而專案開發，則不具備這樣的條件。

    先說假設專案開發適應流水線，就必須各個之功能分解的非常詳細，定義的非常明確，這樣才能滿足隨時可以調配人員來開發的程度。在達到這樣的目標之前，必然有大量的人力、物力來負責專案的分解、跟蹤等等，以便滿足人員流動帶來的專案持續問題。這其中的複雜程度，與一般專案要求的“短平快”是非常矛盾的。或許，在某些大公司重要產品的開發上，可以滿足，但對於許多專案來說，這顯然是不可能的。

    專案開發的過程中，實際上能重複利用的是“以往的經驗總結”。這些，又是非常不明確的，沒法定性量化的。所以，一個好的團隊必然十分重要。一個好的團隊，隊員之間的價值觀、性格、能力，相互之間是認可的，也是有互補的，往往會產生1+1>2的效果。畢竟，在專案開發中，開發人員的效率，對周圍的環境、氛圍等，要求還是比較高的。好的氛圍，必然產生高的效率，反正，必然會受影響。而且，團隊內部之間的能力互補、習慣、默契等等，這些都是無形的，但又是影響非常大的因素。

    開發人員進行的工作，看起來像是重複性勞動，實際上，每次都需要進行處理，不能視之為簡單重複勞動。一個合作不是很默契的團隊，可能每個人的技術水平、能力很高，但合作起來彆彆扭扭的，對整個專案的進展都不會有好處。這就是，為什麼臨時搭的“草臺班子”幹專案，總是出這樣那樣的問題的原因。不是團隊內的人員不想出問題，在各種想不到的原因下，導致合作出現了問題。出現了問題後，這樣的團隊往往不能及時解決、糾正，反而導致積少成多，最終問題不可收拾。

    專案中的技術人員，不能和流水線上的工人一樣看待，雖然看起來兩者的工作有些相似，但開發人員，在每個任務環節中都投入了不同程度的“腦力”，而不是簡單的體力投入。這就間接的導致了，取代這個人，不只是要取代他從事“體力”敲出的程式碼，還有繼承他在敲擊程式碼時投入的“腦力思想”。這就是為什麼危害別人的程式碼，會非常的累，尤其是不熟悉的專案，這是因為你不光是需要了解這些程式碼“幹了什麼”，還需要明白程式碼背後的思想“為什麼要這麼幹”。

    所以，一個穩定的團隊，在專案開發過程中，會無形中解決很多很多的問題，提高非常大的工作效率，這從明面上的人員配置、能力高低、工資水平等等的，是看不出來的。不要迷信“我們團隊有超級大牛”這樣的話。專案的成敗，往往不是技術大牛能解決的。成功的專案有各種因素，但是失敗的專案，必然會有一個不成功的團隊。

    縱觀全世界各行各業，只有是“知識性”的腦力投入勞動，乾的好的都是某個或者某些團隊，哪怕這個團隊是以誰為主的。不會是因為某人的技術牛，拉一幫人，就是一個合格的團隊了。

    必須承認的是，在腦力勞動中，投入的是“思想”，所以團隊協作時，有一致的價值觀、統一的認識、相似的解決方式，都能夠很好的協調整個團隊。一個穩定的團隊，標誌也基本上就是。就像籃球界，一說活塞，那就是防守型團隊，這就是標誌。有了這個，一個只攻不防、獨佔球權的人，哪怕是巨星，也不適合這個團隊。哪怕是強行拉進了隊伍，團隊的成績也不見的能提供，除非圍繞巨星重建。

    不要盲目的崇拜那些技術牛人，一個團隊是很重要的，千萬不要忽略團隊的作用。

    當聽到那種“我有NN多人，隨時能組建一個團隊”或者“招××人，組建##個團隊”這樣的話，好像菜市場買菜一樣容易就把團隊建立起來了，我就“呵呵”。