產品需求文檔的十步

做好產品需求文檔的這十步,是經過長期的實踐經驗和反覆驗證而得到的。
可能這裏描述的不是很全面,但他已經足夠讓你做一個成功的產品需求文檔。
做好這幾步花費的時間要以項目的大小、複雜程度、個體學識、基本技能熟練度而定。

 

第一步:做好準備工作

  
你要做的是一個讓人無可爭議的產品,爲了做好他,你必須做好前期的準備工作。你需要去了解你的顧客、競爭對手、產品團隊的實力和需要的技術。你需要從顧客、用戶、競爭對手、分析師、產品團隊、銷售隊伍、市場、公司職員等收集他們能發現的問題和可能的解決辦法。這裏有很多的工作需要你去完成,在“成功的產品背後”這篇文章中有詳細的描述。
  建立良好的交流也非常重要,它會影響着產品團隊。如果你的準備工作做的夠好,你也會變得越來越有信心和說服力。
  
第二步:確定產品的目的

  
任何一個好的產品都開始於一個需求。你必須清楚的瞭解這個需求,你的產品如何達到這個需求。
  產品經理需要提出一個清晰、簡明的價值主張,讓它很容易被接受,要讓產品團隊、管理人員、用戶、市場人員清楚的明白這個產品到底是什麼意圖。雖然這聽起來很簡單,但是也只有少數產品纔有這樣的價值主張。考慮“velevator pitch (電梯間演講、電梯行銷)測試。假設你在做電梯的時候遇到公司CEO,他問你產品的意圖是什麼,你能在電梯到達之前回答這個問題嗎?如果不能,你就還有工作需要做。也許是你的說明沒有針對性,他可能表現出來和其他產品做的沒有什麼明顯區別;也許你提出的觀點不能和你的用戶產生共鳴;也許你解決的是一個非常規的問題,可能你想應用一種技術。這個價值主張可能需要滿足公司的產品戰略。注意你不需要闡述太多的細節,從某些方面來說,一個有價值的觀點應當是越簡越好。
   產品需求需要確切的指出這個產品發佈的目標,同樣的這個目標也有優先之分。例如,你的目標可能是:1)易用,2)零售價不足$1003)和前期產品很好的結合。然後你需要說明如何去測算。對於“易用”這類項目,你需要明確指出產品可用性達到某個水平。這是通常用目標用戶來定義。可用性工程師能測算出你的產品對目標用戶的可用性,也測算出可用性問題的嚴重程度,同樣你可以說明沒有重大的可用性問題。
  這裏的關鍵就是讓每個人都知道產品成功的時候是什麼樣,還有給產品團隊在設計和實施中遇到問題如何進行取捨的指導。
  
