需求评审
误解：需求评审就是大家坐在一起讨论需求设计是否合理
一直如上理解需求评审的意义，直到最近为一套产品方案需求评审四次不通过，开始反思如何去做需求评审。
这套产品方案有多个技术方式可以尝试，产品设计按照其中一种设计了实现逻辑，然后召集大家评审。评审会上研发各抒己见讨论各个方式的优劣，最终因为没有一个能够完美满足需求，因而每次评审完后都会对产品方案再做调整，几次评审下来没有一个确定的结论，研发开始抱怨评审会效率低下。
正确打开方式：
评审不是大家讨论这事儿这么办对不对，而是告诉大家这事儿要怎么做。
确定需求是产品的职责，这里需求包括了产品需求和技术需求，用什么方式和逻辑来实现什么功能和交互，这部分工作要在需求评审前就完成，产品要对需求拍板定案。
怎么完成？通过多方沟通达成一致，达成一致！沟通可以用会议形式，但不需要正式开会召集大家，相关人拉一起快速风暴是最高效的。其次就是基于对产品的了解和把握，需求能够实现到什么程度心里要有数。
需求明确了，关键人物(通常是研发leader、项目pm和老板)也都认同了，这时候再召集大家评审同步下信息，确认细节和各方分工
通知触达
误解：已经发过邮件了，对方是知道的，对方会去处理的
线下沟通、线上消息、邮件、工作流…这些信息通知方式都是一种形式，最终的目的是通知的触达，所以无论什么形式，当你不确定对方完全理解并确认执行的时候，通知就失败了。
任何通知形式都不是用来宽慰自己消息已经触达，责任心这件事落实起来就是一个长跑马拉松
