12.26 我们产品部门 3 个人就过去两个月的产品工作进行了一次较为深入的复盘。主要是就本阶段项目 B 工作中遇到的问题、感悟的交流。聊了 4 个多小时，信息量比较大，下面就一些没有涉及到业务的部分简单记录分享。
一、本次复盘流程
（一）各自回顾
（二）复盘会议（非正式）
1. 整体回顾关键时间节点
2. 整体回顾 PRD 更新记录
3. 围绕时间主线上重要时间节点的工作展开讨论（可展开）
4. 每个人分别补充
5. 会议总结
（三）各自总结
二、个人零碎感悟
以下主要是第一部分自己的一些回顾反思
1. 多了解不同利益相关者对于产品的看法
leader 在的时候，因为他对之前的产品A很有信心，所以总会过滤掉一些产品的负面的声音；leader 退出公司后，从其他同事那里了解到了销售人员从不同的视角对于之前产品的看法：
1. 以前 leader 为了防止业务变动，所以把很多功能做得很通用、抽象；从另外一个角度看来，这导致产品被认为缺少具体使用的场景。
2. A 产品的一个核心功能让内容人员实现了组件化创建课程，越过了代码让创建课程更加快速。但是，销售人员去展示时， 内容本身的设计很难一下被感知，主要靠交互，但是 A 产品由于技术等多方面原因功能较为初级，效果不如用代码来的酷炫，缺少销售优势。
3. 公司原来的销售采用大单模式，而 A 产品开始采用 Saas 模式，想要从客户定制的模式调整为大客户定制，小客户订阅的方式。这本身在领域内属于很前沿的模式，但是由于教育买产品审批是一个复杂冗长的流程，每年都要重新申请一次学校会觉得很麻烦。
· 兼听则明，多听多了解不同利益人员对于产品的看法，并保持独立的判断。
2. 用简单的方式应对复杂的环境
leader 刚退出公司时，不懂产品的大老板接管产品中心工作，并让某个器重的员工暂时协助他负责新的项目 B。一段时间内自己觉得特别煎熬，觉得可能要被卷入办公室政治中觉得很烦躁，很缺乏安全感。
一直比较理性的产品小哥应对这个问题坦荡荡的态度让我觉得很惭愧，不过也深受启发，总结起来就是「坚持做自己认为正确的事」，有点大道至简的感觉。在复杂的环境中，我们唯一能掌控的就是自己，让自己变得更强，坚持做自己认为正确的事就好，如果自己已经尽力但还是遇到一些问题，那可能就是环境不合适，可以考虑换个环境了。
虽然过程可能曲折，但是这种应对问题的心态把问题变得简单了很多。
3. 沟通中的问题
和内容沟通以及评审的时候意识到了自己及其他同事身上的一些沟通问题：爱打断彼此说话，或急着否定别人；无法很好的看待别人的建议，或者因为别人的否定而急着为自己辩解。
1. 「反驳不会让你更聪明」，不要急着为自己辩解。
2. 认真听完别人不同的观点
3. 把别人的建议当成礼物，说谢谢就好。认证听，但不照着做。
沟通的问题很难一下改掉，我们首先要意识到自己的问题所在，然后朝好的方向努力。
4. 如何应对「老板的需求」
之前因为总担心老板及业务方会有需求变动，所以讨论产品功能设计的时候自己会强调「XX说，balabala」。按照领导说的做可能是最省事最方便甩锅的做法，但是认真处理的方式，其实还是应该去了解他的需求是什么，他想解决的问题是什么，然后从产品更专业的角度考虑是否有更好的方式可以解决问题，达到目标。
最近看大家冯大辉对于微信改版问题的评论，提到微信团队解决问题的风格，「当用户喊出某个需求或者问题的时候，他们要么认为这不是需求或问题，要么会尝试给出他们认为更好的解决方案。」
5. 不要追求刻板的形式
2B、2C 更多的业务上客户的不同，还有购买决策流程的差异。我司设计过于追求所谓的「2B」、「2C」设计风格（比如，设计将顶部菜单调整为很多 2B 采用的左侧菜单），在我看来是没有必要的。
之所以很多 2B 产品采用左侧导航栏，个人觉得一方面是因为当功能较多、层级较浅时，左侧导航拦更便于功能陈列、切换 。但是当遇到层级较深的页面时，左侧导航栏比较局限；或者当页面信息较多时，左侧导航栏因常态存在而占据了不必要的面积就不太合适。
btw，很多 2B 产品做的丑是因为他们靠功能而不是设计赚钱，为了控制成本而没有将时间、精力等放在产品设计上。
还有关于关闭弹层的操作，设计为了保持统一在全站采用了同一种方式。个人觉得在有重要信息填写的弹层，需要点击「关闭」作出拦截后关闭弹层；而仅做信息浏览的弹层，点击「关闭」及弹层外区域直接关闭即可。
6. 梳理业务逻辑单元
小哥一直在做 B 端产品，而且负责逻辑复杂的后台，自己一直觉得这一块非常难。但是在车次项目 B 的第一个阶段，小哥梳理了业务逻辑，看到这个我才意识到，这些其实就是支撑整个产品最核心的、最底层的逻辑。解决了好这些最「本质」、最核心的问题之后，其它的问题都迎刃而解。自己在项目 B 第二阶段承担了起主要业务逻辑的梳理（较阶段一情况略复杂），梳理后觉得脑子里对产品的理解变得更宏观了，对一些复杂的后台设计也在脑子里直接有了画面感。 项目 B 不同角色的需求中，用到的很多东西都统一的。
业务逻辑的梳理有点像是整个产品的骨骼，也有一些像是书籍后面的专业词汇表，统一了所有相关人员对于某个概念的理解、认知。
7. 负面反馈的处理
之前手贱在微博搜到了关于之前产品 A 的一个负面评价（后来再搜竟然被用户删掉了），第一反应觉得很惭愧，自我否定，觉得很糟糕。
但是后来反思了一下，在当时的时间、开发资源条件下，当时的处理方式已经是自己可以想到的最好的方式了，即使现在我也还没有更好的解决方式，然后就突然释怀了。
听到负面反馈，这些都是宝贵的经验，正视问题，反思造成的本质原因是什么，先看当下是否有更好的解决方式，当下是否有条件解决，不要急着否定自己。
8. 如何让需求评审更有效率
1. 明确每次评审会议主要想达到的目的，信息主要想传达对象。
2. 内部评审时，自己提前回忆需求细节、设计时的思路。讲解的时候不要机械的照着读，而是像对着一个人在讲解一样，思路需要一直是清晰的。
3. PRD 整体及页面内功能讲述时，运用「金字塔原理」，让自己、听众思路更清晰。
4. 至少预留半天～1天时间，让相关人员阅读 PRD。鼓励大家在阅读 PRD 期间提问，告诉大家可能是 PRD 写得不够清楚，如果看的时候哪里有疑问，欢迎及时沟通。
5. 可以尝试仅让需求相关人员参与的小批量、非正式的沟通，这样信息传达更有效，大家可能更放松，敢于发言参与问题的讨论。
6. 想要尝试对于听众的提问。对于较为重要的功能点，在重点讲解后提问听众。