完整的研发流程
在一线互联网公司中，项目角色通常划分非常详细，比如常见的PM、RD、FE、UI、UE、QA等等，每个角色都对应着明确具体的分工。核心步骤规划明确：业务需求分析、评审、技术预研、立项、研发、迭代等等。本文针对前端研发环节进行剖析。一个完整的研发流程包含以下5大环节：开发准备、编码联调、调试优化、构建部署、数据采集，每个环节下面对应着很多细小而具体的工作任务，
研发效率的提高
如上图所示，一个基本的研发流程闭环包含了很多个节点，每一个节点都有其进一步的内部环节，只有每一个环节都顺利通多，研发流程才会顺畅。反之每多一个阻塞点就会导致研发流程阻塞一点，进而影响整个研发周期。
充分理解需求本质
研发工作的根本是解决用户需求，理解需求本质才是理解其背后的真正诉求，这一点没有过多技巧，但有2个条件必不可缺少，一是对业务绝对的“熟”，二是”多思考“。一定要避免领导说啥就是啥，PM讲啥就做啥，一个好团队是要有独立思考的能力，而且是要同频的。只有大家对目标、对需求的认识保持一直，研发的效率才可以提高上来。
精细合理任务拆分
任务拆分即目标分解，就是把一个大的任务拆分成一个个具体的,清晰的小任务,各自独立,又互相关联，跟因数分解是一个原理，通过解决这些小任务,最终完成大目标。涉及理论“工作分解结构”，简称WBS。在实际工作中可以遵照以下规则进行任务拆分：
- 接到需求后不要急于拆分，先理顺多沟通
- 准确的工作量评估
- 务拆分的颗粒度尽可能小，按小时估算
- 按小时不适应情况可按最小可CodeReview为单位
- 8小时工作制下真正有效工作时间为大约6小时
- 及时更改任务状态：开发中、联调中、已实现等等
- 周任务周期内放宽1到2个工作日作为缓冲期
- 任务排序最好按照优先级排序，后面使用起来更直观
- 业务相似度高的需求也要重复拆分任务，业务类似不代表技术类似
- 研发前期任务完成度最好超前一些，越往后越有拖延症
基础设施建设
上图列举了目前绝大多数前端对可做的前端基建工程大约50+个，基建工程可以说比较锻炼团队技术能力的，很多团多（包括我们）也是将基建的建设贯穿整个日常工作中的，并依照做业务、做技术划分实线、虚线2条线进行管理，实线做业务，虚线即做基建，两点对能力要求略有不同，可能你善长于研究框架、库，那你可能是个技术小组Leader，但不一定是业务小组Leader，反之亦然。不同的团队、不同的发展阶段、不同的业务体量决定了基建工程在研发流程中的重要程度，其最核心的意义仍然是解决业务问题、提高研发效率，切不可脱离这2大主题，在之后的梯队能力建设、团队文化凝聚、团队影响力建设等都是在以上2点基础上的，做好业务支撑一切才有意义，切不可为情怀买单。
代码审计
交叉评审
这部分我们在之前的文章《质量管理之CR流程建设》单独讲过一次，交叉评审简单来讲就是：你评我的、我评他的、他评你的.....，成员之间相互评审，每个人既是Author又是Reviewer，依赖于团队规范，每次提交的代码必须经过审核，这种模式更适用于人数多一些团队，我们团队每天几个个Merge请求，从另外一种角度看也解决了Leader的合并任务繁琐问题，更重要的是对代码质量有了更多的提高，否则评审只是个摆设了。
线下评审
这个阶段的CR通常伴随着一些业务知识进行评审, 比如你正在开发一个系统的权限模块, 那就针对人员、角色、模块等等进行一系列的评审, 设计是否合理? 模块划分是否耦合? 消息机制是否完善? 可扩展性是否满足发展需要? 等等. 这块可以极大的提高我们在对系统架构设计方面的能力.
工具扫描
主要工具还是SonarQube，可以找到很多我们评审忽略的地方。在实际研发中我们也会讲Sonar集成到CI/CD中，以及VsCode中，已保证Sonar能够持续扫描代码并发现问题及时纠正。
阶段性复盘
项目管理是跨学科技能，复盘本身是棋类术语，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。放到实际工作中即回顾、反思、探究、总结、提升，复盘要落地，必须融入日常工作中，复盘要“善用”，不能“滥用”。合理的复盘方式，是“小事及时复盘，大事阶段复盘（月度/季度），事后全面复盘（半年/年度）”。复盘不拘泥于形式，但我更倾向于大家坐到一起交流，试想我们日常生活中能有几次静下心来直面自己的过去，好好的反思呢？他山之石、可以攻玉，做好复盘，让每次遇到的问题都变成下一次的解决方案。
以下是复盘表格模板
| 项目复盘维度 | 项目1 | 项目2 | 项目3 |
|---|---|---|---|
| 涉事对象 | 产品、运营人员 | 售前、商务、售后人员 | 客服群体 |
| 业务价值 | 高效推进产品建设 客户关系维护进展 | 提高客户签约效率 业绩目标达成管理 | 快速响应用户问题 报表的定制化管理 |
| 项目周期 | 4周 | 2个月 | 2个月 |
| 研发成员 | 3 | 5 | 6 |
| 成员职责 | -- | -- | -- |
| 应用技术栈 | Angular8 | Vue3+TypeScript | React18+ES6 |
| 存在技术难点 | -- | -- | -- |
| 技术解决方案 | -- | -- | -- |
| 待深入探索技术点 | -- | -- | -- |
| 获取到的经验 | -- | -- | -- |
| 针对项目/团队的调整 | -- | -- | -- |
| 团队沉淀与输出 | -- | -- | -- |
总结
其实，不管大厂小厂，建设完善的研发流程的能力是一样的，都是为了能够满足业务、团队的需要，大厂的流程确实完善精细得多，但也不是一开始就完整的，在不同的发展阶段都是有调整的，小厂更多时候讲效率，自然不需要太繁琐，随着业务发展规模的扩大，各类管理方式也紧跟其上，KPI、OKR、BSC和各类专家，做事也变得越来越专业，自然而然研发流程也愈加细致。最终，最重要的还是能够锻炼自身“建设”的能力。
