PRD你可能寫過很多，那么，針對AI硬件產(chǎn)品的PRD有什么不一樣嗎？

關于產(chǎn)品需求文檔（PRD），我在轉行初期也經(jīng)歷過一段糾結時光。不知道怎么寫比較好，也曾在格式、文檔軟件這些表面的東西上糾結。

經(jīng)過幾個月與研發(fā)磨合，終于明白，保持一個樸素的目標清晰的傳達產(chǎn)品概念、產(chǎn)品需求就好。

所以，我們用 word、Excel 或者咱們企業(yè)內(nèi)部的協(xié)作軟件都可以。

我個人喜歡用 Excel ，一個 Excel 文件包含多個工作簿，這樣方便管理/查看。因為研發(fā)工程師、市場、運營等部門他們都會用這個軟件。

當然也可以用其他軟件，比如 Axure 等，文件分享不方便其他部門打開文件；像 Axure 可以分享鏈接，但是不方便保存以及打開速度較慢或者有些瀏覽器根本就打不開。

如果您公司有協(xié)同軟件那挺好，直接可以在上面編輯、權限管理等；如果沒有協(xié)同軟件，我們作為產(chǎn)品人需要考慮所有使用者的觸點，方便團隊所有人使用。

以上，只是想說工具不重要，重要的是準確的傳達產(chǎn)品需求。

產(chǎn)品文檔（PRD）包含哪些？

如圖，我將產(chǎn)品需求文檔（PRD）分為三大類文檔。

如果您對技術不是很了解，《硬件需求》和《軟件需求》這兩個文檔可以裁剪掉。但是其他的一定要詳細描述清楚。

我們開產(chǎn)品評審會議時，主要講解《產(chǎn)品功能列表》《業(yè)務及功能流程》和《產(chǎn)品功能需求》。

這三個文檔詳細描述了，我們的產(chǎn)品需要哪些功能、產(chǎn)品涉及的相關業(yè)務方和流程、產(chǎn)品具體的功能/性能要求。

啰嗦一句，關于文檔命名的事情，我發(fā)現(xiàn)很多同事不喜歡將文檔命名，找起來好麻煩，也不方便管理。一定要養(yǎng)成規(guī)范命名的習慣。

我自己的命名方式：產(chǎn)品需求文檔_XX 產(chǎn)品_V1.0.1_20191210，包含文檔屬性、產(chǎn)品名稱、版本、時間。

文檔信息類

文檔類別包含《文檔信息》《項目規(guī)劃》《change list》，分別描述項目的歸屬、整體計劃、產(chǎn)品修訂信息。

《文檔信息》

這個表格表述的是整個項目的概況，方便一目了然的了解整個項目。特別是在公司項目很多的時候，這個概述很重要。

《項目計劃》

這個表格表述的是項目預研以及研發(fā)設計的整體時間規(guī)劃，公司項目少的話，可以不需要這個。一般我們做項目管理的時候有一個公司所有項目時間分配的匯總表。

《change list》

產(chǎn)品文檔關于產(chǎn)品決策的每次變更均需要詳細的記錄在案，并發(fā)送到業(yè)務相關方。防止相關業(yè)務方開發(fā)出現(xiàn)信息錯位，同時保證自己隨時查閱相關產(chǎn)品狀態(tài)。

當然，產(chǎn)品變更項目經(jīng)理會出具會簽的《變更申請表》，但是作為產(chǎn)品需要記錄產(chǎn)品完整的研發(fā)路徑。無論是作為產(chǎn)品回溯還是作為以后的經(jīng)驗參考都具備重要的意義。

產(chǎn)品需求類

《產(chǎn)品信息》

這份文檔從全局表述了產(chǎn)品的形態(tài)、規(guī)格參數(shù)、包裝等。產(chǎn)品信息全覽，方便項目組成員快速了產(chǎn)品信息。

例如：硬件工程師看一眼就是知道，這個產(chǎn)品人機交互層面包含電源開關、什么類型以及幾個功能按鍵、什么類型以及幾個指示燈、是否有功能端口、是否有其他交互附件。根據(jù)規(guī)格參數(shù)選擇什么樣的傳感器等元器件。

再例如：ID 工程師一看就明白外觀上有哪些組件，以及產(chǎn)品 ID 概念。

所以，這份文檔極大的方便項目組成員了解產(chǎn)品整體信息。

《硬件需求》

如果您對硬件不熟悉，可以不用出具這個文檔，參與到硬件團隊中，慢慢的就能學習到很多東西。待硬件工程師選型完成了，匯總到這個文檔上就好。

