接触过制造业的小伙伴对这个词应该说是非常的熟悉。它就是一本傻瓜手册，傻瓜到就算你没有任何专业知识背景，也能完成分配给你的工作，大家之间的差别只体现在熟练度。
没有多少人会注意到 SOP 本身的技术含量，因为一份真正的 SOP 会写得很傻瓜，以至于很多非管理系工程师会觉得「这么傻瓜流程化的东西，真的有必要写下来吗？这简直是对智商的侮辱。」
什么是 SOP ?
先让我们随手举个例子来理解一下 SOP ，比如我们要写一个「把大象放到冰箱里」的流程：
有图有真相的 C 才是一份 SOP ，为什么 B 不是？因为它隐藏了一些专业知识，首先你得知道什么是冰箱，什么是大象，其次还得知道这个叫冰箱的东西怎么打开。
我相信，大家都会觉得这例子好傻：竟然有人不知道冰箱和大象？有了冰箱还不会打开？最傻的是这么的内容竟然还有人用图文把它写下来。
那么如果我们换掉一些名词呢？
「打开 GUI ，配置 S3 信息，再关上 GUI 」
非软件领域的同学，也许压根儿不知道这是在说什么。
多数人都习惯性的把自己所掌握的信息，强加于人，一些自己非常熟悉的小知识，默认别人也应该懂得。在工作中，我们花在沟通上的成本过多，正是因为信息不对称造成的。再加上「难者不会，会者不难」，感觉 SOP 傻的人，都是对 SOP 所述内容熟练到不需要经过大脑思考的熟练工。
扯远了。
SOP 的最佳效果应该如何？—— 「随便一个人来照着文档做，不动脑子也能完成工作」
技术含量甚高的软件业也可以用这样的 SOP ？
我们的团队是一个基于 Linux 平台的分布式云存储系统测试团队，不但要会敲命令，还得会编程。
在这样的一个团队里提出写 SOP ，一开始几乎没有组员认同，总结下来两点：
# 工作中目标虽明确，但测试方法不唯一，怎能只总结为一个流程？
# 工作过程中每次会遇到各种不同状况，怎能靠一个简单流程来指导？
简单一句话：软件测试也是有技术含量的，怎能随便一个人都能做。
这些话，没毛病。我也非常认同，只不过大家会错了意。
写 SOP 并不要求多种解法，只要一种解法，解出答案，固化下来。
如果按照一种解法每次都会遇到不同问题，难道不要怀疑是方法有误，或是产品有缺陷吗？
所以从这个思路去规划，对于产品团队而言，即使自动化软件测试团队也是可以有 SOP 的。
为什么要折腾 SOP ？
当时组员还有一大质疑：花时间搞这个，值得吗？
我一向都用简单粗暴的回答，直接说目的：「让初级工程师或新人解决答案已知的回归性题目，解放高级工程师，从而让他们去分析更复杂的难题」
中国有句老话：「师傅领进门，修行看个人」
让高级工程师教会新员工一种解题方法，让他勉强能完成工作，至于「多解」这种能力，让他们自己修炼去吧！
最后我说一下推行后的效果：
再也听不见高级工程师们抱怨：
# 带一个新人我都没有精力干活啦！
# 这活都没人能接手，我哪有时间去研究技术啊！
如何建立软件测试 SOP 体系？
这是一个好问题，我以后应该要尝试再总结一下具体如何实施。
