在做產品開發時, 我們常會遇到某些功能花了很大的代價做了, 可是卻不是客戶想要的. 早期 waterfall 的時代, 這樣的事情很常發生, 常讓團隊覺得好累喔
 
 
 
等到敏捷開發出現, 發現事情有了生機, 我們可以藉由迭代的機制, 批次作業, 先完成一部分的功能, 然後交付給客戶, 及早取得回饋, 早點做調整. 
 
 
可是 ..... 團隊還是花了時間把這個東西給做出來, 可能一個月, 或者是兩個月. 雖然比以前的一年半載好很多, 但是我們還是花了代價把東西給做了出來.
 
後來, 有人提出了 Pretotyping 的概念, 可以在不用把產品做出來的狀況下, 驗證產品的想法是否正確. 那時候確實也是眼睛為之一亮, 想說這應該不錯, 這確實是我們需要的.
 
 
但是, 並不是像大神說的, 每次都能做 landing page XD. Fake Door 或 Mechanical Turk 的概念, 並不是每次都能落實的產品中. 
 
另外, 就算 pre-totyping 的手法知道怎麼套用, 我們必須要定義好要解的問題是什麼. 如果找錯問題, 後面產生出對的驗證方式, 這也是白搭.
 
我們又想找找是否有好的方式, 可以幫忙找出對的客戶問題. 這時侯火紅 design thinking 的流程, 應該也是一盞明燈. 但是接觸後, 發現設計思考的流程太 high level, 不容易落地. 中間提到的腦力激盪, 並沒有想像中的完美, 有時候個人深思熟慮, 比眾人腦力激盪管用.
 
 
 
因此, 我在想是否能一個作法, 可以有以下特性, 讓我們解決或減輕上述問題.
(1) 不需要真的做出產品
(2) 短時間可以產出
(3) 可以迭代方式進行
(4) 可操作性高, 並非只是 high level 流程
(5) 不只腦力激盪, 也重視個人思考
(6) 可以找用戶驗證想法
 
 
而 GV 所提出的 design sprint, 似乎是目前最棒的解決方式之一. 他的流程如下:
 
第一天:理解我们要解决的問題
第二天:探索可能的解决方案
第三天:決定接下来要打造的產品
第四天:制作原型
第五天:從原型的用户測試中收集反饋
 
 
 
目前看起來有以下的好處:
(1) 以五天為一個迭代, 或者最長是五天, 在這個期間內要解決一個重要的問題
(2) 這個流程中, 他不但要團隊腦力激盪, 他更強調在此之前要先做個人腦力激盪, 
(3) 在這五天中會做出原型, 找客戶驗證取得回饋. 因此不是空口說白話, 不是自己腦補
(4) 在 sprint 一書中不旦詳細描述細部做法, 甚至還有檢查清單, 手把手地教你落地. 
 
 
 
但是, 他還是有些東西無法解決
(1) 在第一天中, 我們需要去定義問題, 和了解問題的 context, 這部分的洞見, 不是 process 可以幫忙的. 領域知識或是用戶調研的功力還是要有, 否則還是不容易看到真的問題. 當然啦, 如果你找錯要解的問題, 最多 5 天你就拿出來面對用戶, 所以要錯也不會錯太久.
(2) 第四天的 prototype 也是件不容易的事情, 你有那些方法可以幫你在一天內打造出原型, 可以讓用戶了解你的觀點. 很多時候大家還是用 paper prototyping 或者是 wireframe. 不知現在的原型工具, 是否已經和之前大大不同, 可以幫我們減輕這方面的不便.
 
整體來說, GV design sprint 的做法, 結合了 agile, design thinking, 和 prototyping 等概念, 讓你在正式開工前, 可以更有效確認你是否解對問題, 還算是一個值得嘗試的做法. 不知大家看法如何?
arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()