编者按：实习有一段时间了，今天 来总结一下工作中的沟通问题、长线任务的执行等，顺便解答一下很多同学的职业困惑，相当有价值的一篇干货。
本文为作者授权优设发布，未经作者本人授权请勿转载，谢谢 ：）
作者微信公众号：zhenlei_pd，欢迎同学们关注唷。
毕业季专题：
最近我开始做一件事，就是在下班后陆续和不同部门、不同岗位的实习生朋友约聊，一来是觉得「阅读」一个人的经历是一件超级有趣的事，二来也是想通过优秀的同龄人来认识自己，认识设计。对了，欢迎在杭州的小伙伴找我聊天，一起分享成长的故事。
好了，接下来说说这周的实习感受。
「每一次会议，都是一场无领导小组讨论，而代价，就是效率」
最近这一年，我养成了一个习惯，就是在和人聊天、讨论时，主动去记录讨论过程中的「里程碑」。非常容易理解，就是去刻意留意话题的走向，记住那些讨论偏移主线的「节点」。这样的好处就是，更能够清晰地看到跑偏的点，并且常常有能力把话题拉回来。
这周参加了几次人数较多的会议，上面小标题的这句话就是一个总结性的感悟。
我发现，工作中大家常常很惧怕开会，也经常被没有效率的会议弄得精疲力尽，花费了数个小时可能也没有得到满意的结论。说起无领导小组讨论，大家都懂得需要有人做 leader，有人做 timer，需要控制讨论的节奏和时间，引导团队产出一个一致的结果。不过很不幸，到了真正开会时，很少有人会记住这些。如果会议中没有明确的目的和控制节奏的人，大家的发散思维就会互相牵扯，干扰了原本的进程，也经常让发言者忘记了时间和主线 —— 尤其在会议人数较多的情况下。
所以，我觉得一次会议如果牵扯到比较多的人，就需要尽可能保障效率（说起来很简单），主持者要在完成自己会议目标的同时，主动记录那些「里程碑」，把拐走话题的节点及时卡住。
「闭门造车的下场，只有事倍功半」
前几天手上有一个需求，在结合自己的理解、师姐的建议和与产品经理的讨论后，都认为这种设计方式可行，改动不大却可能非常有效。由于刚来公司不久，还没有和开发同学深入接触，因此就凭着自己浅薄的客户端开发经验认为这个设计方案是容易实现的，于是就继续细化设计稿。
等到评审的时候，我发现自己的设计中，百分之七十的内容都被开发驳回了，原因主要在于方案不易实现。这里的不易实现绝对不是指开发的水平低或者故意推脱，而是我没有考虑到的一些复杂的业务情况。
举个例子，我想在某个页面修改一个弹窗的样式，并且增加两个入口，因为都是 iOS 自带组件的样式，我就默认这个内容很容易开发了。但事实是，这个弹窗根本就不是我们自己 SDK 产生的，属于「设计界限之外」，同时，我所希望增加的这个入口也会影响到后续页面中的业务逻辑。
所以结果是，我需要在评审后重新修改稿子，而在这之前，我已经花费了不少时间研究前一个设计方案。因此，在设计过程中，每一个不确定的点都一定要随时主动和开发、运营同学，产品经理一起沟通确认，永远不要高估自己对技术、业务和设计的认知，必须让专业的人做专业的事。
「分解任务、分解时间」
我是一个非常不擅长多线程工作的人，我也相信大多数人也绝不可能同时进行多项设计工作，最多也只是快速地切换而已。但在实际工作中，有很多长线任务，让我最为头疼。
所谓的长线任务，就是一时半会儿解决不了，即便你通宵两三个晚上也未必能马上得到结果的那种任务，它们的 deadline 可能在两三个月之后。这类任务让我难受的地方在于，我不知道每天该给它们分配多少工作时间和精力，也很难衡量一天的产出占总体的比例。最可怕的是，长线任务往往不具备有效的心理正反馈，常常让人做得很疲倦。
因此，把大任务分解成小任务，并且有条不紊地安排一整天的工作分配，是非常重要的一项能力。我尝试使用 wunderlist 和公司内部的任务管理平台来规划一天的工作，勾上每一个完成的小任务并且心满意足地去进行下一个。但是目前，我对大任务的分解能力还是比较薄弱，需要在后续加强。
「最不擅长的，却成了最需要的？」
对于动效设计软件，我其实很早之前就开始接触和学习了。从 Quartz Composer 到 Origami、从 Framerjs 到 Form、从 Keynote 到 Pixate、还有浅尝辄止的 Swift，甚至我还翻译了很多相关的教程并和朋友一起制作了粗糙的 Framer 中文网。但是很遗憾，缺乏实际项目需求的情况下，我并没有精通其中任何一样。
如果是之前文章中讲的很多体会都是设计中的「道」、「内功」，那么软件工具的使用就是「术」与「外功」。类似 Sketch、PhotoShop 和 AI 等软件，相信几乎所有的设计师都是信手拈来的，但是目前团队中动效设计还停留在一个比较初级的阶段。
台上十分钟，台下十年功。很多能力和技能的学习都应该在实际使用之前就准备好，在工作时间中边学边做，效率是极低的，同时还会影响其他工作的进展。这一周，我有超过百分之五十的时间都在做可交互的动效原型，不仅花费了大量的时间，最终产出的设计效果也不完美。
周五还和一位客户端研发同学进行了沟通，明确了 QC + Origami2.0 可能是目前设计与开发综合成本最低的一个实现方式。尽管 Origami 有较陡峭的学习曲线，但是它的 code export 功能却是其他所有同类软件都无法比拟的。
我决定，等到实习结束回学校到毕业的这半年时间里，会花更多的时间到动效设计中，争取精通 Origami 并掌握 Swift 在 iOS 中的前端效果实现。相信，这会成为很有竞争力的一个武器。