曾經(jīng)有實習(xí)生問我：“需求提交完了，好像沒啥事情做了，我該做什么？”納尼？需求提完了就大功告成，萬事大吉了？那還是太天真了，這個世界可沒有辣么友好的哦。需求提交了，程序猿進(jìn)入開發(fā)流程，你要做的事情可多著呢！

首先，做好變更需求的準(zhǔn)備

什么？不是說需求不要輕易變更嗎？少年郎，你該聽過一句話“夢想是美好的，現(xiàn)實是骨感的”。雖然我們都希望需求確定以后盡量不去更改需求，但更改需求的情況還是比較常見。比如你確實沒有考慮到這一點，比如開發(fā)同學(xué)發(fā)現(xiàn)技術(shù)成本太高，再比如市場情況有了變化等等，這時候作為產(chǎn)品經(jīng)理要做的是快速整理新的需求，判斷新需求是否需要在當(dāng)前版本添加或更改，盡快和開發(fā)等相關(guān)部門制定出合適的變更方案，整理更改后的文檔。

不要害怕去更改需求，更改需求并不是什么丟臉的事情。記得看過一句話，從來沒有改過需求的產(chǎn)品經(jīng)理不是好的產(chǎn)品經(jīng)理。為什么？我的理解是說明你的思維是固定僵化的，也說明你缺乏自我驅(qū)動性，完成任務(wù)就不管了，沒有繼續(xù)觀察產(chǎn)品，用戶和市場。

其次，準(zhǔn)備好測試所需的文檔和計劃

和測試人員的溝通同樣重要，需要讓測試人員清楚的明確需求的目的，需求的目標(biāo)人員，功能點的設(shè)計目的，一起確定需要測試的測試點。只有這樣，測試人員才能更好地梳理測試用例并執(zhí)行。

如果你的團(tuán)隊里沒有測試人員，又正好不愿意雇傭外包測試人員。那么只好你自己來寫測試用例，安排測試計劃并且執(zhí)行了。那么測試用例如何來寫呢？一般測試用例包含幾個方面“測試的前提條件，測試步驟，期望結(jié)果，實際結(jié)果”。所謂測試前提條件是指該功能要運行需具備的前置操作或運行。下圖是一個測試用例的模板，可以供大家參考。

因為沒有專業(yè)測試人員，那么測試者只能是團(tuán)隊成員和部分種子用戶了。在測試用例之外，你還需要制定一個測試計劃，比如需要多少臺測試機，安卓和IOS各占多少，團(tuán)隊成員和種子用戶各占多少，如何收集整理他們反饋的問題等等。這一個計劃根據(jù)各自團(tuán)隊實際情況而定，這里就不展開說明了。

第三，對接運營、客服、市場推廣等部門

一個產(chǎn)品的上線和發(fā)布，后期的運營，不是只靠產(chǎn)品和開發(fā)就可以的，還需要依靠運營，客服、市場等部門的共同努力。因此需求提交之后，你還需要和上述部門闡明需求。主要是下面幾點

• 告知重要的功能點，讓運營等部門理解需求的出發(fā)點，和他們共同制定產(chǎn)品的推廣計劃和策略；
• 告知涉及用戶的重要功能點，整理一份初步的Q&A，便于客服人員提前準(zhǔn)備用戶咨詢話術(shù)；
• 了解市場推廣部門的特殊需求，比如某個應(yīng)用市場首發(fā)，比如第三方聯(lián)合做的推廣活動，及時響應(yīng)這些需求。

理論上這些前期都要和相關(guān)部門對接，但是架不住別的部門事情多啊，計劃趕不上變化之類的，這個時間點再認(rèn)真確認(rèn)一次還是很有必要的。

第四，整理BUG等級表，清晰描述BUG

測試之后必然會有BUG。BUG也不會少，那是不是所有BUG都得馬上改呢？如果你的團(tuán)隊有專職測試人員，就不用你操心了。但是如果你沒有專職測試，那么這事還得自己來。BUG根據(jù)嚴(yán)重情況列優(yōu)先級，如果時間緊張，一些不影響使用的小BUG可以放到后面改。崩潰的BUG當(dāng)然馬上改了。

優(yōu)先級列完了，你還要將BUG描述清楚，BUG出現(xiàn)的頁面，BUG出現(xiàn)的場景，重現(xiàn)的截圖或視頻等等。

本期總結(jié)：

做好需求變更的準(zhǔn)備，整理好文檔；

需要和測試、運營、客服、市場推廣等部門提前溝通，準(zhǔn)備好必要的文檔；

梳理好BUG優(yōu)先級，清晰描述或重現(xiàn)BUG

作者：肥寒，微信公眾號“產(chǎn)品狗日記”。8年產(chǎn)品經(jīng)理，做過數(shù)字閱讀、社區(qū)、電商。

本文由 @肥寒 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。