1: 跟后端开发多次评审
前一次评审,我说新建发货单,默认是已发货状态,开发不同意,要加备货中状态. 再次评审时,开发说备货中状态,会导致判断其他订单状态更复杂,但是又担心物流状态不匹配. 我们明确告知他物流状态是独立的,且只是参考.然后果断去掉了备货中状态.
评审中开发不记得重新拆单时的一个需求:如果已存在相同供应商的订单则合并,否则新建订单.可能上次评审时没有详细说这块,他也没细看流程图和原型图.所以一次评审是不够的.
2:跟前端开发评审
开发建议去掉订单合并功能,以前做的类似功能,坑很多.鉴于他经验丰富有资历,且时间紧迫.就采纳了.
开发建议先去掉单独商品的取消功能,延用以前的整单取消功能,时间紧迫,而且实际操作时,可能不需要单独取消商品,后期优化也可以.
开发赞同在一个页面里显示所有未拆单商品和已拆单商品,一目了然,所有操作一个页面搞定.愉快的通过了.
我一直以为自动拆单是支付完成时,系统就拆单完成.但开发说是批量跑job把状态变为已完成,并不能调起自动拆单接口,或者是4s店后台支付成功,无法和我们的后台打通. 灵机一动,提议一个图标用于调起自动拆单,一个图标用于查看及调整拆单方案.考虑到两个图标累赘,就用空心的田字图标标识自动拆单,前端判定已点击过自动拆单,则变为实心的田字图标,用来标识拆单方案调整.只显示一个图标,通过颜色变化表明功能关联. 这样操作是否会引起歧义,等系统上线后再看操作方反馈.
跟开发表明:需求方认为不需要自动拆单,可能会是伪需求.如果需求方要经常取消订单再重新拆单,反而增加工作量,画蛇添足. 不过开发主管从系统改造的角度,坚持要改.以前的业务小伙说更改的概率应该不超10%,并且我们的默认供应商会加上地域限制,且供应商数量也会增多,人工分配出错率会增高.所以还是做上这个功能.明白前应后果,不做伪需求.
3:跟供应链沟通
由于供应链要求展示本品牌,方便特殊品牌更改配送地址,考虑到新增功能可以要做相应调整,去问供应链是否需要发货单的配送地址可编辑.并且说到发货单的建立时,由于实际操作的人变更,需求方认为没有必要.还好原来操作的人在,确认有不少场景是分成多次发货的.新功能没有白做.
而单独取消商品的场景,他们觉得概率很低. 正好这次不做,实际操作中,如果情况有变,或者痛点明显,再加也不迟.
4:跟测试沟通
测试小伙认真的总结了几个问题,一一答复.但有个地方,总是不明白对方的意思.争论几个回合,原来他不清楚拆单方案的页面,入口还是田字格.他以为是个列表页,展示所有方案.所以,对于这种特殊入口的情况,要写个操作手册,防止其他使用的人不理解逻辑.
对于测试的小伙伴,评审需求时要把每一个操作的流转,给他们演示清楚.所以和开发测试一起评审完毕后,最好把更新的流程,再一起捋一遍.防止没听明白,但又不好意思共同的小伙伴,按照自己意思去做,实现的功能和需求南辕北辙,重新返工排期,就浪费资源啦.
总结:
需求变更是难免的,但要确保参与的各方,都了解变更的内容.对整体流程和功能达成共识.
在资源有限的情况下,砍掉性价比不高的功能.
明确需求的前因后果,考虑需求的影响面,尽力优化流程,不做无用功.也让参与的人明白做的事情,意义和价值是什么,更有动力做好.
