總所周知程式設計師和產品經理之間產生矛盾大多是因為乙個叫「需求文件]的東西，那我們應該如何撰寫乙份程式設計師真正需要的需求文件來解決這個矛盾呢？
如果一定要乙個答案：
從下面3個角度分析：
1. 因人而異
程式猿也需要畫像區分：
2. 因功能而異
通用邏輯：原型與文件並重，功能結構圖與頁面結構圖為首，流程圖為輔。
目前前端產品設計目前比較主流的方**有：場景論、資料論、功能論、設計論。無論哪一種方**前端產品就是給c端使用者看並且使用，所以原型跟文件不可缺少。
這裡額外提一句關於原型、文件的格式。我在剛從業1年的時候，一直糾結原型與文件是否一併寫入在axure。這點不重要，尊重開發團隊的習慣就好。
當年我在金生寶就使用axure＋word，到了金大師後台主要用axure為主。對於乙個優秀的pm，這些都是常用工具，需要做到用什麼都可以。
通用邏輯：流程圖、時序圖、架構圖、資料表為主，文件次之，原型為輔。
後台產品設計主要方**有：業務流論、效率成本論、效能論。主要面向企業內部使用者，目的是提公升企業整體效率：人的效率與錢的效率，包括獲客效率、服務效率、管理效率、資訊流轉效率等，對於感性體驗沒有c端產品那麼苛刻，而對於邏輯與資料會加強。
通過圖、表更能便捷、快速的反映基於業務流的本質。一張圖表現的東西，可能用10個原型頁面都未必能畫清除。
抄傢伙：
業務流程圖、系統互動圖、資訊流圖、資金流圖為主
功能列表、頁面結構表次之
原型最末
3. 寬度、深度、長度、量度
如何讓需求文件考慮更周全？我們從4個角度來說：
這在開始比較困難，有以下幾個方法可以讓我們逐漸做到。
重要業務關聯模組梳理。當產品功能越多，那麼新增乙個功能就有可能對原有功能產生影響，這就是我們所謂的看得見的耦合。看不見的耦合是在**層面。所以平時一定要多關聯業務模組有更多了解。
重要業務流節點梳理。無論是前端還是後台產品，都會有1、2條主要的業務流（人體脊柱），這些業務流中的關鍵節點類似人體的脊柱節點。在功能規劃設計的時候，提前需要考慮到。
如果業務邏輯的分離不夠導致耦合，則會導致產品功能邏輯耦合在一起，進而使得**邏輯耦合在一起，對於擴充套件、重構就是件很蛋疼的事情。這個設計理念可直接評價乙個pm的邏輯、抽象、規劃水平能力高低。有機會我詳細再寫一篇。
產品邏輯可以簡單模擬成**中的輸入於輸出關係。我的習慣是畫流程圖避免邏輯上的遺漏。
如果文件中出現思慮不周的情況，而技術小夥伴已開工，根據我的經驗，不要去彌補這個邏輯的漏洞輕易衍生出新的邏輯。有些漏洞是因為不重要，所以pm會遺漏，如果不重要那麼就放在下個迭代進行優化。
不要老搞么蛾子變動，尤其是已經定稿的開發邏輯。一定要改變，pm自己先想清楚是否會影響到其他功能。
從0到1，從1到10，從10到100，是產品的不同階段。pm有時像乙個軍師需要運籌帷幄。根據市場情況、競爭環境、公司情況、團隊能力、產品成熟度決定什麼時候做什麼功能，做到什麼火候，都是需要提前考慮的。
這點也是直接評價乙個pm水平能力高低的主要依據。當然也有一些天才，可以天馬行空設計出一些驚才絕豔的產品，在我看來，他們更有預見、洞察的能力而非胡思亂想的塗鴉之筆。
功能價值資料化，讓開發小夥伴認識到他們的每一天、每一分鐘、每一秒都是在做一件有意義、有意思的事情。與團隊達成一致的願景、使命、價值觀，不斷溝通，反覆溝通。讓這些深深印刻在團隊成員心中。讓開發小夥伴更有成就感，為他們掃清前進道路上的所有障礙。與他們站在一起，體諒他們，給他們更積極的反饋。即使在高強度、高壓力的環境下，盡量為他們創造快樂、開心的工作環境。
程式設計師如何寫出乙份好的文件？
例如，有一段描述某軟體功能的話是這樣的 該軟體模組在系統中占有重要的地位，其實現的主要功能為 2 從本地目錄中獲取檔案進行解析，並生成新的檔案放到本地的另一目錄中。3 將目錄中生成的檔案上傳到客戶指定的ftp目錄中。4 清理本地目錄中的過期檔案 清理時間及過期期限可配置 一篇 並茂的文章才是好文章，...
程式設計師如何寫出乙份好的文件？
在實際的軟體開發工作中，除了編寫 之外，程式設計師還會花大量的時間來編寫相關的研發文件，這些文件包括 詳細設計文件 單元 整合測試文件 軟體版本開發報告 軟體安裝說明 軟體公升級指導書等。在 程式設計師既要寫好 又要寫好文件 一文中，我提到過 和 文件 就像是乙個人的左膀右臂，一定要讓兩者均衡發展，...
程式設計師如何制定自己的乙份年度計畫
目錄拆分量化 階段總結 看這篇文章前，我想說，所有的計畫，如果你不堅持，都是空談，空計畫，所以如果你感覺你是乙個不能夠堅持的人，就別看了，看了也沒用。用 的話說就是 空想誤己，堅持興我。很多人不知道如何制定年度學 計畫，而乙個系統性的學 計畫，是最好的提公升自己系統性內在能力的技能。在這裡也統一為一...