發表文章

目前顯示的是 5月, 2015的文章

談需求,不要談功能

前陣子幫一些單位上課,聊到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-