工作三年，这才是合理的开发流程！

大家好，我是小彭，从毕业找实习，一转眼过去三年多，自从毕业后感觉时间过的特别快。第一份工作是在一家小型创业型公司，有自己的产品和规划，由于面向B端商家，发展的不温不火，疫情爆发后，公司经营困难，无奈只能辞职换下份工作。在第一家公司工作两年后跳槽到现在的公司，整体还是比较满意的。

在工作的三年多里，经历了不同公司的开发流程。小公司讲究快速开发，人手不足不说，上去就是干，这样产生的问题也很明显，需求不明确、测试覆盖率低、bug多、上线不规范等等。大中型公司讲究分工明确，各司其职，只需专注自己手上的事就行，但也有不好的地方，就是无法掌握整体的业务。

小彭将在本文中分享中型自研公司开发人员的工作流程和注意事项，并举例拿一个需求，对该需求进行模拟评审、功能拆分等等，走完整个流程，希望能对大家有所帮助和启发。

1.需求评审

1.1 收集需求

产品经理收集客户、运营相关需求，经过分析和整理，编写成需求文档。

举个例子：假设本次需求是【V1.1.2订单模块优化：新增评论功能，完成评论可获得指定积分，根据不同会员等级可配置不同的积分。后期积分可兑换商品、付款时抵扣金额】

1.2 发送需求邮件

产品经理编写完需求文档后，会根据需求文档类型发送邮件到相关开发小组和人员（如本次的订单模块需求，将邮件通知交易小组开发人员），开发人员收到邮件后需要提前熟悉文档，记录需求文档中疑惑的问题。

注意事项：

1.开发人员一定要抽时间看几遍需求文档，不然在评审需求阶段会一脸懵。

1.3 需求评审

产品经理召集大家参加评审会议，讲解需求文档中的相关细节，并解答开发人员疑惑的问题。

注意事项：

1.跨城市需要协调好时间，提前预约会议室（如钉钉会议室），避免因为各城市人员时间冲突导致无法进行会议。

2.开发人员记得把疑问都提出来，毕竟产品不可能考虑的特别仔细，对于不合理的需求需要及时指出，及时止损。

2.技术评审

需求评审完毕后，对于有难点、核心的需求，开发人员将进行技术可行性评审，分析可能存在的问题，分析是否可以实现该功能，（如：订单模块，订单完成收货后可以进行评论）对于小需求可忽略该流程。

3.功能拆分

3.1 功能拆分

需求评审、技术评审都搞定后，由开发人员针对需求文档，进行功能拆分，把文档中的每个细节都记录下来，记录需要开发的功能，汇总到在线文档中。

比如本文假设的需求，我们站在后端人员的角度进行需求拆分，拆分出以下功能：

1.数据表设计

1.1 数据表整体设计与构想 （估时：4）

1.2 积分配置表 （估时：0.5）

1.3 评论表（估时：0.5）

1.4 积分表（估时：0.5）

1.5 积分变动表（考虑到获取奖励积分和使用积分）（估时：0.5）

2.积分配置

2.1 根据不同的会员等级，配置不同的奖励积分（估时：8）

3.评论功能

3.1 完成评论接口 （估时：16）

4.积分奖励功能

4.1 需要考虑到扩展性（可能会有签到送积分、收货送积分、评论送积分、分享送积分、积分排行等需求，要相信产品经理的脑洞）（估时：8）

4.2 积分奖励功能，尽量不要写的太死板 （估时：16）

4.3 积分获取记录（估时：8）

5.各端联调

5.1 接口联调 （估时：8）

5.2 整体流程联调（估时：8）

注意事项：

功能拆分要拆到最小粒度，否则会影响到估时排期。

4 分配任务与排期

4.1 估时与排期

需求评审、技术评审、功能拆分流程走完后，来到了比较重要的估时，也就是对拆分的每个小功能进行估时，累加一起算出需要的工期。如2.1功能拆分小节，每个功能后记录的估时，单位是小时。

计算好工期后，比如本次需求排期是78个小时，按照每天8个小时，78/8=9.75，也就是10个工作日。根据人力再进行计算，比如我们投入两位后端开发人力，那么10/2=5，也就是说，后端开发需要5个工作日就能完成本需求的开发。

还需要前端人员的估时，比如投入一个前端人力，前端小姐姐估时7个工作日，那么最终的估时排期是7个工作日。

将排好的工期告知自己的上级和产品经理，产品经理确认没问题后就可以对任务进行分配和开发了，如果产品说排期太长，要么自行压缩工时，要么和产品说原因，让对方认同自己的排期。

注意事项：

1.在时间允许的情况下，尽量多估一点时间，以免开发过程中出现需求变动，很可能要加班才能在指定排期内完成。

2.需要考虑前后端人员的估时，如果你是后端，那么你要了解前端的估时，最终需要按照最长估时的排期。

4.2 分配任务

把拆分好、估时好的任务进行分配，可由组长或者开发人员自行分配，根据功能种类和开发人员实际情况进行分配，保证每个人的工时都比较平等，能力强的人员可以承担核心功能的开发。最后将任务录入到系统中，如禅道或者JIRA等系统。

注意事项：

1.需要根据功能种类进行分配，如奖励积分和奖励记录可以分配给同一个人开发。

2.每个人分配的任务工时累加在一起，不能相差太多，否则可能会超出预定的排期。

5.开发

开发阶段其实也没太多需要描述的，根据上面咱们的估时，保证今天需要写完的功能都完成就可以了。

注意事项：

1.多思考、多抽象、用心去开发，做一个有职业素养的程序员，少写不可维护的代码，少堆屎山。

2.开发阶段发现需求有问题要及时和产品沟通。

6.提测

太好啦，终于开发完毕了，在前后端开发完毕后，并且根据测试用例自测几遍后，就能发送提测邮件、提测单给测试小姐姐了。

测试人员将在测试环境测试本次需求的相关功能是否完成，是否有bug，如果有bug将会在系统中登记并指派给相关人。

注意事项：

1.发送提测邮件时一定要选择对人员，抄送到相关人。

2.提测前一定要自测几遍，至少流程要通。

3.及时处理解决测试指派的bug。

7.上线发布

提测完毕，并且登记的相关bug已经顺利解决，产品会根据业务的时间点，决定什么时候上线发布。

开发人员只需点好外卖，合并自己开发的分支到master主分支上，发起上线审批，系统自动构建项目，完成上线。

注意事项：

1.注意分支管理。

2.注意其他关联的系统是否上线，注意上线顺序。

3.注意SQL是否执行成功或者报错。

8.复盘

如果在开发过程中产生太多的问题、上线后产生重大bug事件，需要开复盘总结会议，主要是对问题进行描述、分析、归纳、总结，达到吸取教训，以免下次再出现此类问题。

9.code review

由开发人员组织的会议，为了发现系统中代码编写中的不足，针对某个需求，让该需求的开发人员讲解自己的代码，其他开发人员进行问题记录，讲解完毕后其他开发人员可进行提问和讨论，讨论哪些不合理的地方、写的好的地方。对于不合理的代码，需要自行更换，在下次版本上线时进行修复。

注意事项：

1.积极参与和提问，共同完善系统。

2.对事不对人。

10.总结

以上内容总结了开发阶段各个环节的流程，功能拆分和估时环节比较重要，开发和上线发布阶段还有很多可以写的地方，有机会的话会继续分享出来。希望本文能对小伙伴们有所帮助，感谢阅读！