本文作者将就个人的工作经验，和大家分享作为设计师，同步项目信息的方法和原则。enjoy~
最近在工作中发现，身边的设计师喜欢埋头干活，项目的信息同步做得比较少。大家普遍有两个观点：
一来认为在事情没完成前，没必要告知别人；
二来，大家认为设计稿还没有完美，给大家看会有不好的反馈。
在大型团队合作中，这种观点非常容易导致一些问题。本文就我个人的工作经验，和大家分享作为设计师，同步项目信息的方法和原则。
项目同步是指：在合作中，团队成员因为各种原因，可能对项目最新的进度、风险、共识理解不一致，所以需要通过阶段性告知的方法，来保证多方理解一致。这个过程称之为『同步』。举例来说，项目周会，不可能保证每个成员都在场，所以在会议结束后，主持人需要同步会议结论，让没参加会议的人也了解项目进度。 由于设计师这个职位，注定大部分时候需要与别人合作。所以项目同步管理，是每一个职业化设计师的必备的技能。
项目同步就是解决：什么需求，在什么时间节点，针对哪些问题，如何组织信息，并同步给合作伙伴、团队内部& Leader。
先来理理在设计师工作中，由于同步不到位，可能导致的问题：
由于需求变更，导致设计稿修改，并出现项目Delay；
设计中沟通次数少，合作方对于最终方案并不买单；
产品不定Deadline，只说尽快出稿，但天天催稿，影响心情和设计效率；
按我在腾讯的工作经验，这些问题几乎每个需求都会遇到，那么如何去解决？这就是我今天分享的主题——如何建立项目同步汇报机制。
什么是机制
简单来说，机制即规范化，也是套路的一种说法。大到国家法律，小到设计规范，都是机制的一种。机制化之后，人们便可以无脑执行。
为什么要建立同步汇报机制呢？主要有3点好处：
书面化共识：留下Record，避免不必要的锅；
制约无序行为：花了半小时当面聊，无序的点很多，需要整理并形成约定；
让利益相关人了解进度：例如产品设计开发Leader，项目接口人都了解情况。
每个Designer都需要建立属于自己的汇报机制，这是成为Professional Designer的第一步。
那么如何去同步呢？基于经验，我认为项目同步前，要问自己这几个问题：
Who：和谁同步？
What：同步什么？
When：什么时候同步？
How：用什么方式同步？
与不同的人，同步的侧重点不同。在IT公司的工作中，典型有3类同步对象：
1. 项目组成员
Tracking：出问题方便溯源；
Organize：整理讨论中零碎的点；
Double Confirm：二次确认双方是否真正达成共识。
就我个人工作经验来看，第三点尤为重要。有时候大家认为达成共识了，但落在纸面上，分歧才会展现出来。根本的原因，还是双方的理解不一致。二次确认，能够最大程度的避免这种情况。
2. 组内同事
主要目标是同步结论，提高组内设计效率。典型的Case是去年，在某个项目的流量报表中，最大的流量来源叫“第三方Refer流量”，这个“第三方Refer流量”具体是指什么，问了很多设计师都不知道。经过和数据经理确认后，将含义同步在大群里，并发了邮件。
3. Leader
主要目标是同步风险，无论在哪个团队，风险预估都是非常重要的。尤其是运营相关需求，要特别注意风险管理。因为运营又要求创意，时间点又卡死，一旦出现问题，立刻向上反馈。在事情变得更差之前，让上级帮你协调时间和资源。
因为每个需同步的Case都不一样，我就讲一讲整理的套路。首先要确定你要讲什么？假设Leader突然问你，XX需求还没搞完么？此时应该如何回答？ 这里有2个模型可以帮助梳理内容：
1. WWH模型：
Why：起因
What：内容
How：方法
就刚才的例子来说，就可以回答为：产品经理因为XX原因，对设计稿不满意（Why）；所以我们需要多出几个方案（What）；今天我就在收集资料，尝试从XX角度给几个方案让大家一起讨论（How）。简单的问询，用WWH模型已经足够。
2. STAR模型
S = Situation（背景）：交代事情的背景；
T=Task（任务）：基于这个背景，需要完成哪些任务；
A = Action（行动）：这些任务，需要通过哪些行动才能完成；
R = Result（结果）：基于这些行动，可能产生哪些结果。
相比于WWH模型，STAR更加完整，适合从头到尾阐述一个需求。确定内容时，另一个重点是：每次只聚焦一个事情。一件事情只有一个重点，任何的讨论都不要偏离这个主题。
不同的内容，同步优先级不一样。对于同步共识来说，讨论结束就要乘热打铁，拉群输出，保证所有人都没有质疑。之前我与上海团队，跨区域团队合作时，我们形成同步机制，每次电话讨论完，结论立刻群里同步，避免忘记。 对于风险同步，则越快越好，且尤其要立刻同步给Leader。沟通工具优先级从低到高为：IM软件<电话<当面。对于IM软件（指用QQ／微信等）同步需要注意：对方没回消息，则不算同步成功。所有人忙起来的时候，都有可能忘看消息。如果没有回复，再次同步，防止出漏洞。
根据内容的复杂程度，选择不一样的同步形式。一般来说分为3种：
1. 简单，急切的内容
直接口头沟通，简单直接，但缺点明显。首先是你需要高度提炼信息，不能啰嗦；其次，听者可能未必有心在听。例如对方正在忙，有可能会被忽略。
2. 复杂内容
指需要讲清楚WWH，或STAR的内容。这类内容往往有前后逻辑，所以强烈建议通过IM软件／微信／QQ汇报。这样的好处是通过文字，可以鞭策和训练自己梳理清楚逻辑。同时也能对设计逻辑进行Review，查漏补缺。
3. 复合内容
需要使用PPT，Prezi等工具进行复杂的汇报和演讲。
同步原则
Point 1：三点逻辑
任何事情都要讲出1，2，3。这里讲工作中的例子，某天早上我们与合作机构开会，调研机构对于小程序的用法。电话大概打了1小时，双方很发散的讨论了很多事情。电话一挂断，设计负责人就总结出了，机构期望的3个小程序能力框架：
内容输出（视频、音频、文章、题库……）；
互动（留言板、讨论区、客服）；
销转闭环（买课、上课，可以复用H5的能力）。
所以在复杂的事情，也要训练出总结1.2.3的能力。本篇文章也是一样，每个节点都拆分了1.2.3。通过下图的Mindmap，可以看到清晰的1.2.3结构。
Point 2：收益逻辑
收益逻辑核心是“三讲一免”。在同步的时候，讲收益，讲好处，讲价值，不要讲没用的细节。一般来说，追责或者设计方案深度讨论时才用到细节。 应用一部电影，《穿Prada的恶魔中》Vogue主编Miranda的经典台词：
“我对你无能的细节不感兴趣” —— Miranda, The Devil Wears Prada, 2006
这句话精准的反映了人们的内心。除非有利益关联，所有人只看结果，没有人会对细节关心。
Point 3：汇报结果
和收益逻辑有点像。为了节约双方时间，同步时只讲结果，不讲或者后置过程，因为如果结果OK，没有人会关系细节。
同步进阶技巧
Point 1：坏消息早点说
坏消息早点说。这里我提到了第一位，大家一定要警惕坏消息可能带来的风险。如果不确定是不是坏消息，可以通过以下的“坏消息陷阱”模型来甄别，来看看你是不是掉进了“坏消息陷阱”：
（1）这事以前发生过，很好解决
No，世界万物都是在变化，团队的资源也在变化，以前能解决过并不代表现在能解决。
（2）Leader说，不重要的事情自己决定
No，问题的核心是，所有坏消息都是重要的消息。如果坏消息Leader不知道，一旦老板开始追责，从Leader到基层，责任一个都少不了。
（3）我知道所有事情
这是在一个职位上坐久的人，和自负的人经常会遇到的问题。当你自认为了解一切时，危机确有可能打的你措手不及。
（4）这事情我能解决
这是一个错觉，因为你不能保证在短时间，把事情看全。举例来说，某些需求可能看需求文档，只有2个核心页面，但其内部逻辑可能极其复杂。这些逻辑很难一眼就看出来。
（5）Leader／产品经理／合作团队应该知道这条坏消息吧？
一来，作为执行的基层，执行上遇到的问题，你不说他们怎么知道？二来，就算他们知道了，再确认一遍别人也不会怪你。
（6）我不用完整汇报；
No，坏消息需要同步，而且需要解释明白前因后果，方便追查到底是哪个环节出了问题。
Point 2：复述要点
指的是每次讨论完，将要点按照1.2.3整理出来，复述给对方。这样做有几个好处：
1. 检查认知
通过复述，看看双方理解是否一致；
2. 查漏补缺
人脑不是电脑会遗忘，双方一起Review可以降低遗忘概率；
3. 随时应变
对于有疑问的点，通过复述来二次讨论。例如基于讨论，你们总结出了1，2，3点。对于第2点你有质疑，此时在拿出来推理一番，是非常自然的；
4. 氛围建立
这是一个很好的合作附加值。情感层面，听与说的互动对于氛围的建立，远远好过无聊的一问一答。
Point 3：用最短的时间
这点有点难，这里我想表述的是：当你想的越清楚，说的越短。这个技巧没有什么捷径，需要通过不断训练才能达到。 今天的分享就是这些，希望能给大家一些启发和帮助。
参考资料：
Its Okay to Manage Your Boss, The step-by-step program for making the best of your most important relationship at work, Bruce Tulgan, Wiley, 2010.8
向上管理：如何正确汇报工作，蒋巍巍，人民邮电出版社，2015.8
