最近在帶一個小型的開發團隊，第一次帶團隊，有一定的壓力，但這壓力還完全在我能承受的範圍內，我是一個喜歡沉思的人，特別是上下班的路上，晚上躺下之後，我都喜歡想一些白天遺留的問題，晚上的寂靜讓我可以盡情地天馬行空的暢想。最近這些日子我想的事情很多，有很多技術上的，更多的是我在思考如何讓我帶的團隊高效地運作。
我不是帶團隊的老手，但我有激情去思考帶團隊這個問題，帶團隊沒有我想象的那麼簡單，這裏面有很多的學問，其實就是管理科學。對我來說，管理不僅包括團隊人員的管理，也包括技術上的管理，如何讓團隊的幾個人在短暫的項目週期內順暢地把項目做完，這值得我最近在帶完第一個項目後認真思考，總結。
正如《人月神話》上說的，團隊人數的增加不一定會使項目週期更短，反而可能會是項目週期更長，這裏面有一個溝通成本，而這一成本的預算對於一些經驗不足的技術經理來說出入非常大。還有，測試這一塊也是我們常常低估的一個環節。
任何一個項目，都需要一個（或少數幾個）核心人物作爲“專制者”來統領總體設計思想，設計一定要和實現相分離，垂直分配任務，而不是水平劃分，水平劃分看似平等，但這增加了太多的溝通成本。垂直劃分技能保證產品概念上的一致性，也能大大減少溝通成本。當然前提是要有一個好的架構師。一個好的架構師可以把系統的設計與實現相分離，他的設計就是其他程序員的參考手冊，開發大綱，程序員的實現工作完全受制於架構師的總體設計思想，任何程序員都不應該加入自己獨特的與總體格調不一致的設計理念，即便是更好的想法也要捨棄。
按照垂直劃分任務的方法，程序員間的水平溝通就會比較少，更多的是程序員和架構師間的溝通，好的架構師應該通過好的架構設計把與程序員間的溝通成本也進一步降低，不是說溝通不好，而是說一些工作上好的設計可以減少溝通成本，溝通不是目的，只是必要情況下的手段而已。一切都爲項目最終的交付服務。
相反，如果是工作按照水平劃分，也就是說任務像切蛋糕一樣，平均一塊一塊地切給程序員，架構師沒有多少設計理念，變成了一個切蛋糕的，看樣子是任務分配者，一副領導架子，實際上他已經嚴重失職。這種劃分方法使得程序員間的溝通變得異常龐雜，最終拼湊出來各種風格混雜的一個四不像產品，而且項目週期還大大超出預算，因爲溝通的成本佔據了相當一部分總預算。