先说本次需求出现的问题
1、对于售卖状态的不了解
课程本身有预售、售卖、抢光、售馨状态。几种状态需要在需求里做详细说明，同时这几种状态是根据后台设置进行前端展现的，一开始这部分因为我对课程商品状态不了解导致的，所以在后续工作中在自己不了解的情况下还是需要多问下。
2、对于标签展现策略给的不够精准
其实是一个很简单的问题，但是由于crm没有增加标签的功能所以都是通过数据提取课程特征前端写死的几个标签，而本次做的需求又涉及到联报和扩科两种类型的售卖名称，加上之前业务方都会把联报按照季节来进行命名，所以无形间前端在做展现判断时需要增加很多条件，后来当机立断，只保留联报和扩科统一化的类型，无论什么季节都展现联报，这样就不用再去增加各种判断条件来展现，其实回顾一下这样做非常好，简单明了，用户在购课时肯定也知道我当前买的是什么季节的联报课程，凡事无需都做到足够直白，功能可以做到足够简单但是一些文案展现层面无需过多去思考，过多的思考只会增加工作量。
3、优惠课程展现逻辑描述不清楚
本次需求一开始我是想了一个相对完整的方案出来，但是在内部做需求评审的时候对需求进行了删减，删减完以后没有做深入思考，导致需求评审完后又做了很多逻辑上的添加，其实本身功能很简单，但是受限于业务先要让用户选时间让优惠课程购买流程拉长了很多步骤，在交互上的讨论时间非常之久，最终评审时还是有同事觉得这样的体验不好，课程1和课程2的命名让用户会懵逼，我认为产品方案不能满足所有人但是要尽量满足所有人，只有这样才算是一个成功的功能成功的方案，在功能逻辑上的思考还是要更加缜密些为好，过于边界的情况在研发同事提出后产品人员评估后直接拍板，做或不做评估后给出理由。
4、忽略了库存问题
我一直以为业务的课程没有库存概念，但是在最后一轮确认需求时同时提出了库存的问题，原则上来讲不应该存在库存的问题因为来的人越多越好嘛，但是后来深入了解后库存受限辅导老师人数，因为辅导老师数量有限，如果无限招人会导致没有辅导老师服务，所以库存的问题不在于商品数量而在于辅导老师数量，延伸的思考是未来是否可以用机器人来代替辅导老师的一部分工作，让辅导老师专注于跟家长和学生的沟通上，监课就用机器人？
5、生成的订单思考不够细致
支付页面做了调整，在支付的时候订单与以往相比就有了变化，但是我在产品方案输出的时候忽略了完成订单的页面应该怎么去展现，这里是因为懒导致后续又补的需求说明
6、沟通问题
本次产品功能涉及到前后端的开发，也涉及到产品内部的前后端需求沟通，一开始定的方案在通过评审后发现无法满足产品功能，然后又变了后端的方案，变后发现后端crm侧需要做一些方案调整，增加一些判断条件，来约束业务以免建立错误课程导致前端同样课程以不同的类型出现了2次而且很有可能价格还不一样，所以这种情况放在后端在录入时就做条件判断屏蔽掉该问题，可是后端的产品同事死活不想做需求改动，如何说都不接受，最终拉上产品老大后最终敲定了能够满足需求的配合方案，这次沟通后我对该同事进行了分析，她之所以不想改无非2点原因，1：她不想改需求不想增加工作量；2：她对该需求根本不了解，所以我在说出不合理的前端展现时她还是坚持她的方案不改动如何让前端研发去判断屏蔽该问题，后来经过沟通确实她不了解，连基本的业务名词都不明白是什么意思。通过这次合作让我更加坚信下次有喝她的需求合作，第一时间拉上负责人去沟通敲定，否则还是会出现扯皮的问题，我不想这样，因为这样只能让自己不爽，效率还比较低。所以未来在与人合作的过程中发现这个人不了解需求背景不了解需求时，最好能赶快拉一个能拍板的人一起来讨论做决策，否则就会导致来回扯皮牵扯你的精力。
通过本次的复盘，做需求前还是要多去了解现状，当前业务逻辑都有哪些点在我的新需求里也会遇到同样的情况，把这些边界情况都要写入你的产品需求文档，只有这样你才能不断的在评审的过程中创造自己的影响力，才能让研发设计的同事们愿意和你一起工作，而不是把人家都搞的很郁闷，不想跟你一起合作。
