HI大家，其實我當PD沒多久，所以我就用了這個標題：“PD成長記”，我所要講的是一個有關(guān)效率和文檔的故事。
我2014年11月8日真正成為PD接到第一個項目是這個日子。接到的第一個項目就是“Y項目”，一個通過日常任務(wù)與抽獎體系增加用戶黏性的項目。當時從需求kick-off到開發(fā)kick-off用了將近一個月，開發(fā)也用了將近一個月。
雖然這個項目的結(jié)果是好的，從數(shù)據(jù)上看它讓用戶黏性提高了10倍左右。項目在時間管理方面也并沒有到達失控的境地。但冥冥中，我總感覺在需求確認和開發(fā)上耗去的時間仍然還有優(yōu)化余地，就去采訪了兩位開發(fā)人員，他們是這么說的。
某后端架構(gòu)師：“還是照著測試的case寫比較好。”
某客戶端工程師：“你們產(chǎn)品寫的文檔都是亂的，現(xiàn)在都是靠case文檔撐起來的。”
在那以后我就一直在反思，如何寫好prd來提升效率。因為我認為“prd是pd自己的產(chǎn)品，讀者是用戶。”讀者這里指的就是你要完成這個產(chǎn)品所要接觸到的所有人。一個pd連自己的產(chǎn)品都做不好，也很難帶著開發(fā)做出征服用戶的產(chǎn)品。所以在之后的時間里，我不停的與開發(fā)溝通，爭取在需求正確的基礎(chǔ)上，寫出可讀性較高的prd。
通過一些溝通與調(diào)整，我的prd格式為以下：
文檔屬性、解決問題、術(shù)語概念、應(yīng)用范圍、產(chǎn)品原型、應(yīng)用場景、兼容問題、競品分析。
文檔屬性我一般會講述整個文檔的概略：pd是誰，交互、設(shè)計是誰，后端、前端、客戶端開發(fā)是誰，測試是誰。
解決問題就是當CEO問你在做什么時，用“解決問題”中的三句話告訴他你在做什么。也可以用另一個角度告誡自己，在撰寫文檔的時候，不要忘記初心，別要忘記為什么而出發(fā)。
術(shù)語概念非常重要，是用來定義一些在你接下來的文檔里，需要引用的一些專有名詞，提高讀者的閱讀效率。
應(yīng)用范圍是描寫一下該產(chǎn)品什么是要做的，為什么要這么做，以及什么是不要做的，千萬別去碰。
產(chǎn)品原型我會分兩部分來闡述，第一部分是產(chǎn)品DEMO，就是用戶能直接看到的界面，也方便開發(fā)人員快速理解。第二部分則是產(chǎn)品架構(gòu)和流程，這就有些許麻煩。架構(gòu)方面我們需要一點架構(gòu)師的思維：抽象畫、通用化、模塊化地描述產(chǎn)品。而流程方面，我們必須梳理業(yè)務(wù)邏輯來串聯(lián)你的故事：要讓開發(fā)和測試明白你要做什么、復(fù)雜流程簡單化，此處我推薦的軟件是MindNode，也是思維導(dǎo)圖軟件家族里，美觀方面我認為唯一能過得去的軟件。
應(yīng)用場景描述的，則是一些場景下的user case。需要注意的是，一般好產(chǎn)品的共性，總是擁有簡單且學(xué)習(xí)成本較低的用戶體驗，而需要的往往也是復(fù)雜而龐大的后臺支撐。所以這里的“user”不應(yīng)該只僅限于用戶，對公司里的運營、BI、開發(fā)人員描寫user case也是非常重要的一部分。
兼容問題的說明，在移動客戶端作用尤為明顯，但并非所有產(chǎn)品都需要做，但這部分做的細致，將給予開發(fā)與測試人員更好的推進體驗。
最后則是競品分析，其實這往往是pd在做一個產(chǎn)品規(guī)劃的時候第一件要做的事情，只是當文檔已經(jīng)完成，這一部分就顯得不那么重要了，放在這個位置，也只是方便大家隨時查看而已。
有些產(chǎn)品邏輯可能確實還是比較簡單的，視具體情況可以進行簡化。但是我們必須保證，在完成這個文檔的撰寫以后，必須對讀者是友好的，且嚴謹?shù)摹?/p>
至于如何高效地進行文檔管理和維護呢？以前我也是直接把文檔傳到服務(wù)器上就了事了，但對于開發(fā)和測試來說，這是一件麻煩的事。對于pd來說，我們這里有四個工具可供文檔維護。
工作流我這邊就暫且不說了，對于項目推進來說是神器，但是對于prd文檔維護來說，可能效果就不那么明顯了。
第二個是我們的郵箱，對大家沒有看錯，其實郵箱如果大家善加利用，也是一個小工作流。只是現(xiàn)在的狀況非常的凄慘，我剛才看了一下，一天的時間里我收到的郵件有27封，其中真正有用的只有兩封，其余25封是什么呢？都是一些垃圾郵件，公司里總有一撥人，為了證明他們是在工作的，隨便寫一封一句話郵件也要抄送好幾十無關(guān)人員，但是真正的實事他們往往干得最少，因為心思都花在這上面了。所以我在這呼吁大家，隨便寫一封郵件就抄送好幾十人這種行為是不好的，凈化我們郵箱，讓他回歸他應(yīng)在的位置。
第三個是我們的Axure RP。因為Axure這款軟件的產(chǎn)品定位緣故，我非常不建議將整個prd用這個軟件寫，然后直接扔到服務(wù)器里了事。我的做法是：只做交互DEMO的時候使用，讓設(shè)計師同學(xué)能夠更加快速的明白你的意思。在設(shè)計師同學(xué)將設(shè)計稿做出來以后，代替DEMO放在RP里，讓前端同學(xué)更易理解。而真正的邏輯問題，我的建議是交給word，并把word放在XWIKI里。
第四個就是XWIKI了，也是目前我認為最適合文檔維護的地方，在XWIKI里，我會分為4個部分存放，第一就是正文，正文是讀者進來第一眼就要看到的地方，我會在這里寫最重要的文檔屬性和解決問題。而附件我首先會上傳pdf格式的prd，在保證嚴謹性的同時，也兼顧了美觀，只是自己會有點麻煩，每次修改后都得轉(zhuǎn)一下格式。第二我會放rp格式的交互稿，但是到后面我也不太放了，直接在pdf里寫好鏈接，讓讀者點擊跳轉(zhuǎn)至服務(wù)器上看，這樣在讀者體驗上也許會更好。第四我放的則是將設(shè)計師給出的設(shè)計稿切玩圖打包好，放在附件中，隨時供前端和客戶端同學(xué)查看。
這一切的優(yōu)化，都是為了我們的效率，為了我們能夠又好又快地使產(chǎn)品盡快產(chǎn)出結(jié)果。
所以做完這些優(yōu)化后，我的結(jié)果是：
2015年3月20日到2015年4月3日，5個工作日就完成了復(fù)雜程度和所調(diào)用的開發(fā)資源均是“Y項目”兩倍的“X項目”的全部需求確認并完成評審，并在開發(fā)那邊反響也非常不錯，排期完成后立即開始了開發(fā)。文檔易讀性也被開發(fā)主管稱贊。
也許我的方法并非最優(yōu)，只是我個人的一點小經(jīng)驗，供大家參考，在接下來的日子，我將繼續(xù)在提高效率方面進行思考。
