企业研发流程演进之路

1,650 阅读12分钟

前言

无论是半路转行的准程序员,还是正在读书的大学生,大家都比较关心一个问题:「企业中真实的研发流程是怎样的」。有一些在小公司的程序员,也会好奇大厂的研发流程。

为什么这么多人关心研发流程呢,因为一个合理完善的流程代表着稳定、高效。一个公司有了好的流程,就能极大节约人力成本和时间成本;一名开发人员体会了好的流程,就能极大锻炼自己的项目 / 代码掌控能力。

本文就和大家分享一下,如今互联网大厂的研发流程。

0.png

大厂流程虽好,但也不是一蹴而成。每个公司体量不一样,流程也不一样,我们就从最简单的流程讲起,看看这些环节是如何一步一步演进过来的。

流程演进

草台班子

1.png

这套流程非常简单,从需求提出到需求结束就只有一个「开发」环节。

该流程可以说是没有流程,往往只会在「个人接私活」中这样做。我曾经接私活,许多客户只有一个简单的需求场景,比如「用户输入一些数据,根据一定公式给出分析建议」,像这种程序,开发人员直接根据描述完成功能即可。

流程弊端:

需求不明确,容易陷入无尽的「扯皮」中。

用户一开始要的是 A 功能,你做出来后,客户改口说要的是 B,那么你之前做的就白费了。

所以,明确需求是软件开发的大树之根,这一点没做好,后面所做的一切都没有意义。

明确需求

2.png

「初创的外包公司」或者「个人接私活」常实行这套流程。

该流程多了一个「需求确认与分析」环节,顾名思义,这一环节主要是对用户提出的需求进行确认和分析,最后确定好需求是会写在合同中的,后续一切按照合同中的需求项进行开发。

这个环节上限极高,下限也极低。做得好,自然能够很大程度上避免用户反复无常;做得差,需求不明确,依然会让开发人员返工。

改需求.jpg

需求变更是程序员最痛苦的事情,所以该环节会随着流程的完善而不断升级。

流程弊端:

客户的需求一般就只有文字描述。这种情况下,开发人员只是凭借自己的想象进行开发,对需求的理解容易产生偏差。

原型

3.png

原型图就是产品的预览模型,用于展示产品的最终效果。

原型图分为低保真原型和高保真原型。

低保真原型就像草图,用于快速向客户或者开发人员展示产品效果,方便修改和调整。

高保真原型基本就是产品的最终效果了,而且还会有交互效果(就是页面可以点击等操作),前端开发人员可以直接按照原型图进行页面开发。

原型图.jpeg

「小型的外包公司」和「个人接私活」常实行这套流程。

外包公司的话往往会有一个设计师进行原型图设计。

个人接私活的话,很多客户会直接给你原型图,他们一般是请外包设计师画出效果图,然后再请我们开发人员进行开发。

流程弊端:

开发完毕后就直接将项目交付了。

项目的各个Bug都是客户在使用过程中发现的,这时候需要开发人员修改很多趟,才能将项目完全交付出去。

要知道,客户不是专业人士也不是你的同事,沟通起来成本是非常高的,这种形式的交付会极其耽误时间。

曾经我接的一个私活,工期是一个月,但是来来回回更改细节和缺陷,拖了三四个月,身心俱疲。

测试验收

4.png

开发人员实现功能后,就会交由专门的测试人员进行系统测试,测试完毕后由产品进行验收,验收无误才能交付/上线。

「中小型的外包公司」和「小型的产品公司」会实行这套流程。

外包公司,就是指没有自己产品的公司,主要承接项目进行开发。需求都是从客户那边来的。

产品公司,就是指有自己产品的公司,会对自己的产品进行开发、运营、迭代。需求是业务部门、产品部门提出的。

这套流程麻雀虽但也小五脏俱全,各个环节都有对应的人员负责:

  • PM:产品经理。负责需求提出、产品设计;
  • UE:交互设计师。负责设计页面布局和交互(交互就是产品的操作逻辑,比如点击这个按钮会弹出什么提示框);
  • UI:视觉设计师。负责产品的具体样式设计(视觉就是产品的现实效果,比如这个图标长什么样),UE 和 UI 很多时候是一个人;
  • RD:开发人员。负责功能实现,主要分后端、前端、客户端开发人员;
  • QA:测试人员。负责产品的质量检测;
  • OP:运维人员。负责上线审批、维护产品所需要的硬件状态。

每个人员都各司其职,对自己所处的环节会进行把控,当前环节没问题后才会推进到下一个环节。

这时候流程的扭转与推进,不是口头上说一下就行了,而是要进行工程化管理,每个环节都要经过特定步骤才能推进到下一步,比如发送邮件。

现在有许多协作工具/平台,可以让我们非常方便地管理流程。比如腾讯推出的 TAPD:

tapd.png

流程弊端:

虽然该流程已初具规模,但还是很粗糙,每个环节都有完善的余地。

很多环节在没有准备充足的情况下就开始实施了,质量得不到有效的保障。

比如确定需求和原型后,开发就直接编码,如果在编码过程中发现技术方案不合理,此时要变更,就会浪费大量的时间。

所以,在实现功能前,应该进行一系列的设计与评审。

开发前的准备

5.png

接下来的流程演进,基本就是各互联网中大厂的流程了,每个环节可能各个公司的取舍不太一样,不过差别不是太大。

这套流程主要体现了功能实现前的一系列环节,这些环节做得越好,功能实现得也就越快越好。

产品需求评审

需求提出后,产品会拉上各个岗位的人进行产品需求评审,交互/视觉设计、开发、测试都会拉上。

