產品需求如何列出節點

⑴ 產品需求文檔模板

首先告訴你產品需求文檔肯定是有的！一個經過實際工作檢驗、經歷過「質疑」、「挑戰」和「斗爭」之後沉澱下來的模板，肯定是已經吸收了各類人的偏好、意見，固化了很多符合實際業務必須的內容要求，能夠起到很好的業務承接作用。格式化、標准化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種「標准」的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。

不過，在享受別人智力和經驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，並在此過程中形成自己對於模板的理解，進而形成對於產品需求文檔的理解，在理解中使用，裁剪和優化。

要理解和分析模板，理解和分析產品需求文檔，可以運用以下幾個方法：

一、描述-解釋-預測-監控

描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據自己的觀察得到的現象、由此現象所產生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現象的反應等信息進行描述。

解釋，是回答 「為什麼」，是對於描述的理解、歸類、定義和解釋。其目標是將描述內容背後的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對於描述內容有更清晰、更細致、全面的了解。

預測，根據以因果關系為內容的內在聯系，相互影響來推導未來的發展或者將要發生的事情。通過研究解釋內在的聯系，准確地表達內在聯系，從中推導出正確的預測。

監控，是對於預測行為、現象的觀察和監督，包括了觀察到的預測中的行為、現象的發生或者預測以外的行為、現象的外發生，以及因此而採取的對應的反映動作；這些反映動作是預測過程中根據內在聯系制定的「響應」機制，並任其自然發生或者通過提供「系統」的自製能力來實現。

二、需求准備、編寫和檢查

回歸到產品經理的日常工作中，在時間佔比上較為集中的就是產品需求管理了，包括了需求的准備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監控這個通用的科學分析過程也同樣使用，且可以貫穿其中，並可以幫助理解、形成並固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。

1. 描述

描述的過程是客觀的進行「需求向」描述的過程，是一個「背景」信息的補充，用來說明，這個需求文檔的源出是什麼，是針對什麼問題，這個問題是在具體什麼領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現之前，當前的解決方案存在的問題是什麼，參與者是怎麼解決的，解決的情況怎麼樣，是好，還是不好，還是勉強可以，對於新的需求的緊迫性是什麼樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統一作為背景去理解一個現實的業務場景和「溝通字典」，避免在溝通中因為誤解而產生不必要的偏差。

需求准備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業、同業規則現狀等）；

需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；

需求編寫的過程：描述需求目的、背景、時間和結果要求、業務流程、交互過程、系統架構、干係人角色和影響范圍；

需求檢查的過程：需求的背景、目標、過程、干係人、結果預測和預防的完整性檢查；

2. 解釋

解釋在需求來源的基礎上描述了 「為什麼」接下來這個需求可以解決遇到的問題，同時還加入了「是什麼」和「怎麼樣」的部分。就是這個需求是通過怎麼樣的方法解決了「描述」過程中提到的問題，這個新的解決方法需要要做什麼，對於原有的業務過程有哪些改變，會提升什麼，會降低什麼，會影響哪些人、哪些業務部分、哪些業務系統以及哪些數據的產生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上佔比最大的一部分。

這里的解釋根據產品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對於運營的影響，對於前端市場的影響，對於用戶的影響，對於財務、法務的影響；從技術開發、技術實現維度，比如對於前端開發的影響、對於服務端開發的影響、對於數據平台的影響，還可能涉及到對於運維資源的影響等；因此對應到實際的產品需求工作中：

需求准備的過程：了解需求可能涉及的相關業務系統及系統對應的數據流程和邏輯、了解需求可能涉及的外部服務的數據流程和邏輯；了解面向的內外部用戶的產品使用水平、學習能力和使用習慣；

需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；

需求編寫的過程：詳細描述需求的業務流程，通過各種圖表格式說明新的解決方法在各服務系統之間、各業務部門之間、用戶與產品，產品與後服務之間的數據、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業務節點明確的輸出物和節點標志，重要性和優先順序；系統架構、干係人角色和影響范圍；

