一份良好的需求文檔，可以很好地傳遞產(chǎn)品經(jīng)理的思路，更好地實現(xiàn)與開發(fā)的溝通。

一份可讀性強(qiáng)、文脈和思路清晰、流程和功能闡述明白、頁面元素、輸入和輸出都定義明確的需求規(guī)格說明書、通常都是需要經(jīng)過幾次持續(xù)的迭代和梳理，才能逐漸完善起來。

到底需要迭代幾次，就取決于你對業(yè)務(wù)的理解能力和需求分析能力了。然而不論你迭代多少次、最終也是為了讓程序員讀到它的時候，能夠心領(lǐng)神會，不用BA和PM解釋過多。愉快地實現(xiàn)玩耍和編碼，最終實現(xiàn)系統(tǒng)/產(chǎn)品（后統(tǒng)稱產(chǎn)品）的功能。

所以需求規(guī)格說明書的目的，不是為了給領(lǐng)導(dǎo)和User看（領(lǐng)導(dǎo)和User并不關(guān)心這個，領(lǐng)導(dǎo)和User在乎的是這個產(chǎn)品啥時候能用，能為他們帶來什么樣的價值?。。。?。工作留檔？也完全沒有必要，除非你今天做了一半要辭職回家去種田，需要工作交接。因為交付一個良好的產(chǎn)品比這個都重要100倍。如果為了紀(jì)念，你曾把大把的時間和精力投入到這個產(chǎn)品的規(guī)劃、設(shè)計、功能交互、后臺邏輯梳理等等上面。你倒是很要必要給自己留個檔案。多年后，無意中再打開，你會看到自己成長的軌跡和脈絡(luò)。

基本內(nèi)容

時間、版本、修訂者、 編寫目的、編寫背景諸如此類的內(nèi)容，就不必再多說了。我不是說這些不重要，而是這些與要實現(xiàn)的產(chǎn)品具體的需求功能均無關(guān)系。不要在這些點上浪費時間，但這些小細(xì)節(jié)會體現(xiàn)出你做需求的規(guī)范、流程及專業(yè)性。

1.用戶及應(yīng)用場景

不同層次、不同角色的User有不同的訴求和應(yīng)用場景。對于BI類的產(chǎn)品不同類型的User使用數(shù)據(jù)的場景均不一樣，明確用戶群體、用戶角色、用戶權(quán)限等，根據(jù)業(yè)務(wù)場景，梳理、構(gòu)建并完善用戶應(yīng)用場景有助于讓需求分析更準(zhǔn)確，讓產(chǎn)品功能更全面，更貼近用戶需求。

比如一個數(shù)據(jù)分析系統(tǒng)，針對不同的User，對需要做業(yè)務(wù)的一線業(yè)務(wù)人員，在設(shè)計的時候，基本上就是要通過界面展現(xiàn)關(guān)鍵指標(biāo)，不涉及詳細(xì)分析功能。并且在某些指標(biāo)異動時能及時通過手機(jī)通知。而運營分析的數(shù)據(jù)分析師，則必須提供多維度分析、靈活分析、對比分析、趨勢預(yù)測分析、假設(shè)分析等功能。

另一方面，不同層級User關(guān)心的功能、數(shù)據(jù)粒度都不一樣。需要站在User的立場上去規(guī)劃和引導(dǎo)應(yīng)用場景。而每一個應(yīng)用場景的設(shè)計是否剛好符合用戶的需求，又解決了User的痛點問題。這是一個大的前提和關(guān)鍵。因為只有在實現(xiàn)基礎(chǔ)功能之上再考慮用戶粘度和用戶體驗度才是有意義的，否則錦上添花的東西有時候會變的華而不實。

用戶群組、角色權(quán)限、應(yīng)用場景等內(nèi)容需要反復(fù)Check和逐一假定演繹系統(tǒng)的應(yīng)用場景，而在這樣的過程中，很有必要和User保證緊密的聯(lián)系和溝通。這也是產(chǎn)品規(guī)劃和設(shè)計的關(guān)鍵，只有在一開始，就盡最大程度的努力讓User參與進(jìn)來，關(guān)注產(chǎn)品的功能、應(yīng)用場景和體驗，你的設(shè)計才不會距離User太遠(yuǎn)。

2.系統(tǒng)/產(chǎn)品的目標(biāo)

通俗一點講，就是要解決什么問題、帶來什么價值。這本質(zhì)上是要明確產(chǎn)品需要滿足用戶的什么需求。但凡需求，均有價值和優(yōu)先級。判斷需求的價值，可用 PST方法分析，但通常這個理論都比較繁瑣。其實優(yōu)先級很容易得出，通常User急切想要的東西，或者急切想要借助一個系統(tǒng)或一款產(chǎn)品來幫助他解決業(yè)務(wù)當(dāng)中棘手的問題時，這些都是優(yōu)先級比較高的需求。

