談需求,不要談功能

前陣子幫一些單位上課,聊到Scrum中的需求訪談。

Scrum採用user story,所以和傳統的Function List有些不同,典型的User Story 長成底下這樣:

As a 〈type of user〉, I want 〈some goal〉 so that 〈some reason〉

例如

As an Administrator, I want to be able to create User Accounts so that I can grant users access to the system.

你會發現和過去最大的不同是,User Story採用很簡潔的方式,不僅描述出要做什麼(WHAT),還包含了誰(WHO)需要這個功能,以及目的(WHY)為何?

關於User Story的寫法,在網路上可以找到很多參考資訊。

我讓學員做了一些練習後,學員們似乎還想了解更多,其中一位學員問到,需求訪談有甚麼技巧? 或是要點? 這是一個很抽象也很大的問題,但,我請同學們在紙上寫下,『談需求,不要談功能』。

一開始學員們有點疑惑,需求不就是功能嗎? 談需求的過程,不就是協助用戶釐清要做哪些功能嗎?

我說:不是的。

Scrum和敏捷開發,讓我們專注於建立出客戶真正需要的軟體。過去,我們可能以為,所謂的軟體產品就是一堆功能的集合。這是一個很大的迷思。

一但我們認為,軟體就是功能的集合,那就衍生出底下幾個問題:
  • 功能越多的產品價值(或價格)越高
但仔細回想,軟體真的是這樣嗎? 好用的軟體(對我們工作真正幫上忙的軟體),有時候用到的功能根本不多。甚至,許多功能點很多的軟體,其實一點都不好用。不僅複雜,更讓用戶在還沒能掌握或發揮軟體價值前,得投資一堆的時間來學習怎麼使用。

只有真正幫得上用戶忙的軟體,才有價值,而不是功能很多的軟體。
  • 談需求時,我們得把功能都談清楚才行
這導致需求訪談的時候,大家都關注在某個功能點上,卻忘了這個功能對用戶而言到底有什麼意義。我參加過很多需求訪談的會議,看到雙方PM和相關人員,為了一個功能如何實作,以及衍生出哪些相關功能爭執得面紅耳赤,會議開了一整天,function List上功能點一個都還沒談定,搞得買賣雙方大家精疲力盡卻一無所獲。

結果,在隔壁開會的end-user突然經過,只說了一句話,就讓整個會議結束了。他說:『你們在討論這個喔? 這個功能其實不急啦,我們不一定會用到耶。』
  • 到底該用下拉還是用多選
一但我們只關注在要實現哪些功能,用戶和開發團隊常常會為了某一個功能怎麼實作而討論半天,有時候一開始只是用戶(或規格書)對於此功能的背景描述不清,導致雙方PM對於怎麼實作有不同的意見,然後這個規格討論被搬上了會議桌。

上了會議桌之後就精彩了,每一個參與會議的人,不管是跟end-user距離多遙遠的高階長官,既然來參加會議了,總是要表達一些看法,但上級指導員畢竟不是end-user,他哪知道(哪在乎)到底end-user要怎麼用這個功能,往往天馬行空的憑著自己的經驗,把scope擴大了n倍,好死不死他是老大,雙方PM必須依照老大的意志,優先完成那些憑空出現卻又用不到的功能。

現在你知道那些永遠用不到的功能到底是怎麼來的了吧?

==========================

因此,我常常跟team member說,進行需求訪談時,不要談功能,盡可能引導用戶談需求。讓用戶告訴你:
  1. 他想要這個系統達成什麼效果?
  2. 希望改善哪些問題?
  3. 希望系統能為他發揮什麼效益或價值?
如果可以,一開始不要馬上談UI、不要談功能點、不要鼓勵用戶立刻開始談細節。因為這樣一定會讓需求和規格發散。永遠無法收斂。(需求會議參與的人越多,發散的程度呈等比級數增加)

所謂的談需求是,在徹底的了解用戶的需要和面對的問題之後,由我們給(功能)建議。

我們會建議用戶,為了實現上述他提到的目標,我們可以怎麼設計系統,我們會在整理後,提供用戶幾個選擇,讓用戶在幾個方案中,選擇他想要的。

注意,這中間有一個很大的差異,透過專注於『需求』的訪談方式,並非由用戶告訴我們系統該怎麼做,要有哪些功能。而是只告訴我們他想達成哪些目標。而反過來由我們告訴客戶,為了實現他的目標,這樣的系統應該需有有哪些功能,應該要怎麼設計或怎麼做。

在這個過程中,我們的團隊也更能夠展現出專業。也不至於陷入功能點漩渦裡,被一堆功能壓得喘不過氣來。

此外,當用戶更聚焦於『目的』而非『功能』,對驗收也很有幫助。專注於系統目標的驗收,才不會落入有哪些功能沒實現,哪些功能有實現這種不具有意義的check list當中。(很多時候,功能是實現了,但完全沒用,或沒價值,這本身就是一種浪費,因為這樣還卡住驗收,得不償失)

當客戶採購(或專案開發)一個系統時,客戶要的其實並非軟體產品,客戶真正要的是解決方案。軟體是用來解決問題的,問題能夠解決,不論功能點有多少,對客戶來說就是一個有用(願意付錢)的系統。反之,如果每一個功能都做出來,但實際上卻無法解決客戶的問題,這樣的軟體,最終也只是被束諸高閣而已。

別讓你的需求訪談,變成功能訪談了,這兩者之間有很大的不同啊~

留言

tomexou寫道…
整篇文章說得很好,給大讚!
KEN寫道…
簡潔又務實, 讚~

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...