在我們平時做設計的過程中，經常遇到需求不完整或者不明確的時候，這個時候如果繼續用平時的工作流程，極有可能在后期因為需求增加和變更增加很多額外的工作量。今天介紹一種叫螺旋模型的迭代模型，這個模型在軟件工程領域已經應用很久，經過了時間的考驗。我之前在做一個項目的時候，也遇到上述問題，考慮如何避免，在設計過程中應用了該模型，效果良好。
首先說下，一般情況下我們使用的迭代流程，是從拿到產品文檔開始進行需求分析，然后出交互稿，再到視覺、開發、測試、發布這些步驟，一般這個流程因為是逐步向前，軟件工程上的定義叫瀑布模型。
可以看得出，這種模型的每一步都依賴于上一步是否完成，如果某個環節出了問題，可能會造成整個過程返工。
那對于今天要講的螺旋模型是什么樣子的呢？首先我們看下軟件工程理論對螺旋模型的定義；
1988年，巴利·玻姆(Barry Boehm)正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統。
“螺旋模型”剛開始規模很小，當項目被定義得更好、更穩定時，逐漸展開。
“螺旋模型”的核心就在于您不需要在剛開始的時候就把所有事情都定義的清清楚楚。您輕松上陣，定義最重要的功能，實現它，然后聽取客戶的意見，之后再進入到下一個階段。如此不斷輪回重復，直到得到您滿意的最終產品。
（1）制定計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件；
（2）風險分析：分析評估所選方案，考慮如何識別和消除風險；
（3）實施工程：實施軟件開發和驗證；
（4）客戶評估：評價開發工作，提出修正建議，制定下一步計劃。
螺旋模型很大程度上是一種風險驅動的方法體系，因為在每個階段之前及經常發生的循環之前，都必須首先進行風險評估。
那對應到我們的設計過程中，可以用一張圖來概括：
可以看得出，我們的步驟也是分為4步：
1、制定計劃：這塊主要是需求分析以及計劃我們需要做什么，對應到設計的幾個層，是在戰略層以及范圍層[1]上。這塊因為之前講了，主要是針對我們遇到的需求不太明確的項目，所以一開始需求不完整也是可以開始的。在有個大概的分析之后，可以選擇我們要做的方案思路或者對應方法。
2、風險分析：這塊主要是針對制定了計劃之后，對于每種方案的風險評估，因為前期對需求定義不完整的情況下，很多設計是建立在數據分析、猜測、簡單的用戶調查等基礎之上的，可以對當前選擇的單個或者多個方案進行一個風險分析，以便于后期測試用戶的時候進行有關分析。
3、設計實施：這部分主要是設計過程，中間的設計過程可以考慮使用模塊化設計（方便后期需求變更的時候最小工作量迭代設計）、敏捷設計、并行設計等多種設計過程和方法。一般前期需求不明確的時候，我們更傾向于做最小產品模型（MVP [2]），這種更方便去修改和完善我們的整體需求。
4、用戶評估：這部分主要是做用戶測試，可以使用快速用戶測試的方法，這部分注意前期需求不完整，在做測試的時候，可以考慮使用區分變量的測試方法。一般來說我們快速用戶測試8個用戶的樣子就可以很大程度上說明我們比較嚴重的問題所在。關于置信度的問題有興趣的同學可以去專門了解下不同樣本下的置信度定義。
那在做完以上幾個步驟之后，我們得出了很多對于最終項目很有用的結論，可以進入第二輪迭代過程，這么好幾輪下來，需求逐步完善，設計方案逐步完善，需求就像滾雪球一樣越來越大，整個過程看起來是一個螺旋過程。可能有一些同學已經在使用類似的流程，我這里是借鑒軟件工程的定義將這部分嘗試用理論方法描述一遍。
對于一些做項目管理（project manage）的同學來說，比較關心的是使用了這個流程之后，效率上的提升是怎么樣子的呢。直觀的來說，可以用兩張圖來表明：
可以看出，兩個模型對應需求總量一定的情況下，一般我們使用傳統流程經常會造成一定程度的延期或者后期嚴重加班。使用螺旋模型因為在中間做了風險分析，并且需求和設計是同步逐步完善的，在需求燃盡的斜率上明顯要優于瀑布模型。
兩種模型對應的風險降低趨勢如下：
通過一般項目經驗分析，使用瀑布模型迭代前期沒有評估風險，后期需求逐漸清楚之后，風險點增多，需求穩定之后，隨著項目進展，風險開始下降。
使用螺旋模型前期評估了風險并預估了相應解決方案，整體項目過程中，風險一直是逐漸減少的。
對比之下，有人可能會問那是不是一定就是螺旋模型更好，我覺得不一定。在需求非常清晰的情況下，個人經驗反而瀑布模型是最有效率的過程。螺旋模型在軟件工程領域也是為了解決需求不明確的情況下定義出來的。所以各位也是要看情況而定。
軟件工程中有很多提高工作效率的理論是不曾引入設計領域的，設計給人一直的概念都比較虛，大家覺得是非常感性的，但是我們也可以考慮使用一些方法提高我們的工作效率，以上是我個人在項目中的實踐，拋磚引玉，希望一定程度上可以幫助到各位。
延伸閱讀：
[1] 《用戶體驗的要素》
[2] MVP產品到底該怎樣做