需求檢查的過程：需求的流程、用戶交互動作、系統信息交互等完整性檢查；

3. 預測與監控

預測與監控在產品需求文檔的管理上是聯動的，是對於預測的事件發生的時候，進行管理的機制，監控=預測+干預。在產品需求文檔的管理上，對於設計好的業務流程、使用功能，在實際過程中可能會出現這樣或者那樣的 「非規劃」的使用，也就是我們通常說的「用戶並不總是按照產品設計的方式來使用產品，而且，往往相反。」因此，這部分內容很大的比例需要來對於用戶的行為進行預測和監控，並提供「預防」或者「解決」方案。其中：

預防在於，預測產品的用戶在使用的過程中，可能會進行的一些超過產品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產品、功能沒有包容性，缺乏引導性，導致了最後操作的失敗，預想的結果沒有實現，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多採用導航、提示等，不同的系統都有各自標准化的控價，我們在這里不做展開。

解決在於，預測產品的用戶在使用產品的過程中，因誤解、操作手誤而進行了「非標」、「超規」使用「掉出」原本設計的業務流程和操作流程的情況下，需要提供額外的流程和控制來「回轉」用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過「導航」引導「跳轉」和「返回」、「回退」來實現。對應到實際的產品需求工作中：

需求准備的過程：了解用戶特徵和使用水平、評估、比較不同方式實現需求對於用戶行為的可控性和「非常規」操作的危害程度；

需求分析的過程：選擇和確定需求實現方案，評估行為管理方式和管理機制；

需求編寫的過程：詳細描述需求的業務流程和交互過程中可能出現的用戶異常操作，相應異常操作中系統反應，系統對應的控制和引導；

需求檢查的過程：需求「異常」流程和相應引導、控制地完整性檢查；

在需求管理的過程中，就可以按照這個 描述——解釋——預測——監控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之後的檢查。

四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標准。所謂標准文檔，就可以按照這四個模塊作為框架、內容和格式。

寫在最後

產品需求文檔作為產品經理同視覺設計、交互設計以及技術開發人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創作。一個完整的、充分溝通確認，並最終達成多方理解和共識的產品需求文檔，能夠最大限度的還原產品、功能的設計，保證產品、功能的實現，最大限度的減少因為各方理解的偏差而造成的時間、人力和經濟資源的浪費及復工。

⑵ 【干貨1】如何寫好產品需求規格說明書（PRD）

PRD，即產品需求文檔，是產品項目從概念化階段過渡到圖紙化階段的重要文件。它不僅涵蓋了產品的戰略層面，也包含了戰術層面的需求描述。PRD的主要用途包括：開發團隊能從文檔中獲取整個產品的邏輯設計；測試團隊據此構建測試用例；項目經理通過PRD拆分工作包，並合理分配開發人員；而交互設計師則根據PRD設計產品的交互細節。在項目啟動前，PRD是必須要經過評審確定的最關鍵文檔。

產品經理的PRD就像是建築設計師的設計藍圖，是設計和思考的結晶，同時也是思考過程的呈現。其另一個重要功能是定義產品需求，並在團隊內部達成共識。PRD文檔常見的形式有Word文檔、圖片或交互原型。

Word版PRD是傳統意義上的PRD文檔，主要包含了信息結構、限制條件、業務流程、產品用例、非功能性需求等內容。該文檔的閱讀對象主要為技術人員，因此其目的是清晰地描述產品的功能需求，減少不必要的文字，讓讀者能夠快速理解產品意圖。在撰寫時應盡量簡化文檔內容。

信息結構是產品結構的基石，類似於建築設計時考慮的整個建築的布局，包括美食區、服裝區、百貨區、休閑娛樂區等，每個區域又可以按照商家或類型進一步細分。產品的功能和內容按照維度組成頻道/模塊，最終形成完整的產品結構。

