进工作，定期召集会议，讨论制度流程的改进。老子说："治大国若烹小鲜"，煎小鱼儿，必须经常翻，不翻就煎糊了；但也不能翻得太勤，翻得太勤就会破环小鱼儿的形状。制度流程也是一样，不应该变动太频繁，让员工不知所措；但也不能永远"以不变应万变"。
2. 软件开发项目组，包括：项目经理、项目成员、质量控制专员、项目秘书等，负责具体的软件开发。
3. 质量保证人员，相当于"检察院"。其工作主要保证制度流程的顺利执行，一个质量保证人员监控几个项目组了。质量保证人员不仅是事后检查，还必须强化事前和事中控制。质量保证人员要主动协助项目经理以及项目组成员理解这些流程、模板、规范，譬如写代码前，质量保证人员可以给项目组介绍编程规范，写文档前，介绍文档的标准、模板等。质量保证人员保证公司的质量体系在项目组内得以实施，每个阶段结束后，都要对该阶段的进行质量以及流程执行情况的总结，监控项目按照质量计划（质量计划是项目经理制定的）执行。质量保证人员还要通过项目组成员搜集数据，分析数据,给出分析报告，等等。
六、需求分析
需求分析贯穿项目始终，在项目过程中会不断产生新的需求，也会不停地发生需求变更。需求分析是项目管理的重点和关键，需求分析常见的问题有：
1. 需求膨胀。希望一次解决所有的问题，项目范围不断扩大，"把海水煮沸"，最终导致项目失控，偏离原来的项目目标。
2. 需求曲解
a) 需求镀金。对用户需求进行了包装和拔高，"用户需要的是一辆自行车，而不是宝马"。
b) 选择性地过滤用户的需求，"对一个拿着榔头的4岁小孩来说，满世界都是钉子"，需求分析人员可能因为自己的价值观而片面分析问题。
3. 需求分析人员过早给出解决方案，失去了寻找更好解决方案的机会。
需求分析的"5C"和"5T"原则
1. Correct（正确）：表述的内容一和包含的信息应该是准确无误的。
2. Clear（清晰）：言简意赅，意思明确，无需别人绞尽脑汁这个需求到底是要表达什么意思，措辞不可含糊不清，模棱两可，更不能让人感觉话里有话，引起岐义。
a) 易引起岐义的需求表述句式通常是否定式，而不是肯定式。
b) 不要隐含假设 -- 所有假设都应表述清晰。
c) 对所有需求要进行优先级排序。一些需求会比另一些重要，如果需求分析人员已有了这样的判断，就应该也传递给别人。
3. Complete （完备）：每条需求都应完整无缺，避免漏缺或不必要的重复。
4. Consistent （前后一致）： 需求应能与上下文保持一致。需求应包含关键字或标识符，如"应"代表必要的需求，"将"代表导向性需求，而且全文保持这一种优先级定义原则。
5. Changeable（可变更）：对单个需求的更改不会对其他项造成过多影响。
6. Traceable（可追溯）：所有需求的来源都要明确，应可追溯到其他相关文档。
7. Tenable（合理）：所表述的需求必须是可实现的和可操作的。 能否在项目预算范围内，利用有限的资源，按时实施这些需求？一条需求是否与其他需求有冲突？是不是正当需求？ 需求实际上都应是必要的。也许需求用"将"来描述更好一些，也就是指，导向性或非基本功能。某个需求是否只是一般描述，与系统功能没有什么关系？某个需求是否超出系统控制范围，或根本不是需求？ 对每个需求，是不是都能找到用途或用户？有没有存在的理由？
8. Testable （可测试）：确定每一条需求都可以通过某种方法去测试其是否能实现。是否已量化？容错性和误差范围是否说明？能不能想到一个合理的方法去测试它？ 这个需求的结果是否可见？
9. Tool （工具性）：需求管理的工具化。
10. Terminology（项目术语表
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
