摘要：
俗话说“三个臭皮匠胜过诸葛亮”，但实际工作情况往往是“三个诸葛亮不如一个臭皮匠”！
软件开发是智力型团队，如何发挥每个人的作用，并将所有人的力量扭成一股强大的项目团队战斗力，这是项目团队模型要重点解决的问题。
大纲：
1.传统项目团队模型
2.实际项目团队模型
3.
MSF的项目团队模型
4.实用团队模型
5.什么才是合适的项目团队模型？
正文：
传统项目团队模型
什么是项目团队模型？简单地说就是项目以怎样的方式组建团队，软件开发项目团队的传统团队模型如下：
项目组在项目经理的带领下，各角色协调工作，为项目成功而努力！
各角色的具体职责如下：
项目经理：整体协调项目，编制计划及保证计划执行，推动项目成功。
系统分析员：分析系统 需求，保证系统需求既满足客户要求，同时保证技术可行性；指导项目技术方案及系统架构设计。
软件设计师：细化系统设计。
程序员： 编码实现设计。
测试工程师：测试系统，保证系统满足需求。
实施工程师：部署、调试系统，培训客户，协助客户推动系统上线运行。
配置管理员：对整个项目周期中的工作产品实施配置管理。
QA： 质量保证工程师，保证开发过程按照既定的要求进行，保证工作产品符合既定的规范。
这个传统团队模型有两大特点：
1.一个团队总有一个头（这也是我们的惯性思维），这个头就是项目经理。
2.假设各种专业的角色能协调工作，并能各自发挥所长。
我们希望项目团队能有一个强大的头领，加上一班专业人才，共同为项目成功而努力。
但实际情况有这么理想吗？
项目经理会埋怨手下能力不够、不主动报告工作、不主动承担责任......
而项目组成员会埋怨项目经理不够强，只会叫他干活，不授权，更加不会传授知识......
实际项目团队模型
我们实际项目的团队结构，往往是这样的：
实际情况与理想的传统模型比较，有以下重大差异：
1.项目经理身兼多职。
很多项目往往没有专职的系统分析员和软件设计师，项目经理兼任 需求分析与软件设计的工作，甚至还需要负责编码的工作。
图中系统分析员、软件设计师这两个角色都是虚线框，意思就是表示这两个角色往往只是虚位，难以落实具体的专职的人员。
项目经理要做的事情太多了，往往没有办法专注 项目管理， 项目计划相关的文档能免则免，项目设计文档能少则少。
2.测试工程师、实施工程师低人一等。
很多公司公司的测试工程师、实施工程师会“低人一等”，开发人员有天生的优越感，而项目经理往往是由开发人员升任的，项目经理会有意无意地将测试工程师、实施工程师摆低一级。各角色如果不能平等的工作，项目团队战斗力自然大受影响。
造成这种不平等的原因主要有两个：一就是开发人员的天生优越感，二就是整体来说我们的测试工程师、实施工程师水平确实还不够
在我们公司其实也有这样的“不平等”情况，我花了很多时间营造“平等”的氛围，我的主要办法有：
1）通过各种途径不断强调项目团队各专业人才的重要性。
2）想尽办法提高测试工程师与实施工程师的水平。
3.配置管理员、QA再低人一等，甚至可有可无。
图中这两种角色是灰色的，这两者可能是整个项目团队中最“惨淡”的角色了！
好一点的公司都会有配置管理员，但往往被当作文员来看待，而有些公司甚至没有专职的配置管理员，项目经理甚至没有想到要配置管理这回事。QA是一个四面不讨好，到处惹人非议的角色，可以说是项目组中最“差”的职位了。
造成这局面原因也主要有两个：一就是大家的习惯性思维认为这两个职位就是最不重要的，二就是我们的配置管理员、QA的水平还不够的问题。
对于配置管理工作，其实实质就是项目生命周期中各种工作产品的管理工作，我认为项目经理应该发挥更大的作用，而我们的配置管理员应该嵌入到项目的具体中去完成工作，而不要只抱着配置管理的大道理来工作。
QA确实是最痛苦的职位，优秀的QA需要有资深的项目经验，但有资深项目经验的人大都不愿意做QA，这是多么矛盾和痛苦啊！
简单地说，实际的项目团队结构有以下严重问题：
1.团队的头不能专职项目管理。
2.项目团队中各专业人才要么缺失、要么严重不平等。
MSF的项目团队模型
MSF，全称是Microsoft Solution Framework，微软解决方案框架，是微软进行研发活动的方法论。
MSF的团队模型非常特别，它没有团队的头领：
此图来自MSF的官方资料
微软的团队是没有项目经理的，由6类角色组成，分别是产品经理(Product Management)、程序经理(Program Management)、开发(Development)、测试(Test)、 发布管理(Release Management)、用户体验(User Experience)。
各类角色负责的职责如下：
该模型的几个重要特点：
1.没有所谓的项目经理。
程序经理这个角色可以说是最接近项目经理的了，他需要编制计划及跟踪计划执行，但在行政级别上，他不是大家的头，大家都是平等的，大家只是处在不同专业的角度来负责工作。
2.强调项目团队是由各专家组成的。
软件开发活动是高强度高挑战的智力活动，我们需要由各类专家共同负责协调工作，每位专家都是同等重要的。
3.用户体验是我们常常忽略的部分。
用户体验简单地说就是用户使用软件时的感觉，软件的颜色、布局、文字、行为等等会直接影响用户使用软件的满意度。目前我们国内的项目组，往往没有 用户体验设计环节，也没有专职的用户体验设计师。
我第一次学习MSF团队模型时让我很震动，该模型体现了以人为本的开发模式，让团队中的每个人都极受鼓舞，但该模型在实际工作中很难完全应用，主要原因如下：
1.各专业人才水平参差不齐。
我的个人感觉国内以上六类角色的水平由高到低排列，大致这样：开发、程序经理、产品管理、测试、发布管理、用户体验，而用户体验基本是空白。各专业人才能力不相当，就无法组成“无头领”的团队，充分发挥各种角色的作用。
2.各专业人才水平全部没达到要求。
哪怕是水平最高的开发角色，我们的平均水平跟微软的相比还是相差太远，那就更加不需要提其他角色了。
3.团队协助能力差。
我们的团队基本不会“team work”，我们从小到大的教育就基本没有“team work”的教育。
MSF常常也被人以“太理想化”质疑，MSF所描述的世界只是软件开发的乌托邦而已。难道我们的现实情况就决定了我们的项目团队水平吗？我们没有办法建立一种实用的项目团队模型，让我们的项目团队能持续进步吗？
实用团队模型
我带领过很多团队，其中不少是带领应届生或者是工作经验还不多的工程师，团队中每个人的能力如果还不能塑造好，确实无法让团队高效运作。而项目初期我做的很多事情，都是通过项目具体工作来训练大家、提高每个人水平的事情。
我们的计算机相关教育并没有训练出合格的各类专业人才，但我们这般计算机从业者都是充满激情和追求进步的，基于这样的现状，我觉得应该有合适的团队模型能让我们的项目团队自学习，然后逐步发挥各专业人才的作用。
我们光抱怨我们的教育制度是没有用的，我们需要实用的团队模型来解决当前的实际问题。我在实际项目中的项目团队模型，通常是这样的：
角色和人并一定是一一对应的，一个人可以戴多个角色的帽子，一种角色也可能由多个人担当。
上述模型有8种角色：项目经理、产品经理、软件设计师、用户体验设计师、测试工程师、实施工程师、配置管理员、QA。
前面六种角色分别与MSF的程序经理、产品经理、开发、用户体验、测试、发布管理角色类似。
我基本上是很认可MSF的项目管理思想的，但为了适应实际情况，我做了一些必要的调整。
1.让综合能力比较强的人担当项目经理。
这个人不一定非常强，但只要他是项目组所有人中综合能力最强的人就可以了。项目经理除了领导项目团队，他需要更关注项目成员的成长。项目经理进行相关决策的时候，应该充分发挥大家的参与性。
2.各角色是同等重要的。
无论是测试工程师、实施工程师、配置管理还是QA，他们都和开发人员是平等的。哪怕是项目经理也不是高高在上的，项目经理只是比大家稍微高级别一点，之所以这样也是因为各角色的水平还不是很够，我们需要一个项目带领人。
3.持续总结与进步。
犯错不可怕，只需要能不断学习不断总结不断进步就可以了。整个项目小组是学习型成长型的团队，要人人勇于承担责任，不怕犯错，遇到问题一起来总结进步！
4.强调用户体验的重要性。
用户体验其实是很重要的工作，但往往被我们忽视，而现实情况是我们基本没有用户体验方面的高校教育，各公司在这方面的基础也比较薄弱。我在实际工作中，会把用户体验的责任落实到实施工程师与测试工程师头上，要求他们多从客户的角度来思考软件应该如何设计。另一方面，我会要求项目组成员或者我自己亲自编写出用户体验设计文档，让整个项目小组来评审。希望通过这系列的工作，培养出公司自己的用户体验设计师。
什么才是合适的项目团队模型？
其实没有固定的标准，各种项目管理理论都会有它自己的见解。无论是传统的团队模型，还是MSF的团队模型，各种理论都会基于某些假设，我们实际工作中应用这些知识时，应充分认识当前我们的水平和存在的问题，针对性地调整模型将其转化为合适的情况，并在实际工作中持续改善它。
从我的经验看来，以下几点是很重要的：
1.项目中的每个人尽管水平和能力不一致，但应该都被平等的对待，所有人对项目同等重要。
2.水平和能力较高的人，应该承担更多责任，并且有责任推动项目组人员提高水平。
3.“学习、总结、进步”，是每个项目团队应该具备的基本特点。
4.项目各角色的划分其实是灵活的，但项目所有人员的整体能力和水平，应该能覆盖实用项目团队模型的8种角色。如果缺失某种角色，或者某种角色的水平较低，项目组则应该有计划地去增强这部分的水平。
5.项目组中所有人承担的工作负荷和责任应该大致均等。
通过本文，希望能为各位打造高效的项目团队带来有益的启发。
作者：张传波
创新工场创业课堂讲师
华为某团队高级顾问
《火球——UML大战需求分析》作者