限制條件部分描述了產品的全局性需求，如網站產品的頁面編碼、用戶角色，移動產品的緩存機制、下載機制等。例如，移動產品的「狀態維持與恢復」需求，即用戶退出產品後，系統需要保持用戶操作前的狀態，當用戶返回時，系統能恢復到之前的操作狀態，並繼續使用。維持狀態包括流程操作、信息瀏覽、文本輸入、文件下載等，即使在鎖屏狀態，如果有下載任務，仍會繼續進行。

業務流程分析有助於產品經理理解產品的邏輯，特別是涉及到多個角色的B端產品流程，可以使用泳道圖來呈現，而C端產品則通常較為單一。在分析業務流程時，狀態圖和順序圖等工具也可以幫助梳理邏輯。

產品用例是描述流程中某個節點的具體需求，例如會員中心下的內容管理模塊，其中包含的具體用例有新增文章、修改文章、刪除文章、查看文章列表、查看文章詳情等。每個用例都應該包含用例編號、用例名稱、使用角色、優先順序、描述、前置條件、後置條件、界面、規則描述和其它說明等內容。

描述產品用例時，規則部分尤為重要，主要涉及數據規則、狀態邏輯和交互規則等。數據規則描述了頁面從資料庫獲取並展示數據的規則，如文章列表頁面展示哪些欄位、每個欄位的類型及長度、列表的排序規則、刷新頻率等。狀態邏輯描述了不同狀態之間的切換條件，如文章狀態為已發布，變為下架可能的觸發條件。交互規則詳細說明了界面上存在的交互元素的規則，包括鏈接、按鈕、滑動、下拉等具體交互規則及異常處理。此外，還需考慮網路問題、系統問題導致的異常情況。

非功能性需求涵蓋了性能需求（如訪問速度、最大並發用戶數）、設計需求（如風格偏好）以及統計需求（如數據欄位、報表生成）等內容。撰寫PRD文檔時，需要將這些非功能性需求考慮在內，以確保產品的全面性和實用性。

撰寫PRD文檔是產品經理的基本能力之一，良好的文檔能力有助於提高團隊間的溝通效率。本文提供了撰寫PRD文檔的基本框架和注意事項，希望能對讀者有所幫助。下一篇文章將更深入地探討PRD文檔的撰寫技巧，敬請期待。

⑶ 新產品開發中TR1,TR2,TR3..具體指什麼

在新產品產品開發中，TR代表的是技術評審環節的節點。

以下對各個技術評審點的說明：

TR1——概念產生階段技術評審點：產品需求和概念技術評審（業務需求評審）。

TR2——需求計劃階段技術評審點：需求分解和需求規格評審（功能需求評審，產品級規格）。

TR3——架構計劃階段技術評審點：總體方案評審（系統設計，架構設計，概要設計）。

(3)產品需求如何列出節點擴展閱讀：

主要特點是由一組評審者按照規范的步驟對軟體需求、設計、代碼或其他技術文檔進行仔細地檢查，以找出和消除其中的缺陷。

技術評審為新手提供軟體分析、設計和實現的培訓途經，後備、後續開發人員也可以通過正規技術評審熟悉他人開發的軟體。

評審小組至少由3人組成（包括被審材料作者），一般為4至7人。通常，概要性的設計文檔需要較多評審人員，涉及詳細技術的評審只需要較少的評審人員。

⑷ 我想做一個產品，產品的研發製作過程是怎麼樣的

大家好，我是隔壁丶老師，下面對一般產品的開發流程做旁派正一些介紹。

產品可以分為很多種，包括但不限於電子產品、軟體、食品、首飾、服飾、機械、玩具等。

對於一般的產品，主要可以分為如下幾個階段：

1.產品策劃與需求分析

2.可行性評估與制定開發計劃

3.產品方案框架設計

4.產品方案詳細設計

5.產品方案驗證

6.產品小批量試產

7.產品首批試產

（高亮表示該階段更為重要）

階段1：產品策劃與需求分析

這個階段是所有的產品都應該仔細進行與完成的階段，是為了明確產品開發目的，統一團隊目標，判斷是否能夠開展的重要環節。