這一章節(jié)的內(nèi)容，它決定了，我們要設(shè)計什么樣的產(chǎn)品，用這個產(chǎn)品能夠用來做些什么。比如一個績效系統(tǒng)，主要就是要實現(xiàn)企業(yè)不同部門，不同層級、角色的績效指標(biāo)的自動化計算、匯總、可視化呈現(xiàn)。做的好一點，時間維度、能夠自由而靈活界定， 準(zhǔn)確而便捷地評鑒個體的績效趨勢和走向方便績效的精細(xì)化管理和追蹤。另一方面能夠從全面的職責(zé)維度出發(fā)，對比和觀測不同職責(zé)的績效表現(xiàn)與趨勢。能夠更加容易、全面、公正地績效考評并有效聯(lián)動獎金激勵機(jī)制。

3.功能模塊概要介紹

這一章節(jié)是概要地介紹，你要設(shè)計和規(guī)劃的產(chǎn)品都需要具備哪些功能模塊、功能點、大致會有哪些主要的功能頁面來支撐這個功能模塊。

模塊的定位、模塊間的劃分與交互都需要有基本的介紹。目的主要有2個：

一方面，是為了方便PM清晰地將產(chǎn)品規(guī)劃的功能落地下來，因為這些瑣碎的創(chuàng)意和設(shè)計，只有在你具體去描述它的時候、并畫出它的Mockup的時候，它的局限性、用戶交互、用戶體驗等種種缺陷才會展現(xiàn)出來，你才能進(jìn)行持續(xù)的思考和摒棄。通過這樣的過程，PM把這些星星點點的創(chuàng)意和設(shè)計，經(jīng)過一個產(chǎn)品化（系統(tǒng)化）的體系思考、演繹之后變得生動和流暢起來。

另一方面，功能概述的意義旨在為程序員服務(wù)，程序員前期不參與需求、系統(tǒng)規(guī)劃和設(shè)計，拿到需求規(guī)格說明書后，如果立馬進(jìn)入到具體某個頁面、功能點的詳盡規(guī)格描述里，通常都會一臉懵逼，然后開罵和抱怨。

所以功能模塊概要需要用盡量簡練的語言將各個功能模塊里的主要功能點提煉概述而過，不拖泥帶水、不瞻前顧后。最好圖文并茂地將功能模塊的profile像一張藍(lán)圖呈現(xiàn)在程序員面前。這是他們讀需求規(guī)格說明書的一個前奏，要不然都不能愉快地編碼和玩耍。

而所有有才的程序員，大多數(shù)都是機(jī)智過人的漢子，你若遇見冰雪聰明的妹子，可以一塊共事，那該是多么大的小確幸，且行且珍惜。

有點才華的PM遍地都是，但才華橫溢的程序員真的是千里難尋。因為在編碼和玩耍的世界里，不存在“三個臭皮匠頂一個諸葛亮”程式，一個有才而好學(xué)的程序員遠(yuǎn)遠(yuǎn)勝過10個平庸的呆笨男。

4.功能需求詳細(xì)規(guī)格說明

看到標(biāo)題，機(jī)智的程序員瞬間就懂得從愉快玩耍的前奏里，停頓幾秒后直入主題。然后開始了一場痛并快樂著的旅程。閱讀、思考、玩耍、編碼、加班、熬夜、糾結(jié)，繼續(xù)玩耍和編碼，周而復(fù)始。那這一章節(jié)到底要寫點神馬，才能讓程序員讀的開心、想的明白，熬夜的甘心、糾結(jié)的痛快，從而實現(xiàn)持久的玩耍和編碼呢？這一章節(jié)是核心，我需要花更多的時間去梳理和胡說額。好吧，趕緊切入主題。

4.1.描述系統(tǒng)產(chǎn)品的容顏

按照User訪問系統(tǒng)功能模塊的界面的依次順序，從上而下，界定和描述頁面上的全部元素（Text Field、Droplist、Button、Box、可視化圖表等等）及元素的屬性。

如下拉單包含那些枚舉值，填寫框輸入的數(shù)據(jù)類型、哪些元素需要弱化，哪些元素需要突出，有/無數(shù)據(jù)時怎么樣。

描述過系統(tǒng)的容顏之后，需要明確界定，功能模塊中全部頁面的輸入和輸出項。比如一個可視化的報表頁面，輸入：需要選擇的組合查詢條件，輸出：要呈現(xiàn)的數(shù)據(jù)可視化圖表。

4.2.USER在界面的交互

