4月开始接手少年得到班课业务，做了退款项目，在设计课程数据项目。

思考与收获：

跟业务方对需求：

要么整个流程图把场景梳理出来，建立他们的整体概念，要么直接说他们要做的（关心点）

不要承诺任何事，做预期管理，不要啥活都接，能力不足的时候不要太“积极”，该拒绝的时候婉转拒绝

体现你的价值

工作效率：

1、一个人坐在工位上容易被外部环境分心，不够专注导致效率低

2、需要和人沟通的项目纠结犹豫了太多，却没有在思考关键问题（对方目标是什么，我的目标是什么，想要问清楚的问题、我表达的结构、礼貌用语）

3、会有大量需要和人沟通的事，消耗个人能量，坐回来比较难快速回到专注的状态

4、没有进入番茄计时的项目，总会慢悠悠地去做，导致效率低

业务优先级：

让业务方之间互相PK优先级，除非是一起讨论的时候可用，否则就是产品经理对优先级的不负责，产品应向业务方充分了解背景以及当下的目标，给出自己的优先级意见，统一说服业务方

建议轮流满足各业务方的需求，以安抚情绪（甚至可以先讨论需求，什么时候做另说）

P0是指这次一定要做的，P1、P2是指即使插入了其他需求到本项目前，系统或业务暂且也能支持

事前准备：

沟通、评审之前都要做好充分准备并让人觉你做好了充分的准备

需求文档：

prd的可读性、文档结构、修改注释都还有很大的提升空间，PRD是个基础能力，让研发舒服开发的基础

可借鉴效率线需求文档的写法

跟进项目/做产品的目标：

产出方面-迭代自己做产品的基本素质（评审、沟通、文档、会议、汇报等）

项目成效方面-做的这个项目确实对公司有益，要可视化这个效果并周知相关人员

团队信任方面-让研发觉得你们是一条战线上的人，你给的方案也靠谱，不会总变

需求评审会议注意：

评审前准备-可以适当打预防针

评审中结构逻辑-先通过流程图/需求功能结构讲主流程，再按文档结构基于文档进行展开

当有人插入后面会讲的问题时，

在风险可控的情况下，简化一些逻辑或者把一些要做的交由业务方手动

可以被分类归纳的内容不需要按时序依次讲的太细

不要刻意彰显自己的逻辑复杂设计的很NB

会议注意：

会议快结束时如果由我主导，我快速复述会议结论，并当场约下次碰面时间节点

会后的会议纪要邮件与微信群分别发一份，格式包括：

会议名称、参会人、会议目标、讨论内容与结论、todo（包括执行人与时间节点）、结尾加上“以上是会议纪要内容，如有疑问，请与我联系”，如果是微信群里发的，结尾再加上“会议纪要已发送到各位邮箱”

当会议时提到自己信息量不足的情况时，尽量少说话，保证自己的逻辑正确性

信息同步：

业务方和我们同步的信息 产品内部知晓

技术和产品同步的信息务必同步给业务方

与UI、研发讨论问题：

不要被对方的逻辑带着走，我必须要带着上下游逻辑，背景场景去想问题，交付之前尽量先把充足的背景交代好

看问题的时候，看得应该是问题的上下游来龙去脉，不止是解决当下问题（遇到问题的时候快速思考剥离出框架目的原因）

和业务方确认过的方案，就算有问题也以业务方意见为准。但是需要和业务方指出风险，并留邮件确认。

和技术确认过的方案，不要总是改。在可接受的范围内，不做变化，但自己要知道风险问题，并在合适的时候补上漏洞。

协作：

协作项目中遇到问题，最好能有同一个信息源eg.核心问题找同一个负责人来问，而不是东问问西问问

跨部门协作中，谁主张谁举证

不要听风就是雨，后台系统是给内部用户最大的支持，告诉他们在对应情况下怎么办

如果有问题，在没定位到根本原因的时候不要擅自给解决方案

项目复盘：

明确好项目复盘文档都有哪些目的：

    ①提升团队信心

    ②把下次需要注意的点同步给团队及leader

    ③展现自己有在干活

尽可能多用如表来展示数据，没有合适的图表自己做一个也行，服务于提振团队信心的目的

所有可能难看的数据都要想办法处理下，如果不服务于当下目的可以不展示

除非营收数据太难看，否则应该把营收数据前置（大老板们一定更关心这个）

产品设计：

想方案的时候一定要深刻考虑方案的复用性，和业务方变更需求的风险

一定要站在用户操作的上下游环境考虑问题，如用户购买查看通知书、老师发放通知书的流程