从去年九月实行了新的研发制度以后，研发部门变得诡异起来，从立项到开发到上线，再到线上故障处理，这一整套的流程整下来，脑门上不多几根白头发我是不信的。这些个过程往往会产生很多需要对齐的事情,,在对齐的过程中充满了质疑,和挑战,为了一些没有意义的问题花费了巨大的精力,搞得大家痛苦不堪，甚至出现了摆烂，宁愿离职也不愿意干下去的情况，要知道在2025年的今天，在找工作比啥都难的日子里，有勇气提离职而不愿意搞这堆流程，可以看出来这个流程对大家的折磨有多深。

1.立项流程

立项是干活的第一步，当需求被提出，在完整的prd出来前，我们要把任务拆分出来，然后把每个人的工时填上去，接着就是拉研发负责人过立项材料，研发负责人过完以后在拉部门总监过，这其中的过程犹如李鸿章在马关条约的签订会议上，受尽质疑和不满，简直对我们就是摧残。
质疑的话题一个是工时为什么需要这么久？面对这种话题后来我们也学聪明了，任务拆分的很细，细到0.2天一个任务，其中还表明每一个任务需要做哪些事情，所以早期的立项材料，写的内容巨多，很花费时间。后来评审了几次后，又说我们拆的太细了，看着费劲，要求我们工时不能出现小数，在工时上面我们改了，最小粒度为1天，但是为了防止被质疑为啥这么久，我们还是会在备注中把任务需要做哪些事情写的很清楚。
另外一个质疑的话题就是立项材料格式不对，比如你为啥不画架构图？画了架构图问你为什么没有数据流向图？为啥这个材料最上面没有汇总研发人员的总工时？研发材料为啥没有其他部门，如安全，运维部门的确认？实际在评审前，我们并没有一个标准的评审材料，全都是写完后大家看下差不多就去评审，并不知道老板们想要看什么,老板们也从来没有告诉我们,一个立项材料里面有什么,没有什么,所以挑战就来源于老板的心情，老板心情好，不多说啥，老板心情不好就一票否决，否决完后，赶紧针对老板的质疑进行变更，变更完后再拉老板评审，来来回回，一个大的需求很有可能要评审三四次才能通过。
如果是一个大项目在开发前需要做这些流程，也就罢了，一个很小的迭代也需要走这种流程，小到一个线上的bug，都需要去写一个立项材料，约大佬们过下，当然后面也就出现了，我们开发我们的，立项过立项的，两不相干的局面。
刚刚讲立项里面划分了任务，当开发过程中，发现立项任务里面缺了某一个功能，比如说在某一个节点需要发一个mq通知别的域，开发的同学可以拒绝开发这个发送功能，为啥呢？因为在立项里面并没有这个任务，所以你想让他开发，就必须走立项变更流程，也就是把变更的内容加上去，在拉大佬们评审一次。
立项的本质其实就是确定同学们的工时，比如我这个需求，A做了3天，立项完了以后，会被录到工时系统中，记录了3.1-3.4号，A有三天的活。当有另外一个新需求缺人的时候，大佬们就可以在工时系统中，查看哪些没有活干的同学可以有幸被翻到牌子，去做新的需求。这个同学甚至可以不用知道项目在哪，项目以前的代码逻辑是啥，反正是拉过去做需求就对了，那同学是怎么写代码的呢？我们把问题留到下一章。

2. 研发流程

