在需求獲取的過程中，你可能會發(fā)現(xiàn)對產(chǎn)品范圍的定義存在誤差，不是太大就是太?。–hrister and Kang 1992）。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業(yè)務(wù)和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那么客戶將會提出很重要的但又在當前產(chǎn)品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產(chǎn)品。需求的獲取將導致修改項目的范圍和任務(wù)，但作出這樣具有深遠影響的改變，一定要小心謹慎。正如經(jīng)常所說的，需求主要是關(guān)于系統(tǒng)做什么，而解決方案如何實現(xiàn)是屬于設(shè)計的范圍。這樣說雖然很簡潔，但似乎過于簡單化。需求的獲取應(yīng)該把重點放在“做什么”上，但在分析和設(shè)計之間還是存在一定的距離。你可以使用假設(shè)“怎么做”來分類并改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然后提供一個尋找錯誤和遺漏的辦法。把你在需求開發(fā)階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應(yīng)該看成是對設(shè)計者選擇的一種限制。
需求獲取研習會中如果參與者過多，就會減慢進度。我的同事D e b b i e在她從事過We b開發(fā)項目中，由于使用實例研習會進展緩慢，曾一度感到灰心喪氣。1 2位參與者對不必要的細節(jié)進行激烈的討論，并且在每個使用實例如何工作的問題上難以達成一致意見。當她把工作人員減少到只有6個人時，進度馬上加快了，而這6個人代表了客戶、系統(tǒng)設(shè)計者、開發(fā)者和可視化設(shè)計者等主要工程角色。
相反地，從極少的代表那里收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數(shù)用戶的需要。最好的權(quán)衡在于選擇一些授權(quán)為他們的用戶類發(fā)言的產(chǎn)品代表者，他們也被同組用戶類的其它代表所支持。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://www.vanceur.cn/pmqhd/index.html