這個文檔的目的是規(guī)劃產(chǎn)品各功能模塊，產(chǎn)品經(jīng)理在設計產(chǎn)品的時候，可以通過這個預估硬件成本。產(chǎn)品經(jīng)理雖然出具這個文檔，但最終還是要與硬件、系統(tǒng)部門工程師深入溝通最終確定這些關鍵元器件。

《軟件需求》

這份文檔是系統(tǒng)及系統(tǒng)應用、算法等軟件按照模塊的匯總。簡明扼要的產(chǎn)品軟件需求，并不像功能需求那么詳細，做到邏輯性以及無遺漏即可。

《產(chǎn)品功能列表》

這份文檔的目的是幫助我們梳理產(chǎn)品功能，與軟件需求的區(qū)別是這份文檔只包含功能，功能底層的支持軟件不體現(xiàn)在這兒。

故此，您也可用思維導圖來表達。

產(chǎn)品評估的時候會拿出來與研發(fā)團隊評審，需要全面、無遺漏的描述產(chǎn)品功能需求。

產(chǎn)品測試時，可根據(jù)此文檔總結開發(fā)時產(chǎn)品功能是否有遺漏。

《業(yè)務及功能流程圖》

業(yè)務流程圖是表達產(chǎn)品的業(yè)務流向。

功能流程圖是表達產(chǎn)品功能關系/流向，信息流等。

我喜歡用 Axure 這個軟件來做，我覺得很好用。其實用思維導圖軟件 Xmind 以及 office Visio 都可以。

《產(chǎn)品功能需求》

根據(jù)之前我們梳理過的《產(chǎn)品功能列表》《業(yè)務及功能流程圖》制作《產(chǎn)品功能需求》。

包含功能描述，清晰無歧義的描述功能；功能的前置條件（觸發(fā)機制）以及輸出（例如執(zhí)行某個動作或功能跳轉）；并且詳細描述功能的性能要求。

上圖舉例中，需求描述我做了很多裁剪。

我們在產(chǎn)品設計的時候，一定要反復的邏輯推演，將自己置于產(chǎn)品使用場景中反復推敲，確保功能能真正解決問題。這塊很重要，很容易發(fā)生功能沖突等狀況，所以邏輯思維能力、同理心都很重要。

想想我們自己在使用某個產(chǎn)品過程中，是不是抱怨這是什么傻 X 設計。原因就是，沒做好前期設計或者沒想到那個使用場景。

我有時候想不清楚的時候，我將這個《產(chǎn)品功能需求》打印出來，然后裁成一個個小紙片貼在墻上，然后用線連接起來，逐步分析。

類似電影上警察分析的那張地圖。

在這些產(chǎn)品需求類別的文檔中，《產(chǎn)品信息》《產(chǎn)品功能列表》《業(yè)務及功能流程圖》《產(chǎn)品功能需求》非常重要，不能省略不寫。工程師是根據(jù)這幾份文檔作為設計指導文件，不然沒法開展工作。

互聯(lián)網(wǎng)平臺類

這類產(chǎn)品文檔，網(wǎng)上很多，大家可以多搜索形成自己的方式。

我個人將這類文檔做了裁剪，因為智能硬件產(chǎn)品 App 工具屬性很重，我覺得相對比較好處理。

下面簡單介紹我自己的方法。

《App 功能列表》

因為在做硬件產(chǎn)品的時候，已經(jīng)將 App 融合進來考慮很久了，所以我直接就上了 App 的功能結構、頁面結構、信息結構等，然后用原型圖做補充。

《云平臺》

這個需要我們根據(jù)產(chǎn)品屬性來考慮，比如云端需要消息轉發(fā)、云儲存、音視頻通訊、設備管理等功能需求；并且需要我們具備一點兒技術知識。不然不知道云端具體該怎么處理。

如果想學習這塊兒知識，從我們的后臺管理需要哪些功能入手進行反推，可能學習起來容易點。

小結

產(chǎn)品需求文檔（PRD）格式可以千變?nèi)f化，唯一不變的是將產(chǎn)品目標清晰的傳達給項目組的的每一位成員。

作為產(chǎn)品經(jīng)理設計產(chǎn)品的時候，用結構化思維將產(chǎn)品拆解成各個模塊，然后用邏輯思維去編織關系。

例如，我們在分析產(chǎn)品需求的時候，通過思維導圖慢慢的羅列功能，然后根據(jù)功能需求反推硬件需求以及 ID 上有什么交互組件。

一步步從上到下，從整體到局部，再深入細化，最后收斂驗證。

作者：Arvinzhou，微信號：zf519678391；公眾號：AI 硬件產(chǎn)品官（ID：AIPM001）歡迎關注我，期待與您交流

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

題圖來自 Unsplash，基于 CC0 協(xié)議