第三步:確定用戶原型、用戶目標和用戶任務

 

  現在你已經明白你想要解決什麼問題,接下來就要深入瞭解目標用戶和顧客,在這步中,和你的PD(產品設計)緊密聯繫非常重要。
  用戶原型

  在這個階段,PM需要和很多用戶交流,需要花費大量的時間去直接觀察和討論。現在我們需要對用戶和顧客進行分類,然後決定那一類是我們的首要用戶。
  比如你正在做一個像eBay一樣的互聯網拍賣服務,你同時擁有買家和賣家,在這之中還有使用頻率少的用戶和經常使用的用戶,不難想象還有個別特殊的用戶,比如團體公司採購者。
  PM(產品經理)和PD(產品設計)需要首先確定類型是最重要的,然後儘量對這個用戶羣的特徵進行詳細的描述,以便使用這個模型去指導產品的設計。這個模型通常稱其爲“人物角色”。 雖然是想像的,但是應該是典型的、可行的和真實的,讓你能夠使用。這個想法來自與一個能代表這類用戶的本質的原型。
  舉個例子:
  “里昂是一個超級賣家,46歲,男性,居住在Fresno,經營小型摩托車配件。雖然他開着一個小店,但是他的生意大部分來自Ebay,每個月平均有400多次交易。他出售的東西品種非常多,但是他最受歡迎的商品還是哈雷戴維森的負重袋。他自己擁有兩個哈雷,還開着1993年的豐田皮卡。里昂已經結婚了還有兩個小孩。
  里昂買電腦僅僅是因爲他需要使用Ebay,除了ebay和電子郵件很少再使用其他東西。里昂已經在Ebay上銷售產品已經三年了,他學會了在ebay應該掌握的東西,他非常自豪的擁有超過5000的信用度。如果Ebay更改了網站,特別是銷售的過程方面,對於他來說改變習慣、學習這些變更是非常困難的。 里昂已經形成了自己的習慣,星期一列出銷售的商品,星期五拍賣結束,設法讓在收到貨款的幾個小時內出貨。”
  但願這樣的描述能讓你瞭解里昂和知道他是怎麼來的。當我們考慮新功能時,我就要問問自己里昂會是什麼發應,爲了讓他能順利的使用這個功能我們需要做什麼。
  注意縮小範圍,讓他僅僅描繪必不可少的。滿足所有人是徒勞的,通常最後沒人會滿意,所以儘量提出幾個最重要的和最流行的角色描述是非常重要的。同樣,如果你不去精確的定位你的目標用戶,你就只會存在模糊的概念,你會發現理解你用戶的反應非常困難。你要傾向於設想,讓你能更像你的用戶。

 

  用戶目標(用戶意願)

  一旦我們確定並描繪了我們主要的用戶類型,我們就需要找出用戶在使用產品中的目標(想要幹什麼).這聽起來很簡單,但是解開根本問題是非常具有挑戰性的,特別當你周圍的人告訴你你已經解決了他們想要的。
  從CEO、銷售代表、工程師到客戶,每個人都太興奮而不能幫助你找到解決根本問題的辦法,他們會告訴你在某個地方添加一個快捷按鈕,或則添加一個功能僅僅是因爲競爭對手有,或則是改變成他們喜歡的顏色。
  最好的解決辦法取決於清晰的瞭解到底什麼問題需要解決,每個用戶模型可能有不同的目的,需要在用戶原型涉及的方面中進行尋找。有可能將來某個功能解決的問題並不是主要用戶需要達到的目標之一。

 

 

  用戶任務(tasks,用戶爲達到目標使用產品而需要做的任務)

  掌握了用戶原型與他們的目標願望,我們就開始着手設計任務來滿足他們的目標意願,這是產品製作進程中最核心的部分,也是創造力和創新力被激發的地方。
  許多優秀的產品僅是用更好更新的辦法解決一個已有的問題,有時候這種辦法僅僅是應用一個種新技術,但是大部分是來自深刻的見解而使一種新方法的產生。例如TiVo(美國市場佔有率第一的數字錄像機)在電視節目錄制的老問題上面想出一個全新的辦法,讓顧客更加容易地實現他們的目標並且建立了電子設備一個全新的類別。

 

  注意我們雖然談到了目標和任務但是還沒有談到具體的功能,這些功能都需要達到用戶目標而必須的。你以後會發現許多功能都是低優先級或則是完全多餘的。
  以“必須功能”這個理由可以排除很多功能。諷刺的是,你用越少的功能,你的產品被發現得越來越強大。這是因爲產品的功能越少,你的用戶就會發現並使用更多的功能,成功的使用越來越多的功能他們就認爲你的產品非常強大。這些理由都是違反我們直覺的,我們大多數人都不能和我們的用戶一樣,我們在自己的行業中願意比用戶花費更多的時間去探索功能和容忍複雜性。
  
第四步:定義產品原則

 

  現在你需要開始把你的需求和用戶體驗定義成詳細的要求。同時你仍然會面臨着許多的決定和權衡,爲你的產品標準作出最佳的決定是非常重要的。
  在大多數的產品團隊中,每個成員都有做好產品的原則,但很少有兩個人有同樣的想法,這些差異都會導致不可思議的結果。
