大纲的阅读对象是高级管理人、各Team负责人，他们只要明白整个业务流上的关键环节，一张概图就应该要能够达到这个目标，对于很多一线工程师而言，大纲通常是空话、废话。因为“违反大纲”这样的事情基本和他们无关。也不可能有典型事例。

过程的阅读对象不应该是工程师的层面，而是PM、TeamLeader、各总监，通过访谈、调研、讨论、以及评审、培训，使得在较高的一个层面上达成一致意见，这些人一方面都比较自信，二方面对于具体细节的工作参与不多，因此，过程要尽可能简略，一张流程图、一份角色职能列表要表达80％的过程信息。加上目的、范围要覆盖90％的必须了解的信息点。不要指望他们会把时间投入在指导一线工程师上。

子过程的阅读对象相对来说应该是各专业Team的管理者，有些复杂的过程必须要依赖子过程才可以阐述清楚。比如把产品发布环节中可能要一个产品部署过程，来阐述在部署环节中各种角色的配合关系

规则的阅读对象主要是执行层面的各种角色了，当然也包含所有兼顾管理工作的Team Leader，规则重点是应该做什么、怎么做，或者不准做什么，不准怎么做，举个例子，代码编写规则（规范）就是这样的东西，只要有规则存在，就一定有违反规则的行为，通常规则开始就会有类似KPI的东西伴随而生，这也是为什么执行层面的人会不得不关注规则。不按照规则未必会出事，但出事一定要被冠以“违规”，所以，趋利避害的朴素想法使得规则被关注的程度远高于大纲和过程。

流程和规则是一样的，阅读对象主要是执行层面的角色，流程的重点是怎么样的阈值什么人来批准、什么性质的事情应该怎么处置。举个例子，缺陷流转流程就是这样的东西。同样，违反流程看起来是个罪过很大的事情，比如，开发工程师自己把缺陷关闭了。虽然这样的问题可以通过系统交互细节来解决，但通常让SQA工程师最头痛的就是流程被屡屡绕过。

方法的阅读对象是不熟悉方法的人，这并非调侃，流程和规则肯定不能依赖一份文档，一个SQA来解决，因此，必须要依赖工具来解决，这个工具是广义的，比如一个系统、一个程序，或者一份模版，这个是过程人员推动的实践，但凡实践一定有人不会，有人不原意会，所以，方法就变成一个必须的输出。

指南的阅读对象是一切找不到北的人，这个是调侃。产品经理不原意看一套过程体系的，就给他一个产品经理工作指南，开发人员不原意做单元测试，就求高人编一个junit使用指南，或者项目组想用Scrum实践，但没有人引导，Scrum Master可以帮忙折腾个工作指南一类的。指南是一切过程、规则、流程和方法的辅助材料。

模版的阅读对象显然是一线人员，这个不解释了。