标准作业流程启示录
近一年时间都忙着服务于各企业客户，疏于做整理分享。这是一篇我在 5 年前写的文章《你真的能写好 SOP 吗？》，发布在其他平台，阅读量不算高，这么多年，也就 10万+ ，是不是真的有这么多人感兴趣，我也不知道，最近，遇到不少制造业客户，令我想到了这边文章，于是重新整理了一下。
接触过制造业的小伙伴对 SOP 「Standard Operating Procedure」这个词应该说是非常的熟悉。 它就是一本傻瓜手册，傻瓜到就算你没有任何专业知识背景，也能完成分配给你的工作，大家之间的差别只体现在熟练度。
没有多少人会注意到 SOP 本身的技术含量，因为一份真正的 SOP 会写得很傻瓜，以至于很多非管理系工程师会觉得「这么傻瓜流程化的东西，真的有必要写下来吗？这简直是对智商的侮辱。」
我个人的观点：SOP 是人类在现代化工业生产过程中伟大的智慧成果。
什么是 SOP
维基百科的解释是:
在有限时间与资源内，为了执行复杂的事务而设计的内部程序。从管理学的角度来看，标准作业程序能够缩短新进人员面对不熟练且复杂的学习时间，只要按照步骤指示就能避免失误与疏忽。
—— 维基百科
先让我们随手举个例子来理解一下，比如我们要写一个「把大象放到冰箱里」的流程：
哪个才算是 SOP 呢？
送分题，有图有真相的 C 才是一份 SOP ，为什么 B 不是？因为它隐藏了一些专业知识，首先你得知道什么是冰箱，什么是大象，其次还得知道这个叫冰箱的东西怎么打开。
我相信，大家都会觉得这例子好傻：竟然有人不知道冰箱和大象？有了冰箱还不会打开？最傻的是，这样的内容竟然还有人用图文把它写下来。
那么接下来，我们尝试换掉一些名词。
且不什么领域，就算是明确领域，同一家公司不同部门的同学，也许都压根儿不知道这是在说什么。
多数人都习惯性的把自己所掌握的信息，强加于人，一些自己非常熟悉的小知识，默认别人也应该懂得。 在工作中，我们花在沟通上的成本过多，正是因为信息不对称造成的。 再加上「难者不会，会者不难」，感觉 SOP 傻的人，通常都是对 SOP 所述内容熟练到不需要经过大脑思考的熟练工。
扯远了。
SOP 的最佳效果应该如何？—— 「随便一个人来照着文档做，不动脑子也能完成工作」
SOP 是否可行
技术含量甚高的软硬件领域也可以用这样的 SOP 吗？
2012 年的时候，我当时工作的团队是一个基于 Linux 平台的分布式云存储系统测试团队，不但要会敲命令，还得会编程。用现在的岗位描述就是「自动化测试工程师」甚至是「测试开发」。
在这样的一个团队里提出写 SOP ，一开始几乎没有组员认同，总结下来无非两点：
- 工作中目标虽明确，但测试方法不唯一，怎能只总结为一个流程？
- 工作过程中每次会遇到各种不同状况，怎能靠一个简单流程来指导？
简单一句话即：软件测试也是有技术含量的，怎能随便一个人都能做。
这些话，没毛病。我一直也非常认同，只不过很多人会错了意。
对于第一点：测试方法多样
写 SOP 并不要求多种解法，只要一种解法，解出答案，固化下来，解法可以很复杂，尽量覆盖比较多的逻辑，预期结果可判断。
对于第二点：验证结果多样
假设按照某一种解法，每个验证步骤都会遇到不同问题状况，难道不要怀疑是方法有误，或是产品有缺陷吗？
因此，从这个思路去规划，对于产品团队而言，软件测试团队是可以有 SOP 的，即使是自动化软件测试团队。
SOP 是否值得
当时的阻碍还有一大质疑：花时间搞这个，值得吗？
我一向都用简单粗暴的回答，直接说目的： 「让初级工程师或新人解决答案已知的回归性题目，解放高级工程师，从而让他们去分析更复杂的难题」
中国有句老话：「师傅领进门，修行看个人」
让高级工程师教会新员工其中一种解题方法，让他勉强能完成工作，至于「多解」这种能力，让他们自己修炼去吧！
最后我说一下推行后的效果：
再也听不见高级工程师们抱怨：
带一个新人我都没有精力干活啦！
这活都没人能接手，我哪有时间去研究技术啊！
软件测试 SOP 体系如何建立
这是一个好问题，即：
- 测试用例如何管理
- 自动化测试用例如何管理
- 软件质量如何管理
- 缺陷如何管理
看起来并不是一个三言两语就能回答的问题。请关注后续。
事实上，职场中随处可见 SOP 的影子，审批流程、任务工作流等等。
传统模式下，主要靠发布通知，让人照章办事。但随着信息化建设的成熟，数字化的 SOP 更加智能、友好。
如今，工具不再是瓶颈，而是缺少能够把传统模式转换成数字化模式的“翻译”工作者，互联网软件仅仅是万千领域中的一个领域。
—— 笔者后记
