前面在《如何设计与管理一个前端项目》一文中，提到过需要做风险把控、事后复盘、数据量化，但具体怎么执行呢？本文主要结合以前的实战经验进行说明。
前面提到，我们需要主动把控各个环节的情况，及时推动和解决出现的一些多方协作的问题，先从风险控制说起。
# 1. 风险控制
举个例子，之前我接过一个需要带外包同学进行小程序开发的项目。在项目启动之前，我找到另外一个有过相同经验的开发咨询他们项目的一些情况，得到的反馈包括以下问题：
(1) 交付物质量问题：
- 主流程无法正常体验
- 代码中充斥着调试代码，交付时接口还连着测试环境
(2) 代码规范问题：
- 格式缩进混乱
(3) 性能问题：
- 只是用一个方法，随意引入第三方开源库
(4) 可维护性问题：
- 多页面重复逻辑
- 多页面写死appid等应该配置的数据
- 接口调用及处理放在多个页面逻辑代码内
(5) 代码健壮性问题：
- 需求逻辑边界未处理，后台数据异常直接报错
- 样式兼容不足，交付时文字掉行
这些都是可预估的风险。为了避免同样的问题出现，我做了一些前期的准备工作。通过前置的这些准备工作，也达到了不错的使用效果：
| 解决方案 | 分析/其他方案对比/模块划分 | 使用效果 |
|---|---|---|
| 开发协作 + 代码管理 | 小程序提供的TGit仓库 TGit与小程序关联，权限管理与开发者权限相关，可在公众平台配置 对比内网Git，可支持与离岸外包外网协作 使用Git可方便跟踪代码变更历史，同时Git在前端开发中普及度较高 | 开发 外包负责人 与外包协助顺畅，支持小团队并行开发 代码变更可追踪，方便管理 便于进行 code review，及时发现问题 |
| 基础环境 | Gulp编译 支持依赖安装与打包 支持less与Babel编译 可进行文件变更监控、编译、打包 | 支持使用less编写样式，提升开发效率 支持使用ES6/ES7语法 |
| mock环境 | 配置json作为mock数据 本地 node express 服务，简单路由映射到文件路径 通过切换 host 代理和 cgi 接口配置，切换 mock 数据、sandbox 和正式环境 | 后台提供完整接口文档和返回数据，前端通过 mock 完成功能流程开发，无需依赖后台 后台服务异常时，可切换 mock 环境，不阻塞前端开发 项目维护或交接时，可通过 mock 数据快速查看所有功能 |
| 代码规范 | prettier 配置好基本规范（换行、行末分号、缩进等），配合git commit提交时自动格式化代码，抹平编译器配置差距。对比 Eslint 校验： 静默格式化，无需开发手动调整或格式化 格式化不影响 git 历史，不会导致大片代码变更、不好定位的问题 | 只需要 外包负责人 配置化规范，开发对代码格式化无感知 代码缩进、句尾分号等都保持一致 |
| 基础库 | 提供常用基础库 请求管理 日志插件 常用工具 常用组件 | 提供公共请求方法，统一处理登录态失效、静默续期、测速上报、数据缓存、全局接口session_key参数等，外包只需关心接口的业务逻辑 大大减少了搭建环境的时间，部分功能模块也得到了复用，对开发速度有很大帮助 |
| 文档管理 | 提供完善文档 项目文档 工具库 demo 与文档 接口文档 | 项目相关文档很细，降低了不少沟通成本 |
| 权限和联调环境 | 提供可使用的权限和联调环境 申请外包驻场开发 提供带权限和环境的测试机 联调接口部署 sandbox | 驻场开发过程，外包与后台联调沟通效率提升不少 解决了外包无商户权限的问题 外包可离岸联调，同时设计、产品体验也无需配置HOST进行 |
通过前期准备的这些方案和工具，提前控制好一些可预见的风险，整个开发过程比较顺利。但是如果我们的效果只有这些的话，很多时候是无法证明自己做了这么多事情的价值。那么，我们可以尝试用数据说话。
# 用数据说话
这次带外包进行开发的项目共分成了两期，第一期开发的时候依然存在一些问题导致延期，包括：
(1) 开发完成延期3天：
- 开发未结束上个项目（另外一个小城小程序），通过临时加入开发人员来赶上进度
- 对可联调时间点评估不准确，启动联调时间晚了2天
- 联调过程，后台接口依赖其他团队配合，其他团队启动时间较晚，最终联调比预估多花费1天
(2) 体验时长共2周，延期7天：
- 设计对小程序质量要求十分高，故有不少的视觉调整，基本上每天一版细节调整（共 12 版）
- 产品体验时间较长，基本上一周一次产品体验的迭代（共两轮体验）
- 部分交互细节在需求没明确，产品体验时发现问题，其中的一些对开发逻辑调整较大
- 开发预留自测时间不充分，产品体验发现问题较多
在二期开发的时候，通过一些对策来避免这些问题，例如：
- 开发评估新的合作模式的项目预留多一些buffer
- 对涉及多方合作的项目，开发外包负责人需多预留些buffer
- 如果希望高度还原或者想做细致的交互，需要和外包商特别提一下
- 体验过程中，对开发、体验问题及时反馈
- 需求文档需完善交互细节，才给到外包开发
- 开发需预留足够的自测时间，对正常路径、异常路径都完成充分自测
通过这些对策，二期开发的时候成功地避免了同样的问题。我们可以通过图表的方式更加清晰洗表达，如图：
除了时间维度，我们还可以通过质量的维度来对比两期的开发情况，如图：
通过这些数据的输出，我们可以进行项目的复盘。
# 及时反馈与复盘
很多开发习惯了当代码开发完成、发布上线之后就结束了这个项目，其实他们遗漏了一个很重要的环节：复盘。通过复盘这种方式，我们可以发现自身的一些问题并改进，还可以让团队其他人以及管理者知道我们做了些什么，这是很重要的。
依然回到这个项目，复盘内容除了上述的数据展示，还可以包括一些项目结束后的问题分析，例如在这次开发过程问题：
- 外包开发效率上问题不大，项目延期主要原因：
- 等待后台接口可联调时间比预期要长
- 产品对接问题：提供资源、体验产品不够及时，需求规划需要更加详细
- 需求变更，主要体现在设计和交互调整
- 沟通和交流上，外包态度比较积极，反馈及时。可以改进的地方：
- 每日、每周工作进度及时做总结和汇总
- 对产品设计和体验的合理性可具备有一定的思考，主动发现问题、提出问题、解决问题
- 开发风格不一致，代码规范不一致，导致部分问题如下：过度抽象、使用自带工具库、逻辑管理较乱、变量类型混乱、重复代码过多
问题发现了，就需要进行解决，与外包同学进行沟通反馈的内容同样可以作为复盘内容的一部分：
(1) 开发启动前，与外包进行需求评审，同时提供了基础代码，可参照上方“前期准备”所述。
(2) 开发过程中，外包负责人发现一些代码上的问题，与外包进行沟通后，已调整和优化大部分代码。
(3) 开发完成后，与外包收集建议反馈，以及与其他项目对比，主要整理如下：
- 该项目过程的一些优点：
- 初始化时提供的代码大大减少了搭建环境的时间，部分功能模块也得到了复用，对开发速度有很大帮助
- 项目相关文档很细，降低了不少沟通成本
- 项目开发过程中，外包成长很多，也知道了之前存在的一些问题
- 对该项目的一些建议：
- 代码规范：外包希望外包负责人能提供一份前端代码规范
- 分工：外包负责业务相关页面开发，外包负责人 负责提供基础框架和工具库
- 小程序：小程序的特性还有一些限制应该考虑进去，比如小程序自定义modal盖不住输入框、title bar没有分割线、tab bar高度无法自定义等
- 视觉还原：外包工程师大部分都是编程方向的，对UI理解不深，如果希望高度还原或者想做细致的交互，需要和外包商特别提一下
这些内容，都可以通过邮件的方式发送给团队以及合作方，同时还可以作为自身的经验沉淀，后续更多项目中可以进行参考。这里举了一个特别详细的例子，可能会有些啰嗦，但大家可以仔细品读里面的一些问题的分析、处理过程和总结方式。如果使用得当，我们还可以通过这种方式来影响我们的团队和管理者，也是向上管理的一种方法。
# 结束语
但其实不只是工作中，我们生活里也可以常常进行反思和总结，这样我们的步伐才可以越跑越快。成长的过程中总会遇到各式各样的问题，有些问题被我们忽视而过，有些问题我们选择了逃避，但其实我们还可以通过迎面应战、解决并反思的方式，在这样一次次战斗中快速地成长。
