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