立完项以后，我们需要将这次需求建一个epic，接着将立项材料的任务在jira上创建任务，同学在提交代码的时候需要明确将自己做的哪一个任务id提交到git上面去，如果没有提交，或者写的任务id不对，那就完犊子，因为在发布的时候，需要填写需求的epic，cd平台可以根据epic，拉取所有的任务id，在和commit message里面的任务id进行对比，如果commit message里面多了任务id或者少了任务id，是不允许发布的，这种情况下，只有两条路可走，一条是做force push，脑袋正常的都不会在这个发布前做force push，另外一条就是走点检审批流程。
所谓的点检审批其实就是一个bpm流程，这个流程主要就是说明为啥需要点检通过，比如合错代码？多提了不该提的任务id？反正就是一通解释，下面就是无尽的审批，研发负责人审批，然后运维负责人审批，最后是研发总监审批，为啥研发总监老是需要他审批？因为他是我们研发部门最大的领导了，可以理解他就是cto，只不过我们公司没有cto这个岗位。这个过程会伴随着各个负责人无尽的质疑，无尽的解释，总之反正就是一句话，你得证明你提交的代码没有问题，是对的，上线不会出问题，这个证明不是你空口说是就是，你需要拉齐架构师做code review，拉齐测试给出测试报告，最好在拉齐提交代码的人，把有问题的commit找出来，一个一个得过下，再给个材料，给大佬们审批，如果最后还是没过，自己想办法把。
说完点检，我们刚刚在立项里面还遗漏了一个问题，就是该同学没有写过这个项目，该如何协作呢？这个时候有一个角色就出场了，架构师，架构师需要去梳理上下游的交互，定义出所有的接口，甚至是实现部分核心功能，再和干活的同学拉齐，你这么干这么干,不能偏离架构师的设想，因为最后上线做code review的时候，架构师发现你没按照他设想的去写，擅自加了一些字段没和他同步或者改了接口的定义，架构师是可以不通过code review，不允许上线的。
那有没有架构师翻车的情况呢?太多了，架构师是不写代码的，他们只做设计，他们离需求十万八千里，更不谈离业务了，很多人设计出来的东西都是有问题的，那架构师设计出来的东西如何保证呢？这个时候架构师委员会出来了，架构师委员会成员们会去讨论设计的合理不合理，很多架构师对于评审的需求也是第一次听说，能评审啥呢？另外架构师的水平大都比较水，他们绝大多数人只是年龄大点，并没有很高超的水平，在加上多年不写代码，所以他们讨论的重点往往就是命名规范上面，或者使用了一个不该用的类库，或者争吵这个需求归属于哪一个域来开发的问题等等。对于需求本身他们讨论不出来啥，这就导致部分水货的架构师，设计出来的东西上线了难以维护，而且还不是一次出现这样的事情，是多次。
在立项材料里面，我们规定了开发时间，测试时间，上线时间，同学开发完成后，就按照流程提测，提测完的同学，又会被新的需求拉走，干新的活，所以一个同学手上忙着好几个需求是常有的事情。下面就是测试同学的时间了，提bug，修bug，老一套流程不讲了，讲一个上线前的小插曲，异常流程验证。
所谓异常验证流程，就是当测试提出了一个短期内无法修复的bug，（比如测试环境拉起收银台唤醒时间超过五秒）能够走到这一步的bug，都比较难修复，不是说技术水平不足，有可能是需要拉齐多方人员来协作你去干这个事情，而我刚刚说了，同学们干活是需要被立项的，是需要给同学工时的，那谁愿意给你白打工呢?除此之外，有的bug解决不是需要一天两天，甚至是需要一个迭代规划做这个事情，根本不可能去很快的修复，另外还有一些bug，测试都无法复现，研发都看了干瞪眼，不知道咋修复，这类诡异的bug，都需要走一个流程叫做异常验证流程。
刚刚讲了什么是异常验证流程，那这个咋走呢？同样的是bpm流程，研发负责人审批，接着运维负责人审批，接着部门总监审批，刚刚解释了部门总监为啥老是审批，这次解释下为啥运维负责人老是审批，因为测试团队和后面介绍的一个sqa团队在他下面，他需要对交付物负责。这个流程是我最不想走的，因为很多bug在我们眼里无法解决的东西，在他们眼里不会关心why，只关心今天能不能解决，其实想想也对，我们换个角度，你是老板，有个同学和你说，今天的上线，可能会出现某某某问题，你什么想法，第一想法必然是，解决他，而正因为它短期内无法解决，所以对这个流程我深恶痛绝。当然除了解决它，还有另外一条思路，就是让业务认可你的交付物有问题，也就是需要产品和业务沟通，和业务说我们的本次上线有问题，最后把他们聊天记录贴到流程里面，一旦业务说知道了类似的话，大佬们批准得比谁都快。

3.上线流程

