中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

“文章本天成，妙手偶得之?！睂懶枨笪臋n不需要“妙手”，但需要思路清晰、敘述清楚。寫的人要能把需求寫透，看的人才能看懂，一篇好的需求文檔能答疑解惑，一篇壞的需求文檔會讓人誤入歧途。

有一天，一個朋友打電話給我。

朋友：“上回聽說你們公司是做產權的，我這有訴訟相關的項目，你們能做嗎？”

老吳：“公司現在不打算接項目了，以做產品為主?！?/p>

朋友：“你在公司負責什么?。俊?/p>

老吳：“我是產品經理，負責公司的產品?！?/p>

朋友：“哦，做需求的啊，知道了。

老吳：“……”

每個公司對產品經理的定位都不同，有的產品經理負責產品的需求，有的產品經理負責產品的設計，有的產品經理負責整個產品線。不論給產品經理的定位是什么，需求對產品經理來說都是必做的功課，那么，寫需求文檔就成了我們的家常便飯。對于不同的大廚來說同樣做一道家常菜，有的做的色、香、味俱全，吃起來入口綿長、滑嫩可口；有的做的熟悉親切、感人落淚如媽媽的味道；有的做的外焦里嫩、清香撲鼻；但也有的做的慘不忍睹、不忍直視。做產品也是一樣，不同的人對產品有著不同的理解，就算理解一樣，寫出來的產品文檔也會不同。

那么，產品經理在整個需求階段要寫哪些文檔呢？

商業需求文檔BRD、市場需求文檔MRD、產品需求文檔PRD、技術需求文檔（需求規格說明書）。

• 商業需求文檔BRD。它是一種商業的需求描述，里面要體現產品的市場分析、規劃、投入、盈利預測等信息，是為了讓決策層便于分析、決策是否開發此產品的依據，商業需求文檔更像是商業計劃書，它是需求階段最早需求提供的文檔，文檔一般不長，也可以是PPT的方式展示。
• 市場需求文檔MRD。市場需求文檔是站在市場、用戶的角度，多描述用戶、購買者、客戶的需求，它是承上啟下的文檔，對技術需求文檔的編寫起到一定的指導作用。文檔中多會加入原型的形式將產品具體化，便于文檔的解釋說明。
• 產品需求文檔PRD。產品需求文檔多是站在業務的角度，讓所有的項目干系人都能夠了解、理解產品而編寫的，此文檔的閱讀者為產品的管理層、需求人員、設計人員、技術人員、測試人員、市場人員、運營人員。

需求規格說明書，此文檔是站在技術角度而編寫，文檔中不僅要描述產品的業務需求，還要描述產品的技術指標和技術參數，是架構設計、技術開發的指導性文檔。為了便于說明需求，文檔中會加入流程圖、序列圖、原型圖等設計模型，更好的讓技術人員理解、指導技術人員開發。

根據公司情況不同，PRD、MRD、BRD文檔不一定都需要編寫，這要看各公司的具體情況。我認為讓非技術人員理解產品一定要有產品需求文檔，指導技術開發一定要有需求規格說明書。產品經理要寫這么多文檔，需要貫徹產品的整個需求階段，那么產品經理一定要是一名好的方案編寫高手。

我們了解了各類文檔，也知道了他們的價值和作用，那么，文檔的編寫需要注意哪些方面呢？

正確性

我們經過調研、分析得到需求后，整理成文檔，以便于信息的保存與傳播。需求在腦子里的時可能是清晰的，但寫出來后就不一定清晰了。原因是，你腦子里想的可能是Ａ，寫出來后可能是Ａ１，但你還以為寫的是Ａ。錯誤的原因有很多可能是你的文筆不好、也可能是疏忽、還可能是你沒有把需求寫透，還有一種可能就是你當初就沒有正確的理解需求。

全面性

我們在獲取需求時盡量全面的了解問題，得到真實、準確、完整的需求，只有獲取的信息全面寫出來的需求才可能全面。另外，就算獲取需求全面了，有時寫需求時也難免有所疏漏。所有，在編寫需求時要考慮全面，建議從大到小、從粗到細進行梳理，從平臺、子系統、模塊、功能點一條一條線進行梳理，當所有的流程都遍歷完成后需求文檔也就整理完成了。

可驗證性