嘗試和制訂一系列指導整個團隊的產品原則是非常有價值的,這些原則需要具體到域名和項目。
  用TiVo舉例,在產品團隊工作開始時,以下這些產品規範就被建立,並在團隊裏傳達:
    1.它是娛樂的
    2.一個傻瓜式的電視
    3.一個該死的視頻設備
    4.平滑柔順的
    5.沒有模式和深層次
    6.尊重觀衆的隱私權
    7.像電視一樣強大
  這些規範很大的影響到產品的定義而且在很大程度上加大了難度,但是他們確實是成功產品的來源。比如易趣的口號就是:1、易於使用 2、安全 3、有趣
  它將在該項目中,在面對衆多問題而作出決定的時候進行指南.

 

第五步:產品原型和檢驗

 

  這是一個拿出你想法的階段,創造力和創新力拿出成就的地方.
  很多人都容易犯一個常見的錯誤,他們對產品設計規範太有信心,結果一旦得到beta的測試他們就必須調整產品。但是肯定beta測試版並不是進行重大改變的時候,所以纔會有許多首次發佈的產品離目標太遠。
  對於許多產品來說,這個時候你可以用大量的原型做很多的實驗。首先,下面的三個非常重要的測試你可能需要做

 

  可行性測試

  一個直接的問題就是產品是否可以開發,你的工程師和設計師應當介入技術的可行性調查和探索可用辦法。有些辦法是行不通的,但是有其他的辦法可行是非常有希望的。
  工程師會發現在產品的某個階段不可能逾越,現在知道比以後知道要好。

 

  可用性測試

  產品設計師將要和你緊密工作共同提出產品功能,讓它能適應不同的用戶。可用性測試常常會找出遺漏的產品要求,同時確認產品最初的要求是否是必須的。在你拿出一個成功的用戶體驗之前需要多做一些測試工作。可用性的目的是在真正的用戶身上測試,從產品目標用戶得到質量反饋的測試是非常藝術和科學的。當然產品經理和產品設計將模仿使用,但是實際是沒有人能取代真實的目標用戶。

 

  概念測試(Product Concept Testing

  光是可用和可行是不足的。真正的問題是你的用戶想要購買嗎—你的用戶有多喜歡-你做的有什麼價值。這測試可能與可用性測試聯繫在一起。
  對於一部份小產品,您的想法寫在紙就足夠了,但是對於多數產品,爲了預計產品是否達到目標,複雜用戶互作用或新技術的使用、某種形式原型都是非常重要的。
  原型也許是一個物理設備,或者它也許是軟件產品的一個預覽版本。關鍵是它需要足夠現實,您能用原型在實際目標顧客身上測試,並且他們可以給您質量反饋。
  以前做原型主要有兩個障礙。第一是缺乏良好的原型工具,需要花費很多的時間製作原型;另一個是管理方不知道原型和真實產品的區別,在不可預計的情況下,按照最終產品來要求原型。
  今天有優秀的原型設計工具可以讓工程師或設計師快速的製作原型,可以有效的模擬未來的產品以達到必要的程度讓實際用戶進行測試。而且大多數管理者都知道模仿和實際的區別 就如同縮小比例的房子模型和真實的家一樣。
  在實際去做產品之前去檢驗你的產品是非常重要的。一旦實際的工程開始,作出重要的變動會變得非常困難,花費也會變得很高。

 

第六步:驗證和質疑

 

  當你認爲你弄懂了你需要解決的問題,現在是時候開始驗證和質疑假設。
  假設甚至當作不知道是很容易的,但是切勿把不可知的結論當作指引,那會妨礙你獲得成功。天文學最初定義是研究太陽和其他行星如何圍繞自己轉,本身的定義就是一個臆斷,反而阻止人們獲得真相。

 

第七步:寫

 

  當然你需要把這些都寫下來,大多數的PRD都是word文檔,但也有一些是幫助文檔,PowerPoint,或則寫在白紙上。當然用什麼格式不是很重要,重要的是讓團隊成功能輕鬆的看懂,不會遺漏,還有就是PRD可以隨着項目開發而更新。
  記住對話是兩個人之間的,但是PRD是要溝通整個小組。你也要記住獲得產品的銷售纔是是重要的,所以不必擔心要有什麼漂亮的外觀、PRD寫的有多厚,只要它是可讀的、可理解的、是需要的內容。
  PRD文檔主要有四個部份組成

 

  產品用途

  你的工作就是指出目標,團隊需要知道他們的目的是什麼,目標說明要儘可能的明確,請確保你的內容包括:
  *那些問題你要解決,不是解決方案
  *誰是目標用戶
  *細節很多,但是大圖片必須清晰
  *情景描述
  多開展集思廣益的會議和臨時口頭的討論,從而更好的寫出來,更會讓團隊深入瞭解。

 

  產品功能特性

  產品需求文檔最主要的當然是需求。 具體的需求完全地將取決於您的領域,但是不管你是什麼行業,您的產品團隊將受益於陳述需求的清楚,毫不含糊的要求,而不是模糊的解決方案。
  描述每個功能的互動設計和使用案例。您必須非常清楚每個功能和用戶體驗,還需要給工程團隊留下足夠多的靈活自主空間。
  同樣重要的是確定那些要求滿足哪個目的。這裏就需要提到“需求跟蹤”,對於關鍵的產品這是一個重要的流程。每種產品規範可能受益於清楚確定那些要求滿足哪個目的,如果某人決定削減要求,想要深入瞭解就會非常困難。 從要求到目的明確說明將會是文檔更加清晰。

 

  發佈標準

  發佈標準經常是不斷變化的,但是好的PRD應該考慮到爲每種標準定一個最低要求。典型的如:性能,可測量性,可靠性,可用性,可控性。

 

  時間進度

  其中很困難的一個問題就是描述產品需要的時間進度表。隨便列出一個時間是沒用的,你需要描述環境、動機、預計目標。你需要整個團隊都和你一樣達到預計目標,最終完成一個成功的產品。

 

第八步 優先級

 

  除了明確的要求,對每一個您的要求給予優先和排列秩序是很重要的。多數產品經理,如果他們給予優先級,一般都是表明要求是否是“必須有, “重要”或“希望擁有” (或其他一些分類系統)。分類是很重要的,不可掉以輕心。
  產品經理對任何一個標記“必須擁有”都需要有高度的標準。如果還沒有找到必須擁有的功能意味着產品還不應該產生。所以小心標註“必須擁有”,這些標註“必須擁有”的功能直接反應出產品的核心價值。
  “重要”的分類也很重要,在產品銷售前只要有機會就要滿足這些功能。
  “希望擁有”產品團隊也應該注意到,即使大多數也都沒有實現,在未來版本也適當的慢慢實現。
  這些有時候是不夠的,從1n每一個分類優先排序都是很重要的。有幾個原因:
  首先,上市時間總是被關注,並且日程表經常下降,您說不定被迫使削減有些特點爲了儘快進入市場。 你也不想產品團隊先開發簡單的功能而放鬆重要的功能,導致最後客戶使用的關鍵功能還沒完成。
  其次,在產品設計和開發階段,團隊將會發現更多的問題產生並解決這些問題,所以很有可能有更多關鍵功能出現。優先順序會可以幫助你如何平衡以容納更多的功能。
  這點就是說產品經理如何不給出優先級和重要等級,其他相關較少的因素也會跟着無法確定。
整個PRD是一個不斷完善和思維提高的過程,明朗銳利就是可以成功的產品的,模糊就是失敗的產品。在爭論最激烈的時候也能容易做決定,並且幫助工程師做出計劃。

 

第九步 測試完整性

 

  現在你有一個PRD草稿,你需要測試它的完整性。工程師是否可以充分了解並達到目標?OA Team(質量管理團隊)是否有足夠的信息來做出測試計劃,是否可以開始做案例?
  當投資人或相關人審覈了PRD,確定了各個需要說明的方面,所有的問題得到解決,現在你就可以按PRD進行產品開發。

 

第十步 管理產品

 

  在產品實施期間,就算是最好PRD,也有不計其數的問題被解決。解決所有PRD中存在問題,如果不在PRD中就寫進去。你的任務就是迅速解決問題並記錄在PRD
  如果你做了你的工作並準備記錄在PRD,項目審查就會變得非常簡單,因爲任何一個部份都歷歷在目。
  記住PRD是一個“活”的文件,在要跟蹤記錄在產品開發期間的所有功能過程。最後你會發現很多額外的東西,如果你認爲是必要的就在PRD中寫進。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章