「用戶故事 User Story」能讓需求簡化,還能更省時、更省錢,提供更多價值,這…可能嗎?

    回歸原點的設計就是好設計,需求的蒐集也是一樣的道理(圖片來源:www.ptbus.com)
    日前在EMBA的課程當中,老師談到了一個設計上的個案。這個設計個案是,一個只能往前推開的門,門上有個把手,把手旁有個「推」的字樣。這樣的設計到底有什麼問題呢?這和專案管理又能扯上什麼關係呢?


    我們先來看看把手的部分。把手通常是用來「拉」開門用的,但這個門卻被要求只能往前「推」開,那這個把手到底有什麼價值呢?

    其次,門裝了把手之後,它反而誘導了使用者去「拉」這道門。所以,又得貼個「推」的字樣,來「教育」使用者「此門要用推的」!

    結果,就形成了這個畫蛇添足的設計!


    想做出好設計,要先回歸到原點

    讓我們回歸到原點,也就是,這個門當初之所以會在「這個位置」,以及之所以要做成「只能推開」來思考,我們會赫然發現,原來,我們只要「單純地」讓這個門「只能往前推開」就行了。因為,當一個人站在一扇「沒有把手」的門前面,即使是沒有任何引導的字樣在門上,他/她也只能用「推」來開門,不是嗎?

    於是,「把手」和「推」的字牌這兩個部分就可以捨去,相關的成本和工時也可以省下來,而且,也不會減損整體設計「解決問題的效力」。例如,防火逃生門就可以這樣設計,讓使用者可以直接「推開」門就能衝出去逃生,既快速又直覺,提供了「能更快逃生」的價值!

    當我們在做一個設計的時候,不論是實體的產品,還是虛擬的軟體功能,我們應該要不斷地嘗試問客戶、問自己,回溯到這個需求剛出現時,那個簡單又純粹的原點:這個需求的初衷是要解決什麼問題?就像這扇門的個案那樣,其實只要回歸到初衷,我們就能夠設計出既符合原始需求(範疇),又能節省成本、縮短工期,還能提供使用者更多、更大價值的設計。而這也就是專案管理的終極目的所在,不僅僅只是符合範疇、時間、成本的三大專案目標而已,更提供了使用者更好的價值和體驗。

    想做好專案管理,要先有效蒐集需求

    相信很多人在做專案規劃的時候,常常遇到「需求不清楚」,或是「自以為清楚,其實並不是真的清楚」的困擾。也因此,在專案的執行過程當中,就容易出現大量需求變更的狀況。這些突如其來的變更,往往造成許多的重工、工期的延遲,以及預算的超支等。要解決這個問題,就要從源頭的需求蒐集下手。那到底有沒有一個簡單、易懂、易用的方法,可以來協助改善這樣的問題呢?

    其實,需求不清楚,未必是客戶的問題,有時候是我們「不會問」!當我們在蒐集一個專案的需求的時候,應該要能問出需求的原始初衷才行。在敏捷(Agile)開發方法裡,就有一個叫做「使用者故事法(User Story)」這樣的需求蒐集工具做得到。它要大家在蒐集需求的時候考慮三個要素:使用者的角色是誰(Who/Role)、使用者想要(Want)的功能是什麼、使用者能用這功能做什麼(即W

    當我們能清楚地定義提需求的使用者角色之時,我們就可以判斷他的「份量」,也就是對專案的影響力大小。例如,公司CEO提出來的需求,權重一定會比較高,要優先、小心處理,對吧?因為他有能力把你這個專案經理換掉。

    接著,我們就來看看,這位使用者所想要的功能,跟他的角色定位符不符合,有沒有說服力。例如,「產品的配色變更」的需求,合適的「使用者角色」就不該是研發人員,而應該是由客戶或是UI designer(使用者介面設計師)來提。

    最後,我們再看,使用者想要用這個功能來做什麼?解決什麼問題?很多時候,使用者自己也不太清楚為什麼要這個功能,只因別人有,所以我也要。此外,我們也還要從這裡反向思考,這功能是這個產品的定位該提供的嗎?有其他更快、更便宜、更有價值的替代解決方案,而不必照著使用者「想要的功能」去做嗎?

    使用者故事法的這「WhoWantWhyW概念,個人覺得還算簡單易懂,好實做,可以協助一個專案在一開始的規劃階段,就把需求盡可能地都說清楚、講明白。這樣,就可以在日後的專案執行上,大幅地減少需求的變更,降低重工所造成的團隊士氣低落,提升專案的達標機率。如果您也是專案經理,不妨也來試用看看吧!