新架构需要的辅助制度、工作方法规定……

    1、项目组与研发中心的沟通标准。原来的项目管理和研发中心是基本二位一体，很多时候，沟通的过程都是非标准的。

    如定期由项目组向研发中心发送新需求清单＋缺陷清单，附上完整的需求文档。这些文档可让在项目组内部的需求代表（研发中心派员，新增职位，见上）参与撰写需求文档。文档可能需要来回沟通，但最后应有一个标准的需求文档、待完成清单。

    研发中心，定期向项目发送研发进展表（针对新需求清单＋缺陷清单）。

    沟通的周期，应尽量地小，最大不应超过一周，周三应该有一份非正式的清单反馈，缩小沟通周期以免影响项目进展。如有信息化的项目管理系统的公司，这些都是实时的，可以迟点再考虑。

    2、研发中心新增设了“开发测试人员”，所以研发中心应对发布出来的产品保证一定的质量。所以项目组每周的缺陷清单，应抄送指定的行政人员备档，每月统计各研发产品的产品测试阶段发现的缺陷数量。

    3、各项目组与研发中心的各组件开发小组，应制定标准的沟通人员清单。规定哪些问题，应由哪些人员来负责沟通。以前的经验是，大问题由小兵来负责，小问题由项目经理来负责，完全混成一片。应做彻底的梳理和规范。保证沟通的有效性。对于没有沟通协调能力、或沟通能力较弱的小兵（比如我），应尽量避免让其参与到部门与部门之间、或跨地域之间的沟通，极影响沟通效率。

    公司应规定哪些标准文档、沟通内容，应由行政人员备份。以记录项目进展和研发进展。定期发布各项目的实质进展报告。周期不应超过三个月，非常好的为每月发布一次。文档可由行政部来草拟（进展文档就应该傻瓜到行政人员都可以统计，客户也和行政人员水平差不多，如果行政人员看不懂项目到哪了，那么客户也差不多），成稿之后，交给研发中心各组件负责人、各项目经理签字，在公司内局部发布。

    4、项目经理，应定期撰写客户对项目进展的要求及评价报告，此报告应站在客户的角度撰写。在公司内局部发布，以保持各部门对客户态度的准确把握。

    5、研发工作量化管理制度。较复杂，另文再详述。