作為網際網路公司的pm(產品經理)，我們需要面對眾多部門，因為自己就是項鍊裡的那根線。需要書寫各種文件，最常見的就是prd(產品需求文件)，當然根據重量級和時間等多因素，可以提交不同類別的，例如drd(設計需求文件)和erd(工程需求文件)。嘿嘿，drd和erd是我自己發明的。更多小的ecr級別專案中，文件大家寫的都很自由。
今天晚上在跟工程師討論中，得到了一些啟發，摘錄部分。
給工程師看的文件
1 工程師程式設計客棧喜歡看結構化文件，不喜歡看描述性文件。
描述性文件也要給工程師看，並且最好親口說，因為這對理解程式設計客棧產品策略和發展方向有幫助，工程師可以幫助pm彌補沒考慮到的地方
2 工程師喜歡流程圖甚於mockup，而mockup是給領導給m程式設計客棧arketing等成員看最合適；
並不絕對，初級工程師反倒喜歡mockup，而高階工程師經驗多了兩者沒區別
3 mockup是畫大餅，產生食慾，爭取資源和獲得理解的方式。「有**的選單永遠比只列菜名的選單受歡迎」，這是馬總說過的；
mockup務必不要過於精細，否則累的是pm，領導和其他團隊會一開始就進入細節盤問階段，不利於表述產品目的和大的功能模組
4 工程師更喜歡菜譜，而且是西式菜譜。做一道菜需要幾分鐘，幾滴色拉油，烤爐溫度和時間，需要哪些工序，前後順序和量化歸納。
這個並不絕對，聰明的工程師不喜歡菜譜，不喜歡純粹編碼。有些時候不妨像做中國菜一樣，給對方發揮餘地。只是碰上好搭檔的概率不多，更多情況下菜譜更保險
5 軟體工程是西方的泊來物，標準化文件非常重要。很多老外pm希望達到一種境界，進行完詳盡的分析和文件後，開發人員按部就班就行了。中國人做菜喜歡個性發揮，油鹽醬醋通常都需要自己拿捏，菜譜上多「少許、半勺、少量」等描述性詞語。有時候pm也希望工程師這樣做菜，我們想吃甜味，但放多少克糖是需要廚師自己揣摩。
6 自己揣摩有利有弊，好處是pm省心，壞處是專案不可控。如果從風險角度考慮，軟體工程中的過程改進及文件管理是受歡迎的。
給介面設計師看的文件
除了工程師，那麼ui設計師的drd(設計需求文件)又該怎樣拿捏？
ms office的visio在pm中比較受歡迎，對於那種沒有fw和ps操作經驗的pm來說就更重要了。當然你也可以使用word，但word在畫框圖方面可視為不專業，對於入門級pm或者輕量級設計框圖也適用。
對word下了這麼個定論，非常慚愧。工具是死的，人是活的，高階pm也能做到拈花折枝即可殺人的境界。
根據我的經驗，如果專案一旦正式啟動，pm最好不要採用photoshop或者fireworks等軟體自己來做設計。那樣會讓自己陷入細節，總想著跟ued去pk設計技巧，做了自己不該做的事。因為visio已經將模組做成控制項，所以自己不需要拉框線，做精細的按鈕。
對於介面設計，除了正常的介面文案外，其他輔助性文字盡量使用一整塊的灰塊表示，pm不要陷入按鈕和字型設計中。pm的眼睛應該像眺望遠方一樣，看到的只是起伏的群山輪廓，至於山上長的樹是什麼顏色，相信ued。
倘若pm有空餘時間，而且專案並非公司會投入ue資源去做的，還處於idea階段。那麼自己不妨用ps或fw做些精細設計。畢竟在立項前，ppt中配上能看上的圖，會增色很多，也更有說服力。讓每個人頭腦中不會出現1000個想象的產品，可以統一起來。至於精細到多細，要自己把握，這很花費時間的。乙個半成品的demo專業ued也需要2－3個工作日，拿業餘時間設計是不可能精細到那種地步。如果非要有個衡量標準，那就是圖層盡量控制在100個以內，不要使用需滑鼠貝賽爾曲線效果，少用染色效果，不用濾鏡。
給ued的設計稿，參考紙媒在版排前的草圖，那種黑www.cppcns.com白框線，文字用灰色細條代替。有空我再思考總結如何具體把握。如下圖：
最簡單的線框圖
多個頁面的線框圖
某個具體頁面線框圖
名詞解釋：
rd：research and development,在這裡是指研發人員，就是公司的工程師
mockup：圖樣，原型圖，在這裡的意思是初始設計圖
ued：user experience designer ，使用者體驗設計。
本文標題: 產品經理如何寫好產品文件
本文位址: /news/plan/63392.html
產品人如何寫好產品分析報告？
體驗產品是pm工作中經常做的事情，企業也常留一些這樣的實習作業給面試者，是因為產品體驗報告一定程度上直觀的反映了面試者的專業水平。求職過程中，如果能提交乙份專業的體驗報告，將大大提公升簡歷通過率，獲得面試機會。關於體驗報告思考 產品體驗報告的定位 依據使用者的需求分析，體驗產品怎樣滿足使用者的需求，...
如何寫好乙份產品需求文件
二 產品概述 三 功能說明 四 其他產品需求 五 風險分析 六 相關文件 版本編號 修訂人修訂日期 修訂描述 1.0.0 2021.1.22 初步確定產品需求 確定產品需求的實現方案 此文件的目的主要是清晰 有條理的說明 平台應具備的相關功能以及開發需求。此文件主要描述 平台中前端頁面涉及到的功能點...
如何寫好軟體文件
今天看到一篇介紹寫作技術文件的文章，試著翻譯了一下，翻得不好，請大家幫忙改正。正文如下 我不知道是不是有人會將閱讀或書寫技術文件當 好。雖然很討厭這樣做，但是通常為了解決問題或介紹乙個技術產品，我們不得不去做這些事情。要想寫好文件很難。技術文件有幾種形式 基本概覽，高階概覽，一步一步的演示，自動生成...