软件项目团队模型
摘要：
俗话说“三个臭皮匠胜过诸葛亮”，但实际工作情况往往是“三个诸葛亮不如一个臭皮匠”！ 软件开发是智力型团队，如何发挥每个人的作用，并将所有人的力量扭成一股强大的项目团队战斗力，这是项目团队模型要重点解决的问题。
大纲：
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. 项目组中所有人承担的工作负荷和责任应该大致均等。