需求文檔中所描述的需求應該是可驗證的，如商業文檔的商業數據的出處。對于技術文檔來說，功能要有輸入項、輸出項、事前描述、約束條件，當一切條件都滿足后，輸入什么樣的數據應該輸出什么樣的結果。對于市場需求文檔，要體現用戶的邏輯思維，為什么用戶會用這樣的功能，依據是什么？是經過推理、還是心理暗示？文檔中的信息應該是可推敲、可驗證的，只有保證數據及信息來源的正確性，才能更好的把握產品。另外，只有需求文檔各接口、屬性、參數具備可驗證性，測試人員才好根據需求文檔編寫測試用例。

無二義性

中文有多音、多義字，英文也有一個單詞代表多種含義的情況，因為文檔主要是文字描述，在文檔中難免有二義性的情況。在文檔的描述中一定要保證含義清晰，表達準確。還有一種情況，就是有時產品經理自己對產品需求理解模糊，思考不深刻，在寫文檔時就不可能保證文檔的準確性。

必要性

不同的需求文檔是站在不同的角度上思考問題的，當我們從多重角度分析問題時，會對產品有更深刻的理解，哪些需求是必要的，哪些需求是次要的，哪些需求是可要可不要的。當一個產品中充斥著非必要性需求，就是喧賓奪主，有時要該“砍”則“砍”，壯士斷臂。

優先級

在產品中加入優先級，有助于讓相關人理解產品中各功能的重要度，在必要時（如開發時間緊張時）也可以考慮優先完成哪些功能。另外，在產品文檔中加入優先級，也便于產品的版本升級。但優先級，我認為不用分得太細，只需要加上“高”、“中”、“低”就好了。

以上問題都是在做產品文檔時需要注意的問題，做為產品經理，我們在獲取、分析需求時，一定要對需求準確把握，不可以有理解模糊、分析不透徹的情況。否則，在編寫文檔時就會出現更多的問題，當你再折回去重新分析需求時會浪費更多的時間和精力。需求文檔的編寫是一個很吃功力的事情，難的不是寫，而是想，只有想透了寫其它是件很容易的事。就跟寫文章一樣，在寫前在大腦中會想好題綱，寫時思路就會非常清晰。建議產品經理，在寫文檔前一定要把需求想清楚，也可以借助一些模型工具，如VISIO、AXURE等，通過模型會有利于幫助我們整理思路、梳理需求。

需求文檔的編寫是一件很費時、費力的事情，大多數公司都會認真編寫需求文檔嗎？需求文檔的下場一般會是什么樣的呢？

• 一、在很多公司，產品的前期和開發階段，文檔都會非常重視，當產品一旦進入開發后期或完成后，文檔就會束之高閣，經過多輪的產品迭代后，文檔與產品間就會完全脫節，這就是需求失敗的信號。
• 二、許多企業為了趕項目工期，前期只是有簡單的設計就進入開發階段，而且對外聲稱自己是“敏捷開發”，敏捷成為不用寫文檔的借口。實際，在開發階段，需求文檔是非常重要的，它將有效的指導開發工作，讓技術人員按照統一的標準實施，它將有利于讓技術人員統一思想，開發時也不用頻繁的進行溝通，前期需求階段多思考后開發階段就可以節省大量的時間。敏捷只適用于小團隊作戰，在大項目中，開發文檔將保證所有的技術人員按照有序的、準確的方向前行。
• 三、很多公司為了應付客戶或領導，在產品開發完成后補文檔，這時編寫的文檔基本上沒有什么價值了，真正要做好產品，需求文檔的編寫是成功的必要條件。

需求文檔在產品團隊中要如何使用和管理呢？

需求文檔應該是共享的，所有項目參與人都可見，一方面有利于干系人理解產品，還有利于其它人提出不同的意見和見解，幫助產品優化。在項目中盡量用一些版本管理工具來管理文檔，如CVS、VSS。這些版本管理工具可以設置權限，哪些人可以看哪些文檔，哪些人可以修改哪些文檔，在版本管理工具中都可以實現。另外文檔要可維護，隨著需求的變更需求文檔也會跟著變化，要保證需求文檔與產品功能一致。另外，為了保證產品文檔的風格一致，盡量讓專人負責文檔的維護工作。

本文由 @產品人老吳（微信公眾號：ChanPinLaoWu） 原創發布于人人都是產品經理。未經許可，禁止轉載。