其實在我剛入行做產品時和大多數新人一樣，遇到最大的一個問題就是「怎么寫需求說明文檔？」，而現在做了一年多之后回過頭來看，這個問題的答案仍然是「需要」，但我所理解的「需求說明文檔」和傳統意義上的可能不太一樣。
先來說說我們團隊現在的配置：
- 1個 CEO 兼產品 Leader
- 1個 PM（我）
- 1個 UI 設計師
- 2個后端開發
- 2個 iOS 開發
- 1個 Android 開發
- X 個運營
除了運營之外我們就只是一個不足10人的產品研發團隊，體量太小，如果是用標準的 PRD 來進行需求溝通，那太慢了，而且維護成本太高，大部分時候 PRD 并沒有起到溝通的作用，在產品的起步階段我寫了上萬字的 PRD 結果卻沒有一個工程師認真的看，在這種情況下 PRD 反倒成了累贅。
PRD 的核心作用無非就是以下幾點：
- 方便產品經理自己梳理流程和細節
- 方便其他人理解需求并按照文檔內容實現功能
而在大公司可能還有其他作用：
- 保證各部門溝通有理有據，避免撕逼
- 約束產品經理的隨意變卦
- 甚至是 KPI 的指標之一
總的來說 PRD 的作用是減少團隊溝通成本，但值得注意的是，PRD 只是需求溝通的一種形式，而不是目標，產品經理的目標應該是提供滿足需求的功能和推動功能的實現，其實大部分產品經理沒必要寫需求文檔去表述功能，尤其是在人數較少的創業團隊，只要能讓所有人理解需求功能點，具體是怎樣一種表現形式又有什么關系呢。
簡單說一下目前我們團隊開發的基本流程：
- PM 根據需求出手稿和 Leader 過一遍
- UI 設計師根據手稿出視覺稿的同時 PM 寫后端功能邏輯
- 和工程師們根據視覺稿溝通前端交互和后端功能邏輯
- 工程師評估開發周期，Leader 根據周期長短適當增刪功能后即可正式開始開發
可能我們團隊有些特殊，我和 UI 設計師異常默契，有時候甚至連手稿都不需要他就能完全把我想要的交互畫出來，大大減少了畫原型的時間；而前端工程師經驗豐富，交互基本都是通過口頭溝通對方即可理解，即使有什么遺漏的扭頭喊一聲我就馬上跪倒在其面前進行講解；測試用例近期也在進行迭代，不再使用傳統的格式「功能點、用例說明、用例編號、前置條件、測試步驟、預期結果、測試結果、失敗原因」，而是用思維導圖一句話表達即可，所以總的來說我需要產出的文檔就只有「后端功能邏輯」和「測試用例」，對于需要快速開發上線的小團隊來說，面對面溝通顯然好過文檔（關于這點當初我和 Leader 產生了分歧甚至因此大吵過一架）。
但需要注意的是這種模式并不適用于所有團隊，規范有規范的好處，隨著團隊的人數擴張，產品頁面數量越來越多，業務邏輯越來越復雜時，一份相對規范的文檔能夠幫助你理清思路，只靠單純地溝通，會顯得吃力且容易遺漏。
所以關于是否一定要寫 PRD 這一問題的答案并無絕對，需根據團隊實際情況以及產品經理的習慣，找出最適合你們的溝通方式即可，至于是用 Word 還是 PowerPoint 甚至是 Excel 都可以，而我則更喜歡用 Markdown 編輯器，畢竟能有效地傳達需求給對應的人員并確保對需求的理解一致才是根本目的，沒必要拘泥于形式。
