如何正確的看待:產品需求文檔和產品需求
其實那會還在北京的時候,就曾經寫了篇文章叫《正確的寫產品需求文檔(PRD)》后來被轉載無數,現在想想那會還僅僅是停留在技能的熟練度一樣,或者說通過這篇文章可以讓大家掌握一種快速文檔的套路。
因為最近還是有很多新人問我要產品需求文檔,他們很想看看一個典型的產品需求文檔應該是什么樣的,我直接拒絕了,我一般會說:“請多想想”。我是這么的理解:看文檔本身其實是沒有意義的,特別是產品需求文檔,其實是需求的產物。作為產物就好比是你今天用一個手機,看手機的說明書一樣,你已經知道了這個產品是什么樣子,但是為什么這么做,如何做?先做什么,后做什么,你還是不知道!
所以從產品需求而言,文檔本身沒有個推導的過程。這也就回到一個問題上,很多產品經理新人本身是意識不到,如何做需求,如何寫需求文檔的差別的。在他們的潛意識里,反正公司是需要有產品需求文檔這么一種載體來表達他們的想法,所以很自然而然的認為,學會了寫需求文檔,就掌握了如何做需求,處理需求一樣。
這樣聽起來有點繞口,但我表達的觀點是:想與做的過程是分開的。一個是過程,一個是因為有這個過程的產物,很可能很多時候產物本身可能沒有太多的意義。但從表象上來看,文檔寫的有沒有邏輯感,有沒有層次感,表述的文字是否清晰、清楚也是一種境界。
很多時候我們寫方案做PPT,很多人寫出來的東西是完全不一樣的。那PPT的宗旨是:簡單、標題化、有視圖、也不乏空洞。之所以舉這個例子,其實是所以一樣的情況。寫產品需求文檔本身其實更多的是:產品需求推導的過程。因為先有了推導的過程,然后再有了推導的結果。很順利成章的,各位產品經理新入門的朋友,你是否也具有:“產品推導”的過程呢?
產品推導的過程是:做什么,為什么要這么做,誰來做,怎么做,一步步怎么做,最后做成什么樣,最什么要做成這樣,不做成那樣。寫需求文檔的過程其實就是處理需求的過程,所以以上這幾點有沒有寫想明白?很多公司要做一個產品,可能高層是想要一個東西,但在執行的過程中因為上下級之間認識、理解的不一樣,所以在執行的過程中或多或少有所偏差。所以在這個過程中,回答上面幾個本質的問題,是會糾正你做需求的思路,不會做彎路。
產品經理這個群體是個很奇怪的群體,他們的主觀性非常的強,喜歡把產品按自己的興趣和喜好去做,所以得出一個結果本身不難。因為這個結果很可能是出于產品經理主觀喜歡的結果,但如果從過程出發得到一個結果,這個時候大家相比一下過程和結果本身而言,對于結果的認識想必也會不太一樣。
結合今天說的主題:《如何媒體正確的看待:產品需求文檔和產品需求》,產品需求文檔可以是沒有固定格式的,大家不要把產品需求文檔想象的怎么樣怎么樣。寫產品需求文檔,是做產品經理的一個基本能力,寫的邏輯感怎么、層次感怎么樣,寫的是否清晰和明白,是有一定差別的。但本質上不管是excel、word、rose、還是txt,其實都是次要的。
宗旨:讓給你需求拍板的人,知道你的邏輯是什么,讓和你一起做的程序員很清晰的知道需求是什么,讓給你一起測試的人員知道你的細節就可以了。以后也方便于版本升級,知道你一個版本、一個版本都加了哪些需求,改了哪些需求,刪了哪些知道需求就可。 所以文檔本身起到的東西就是這個,一個是告知,一個是存檔。
但產品需求是本質核心的東西,只有你想明白要做什么,怎么做,誰來做,一步步推導的過程是否合理、是否讓自己信服,讓別人信服,這才是最根本的。有了這個做保障產品需求在文檔化的過程中,才會層次分明,結構清晰。所以當很多朋友一直在問我文檔怎么寫的時候,請大家好好的想一想:我應該在哪幾個方面處理這個需求,需求的維度怎么切割?需求的優先級怎么切分?哪些是核心的,對整個產品起到重大關鍵的?哪些是錦上添花的?哪些是可有可無的?需求的主線是什么?……等等
只有想明白了這些,才會輪到如何把產品需求,進行文檔化的階段。這個時間,我們再回顧頭看看《正確的寫產品需求文檔(PRD)》,通過一些小的思維方式把寫文檔的技能組織起來,發現所有的一切都是那么順利成章。最后也忠誠的建議大家:要想學會寫需求文檔,請先學會怎么樣分析需求開始。生活也一樣,從本質看起,這樣我們感受到的會不一樣。
本文作者: 費杰
發表日期: 2010-08-15
文章鏈接:?如何正確的看待:產品需求文檔和產品需求
- 目前還沒評論,等你發揮!