兵书有云：“兵不在多，而在于精；将不再广，而在于勇”。因此一个软件项目能否成功其关键并不在于有多少人，而在于如何建设一个高效、和谐、反应快速的团队。但是说起来简单，可在实际工作中我们总会遇到许多难以预料的问题，这些问题有些是技术上面的有些并不是技术上面的，有些问题可能在目前中国式的软件开发中永远也不能很好的解决。但是，生活还要继续，程序员也需要面包和牛奶，面对这样的情况我们所要做的是“把问题搞定！”。

目前根据开发团队的人数基本上可以把软件开发团队分为：

1、大型团队：我个人认为大型的团队没有一个固定概率，通常有若干个中型或者微型的团队中一起来完成一件事情，这样的团队 可以称之为大型团队。诸如微软、google这样的团队不在本文到讨论范围之内。

2、中型团队：通常团队的人数字20人以下，10人以上并且在做通一件事情的开发团队。这样的开发团队可以有这样几个部分组成。

3、小型团队：5人以上，10人以下。

4、微型团队：5人以下，有时候甚至一个人，笔者就有过这样的经历。

在web2.0时代造就了大量新兴的网站，这些网站在开始的时候通常是由一些小型团队开始的，如果这个时候没有组建一个好的团队那么项目可能坚持不到凤凰涅磐的那天（通常是被收购或者得到GC :)）。同时web2.0时代一切都趋于理性，各路财神无不看紧钱袋因此创业型的团队不可能在一开始就组件很大的团队，因此中小团队的建设显得尤为重要。

凡是项目团队肯定就要有一个负责人，这个负责人就是通常所说的项目经理。可能大家所经历的团队多是一个或者几个大虾带着一群小虾一起开发。现在第一个问题来了，项目经理到底要不要有很好的技术底蕴？我想大家在面试的时候经常会被问到这样一个问题：“如果某完全不懂技术的人领导你，你会服从他的领导吗”，我想大多数人都会回答：”服从“，虽然心里并不是真服从。但我们经常遇到的一个情况是：项目经理对下面的开发人员失去了控制。所以目前大多数项目经理都是在程序员中产生的，我想这也是大多数程序员奋斗的目标吧（之所以说是大多数那是因为我们不得不承认有些人天生确实不适合管理一个团队）。可是许多技术高手走上管理岗位后变得无所适从，甚至有的既没有有效的带领团队很好的工作，同时也荒废了自己的”武艺“。那到底项目经理应该由什么样的人来担任呢。依笔者愚见，在中国式的软件开发中项目经理是那些有管理才能的技术高手来担任。至于其原因笔者认为有以下几点：

1、和开发人员的交流问题

项目经理如果不是搞技术出身的话那么他很难理解开发人员的一些行为，同时他也不能程序可以理解的语言将问题描述清楚。还有， 没有搞过技术开发的项目经理通常不能很好的理解程序员的工作习惯。笔者就遇到过这样的一件事情，开发人员正在为赶进度全力以 赴对某个技术难题进行攻关，这个时候项目经理在写一份需求，他有个并不是很重要的问题需要咨询开发人员，于是这位老兄随即打 断开发人员的思路，向他询问这个问题。结果是可想而知的，开发人员最反感在他集中精力解决某个问题的时候被人打断。其实搞过 技术攻关的人都知道，如果换个时候提问结果是不一样的。同样的问题在不同的时刻提出往往结果是不一样的。

2、对问题的思考角度

开发人员和非开发人员思考问题的角度通常是不一样的，这里笔者并是强调项目经理非要按照开发人员的思维考虑问题。比如项目 经理 在跟客户交流的时候是绝对不能用开发人员的思维跟客户交流的。但是同样的问题如果你在跟开发人员交流的时候，能够 按照开发人员的思维方式表达出来那么结果是皆大欢喜。由此可见技术能力对项目经理是比较重要的。

3、统一的描述语言

目前的开发实践中似乎缺少一个统一的思维表达方式，RUP，UML似乎并不能完全解决我们的问题。“用户不懂java，同样也不懂UML” 因此项目经理的技术能力就跟显得重要了。他能够把用户的要求用程序员的语言表达出来。

综上所述有管理才能的技术高手来担任项目经理还是比较合适的。

讨论完中小型团队中的项目经理，下面我们来探讨一下中小型团队中的主力-程序员。他们应该如何组织呢？

笔者个人认为有以下几点可以参考

1、如果开发团队的人数小于5人，那么有项目经理直接领导。

2、如果开发团队大于六个人可以将它们划分为若干个小组每个小组不少于三人不多于5人，同时每个小组设组长一名。这里笔者提醒大家都是，在一个小组中组长的技术能力要高于组员，不要让小组中存在和组长技术能力不分上下的人。这样不利于小组的和谐。诚然，现实的工作中有很多李云龙，赵刚似的好担当。但是那确实很好，我们没有必要冒这个风险。

3、在项目的开发过程中有很多需要进行技术攻关的任务，这个任务通常是项目经理一人来搞定（条件是他有这个实力）或者有些团队会设定专门的技术攻关小组。笔者并不反对这一点做法，只是如果在条件允许的情况可以将这些任务适当的分配到各个小组，这样能让每个开发团队的成员都有机会接触到新的东西，毕竟没有谁喜欢一直调用别人的API。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号