摹客
產(chǎn)品
下載
傳統(tǒng)意義上，一篇優(yōu)秀的產(chǎn)品需求文檔，往往包含8個重要的元素：項目背景、項目目標、項目方案概述、項目方案詳細描述、項目運營方案、項目風險及解決方案、項目時間計劃、項目組人員。
產(chǎn)品需求文檔之所以有如此豐富的內(nèi)容，完全是因為在最早期，一直被唯一廣泛采用的軟件開發(fā)模型——瀑布模型。瀑布模型的核心思想是采用結(jié)構(gòu)化的分析與設(shè)計方法將產(chǎn)品的邏輯實現(xiàn)與物理實現(xiàn)分開，這就使得我們產(chǎn)品的設(shè)計邏輯要足夠完善。
并且這個完善，不單單是需求明確，還要細化到每個模塊的用例結(jié)構(gòu)，以及每個功能的邏輯流程。
但現(xiàn)在很多公司的軟件開發(fā)模式都采用敏捷或迭代的開發(fā)方式，以求在最短的時間內(nèi)上線可用的產(chǎn)品版本。尤其是在敏捷開發(fā)的過程中，需求有時會在短期內(nèi)發(fā)生多次變化，所以對項目團隊的協(xié)作也有了更高的要求。在這種情況下，編寫傳統(tǒng)的PRD文檔會拖慢整個產(chǎn)品的開發(fā)節(jié)奏，也會讓整個項目的進度變的難以把控。
所以，當下的產(chǎn)品PRD文檔，已經(jīng)不適合像以往那樣，將整個產(chǎn)品的框架都囊括其中。
它的格式必須隨著產(chǎn)品開發(fā)模式和團隊協(xié)作方式的變化而變化，變得更加輕量、快速、且擁有完整的變更記錄和版本控制能力。
要說到“輕量”，似乎就繞不開一個觀點：“畫了產(chǎn)品原型，還需要寫PRD嗎？”
答案絕對是肯定的，因為無論原型的界面多么保真，交互多么還原，它都僅僅只能展示產(chǎn)品邏輯的一部分。就如同上述流程圖所示的注冊功能一樣，其中包含的“檢查激活”這個判斷，就屬于需求分析中無法用原型來展示，卻又是功能實現(xiàn)中必不可少的部分。
但其實，在快速的研發(fā)節(jié)奏和完備的需求分析中，我們是有機會實現(xiàn)完美平衡的。
最為廣泛應(yīng)用的方法是將需求描述寫在產(chǎn)品原型頁面上，如圖中黃色部分就是摹客RP中的便簽組件，它能夠很好的將該頁面內(nèi)涉及到的功能規(guī)則標注在旁側(cè)，幫助設(shè)計研發(fā)團隊能夠通過原型對產(chǎn)品有更深的理解。
另外，摹客RP還自帶了一個流程圖模式，可以直接在原型界面快速進行流程圖的繪制。通過這種一邊繪制產(chǎn)品原型界面，一邊梳理功能流程的方式，能夠幫助產(chǎn)品經(jīng)理反復(fù)推敲需求邏輯，避免信息遺漏。
盡管摹客RP已經(jīng)能夠?qū)崿F(xiàn)全面的原型注釋和流程圖繪制等功能，但用這種方式來取代需求文檔的項目還是非常少，且一般都非常輕量，團隊人數(shù)不多，溝通從成本較低。
同時，用原型來表述需求，還有個最大的問題，就是很難用可追溯的方式去記錄需求變更以及開發(fā)迭代。并且當開發(fā)團隊足夠大，項目功能足夠多的時候，也會出現(xiàn)非常困難的需求管理問題。
所以，產(chǎn)品需求文檔在更多時候，是不可以被替代的。
但并非選擇了產(chǎn)品需求文檔就等同于選擇了冗長的文字描述，因為同樣，我們也可以使用摹客的文檔功能，直接在PRD文檔中引用產(chǎn)品原型，或產(chǎn)品流程圖，快速的簡化產(chǎn)品需求文檔中相關(guān)的文字描述。同時也避免了我們平時編輯需求文檔時，因為無法實現(xiàn)流程圖在文檔中的同步展示，而需要反復(fù)修改、粘貼的過程。
而除了梳理功能和邏輯以外，產(chǎn)品需求文檔的另一個用處卻常常被大家所遺忘，那就是留檔備查。
在整個項目研發(fā)過程中，需求文檔常常需要經(jīng)過多次修改，這種需求的更迭需要用更高效便捷的方式來進行管理。
一般來說，需求文檔修改記錄一般包含版本號、修改內(nèi)容、修改人、修改時間這四大部分。而我們可以看到，用摹客管理需求文檔，可以很便捷的對版本變更進行有效的管理。他能自動保存我們需求文檔的更新版本，并同步記錄下時間和修改人，讓需求文檔的變更記錄更加簡單高效。
梳理好邏輯、表達出需求、記錄好變更、管理好版本，才是PRD的本質(zhì)。
只有明確了需求文檔呈現(xiàn)的方式，才能將他的價值最大化的發(fā)揮出來。
摹客協(xié)作
摹客RP
摹客DT
摹客超級版