我知道设计师很苦，设计师很累，设计师总在加班而且薪水还不高。

我当然知道很大部分要归功于“甲方”这个奇特的物种。但我们有没有想过，这里面其实也有设计公司自身的原因？

设计管理者有没有真正地起到组织协作的作用？仅仅是把控方案就可以了吗？还是在设计管理中，缺失了什么角色？

我们先来看看设计师不停加班，是哪些直接原因导致的。

01什么叫“完成了”？

小组长把一个项目分解为若干任务后，给设计师说：你去做这个部分吧。设计师做了一轮给小组长看，小组长说，我不是这个意思，你应该这样这样……设计师又修改一轮，小组长再看，发现还不是他想要的……提意见，又改……

直到双方都失去耐性，暴跳如雷——其实大多数情况下是一方暴跳如雷，另一方脸上挂着礼貌的微笑，心里一万匹草泥马奔腾而过。

02多头管理

设计师做了一轮方案，拿给小组长看，小组长说我觉得这样可以了。过了一会儿，设计总监/总经理/老板来巡视，看了看，给了点建议——这些建议恰好跟小组长的意见不一样。你说设计师是改呢？还是改呢？

刚根据设计总监/总经理/老板的意见修改了一轮，甲方经理张富贵儿又来蹲点，看到这个方案之后，又提了一堆意见，还跟前面设计总监/总经理/老板说的不一样！你说设计师是改呢？还是改呢？

含泪按照甲方经理的要求改了一轮，去甲方汇报，发现甲方城市总说的跟甲方经理张富贵儿说的又不一样。你说设计呢？还是改呢？

……

其实，还有很大概率，城市总后面还有区域总……

03不停变化的设计条件/提交日期

说好了下周一(别问我为什么总是周一早上要，反正我知道他们就爱这么干！)提交概念方案，甲方(这个神奇的物种)总是会在周五下班前打电话来说场地内有栋老房子，不能拆了，总图要改……

这里还有两种可能性，也不知道哪种情况对设计师会好些……

可能性一：提交时间还是周一早上。本来以为周末的白天泡汤了，这才发现连晚上也泡汤了。

可能性二：经过小组长要求恳求，甲方终于同意延后提交的日期到周三。周二晚上，甲方又来电话了，经过一番运作，那栋房子又可以拆了……

设计师：后面我还是悠着点做吧，反正都要改……

这里面当然有甲方这个神奇物种的原因，但设计管理者也有着重大缺失，才造成了这种疲于奔命的局面。普遍意义上讲，很多人一开始的时候都想不清楚自己到底要什么，公司更是这样，本来这也正常。设计管理的重要职责之一，就是帮助业主梳理清楚需求。在互联网行业，产品需求梳理是非常重要的工作，是开启产品设计的前置条件。

软件开发行业最开始的时候是借鉴建筑设计的管理经验，甚至连职位都是。“架构师”的英文就叫Architect。后来软件行业对项目管理的重视程度高过设计行业，进入互联网时代之后，更是将设计行业远远抛在了后面，形成了非常完整系统的项目管理理论框架和具体操作原则。

前面提到的设计公司管理中出现的这些问题，在互联网产品开发行业都能找到对应的管理框架，来改善这种疲于奔命的状态。

04Scrum(敏捷开发)

Scrum管理框架，是萨瑟兰(JeffSutherland)和苏瓦博(KenSchwaber)在年提出的项目管理框架，之后在软件开发行业以及后来的互联网产品开发中得到了广泛的应用，并且还得到了更多的扩展，发展出了更为细致的使用方法。Scrum管理框架中的很多概念，对前面提到的设计管理问题，都会有很大的帮助。

05冲刺-锁定近期工作量

Scrum管理框架的诞生，出发点就是为了应对不停变化的市场(工作起始条件)。在Scrum管理框架认为，过长时间跨度的任务详细规划是没有作用的。“过长”的具体定义就是，超过两周都太长，实在不行，最多一个月。所以Scrum要求将长期计划划分为若干个“冲刺”(Sprint)，每次工作只聚焦于本次冲刺。一个冲刺的周期是一周到四周，最好是在两周之内。

每个冲刺开始之前，需要明确这一次冲刺要达到的目标，然后将这个目标分解为若干任务。一旦冲刺开始，在这一次冲刺结束之前，任务不可变更。如果中途还有什么需要增加或是变改的内容，记录下来，可以考虑进入下一次冲刺。采用这样的方式，就可以避免不停变化的设计条件造成交付日期一再变更。

