人员配置与沟通管理.docVIP

四、组内成员配置 　　项目启动之前除项目管理者着手计划制定外，同时也需要对其项目组那成员配置进行规划，界定其职责。通常我们需要几种角色： 　　技术组长：负责技术难题攻关，组间 沟通协调。 　　需求人员：负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化。 　　设计人员：负责对需求规格说明书，进行系统设计。 　　开发人员：实现设计，完成用户功能。 　　集成人员：负责整套系统的编译集成，督促小组系统功能提交，及时发现各模块集成问题，起到各小组之间的沟通的纽带。 　　测试人员：对于集成人员集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计。 　　文档整理人员：负责对小组内产生文档的整合，统一。 　　系统环境人员：负责系统编译环境、运行环境规划。编制系统环境说明书。 　　维护人员：系统验收后，维护人员，建议维护人员早期进入项目参与项目测试以便顺利承担起项目维护职责。 　　项目组启动初期需求人员首先根据迭代计划第一个迭代计划进行需求调研编制功能需求规格说明书，通过项目下到工序人员评审后进入软件设计、编码。注意，这里需求确认并不是指项目中的整体需求，仅仅是指该迭代过程中体现的需求。整个过程类似如项目开发流程，这里只是细小流程，逐步完善，渐进提交。 五、项目中沟通 　　通常项目中口头沟通是最为常见的，包括项目组内部、外部沟通，这种沟通快捷、方便。一般的小问题或者是简单问题的理解非常有效，但问题复杂或是此次沟通需要后续使用，那么该种沟通则存在问题，则需要以书面方式加口头相结合最为有效。即可在本次沟通中方便、快捷的领会，也可以为后续工作提供依据。 　　通常用户对于项目进度却是有要求，不仅需要提交周计划和总结，还需要定期汇报项目的完成情况，对于即将延时的里程碑，需要提前至少三天时间提出项目延时申请。那么从这里我们可以吸取，与用户的沟通间隔除每周进行项目计划和总结外，对于用户认可的项目开发计划，需要在里程碑需要向用户汇报，对于即将延时的开发进度，尽可能早的通知用户方的项目负责人知道，方便用户方的项目负责人有准备的与其领导沟通，可以有效预防工作被动状态出现。 　　项目组内部沟通不是越多越好，你会发现当内部的沟通时间没有规律或是沟通时间过长，这样其实也会严重影响项目成员的开发进度，但沟通又是必不可少，何种间隔最为适宜了?这是不好定的，我们通常以评审作为沟通的基础，平日的沟通建议项目组成员在每天工作过程遇到问题，将其记录下来，然后在以邮件方式发送给需要沟通或者询问者。大家可以每天下班之前收取邮件，对于可以直接回答的问题则直接以邮件方式回复，对于无法直接答复而只需与提出问题者讨论的问题，则可以在第二天上班前进行商议确定。而需要众人一起讨论的问题，则放到每周 会议上讨论。非常紧急的话则可以马上约齐人员讨论，通常有良好的沟通方式话，这种非常紧急的问题是不常见的。