請經(jīng)營好自己的需求庫,他將會成為你個人價值的一部分

8 評論 13947 瀏覽 130 收藏 10 分鐘

網(wǎng)絡中,已有太多關于PRD撰寫方法的文章了,包括我自己也曾分享過一個技巧,但是,你知道為什么要寫需求文檔嗎?

文檔我們可能寫過很多了,但是有沒有發(fā)現(xiàn)他的重要性呢?或者說,在實際工作過程中,除了評審以外,是不是就沒有什么時候用到了?

我還是強調(diào)這個觀念:10年后的現(xiàn)在,產(chǎn)品經(jīng)理已經(jīng)從探索階段逐漸發(fā)展到規(guī)模階段并且正在向標準化發(fā)展。

最早對于PRD文檔的定義,在于需求評審,以及對需求的表達。但這對于現(xiàn)在來講是不夠的(如果僅僅將需求文檔當做是表達,或者是評審的載體,那您仔細閱讀本文的內(nèi)容吧,或許對你有所啟發(fā))。

我們一起來看看,需求文檔在這些地方產(chǎn)生的影響。

產(chǎn)品技能的熟練度

對于app、HTML5、web的產(chǎn)品而言,我們的功能很大程度是受限于編程語言的,所有的功能都包含在我們基本不會觸及到的編碼邊界內(nèi)。

這個是我親身經(jīng)歷的一個示例:一個編碼邊界值在android平臺里,能夠調(diào)用的方法不能超過65536個;一旦超過后,就會無法編譯,并且提示你錯誤信息。

這意味著什么呢? 這意味著:并不存在真正意義上的“創(chuàng)造”,我們所謂的“創(chuàng)造”產(chǎn)品,都是基于已有規(guī)則內(nèi)的“應用”。

你覺得不同平臺之間的手機號碼注冊以及第三方登陸,會有什么不一樣的嗎?其實大家都是一樣的,我們都是基于一定條件下,對規(guī)則、對邏輯的應用。

既然是“應用”,就會出現(xiàn)熟練度的問題。

你有沒有發(fā)現(xiàn)大量功能的背后,是存在“類型”的,相同“類型”的功能,他的需求文檔總是驚人的相似,你需要做的,也許只是調(diào)整“參數(shù)”。

我們拿個人資料來看看吧,看看他們都是什么樣的功能類型。

微信的個人資料,設計的很是巧妙,他將預覽和編輯分離了,這對我們?nèi)ダ斫膺@個命題很有幫助。

我會這樣來寫他們的需求文檔:

重視需求文檔

點擊類的功能,不僅僅適用于個人資料,在我們的信息流頁面,基本上都是點擊類的功能,你要做的是將需求描述后面的跳轉頁面地址更換成正確的地址,就足夠了。

我們往往會先繪制原型圖,再對比原型圖進行需求文檔的撰寫,這是為了減少調(diào)整的幅度,也是為了需求的完整度,要知道很多功能隨著原型圖的改變而改變。

當你在看著原型圖時,能否立即反應出這個頁面都是什么“類型”的功能,這種“類型”的功能,通常都會有哪些“功能點”?

這是我們對產(chǎn)品技能掌握的熟練度。

我需要向你再次強調(diào)一件事實,就目前市面上大部分的產(chǎn)品而言,我們的需求文檔是相同的!你未來要做的一款新的產(chǎn)品, 他的需求文檔也和你現(xiàn)在正在做的產(chǎn)品,是相同的,你所需要的,僅僅是將已有的需求文檔,重新排列,組合。

這正如我告知你的:我們只是對規(guī)則的“應用”, 并不曾真的創(chuàng)造“規(guī)則”。

減少不必要的思考時間

從自私的角度來講,需求文檔大概是你能夠為自己做的最偷懶的事情吧,但也是你最應該做的事情。

現(xiàn)在,我在設計一個信息流時,我大概需要5分鐘來寫這個頁面的需求文檔吧?而且我可以肯定的告訴你,這份文檔會很完整,包括錯誤機制,數(shù)據(jù)獲取機制等等。保守估計,這會有40個需求點,你需要多少時間呢?

我能做到這點的原因很簡單,我對需求非常熟悉,熟悉到我只需要從我以前的需求庫中copy出來,做微小的調(diào)整就可以了。

當你擁有了一個需求庫,這個庫里保存了你一直精心維護的需求文檔,并且你平??臻e時會將他們做整理,分類,讓他們更像一個庫而不是文檔這會是什么感覺嗎?

這將會為你減少非常多的工作時間,如果每一個版本的研發(fā)周期是3周, 你在需求文檔上花的時間應該會在2天以上,并且這還會容易遺漏需求。

有沒有發(fā)現(xiàn),我們大部分的時間是在做重復的事情嗎? 不斷的重復的寫著“點擊跳轉xxx”“字符長度xx位”。

