鄙人拙見儡司，歡迎各位共同探討挪捕。

自己摸爬滾打一年多，同時也跟著產(chǎn)品leader學(xué)習(xí)，主要是做前臺產(chǎn)品甜无，一份相對完整的產(chǎn)品（交互）文檔可以包含以下部分。

1.文檔說明哟玷。主要包括對文檔的作用希停、目的說明；版本記錄淳衙。

2.產(chǎn)品說明蘑秽。主要包括產(chǎn)品定位；產(chǎn)品目標(biāo)箫攀；目標(biāo)用戶肠牲；商業(yè)模式；功能結(jié)構(gòu)靴跛。

3.業(yè)務(wù)說明缀雳。主要包括業(yè)務(wù)流程；業(yè)務(wù)資料梢睛。

4.產(chǎn)品原型肥印。此部分一般會與交互設(shè)計師共同維護。

5.關(guān)聯(lián)系統(tǒng)需求扬绪。主要是給后臺提的需求竖独。

這一年多來做的算是一款創(chuàng)業(yè)產(chǎn)品。最開始的時候挤牛，作為一個產(chǎn)品新人莹痢，此前沒有任何產(chǎn)品經(jīng)驗，在沒有交互的情況下墓赴，我最開始嘗試的就是產(chǎn)品原型圖竞膳，因為有設(shè)計的基礎(chǔ)，很快就上手了诫硕。但是久而久之坦辟，其實更像一個傳達需求的“交互設(shè)計師”。在leader的指點下章办，我也參考他的完整的一份PRD锉走，就是上述的幾個部分。這樣寫下來藕届，其實會促使自己去反思產(chǎn)品的定位挪蹭、核心功能、以及整個業(yè)務(wù)邏輯和以后的發(fā)展方向休偶。

團隊采用的是敏捷開發(fā)梁厉，因此在最初的時候我們不追求美觀和全面，只要能清楚目前這個階段需要什么踏兜，快速迭代和實現(xiàn)就OK了词顾。在整個團隊磨合以后八秃，作為產(chǎn)品的我就開始思考如何改善自己的產(chǎn)品文檔了。

1.相對完整的產(chǎn)品文檔肉盹。因為不斷有團隊成員加入昔驱，并且產(chǎn)品團隊和開發(fā)團隊分別在廣州和上海，設(shè)計垮媒、開發(fā)團隊也不希望僅僅成為一個執(zhí)行者舍悯，因此有一份相對完整的文檔航棱，比如上述的5個部分睡雇，就能減輕你們的溝通成本以及增強大家的參與感。

2.良好的排版和設(shè)計饮醇、細節(jié)到位它抱。團隊Boss是一個有強迫癥和完美主義者，因此我們作為產(chǎn)品朴艰，提交的產(chǎn)品文檔也要進行排版設(shè)計观蓄。比如字距、行距祠墅、字體的顏色侮穿、標(biāo)點符號全角半角等，尤其是原型圖毁嗦，不要想著隨意畫幾個方框糊弄他亲茅，一定要細致到每一個icon都要用到最符合現(xiàn)在的設(shè)計潮流，這樣會在提需求給boss審核的時候就被斃掉（因為我們公司的交互資源是公用的狗准，所以產(chǎn)品經(jīng)理在提需求之前需要自己畫原型給老板審核）克锣。

3.記錄關(guān)聯(lián)后臺系統(tǒng)的需求。在我司腔长，許多后臺都是共用的袭祟，最開始的時候我都是口頭提需求，但是發(fā)現(xiàn)這樣子對方產(chǎn)品經(jīng)理會理解不清楚或者自己日后查閱起來也不方便捞附，因此提需求的時候最好把你的需求也保存在這一份產(chǎn)品文檔里面巾乳，為日后省了不少事。第一點提到的相對完整產(chǎn)品文檔鸟召，除了給自己團隊成員看胆绊，也方便給別的產(chǎn)品經(jīng)理理解你們的產(chǎn)品和查閱。

4.版本管理药版。我們開發(fā)的周期一般為2周一個版本辑舷，迭代速度非常快槽片，因此在產(chǎn)品文檔方面何缓，我一般會自行維護一份完整的囊括整個項目各方面的內(nèi)容肢础，如上述的5個部分；而交付給交互和開發(fā)的文檔碌廓，一般都是當(dāng)前2周之內(nèi)的工作量的文檔传轰，這樣子他們不會搞不清楚這個階段需求的邊界和范圍。扯個題外話谷婆，我有個同事非常喜歡把一整份超級完整的產(chǎn)品文檔交給開發(fā)并且不幫他們做劃分慨蛙，因此開發(fā)經(jīng)常都會一頭霧水，不知道到底需要實現(xiàn)到什么程度纪挎。

