需求到底是什么 如何撰寫需求文檔
只有當自己知道需要什么的時候,才有可能會獲得它,這也是探索需求的必要性。
我們常常談需求,但是需求真的是我們想象的那樣嗎?下面我就給大家梳理一下,關于需求你可能誤解了的11個真相。
1.寫需求其實并非是在談需求。
需求活動主要不是編寫需求文檔,相反,它專注于理解業務問題,并為之提供解決方案。
怎么樣才算理解了業務問題呢?
即你做的是哪個行業的產品,就對這個行業的商業模式、產業鏈、競爭狀態等要有所了解。而只有深入了解了業務本身,才有助于發現使用場景,并為之提供解決方案,讓用戶用得爽。
2.如果我們必須構建產品,那么它必須為擁有它的人提供最理想的價值。
除非產品提供了利益,否則擁有產品者不會付錢。
作為產品開發者或設計者,要深諳一點:即我們關注最終結果的擁有者,只是間接地關注用戶。但是在免費時代,很多公司并不靠產品本身盈利,所以不能孤立地看這個上圖中的曲線,應當將整個產品生態搭建起來,看看哪個環節是贏利點。
很多大公司,平臺級的產品均是不盈利的,通過專心打磨產品獲取千萬級的用戶,然后通過其他方式進行盈利,例如在線廣告、增值服務或電商。
3.你必須知道要求是什么,才能構建正確的產品。
要理解產品打算為用戶完成什么,以怎樣的方式完成,就必須理解擁有者的業務工作。產品經理得到需求,描述產品的功能(做什么)以及產品的屬性(做到什么程度)。
不幸地是,交流的無奈導致需求并非總是被恰如其分地理解了。
4.構建一個產品和解決一個業務問題之間,存在巨大的差別。前者不一定實現后者。
這一點是對第一點的補充。做一個產品就是為了解決一個業務問題,因此開發工作必須從問題開始,而不是從解決方案開始。
5.需求不一定要寫下來,但是構建者必須知道它們。
需求文檔是為了更好的溝通想法,一份高效準確的需求文檔能夠讓開發人員和設計人員非常明確需求是什么,從而實現它。但很多時候,口頭溝通更方便、直接,特別是一些細節的確認,往往需要口頭表達。
但值得注意的是,口頭溝通需求效率雖然高,但是不是所有需求都能用這種方式來溝通。編寫需求是為了讓利益相關者和產品經理徹底地理解需求,也有利于追蹤文檔。
6.客戶不一定能給你正確答案,有時候他也不知道要什么。
利益相關者在描述一個需求時是由困難的,交流的無奈是存在的。所以產品經理應該把握業務的復雜性和規模。
有時候,產品經理應該如實記錄下客戶的要求;有時候,應該從解決方案中導出需求,有時候必須提出創新,得到更好的解決方案。
7.需求不是偶然得到的,要通過某種有序的過程得到。
做產品就像拍電影,要先有一個劇本,確保劇情有序地發生。
任務的次序、重點和應用程度需要采用該過程的人或團隊來決定,參與這個過程的人必須能看到為什么不同的任務是重要的、哪些任務對項目最重要。但優先級是可以調整的,過程中要靈活變通。
8.怎么迭代都行,只要理解了業務的需求。
敏捷迭代越來越成為新寵,取代著原始的瀑布流開發方法。但是冷靜的頭腦在開發之前已經將需求過程吸收到開發的生命周期中了。
聰明的辦法不是廢除需求,而是從一個不同的方向接近需求。真正值得關注的是,既要發現需求,又不必編寫無用的、不成熟的文檔。
9.所有的方法和工具都無法彌補糟糕的想法和糟糕的手藝。
有序的過程并不能替代思考。需求收集、驗證、編寫文檔的過程并不是一種流程,而是由提交的產物驅動的。
要記住,自動化的工具只是輔助手段,產品經理最重要的工具就是:腦袋、眼睛和耳朵。
10.要想成功地實現需求,需求就必須可度量、可測試。
需求可以主要分為以下三類:
功能需求:產品支持其擁有者的業務時必須做的事情。
非功能需求:產品要再擁有者的環境中取得成功,必須將功能完成得多好的量化描述。
限制條件:全局性的需求。
例如,產品有一個需求是“應該對新用戶有吸引力”:
建立可測量的指標即:注冊時間少于2分鐘、數據項(例如姓名、郵件地址等)猶豫時間不超過5秒。
可以很肯定地說,如果你不能為需求找到測量指標,那么它就不是需求,只是一種無根據的想法。
11.作為產品經理,你終將改變用戶思考這個問題的方式。
產品經理的部分工作就是幫助人們盡早理解和質疑他們的需求,這樣他們就可以幫助你發現它們真正的需求。
當產品經理開始理解需求時,尤其是在需求來自于不同利益相關者時,就開始建立起一套抽象概念,通過展示業務過程的模型漸漸參透工作的本質,得到清晰、可測量的需求,并把這些反饋給利益相關者。
在做這些事情的時候,產品經理就在漸漸改進(改變)他們對業務的看法。
簡言之,需求就是產品支持其擁有者的業務所必須完成的事。而產品經理的工作就是理解需求,理解到應該做什么、做到什么程度,并建立起一套解決問題的方案,反饋給產生需求的人。