跨部门算法迭代需求，从提出到上线的全流程实践

引言

最近工作中有一个算法迭代的需求，我在其中作为技术侧负责人（技术主R）推动需求完成上线。

需求涉及多个部门，前后耗时接近1个月。

我第一次在这么复杂的需求中做技术主R，深入参与了需求从提出到上线的全流程，中间踩了不少坑，特此把整个过程记录下来，供大家参考。

我按照时间顺序，将全过程分成5个阶段：产品需求评审->技术方案评审->模块开发->系统联调->产品验收，接下来也会按照这个顺序依次描述。

正文见下。

需求评审

为了描述清楚此次需求，我画了个简易的系统数据交互图，步骤大概为：C向D触发一次计算请求，D拿到必要的参数后，将其传给算法，算法计算完成后将结果返回给D，D将结果包装后再返回给C；C将结果做必要的处理后，继续推送给Z，Z处理后再依次传给K、J和G等下游。

系统现状是：整个系统是已有的，但算法侧在计算时只有A类数据。此次核心需求是：算法侧需要增加X和L类数据，以提升最终的核心指标。

从系统能力上看，在拿到更多数据后，算法能分析得到更多内容。从系统变更上看，算法需要新增决策的逻辑，其他模块则需要增加接口字段并对新数据进行包装和处理。

初步盘点下来，此次主要的改动是算法侧，因此作为算法迭代负责人的我，便成了本次需求的技术主R。

技术方案评审

我被确定为技术主R后，产品便催我去约其他模块负责人的时间，早点组织技术方案的评审。

我找了一个大家都空闲的时间段，确定了评审时间。在实际评审时发现，只有我写了比较完善的技术方案，K写了大概思路，其他人什么都没有。当时感觉，大部分模块确实只有一些接口上的变动，好像没啥需要写的，所以也没在意。

会议上遗留的重要TODO是：（1）完善整体技术方案；（2）确定各模块工时、预期上线时间和具体的排期。

技术方案在会前并没有写，实际上是评审后补充的，主要包含4项内容：

（1）需求背景和目标，此处直接复制了需求文档中的内容；

（2）总体设计，此处复制此前系统开发时绘制的系统交互流程图；

（3）详细设计，按模块分别@了各负责人，并告知将各自的技术方案添加至此；

（4）工时预估和排期，评审会上做了初步沟通，结束后又逐一确认，然后得到了如下的排期。

模块开发

进入模块开发阶段后，我和D确认了输入和输出接口的字段后，就埋头撰写算法代码了。算法主要关注的事项有两个：（1）输出结果准确，这是基本要求，自不必多说；（2）能兼容线上已有版本，确保上线后不影响线上功能。

在完成代码开发、结果自测和代码评审之后，我就坐等联调了。

系统联调

由于所有联调都依赖D能正确从算法模块拿到数据，所以需要先专注于算法和D的联调。刚开始联调过程并不顺利，到了联调的第二天下午，才基本没有问题。后来我反思了一下原因，主要是因为算法需要的输入X在联调前只有大概字段，并没有提供具体实例，导致在联调时，算法耗费了大量时间在实例数据的处理上。

因为联调一共只有两天，到了联调的第二天下午，产品开始在群中询问联调进度。然后才发现，只有D和算法在联调，其他内容都没开始。所以其他模块间的联调也要快速动起来了。

很快，C出现了大问题：算法返回更多数据后，C只有新数据的接收功能，并没有继续开发针对新数据的处理功能，所以新数据实际上并不可用。

紧急沟通后的结论是：C需要2天重新思考技术方案和代码开发，然后再用2天做系统联调。

没办法，我只能在群中同步产品和老板们，项目上线日期需要延期4天。

为了提升第二次系统联调的效率，经领导的提醒，我梳理了联调的顺序，并提醒大家完成后依次在群中确认。

最终，第二次联调耗时2.5天。

QA测试

技术方案评审的时候，和QA约定的是，由于其他模块改动量较少，所以只对算法（+D）模块做测试，其他模块的测试由各自负责人自行完成。

因C导致的延期，并不影响QA测试算法模块，所以QA测试无需延期，可以按期开始。

算法测试的全流程为：（1）QA和算法、产品确认需要测试的功能点；（2）QA构造测试数据，并逐一测试算法结果是否符合预期；（3）反馈测试结果。

最终，QA测试很顺利，几乎不需要花时间再对算法代码做优化。

产品验收

产品验收分为测试环境验收和线上环境验收。

验收用例范围由产品确定，并由算法、D和C构造所需的必要输入。

本以为会和联调测试一模一样，但实际上产品验收时考虑的更多——还需要确认是否会影响到其他需求，以及是否会被其他需求影响。

验收过程也是比较顺利的，只有J模块有点小问题。

最终，测试环境验收共耗时2.5天，系统正式上线后，线上环境验收耗时0.5天。

经验教训

如果是有经验的技术主R，可能已经发现了很多我做的不好的地方。
这里我反思总结如下：

（1）技术方案应该在评审前就有个初版，各模块需要完成的功能应该和相关负责人达成一致，模块间的接口参数应该定义清楚。

（2）算法需要的数据样例，应该要求D至少在模块开发的中期就提供出来。

（3）系统联调时，需要提前确定联调的顺序和步骤，并告知相关方。

（4）在各个阶段都要及时跟进各模块进度，感知可能存在的风险，并寻找解决方案。

（5）排期时，不要过度压缩时间，还要有预留时间。

虽然此次经历并不是完美，但依然收获颇多，总结如下：

（1）更细致地了解整个系统。平时的工作基本仅限于算法和D，做了主R后，会倒逼自己了解清楚C、Z等后续所有模块。

（2）深度参与了一个需求从提出到上线的所有过程，极大拓宽了自己的认知，是一次很有意思的的体验。

（3）相比新系统开发的需求，算法同学更适合在系统迭代的需求中做主R。