工作流程盘点 | 前端人的认知升级

1,883 阅读5分钟

近期的工作很忙乱,忙里偷闲把工作流程上的一些纰漏,做一个总结。

需求评审

重视每一次需求评审。

充分理解需求单,并结合实际业务去判断是否有遗漏的点,有的话,及时让产品补上需求。

对需求单上的每一个点都要能cover住,能以产品的角度或者开发的角度提出建设性意见更佳。面对需求,如果遇到有疑惑的点一定要及时抛出来,当面对齐;如果遇到知识盲区的点,一定要有调研,在调研结果出来之后,再一次进入需求终审。

需求评审阶段,是第一次能够以合理的诉求改需求的地方。这对后续的写技术方案阶段很有帮助。

技术方案

正常的流程中,是一定要有技术方案的。对于那些紧急需求除外,比如老板给你提要两天完成,你判断要三天,那能怎么办,加班或者寻求更多的资源支持。

为什么说要技术方案呢?首先技术方案是一个需求中最有技术含量的东西,敲代码只是整个需求交付的流程中,占很小的一部分。其次,技术方案写完,还可以找产品再继续对齐一下,看方案要完成的东西符不符合产品的预期,或者通过调研后得出合理的技术方案,还能再PK一下需求,这时候还能够再次更改需求,这是对能否按期交付需求的保障。最后技术方案还能做一个沉淀,做完需求回过头来看哪里做的好不好,为下次需求做积累,而且有技术文档,能更方便的做工作交接。

技术方案的好坏,可以看这三方面。

  1. 它是否能够通过开发的角度去描述清楚这个需求到底要做什么,抛开需求单,让有相同技术栈的人通过技术方案,能不能也能轻易开发出来;
  2. 对于需求中的重点和难点,能不能通过调研后的结果,把实现方案给呈现出来,为了后期能够有个参照,避免实现遗漏;
  3. 一般调研后的实现方案可能会有多种,能不能列出其中的优缺点,思考的多了,才能够让技术沉淀进步。

知识盲区

首先可以去问同事,如果同事刚好知道,那就可以省去调研的时间,如果不知道,那就再去调研学习相关知识,如果实在是解决不了,可以及时抛出来,向外面的部门寻求帮助。

其实这个阶段是知识积累的时候,遇到不懂的,事后一定要及时去填补,这是属于重要的事情。

排期估时

估时一定要估好,这是技术活,请认真对待。

估的多了,容易被挑战,估的少了,有不能按时完成的风险。在合理的诉求下,一定要留有估时buff,比如 开发估时 * 0.2,人总有那么几天不想上班的时候,对吧。

开发阶段

好好的code,遵守规范,封装组件,提炼工具函数,下一次需求来的时候,就能愉快的复用。

如果在开发中,才意识到需求不合理的地方,还能做最后一次需求pk,如果到了后面的流程,则不太可能更改了。

如果遇到一些事情,阻塞了开发进度,一定要在工作群中及时抛出来,说明原因,请求延长排期,这点很重要。不然后面不能按期完成,就会吃哑巴亏。

体验提测阶段

提测前,一定要充分自测。自己主流程一定要跑一遍,要多考虑边界条件;还有作为前端开发,样式上的实现,一定是像素级别的。

这时候是不能更改需求了。对提出的问题一定要及时跟进。假如万一真出现太多问题,导致流程无法继续,一定要及时中断,等把问题都修复,自测通过了,再一次去提测。

其实如果前面的几个阶段都能做好,是不会出现这种回炉再造的情况。请记住,测试只能保证代码的下限,完成技术方案才能提高代码的上限

关于开发过程中的需求变更

如果是合理的需求变更,比如不改,会导致线上问题,那一定要去改,但有一个前提就是,改了需求后,要对整体的估时排期做一个调整,并在工作群中及时同步因为更改需求而调整排期,如果不改,上线后的表现影响到用户的体验,则会受到批评。

改需求一定是会对开发有影响的,大则是整体技术架构推倒重来,小则是排期延长。

如果是加需求,那不好意思,提需求单,下期优化再见。

工作push

当面交流其实是高效的方式,如果人多,则可以拉一个会议室碰一下。

作为一个前端开发,肯定是想着视觉稿赶紧出,后端接口赶紧给。

而对于产品或者leader,给的一个需求,肯定是要知道大概什么时候能够完成,有什么风险,有什么解决方案,而不是给了需求之后,收不到任何反馈。

提升

当hold住了一个大需求,那么会有越来越多的需求找到你。提升(年终奖)也就指日可待了。


以上。

但愿每一个加班,都能够被温柔以待。