项目同步管理法 - 设计师辅技手册(三)

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

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

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

项目同步的核心

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

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

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

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

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

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

什么是机制

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

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

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

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

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

如何进行项目同步

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

1. Who:和谁同步?

2. What:同步什么?

3. When:什么时候同步?

4. How:用什么方式同步?

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

与不同的人,同步的侧重点不同。在互联网公司的工作中,典型有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个小程序能力框架:

1、内容输出(视频、音频、文章、题库……);

2、互动(留言板、讨论区、客服);

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


感谢阅读,本文由 腾讯ISUX 版权所有,转载请注明出处,违者必究,谢谢您的合作。注明出处格式:

文章来自公众号:

腾讯ISUX (https://isux.tencent.com/articles/sync-design-project.html)

原文发布于微信公众号 - 腾讯ISUX(tencent_isux)

原文发表时间:2018-05-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏花叔的专栏

七天内提醒一次,玩转模板消息

话说在花叔大学年代,曾经跟一帮有意思的同学们组建过一个工作室,名字叫“艾维前端”(http://www.i-wui.com/)。 虽然到现在那个官网还在,但是其...

2846
来自专栏java一日一条

游戏编程十年总结

自敲第一行代码起,已经十年多了,今天既不是十年整的日子,也不是一个有特定意义的日子,本来像这种大总结的文章,当择良辰吉日,斋戒沐浴三日,方可动笔。一开始计划是写...

871
来自专栏程序员宝库

法国政府搞的一个软件项目,坑出新境界

【编者按】:很多软件项目开发时间大大超出了规划的时间,投入大量资金和人力,都没有实在的结果。如果你讨厌你的编程工作,请认真阅读这篇 2008 年的文章吧。法国科...

1113
来自专栏禹都一只猫博客

评程序员和会不会修电脑到底有几毛钱关系?

额...工作或者学习中总会有人找身边的程序员修电脑,加班加点的工作之余,还得兼做电脑维修。

582
来自专栏腾讯社交用户体验设计

Apple Watch平台认知与产品设计 - 腾讯ISUX

1194
来自专栏Java学习网

开发者,速度远比你以为的重要

开发者,速度远比你以为的重要 效率高的明显好处是——单位时间内,能完成更多工作。但这只是冰山一角,假如工作速度快,你就会倾向于低估做事的成本,因此乐于完成更多工...

2287
来自专栏Java架构

金三银四跳槽季,阿里面试刚回来的总结——干货!前言:面试总结总结:

1484
来自专栏智能算法

最令程序员沮丧的十件事

er双旦快乐~! 软件开发是一个伟大的工作——和任何其他工作一样,它也有它的缺点。下面的十件事就是大多数程序员关于编程所无法苟同的。 对于非软件开发人员来说,...

2595
来自专栏java一日一条

最令程序员沮丧的 10 件事

软件开发是一个伟大的工作——和任何其他工作一样,它也有它的缺点。下面的10件事就是大多数程序员关于编程所无法苟同的。

843
来自专栏VRPinea

VR开发快速入门小诀窍——选对一款VR开发工具让你事半功倍

2987

扫码关注云+社区