通常，User對系統(tǒng)的體驗都是老司機(jī)，你只要告訴這個系統(tǒng)會提供什么功能、能給他帶來什么，即刻他便明白他將在系統(tǒng)里能怎么操作，能得到什么。因為User永遠(yuǎn)會在最大程度地想讓自己在使用某個系統(tǒng)或者某款產(chǎn)品的時候得到最大的靈活和便捷，以及滿足感。所以，功能和用戶體驗才會成為所有系統(tǒng)和產(chǎn)品研發(fā)的最根本的出發(fā)點和立足點。

USER在這個界面是單純的瀏覽，還是編輯，是操作的主流程，還是分支流程都需要有清晰的定義和描述。例如，一個互動功能，不論是點贊、關(guān)注還是評論，我們要從用戶體驗的角度和先后次序去闡述它：鼠標(biāo)/手指觸控/點擊后控件的樣式變化， 取消的時候又是什么變化等等。

很多時候，User是不愿意告訴PM實際的目的和想法，只是純粹在爭取他們想要什么，強(qiáng)調(diào)一個系統(tǒng)/一款產(chǎn)品必須要能夠解決掉User在業(yè)務(wù)流程里的難點和痛點。這沒有錯，但PM需要能夠站在User的立場上，去思考對方的真實想法，需要去分辨那些才是真正實際的、有利于業(yè)務(wù)發(fā)展的需求，然后前瞻性地考慮功能頁面的交互。在這過程中，需要不停地將很多需求點，進(jìn)行轉(zhuǎn)換和變通。把需求的理解，從User的角度、演化為系統(tǒng)/產(chǎn)品的理解：交互和功能層面。而后，拋開體驗層面，回歸到需求層面，不斷地驗證和完善系統(tǒng)/產(chǎn)品設(shè)計背后的邏輯。

所以，你看到了嗎，PM的地位在User面前就像低到了塵埃里，并且還開不出花來。

4.3.系統(tǒng)產(chǎn)品業(yè)務(wù)邏輯和規(guī)則

基本上有80%的PM都停留在這一階段，認(rèn)為自己完成了基本功就是長久之能，懂得畫圖懂得做原型懂得項目跟進(jìn)，就是懂做產(chǎn)品了。

我也是一樣的，目前在一家新公司。也是處在這樣的一個邊思考邊行走的階段。但我明白，對業(yè)務(wù)的理解非常重要，只有你對業(yè)務(wù)邏輯相當(dāng)熟悉了、明白和領(lǐng)悟了基于這一系列業(yè)務(wù)邏輯之上的各種業(yè)務(wù)規(guī)則，你才有可能把產(chǎn)品做好，不然你淪為的只是老板或領(lǐng)導(dǎo)的畫圖工具，這個時候你規(guī)劃設(shè)計的產(chǎn)品的價值是很難體現(xiàn)出來的。

業(yè)務(wù)邏輯，呈現(xiàn)在系統(tǒng)里就是一個合理的架構(gòu)業(yè)務(wù)的框架，并不是具體的一個交互。深入的了解業(yè)務(wù)邏輯和規(guī)則，以及對他們的思考，明白業(yè)務(wù)為何是這樣的邏輯流程、為何這些業(yè)務(wù)流程邏輯上要設(shè)定這么多的規(guī)則？你不要試圖去改善業(yè)務(wù)流程和邏輯，因為大公司很多時候輪不到你思考業(yè)務(wù)或者提出更好的業(yè)務(wù)。而且業(yè)務(wù)框架也定了，但你可以把業(yè)務(wù)梳理好，可以把需求方服務(wù)好，要一起前進(jìn)。

這也是提升的地方。明白了業(yè)務(wù)流程邏輯是什么樣子，這些流程規(guī)則上為何設(shè)定這么多的業(yè)務(wù)規(guī)則。就已經(jīng)成功一半。把這些內(nèi)容分主題、分類別、梳理出來，歸屬到規(guī)劃好的功能模塊當(dāng)中，當(dāng)然還是從User的角度、習(xí)慣、意愿去梳理規(guī)劃這一切。

5.非功能性需求

非功能的需求，本身跟User無關(guān)。比如用戶體驗的需求，這個User不用說，PM自己要考慮。就簡單的響應(yīng)方面，如果一個報表系統(tǒng)，User選好組合條件，點擊查詢后，數(shù)據(jù)或者可視化圖表要經(jīng)過很久才能展現(xiàn)（比如超過10秒或者更久），那基本這個系統(tǒng)/或者產(chǎn)品已經(jīng)接近失敗了。另外還有一些系統(tǒng)性能和安全方面的隱性需求，都是需要進(jìn)行規(guī)劃和設(shè)計的。我在此就不一一敘述了。

作者：楊進(jìn)玉（微信號公眾號Bear-it-am），VIPABC BI產(chǎn)品經(jīng)理，4年產(chǎn)品設(shè)計經(jīng)驗，曾主導(dǎo)過企業(yè)級BI產(chǎn)品的策劃和運營工作。

本文由 @楊進(jìn)玉 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。