深度复盘

事项1：

背景：仓库需要增加循环盘点功能，但这个项目又包含了商家端部分需求。KA和服务同学希望能够把盘亏原因和转残原因透出给商家，以便商家能够知晓库存产生此类异常的原因，并能够基于此来核算哪些是需要仓库赔付的。同时，也需要输出给商家一份月度库存报告，该报告中包含了月末最后一天的结余库存和当月转残/盘亏/赔付等汇总数据。

说明：晚上约了中台同学聊需求和排期。因为项目是7月30日上线，中台同学反馈这个需求无法排期，预估需要1130以后。同时，他们提到菜鸟如果再面向商家透出一份库存数据，当这份数据和商家看到的供应链库存数据不一致时，该如何处理的问题。

反思：

1、涉及中台改造的需求没有在项目初期就involve他们一起进来，也没有第一时间对焦需求；

2、沟通过程太久，且一直没有明确结论，都是单点沟通，效率非常低，浪费了太多时间

3、面向商家只能展示一份库存数据，否则当两份数据存在差异时，商家咨询量非常大，且商家更容易发现两份库存的差异，更能感知到内部管理的问题，也就暴露了更多的问题，且库存不一致是不可避免的问题。因此，要尽可能避免同时透出两份理论上应该相等但实际上可能不相等的数据源。

事项2：

背景：货主二期预计上线时间从7月2日延迟到7月7日，再延期到7月14日，再延期到7月16日。且每次都是上线前1-2天发现问题。第一次延期是因为页面设计不合理，产品验收时才发现问题，属于需求变更；第二次延期属于没有考虑上线前的培训，也没有预留时间写操作手册，而服务同学坚持要先培训才能上线。第三次是因为商家灰度问题，原本是按照对商家操作不影响的方式设计方案，但没有考虑到未参加培训的商家看到新增加的字段时会带来较大的咨询量。

反思：

1、产品验收需要尽早完成，尽量提前发现问题，不要等到UAT前1-2天才提出来

2、项目开发过程中就需要同服务运营和业务方沟通清楚培训计划和灰度要求，并把方案前置做到开发环节，不要一步步像打补丁的方式来实现。

3、做项目，要明确每项工作最晚在哪个节点完成，否则就可能出现准备做某个事情时，发现还没有明确的方案，就只能先凑合着做，或者就只能紧急找开发同学来支持，这种情况多了，就会给其他人造成你很不靠谱的感觉，也就很不愿意再和你二次合作。

4、做面向众多商家的产品方案时，不要想当然地，不要过于自以为是，不要认为我能理解，或者我觉得没问题就怎么样，要借助公司内部不同人对商家的认识和理解，让他们给出更加专业的意见。当你没有足够的判断力的时候，请放低自己的姿态，请虚心接受别人的意见。