網際網路行業加班成了一種常態！剛剛工作那段時間，每日回家瞥一眼鐘錶都已過了10點。一副疲憊的身軀拖著疲憊的心靈，彷彿全世界都顯得那麼沉重，該以怎樣的態度面對生活？貼心準備的明日午餐、舒服的洗頭體驗，讓我有一種莫名的感動。簡簡單單的點滴生活，我感覺好平靜、好純淨。
這一生感謝有你！
這段時間比較忙碌，幾乎沒有時間停下腳步去思考。繁忙的工作之外，還是抽了點時間約上幾位產品前輩和創業公司的老闆，閒談了一些關於商業和產品的軼事，不可謂不受益匪淺。與前輩年齡間的差距還是蠻大的，可以說就是乙個晚輩的取經之旅。至於行業及工作經驗更是相差甚遠，但我相信：優秀的人之間總是能產生共鳴。交流話題大致概括為兩個要點：
觀點一：傳統產業如何借助[網際網路+]轉型公升級？
觀點二：產品如何傳遞商業與使用者之間的價值？
以上兩個觀點就不作太多說明了，留給打今日與大家分享：撰寫《產品需求文件》過程中不期而遇的趣事。
有人說，產品經理無所不能、八面玲瓏！有人說，產品經理就是負責吹nb，忽悠得住老闆就萬事大吉了。大多數技術人員眼裡，產品經理就是寫文件、畫圖的，技術人員才是核心！我就不反駁了，因為這完全沒有意義。大家持有這樣的觀點，其實也不是完全沒有道理的，太多的公司太多的產品經理不都是原型、文件、撕逼三部曲嗎？有些乾脆直接一步曲搞定：原型，除了原型、還是原型。近期的主要工作圍繞《產品需求文件》，著實強化了自己的文件能力。
產品需求文件是產品經理的核心工具之一，也是產品工作的必要輸出。我恰恰是從單純的文件開啟了產品之路，因而對《產品需求文件》有著不一樣的感情。
此前參與的產品專案，分工清晰、使用者畫像主要分：b端和c端。一批人專門負責產品原型設計，一批人專門負責產品需求文件，而我被分配了b端產品需求文件的撰寫任務。下面和大家**的並不是《產品需求文件》好壞的問題，而是撰寫《產品需求文件》的準備事項和價值思考。
早期軟體工程崇尚傳統開發模式——瀑布模型，《產品需求文件》作為完整軟體過程的的核心環節之一，需要等到互動設計圖成型後才能撰寫。軟體工程是乙個經驗性的預設過程，需求文件完全概括了核心產品邏輯，更完成了產品細節的梳理。遍歷產品框架能夠了解產品的每乙個細節，對產品邏輯做到了然於胸。
產品需求評審確認、互動原型定稿之後，恰是正式開始文件編寫的最佳時機？不是！一切都要回到需求原點，需求背景、產品思路、產品經理風格都是不可忽略的要素，尤其是多方協同的團隊。等待和唏噓只能是浪費時間，對產品生命週期的掌控是每一次產品經歷的基本功，功夫不到位、自然無法獲得預期的產品效果。
產品需求文件的詳略應該控制到什麼程度？我相信：這個問題不僅困擾著我，產品線上的同事都感同身受。記得有人說，文件要盡可能寫地詳細點；也有人說，文件是寫不完的！我tm就想說，那還寫個p啊！總而言之，產品經理肯定是不可能越過產品管理的任何乙個環節，更不要說《產品需求文件》的核心環節。
之前和大家提起過乙個觀點：文件是一種政治工具！如果硬是將文件賦予一層厚黑的概念，難免讓人覺得職場黑暗。 至於現實是怎樣的？這個問題就留給我們彼此了。寫不寫文件、文件詳略程度取決於團隊成員之間的協同及默契度，scrum強調個體之間的互動，弱化文件及固有流程，倡導經驗性過程控制，如果團隊成員之間缺乏溝通和默契，那就安心寫文件吧，越詳細越好！
大家習慣性稱編寫需求文件為寫文件，而我更加願意將這一過程稱為設計文件。產品文件編寫的過程不只是碼字那麼簡單直接：
一方面：產品原型設計的書面化
二方面：產品邏輯的組織和設計
無論原型或者ui效果圖設計地多麼美，缺少良好產品邏輯框架做支撐，只能是乙個爛尾工程，結果不堪設想。設計文件是產品管理的核心環節：
一方面：檢驗產品設計者邏輯是否合理/周全
二方面：評估產品邏輯的可行性和可用性
產品邏輯可行而技術不可行或者使用者體驗可用性差，那樣的產品設計、文件都沒有意義？梳理產品設計者的產品邏輯，矯正不合理的地方，為後續產品過程前置掃雷，意義非凡。
產品經理的關鍵工作輸出：文件和原型，兩者之間關係如何？這個問題至今都沒有取得乙個令自己滿意的回答。流傳的原型和文件的言論還是層出不窮的，文件無用論、文件多餘論、敏捷開**，貌似都一致降低文件存在的作用和意義，透露著一股怨婦的苦楚，想必是經歷了文件的一番折磨。
簡潔、直觀的原型，視覺化程度高；文件明確詳細，可靠性更高。兩者之間互補、競爭——彼此都希望更加完整地表達產品的每一層邏輯、每乙個細節。產品原型、文件都想在各自的層面窮盡產品的全部，略顯苛刻，因而也可能造成相互依賴的惡跡。不妨將這種微妙關係看成冤家之間的相愛相殺！
謹記那句話：文件只是手段不是目的。如果文件只是文件，那就變了味了；未能解決問題，那就得不償失了！產品管理過程，規劃階段對產品方案的精雕細琢、設計階段對產品原型的細節苛求、執行階段對產品文件的高標準輸出。設計文件的過程，產品經理不僅要克服自身的浮躁不安，也要洞悉產品被賦予的產品邏輯/細節，知己知彼、百戰不勝。
note：寫於2023年3月16日，整理於2023年1月14日清晨。
我是王偉
很開心和大家分享，而我想把開心一直繼續！希望對大家有點幫助！
作者簡介：
《產品經理那些事兒》
產品經理那些事兒 基本資訊 叢書名 圖靈原創 出版社 人民郵電出版社 isbn 9787115344656 出版日期 2014 年2月 開本 16開 頁碼 1 版次 1 1 所屬分類 經濟管理 管理 企業管理 綜合 計算機 電子商務與計算機文化 綜合 更多關於 產品經理那些事兒 史上最全 乾貨最多 ...
產品發布的那些事兒
產品發布需要注意的一些事項，由於自己目前的產品經驗還很少涉及產品發布的階段，所以這一塊就簡單記錄一下 首先是技術和流程上的相關方 業務部門和使用者的相關方 發布通知盡可能冷靜克制，發到合適的人就好了，別漏掉誰，也別什麼事兒都興師動眾給全公司發郵件。這個過程跟做產品設計時理解使用者場景的過程類似，我們...
編寫產品需求文件
1做好準備工作 你需要去了解你的顧客 競爭對手 產品團隊的實力和需要的技術。你需要從顧客 使用者 競爭對手 分析師 產品團隊 銷售隊伍 市場 公司職員等收集他們能發現的問題和可能的解決辦法。這裡有很多的工作需要你去完成,在 成功的產品背後 這篇文章中有詳細的描述。2確定產品的目的 注意你不需要闡述太...