信息同步

这部分主要介绍什么是信息，信息传递的形式，信息传递的方法以及如何检查信息传递的结果。

什么是信息

信息: 是用来消除随机不确定的东西。
信息技术: 是用技术来消除随机不确定的东西。

信息的传递

信息从A->B的过程。

信息同步的方法（原则）

信息同步的原则有5点，按照优先级排列如下：

• 数据:用数据说话。
• 事实:任何人说都一样。
• 经验:历史发生过且讲述人能够确定已经发生过。
• 预测:无经验可借鉴，基于现有状况预测。
• 观点:发泄。

5点之间的联系如下：

• 最好的方式就是摆事实，而数据是最好的事实。
• 能用经验解决的事情不要猜。
• 汇报只有数据和事实。用简短的数据和事实来描述而不是试图通过详细的前因后果将事情讲明白

这一点是我做的最不好的，也是很多研发在表达的时候往往容易犯的错误，在表达事情的时候，总希望用严谨的逻辑将事情的前因后果完整的讲述出来，而这些东西对于接受者来说可能意义并没有想象的那么大。

• 避免无用的发泄。发泄是最解决不了问题的方式，所以尽量不要用。

信息传递的模式

• 点对点
  点对点的典型使用场景及优先级为：打电话 > IM文本 > IM语音(底线) > 邮件(代办/留证）。
• 点对多
  点对多的典型使用场景为：培训，任务传递，周会，晨会。
• 多对点
  多对点的典型场景为：汇集意见做决策。
• 多对多
  尽量避免，除非脑暴，闲暇时讨论以促进创新。

如何有效的进行信息传递

增强信息重要性

• 多次确认，强调性重复（不断提醒），循环式（周期性提醒）不能常用。
• 将情绪和态度融入沟通，用情绪表达信息的重要性。
• 前置计划加不断提醒：提前约定，前置越久提醒越频繁，说明事情越重要 对有拖延症，PDCA做的比较差的很有用。
• 同步背景信息，且具备分析能力
• 加入与接收方利益相关的元素

增强信息的权重

• 社会标准逻辑，位置越高权重越高
• 谁是责任人，责任人的权重大。（比如信息同步不到位，CEO要背锅）。
• 主管大于指引人
• 表达出对信息内容的重视。
• 表达出对该信息投入的精力。（比如我为此总结了两个月）。

抓好信息同步的时机（这部分有些散乱，需要进一步整理）

• 避免滞留，信息要在每个节点都得到快速的处理，这样在整个信息传递链上才能流动的最快。
• 执行力:做事的能力和态度，要用严谨的态度处理事情，但能力是基础。
• 周期性传递，符合PDCA.
• 信息传递越快越好
• 自己做不了的，尽快同步，寻求外部助力
• 代办管理，周期性代办

如何衡量信息传递的结果（确保信息差被消除）

• 发起人来确保信息传递的结果

如果你是信息同步的发起方，你就有责任跟进信息的传递并确保信息有效的得到传递。

• 反复加重复加强调 不断重复是一种很low也很容易让人烦的确保信息差被消除的方式，但是适用于以下场景：
  • 信息同步双方非常熟悉
  • 信息非常重要（值得用任何方式传递）。
• 提问 通过提问以及检查对方的反馈也是一种非常有效的方式。是二次确认在现实中的应用。使用场景是信息的发起方不仅需要接收方接收信息，还需要接收方理解信息。
• 检查结果：数据和事实 可以通过检查信息所涉及工作的结果来确保信息得到了有效传递。
• 复述 让接收方重复发送方的信息内容。复述可以是简单的重复描述，又或者是对接收放信息的理解总结。
• 抄底方案 信息同步的开始最好有抄底方案，即如果不能达到信息同步，至少要有一个不是最优的但是可行的方案。

比如在讨论设计方案的时候，可以先给出一个可行的方案，可能很烂，不容易维护，但是可以解决当前问题。然后再进行讨论，看有没有更好的方案。这样即使讨论没有结果，至少还是有一个抄底的方案的。

如果我们只是想做简单的信息文字传递，复述是个很好的方式，但是要确认接收方理解了要传递的信息内容，则可以以提问的方式。

思考与延伸

• 信息传递的换位思考 我们既是信息的发起方，在对待不同的接收方，我们有以上方式来促进信息保质保量传递到对方。 同时我们也是信息的接收方，当发送方用不同的方式向我们传递信息的时候，其实也是对我们的信息接收能力的综合评价。
  Example: Anna最近在不停的催我看简历，每天好几次。 当她用这种方式对我同步信息时，我在处理这个信息上，被评价为”拖延症“患者，所以要在这方面做改进，尽快响应不要拖延。
• 如何改善信息同步不到位的现状 理论来源于实践，但其更大的意义在于指导未来的实践，所以根据理论，结合实际场景制定出最佳的工作实践是非常重要的。 比如对于一整个研发流程，目前我们有很多问题。

场景1

• 场景描述: 研发同学会抱怨产品的需求给的不明了，做需求的时候需要反复的去问，完善的需求文档有利于研发把设计做的更好（反复交互，低效）。
• 流程规范与改进: 需求同学在出需求的时候需要尽量详细的给出需求（不一定是非常冗长的文档，但针对需求点，要将核心case描述到）
• 量化评价标准: 以研发在和测试在需求评审之后跟需求方确认需求的次数来衡量，如果确认次数少于3次，可以认为需求文档中的信息是相对全面的。

场景2

• 场景描述: 研发同学跟测试同学提测，跟测试同学说功能开发好了，但实际测试同学测试的时候发现，研发的很多功能是没有开发好，没有自测好的。（反复交互，低效）
  流程规范与改进: 需求评审后， 测试同学给出功能的测试用例表，研发在提测之前必须将该表中的用例全部自测过之后再提测。
  量化标准: 测试同学测试的时候用例中的case除非有特别异常的应该全部跑过，有一个用例跑不过，责任就在研发。如果有用例是测试没考虑到的，责任在测试。

场景3

• 场景描述: UI同学有的时候自己更新了图片，没有同步给研发和测试，或者同步了但只是在群里说一句，但是研发和测试并没有收到。（信息没有同步到位）
• 流程规范与改进: 将信息同步的责任方划归到UI同学，如果研发和测试不知道更新了这张图片，则这张图片没有更新的责任就在UI同学。规定UI同学需要当面只会研发和测试，且当面得到已接收确认。
• 量化标准: UI同学没有按照标准操作的次数。

总结

• 信息同步在项目实践中很重要的一个点是权责分明, 必须把责任方划分清楚，才能将责任转化为动力和压力，从而促进信息的快速和有效传递。
• 如果信息接收方对信息的获取是周期性的，那么信息接收方应该制定信息内容的基本规范与标准。

个人犯错

脑暴