前面在《如何设计与管理一个前端项目》一文中，提到过需要做风险把控、事后复盘、数据量化，但具体怎么执行呢？本文主要结合以前的实战经验进行说明。

前面提到，我们需要主动把控各个环节的情况，及时推动和解决出现的一些多方协作的问题，先从风险控制说起。

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理解不深，如果希望高度还原或者想做细致的交互，需要和外包商特别提一下

这些内容，都可以通过邮件的方式发送给团队以及合作方，同时还可以作为自身的经验沉淀，后续更多项目中可以进行参考。这里举了一个特别详细的例子，可能会有些啰嗦，但大家可以仔细品读里面的一些问题的分析、处理过程和总结方式。如果使用得当，我们还可以通过这种方式来影响我们的团队和管理者，也是向上管理的一种方法。

结束语

但其实不只是工作中，我们生活里也可以常常进行反思和总结，这样我们的步伐才可以越跑越快。成长的过程中总会遇到各式各样的问题，有些问题被我们忽视而过，有些问题我们选择了逃避，但其实我们还可以通过迎面应战、解决并反思的方式，在这样一次次战斗中快速地成长。

查看Github有更多内容噢：https://github.com/godbasin
更欢迎来被删的前端游乐场边撸猫边学前端噢

如果你想要关注日常生活中的我，欢迎关注“牧羊的猪”公众号噢