整个研发流程的研发效能很重要，好的研发性能能很大程度提升研发同学的幸福感，更能有助于减少需求线上的问题。

整个研发流程：

那么我们的效能问题会出现在哪些环节呢？

大的划分我们可以看到几个大的环节：

一、开发前

二、开发中

三、测试

四、上线

需求设计出来后，会进入一个大的需求池，很多需求不可能每个需求都有人马上支持，因此产品会对需求排优先级，根据释放人力排出高优需求

那么第一个问题出来了，就是需求优先级不确定或者说本来确定了，结果突然强插其他高优需求，还有一点就是可能这个需求在依赖方处的优先级不确定或者和依赖方沟通没有达成一致

比如说团队A和团队B今天都给团队C提了个高优需求，团队C认为团队B的需求更高优且当前人力只够支持团队B的需求，A的需求就会被搁置往后排，这个需求到这里就算夭折了，这个问题越早暴露越好，就怕等开始开发了才发现其他合作方人力没法及时投入，拉长整个需求的排期，甚至需求搁置暂停。

然后需求会现在大范围做第一次粗评，主要看的是合理性、可行性、优先级等问题，然后就拉小群在小范围内详评，详评期间就会确定各方的对接人

那么就会有另一个问题，也是大家最常遇到的，需求文档质量问题、需求本身的质量问题，先拿需求文档来说，长篇大论，可能仅仅几行才是有用的，再比如一句话需求，一句话概括了需求了，说了又好像没说一样。。。还有一种，遇到一些不直接写出来要做成什么样子，而是写“参考线上逻辑、参考xxx需求的做法”，这个其实也挺坑的 =-=还有另一种是某些点没有确定，就在文档写个TODO或者写个待情定～

然后再说需求本身质量问题，你也不想做一个上线完没有任何收益的需求吧，甚至会有损大盘，或者说成本远远大于收益，比如说一堆人吭哧吭哧干了几个月，用了很多服务器，跑了很多服务，实际收益增长很少，后续直接需求下线。。。所以需求的质量真的很重要，远远大于数量，并不是一个量变到质变的过程。

这些问题当然不是说产品同学不行，只是会存在这样的问题哈。

还有一个贯穿在整个研发流程中的问题，就是需求变更问题。。。

需求变更其实存在2种一个就是很重要很紧急的变更，一个就是无关痛痒的变更，然而很多产品同学往往衡量不好

有什么新的就变更需求，这样会对研发造成很大的负担。

然后就是方案设计、接口协议设计等，外部交互一定要拉会和合作方对清楚，需求方案也要在组内做评审，避免返工，或者造成线上其他问题。

之前就是给出最终排期表，这个也是问题，一般为了赶上线时间，会压缩排期，开发时间工作量摆在那里不好压缩，一般就压缩联调和测试时间，这样其实对需求的质量有一定的冲击，特别是大需求更是要充分联调和提测才行。

还有一种场景就是需求刚出就想要给出排期，往往这个时候一些需求的细节还没有沟通清楚，方案细节也没设计，此时给出的排期一般都不准确，有较大偏差，反而影响需求的交付。

而且越大的需求，反而在开发前更要留够需求沟通、方案设计、排期沟通的时间。

进入到开发就是实现每一个功能模块，在联调前部署测试环境，做一些自测，开发中遇到最大的问题一般是Code Review的质量和速度，Code Review的重要性在这里就不做强调了

一般随着团队扩张、业务紧急，code review的质量就没有那么高了，一来人多code reveiw看不过来，二来新人多代码风格没有对齐。

还有一种问题就是工期紧，没充足时间做review，这个时候一般需要做排期还是留一些buffer处理一些其他事情

还有一种场景就是提code review的代码行数太多，又大、又杂、又乱，根本看不过来

如果在MR里看代码，少则几个文件，多则变更上百个文件，也看不过来，完全依靠测试

所以还是需要在code review 阶段小步快走，每次提cr，量要小点， 尽量清楚，适当做一些注释，想办法减轻帮你看代码人的负担。

开发阶段一般来说也包含自测，自测一般就要看我们的devops平台的易用性、测试环境的易用性，还有一些工具什么的使用体验上有啥问题没

然后就是联调，联调其实还好，多方一起联调，修复一些bug

但是这里要强调的就是需求一定留够自测联调时间，这样才能保证后续的提测质量

如果提测质量没有保证，就会在测试阶段发大量精力修bug, 甚至会出现进入到下一个需求后还会被上一个需求线上问题所影响，连锁反应。。。

拆东墙补西墙，实际上就进入一个不健康的状态了。

需求前期的开发自测联调做好了，其实后期需求提测后就整体会轻松不少

测试期间也会有2个比较明显的问题：

一个就是前期的工作没做好，测试期间不停修bug -> 提测质量问题

另一个就是测试的质量没有保证，测试同学漏掉一些场景和测试点 -> 测试质量问题

最后就到上线阶段了

上线checklist

需要提前写好上线步骤，需要变更的开关、配置、服务等

上线有没有依赖关系、有什么顺序没有等

checklist 一般需要人工维护，就会出现一个问题，比如配置漏更新了，服务漏上线了。

然后上线工作完成后，需要添加白名单做线上回测

线上回测是最后一道保证，马虎不得，要验证监控、打点、日志、线上存储、接口请求相应等

充足的线上验证后就到了放量环节，一般来说产品为了快速看到效果得到结果，会催着放量

但研发需要坚守原则，以稳定性优先，在线上缓慢放量，慢慢的最终全量。

最后我们讨论几个问题哈。

部分提测的利与弊？

还有一种mock联调测试，等客户端封板后服务端再做具体实现

优点就是比较快

缺点就是服务端要额外开发一些mock逻辑，后续有一些变更和出现什么问题，客户端都已经封板了没法改了。。。

人员在什么阶段释放呢？联调？测试？上线完？需求放量？

就像我们一般想充分压榨CPU性能一样，我们的人力也会考虑做充分压榨，不然需求的交付速度跟不上

一般来说我们会在一个需求快要结束前投入下一个需求

目前的话遇到2种，测试期间投入一半人力到下一个需求的方案设计，

一个就是等需求上线完后再投入到下一个需求。

我觉得都🉑，主要还是看需求的大小和复杂程度，较大需求最好要在上完线后再去跟其他需求更稳妥点。

需求并行对开发人员负担会比较重，容易出问题。

我个人觉得下一个需求的介入时机最好在上一个需求的测试后期或者上线完了。

因为充足的联调时间能够保证提测质量

充分的测试时间可以修正一些bug，越复杂的需求bug数会越多

不过一些中小型需求在前期自测联调的保证了提测质量，测试期间没什么bug, 介入到下一个需求倒也ok。

总之，人是活的，规则和流程是死的，开发中要及时同步问题，不要报喜不报忧，以健康的状态去迭代和高质量交付每一个需求，才能更长远的提升研发的幸福感！

转载请注明：汪明鑫的个人博客 » 研发效能—提升研发幸福感