談需求，不要談功能
前陣子幫一些單位上課，聊到Scrum中的需求訪談。
Scrum採用user story，所以和傳統的Function List有些不同，典型的User Story 長成底下這樣：
As a 〈type of user〉, I want 〈some goal〉 so that 〈some reason〉
例如
你會發現和過去最大的不同是，User Story採用很簡潔的方式，不僅描述出要做什麼(WHAT)，還包含了誰(WHO)需要這個功能，以及目的(WHY)為何?
關於User Story的寫法，在網路上可以找到很多參考資訊。
我讓學員做了一些練習後，學員們似乎還想了解更多，其中一位學員問到，需求訪談有甚麼技巧? 或是要點? 這是一個很抽象也很大的問題，但，我請同學們在紙上寫下，『談需求，不要談功能』。
一開始學員們有點疑惑，需求不就是功能嗎? 談需求的過程，不就是協助用戶釐清要做哪些功能嗎?
我說：不是的。
Scrum和敏捷開發，讓我們專注於建立出客戶真正需要的軟體。過去，我們可能以為，所謂的軟體產品就是一堆功能的集合。這是一個很大的迷思。
一但我們認為，軟體就是功能的集合，那就衍生出底下幾個問題:
只有真正幫得上用戶忙的軟體，才有價值，而不是功能很多的軟體。
結果，在隔壁開會的end-user突然經過，只說了一句話，就讓整個會議結束了。他說：『你們在討論這個喔? 這個功能其實不急啦，我們不一定會用到耶。』
上了會議桌之後就精彩了，每一個參與會議的人，不管是跟end-user距離多遙遠的高階長官，既然來參加會議了，總是要表達一些看法，但上級指導員畢竟不是end-user，他哪知道(哪在乎)到底end-user要怎麼用這個功能，往往天馬行空的憑著自己的經驗，把scope擴大了n倍，好死不死他是老大，雙方PM必須依照老大的意志，優先完成那些憑空出現卻又用不到的功能。
現在你知道那些永遠用不到的功能到底是怎麼來的了吧?
==========================
因此，我常常跟team member說，進行需求訪談時，不要談功能，盡可能引導用戶談需求。讓用戶告訴你:
所謂的談需求是，在徹底的了解用戶的需要和面對的問題之後，由我們給(功能)建議。
我們會建議用戶，為了實現上述他提到的目標，我們可以怎麼設計系統，我們會在整理後，提供用戶幾個選擇，讓用戶在幾個方案中，選擇他想要的。
注意，這中間有一個很大的差異，透過專注於『需求』的訪談方式，並非由用戶告訴我們系統該怎麼做，要有哪些功能。而是只告訴我們他想達成哪些目標。而反過來由我們告訴客戶，為了實現他的目標，這樣的系統應該需有有哪些功能，應該要怎麼設計或怎麼做。
在這個過程中，我們的團隊也更能夠展現出專業。也不至於陷入功能點漩渦裡，被一堆功能壓得喘不過氣來。
此外，當用戶更聚焦於『目的』而非『功能』，對驗收也很有幫助。專注於系統目標的驗收，才不會落入有哪些功能沒實現，哪些功能有實現這種不具有意義的check list當中。(很多時候，功能是實現了，但完全沒用，或沒價值，這本身就是一種浪費，因為這樣還卡住驗收，得不償失)
當客戶採購(或專案開發)一個系統時，客戶要的其實並非軟體產品，客戶真正要的是解決方案。軟體是用來解決問題的，問題能夠解決，不論功能點有多少，對客戶來說就是一個有用(願意付錢)的系統。反之，如果每一個功能都做出來，但實際上卻無法解決客戶的問題，這樣的軟體，最終也只是被束諸高閣而已。
別讓你的需求訪談，變成功能訪談了，這兩者之間有很大的不同啊~
Scrum採用user story，所以和傳統的Function List有些不同，典型的User Story 長成底下這樣：
例如
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和敏捷開發，讓我們專注於建立出客戶真正需要的軟體。過去，我們可能以為，所謂的軟體產品就是一堆功能的集合。這是一個很大的迷思。
一但我們認為，軟體就是功能的集合，那就衍生出底下幾個問題:
- 功能越多的產品價值(或價格)越高
只有真正幫得上用戶忙的軟體，才有價值，而不是功能很多的軟體。
- 談需求時，我們得把功能都談清楚才行
結果，在隔壁開會的end-user突然經過，只說了一句話，就讓整個會議結束了。他說：『你們在討論這個喔? 這個功能其實不急啦，我們不一定會用到耶。』
- 到底該用下拉還是用多選
上了會議桌之後就精彩了，每一個參與會議的人，不管是跟end-user距離多遙遠的高階長官，既然來參加會議了，總是要表達一些看法，但上級指導員畢竟不是end-user，他哪知道(哪在乎)到底end-user要怎麼用這個功能，往往天馬行空的憑著自己的經驗，把scope擴大了n倍，好死不死他是老大，雙方PM必須依照老大的意志，優先完成那些憑空出現卻又用不到的功能。
現在你知道那些永遠用不到的功能到底是怎麼來的了吧?
==========================
因此，我常常跟team member說，進行需求訪談時，不要談功能，盡可能引導用戶談需求。讓用戶告訴你:
- 他想要這個系統達成什麼效果?
- 希望改善哪些問題?
- 希望系統能為他發揮什麼效益或價值?
所謂的談需求是，在徹底的了解用戶的需要和面對的問題之後，由我們給(功能)建議。
我們會建議用戶，為了實現上述他提到的目標，我們可以怎麼設計系統，我們會在整理後，提供用戶幾個選擇，讓用戶在幾個方案中，選擇他想要的。
注意，這中間有一個很大的差異，透過專注於『需求』的訪談方式，並非由用戶告訴我們系統該怎麼做，要有哪些功能。而是只告訴我們他想達成哪些目標。而反過來由我們告訴客戶，為了實現他的目標，這樣的系統應該需有有哪些功能，應該要怎麼設計或怎麼做。
在這個過程中，我們的團隊也更能夠展現出專業。也不至於陷入功能點漩渦裡，被一堆功能壓得喘不過氣來。
此外，當用戶更聚焦於『目的』而非『功能』，對驗收也很有幫助。專注於系統目標的驗收，才不會落入有哪些功能沒實現，哪些功能有實現這種不具有意義的check list當中。(很多時候，功能是實現了，但完全沒用，或沒價值，這本身就是一種浪費，因為這樣還卡住驗收，得不償失)
當客戶採購(或專案開發)一個系統時，客戶要的其實並非軟體產品，客戶真正要的是解決方案。軟體是用來解決問題的，問題能夠解決，不論功能點有多少，對客戶來說就是一個有用(願意付錢)的系統。反之，如果每一個功能都做出來，但實際上卻無法解決客戶的問題，這樣的軟體，最終也只是被束諸高閣而已。
別讓你的需求訪談，變成功能訪談了，這兩者之間有很大的不同啊~
留言