戏说流程制度

序

    想成功，先弄几个流程制度，这也算是发疯的一种。。。想成功，先发疯。

    孤注一掷里面的标准化流程来一套，也是集合了各种人的经验，就和有些地方所谓的SOP流程一样，先来一套SOP，然后再继续。

风言风语

    秋风吹，忽然想起原来忽悠别人做各种流程。

    当一个企业有一定的规模之后，就会有各种流程了，为啥呢？原因有二：第一个是因为对于管理层来说，劳资定的规矩就是规矩，制定流程是为了便于管理，例如项目管理流程，对于管理层来说，会节省很多时间，不需要花费很多时间，从而只要看一下统计表就能知道当前所有的项目，目前的进展，其实和经营列表是一样的，主要看数据就行，毕竟所谓的管理层也没那么多时间和精力来查看每个项目的进度时间日期，毕竟管理嘛，无需了解底层；第二个是因为一旦人数超过了一定的限制，例如8个人，就无法知道每个人手头上的事情，也不知道每个人的技能水平，从而有一套准入的流程，从而可以大大的节省培训成本，一些标准的流程可以指导一个小白一步一步完成螺丝工的功能。

    不同的规章制度，在不同的时间，不同的场合出现，也是为了解决一些问题而出现，然而是否能解决问题，主要还是看是不是提供了有效的流程制度，而不是为了应付，如果所有的都是形式，除了浪费时间，其他毫无用处。

    尝试谈谈怎么样的流程才是一个好的流程，什么时候加入流程才是一个好的时机。

    1 为什么别人反对一个流程

    为什么要反对一个流程呢，肯定不是因为爱情，而是因为利益。

    宣布一个流程的时候，其实最初的都是草稿，不会很成熟，从而造成了流程不清晰，今天一个流程，明天又变了，让执行者无比烦躁，白白增加了很多工作成本。

    当一个流程开始落地执行的时候，其实会很大程度增加底层人员的工作量，当时所有事情的进度还是保持不变的状态，就像一个变更管理流程，如果你是执行者，你会增加发布变更的事情，你会增加变更前置检查动作，你会增加变更变更结束检查动作，检查的工作量谁来承担？

    当一件事一旦计划提上流程，如果这件事本身就充满着变量，那么这件事的进度就更加难以控制了，根本不可能完成的任务咯。

    流程执行，损害的都是执行者的利益，而对于好处来说，基本上都是管理层收益，水能载舟却不能覆舟。

    2 如何解决这些反对的声音

    大部分的企业，其实并不关注这些反对的声音，因为劳资的规矩就是规矩，你必须遵守。

    流程不清晰，说明调研程度不够，经常变化，说明不成熟，那么借用别人的成熟的方案，然后进行宣讲培训，对具体的流程有专人服务，流程的问题流程解决，从而能缓解部分问题，对于那种实在不想执行的，其实也很难推进，除非碰上了一些事，必须依赖这些流程来解决。

    增加了工作量，那是否有专人去负责这些事情，从而让总体的工作量保持平衡，但是管理者一般画饼，这些流程是为了帮助大家更好的执行，啊呸。。。

    流程增加了，理论上是可以提升质量的，但是对于效率的追求就不要那么高了，管理层就要提升这种意识。

    其实也就是上下要达成一种共识，大家都别催，都按照流程时间节点来，如果没有这种默契，那就很难了。

    实际上每个人都会只关心自己手头上的问题，例如管理层发现自己无法掌控所有项目，就会弄个项目经理来管理，从而流程有了，数据统计有了，而这种算是比较好的，毕竟加了人。

    3 流程主要解决什么问题

    一套流程下来，主要解决什么问题，这个非常关键，决定了整体流程执行的走向。

    就像变更管理流程，主要是为了解决变更导致的故障，那么在没有这套流程的时候和有了之后，有什么样的区别呢？

    没有变更管理流程：变更随时执行，变更故障率80%，变更导致的后果损失10%营收。

    有了变更管理流程：变更执行效率降低，原来一次变更10分钟，现在一次变更需要1小时，变更故障率降低为20%，变更导致的营收损失1%营收。

    这就是一套好的流程，能真正解决问题，从数据上来看，主要的目的达成了，大大提高变更的质量和减少执行风险。

    曾经看过一套研发流程，主要目的是为了提升质量，然后定了发版日，发版的时候要提供各种各样的单据，试问，这种流程能提升质量吗？定一个发版日，就能减少BUG？如果研发人不换，如果单元测试不足，该有的BUG一个都跑不了；发版的时候提供各种各样的登记单据，这能提高质量？啊呸。。。形式主义很足，这种流程除了增加工作量和负担，减少斗志，毫无用处，为了做流程而做流程。

    如果使用了这个研发流程，是否有可量化的数据对比，例如上了流程之前，BUG率是多少，上了流程之后，BUG率是多少，这个。。。好像无法量化，也无法证明是流程带来的价值。

    流程不是形式主义，真正好的流程都要从目的出发，具有可衡量的数据出发，从而去做针对性的流程。

    例如研发流程，如果发现是人员能力不足导致的BUG率很高，那就应该去做培训，不是弄一个研发流程；如果发现是人员发版的时候不细心，那就应该增加发版流程，增加双人check啥的；如果发现是代码写了之后，就上线导致的BUG率很高，那就应该做单测流程，回归测试流程。这或许是更好的流程，能真正解决问题的流程。

    4 什么样流程是一个好的流程

    一个相对好的流程，应该是能解决问题的流程，不是泛泛而谈，可能是更加详细的一个一个案例组成。

    例如变更流程，划分为很多，可能有nginx变更流程，在修改配置的时候，要检查语法，在生效的时候，需要使用reload，在变更完成之后，需要去检查access log和流量。深入这些细节让每个人都知道正确的事应该去做什么。

    流程能深入细节，也是极好的。

    流程也可能是技术，对一个技术点的深入，能识别到其中的问题和风险所在，例如进行k8s扩容的时候，你需要新加入一个cordon的节点，不立即上线，然后ready之后，再弄一个pod上去灰度检查，最后才是正式上线，这才是能识别到真正问题点的流程。

    大的流程是战略方向，而小的流程才是各个细节技术点的剖析。

    每个人都想做流程，想法是好的，但是大部分到最后执行的时候，都变了味，落伍了。

    5 什么时候需要流程

    很多时候，为了流程而流泪，那么什么时候需要流程？

    当人数达到一定规模的时候，这个时候就需要流程进行统一规范了，毕竟人多了，队伍就不好带了，其实就是不能了解每个人手头上的事情和工作量了，评估工作量还是一件很难的事情。

    如果是人数多了，才会有流程，那么是不是可以不要流程，而是把这个人数多的部门给拆了，就像现在的微服务，微服务之所以出现，就是因为庞大的服务影响的面太大了，从而需要拆分。

    流程多了，一环卡一环，有的时候，流程不是为了做事，而是为了让别人做不成事，这个很关键。。。也是常用套路，小人计谋

    当有很多流程出现的时候，说明业务至少已经进入了成熟期，已经不是那个年轻有为的强势爆发期了，因为开始追求稳健，而不是追求效率了。

    当几个人所在的小组都开始有流程了，说明已经开始进入衰退期了，因为每个人的利益目标都不相同了。

    流程太多，对于一些从0到1，一些创新业务来说是灾难，因为无法快速进行迭代发展。

    6 抛开流程谈目的

    如果把流程抛开，那么是不是可以认为所有的流程出现的目的其实是为了流程的自洽，或者是流程的闭合，就像一件事能控制在自己的组内，那么就无需流程。

    流程多了，冗余繁琐，毫无价值，但是做一件事，有需要快速去做，自己协调，那是不是可以拆分组织，将需要流程的全部拆分到一个组，自己组内进行发布，测试，上线，运维，小团队单产品模式快速运营。

    如果是你，你是选择更多的流程，还是直接把组织架构拆了？

    流程发布之后，需要一视同仁，君不见高层就是随意玩，底层在用流程各种卡卡卡，玩呢。

    流程的执行观察周期是多久，是否能达成目的，不过大部分的汇报也无法观察到真实的情况。

疯言疯语

    听说你在反对这个流程，反对无效，来人，把这个人干掉。。。

    真正好的流程是让人一听，耳目一新，卧槽，我想试试，这个能解决我好多已知的问题。

    傻逼流程基层人人喊打，但是高层喜欢，毕竟管理人的工具谁又不想玩玩呢。。。玩呢，看看效果，看看驯化的程度。

    想成功，先发疯。。。在不合理的流程面前，你是孤注一掷呢？还是？？？

    我家娃看到好看的人跳舞都说。。。站起来，站起来