1樓：小婧
我個人覺得這個要看團隊。
如果開發團隊裡面的人都比較認真負責，自己也比較有想法，流程也比較規範的話，你可以不寫太多的技術細節。
但是如果不是這樣，那最好還是寫，否則可能真的會出現掰扯不清楚的情況。
我個人覺得，在大部分的情況下，需求分析/產品經理寫一些設計系統流程和資料流程的部分是從業務和需求的角度來描述的。真正實現上，技術實現上並不要求這麼做。
就像建模還分層：概念模型、邏輯模型、物理模型。所以我覺得，需求分析/產品經理在寫需求規格SRS/PRD的時候可以涉及到概念層，甚至是邏輯層的設計和訴求。
2樓：Jeffery李
這個東西是需要的，有這個意識就已經戰勝了很多浮於表面的產品經理，有平台意識。
不過要注意，需要自己理順不代表一定要給別人看，需要拿出來還要看給誰看，適當調整下行文邏輯和切入角度，盡量站在產品應該站的視角出文件，不僅可以避免讓開發技術同學不適，還會讓他們覺得你靠譜願意合作。比如梳理資料的邏輯過程也可以寫成業務流程圖，資料庫表的要求可以寫成你對這個業務欄位的業務要求、極端邊界情況的處理規則等，這些都是業務需求，你不定開發到這裡他也要和你確認的。說的玄乎一點，第乙個段位產品看山是山，上一層段位的產品看山不是山，再上一層要看山還是山。
可能現在你已經達到第二層level了。
3樓：大豬怪
看情況吧，有時候我也會寫。比如一些重要的流程，如果不寫清楚就會影響最終產品。
但，如果技術那邊是合作過對他有了解，知道不會出問題的，我就不會寫，在介紹需求的時候說明一下，就好了。
講真，如果公司沒要求，真的需要看人下菜碟。文件的作用就是讓別人理解你想表達的東西。如果是合作過很多次的人，也許不用文件，乙個截圖，一句話對方就知道你想要做什麼，然後開始幹活。
當然，也有例外的情況，你需要把自己的智商和對方的智商都歸零，來考慮描述這個事情。
4樓：PM網事
我的建議，不要寫。除非系統資料級別的互動會影響產品的商業價值。
術業有專攻，如果有必要，你可以和設計人員溝通。
需求文件不是設計文件，需求文件本身具有權威性，要維護這種權威性。
產品經理如何寫PRD需求文件？
劉歡迎 PRD 產品需求文件 是讓所有團隊成員保持一致的答案。它作為乙個單獨文件，所有團隊成員和利益相關者，都可以理解產品的目的和需求。它不需要是乙個非常詳盡的文件，但它應該提供產品的基本概念。乙個好的PRD文件應該有以下幾個部分 產品簡介，願景和目標 產品為誰開發 為什麼要開發這個產品 競爭態勢與...
產品經理在寫需求文件的時候要詳細到什麼程度呢？
充電5分鐘 不到萬不得已不要用需求文件和研發撕逼，一旦這樣做也就說明你對研發的驅動力來自於職位而不是來自於個人。一旦大家都很規矩的做開發，那即便乙個很小的改個排版也要讓你寫個文件，想想多痛苦，產品經理的目標是盡可能快速的把產品做出來，而不是如何把文件寫的好啊。多關注工作目標，過程當中背一點鍋，多認個...
怎麼從需求分析轉換到產品經理？
力娃 產品需求主要存留在需求層面，真正產品經理需要對產品全生命週期成功負責，包括使用者導向，購買決策，投入產出經營，生命週期管理，競品監控等等 lanbang 如果你們公司沒有產品經理，你幹的事就是產品經理的事，如果你們公司有產品經理，你就要總結他和你幹的事的區別。每家公司這兩個崗位的分工配合不盡相...