辽宁白癜风医院 http://pf.39.net/bdfyy/bdflx/171107/5824583.html

PhotobyNataliePedigoonUnsplash

项目

在建筑，景观，规划设计及其相关领域，“项目”一般有着比较大的工作量，会有多人参与，持续较长的时间。我们需要将项目拆分以后，才可能交给不同的设计师来协作完成。

设计行业一般会按照“阶段”来对项目进行拆分。例如建筑设计中的方案，初设，施工图阶段。“阶段”中再分专业，再拆分到设计师。

按照IT行业的概念，设计行业的各个阶段之间，有非常强的“依赖”关系。就是下一个阶段的工作严格受上一个阶段的制约，如果改动前一个阶段的内容，后面的全部都要做相应的改动。

设计工作的开展，都是根据甲方的需求来进行的。问题出现在，甲方的需求会不停地发生变化。这也难怪，很多设计项目都需要甲方不停地做决定，而后面的决定跟前面的决定之间也是“依赖”关系。每一次决定都会把项目带向某个方向，最终会走到哪里，没有人能够在开始就预见清楚。

IT行业的产品开发也是一样的，没有大神一开始就能完全猜中用户究竟要什么——更多的时候，用户都不知道自己要什么。IT产品也就是小步快跑，快速迭代，不停把新的版本提交市场，让用户来进行验证。

在Scrum管理框架中，每一次交付迭代，就叫做一个

冲刺

这个跟设计行业交付一次文本或是一次设计汇报，是一样的。

冲刺开始之前，需要明确的要素如下：

需要达到的目标。

明确的开始和结束时间。

这两组要素确定之后，才能开始冲刺，一旦冲刺开始，就不能再变更这两组要素。

从这个要求中我们能够推导出对冲刺划分的要求和标准：

冲刺过程中不能有外部意见参与。否则完成时间不可控。

需要明确完成的标准。如何判断一个冲刺结束？只能是团队内部的领导说达标了，就结束。否则完成时间不可控。

项目团队的队长应该对冲刺的成果完全负责。成果经过他的验收之后冲刺就已经完成。如果甲方还有什么意见，可以作为下一个冲刺的起始条件。

这个在IT行业是一样的，产品经理对每次冲刺的成果负责，交付上线后，根据用户的反馈再来决定下一个冲刺的内容。

如果在某个冲刺中间需要同甲方沟通(或者更准确地讲，沟通结果会对本次冲刺造成影响)，那么这个冲刺的划分就不合理，正确的做法是以跟甲方沟通的时间节点为界，将这个冲刺分解为两个。

一个冲刺的合理周期为一到两周。如果太短，就会让冲刺准备占到的时间比例太高，而且也不利于形成系统的交付成果。如果太长，一次成果接受检验的时间间隔太长，就会集聚走错路的风险。

在跟很多设计管理者交流的过程中，我发现大家对“冲刺过程中不能让甲方对本次冲刺形成影响”这个原则很难理解。因为作为服务特别好的设计师，跟甲方打电话常用的结束语就是，“有什么问题随时沟通！”

“随时沟通”肯定不是把事情做好的最佳方法。再密集的需求提供，频率也不会高到每天变更吧。即便是甲方不是系统的工作方式，每周整理一次甲方提供的需求，汇总进入为期一周的“冲刺”，我想，但凡是还有点理性的甲方，都应该会接受的。

项目走的是曲线，但每个冲刺应该是直线

一般情况下，一个冲刺还是需要多个成员协作完成。为了管理方便，还需要将冲刺拆分为：

任务

任务应该足够小，小到可以由一个设计师来独立完成。这样才能为每个任务确立责任人。一个任务只能交给一个设计师；但一个设计师可以负责多个任务。

跟冲刺成果一样，任务也必须有清晰的验收标准，也就是“完成”的定义——做到什么程度，才算是完成了。

根据我的建筑设计从业经验，很多管理者在交代任务的时候，都没有给出清晰的验收标准，导致设计师不能直击目标，也是造成成果交付延误的重要原因之一。

任务的工作量，由“故事点”来进行描述。有关“故事点”的概念，参见之前专门写的一个小作文。

当我们说工作量的时候，究竟在说什么？——向IT行业学习项目管理

故事点的数值，由设计团队讨论决定。如果团队内部对某个任务的故事点无法达成共识，有大概率是对验收标准理解不一致造成的。这种分歧正好就提醒了这个潜在的风险，大家需要进一步阐述对任务的理解，以便达成共识，这样才能在冲刺过程中提高效率。

项目-冲刺-任务，

就是Scrum管理框架下的工作分解方法，简单有效。放到设计服务领域，同样适用。

冲啊Scrum是我们专为设计师和设计团队开发的冲刺管理工具，希望能将IT行业的管理经验和方法，引入到设计行业。欢迎试用。

Step01

Step02

Step03

Step04

Step05

Step06