2.整体研发流程相对完整的需求研发大致总结

　　2.整体研发流程相对完整的需求研发大致总结

　　1. 前言

　　我以前在一家不到100人的小公司工作，没有正式的需求研发流程。通常在产品提出需求后，技术方会在简单的审核后开始编写代码，本地或测试环境会直接在线发布。

　　后来去了一家二线工厂。虽然规模还远远落后于一线厂商，但公司也不算小，几千人左右，发展过程和一些大厂商有很多相似之处。

　　前段时间，运营*敏*感*词*姐问了我一些开发相关的内容，她告诉了她我们的开发过程。这是一个简短的摘要。

　　2.整体研发流程

　　一个比较完整的需求研发流程大致如下：

　　

　　PS：此流程仅供参考，可能因公司而异，但主要流程大体相同。

　　下面简要介绍每个链接的主要内容。

　　3.工艺分析0.产品需求

　　产品通常与“运营”和“研发”直接相关，是运营与研发之间的桥梁。

　　操作过程中产生的需求一般反馈给产品。产品将需求的主要功能组织成产品需求文档（PRD），并绘制产品原型（常用工具：Axure）。

　　PRD通常主要收录：

　　需求背景。为什么需要这样做？你想达到什么目的？要求详情。每个部分如何实现，包括业务逻辑以及如何交互。 1.珠三角评论

　　PRD完成后，产品经理（或项目经理）邀请开发、测试、运维、交互设计师等在会议室开会，详细说明需求，主要是讨论需求的可行性，比如技术能不能实现，逻辑有没有问题等。

　　2. 互动评论

　　产品给出的原型图可能不够具体，交互设计师必须针对细节出设计稿（常用工具：Sketch）。

　　比如按钮放在哪里，多宽多高，色值多少，点击后如何跳转等等。

　　然后设计师会根据设计稿剪出图纸交给前端开发人员。

　　3. 技术审查

　　是确定技术方案，这部分工作将由我们的开发者主导。主要包括以下几个部分：

　　主要是开发同学给大家讲解详细的技术实现方案，评估是否有不合理的地方。

　　对于架构图、流程图和时序图，可以使用 ProcessOn、draw.io、OmniGraffle、StarUML 等工具。

　　4. 开发和测试调度

　　经过技术审查，可以大致确定一个需求的具体工作量。这时候会给出更详细的时间表，主要包括：

　　通常“开发调度+联调调度+测试调度”就是这个要求的实现时间。这几次确认后，需求的发布和上线时间就基本定下来了。但也要考虑到期间可能发生的一些意外情况。

　　5.输出技术文档

　　技术审查需要输出技术文档，记录使用了哪些技术，添加了哪些配置，这次设计了哪些表格。流程图和架构图也应该记录在案，以便在一段时间后阅读，或者稍后移交给其他人进行维护。

　　另外，后端开发通常需要先提供接口定义和参数（这个过程可以由前后端讨论确定），以便前端开发mock数据。

　　6. 测试用例审查

　　测试学生列出本期所需的所有功能点，并向大家解释如何测试以及他们期望得到什么结果。如果某些接口对QPS、RT等有较高要求，一般会进行“压测”来判断是否满足要求。

　　类似于测试的“技术审查”。

　　7.前后端分开开发

　　此时，你终于可以按下代码了。

　　前后端是按照之前的接口定义分开开发的。

　　8.前后端联调

　　开发完成本地自测后，前后端一起走下整个流程。

　　PS：有时候考的同学会在考前给出一个冒烟的测试用例，一般是主要流程和逻辑的一些核心部分，当这些方面都没有问题时，就可以进行测试（不是必须的）。 9.提测

　　测试是正式告诉测试的学生这个需求已经初步制定出来，可以测试了。

　　一般会通过邮件通知，包括相关的测试、项目经理、开发、产品等，以控制进度。

　　如有延期，需提前发邮件告知延期原因。

　　10.测试环境测试

　　在测试环境中根据之前的测试用例测试学生发现bug...修改bug...发现bug...修改bug...

　　整体Bug修复完成后，对产品进行初步验收，看是否符合预期。

　　11. 预发布环境测试

　　测试环境的数据可能不够正式，主要用于测试各个流程是否可以通过。在预发布环境中，各种配置和数据库与生产环境基本相同。

　　如果预发布环境没问题，那么生产环境就可以发布了。

　　12.发布生产环境

　　在发布生产环境之前，通常需要做一些准备工作：比如创建数据表，添加新的配置等，通常需要运维同学的配合。

　　13. 在线回归测试

　　发布成功后，测试同学需要进行回归测试，即在生产环境中再次验证需求。

　　全部通过后，产品叫验收，产品感觉OK，所以需求OK。

　　产品点点头后，这个需求才真正开发出来。后面可能还有其他的整理工作，但不是必须的。

　　14. 项目评审总结

　　这部分不是必需的。

　　一般来说，当需求过程中出现很多问题时，我们会回顾主要问题以及以后如何避免这些问题。

　　15. 需求已完成

　　到此，一个比较完整的需求开发过程就结束了。

　　4. 补充说明1. 代码审查

　　通常的 Code Review 是在测试环境流程通过之后。

　　虽然测试后功能没有问题，但代码中可能存在一些难以检测的隐藏问题。这时候可以请几位开发兄弟和老板找个地方复查一下代码的关键部分，看看有没有潜在的漏洞，或者代码写得不合理的地方。

　　如果这部分做得好，其实对个人成长是有帮助的，但是有些公司可能会忽略这部分，尤其是在时间紧迫的情况下。

　　2. 帮助

　　以上流程只是个人根据平时的开发经验总结出来的，可能存在一些不妥之处。

　　如果要求比较简单，可以省略一些步骤。

　　PS：运营*敏*感*词*说我们之前觉得应该把需求做的很快，不明白为什么要开发一个需求那么久。我跟她谈了开发过程后，她保证以后再也不催我们了。