主要的任務為（不分先後）：

1.確定產品市場定位及目標消費人群。也就是分析將來誰會購買這個產品，如何進一步的滿足他們的需求，年輕人/老年人，男性/女性，企業/個人，甚至是更為針對性的群體，區別很大。

2.規劃產品性能和功能需求。性能是產品的核心競爭力，功能則為產品錦上添花，更要仔細的分析與規劃核心功能。

3.初步規劃產品成本。不僅是規劃產品未來的生產成本，研發的投入成本也需要進行規劃，特別是人力與時間、外包成本等，估算需要籌集或開銷的資金，判斷是否能夠滿足。

4.與競品的對標分析。尋找市場上是否有相近似的產品，如果有，那麼要考慮如何與現有產品競爭並擊敗他們，又或者是如何搶占市場份額；如果沒有，則要考慮如何讓客戶接受新產品。

確定產品的特定要求。比如必須滿足的法律法規、認證、生產許可要求，價格要求、外形特點、尺寸、結構形式、產品包裝與材料等。

階段2：可行性評估與制定開發計劃

進入這一階段，則是為了確認產品是否有可能在規劃的時間與成本內被開發出來。

主要任務為（不分先後）：

1.確定產品技術的可行性。需要專業的技術人員從技術的角度評估現有技術能否滿足產品開發需求，包括材料、運悔生產工藝、元器件供應等方面均需要進行考慮。

2.初步估計產品的成本。根據產品的可行性分析，將所涉及的主要元器件、材料價格等估算產品的大致生產成本，評估是否滿足規劃要求。

3.評估產品生產效率和生產規劃。在產品開發的初期，就應當考慮是否有合適的廠家或者產線進行生產，如果沒有，則需要進行仔細的評估。

4.元器件與材料供應情況評估。產品所需的元器件或者材料是不是需要定製，或者都是易於采購的標准間，供應商的供貨能力與周期，甚至運輸周期、費用等問題，都將直接影響到產品的研發周期。

5.檢驗檢測能力評估。產品的性能與功能如何進行檢測，特別是如何判定是否滿足強制性的法律法規要求，也是需要進行考慮的問題。

6.確定產品的開發周期與節點。計劃好開發的時間節點，分配好各項任務的負責人，進而對整個項目進度進行監控，是做好產品開發的有效管理手段。

（產品的性能、功能與成本永遠是產品開發所需要進行權衡與考量的關鍵所在，到底向哪方面妥協，都可能影響到產品最終的效果）

階段3：產品方案框架設計

在確認了產品方案可行後，就要對產品進行初步的設計與驗證。進一步的確認產品技術方面的可行性。

主要任務為：

1.制定產品大致方案。

2.將關鍵元器件組裝成初代實驗機進行實驗，判斷性能、功能等關鍵項目是否滿足要求。

3.參照相關測試標准，對初代實驗機進行測試。如果不能通過，則需要更換方案再次進行測試，直至滿足要求。

4.根據測試結果，確定產品的大致方案。包括元器件選型、結構方案、電氣方案、控制器方案、操作軟體、包裝方案的初步確定。

階段4：產品方案詳細設計

這一階段是產品研發製作最關鍵，也是難度最高的部分。將方案從框架落實到產品的各個方面，都將面臨一道又一道的考驗，一次又一次的修改方案與測試。

主要任務為：

1.按初步設計方案采購與製造相應的元器件材料，製造或組裝一定數量較為完整樣機。

2.參照相關測試標准（國標、認證標准、企業內部標准等），對初代實驗機進行測試，檢測並判斷各項設計指標是否符合設計要求與標准要求，並根據測試結果進行針對性的改進，直至能夠同時滿足所有的標准要求與產品開發需求。

3.根據測試結果與改進後的方案，確定產品各設計板塊的最終方案。

階段5：產品方案驗證

這一階段的目的，是對方案進行最終的確認，再次驗證產品設計是否滿足需求。

