作为一路摸打滚爬过来的互联网人，总结这几年的经历，我发现虽然企业所从事的业务大相径庭，但是研发团队的开发流程几乎相似：
用户需求采集->需求梳理成为产品文档->研发排期->研发方案评估->研发阶段->测试阶段->验收阶段->发布阶段->用户反馈->用户需求采集->...
而作为研发一员，项目管理的最重要一个环节就是“前期风险评估”。
根据自己实际的工作内容（已脱敏）和踩过的坑，总结一下自己对“技术人如何做好项目风险评估和把控”的理解。
补充两个基础的概念：研发环境分类与灰度测试。
（1）研发环境一般分为4种：
- 本地开发环境local
- 集成测试环境test
- 灰度发布环境cannary-env
- 正式发布环境pro-env
（2）特别需要注意的是灰度发布环境，这是非常有效的风险管控手段：灰度测试是一种（遵从某种灰度策略）给一小部分用户开放新功能体验，来降低风险与验证软件新功能的手段。通过灰度测试，我们可以在固定时间内指定特定的用户群来测试这个功能。
金丝雀版本也称为金丝雀部署、增量、分阶段或分阶段推出，是devops和软件开发中的最佳实践。
Canary Testing is a way to reduce risk and validate new software by releasing software to a small percentage of users. With canary testing, you can deliver to certain groups of users at a time. Also referred to as canary deployments, incremental, staged, or phased rollouts, canary releases are a best practice in devops and software development.
如何更好做到“前期风险评估”？
怎么做好“前期风险评估”呢，我觉得做到以下五点非常重要：
- 迭代改动范围
- 研发工作量评估
- 研发发布计划时间表
- 研发资源协调
- 上线风险评估
迭代改动范围
迭代改动范围：这个对于开发来说很好理解，简单来说就是你的改动要提前评估到会影响到哪些业务。
通常按微服务维度，你的这个功能需要影响的微服务数量是多少；如果按模块维度，你的增量API影响的上下游模块数量是多少；这些都可以作为横向评估的要素。
研发工作量评估
研发工作量评估：相比迭代改动范围，研发工作量评估是纵向评估的要素。
我们可以从待开发的api数量、新增的业务功能复杂度和实现难度、框架和其他业务的能力支持等等方面去评估。
研发发布计划时间表
研发发布计划时间表：我们需要提前跟运维和发版人通个气，大致了解项目的test环境/灰度环境/正式环境的预计发布时间点。
提前了解deadline，一方面会推动自己评估在现有的研发工作量下能否按期交付任务，另一方面会成为推动研发进度的强有力工具，包括下面提到的去协调资源。
研发资源协调
研发资源协调：站在PM的角度，我们不仅仅需要关注自己的开发进度，还要考虑到预留给测试/产品验收功能的时间。在掌握了研发发布计划时间表之后，可以提前咨询测试人力的投入是否足够，假如满足需要什么时候介入进来，假如不满足又需要从哪个业务线调配，最终确保有足够资源投入到产品质量的保障上。
业务兼容评估
业务兼容评估：或许你开发的功能，通过了local&test环境的各种测试，保证了新的产品功能落地，但是千万别忽略了灰度环境带来的影响。
灰度作为确保服务平滑升级与降低风险的手段，在大厂里面是不可或缺的。因此，开发者最好要确保代码的健壮性，满足正式环境与灰度环境同时存在新旧两份代码的运行条件，同时确保数据一致性。（虽然很苛刻，但这是大部分研发都容易忽略掉的点）
- 如果确保业务兼容灰度&正式环境，那么剩下的就好办了，只需要静待升级；
- 如果业务不能兼容灰度&正式环境，那就只能在工程里面添加控制开关（动态配置：通过配置中心动态配置；静态配置：通过项目配置文件实现静态配置）；
写在最后
项目管理不是生搬硬套，风险点更不是一成不变，上文仅仅就针对最通用常见的研发流程做个小总结。
真实研发流程往往会面临更多特殊的情况，比如：某个功能点遇到了不可抗力的延期，合作部门缺少及时的能力支持等等，这些都会成为“中期风险”的不定要素。如何管理研发过程，在项目管理里又是一门大学问了，后续有空再细聊~~
