会议制度
有个理论叫"会议有毒"，大意是：如果一个会议大于10人，那么一定会有人全程不相关，那么就会造成时间的浪费。但是有些会议还是必须设置的，会议也是保证团队健康的一个方法。为此以下介绍几种会议的方式和流程。
晨会
部分团队选择每天早晨进行十分钟晨会，晨会主要是每个人陈述给你当日的工作。晨会建议全程站立而不是在会议室坐在舒适的椅子上懒洋洋地进行。晨会时如果发现工作不均衡或者有些员工没有分配工作，你需要及时地调配和分配工作，不要把压力放在一个人上。哦对了，不要搞混淆了，我不是让大家像理发店一样清晨喊口号，而是利用早晨的时间确定好一天的工作量。晨会在工作较为繁忙或者团队稳定时也可以取消，并不是必选项。
设计师的会议 by rawpixel
夕会
如果团队目前状况非常复杂，人员工作分配不均，光凭借晨会无法梳理好流程时，你也可以采取一段时间晨会+夕会的方式来纠正一些工作的问题。夕会顾名思义是在下班前开的十分钟会议，同样采取站立形式，由总监主持，每人轮流陈述今天工作的进度和遇到的问题。如果遇到了一些问题你也可以及时发现并解决。当然晨会和夕会一共会占用全天工作时间的二十分钟左右，有些成员可能会表现出对会议比较抗拒，所以如果团队运转正常，也可以减少这些会议。
季会
我们把一年分成四个季度，即Q1、Q2、Q3、Q4。每个季度长度为3个月，每个季度结束时都会对整个团队经手过的项目进行一个review。这个工作非常重要，因为漫长的时间会把设计师的激情磨平，每个季度结束时让设计师们看到自己在团队中所处的水平和所有人的工作量对于那些积极工作的设计师非常有刺激作用。这个会议由你组织，需要有助手来负责做记录，每位设计师呈现自己一个季度的工作并做工作报告。你可以为每位设计师进行打分，这个分数在年终相加可以评出优秀员工和晋升名单。
不同会议针对的目标也不同
敏捷开发
现在你发现整个公司和你的部门格格不入：除了设计部门之外的研发部门使用敏捷开发和最小化可用产品来管理团队和驱动产品，那么作为协作部门的leader，你有必要知道什么是MVP、什么是敏捷开发。然后甚至可以将敏捷开发中适合团队的管理方法带入设计组。
最小化可用产品 MVP
我们之前介绍过大公司的组织结构，应该有用研部门研究用户、交互设计师优化原型等。但是很多公司人员并不齐备。其实，绝大多数的创业项目初始阶段是不太清楚用户真实的需求是什么的，并且也没有资源去研究用户。因为建立一支用研团队的经费是比较巨大的。那么一个创业型公司是如何确定用户需求的呢？了解一下最小化可用产品。最小化可用产品（Minimum Viable Product，简称MVP）是一种避免开发出用户并不真正需要的产品的开发策略。简单来说就是，团队快速地构建出符合产品预期功能的最小功能，比如微信的最小可用功能应该是基于通讯录聊天、支付宝的最小可用功能应该是扫码付款。而微信的朋友圈和支付宝的订阅号等都属于附加功能。如果我们是以上两个产品的创始人，如果我们没有用户研究的条件，那么就简单描绘一个用户故事，即用户使用我们的产品和用户的画像，然后把最小化可用产品做出来。举微信的例子，那就是一个进入后同步通讯录可以语音聊天的应用程序。其他功能都没有，仅仅是核心功能，然后放到市场上看用户的反应。如果用户接受了核心功能，那么我们可以围绕着核心功能打造比如发图片、朋友圈、表情等附属功能。如果用户连最小化可用功能都没有接受，那么代表产品需要重新思考。
同样，介绍一下小规模互联网公司常用的工作方法：敏捷开发。1986年，竹内弘高和野中郁次郎阐述了一种新的工作方法，这个方法能够提高产品开发的速度，他们将这种新的方法用橄榄球里的术语命名。后来这种工作模式被国外很多团队推崇，一时间在国内外的互联网公司非常火爆。这就是我想介绍的工作方法：Scrum 敏捷开发。敏捷开发主要应用在产品开发团队中比较多，设计师也是其中一个角色。一般来说，如果你的团队是三人左右，那么可能设计师会被划分成敏捷开发里的一个成员。如果你的设计团队发现设计师们不太擅长时间管理，也可以在设计团队内部使用敏捷开发工作方法。
敏捷开发中的角色 Role
在敏捷开发中有不同的角色。产品负责人 Product Owner： 一般是产品经理担任，负责整体项目的时间节点协调和解决每个环节上出的问题，基本上和产品经理本身的工作很相似。团队主管 Scrum Master： 这个职位一般是由团队中的技术领导或者项目经理来担任，负责解决开发过程中的疑问，同样要对时间节点负责。开发团队 Team: 开发团队是剩下的所有人：设计师、测试人员、程序员等。
敏捷开发中的User Story
每一个需求被称为user story，即用户故事。这样做的好处是保证每个需求都是以用户为中心设计的。比如产品经理希望完成一个分享功能，那么应该描述为"某用户在使用相册功能时希望可以分享这张图片，因此需要分享功能"。在敏捷开发中通常用户故事并不是由用户调研得来的，而是根据产品经理的判断和用户画像而来。
敏捷开发中的优先级
类似我们上文介绍的时间管理方法，需求需要根据优先级排序。优先完成重要且紧急的需求，然后排序。这个过程由PO来完成。设计团队由设计团队的负责人来划分每个需求的不同权重，优先完成重要且紧急的。
敏捷开发中的冲刺Sprint
橄榄球不是要疯跑吗？所以用来比喻产品的研发阶段很合适。每个冲刺的时间由团队共同决定。一般来说是半个月或者一个月，比如某产品的新版本迭代冲刺。在冲刺之前，会开计划会 （Sprint Planning Meeting）。这个会是在每个冲刺之初，由产品负责人（产品经理）讲解需求，并由开发团队进行估算的计划会议。这个会的职责就是每个角色（包括设计师）确定好自己需要完成的任务和交付时间。然后全体的需求都要在这个冲刺内完成不得延期。在冲刺开始后不允许产品经理额外增加需求。
敏捷开发中的例会
在冲刺阶段，每一天都会举行项目状况会议，被称为"每日站立会议"。会议准时开始，迟到者常常会制定惩罚措施，比如做俯卧撑等。所有人需要站着开会，不管团队规模都只能十五分钟完事。在会议上，每个团队成员需要回答三个问题：今天你完成了哪些工作？明天你打算做什么？完成你的目标是否存在什么障碍。Scrum Master需要记下这些障碍并帮助解决。每一个冲刺完成后，都会举行一次冲刺回顾，在会议上所有团队成员都要反思冲刺中自己的问题和经验。会议的时间限制在4小时。
产品需求池Product Backlog
产品需求池就是我们把需求分为：未开始的、进行中的、审核中的、完成四个大分类然后进行管理的一种方式。在工作当中其实很多时候都会被多线程的任务搞糊涂了，如果应用了产品的需求池方法就可以轻易地管理工作了。作为一个总监可以为十人内的团队统一建立一个产品需求池板，使用一面空白的墙和便利贴就可以。然后把这个板子划分为四个区域，把不同的需求写上认领的人员贴到相对应的位置（比如：公司网站首页设计 重要且紧急 预估时间：3天 设计师：小张 贴在未开始处）。谁有多少个在完成的项目，谁吃的工作量最多，谁现在在做无关紧要的项目所有人都可以一览无余。
便利贴形式的产品需求池 by Daria Nepriakhina
电子版的产品需求池
提供进步通道
一个设计师在工作中其实长期会处于输出的状态。公司花了金钱来雇设计师，当然不是让我们来"成长"的。公司提供薪资，设计师提供优秀的设计，这是最起码的公平。那么在工作上你无法被"带"（很多设计师竟然求职时天真地要求公司一定保证自己的进步），那我们怎么进步呢？进步就需要输入了。如何输入一些知识保证自己一直在进步呢？
网络资源
现在关于任何设计门类的网站、公众号、博主都非常多，我们生活在一个资源触手可及的时代。不管您从事什么职业，相信你都能很轻易地订阅查找到很多设计知识和资源。那么我们可以利用好这些资源，在碎片时间（碎片时间指的是你上厕所、等公交等的琐碎时间）进行阅读和学习。这些知识比较偏向理论型知识。
下班后的练习
远离了工作的需求让我们头脑更清醒，你可以发现自己的短板，相信大家都听说过木桶原则（即最短板决定每个木桶能装多少水）然后加强这个短板的练习。比如我曾经图标是最薄弱的项目，我花了两年时间下班后在家做大量的图标练习，直到自己的图标能力在工作中被认可。所以各位leader也可以建议自己团队成员在下班后补齐自己所欠缺的能力。
输出是知识的印证
本身我们的工作就是一种输出。那么工作包括的种类很多，APP的设计、网站设计、运营图设计、皮肤设计、表情设计等，这些都需要我们去输出自己的存货。为了我们的输出平时要多积累知识和练习能力才行。
总结
其实做管理，成为leader很令人兴奋，可是兴奋背后是责任和重担。蜘蛛侠说过：能力越大，责任越大。所以如果您决定自己的职业生涯要朝管理方向发展，你就要有一定的抗压能力和学习能力，抗击那些不被人理解的压力，也要学习那些自己不会的知识，离开自己的舒适区。总之，尽管被人叫做leader，我们仍然是和大家一起成长的团队成员。希望你能真正做一个合格并称职的leader。
FEVTE编注：更多平面设计理论学习请访问飞特网平面设计理论知识栏目，地址：https://www.fevte.com/plan/shejililun/
飞特游客
委托设计