1.按最終方案，模擬實際生產組裝一定數量的完整樣機。

2.參照相關測試標准（企標），對實驗機進行全面測試，檢測並判斷各項設計指標是否符合設計要求與標准要求。

3.全面考察產品的方案是否滿足需求（各板塊必須全部合格）。

4.對於一些需要進行認證的產品（如3C認羨鉛證、生產許可證、CE認證等），需要准備相關資料與手續，進行認證工作。

5.根據產品需要，申請相關專利、軟體著作權等知識產權保護。切記在產品公開之前完成專利的申請工作。

階段6：產品小批量試產

這一階段是為了用較低的成本測試產品的生產效率，以及尋找優化生產效率的可能性，排查在實際生產過程中導致的產品不合格的因素，提升良品率。

1.使用經過驗證後的產品方案，在實際生產線正式生產一定數量的產品，考察產品的生產效率。

2.參照相關測試標准（企標），對產品進行抽測，分析產品的合格率以及良品率是否滿足要求。

3.根據發現的問題，進行針對性的優化，如改動過大，可能需要再次進行產品方案驗證。

階段7：產品首批試產

本階段與小批量試產的區別只是產品生產數量上的區別，可能在實際的產品開發中忽略這一階段。

1.按小批試產通過後的（整改後）方案，在實際生產線正式生產一定數量的產品，考察產品的生產效率。

2.參照相關測試標准（企標），對產品進行抽測，分析產品的合格率以及良品率是否滿足要求。

3.根據發現的問題，進行針對性的優化。

經過了上述七個階段，並且全部通過後，產品就可以正式的定型了。

後續在銷售與客戶使用中接收到的反饋，可以對產品進行改進，或者開發新一代的產品。

當然，上述的階段在實際的產品開發過程中，不一定是一步一步的進行，有些階段可能進行了合並或簡化，一些階段可能會同時進行。這也取決於開發團隊的管理模式、生產規模與實際需求。

作為一名過來人，建議大家在產品開發的過程中，做好更多的前期工作，以及在設計中留有改進的餘地或者空間，以防項目在後期需要修改而導致對前期的方案推倒重來，造成不必要的損失。

以上，就是一個產品的大致研發製作過程。希望能夠對大家有所幫助。

1產品的設計:產品的業務模型與流程要設計好，如果有UI的話先做好UI模型，把整個產品原型完全程序出來。

2技術選型與架構設計。產品原型出來後就可以進行技術選型，根據產品的要求，選擇最高效與簡潔的技術方案。技術選型完成後就可以進行整體架構設計。如果產品比較復雜，做完架構設計在分模塊進行詳細設計，具體到模塊功能的設計，業務流程，介面定義等。

3開發與測試階段。技術方案出來後評審通過，就可以按設計進行開發。開發過程涉及到細節與設計沖突或不明確，可以討論再進行修補方案。開發完成後一般開發先進行基本功能的單元測試，單元測試完成後提交版本交付給系統測試（黑盒測試），測試與開發過程中可能有多次駁回與重提版本的過程。

4測試完成上線。產品測試通過後就可以准備伺服器部署上線。一般由運維人員部署上線。

5產品運營。產品上線後交付與運營人員進行運營。

6產品迭代。產品運營過程中，有反饋需求的可以對產品再進行迭代開發，不斷完善產品。

互聯網產品，如果需求確定的話，按大公司的流程一般是這樣的

一、產品經理根據需求畫原型圖

二、調配開發資源，協調後端開發工程師，前端開發工程師

三、以最小化可運行單元迭代開發，一般以周為單位

四、協調運維分配機器，然後上線

當然如果需求和立項都不確定的話，也需要花很長時間確定需求，計算投入等預算

如果是創業初期就不用考慮那麼多了，自己確定好方向找個開發，最好前端後端都會的，開編碼就好了，一切從簡。

如果是其他實物類商品，那就找代工廠吧，一般都有，你設置好圖紙，人家基本會定製做。