网易严选交互团队的管理方式进化史

管理团队是一个艰巨的任务，不仅需要管理者的智慧，也需要具备相关的管理知识。本文作者从具体的工作分工、文档管理分发和人员培养这三个方面出发，分享了网易严选交互团队管理方式的进化，与大家分享。

今早看到一篇大众点评研发团队项目管理优化的文章，脑海中一瞬闪现了这几年带严选交互团队的工作方法渐变历程，于是乎想趁热写一篇文章。

严选交互团队从2015年至今，一直维持在4人规模，承接的工作包括：移动端/WAP/PC/小程序/部分后台/运营活动/交互规范制定。

2015年开始做严选项目，只我一人负责交互，当时带着设计团队（严选启动时设计团队只有5人，还包括1个实习生）。后来我开始专职负责交互工作，2016年才社招到麻译天同学进入团队，同年7月2个校招同学翟翼畅和柴蒙入职，从此4人团队一直合作到现在。

由于工作责任、团队规模、项目扩展、合作团队工作方式等变化，我们交互团队的工作方式也在不断的调整。所以这篇短文就是简要的讲一下严选交互团队的工作方式渐变过程。

AXURE的团队协作功能我们使用了仅2年，后期也发现一些问题：

一个文件内页面较多时，迁入迁出比较费时，也偶尔会出错有些需求会做版本调整，从团队文件中移除加入到另一个文件是常有的事团队协作还是不如个人管理自己的需求文档灵活

于是，从18年Q4开始，我又让大家放弃了团队协作功能，APP的每个功能单独导出为文件，放入一个版本文件夹，从而减少了很多文档迁移消耗的时间，而对上下游查看文档并没有影响。

其他：

为什么一直用FTP？杭研以及邮件也有一个文档管理平台，我也尝试过，但从文档的层级和版本管理来说，都不能满足我们的要求。而我们目前用FTP，管理分发效率最高，同时也做了一些加密处理，安全性也有保证。所以从工作效率角度，我还是继续使用FTP。

交互文稿的两个注意点：1 要有更新日志，从交互评审定稿后，记录后续增加的修改点 ，同时修改的地方要打时间戳  2  要有需求目的，并不是所有相关人都能去参加交互或更早的产品策划评审，有些方案定稿后，可能要等很久才进入开发阶段，所以要有地方让相关人员去了解这个需求的价值。

三、人员培养

关于人员培养，其实这三年我是精力放的最少的，当然主要原因也是需求太多，大部分时间放在完成需求上。我这边大概从几个方面去做人才培养：

新人加入到团队，需要熟悉工作方式，这里我指的是交互设计的方式方法。可能你之前用别的软件做交互稿，但是我这边使用AXURE，那你也要用这个；阅读交互稿的规范，保证交互文档内的样式一致；阅读已有的交互稿（不需要全部），去了解业务。这个阶段大概1周到2周的时间。但一般来说第2周就要开始做一些需求了。

因为精力有限，关于专业能力的提升，我还是主要通过审核交互文档时对设计师进行一定的指点，给出设计方法和理念，几乎没有去做专门讨论设计的会议，除了周会和对外交流会。

这点是我强调和推动组内设计师做的最多的，希望的是大家不要只关注设计本身，也要从其他角度，比如产品、运营、市场、技术、数据等多方面去思考，做出提升业务效益的设计，所以有些需求我们交互也承担了产品的角色。

通过数据平台、用户反馈，去挖掘需求。每个季度的绩效也是要有一定比例根据业务的数据表现来考核。

写文章和做分享，这两个虽然是有一点功利性在里面，因为多少会和每年的CPP评审有点关系。但对设计师个人来说，半强迫式的去花时间思考总结自己的工作和设计，去有机会锻炼演讲能力，还是有实际意义的。所以组内所有人还是在2年内每人都做了至少实践者论坛或者一级部门内的分享，都向UEDC月刊投了文章。

后记

这篇文章确实是一时兴起写的，总共花了三四个小时，所以里面内容比较干，对我本人来说，是快速的反省了一下这几年组内的一些管理方式的变化。之后可能根据项目的扩大，也会补充新人，可能从明年开始，我会拿出较多的精力在人才培养上了也说不定。

*以上文章2018年在网易内部论坛发表，今天才拿出来分享。

本文由 @re1937 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。