冲刺中间，甲方修改了条件，如果并不影响整体方向，设计管理者可以记录好变更需求，进入下一个冲刺，本次冲刺继续按照原计划完成，形成完整的工作成果。下一个冲刺准备会中，将变更条件跟本次冲刺成果对照，形成新的冲刺计划。

如果条件变更影响到了整体方向，可以立即停下本次冲刺，召开会议，研究变更，开启一次新的冲刺，重新确定成果要求，分解任务，跟甲方商量新的交付节点。

如何分解设计项目？-大海聊设计管理

06项目拥有者——团队只听一个人的指挥

在Scrum框架中，有各种角色，对每种角色的职责有着清晰的界定。其中的“项目拥有者”ProductOwner是开发团队的直接领导，所有意见都应该汇总到项目拥有者，项目拥有者整理之后，在分解成任务，交给开发团队。在冲刺中，所有队员都只对项目拥有者负责。

项目拥有者对应到设计项目中，那就是设计团队的小组长。在每一个冲刺中，设计师都只执行小组长的任务和意见。

项目拥有者/小组长同时还必须决定什么算是“完成了”，而且还只能由他来决定。也就是说，在冲刺中，只要小组长说，这个可以算是完成了，那这个任务就是完成了。即便是他决定错了，其他人也只能指出来，在下一次冲刺中去修订。这样就能避免让设计师无所适从的多头管理。

向IT行业学管理-项目团队中的角色-大海聊设计

07“完成”的定义

Scrum的一个冲刺下有若干任务，而每个任务要怎么样子才算是“完成”了，是安排任务的时候必须定义清楚的。很多设计管理者，安排任务的时候，只是叫设计师去做什么，但没有表达清楚，做到什么程度，怎么样子才算是做好了。按照Scrum管理框架，只是说清楚还不够，还必须写下来，并且给出验收标准。我在之前的视频内容中，介绍过我们管理设计项目时候的任务分解方法，以及对“完成”的定义。每一个任务交代出去的时候，至少包含三项内容：

任务导则。也就是设计要求细则。

样图。给出类似项目的样板，要求设计师参照执行。

检查表。任务完成后，打开检查表，一项一项勾选，检查是否达到了要求。

这些方法在我之前的视频栏目中有详细介绍：

这样子设计师拿到项目的时候就清楚究竟做到什么程度才算是“完成”，不用在工作的过程中，不停找管理者试探要求，浪费时间和精力。这对设计管理者而言，也会节约大量的精力。

08敏捷教练(ScrumMaster)

这负责组织整个Scrum和冲刺的角色。如果硬要翻译，可以叫做敏捷教练。对应到(建筑)设计行业，有点像某些外企的PM(项目经理)。这个角色不是技术岗位，只负责组织工作。描述这个角色的英文很有意思，ServantLeadership。也就是说，这个角色既是领导者，又是服务者。他的职责就是为冲刺中的设计团队扫清一切前进的障碍。

ScrumMaster在理解到产品经理指定的设计目标之后，负责组织整个团队将大的目标拆分为小的任务，评估故事点，开启冲刺。

对于没有设置专职项目经理的设计公司而言，这个角色也会由设计小组长兼任。他就需要同甲方商量合理的交付节点，设定每次冲刺的目标和交付内容。

每次冲刺开始之时，组织冲刺准备会(SprintPlanning)，确定任务之后，封闭需求。

冲刺中，他需要组织每日立会(DailyScrum)。没错，就是“立会”，因为需要简短，所以要求站着召开，一般限时10分钟。每个成员只说三件事：

我昨天做了什么。

我今天准备做什么。

还有什么因素阻止了我的工作推进。

冲刺结束后，敏捷教练需要组织团队召开冲刺评审(SprintReview)和冲刺回顾(Retrospective)。冲刺评审就是大家一起检验冲刺的成果是否符合冲刺准备会的既定要求。冲刺回顾是要看看大家在相互协作方面，有哪些做得好的地方，有哪些不足，需要改进。

09可持续的工作节奏

Scrum框架强调团队必须要有可持续的工作节奏，这也是敏捷教练的重要职责。如果管理者总是制定不切实际的工作计划，设计师们就会认为反正怎么折腾都完成不了，那还不如划水应对。Scrum特别强调队员的积极性和主动性，注重冲刺达成的成就感和满足感。设计公司是完全可以学习的，每次制定好冲刺计划后，严格执行，保证团队中的每一个设计师都能够知道所有的工作内容，每天都了解到整个团队的进度，也明确知道冲刺结束的时间，这样子才有可能主动安排好每天的工作量，保证持续的精力投入，创造性和责任心。

10设计公司内部管理改进空间

对大部分设计公司而言，跟互联网行业相比较，管理方面投入的