终于到了最后一步了，就是上线，刚刚讲了在立项的时候，需要创建epic，epic是一系列任务的集合，在真正上线前，我们需要将研发的整个流程里面产生的文件上传到epic里面。这个文件包括，需求评审报告，show case报告，架构设计报告，code review报告，异常流程报告（也就是上面一堆bpm的截图），自测报告，stg验收邮件，发布评审报告，测试报告，回归报告，性能测试报告。所谓报告就是一个word，里面记录了当时发生的一些事情，比如评审报告，需要记录哪些人在上面时候参与了评审，评审的内容是什么，在文件最下面，谁谁谁同意研发，当然这里面很多文件因为记录得太细，导致具有不可实施性，到最后都随便整两句就传上去得了。
那能不能不传报告呢？不能，这里就要介绍另外一个角色，就是SQA,他们是整套上线流程得设计者及参与者，发布评审得时候必须要拉上sqa，sqa会依次检查epic里面得文件少不少，但是对于文件内容他们是不看得，只看有没有提交。
接着就是发布评审环节了，发布评审报告里面需要记录今天发布哪几个项目，版本号是多少，code review是谁做得，架构师设计是谁做得，等等，发布评审报告里面可以理解为将一些重要得报告又说了一遍，突出了一个冗余就是重要得特性。在经过sqa细致检查不缺文件后，可以走发布申请了。
发布申请就是在cd平台上面，提发布申请单，需要将需求得epic贴进去，cd不仅会去校验commit msg任务id对不对，还会去校验上面需求评审报告，自测报告等报告有没有漏，防止sqa看走眼。提完申请单后，经过一系列的审批，终于到了发布过程，发布完以后，需要验收的就让业务验收，无法验收需要产品在发布前走无法验收流程。
有的同学可能会疑惑，为啥生产当天无法验收?抛开非常规的业务需求的上线，如bug修复，没有业务配合外，正常的业务需求，他也不是上线当天就要用的，有可能是下个星期才会打开这个功能，你让业务当天发验收邮件，他确实没办法，有点不讲理了属于是。
无法验收流程和刚刚讲的流程多了一个产品负责人审批，也就是产品负责人审批，研发负责人审批，运维负责人审批，最后是研发总监审批。这个审批相对来说比较简单，只要说明为啥无法验收，以及何时验收就好。在到了约定期，比如上线十天，当时业务回复说验收的，到期后没有发出验收邮件，这个时候sqa会去催产品，让产品催业务发验收邮件，主打一个守信。

4.复盘流程

说到复盘流程真是的是所有流程最可怕的，上面的流程只要你不出幺蛾子，不需要走那些类似点检的流程，都是花点时间一个人就能搞定的，而复盘流程，是需要你拉齐一堆人，在那讨论一堆没有意义的问题，最后得出一些可笑的结果，甚至会议还不能达成一致，需要多次拉齐，需要上升到部门总监参与进来，一次复盘就像是犹太人在奥斯维辛集中营走了一遭一样，完全是要命的节奏。
首先说明下复盘流程是咋来的，就是大概有三十个人组成的值班群里面，每天轮值一个，会有其他产品同学或者业务运营同学上报一些线上问题，值班的同学首先要去找到对应的人，解决问题，接着就是开始对问题的复盘。
首先明确一点，无论什么问题都需要复盘，这是大家讨厌这个流程的原因，比如数据库的一次抖动，导致部分用户报错，有人上报了，这个问题正常人看了以后，解释下，就没了，但是这里不行,必须要复盘，防止同类问题再次发生，正所谓用户事件无小事。
在复盘前，需要拉齐产生故障同学，写一篇复盘报告，记录了什么时间发生了什么，怎么解决的，问题的直接原因是啥，根本原因是啥，如何给出一个长期的解决方案，写完这一套基本两三个小时就过去了，值班经理往往不知道发生故障团队事情的细节，需要对方来写，上面的流水账还好写，但是这个直接原因，根本原因，还有长期方案咋写呢？就比如刚刚说的那个网络抖动了下，数据库哆嗦了下，写啥呢？直接原因，网络抖动?根本原因是系统无法应对突发情况，未进行合理降级？那长期解决方案呢?写出来以后，在正式复盘，同样也会被大佬们质疑，他觉得你思考的不够深刻，没思考出问题的关键，一次网络抖动能思考出啥呢？你让他说，他也说不出个所以然出来，所以这个东西不好写。复盘报告写好后，就要约同学们开复盘会，根本故障等级不同，拉的人也不同，p2小打小闹，自己玩去吧，p1就要开始拉大佬们了，p0就不得了，就要拉部门总监了。
对于故障的响应，同样也有一些应对措施，比如5分钟没响应，这个时候部门总监就要在群里开始批评值班经理，未及时响应故障，要好好反思，如果十分钟没响应，那完犊子，至少得有四五个人给值班经理打电话，提醒他看下群里，赶紧处理下。
好了，回归复盘会上，复盘会上会去真正的确定故障的等级，因为并不是所有的故障都是那么好运，能被总监直接命中定义为p0，这个时候sqa就需要掏出他的老表，哪个系统的，影响多少人，时间多久，定什么级别，大家对于故障定级到不会产生太多的争执，往往有争执的是故障的负责人，也就是谁来背这个锅，这个就扯的很，有的时候问题是A导致的，但是原因是B，B说你A为啥不做好异常处理，这种锅背不好的话，或者没人肯认，就要上升，那就是需要另外一个会议，拉齐大佬们定夺。
说到这，大家可能都好奇，定级是不是影响绩效？其实说来好笑，定级就和过家家一样，啥也不影响，你就是拿一个p0，也不会影响你的年终和工资，所以在开通我就讲了讨论一堆没有意义的问题，一场自嗨罢了。
接着就是过直接愿意和根本原因，考验大家反思得深刻不深刻的时候到了，反思不深刻，那就先回去再反思反思，等深刻了再约会，再次讨论，当然这个是大佬们参加的复盘会议才这样，小故障通常就直接整两句走个流程得了。
最后就是改进技术，直接改进计划是什么，比如修了一版发上去，长期改进计划是上面？一听长期，听着就是要拉齐很多人做事情，还需要给个明确的时间，上面时候长期解决计划上线，sqa到期后会去检查有没有上线，主打一个守信。
对于小的故障，就到此结束了，对于其他故障，还需要和大佬们在过一波，大佬们当然会对这种事情有疑问，就看值班经理控场能力了，控的不好，直接散会，在拉小兄弟们解决大佬会上的疑问，接着在拉大佬们，在去过复盘，反正来来回回，有的一个屁大的事情，得搞四五个会议才能结束。
有的同学可能有疑问了，那小故障或者不重要的故障，我不复盘不就完了吗？哈哈哈，还是太天真了，刚刚说有一个岗位叫sqa，他会在故障发生后，第一时间给值班经理发复盘报告的文档，让值班经理写复盘报告，写完后，sqa会催着值班经理去复盘。
说到这，说实话我眼泪快下来了，有一次我值班，那天晚上我要发版，还要走一堆发布流程，恰好，他妈的，线上那天报了两个故障，给我那天累的不行。

