做为一个IC (Individual Contributor)，我们会根据流程办事。比如说，很多公司规定提交代码之前必须要先发一个code review，有的还规定必须至少两个人要去approve，等等。这些规则就是所谓的Process，用来规范我们的做事方式，减少歧义，也能让缺乏相关经验的人完美的完成任务避免反复的掉进同一个坑里。比如你可能听说过Development Process，Intake Process，Testing Process，Launch Process，Escalation Process等等。
那么这些Process或者规则是谁定的呢？可以是大家共同认可的，也可以是管理层制定的。如果制定得当，那么会让大家事半功倍，做事一步到位；如果制定不得当，那么可能会事倍功半同时大家会在私下里抱怨。比如如果请假的Process是你一个小感冒也要必须大夫亲笔写假条然后还要录个现场开药的视频，这个请假Process可能并不是一个受欢迎的Process。你可能已经有过不好的Process体验，那么怎样才能定义和改革一个Process从而得到正面的反馈就是做为管理者需要做好的事情了。作为想要转到管理层或者新晋的管理者，建立一套Process能让你的团队更快速的发展壮大同时给你更多的时候去做更有意义的事情。
首先，我们要先搞清楚，为什么要有Process？
上一篇文章（Part 2）里提到过我们要定义Vision，这是我们的视野，制定了一个方向。然后我们选择了一系列的Goal，定义了短期和长期要具体完成什么目标来实现我们的Vision。我们同时还有Tenet来帮我们做关键决定，最后有一套Strategy具体讨论如何去完成这些目标和计划。在有了这些之后，我们会进行计划，慢慢进入具体项目的开发和运营。在不断的尝试和总结中，我们会发现，落实到具体化执行的时候，有些状况会经常出现，技术问题大多数情况下有好的解决方案，但是和人相关的问题我们并没有好的办法去解决。比如说，最近上线了一个软件升级但是所有人都没有能够及时发现问题，导致了严重的客户损失。这个问题可能之前也发生过，而且和这次发生的问题的原因都是一样的，但是毕竟人不是机器，每个人都是不同的，并不能开发个软件然后部署到每个人的脑子里。尤其是总会有新人加入旧人离开，无法保证每个人都会学到同样的经验。那么Process存在的意义之一就是要去解决这个问题，尤其是这种经常反复要做的事情（比如软件升级），通过建立一个明确的Process来不断的提升效率的同时降低出错率，也就是达到了事半功倍。
什么样的事情需要Process？
反复在做的事情，对组里或者公司业务有直接影响的，容易出错的，这些事情需要一套Process。比如每个员工每天会吃饭，虽然是反复发生但是并不会影响到业务，所以大家怎么去吃饭并不需要Process。相反，定期会部署新的软件升级，这个只要软件还在开发就无法避免，而且和业务直接挂钩，我们需要一套Process并不能每次换一个人就换一套方式（尤其新人还可能因为缺乏精要而重复犯之前已经犯过的错误）。我们要明确的一点是，并不是所有问题都能靠自动化来解决的，否则我们做为人就没有存在的意义。就算是哪一天我们搞技术的真的全都被AI取代了，那么我们还是要管理这些AI，同样需要一系列的Process。其实归根结底，Process和我们写的程序差别不大，只不过机器可以去执行我们的代码，然而不同人执行同一个Process后的结果可能不同。
如何创建一个好的Process来统一行动？
定义一个Process有多重方式，比如说你入职的时候你的老板定的或者之前公司定好的一系列Process。这种比较成熟的Process在绝大多数情况下不需要我们参与制定，因为这些可能已经经过了很多轮的改善或者有特定的人群在维护和改进，它们的存在都有其最原始想要达到的目的，比如说方便公司管理员工，Code Review，等等。我们这里讨论的是你为了你的团队的发展而创建的量身定做的Proess，暂不讨论更大群组范围内的Process。想当然的来看，作为团队领袖，你可能会有想直接亲自定义Process的想法，这个并非是什么坏事，然而，除非当你能很明确的理解这些问题的同时还能让别人心服口服，我并不建议初入管理岗位或者还没进入管理岗位的人直接去强制执行任何意愿。无论你作为团队的一员还是领导，需要创建一个新的Process的意义是去解决一些重复性的问题。上文提过，这些问题并不是由于机器引起的，而是由人引起的。所以一个好的Process必须能让大家愿意去执行，才会变成习惯。就好比之前“从技术转主管 Part 1”提过的三种Power，如果你只是逼迫别人强制去执行（一级Power，头衔），那可能并不会让人心服口服。相反，如果你能用好你的第三级Power（别人愿意和你合作），那么你建立的Process可能会更有效。我建议最好通过小组讨论投票的方式来决定Process的执行方式，作为管理人员，你可以是发现问题的那个人而并不一定是要提出最佳解决方案的人。在这个时候，作为管理人员，你可以调动组员一起去思考这个问题，咨询一下大家的想法，同时提出自己的想法，看一看几个方案中哪个受大家的认可。虽然有时你可能会发现，最终的结果和你的期望有所不同，不过没有必要马上站出来反驳或者尝试去说服别人，相反，支持大家的想法，把这个作为一个实验，看看下次问题是否还会重复发生。如果问题不再重复发生了，具体Process虽说和你想象的不同，但是目的达到了。如果问题还再重复发生，那么你可以让大家自己总结，为什么这次发生了这个，是Process里缺了什么还是有人没有执行，如果没有执行，为什么没有执行，增加什么样的机制才会避免下次没有执行，等等。多问问题，少提方案，让你的员工或者组员来思考，毕竟他们才是一线亲自经历这些事情的人，他们可能会更了解这个情况。作为一个管理者，你可以引导但是不要强求。不断反复这样做之后，你会发现，下次遇到问题，你的组员自己就开始思考如何避免它的重复发生，你可能间接的培养了他们自己思考怎样建立和改进Process的习惯。
什么才是一个好的Process？
我觉得这篇文章讲得很好，https://www.industryweek.com/operations/continuous-improvement/article/22008150/six-easy-criteria-for-targeting-a-good-process
这里提出了几个方面，简单来说就是[Simple], [Robust], [Documented], [Controlled], [Communicated], and [Error-Proofed]。除此之外，我还需要加上[Enforced]和[Reviewed and Iterated]
先说说推荐文章里说的几条，如果你的Process很复杂，需要人慢慢读慢慢理解，那么这个Process就很难被按照预期的来执行。就好比发射火箭如果要按照顺序按500个按钮的话，这个Process可能就太复杂了，如果能倒数到3,2,1然后按一个按钮，就很容易记住也很容易执行。其次一个好的Process要Robust，也就是说考虑了各种因素，这个和编程其实是一样的，不管你是用If/Else还是用Switch，没考虑到的情况很有可能在Else里或者Default里被错误的处理了。Proess也是一样，如果有情况没有涵盖，那执行者很可能错误的执行或者按照自己的想法来做。人脑不是机器，记忆是不可靠的，依赖记忆不如写下来，或者存起来（Documented），这样下次执行的时候可以无脑的照着流程来做而不用重新思考回忆。Controlled的意思是减少变量和不可靠因素，如果不可靠因素太多，那么这个Process很难每次都取得同样的结果，就好比如果一个Process对空气湿度和温度的依赖很高但是这些因素又经常会变动，那么很难保证执行几次后的结果是相同的。Communicated就不用说了，如果大家都不知道某个Process的存在，那没有人会去执行的。最后Error-Proofed是说这个Process要减少犯错的概率，比如说你的步骤是按顺序执行下面的几个命令，那不如把他们变成一个Script减少执行的步骤。
那么除此之外，我需要加的两点是一定要有办法是Enforce你们组Process的执行力。虽然说Process的存在是解决人为的、自动化无法解决的问题，但是我们可以利用自动化来Enforce一个Process的执行。比如说，假设你们有一套Process说项目上线之前所有代码都要经过code review。这个意图是很好的，但是很不巧，经常没有被执行因为总有那么几个漏网之鱼。你的Process定义的是何时去code review，code review哪些commit，这个很难去自动化因为code review这件事需要人去做而不能完全依赖机器。不过，enforce code review倒是可以，比如你有个script自动查所有下一步要上线的所有commit，自动生成一个dashboard，每天晨会的时候你们就会自己发现还剩多少代码没有经过code review。这个办法去Enforce就比专门找个人天天盯着或者你亲自去一个一个查效率高得多。那么另外一点，就是一个Process一定要定期的去Review和Iterate。就和软件一样，代码写完了当时是好用的，但是随着时间的推移和业务的变化，尤其是人员的变动，之前好用的套路现在并不一定好用。所以定期的去观察和分析这套Process在现在这个环境下是否还是有效的，如果没有，如何去改进它？
下篇预告 - 从技术转主管 - Part 4 - 培养一个Tech Lead