产品经理会将需求项写好,并且整理出低保真原型图、产品流程等,让大家能够对产品和需求有个概念。

这时产品经理整理出来的叫做 PRD 文档,内容大概如下:

prd.png

每个公司都不一样,也不一定要写出文档一条条列出来,现在许多时候是直接在原型图上进行标注说明,然后大家根据原型图评审。

各个岗位会争取弄清楚产品和需求的每个细节,并且提示自己的想法,各抒己见。比如某个需求实现成本太高需要重新考虑、某个需求不合理需要改进等。

这个过程会花费比较长的时间,意见统一后产品经理会确定版本,然后各岗位就要开始进行自己职责内的设计了。

首先是开发人员,要进行概要和详细设计。

概要设计

概要设计就是开发方案设计,比如模块怎么划分、技术如何选型、数据模型如何设计等。

概要设计.png

这一块主要是对整个项目进行一个大概的设计,切记在该阶段对业务流程、细节实现过多纠结,这些都是详细设计的事。

详细设计

概要设计完成后,接下来就可以对细节方面进行设计了。

这个细节就是指功能的实现思路,比如一个非常简单的登录功能是这样的:

详细设计.png

编码时基本上就是看着图开发了,设计得越详细,编码时就越轻松。

测试用例设计

开发人员需要对编码进行思考和设计,测试人员也要对测试进行思考和设计,不然到时候想到哪测哪,容易遗漏功能点。

测试用例就是指需要测试的功能点详情,这个功能点应该怎样测试、前置条件是什么、预期结果是什么,等等。

测试用例.png

测试用例可以帮助测试人员理清需求,为后续的测试提供可参考的依据,在测试过程中也可以反映测试进度。

交互/视觉设计

同时,设计师也要进行交互和视觉设计。

这个环节做出来的高保真原型图,基本就是产品的最终样貌了。

综合评审

当开发人员、测试人员、设计师把自己的内容设计完毕后,大家又会凑到一块进行一番评审,来看看各自的设计有没有问题。

比如开发人员和测试人员会看下互相对功能的理解是否一致,不然到时候测试起来,测试说这个有问题,开发说这样是对的,就会浪费时间。

产品也会看下大家对需求的理解程度,避免理解偏差。

这个环节就是对细节方面的修改,改动一般不会太大,不会花太多时间。

该环节完成后,就是开发人员进行功能实现,前后端也会进行联调,联调完毕后开发人员会自行测试一番,没问题了再交由测试人员测试。

流程弊端:

该流程是在开发环节前做了充足的准备,但没有在开发环节后做充分的测试验收,产品上线后质量得不到保障,容易出问题。

所以,在开发完成后还需要进行一系列的测试验收工作。

开发后的保障

6.png

可以看到,开发完成后还有一大堆的事要做。

代码Review

首先,大厂一般会做代码 Review,即由组长或者组员审查你的代码,无论是业务上还是技术上,在这个环节都能收获许多建议,这个对开发人员可以说是成长最快的环节。

提测&第一轮测试

代码没问题后,开发人员就要提交测试申请,然后测试人员将代码发布到测试环境进行测试。

为什么开发人员在这一步还要提交一个申请呢,直接将代码发布不就得了。

这是因为测试周期比较长,测试人员还在测呢,你擅自发布,会影响测试人员的工作。

所以,测试环境只能由测试人员发布代码。

测试环境没问题后,就可以将代码分支合并,然后由测试人员发布到预发/沙箱环境。

预发/沙箱&第二轮测试

沙箱环境就是指将系统接入真实的数据,但系统只能内部访问,用户是无法访问的。

这个环节就是为了保证上线前不出问题,所以模拟线上真实环境,看系统能不能在真实数据下抗得住。

这一轮测试没问题后,又可以将代码分支合并一次,然后让产品经理进行验收。

产品第一轮验收&上线申请&上线

产品经理会看看现在完成的功能是否和需求一致。

验收无误后,就会发起上线申请,然后就要将代码发布到线上真实环境了。

上线这个事是“神圣又庄严”的,每个人巴不得焚香沐浴,深怕在线上出问题。

上线前要准备许多工作,比如要列出上线的服务有哪些、参与的相关人员、上线服务配置的变化、部署步骤、回滚方案等。

上线申请.png

发布时间也有讲究,一般不会在周五发布,怕出问题后周末不好调整;同理,一般也不会接近晚上发布,怕下班后不好处理。

有些公司还会发布灰度版本,即给部分用户发送新版升级,这部分用户体验没问题后,才全量发布。

回测&产品第二轮验收

上线之后,测试人员还会进行一次回归测试(第三轮测试了),测试无误后产品会再次验收。

都没问题了,这个需求才算结束。

总结

从需求提出到需求结束,还是挺不容易的,中途历经多个环节,要和多个部门/岗位协调,各种问题和难点都要面对。

这些流程,各个公司可能会有些出入,不过差不了太多。

每个公司会根据自己的公司文化、人员配比、业务方向以及需求大小做出调整,比如一些小的需求小的改动,概要/详细设计就不会做了;再比如一些公司会将产品验收环节放在第一轮测试之后……

流程的最终目的是节省人力成本和时间成本并且提高产品质量,符合公司实际情况的才是好流程。

小公司盲目采用大公司的流程,反而增加沟通成本;大公司明明流程老旧也不愿意改进,技术负债就会越来越多

无论是公司还是开发人员,我们都应当保持学习、时刻进步,这样才不会被这个时代抛下!

本文到这里就结束了,我是「RudeCrab」,一只粗鲁的螃蟹,我们下篇文章再见。

关注「RudeCrab」微信公众号,和螃蟹一起横行霸道。