主页 > 洞察 > 设计沙龙 > 用户研究
  • 腾讯出品!设计师辅技手册之项目同步管理法

    adinnet / 2018-07-09 10:46 /用户研究

    更近在工作中发现,身边的设计师喜欢埋头干活,项目的信息同步做得比较少。大家普遍有两个观点:一来认为在事情没完成前,没必要告知别人;二来,大家认为设计稿还没有完美,给大家看会有不好的反馈。在大型团队合作中,这种观点非常容易导致一些问题。本文就我个人的工作经验,和大家分享作为设计师,同步项目信息的方法和原则。

    一、什么是项目同步,它的意义是什么

    项目同步是指:在合作中,团队成员因为各种原因,可能对项目更新的进度、风险、共识理解不一致,所以需要通过阶段性告知的方法,来保证多方理解一致。这个过程称之为「同步」。举例来说,项目周会,不可能保证每个成员都在场,所以在会议结束后,主持人需要同步会议结论,让没参加会议的人也了解项目进度。 由于设计师这个职位,注定大部分时候需要与别人合作。所以项目同步管理,是每一个职业化设计师的必备的技能。

    二、项目同步的核心

    项目同步就是解决:什么需求,在什么时间节点,针对哪些问题,如何组织信息,并同步给合作伙伴、团队内部& Leader。

    先来理理在设计师工作中,由于同步不到位,可能导致的问题:

    • 由于需求变更,导致设计稿修改,并出现项目 Delay;

    • 设计中沟通次数少,合作方对于更终方案并不买单;

    • 产品不定 Deadline,只说尽快出稿,但天天催稿,影响心情和设计效率。

    按我在腾讯的工作经验,这些问题几乎每个需求都会遇到,那么如何去解决?这就是我今天分享的主题——如何建立项目同步汇报机制。

    三、什么是机制

    简单来说,机制即规范化,也是套路的一种说法。大到国家法律,小到设计规范,都是机制的一种。机制化之后,人们便可以无脑执行。 为什么要建立同步汇报机制呢?主要有3点好处:

    • 书面化共识:留下 Record,避免不必要的锅;

    • 制约无序行为:花了半小时当面聊,无序的点很多,需要整理并形成约定;

    • 让利益相关人了解进度:例如产品设计开发 Leader,项目接口人都了解情况。

    每个 Designer 都需要建立属于自己的汇报机制,这是成为 Professional Designer 的第一步。

    四、如何进行项目同步

    那么如何去同步呢?基于经验,我认为项目同步前,要问自己这几个问题:

    • Who:和谁同步?

    • What:同步什么?

    • When:什么时候同步?

    • How:用什么方式同步?

    Point 1:和谁同步 – 确定同步对象

    与不同的人,同步的侧重点不同。在 IT公司的工作中,典型有3类同步对象:

    1. 项目组成员

    与他们主要目标是同步共识,同步共识的好处有3点:

    • Tracking:出问题方便溯源;

    • Organize:整理讨论中零碎的点;

    • Double Confirm:二次确认双方是否真正达成共识。

    就我个人工作经验来看,第三点尤为重要。有时候大家认为达成共识了,但落在纸面上,分歧才会展现出来。根本的原因,还是双方的理解不一致。二次确认,能够更大程度的避免这种情况。

    2. 组内同事

    主要目标是同步结论,提高组内设计效率。典型的 Case 是去年,在某个项目的流量报表中,更大的流量来源叫「第三方 Refer 流量」,这个「第三方 Refer 流量」具体是指什么,问了很多设计师都不知道。经过和数据经理确认后,将含义同步在大群里,并发了邮件。

    3. Leader

    主要目标是同步风险,无论在哪个团队,风险预估都是非常重要的。尤其是运营相关需求,要特别注意风险管理。因为运营又要求创意,时间点又卡死,一旦出现问题,立刻向上反馈。在事情变得更差之前,让上级帮你协调时间和资源。

    Point 2:同步什么 – 确定同步内容

    因为每个需同步的 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 更加完整,适合从头到尾阐述一个需求。确定内容时,另一个重点是:每次只聚焦一个事情。一件事情只有一个重点,任何的讨论都不要偏离这个主题。

    Point 3:什么时候同步 – 确定同步时间

    不同的内容,同步优先级不一样。对于同步共识来说,讨论结束就要趁热打铁,拉群输出,保证所有人都没有质疑。之前我与上海团队,跨区域团队合作时,我们形成同步机制,每次电话讨论完,结论立刻群里同步,避免忘记。 对于风险同步,则越快越好,且尤其要立刻同步给 Leader。沟通工具优先级从低到高为:IM软件<电话<当面。对于 IM软件(指用QQ/微信等)同步需要注意:对方没回消息,则不算同步成功。所有人忙起来的时候,都有可能忘看消息。如果没有回复,再次同步,防止出漏洞。

    Point 4:用什么方式同步 – 确定同步形式

    根据内容的复杂程度,选择不一样的同步形式。一般来说分为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:用更短的时间

    这点有点难,这里我想表述的是:当你想的越清楚,说的越短。这个技巧没有什么捷径,需要通过不断训练才能达到。

    今天的分享就是这些,希望能给大家一些启发和帮助。


    本文转自:https://www.uisdc.com/project-synchronization-management-method

上一篇:超全面的导航设计基础知识总结(一) 下一篇:掉进这6个陷阱,可能会毁了你的原型设计!