以使用者為中心的軟體開發
問題
今天這個時代迭代開發已經成為常識，甚至政治正確。隨便誰就能給你扯兩句mvp。敏捷也從一個開發的名詞變成了管理名詞。迭代，測試，反饋，名詞滿天飛。
人人都在說這些術語，彷彿他們真的就懂怎麼做軟體了。起碼，覺得自己真的懂怎麼創新了。然而經不起細聊，一旦深入下去聊一個mvp，聊聊他的迭代計劃。就會發現露餡了張嘴閉嘴，談的都是功能。這個迭代要交付幾個功能，這個mvp多了什麼功能？他的競爭對手都有哪些功能？卻很少聽到使用者人人都在喊，以使用者為中心。口號喊得震天響，但你看他們的行為模式，他們的語言，並沒有使用者的身影。
我時常覺得這個事情不太對勁。但是也沒有想到更好的方法。敏捷中使用的故事卡比功能的視角要好一點。因為在故事卡里，你要寫下使用者的價值。但是，我一直也不知道這個價值是從哪兒來的。是先開槍後畫靶子我們想做某個功能了，所以硬按一些價值的。還是真的存在的，價值的單位應該是什麼呢？沒有單位的東西就無法管理。無法管理，也就無法優化。我們交付的價值是越來越多嗎？還是交付的不如以前了？用什麼來判斷？
回答不了這些問題，不管輸贏都是有點不明不白的。這些問題的核心問題就是價值的單位應該是什麼？怎麼算一個價值？直到我看了，我們公司設計團隊的一個框架MERLIN。又在《創新的窘境》，作者的新書《與運氣競爭》裡，看到了理論依據。這個問題在我這裡才算是告一段落。我明白了，以使用者為中心的軟體開發大概應該怎麼做。
方法核心
如果我們想以使用者為中心進行軟體開發，那麼知行要合一，我們的分析方法應該是圍繞著使用者展開的。
這個方向倒是不新鮮，我們在inception的時候做用需求分析時我們的方法就是圍繞著使用者展開的。一個典型的分析過程，如下圖所示：
我們會在上面畫一條軸，標示出使用者旅途。這是使用者在使用軟體的時候的，他的一個全過程。然後在對應的時間點上，標記出，我們的功能。這樣我們的功能就不是平白出來的。每一個都聯絡了使用者價值。在ThoughtWorks，我們可能標記的是使用者故事，相對於功能，使用者故事，首先就是要寫出價值。
但是這個圖還是不夠給力。首先，從使用者旅途上的點，到功能的對映簡直是個magic move。並不能很好的傳遞為什麼是這樣的一個功能，而不是別的功能？畢竟實現一個使用者的價值方法有很多。後續在執行的過程當中，難免會僵化行事。
其次，上面的旅途，還可以再抽象和封裝。簡言之，旅途本身也應該是有抽象層次的。一個旅途上的一個點，可能也是一段新的旅途。
一個更系統的做法是這樣的，首先做服務設計：
系統化的分析使用者的行為，過程中與企業有哪些觸點，在這些觸點上使用者“僱傭”企業的產品到底是來做什麼的，也就是動機。
然後將這些點再進一步細化，採用故事的模式：
圖上的一行會講一個故事，就像電影分鏡或者漫畫一樣，來表達使用者使用的故事，真正的故事，而不是使用者故事那種東西，我們叫這個東西故事板。
在故事板上，我們描繪了一個故事，這個故事裡，使用者獲得了一種體驗。一個故事對應一個體驗。在基本需求都已經得到滿足的今天，體驗是新的最有價值的事情，以體驗為中心才是以使用者為中心。故事板恰好給了我們一個非常符合人類認知習慣的方式來描述什麼是一個體驗。也就回答了開頭的問題，什麼是價值的單位。
當我們定義出了價值的單位，就可以從這一單位的價值裡面映射出故事卡，來進行開發過程的管理。
這裡就是我們的重點，我們將來交付的軟體、交付的服務、我們交付的一個MVP本質上是交付給了使用者一組體驗。MVP的迭代則應該是更多的體驗或某些舊體驗的升級（也就是同一個動機，換了一個故事來滿足）。
這就是以使用者為中心的軟體開發的核心。最終我們把使用者的價值很好的表達了出來，並且找到了使用者體驗的基本單位——故事板，由於故事板也可以轉化為使用者故事，結合早已經存在的敏捷開發方法，也就可以對體驗的交付進行度量和管理。達到真正的以使用者為中心進行軟體開發。
文/ThoughtWorks仝鍵
更多精彩洞見，請關注微信公眾號：思特沃克