带团队的初体验

    最近在带一个小型的开发团队，第一次带团队，有一定的压力，但这压力还完全在我能承受的范围内，我是一个喜欢沉思的人，特别是上下班的路上，晚上躺下之后，我都喜欢想一些白天遗留的问题，晚上的寂静让我可以尽情地天马行空的畅想。最近这些日子我想的事情很多，有很多技术上的，更多的是我在思考如何让我带的团队高效地运作。

    我不是带团队的老手，但我有激情去思考带团队这个问题，带团队没有我想象的那么简单，这里面有很多的学问，其实就是管理科学。对我来说，管理不仅包括团队人员的管理，也包括技术上的管理，如何让团队的几个人在短暂的项目周期内顺畅地把项目做完，这值得我最近在带完第一个项目后认真思考，总结。

    正如《人月神话》上说的，团队人数的增加不一定会使项目周期更短，反而可能会是项目周期更长，这里面有一个沟通成本，而这一成本的预算对于一些经验不足的技术经理来说出入非常大。还有，测试这一块也是我们常常低估的一个环节。

    任何一个项目，都需要一个（或少数几个）核心人物作为“专制者”来统领总体设计思想，设计一定要和实现相分离，垂直分配任务，而不是水平划分，水平划分看似平等，但这增加了太多的沟通成本。垂直划分技能保证产品概念上的一致性，也能大大减少沟通成本。当然前提是要有一个好的架构师。一个好的架构师可以把系统的设计与实现相分离，他的设计就是其他程序员的参考手册，开发大纲，程序员的实现工作完全受制于架构师的总体设计思想，任何程序员都不应该加入自己独特的与总体格调不一致的设计理念，即便是更好的想法也要舍弃。

    按照垂直划分任务的方法，程序员间的水平沟通就会比较少，更多的是程序员和架构师间的沟通，好的架构师应该通过好的架构设计把与程序员间的沟通成本也进一步降低，不是说沟通不好，而是说一些工作上好的设计可以减少沟通成本，沟通不是目的，只是必要情况下的手段而已。一切都为项目最终的交付服务。

    相反，如果是工作按照水平划分，也就是说任务像切蛋糕一样，平均一块一块地切给程序员，架构师没有多少设计理念，变成了一个切蛋糕的，看样子是任务分配者，一副领导架子，实际上他已经严重失职。这种划分方法使得程序员间的沟通变得异常庞杂，最终拼凑出来各种风格混杂的一个四不像产品，而且项目周期还大大超出预算，因为沟通的成本占据了相当一部分总预算。