難道你沒想過有什么樣的辦法,把這些重復的,又占據(jù)了你很多時間的工作處理一下嗎?當你開始建立需求庫時,當你開始去經(jīng)營自己的需求庫時,就像經(jīng)營一個只為你服務的“產(chǎn)品”時,你應該很快就能從這樣的狀況里解放出來了。

你也不需要每一次寫需求文檔,都再去思考、擔心有沒有遺漏的,這樣的參數(shù)合不合理。這是因為:他已經(jīng)被使用過了,因為這是在你曾經(jīng)的項目過程中,就如此使用了;如果有問題, 那也一定在文檔里進行過修改了。

如果你對需求文檔足夠的重視,他將會在你未來的時間,也許是一年,也許是半年,開始回報給你。

減少團隊時間耗損

需求文檔節(jié)省的不僅僅是自己的時間,好的需求文檔還會為整個團隊帶來可觀的時間節(jié)省。

對于QA而言,是需要產(chǎn)出test case,這和我們產(chǎn)出需求文檔時一樣的,不一樣的地方在于,如果你的需求文檔不夠詳細,那么QA同學將會把我們的工作重新做一遍,并且這里面的時間耗損將是1+1>2的狀況。

這是因為在QA按照你的粗糙的需求文檔編寫測試用例時,會反復找你溝通,確認需求,因為沒有明確的需求表達,QA同學無法界定程序實現(xiàn)的正確,或者錯誤。

對于研發(fā)而言,你有沒有發(fā)現(xiàn) Android 和IOS在同一個功能上用了不同的實現(xiàn)方法,我曾經(jīng)遇到過。

在我們的需求文檔里,沒有提及首頁在數(shù)據(jù)請求后,需要將內(nèi)容緩存下來,當然,文檔里,也沒有提到“不緩存”,于是我們的IOS 沒有緩存數(shù)據(jù),而android 緩存了,最后的結果,無論是緩存還是不緩存,都有一端需要調(diào)整。

你的需求文檔,能夠最大限度的解決研發(fā)過程的漏做,錯做,自定義需求三種惡劣情況的產(chǎn)生,從而減少研發(fā)同學的編程耗時。

數(shù)據(jù)分析

我已經(jīng)和你提及了需求文檔將會為你還有你的團隊,減少許多不必要的時間耗損,相應的等同于提高了整個項目組的產(chǎn)能, 這只需要你重視自己的需求文檔。

我還會為你介紹一個原因,數(shù)據(jù)分析,這將幫助你成長。

我們這里提到的數(shù)據(jù)分析,實際上需要你對數(shù)據(jù)足夠敏感,具備數(shù)據(jù)驅動的一些思維。

你在實際工作中,會反復經(jīng)歷評審,研發(fā),評審,研發(fā)的循環(huán),如果是這樣,你一定會經(jīng)歷另外一件事情:“需求被拒絕”。

需求被拒絕的原因有很多,諸如上層不通過,研發(fā)拒絕等等,當你把這些被拒絕的需求單獨拿出來進行分析時,你會不會發(fā)現(xiàn)里面的“共性”呢?

而這些共性,則會加強你對需求的掌控力,讓你知道什么是“可以實現(xiàn)”,什么是“無法實現(xiàn)”。

冒昧問一下, 產(chǎn)品新人,和產(chǎn)品老司機的明顯差異不是正好包含:知道什么能做,也正好知道什么不能做嗎?

最后,我希望你真的能夠重視你的需求文檔,建立好自己的需求庫,這好比研發(fā)人員手里的代碼一樣,他將會成為你個人價值的一部分。

#專欄作家#

枯葉,微信公眾號,枯葉咖啡館,人人都是產(chǎn)品經(jīng)理專欄作家。擅長社交,社區(qū),細分群體挖掘。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載。

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 說的甚好,我最近也許在想如何快速而不遺漏的把需求文檔做好。最近感覺花在交互原型和需求文檔編寫的時間,基本是工作的全部的。這樣優(yōu)點不高效。

    來自廣東 回復
  2. 當有一天需求文檔也可以Ctrl c 、ctrl v的時候,文檔就不再是產(chǎn)品經(jīng)理的價值體現(xiàn)。

    回復
    1. ctrl c、ctrl v是為的是節(jié)省編寫時間,思考時間是才必須的。就好像程序員自己的代碼庫一樣,他也會ctrl c、ctrl v自己的代碼庫,但是思考還是他自己進行的,節(jié)省的是重復查找編寫的時間。

      來自廣東 回復
  3. 醍醐灌頂,感謝感謝。

    來自北京 回復
  4. :mrgreen:

    來自上海 回復
  5. 方法挺好的,可不可讓我做一回伸手黨 ??

    來自廣東 回復
    1. 啥事伸手黨

      來自上海 回復
    2. 恩?

      來自上海 回復