4

企业研发流程演进之路

 3 years ago
source link: https://www.cnblogs.com/RudeCrab/p/14620264.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

企业研发流程.png

前言#

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

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

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

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」微信公众号,和螃蟹一起横行霸道。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK