4月开始接手少年得到班课业务，做了退款项目，在设计课程数据项目。
思考与收获：
跟业务方对需求：
要么整个流程图把场景梳理出来，建立他们的整体概念，要么直接说他们要做的（关心点）
不要承诺任何事，做预期管理，不要啥活都接，能力不足的时候不要太“积极”，该拒绝的时候婉转拒绝
体现你的价值
工作效率：
1、一个人坐在工位上容易被外部环境分心，不够专注导致效率低
2、需要和人沟通的项目纠结犹豫了太多，却没有在思考关键问题（对方目标是什么，我的目标是什么，想要问清楚的问题、我表达的结构、礼貌用语）
3、会有大量需要和人沟通的事，消耗个人能量，坐回来比较难快速回到专注的状态
4、没有进入番茄计时的项目，总会慢悠悠地去做，导致效率低
业务优先级：
让业务方之间互相PK优先级，除非是一起讨论的时候可用，否则就是产品经理对优先级的不负责，产品应向业务方充分了解背景以及当下的目标，给出自己的优先级意见，统一说服业务方
建议轮流满足各业务方的需求，以安抚情绪（甚至可以先讨论需求，什么时候做另说）
P0是指这次一定要做的，P1、P2是指即使插入了其他需求到本项目前，系统或业务暂且也能支持
事前准备：
沟通、评审之前都要做好充分准备并让人觉你做好了充分的准备
需求文档：
prd的可读性、文档结构、修改注释都还有很大的提升空间，PRD是个基础能力，让研发舒服开发的基础
可借鉴效率线需求文档的写法
跟进项目/做产品的目标：
产出方面-迭代自己做产品的基本素质（评审、沟通、文档、会议、汇报等）
项目成效方面-做的这个项目确实对公司有益，要可视化这个效果并周知相关人员
团队信任方面-让研发觉得你们是一条战线上的人，你给的方案也靠谱，不会总变
需求评审会议注意：
评审前准备-可以适当打预防针
评审中结构逻辑-先通过流程图/需求功能结构讲主流程，再按文档结构基于文档进行展开
当有人插入后面会讲的问题时，
在风险可控的情况下，简化一些逻辑或者把一些要做的交由业务方手动
可以被分类归纳的内容不需要按时序依次讲的太细
不要刻意彰显自己的逻辑复杂设计的很NB
会议注意：
会议快结束时如果由我主导，我快速复述会议结论，并当场约下次碰面时间节点
会后的会议纪要邮件与微信群分别发一份，格式包括：
会议名称、参会人、会议目标、讨论内容与结论、todo（包括执行人与时间节点）、结尾加上“以上是会议纪要内容，如有疑问，请与我联系”，如果是微信群里发的，结尾再加上“会议纪要已发送到各位邮箱”
当会议时提到自己信息量不足的情况时，尽量少说话，保证自己的逻辑正确性
信息同步：
业务方和我们同步的信息 产品内部知晓
技术和产品同步的信息务必同步给业务方
与UI、研发讨论问题：
不要被对方的逻辑带着走，我必须要带着上下游逻辑，背景场景去想问题，交付之前尽量先把充足的背景交代好
看问题的时候，看得应该是问题的上下游来龙去脉，不止是解决当下问题（遇到问题的时候快速思考剥离出框架目的原因）
和业务方确认过的方案，就算有问题也以业务方意见为准。但是需要和业务方指出风险，并留邮件确认。
和技术确认过的方案，不要总是改。在可接受的范围内，不做变化，但自己要知道风险问题，并在合适的时候补上漏洞。
协作：
协作项目中遇到问题，最好能有同一个信息源eg.核心问题找同一个负责人来问，而不是东问问西问问
跨部门协作中，谁主张谁举证
不要听风就是雨，后台系统是给内部用户最大的支持，告诉他们在对应情况下怎么办
如果有问题，在没定位到根本原因的时候不要擅自给解决方案
项目复盘：
明确好项目复盘文档都有哪些目的：
①提升团队信心
②把下次需要注意的点同步给团队及leader
③展现自己有在干活
尽可能多用如表来展示数据，没有合适的图表自己做一个也行，服务于提振团队信心的目的
所有可能难看的数据都要想办法处理下，如果不服务于当下目的可以不展示
除非营收数据太难看，否则应该把营收数据前置（大老板们一定更关心这个）
产品设计：
想方案的时候一定要深刻考虑方案的复用性，和业务方变更需求的风险
一定要站在用户操作的上下游环境考虑问题，如用户购买查看通知书、老师发放通知书的流程