这两天完成了一个中途接收的项目，开发改造已完成，目前处于业务使用方的验收阶段。加入这个项目的时候，属于需求已经确定，开发方案基本确定并开始启动开发的阶段了。由于是中途加入项目组，对项目改造点并不是特别了解，因此在方案设计方面，开始的一段时间始终是处于一个学习 + 项目管理的状态。5月中旬开发改造终于完成，业务方启动验收，中间出现了一些方案评估不全面导致整改的问题，具体如下：
1、方案设计不完善，仅考虑当前的业务场景，未考虑关联场景，新增接口未考虑老接口，新老接口数据存差异，导致对端处理失败和终端上报的数据使用方认为不合理；
2、业务调研不全面，未对覆盖的终端做全面的调研和分析；
3、数据转发时延大；
针对这个问题，做一个简单总结。
做好需求评估和方案设计
1、业务场景和需求
业务场景和需求是两回事，业务方一句话的需求需要有明确的业务场景对应，针对每个业务场景，再进行需求的细分。在需求的细分当中，需要再结合业务场景（含关联的场景），进行细化，需求分析要覆盖到开发的方方面面，不仅仅是功能方面，更要考虑到DFx方面的需求。
在这个项目中，需求细分仅针对当前要解决的问题，并没有全局考虑，特别是改造后对老业务的影响。该场景中，会对每个店铺分配一个渠道编码做管理，针对渠道编码，现在有省渠道编码和全网渠道编码2种，其中全网渠道编码会基于渠道特征变化，仅用于销售分析，不适合在业务流中使用。新接口设计时，统一要求终端携带两个字段，同事要求对端使用省渠道编码处理业务逻辑。但是老接口却忽略了这个问题，仍然使用全网渠道编码，导致这个接口开放后（改造前不传数据到对端），对端处理失败，让终端重新改造。
2、要有明确的文档或流程对需求进行管理
需求要有明确的载体。当前这个项目需求都是靠口口相传，并没有明确的需求文档。在项目验收时，对验收标准双方持不同意见，始终无法达成一致。如果需求有明确的文档记载，那么在验收标准方面就不会存在各种扯皮的问题了。
3、需求并不是最终方案
原始需求并不是方案设计的输入，只有通过需求分析和需求细化后，才能作为方案设计的输入。需求细化的作用可以参考第一点。
做好上线前的测试工作
在这个项目中，发现了一个非常大的问题，但是这个问题又是目前难以扭转和解决的问题，那就是测试的完备性。从我目前了解的情况，当前版本的测试情况是比较糟糕的，测试用例只有集成测试功能，而且仅涉及了正常使用场景的用例，而不是按照工程设计方法设计。另外在DFx方面，在需求和方案设计阶段，并没有过多的考虑。因此在业务验收的时候，发现部分接口时延较大，导致不满足需求。
如果在需求和方案设计阶段，我们对业务流量，业务模型有个大概的摸底，然后基于业务情况进行能力的设计，这个问题应该是完全避免的。再退一步，如果产品开发完成后，DFx测试能够正常完成的话，这个问题应该也是可以解决的。但是这些动作都没有正常执行，结果就是二次整改。
以上这些仅是记录的部分影响较大的问题，希望在后续的项目中能够避免再次出现。
