手机软件项目管理—项目组内部的沟通

五 项目组内部的沟通

1 SPM要把相关的项目信息通知到每个项目组成员，如产品定义、产品的上市时间、版本计划、代码存放地址、编译命令和开发环境等；且需要每周发布软件进度周报，告知项目组成员软件状态和进度。

2 在评估需求时，SPM一定要知会到具体的开发人员，请开发人员输出意见，如果SPM和开发人员的初始意见不一致，那最后也一定要达成一致，再由SPM汇总，对外输出；SPM最好不要直接取代开发人员做评估工作。

3 SPM需要和项目组成员明确，SPM作为软件项目组的唯一对外接口，承接外部需求和对外输出评估结果。

有时产品经理或其他人员会直接找到开发人员要求评估某个功能，开发人员不要直接输出评估结果，应先通知SPM，由SPM和对方沟通。

4 在评估需求时，往往关注了需求的实现，会遗漏需要外部提供的资源，在项目评估时，SPM需要从各项目组成员收集需要客户或其它部门提供的资源，如网络配置参数、三方应用、图片、铃声和信息模板等，并在制定版本计划时，列出需要资源的时间点。

5 SPM需要和各项目成员核对，各模块（包括三方应用）具体的开发计划，要和软件版本的主计划相匹配，尤其是把功能集成到代码主干的时间点，一定要和各模块负责人达成一致。

6 SPM需要和项目组成员明确，在项目过程中，如果项目组成员需要他人或其他部门配合，如测试和硬件部门配合，可以找SPM协调解决。

7SPM需要和项目组成员明确，在项目的开发阶段，以快速稳妥的解决问题，按时保质发布版本为第一准则。

在解决问题时，如果暂时无法查明具体原因或解决方案修改的代码较多，会有风险，那可以先采取一个临时变通的方法解决，先保证正式版本的发布，等后续再查明具体原因。

对于有风险的解决方案，可以先发布一个临时版本，让测试部门做专项测试，测试通过后，再正式集成到服务器上。（如果在项目过程中，开发一个大的新功能，也可以同样处理）

8 在提交代码时，开发人员一定要写明代码的用途，是解决某个问题或实现某个功能，以便日后追溯。不写清楚，时间长了，都不知道这段代码的用途了。

在提交代码时，最好是把解决某个问题或实现某个功能的代码一次性提交，以便其它项目移植或参考，不要分多次提交。

有时某个开发人员可能需要花费很长时间，一次提交很多代码，这时需要暂时锁定提交权限，只允许此人提交代码，其他人不能提交，以免提交代码冲突。

9 SPM需要每天review项目的bug列表，对于以下几类bug需要特别关注：(1)状态标注为Won’tfix和Invalid的bug需要看下，是否是不需要修改或

测试提交的bug是否真是无效bug。

(2)状态标注为WaitForInfo的bug，需要看下bug负责人需要谁提供哪些信息，帮其获取这些信息。

(3)经提交了3天，但状态还是New的bug，需要立即推动bug负责人更新状态，解决问题。

10 如果某个人员需要处理的bug较多，SPM需要和开发人员一起确定解决bug的优先级；或分配bug给其他人员，以便保证软件开发进度。

11 在项目的攻坚阶段，可以采用bugreview会议的形式，和项目组成员开会讨论，确定bug的处理方式：哪些改和哪些不改；对于要修改的bug，需要确认bug的优先级，先改哪个，后改哪个。

对内最好有测试人员一起参会，取得测试人员的支持，对外需要和客户一起开会核对，取得一致意见。

同时要每天给各bug的负责人发送bug状态日报，并抄送各部门领导，以便加快问题解决进度。

12 每次发布一个版本后，SPM要推动开发人员在bug系统上关闭所有已经解决的问题，并标明版本号，以便测试人员验证。