作为产品经理，我们时常需要与各种不同角色的人打交道：
对于产品经理，可能需要与老板、客户、市场推广人员、运营人员、客服人员、UI、前端开发、后端开发、测试、运维人员沟通；因此，准确、快速、高效的让队友人员理解你的需求并给出明确的反馈就成了产品经理必备的技能。总结起来，沟通包含三个主要的问题： 说什么、 和谁说、 怎么说
一、 说什么：
首先，当你准备表达某件事情的时候，你需要提前知道你自己表达的内容是什么，可以分为哪些信息点，简单来说就是4w1h原则：：what：是什么；why：为什么；when：什么时候；who：谁来执行？ how：怎么做？
1. what：你要做的是什么事情？
2. why：为什么要做这件事情？
3. how：准备怎么做
4. when：准备什么时候做？
5. who：需要谁来做/谁配合来做？
例如：保险模型准备做标记预警
你要做的是什么事情？
搭保险标记建预警机制，对保险标记异常的依据、规则进行提前预警，便于分析规则库或保险模型问题，用于迭代优化
为什么要做呢？
1）现在训练源准确度存疑：
·作为训练对照组的评估师标记会出错；
·线上的数据错了也没人修复，会成为脏数据影响保险准确率；
2）保险数据需要纯人工导出+分析：
·线上的是否有问题需要人工分析才知道，不分析不知道存在的问题；
·人工分析耗时长且效率低，后续若商用样本更多根本分析不过来；
3）数据验证需要产品+研发对数据库操作，成本高、耗费时间长且效率低
·对规则库的修改都需要研发人员操作数据库后再跑数，修改一次基本半天没有了（投入一个产品+一个研发的半天），多操作几次成本过高且效率低
怎么做（四个阶段性需求）：
1）保险标记：评估师标记的事故类型必须选择依据，且依据由保险模型抽取出来的，将评估师判断的依据转化为规则库能够识别的依据，这样就可以判断评估师判断事故的标准以及该标准下标记的类型是否有误；
2）异常单批量处理：将评估师标记类型与依据不一致的订单、评估师与保险模型标记不一致的订单丢到异常单处理中心，可以对这批异常单进行批量修复、导出、分析
3）建立预警模型对异常单异常的类型进行分类预警：例如：判断依据指向事故不一致、评估师标记与保险模型不一致、其他原因等，设定异常阈值，达到阈值即通过邮件预警，及时处理
4）保险规则库线上化维护及初始化：将保险规则库、别名库、剔除词库放到线上维护及初始化，进行权限限制，无需再让研发浪费时间来操作且可以快速验证修改规则的效果
什么时候做：
9月始-11月终
谁来做：
产品部、评估部、研发部
根据做什么，和怎么做，梳理出自己需要争取的开发、评估师资源，确定协助完成这件事的人员
二、和谁说：
当你了解你要做什么并且梳理完成后，就针对做涉及这件事的人员进行沟通，或寻求支持，或争取资源，或分配事务，但是，不同角色的人群关注点不同：
领导
做这件事情的价值——阐述需求的价值，争取立项
评估师
做这个会不会增加我们的工作量？会不会浪费我们的时间？对我们工作有什么影响？（是否影响他们的个人考核）
研发人员
别废话，简明概要的说让我干啥，还有，少挖坑，少变更需求，需求想清楚点
——做事的人找到了，明确各节点任务人员需要做什么
怎么说：
领导:说价值、说战略
对于预警模型：
现状：1）现在评估师评估的不准；2）导致脏数据影响我们模型准确性；3）而且我们现在跑数模式不导出数据无法知晓模型效果，无法防范异常情况；4）且数据量多纯人力分析效率低成本高；5）后续自动化必须要上预警
做了的价值：1）反证评估师的准确率；2）模型会越来越准确；3）能及时发现模型异常，主动预警；4）降低人力成本；5）为后续自动化做铺垫
评估师
做这个会不会增加我们的工作量？会不会浪费我们的时间？对我们工作有什么影响？（是否影响他们的个人考核）
不会增加你们工作量的~你们连复制粘贴都不要，直接点击依据然后提交就行了~以后也不用发Excel表让你们一个个修复了，直接在线上编辑一下就行~这么看你们操作更便捷了呢~
研发人员
1. 说产品设计的规划——该业务的背景、已完成的阶段、未完成的阶段，本需求将要完成的阶段；
目的：
1）认知统一——将大家对于这件事情的认知处在同一水平上，避免对牛弹琴白做功
2）方便研发结合整体业务搭建技术框架，避免程序兼容性、拓展性过于狭窄，后续改造浪费时间和精力
2. 说逻辑设计——本阶段需要他们做什么（重要阶段）
1）沟通本阶段需求的内容及目的
2）产品逻辑同步给研发、测试及相关人员，让各个角色了解自己负责的工作（同时各角色对产品逻辑疑问进行提问）——对各方工作进行确认，疑问点提出并解答，保障各节点认知统一
3）针对需求本对，就做这些，嗯，就这么做，不坑你，嗯嗯，确定了，这个需求肯定不改了~
3. 确定各阶段交付时间并让团队内的人员知晓——降低后续沟通成本，避免扯皮，方便后续把控时间（产品经理）
例如：UI交付时间、后端接口/前端接口交付时间、联调时间、提测时间、测试开始/结束时间、上线时间
1）确定需求周期，方便跟进项目进程；
2）便于把控项目质量（按阶段验收，项目有异常及时知晓）
3）避免扯皮、甩锅
4）收集研发人员工作特点及信息，方便后续需求周期把控（例如：测试测的过于细致？研发新手可能会有阶段性问题？新项目前后端联调可能会有问题）
4.复盘：
目的：
1）复盘需求成果，鼓舞人心（失败的项目就是复盘失败的原因）；
2）需求周期内发现的问题产品经理需要记录下来，在下个项目时需要综合考虑进去
注：小项目产品经理自己复盘就行，大项目才需要开复盘会
