在我们平时做设计的过程中，经常遇到需求不完整或者不明确的时候，这个时候如果继续用平时的工作流程，极有可能在后期因为需求增加和变更增加很多额外的工作量。今天介绍一种叫螺旋模型的迭代模型，这个模型在软件工程领域已经应用很久，经过了时间的考验。我之前在做一个项目的时候，也遇到上述问题，考虑如何避免，在设计过程中应用了该模型，效果良好。
首先说下，一般情况下我们使用的迭代流程，是从拿到产品文档开始进行需求分析，然后出交互稿，再到视觉、开发、测试、发布这些步骤，一般这个流程因为是逐步向前，软件工程上的定义叫瀑布模型。
可以看得出，这种模型的每一步都依赖于上一步是否完成，如果某个环节出了问题，可能会造成整个过程返工。
那对于今天要讲的螺旋模型是什么样子的呢？首先我们看下软件工程理论对螺旋模型的定义；
1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。
“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
那对应到我们的设计过程中，可以用一张图来概括：
可以看得出，我们的步骤也是分为4步：
1、制定计划：这块主要是需求分析以及计划我们需要做什么，对应到设计的几个层，是在战略层以及范围层[1]上。这块因为之前讲了，主要是针对我们遇到的需求不太明确的项目，所以一开始需求不完整也是可以开始的。在有个大概的分析之后，可以选择我们要做的方案思路或者对应方法。
2、风险分析：这块主要是针对制定了计划之后，对于每种方案的风险评估，因为前期对需求定义不完整的情况下，很多设计是建立在数据分析、猜测、简单的用户调查等基础之上的，可以对当前选择的单个或者多个方案进行一个风险分析，以便于后期测试用户的时候进行有关分析。
3、设计实施：这部分主要是设计过程，中间的设计过程可以考虑使用模块化设计（方便后期需求变更的时候最小工作量迭代设计）、敏捷设计、并行设计等多种设计过程和方法。一般前期需求不明确的时候，我们更倾向于做最小产品模型（MVP [2]），这种更方便去修改和完善我们的整体需求。
4、用户评估：这部分主要是做用户测试，可以使用快速用户测试的方法，这部分注意前期需求不完整，在做测试的时候，可以考虑使用区分变量的测试方法。一般来说我们快速用户测试8个用户的样子就可以很大程度上说明我们比较严重的问题所在。关于置信度的问题有兴趣的同学可以去专门了解下不同样本下的置信度定义。
那在做完以上几个步骤之后，我们得出了很多对于最终项目很有用的结论，可以进入第二轮迭代过程，这么好几轮下来，需求逐步完善，设计方案逐步完善，需求就像滚雪球一样越来越大，整个过程看起来是一个螺旋过程。可能有一些同学已经在使用类似的流程，我这里是借鉴软件工程的定义将这部分尝试用理论方法描述一遍。
对于一些做项目管理（project manage）的同学来说，比较关心的是使用了这个流程之后，效率上的提升是怎么样子的呢。直观的来说，可以用两张图来表明：
可以看出，两个模型对应需求总量一定的情况下，一般我们使用传统流程经常会造成一定程度的延期或者后期严重加班。使用螺旋模型因为在中间做了风险分析，并且需求和设计是同步逐步完善的，在需求燃尽的斜率上明显要优于瀑布模型。
两种模型对应的风险降低趋势如下：
通过一般项目经验分析，使用瀑布模型迭代前期没有评估风险，后期需求逐渐清楚之后，风险点增多，需求稳定之后，随着项目进展，风险开始下降。
使用螺旋模型前期评估了风险并预估了相应解决方案，整体项目过程中，风险一直是逐渐减少的。
对比之下，有人可能会问那是不是一定就是螺旋模型更好，我觉得不一定。在需求非常清晰的情况下，个人经验反而瀑布模型是最有效率的过程。螺旋模型在软件工程领域也是为了解决需求不明确的情况下定义出来的。所以各位也是要看情况而定。
软件工程中有很多提高工作效率的理论是不曾引入设计领域的，设计给人一直的概念都比较虚，大家觉得是非常感性的，但是我们也可以考虑使用一些方法提高我们的工作效率，以上是我个人在项目中的实践，抛砖引玉，希望一定程度上可以帮助到各位。
延伸阅读：
[1] 《用户体验的要素》
[2] MVP产品到底该怎样做
