一线大厂:从需求提出到上线流程总结(一)

产品的技术小课

共 3586字,需浏览 8分钟

 ·

2021-08-13 01:40

在一线大厂,从需求提出到上线,整个流程是怎样的?笔者结合腾讯的工作流和调研了阿里、字节等公司的项目开发流程,发现大厂的工作流大同小异,总结了如下的整体流程图。


下面将按照这个流程的每个节点,详细阐述。全文3000多字,阅读大概需要6分钟~

目录

1、需求阶段

2、开发阶段

3、测试阶段

4、发布阶段

5、监控阶段

6、总结

1、需求阶段

1.1 原型评审

需求提出后,产品一般会带着原型图,拉开发、数据、设计一起开需求评审会。

在这个会议中,大家如果对需求有什么建议/意见都可以提出,如果需求实现不了、改动很大没法向前兼容、开发周期长等问题都可以在这个会议中抛出来,产品会做出相应的调整。

1.2 交互设计评审

大家对原型图都没有什么异议之后,就进入下一流程了。当设计出了设计稿之后,就拉着产品、前端一起评审交互设计稿。

这个评审会主要是看以下几个方面:

(1) 交互设计稿跟产品逻辑有没有一个比较大的出入;

(2) 组件风格跟整体风格是否统一

(3) 在有产品上线有规定时间的条件下,UI还原复杂度如果占用开发时间比较长的话,会考虑让设计协调一个降级的方案。(比如复用以前的功能类似组件)

2、开发阶段

2.1 概要设计&排期

交互设计评审完之后,开发就可以开始排期了。(前端同学要到这个阶段才开始排期,但是后台、数据的同学一般原型评审完后就可以排期了)

开发是如何排期的呢?一般来说,一个需求开发出来到底需要多少时间,这个是不能百分之百准确评估的,因为有很多情况你没发预料,

比如线上出现bug,这个bug你可能要花一天的时间才能找到并修复,

再比如在你开发过程中,遇到一个难题,要花时间做调研等等。

所以开发排期一般都会留给自己一些buff(缓冲时间)。

要评估一个需求开发完需要花费多少时间,一般我们会先做一个概要设计,啥是概要设计?

概要设计就是实现这个需求的一个大概方案。一般会考虑以下几点:

(1) 考虑依赖

需求要实现依赖了哪些服务,包括第三方和我们自己的服务。

如果需要依赖第三方服务,需要调用第三方接口的话,可能还要去阅读第三方服务的接口文档和调用方式,也是需要一定的工作量的。

(2) 考虑复用

需求依赖的接口是否能复用,前端的组件是否能复用。如果组件可以复用的话,开发工作量是可以减少的。

(3) 考虑兼容性

需求实现之后,对已经存在的数据是否有冲突?对现有的功能是否有冲突?

比如说一个平台,以前用户的昵称是可以重复的,但最近产品提了一个需求是用户昵称不能重复,那么开发就需要对以前的用户昵称数据做一个修复,这也是一个工作量。

(4) 考虑技术盲点

如果遇到了不了解的技术盲点,可以申请一个调研的时间。因为技术选型也是需要调研和做竞品分析的 ,要找到最适合自己业务的技术选型。

概要设计一般会使用xmind等工具来把每一个功能涉及到的服务及影响写出来。

同时,概要设计也会给到测试同学,测试同学会根据你的概要设计,评估影响范围,新增、改动的接口有哪些,可以更全面的去写测试用例。

2.2 测试用例评审

这个环节测试同学会把测试用例拿出来评审,这时开发可以评估是否合理,或者有哪些点没有考虑到,都可以提出来。

2.3 接口定义与开发

如果这次需求涉及到新增、更改接口,是需要后端先定义一个接口协议的。比如一个查询订单的接口,需要提供哪些字段查询,返回的数据结构是怎样的。

后端提前定义好协议之后前端开发起来就顺畅很多了,因为数据结构已经都清楚了。

接下来开发们就开始写代码了。

2.4 开发自测

开发自测一般会在开发过程中完成。一般会做单元测试,性能测试等,根据具体需求而定。

对于前端,因为后台可能接口还没开发完成,但是这时又需要后台接口来测试,那怎么办呢?

我们一般会使用mock服务,mock就是模拟接口返回的服务。这样就可以大大提高了开发效率。

2.5 联调

当前后端都开发完,就开始联调啦。联调就是前端正式调用后台发布到测试环境的接口。这个阶段可能会出现后台漏字段、字段名变更、接口返回异常等问题。

在排期时联调也是需要把时间算进去的。

3、测试阶段

3.1 静态扫描

