从前端视角归纳、分享下一线大厂业务开发流程，仅供参考！
需求探索、收集和落地
这活是由PD负责，这里简单了解下~
需求探索与收集
1，一般来说，需求的来源主要是两部分：一是公司/部门的战略需求，由老板或其它利益相关者提出，这类需求往往比较大，开发周期很长，通常会拆分成几个部分，不停地迭代开发，以作者为例就接到过开发周期超过四个月的需求，分成了六期完成(ps: 注意下，这里讨论的是业务开发，与大型软件或基础设施开发是有区别的)，二是由运营提出的需求或是为了支持市场运营的一些大型活动，即日常需求，通常来说，大部分的业务开发是满足这类需求。
2，需求确定后，PD会将需求整理好，对需求进行分类，定级和排期，一般会以月为一个周期。这里一个主要的矛盾是开发/设计资源是有限的，不可能将所有的需求并行推上去，所以排期是非常重要，也非常考究PD的调度执行能力。
需求落地
这一步有一个很重要的会议：需求评审会议。它会产生一个非常重要的文档：PRD(产品需求文档)，后续的交互/视觉设计、前/后端开发与测试都是围绕该文档进行展开的。
1，产品需求文档，它是产品功能实现的指导文档，后续的一切活动都围绕该文档展开。由PD分析、确定需求后编写。
2，需求评审会议，PD将需求排期确定后，发起会议邀请，通常会邀请所有有关联的人员，包括：
- 老板(大型需求会邀请)
- 产品经理
- 交互/视觉工程师(通常是两个人负责的，在资源不足的情况下，交互/视觉稿都是有交互工程师产出)
- 前端开发
- 后端开发
- 产品运营
- 测试相关人员
- 涉及到的其它部分的同事(如果有)
PD会根据PRD将需求功能一一列出来进行讨论，解释其需求背景，预期结果等等，确定其合理性、技术可行性等，进一步指导交互/视觉设计。这里有一个点需要注意的是，对应的功能实现需要将部分字段列出来(ps: PD在编写PRD时会先跟后端开发同学进行几轮讨论)。在会议过程中，参会人员需求将自己的疑问提出来，一一确认并解决，避免Block后面的流程。
3，改进后的PRD，会议结束后，PD会将会议中的提出的疑问一一确认、解决并同步到所有的关联人员，优化PRD内容。
开发阶段
需要注意的时，软件开发过程中，编码只是占比不大的一部分
交互/视觉设计
1，根据PRD，交互/视觉工程师开始设计，如果以一个月为周期的话，设计时长大概五~七天左右(ps: 仅供参考)。另外简单提下，移动端(C端)肯定是有视觉稿的，在设计资源紧张的情况下，PC端(B端)可能只有PD给出的草图，需要前端工程师自行确定交互与视觉。设计完成后，产出交互/设计稿。
2，完成交互/视觉稿后，UE/UI发起「交互/视觉评审」会议，邀请相关的同学参加，主要讨论的问题如下：
- 设计合理性，如：用户体验，视觉美观度，与应用主题是否协调等等
- 技术可行性，需要前端工程师进行辨别判断
- 与PRD对比验证，进一步确认需求功能是否合理并查漏补缺
- 找出视觉稿中存在的问题
3，根据会议中提出的问题，UE/UI优化设计稿，并交付给前端工程师和测试工程师。
4，前端同学会根据视觉稿进行开发。
前/后端并行开发
服务端开发
1，服务端同学拿到PRD后，对需求功能进行分析，产出「服务端系统分析文档」，文档内容主要包括：
- 需求功能对应的接口名与字段，前端同学会根据系分文档中的接口与字段，mock对应请求并行进行开发
- 对接口展开分析，通常会以时序图、用例图等形式对接口在系统的调度流程进行剖析，分析可能存在的风险与影响，这部分的分析对QA很有帮助
- 系统风险评估
- 确定主要的开发节点，如：开发时长(ps: 单位是 - 人/日)，前后端联调时间，提测时间，发布上线时间等
2，后端同学产出「服务端系分文档」后，发起「后端系分」会议，邀请相关的同学参加，讨论问题主要包括但不限于如下：
- 讲述需求功能实现的方案
- 抛出PRD中的可能存在的问题，在会议中讨论，确定并给出解决方案
- 提出实现方案中可能存在的风险问题，如：复杂系统下，接口调用链路过长可能导致接口请求超时，由于系统限制，有些交互与实现冲突等等
3，前端开发也依赖「服务端系分文档」。
4，开发完成后，会有一次代码CR会议，主要参加人员包括：产品经理，后端其他同学，测试人员以及前端开发。
前端开发
1，根据交互/视觉稿，前端同学需要产出「前端系统分析文档」，主要内容包括但不限于如下：
- 需求开发的主要几个时间节点，如：开发时间，前后端联调时间，提测日期，发布日期等
- 需求的实现方案，尽可能的详细，图文并茂
- 可能存在的风险点以及遇到的问题
- 发布计划
2，根据交互/视觉稿，开发对应的静态页；根据「服务端系分文档」，mock对应的接口，完成功能开发；通常所说的，前后端分离，并行开发就是这种模式。
3，前/后端开发地差不多了的时候，进入前/后端联调阶段，联调时间一般是2~3左右(ps: 仅供参考)。
4，联调完成后，基本功能已经实现，可能会邀请PD预验收一波。保证整个流程是贯通的，如果QA在测试的过程中，发现流程走不通，会将测试邮件退回来。
5，发送提测邮件，这个时候开发过程基本完成，开始介入下一个需求。
6，开发完成后，前端可能也会有一次代码CR会议(ps: 一般比较少，小编也就开过几次这样的会议，主要是项目是多部门共建时需要做)
测试进场兜底
1，在前/后端提测后，正式进入测试阶段，这部分工作是由测试工程师来完成。
2，在正式提测前，QA会产出「测试分析文档」，一般使用xmind工具将测试用例列出，主要内容包括：
- 需求功能的流程梳理
- 根据PRD列出测试用例，对功能点进行测试
- 其他等等
3，在测试过程发现bug会指派给对应的开发同学进行修复。
4，测试完成后，同步到PD和UE/UI进行验收。
验收和上线
验收
1，PD验收，主要内容包括：整个流程是否贯通，功能点与PRD是否一致，验证埋点信息是否正确等等。
2，UE/UI验收，检查功能页与设计稿是否完全一致，严格一点的，1px都不行 。
3，验收完成后，准备发布。
发布
1，一般来说，是服务端先发，前端后发，每周只有固定的发布窗口。
2，以前端来说，先灰度发布，再全量发布。
3，发布完成后，需要到线上做最后一次确认，保证线上功能正常，一般来说，预发环境与生产环境基本一致，但也有可能出问题，出问题就很坑，较难定位排查。
总结
从整个业务开发流程可以看出，在一个较大型的团队中，编码能力并不是一个决定性的因素(说明下，这里没有贬低编码能力的意思)，反而一些其它的能力非常重要，简单谈下。
1，沟通，这里从一个前端工程师的视角，具体简单的谈一下这个问题：
- 与产品经理沟通，虽然PD和UI可能会懂一些技术，但一般来说，不会很精通，所以有些功能设计深层次或边缘问题，需要在具体的开发过程中才能被发现，此时，一定要及时与PD进行沟通，确认。这里考虑的有两点：一是测试过程中可能被发现，但越晚发现修复时间就紧张，二是一个很小的细节bug，在足够体量的用户使用下，问题可能会被放大。不要心存侥幸，一定要发现问题，及时抛出，并解决问题。
- 与UE/UI沟通，前端开发时依赖视觉稿的，在发布时间节点确定的情况下，如果UI不能按期产出视觉稿的话，会压缩前端同学的开发时间。所以，小编印象比较深刻的是，一到比较忙的时候就各种花式催稿。另外提一点的是，设计资源即使在大厂也是比较紧张的，而且重点都放在移动端，PC端的交互和视觉基本都是前端自己确定后，再与PD进行沟通。而且，UI在繁忙的情况下产出的视觉稿，各种细节问题非常多，如果前端同学在发现问题后不及时与UI进行沟通，就照着视觉稿去实现，可以肯定的时测试，验收一定通不过，返工是必然的。
- 与后端沟通，主要内容围绕在接口，接口字段以及前/后端联调。比较常见的问题时，后端同学改了接口名称或接口返回内容中的某个字段，没有同步给其他同学，导致联调不同。这里提一点，小编推荐的一种前/后端沟通方式是以「服务端系统分析文档」为准，服务端同学有任何变动及时修改文档。可惜，我们都不喜欢写文档，这是肯定的。
- 与测试沟通，主要矛盾在信息不同步，由于测试介入的比较晚，测试用例是按照最初的相关文档编写的，但在开发过程中PRD或视觉稿会进行多次优化变更，如果变更没有被同步出来或没被注意到，就会造成信息认知偏差，相应的问题也就出来了。
最后，整体说下沟通，团队越大，沟通越重要，沟通成本也越大，这是肯定的，我们常说「有效沟通」，但现实中很难做到「有效」或是「高效」，我们都很忙~
2，积累，这里说的积累主要是指文档积累，在整个流程中，我们看到会产出很多的文档。这些文档在哪些长周期迭代的项目中或团队人员变更时显得非常重要。
3，心态，这里主要说两个点，一是成就感，把工作当成自己的工作，主动揽责任，功能被发布上线后，想到能被很多人使用会很有成就感；二是积极，主动推进项目开发的进度，保证项目不会延期。有两这两点，人就不会懈怠，人不懈怠事情就能做的成功。
拓展阅读
1，推书：《一个APP的诞生2.0》
内容偏设计，但将整个流程梳理了一遍，可以参考一下。
大家加油 ：）
