01 前言

最近，由于工作疲于各类突然的临时事件，整天和流程穿透、文档、数据等打交道，偶尔在与别人闲聊的时候产生了以下几点感悟，记录下来。

02 流程在软件质量体系中的作用

我曾经犯过这么一个错。

17年从就职CMMI 5的公司离开了，去了一家初创公司，当时主要负责研发流程体系的搭建及落地运行。刚接手时，身边的同事对于流程、质量体系这些的概念几乎为0，我心想，上家公司质量体系建设和运营的这么完善，我依葫芦画瓢搬过来就是了呗，然而，现实情况却是另外一番景象！

因为是初创公司，原公司很多流程细节在此处无法复制落地，执行过程中会遇到各种问题，甚至会产生阻碍。

该出现的问题还是会出现，曾经让人引以为傲的CMMI 5质量体系一时间竟有点尴尬了

于是，我回过头来想，流程体系的建立是为了什么？或者说什么样的流程体系才是最合适的。

首先，流程的建立肯定是为了解决某个突出的问题，而不是因为我们建立流程而建立。

一个事情，简单如买菜，绝大部分人都能无纰漏的完成，这样的事就无须再建立流程了，因为众人基本一致的行为已经是最好的流程，且固化在每一个心中

稍微复杂点的事，比如做个清蒸鱼，同样的材料，不同人做出的味道不一样，且存在味道好于坏之分，那做出美味的清蒸鱼的人是怎样的烧菜工序，味道不那么尽然的，是操作步骤混乱了，还是火候把握不到位了，还是配料搭配的原因，想提高，是否可借鉴他人经验？

流程的应运而生也是这个道理。为了解决某个问题而产生。

流程是否越详细越好？并非如此，既然流程是为了解决问题的，那针对问题制定可帮助提高问题的方法，步骤，约定即可，只要解决了既定的问题，流程落地已经成功了。

如果想更进阶，或者发现其他问题，那就是修订的问题了~我觉得在解决当前问题的前提下，越简答越好。比较，胖子也非一朝一夕就能养成的。

另外还有一点，流程生效前务必征得涉及关键人物的一致意见。

03 文档只是应付要求的？

一般技术的同事对于写文档这个操作是比较抵触的，哈哈，毕竟天性使然，尤其是大部分开发小伙伴，心里大概会默认一个念想：明明有敲代码这么高级的操作，为何还要写这些没用的文档？

那文档到底有没有用呢？或者会有啥作用呢？

其实大部分引入了ISO 9001或者CMMI等管理体系的公司，可能都会要求输出很多文档，比如各类计划、各类设计文档、测试文档、问题记录等，那是不是所有的文档都有必要存在呢？

曾经和业内的一个大佬，也是一个比较出名的CMMI咨询师聊过，他提及大部分公司在搭建及运行质量体系或者进行CMMI各级别认证的时候都走篇了，以致于狂要求输出各类文档，甚至会有文档输出越多，对提升项目交付质量越有帮助的误区，然后底下的很多干活的小伙伴就来了：写这些文档都是给QA看的，都是那个啥CMMI惹得祸...

现在仔细一想，CMMI 真是冤大头了，因为误解的人太多了！！！

CMMI规定，要达到相应的级别，需完成对应的过程域，怎么证明完成了，提供证据，注意了这里说的是证据，没有非说是文档，证据的形式可以是文档罢了

所以我们确切需要哪些文档呢？

1、工程技术类文档，如需求分析书、概要设计文档这些应输出几份，就应该按要求按时间输出几份

2、管理类文档：如各类工作计划、资源评估等，尽可能少，能满足大纲要求即可

3、记录类文档：建议用工具或其他方式体现

现在回过来看看必要的工程技术文档，还只是用来提交给QA检查的吗？显然不是，因为我们的软件研发必定是一个协同完成的工作，写文档的同时能帮忙理清思路，明确实现方式，重要控制点，t同时同步给合作伙伴，这么来看，这类的文档没有什么理由省略，因为可发挥的价值太大了

04 成天的分析数据有用吗？

首先，无质量不数据，这句话我一直赞同。

数据中，永远包含着真理及待发现的真理。

首先，要明确要收集拿些数据，想体现什么方面的问题？

其次，如何确保数据收集正确及有效

再之，怎么分析数据，横纵向对比能发现哪些问题？

最后，数据中体现的结果如何转化成可驱动人改进。

所以我觉得，先想想要通过数据反映什么问题，然后再制定数据的收集分析方式，最后找出问题，或奖或惩，让数据开口说话并直入人心。

05 审计就是找茬并扣绩效？

审计的意义是什么？其实这个问题我也在问自己，因为审计的同时，事情已经过去了，还为啥还要去翻旧账呢？

审计是为了保证执行与流程100%符合？发现问题然后跟进解决？我觉得这不是最主要的。

我觉得审计最主要的目的在于向这个世界宣告，某些流程，某些制度，某些规范并不是说着玩的，让执行者心里有一根紧紧的绳子。

其实没有流程是100%符合的，审计人员看到通篇100%合规的结果也许是失败的，因为人都是这样，达标了开始放松，落后了开始绷紧，审计的目的就在于让所有人知道有这么回事，某些事情不是无人管辖的，这其实是个心理战争，让少部分人当“鸡”，大部分人当“猴”，杀鸡儆猴！