談需求，不要談功能
前陣子幫一些單位上課，聊到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-...