前后端联调完之后,就可以把代码发布到测试环境啦。测试环境是公司内网才可以访问的环境。在发布到测试环境之前,会自动触发一个工具的静态扫描。

静态扫描是啥呢?其实就是一个检测你的代码的工具。

一般会检查代码是否符合规范、代码是否有安全漏洞、依赖的第三方库是否安全等等,如果扫描过程中出现问题,会直接通知你,让你改进。

3.2 提测

代码发布到测试环境后,测试同学就开始测试啦。遇到什么bug的话,就会在需求管理平台给开发提bug单,开发收到之后就去解决。

这个阶段的周期看开发的质量和需求的大小。

3.3 产品第一次体验

bug都修复完之后,产品就开始在测试环境进行产品的第一次体验啦。

体验阶段,产品找出了bug,或者实现与需求有出入的地方都可以提给开发。

对于有设计稿的需求,设计这时也会参与进来走查还原度的问题。

产品&设计验收ok后,需求就可以发布到预发布环境体验真实的场景啦。

3.4 预发布环境体验

什么是预发布环境?预发布环境是为了模拟线上真实环境的体验环境,它跟线上环境唯一的区别是网址不同,其他的都一致。

为什么要有这么个环节呢?原因主要有2个:

一是线上数据与测试环境数据不同,想用线上数据做一些测试。二是为保证万无一失,看看新功能增加后,在线上环境会不会暴露出一些隐藏问题。

这个阶段不是必须的。还是具体情况具体分析。

4、发布阶段

4.1 制定发布计划

一般上线前,后台会找到相关的开发同学,制定一个发布计划。

因为当一个产品强大起来之后,它依赖的服务是非常多的,会涉及到一个发布顺序和对线上服务不可用的问题。

如果发布的是一个产品大版本,对线上完全不兼容,在服务发布时,如果线上有用户在使用,可能会导致操作失败或者引入脏数据。这都是我们不想要的结果。

对于这种情况,一般会采用2种方案,一种是暂时关闭线上服务,提示服务升级中。还有一种是关闭数据库的写操作,提示用户稍后重试。

4.2 灰度/全量发布

如果产品没有要求的话,默认使用全量发布,即对所有用户开放。

什么情况下会使用灰度发布?

(1) 降低发布带来的影响

虽然功能都在测试环境测过,但毕竟没有发布到生产环境,如果先让少部分用户先使用新版本,提前发现bug,或者性能问题,提前做好修复,就可以降低新版本带来的影响。

(2) 通过对新老版本的对比,观察新版本带来的效果。

具体的灰度发布细节可以看我以前写的这篇文章:大厂常用的几种灰度发布方案

4.3 产品第二次验收

当服务都发完后,产品需要到线上体验下新功能,看看有没有什么问题,保证万无一失。产品第二次验收完成后这个需求就算是完成了。

5、监控阶段

5.1 埋点统计

产品为了查看功能的使用情况,比如页面停留时长、点击量、访问量等,前端一般都会做埋点统计。

5.2 错误日志监控&性能监控

为了保证线上的稳定性,前端、后台都会接入错误日志上报,比如接口返回出错1分钟内次数达到10次,那就会给开发通知告警。

性能监控主要是为了保证服务的可用性。比如服务内存、cpu占用过大,或者某个接口在1秒内调用频率超过了限制,都会有告警。

6、总结

到这里就讲完了,可能有的小伙伴会觉得这个过程很长很复杂,有点小题大做了,有些节点没必要。

当然如果对于一些小需求,小改动有些环节是可以省去的。但是对于常规的需求,都这样规范起来的话,可以保证开发效率和产品质量。

我们可以看到一个需求从开发到上线涉及到了需求管理、代码管理、版本管理、发布管理、人员通知等关键节点,

在上古时期,这些节点之间是割裂的,没有一个工具或者平台可以把他们串起来,比如需求和代码的关联,代码和发布版本的关联。

而且,这些节点很多都可以用自动化工具来管理起来,比如当开发提交代码到测试分支后自动发布,自动通知产品验收。

在自动化方面,一般大公司都有相应的工具/平台来管理,后面的文章将会讲到自动化管理项目方面的内容。


---- end ----

---- 推荐阅读 ----

后滴滴时代,论产品经理的安全意识

产品经理:小程序热门问题汇总

效率工具推荐(第5期)

掌握PC端和移动端差异,避免需求设计踩坑


❤️❤️❤️
1、码字不易,如果文章对你有收获,来个三连支持一下吧
2、关注公众号【产品的技术小课】,回复【星球】进入免费星球获取免费的产品技术学习资料
3、也可添加我微信【yss627144】,一起成长
浏览 95
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报