仅针对当前项目组，其他项目组慎用，呵呵~~
这些天为给组员培训些的东西，摘取要点，可能不全面，呵呵
项目组人员职责
1、总则
本文旨在明确项目组各相关人员责任和权力，明确任务分工，降低各角色之间协调的成本，提高沟通效率。
2、项目角色定义
1) 项目经理：
代表公司执行项目管理，进行整个项目的协调工作，对项目成败直接负责的人员。
2) 需求人员：
与客户业务人员进行业务需求沟通，引导业务人员进行系统需求提出的人员。
3) 开发人员
根据需求进行系统设计及编码的专业人员。
4) 测试人员
根据需求对系统进行正确性验证的人员。
5) 配置管理
负责进行系统基础软硬件环境管理、版本发布的人员。
3、项目角色职责
3.1 项目经理
A. 对项目成败及收益负全责。
B. 5大过程管理：（摘自PMPBook）
a) 项目启动过程，
b) 项目规划过程，
c) 项目执行过程，
d) 项目监控过程，
e) 项目收尾过程。
C. 9大领域管理：（摘自PMPBook）
a) 项目整体规划，
b) 项目范围管理，
c) 项目时间管理，
d) 项目费用管理，
e) 项目质量管理，
f) 项目人力资源管理，
g) 项目沟通管理，
h) 项目风险管理，
i) 项目采购管理。
3.2 需求人员
A. 对需求正确性和完备性负全责。
B. 进行需求沟通：与业务人员深入沟通业务需求，确定软件需求限制和软件同其它系统接口细节。
C. 发起讨论：与业务进行重大需求讨论和确认前，应与项目组内部干系人进行需求讨论，达成一致，避免出现不合理需求。
D. 出具需求规格说明书：出具完整描述业务需求、无歧义、可执行的需求文档。
E. 维护需求状态。
F. 解答项目组内其他人员关于需求的疑问。
G. 屏蔽业务人员对开发人员的干扰，使得开发人员可专注于系统实现。
3.3 开发人员
A. 对系统功能代码质量负全责，掌握功能发布状况。
B. 需求沟通：与需求人员沟通需求，了解需求细节。
C. 需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量。
D. 系统设计：根据需求规格说明书进行系统功能设计，出具可执行的详细设计文档。
E. 发起评审：重大功能或核心算法，在编码前，应主动提起设计评审，让项目组相关人员相互取长补短，共同把控系统质量。
F. 编码：根据详细设计文档进行系统编码工作，实现需求功能。
G. 单元测试：对自己开发的功能进行单元测试，确保功能的正确性。
H. 功能发布：负责正确填写更新列表，跟踪功能发布状况。
I. DAT验证测试：接收到配置管理人员更新完毕的通知后，在DAT进行功能验证，确保更新完整性。
J. BUG修改：修改DAT和UAT发生的BUG，及时发布，并跟踪BUG复测情况。
注：开发人员享有拒绝权：
若发生需求描述不明确，或与系统不兼容，甚至不能实现等需求问题，开发人员有权利拒绝本需求的开发，并与需求人员沟通提起需求的再分析。
若接收到的BUG非系统功能问题，开发人员可进行拒绝处理，并根据实际情况进行解释或提起讨论分析。
3.4 测试人员
A. 对DAT测试完毕并发布UAT后的系统质量负全责。
B. 需求评审：评审需求人员编写的需求规格说明书，共同把控需求质量。
C. 理解需求：深入理解需求人员给出的需求规格说明书，掌握业务需求要点。
D. 编写测试案例：编写能覆盖需求内容、且能覆盖绝大部分业务行为的测试案例。
E. 发起评审：重大功能或核心功能的测试案例应发现评审，共同把控案例完备性。
F. 执行测试案例。
G. 复测BUG。
H. 出具测试报告：给出能否更新UAT的结论，若不能更新UAT，需给出哪些点不能更新。
注1：测试人员享有拒绝权：
若开发人员提交DAT的功能有阻断性BUG或严重BUG较多，测试人员可拒绝相关功能的测试，等待开发人员调整系统。（严重Bug较多：按功能工作量，平均每天发生一个严重Bug）
注2：测试人员享有免责权：
若测试报告为不能更新UAT，但经项目经理及客户同意，将该功能更新到UAT，则测试人员可不对测试报告中提出的不能更新的功能点负责。
3.5 配置管理
A. 对公共软硬件环境稳定性及功能发布正确性负全责。
B. 软硬件环境准备：负责搭建及维护公共软硬件环境，如VSS、开发库、DAT等。
C. 按时发布功能。
D. 确保开发人员提交的文件完整正确的发布到相应环境，若发现开发人员填写文件不正确，应提醒相关开发人员填写。
E. 大版本发布方案整理。
注：配置管理人员享有拒绝权：
若开发人员不按时提交更新，或提交的更新不正确，配置管理人员可拒绝更新相关功能。