互联网产品研发全流程就看这一篇

随着互联网的发展，很多小伙伴都融入了其中。有的身兼数职成为万精油，有的敢当螺丝钉任劳任怨。今天让我们来看看互联网产品开发过程中到底经历了哪些过程。你是在某个环节发光发热或者充当全栈角色，更有甚者成为掌控全局的大神呢？

要点：

互联网产品研发流程

需求确认

交互设计

架构设计

研发编码

程序测试

产品发布

互联网产品研发流程

总体来说是通过公司的商业模式，确定目标用户，将用户的需求转化为产品需求，通过研发的方式再展现给用户，从市场中拿到用户反馈再产生新的需求。这个过程周而复始称为产品迭代。

产品，设计以及研发部门通力协作，经过层层工序才能打造迭代闭环。这里列出几个主要的流程节点，希望让各位有整体的认识。

需求确认

通常一个产品的产生都有自身的商业目的，可以用精益创业九宫格来定义你的产品，这里主要讲讲产品的需求确认阶段我们需要做些什么。

需求收集：产品一定会推向市场，一定会有用户群体。对群体按几个维度进行划分之后，就可以通过问卷调查，用户面谈的方式收集需求了。需求分析：通常用户的需求可能并不是针对的产品需求，我们的产品经理会对用户需求进行筛选转化成为产品需求，一般这个过程之后会形成需求文档。文档中会对应用场景进行描述，并且包含5W1H的内容，同时会附上原型设计。需求文档也有设计的先后例如MRD和PRD，这里不展开说明。原型设计：需求评审评审小组会结合上面的需求文档进行评审。评审不通过，根据原因重新进入需求分析或者需求获取阶段。

需求文档一旦经过了评审就会放到需求池中，根据上面提供的需求文档可以定制需求计划。项目的迭代根据需求计划设定。经历设计，研发，上线，最后发布到市场，用户使用之后的反馈又会回到需求池中去。

交互设计

有了需求文档会设计对应的原型初稿，然后就可以做交互和视觉的设计了。交付物品就是高保真的设计稿以及原型终稿。经过评审之后就能用为研发了。此时需要UX设计师和产品经理参与其中。原型终稿包含需求文档中的交互说明以及需求描述。每个团队实施上会有差异，我也咨询过几个互联网团队，基本相似，大家可以借鉴。

架构设计

架构设计的开始时间可以往前一些，通常在产品调研的阶段就可以介入了。通过了解产品的使用场景以及功能，大致可以推断出需要应用的技术。当整个产品需求和模型出来以后基本就可以确定架构了，整个架构设计基本分4步。

一. 业务架构：针对需求范围定义有哪些业务模块以及模块之间的关系。架构师需要完全理解业务模型，在阅读需求文档之后需要对其进行抽象理清他们之间的关系。

二. 应用架构：有了业务模块以及之间的关系，那么需要用哪些技术把他们构建并且连接起来就是应用架构要考虑的事情了。通常这里只需要抽象应用的技术类别，不需要设计具体的实现和选型。

三. 技术选型：有了应用架构做基础，技术选型就好像做填空题了。对应的应用需要具体哪些技术方案或者组件，中间件来实现了。例如：需要用到分布式服务，那么需要用到Spring Cloud。分布式服务就是应用架构，Spring Cloud就是其实现。当然，对于选型需要考虑可用性，效率，健壮性，可扩展性，学习成本等方面。这里不展开说明。

四. 数据库设计：考虑分布式或者集群，是否分表分库，是否读写分离。从业务模型如何转换到数据库模型，考虑以后的业务发展数据库如何做扩展设计。是否需要和外部系统做对接。这些因素都需要考虑。

开发流程

一般采取敏捷开发流程，把需求生成对应的Backlog，再将Backlog 拆分成多个UserStory。产品经理会给组员讲解每个UserStory需要完成的功能，由组员评估需要的时间（也有举牌打分的环节不过实际落地的情况比较少）。拆分的过程因拆分的内容不同，大约需要1-2天，每个任务大小控制在一天（8小时）可以完成。拆分之后就进入编码阶段，测试同事会编写测试用例。

每天上午由15-30分钟的全员站会，需要问三个问题，昨天做了什么？今天准备做什么？有什么问题阻碍了我的进度？Scrum Master 或者项目经理来主持会议，并且推动项目的进度。开发接近尾声的时候，会有每个开发人员demo自己做的功能给团队成员。之后就是功能测试，集成测试。这个迭代（sprint）持续2-4周。这期间会不断的重复，编码，测试用例编写，需求澄清，集成/冒烟测试。迭代结束一周会对用户进行demo或者培训，之后就可以正式发布了。

研发编码

在真正开始编码之前，需要针对上面的架构设计做对应的代码架构。实际就是把架构代码化，也有人把架构设计和代码架构在一起完成，也是可以的。代码的架构需要通过用途分为客户端，后台管理，服务端。构建的方式也很多例如MVC，MVP，MVVM等等。会用到一些设计模式的东西，例如工厂模式，适配器模式，装饰者模式，观察者模式，责任链模式，门面模式等等。基本的代码结构如下：

展示层（客户端，后台管理）：展示的元素，样式，模版定义，数据绑定。自定义组件：客制化用户组件，业务组件。业务模型：根据业务实现生成模型。业务逻辑层：业务逻辑编写。数据访问类：访问数据库的接口，需要考虑更换数据库的情况。类仓库，类依赖关系：依赖的系统组件，第三方组件工具类：类型转换，网络通讯，系统服务调用。资源：静态资源。常量：各种常量定义。

此时输出是代码的项目文件以及对应文件夹和代码文件，同时会放到代码库中管理起来（Git，SVN，TFS）。这个时候我们的程序员就可以根据这些架构进行开发了。

这里建议使用git工作流的方式创建任务，提交代码，以及对代码进行审核。由于篇幅原因这里不做展开，后面会专门起文章给大家讲解。

程序测试

根据需求文档/原型进行测试用例的编写，编写完毕以后产品经理会对用例进行审核。功能出来以后，对单个功能进行冒烟测试，各个功能点完成以后把功能点集成起来做集成测试。测试完成提供测试报告。对出现的问题（Bug/Issue）按照优先级记录，记录内容主要包括，期待的测试结果与实际的测试结果存在的差距，之后可以分配给开发人员进行bug的修复。一轮测试完毕通常会提供一个测试报告，上面会记录所有的问题，产品经理会根据这个报告判断是否发布。

产品部署

程序部署的环境有四个

Dev：开发使用的环境。Int：测试使用的环境。MO：预生产环境，和生产环境的配置和数据保持一致。Pro：生产环境，最终发布给用户的环境。

程序员在Dev对自己的代码进行调试，代码通过了审核编译成功之后就会发布到Int环境。测试人员会在那里进行集成测试，生成测试报告。如果Bug 数量在符合标准以内可以发布到MO环境继续测试，否则需要修复Bug 以后继续在Int测试直到符合要求。通过Int测试之后会进入MO环境，这里的数据以及配置和产品环境是一样的。在这里会模拟产品环境的测试场景进行测试，如果测试成功，经过产品经理审核符合发布条件就可以发布到Prod生产环境中了，否则还是要修复Bug重新测试，直到满足要求。

总结：全文介绍了互联网产品，从需求收集到设计，架构，编码，测试，发布的全过程。由于篇幅有限这里没有展开。后面会把DevOps的部分单独给大家做分享。