5.刷数据流程

当线上有出现bug,或者异常流程的时候,通常需要刷数据,这个时候就产生了刷数据流程。
刷数据流程分为两种情况,一种是业务的异常流程,比如说产品功能不能满足业务的需求,或者业务没有按照产品的设计使用而产生了一些需要手动修复的数据,这种情况需要业务发起邮件,由业务总监审批后,将邮件扭转至产品,产品发起刷数据流程,第一步审批的是产品的负责人,描述清楚为啥需要改数据,产品负责人通常的回复是需要支持业务,下一步就是到了开发这边,开发将需要处理的sql贴进邮件,再下一步由技术负责人审批,技术负责人回复ok后,还需要部门总监审批,当然这个过程也会充满质疑,质疑无外乎为什么功能不支持业务?什么时候可以支持业务?甚至还需要拉会去解释这个事情本身是否具有合理性。等大佬们的疑问打消,回复同意后,开发将sql贴进db平台,再把审批邮件截图贴进去,dba审批通过,执行完成就可以了,这一套流程走完没个半天是搞不定的,所以啊,业务的哥姐们,不是我们不能快速响应啊,你催我们也没用啊,大佬们每天忙于各种审批,实在是响应不起来啊。
另外一种是系统bug导致的数据,这种数据让业务发起也不太合理,就由产品发起,描述清楚,什么bug导致的,刷什么数据,后面的流程和业务发起的一致。

说到最后,有的同学,可能好奇,到底是得了多少年的脑血栓才能想出来这些流程。这些流程得来源归根到底还是我们的反思能力太强了,都是日常开发出来遇到的问题,将它反思后搞出来的。举一个例子,为啥发布的时候要提一堆需求评审报告?因为当时有一个开发做的功能不符合产品需求,被产品投诉了。针对此类问题,所以就要求开发,必须要真实还原当时需求的样子,要溯源,所以需要记录需求评审报告，越详细越好，方便后期翻旧账看到底是不是按照产品要求做的，如果可以最好把邮件和聊天记录也贴进去。再比如为啥要有工时?因为少部分团队出现工时乱报的现象，两天的活给产品报了五天，也被产品投诉了。所以你看,将特例普遍化带来的后果就是折腾,出现了问题,不去解决真正的问题,而是通过流程去限制大家,不得不说,管理的高手想法和我们这些小卡拉米确实不一样，一个字，服。