當(dāng)然期贫，你可以有一份超前的產(chǎn)品文檔，囊括了接下來幾個版本會要覆蓋的范圍异袄，放在一個公共平臺方便查閱通砍。原因有二：一個是方便你的開發(fā)團隊了解你日后的發(fā)展方向和目前所做需求的意義是什么，也就是上述的參與感烤蜕；第二是與你合作的開發(fā)經(jīng)理會從技術(shù)實現(xiàn)和連續(xù)性等等的角度給你適當(dāng)?shù)慕ㄗh封孙，幫你調(diào)整你的步伐，讓整個團隊在一個比較合理的節(jié)奏下進行版本迭代讽营。

5.關(guān)于產(chǎn)品原型虎忌。

順便提到一句，一位前輩跟我說的：“產(chǎn)品經(jīng)理處理的都不是一般情況橱鹏，只有把“二般”情況處理好才能成功膜蠢。”這句話在我現(xiàn)在看來蚀瘸，應(yīng)該就是說我們應(yīng)該去思考一些邊界情況和特殊情況下應(yīng)該如何處理狡蝶，這個在寫需求的時候應(yīng)該特別提到，這也是我自己經(jīng)常會忽略的贮勃，以后應(yīng)該引起注意贪惹。

關(guān)于產(chǎn)品經(jīng)理與交互設(shè)計師的界限，其實會有重合的部分寂嘉。其實一般你的交互設(shè)計師會跟你說你的需求只需要用文字或者口頭描述清楚即可奏瞬，不需要具象化，因為他可能會有自己的想法泉孩，而且會不知道應(yīng)該在你的基礎(chǔ)上進行修改還是新建一份文檔好硼端，可能會浪費大家的時間。因此有2個建議：一個是如剛剛所提到寓搬，自己維護一份完整的文檔珍昨，按照你喜歡的風(fēng)格和習(xí)慣的排版；二是以一份文檔的形式記錄你的需求，主要需要涵蓋以下幾個內(nèi)容：序號镣典、需求模塊兔毙、需求類型、具體描述兄春、期望目標(biāo)澎剥、需求收益、需求提出人赶舆、備注哑姚、完成情況。

一份良好的需求文檔芜茵，能夠幫你管理好你的需求叙量。然后在這份需求表的基礎(chǔ)上，附帶上交互的文稿夕晓，就可以交付給開發(fā)了宛乃。交互文檔雖然不可能細致到方方面面，但是也應(yīng)該盡量完善蒸辆，也方便測試寫TC，還有產(chǎn)品團隊驗收產(chǎn)品析既。在開發(fā)過程中發(fā)現(xiàn)的問題躬贡，應(yīng)該及時補充進入產(chǎn)品文檔，對交互文檔進行了修改眼坏，記得要進行標(biāo)注拂玻，方便日后對照，以免需求混亂宰译。期望目標(biāo)主要是指在項目的直觀實現(xiàn)的目標(biāo)檐蚜，比如優(yōu)化產(chǎn)品UI、完善產(chǎn)品功能沿侈、提升PV闯第、UV等等；而需求收益主要是一些商業(yè)目標(biāo)缀拭、市場目標(biāo)等等一些最終目標(biāo)（取決于你的產(chǎn)品類型和目標(biāo)）咳短，比如通過增加倒計時按鈕提高訂單轉(zhuǎn)化率等等。當(dāng)然這也只是我的個人記錄需求的習(xí)慣蛛淋，只是作為參考咙好。

產(chǎn)品文檔最好有統(tǒng)一性。就是在文檔邏輯褐荷、語言風(fēng)格勾效、排版設(shè)計方面，最好能統(tǒng)一起來，方便各方理解层宫。這個主要是在產(chǎn)品和交互維護同一份文檔的時候绘迁，可能會產(chǎn)生一些歧義。比如這個某個icon在你的文檔里是表示發(fā)現(xiàn)卒密，而在她的文檔里是表示朋友圈缀台；再比如關(guān)閉當(dāng)前正在寫作的文檔，提示浮層顯示“是否保存文檔”哮奇，“保存”和“確定”其實是有不同的膛腐，“保存”是指保存文檔，而“確定”則是對上面提示語的確認鼎俘。細節(jié)雖然細致哲身，但是也值得注意，需要保持一致性贸伐，不能一個地方一個樣子勘天，這些都是交互設(shè)計師需要考慮的細節(jié)部分。因此我一般只會畫輔助理解的幾個簡單原型捉邢，剩余的完整的需要交付給設(shè)計脯丝、開發(fā)的原型、交互等工作留給交互設(shè)計師去完成伏伐。

總之文檔只是工具宠进，最重要的是因時制宜、因地制宜藐翎，在不斷磨合中探索出方便自己團隊交流的文檔材蹬。