需求提交了,產品好像沒啥事兒了?
曾經有實習生問我:“需求提交完了,好像沒啥事情做了,我該做什么?”納尼?需求提完了就大功告成,萬事大吉了?那還是太天真了,這個世界可沒有辣么友好的哦。需求提交了,程序猿進入開發流程,你要做的事情可多著呢!
首先,做好變更需求的準備
什么?不是說需求不要輕易變更嗎?少年郎,你該聽過一句話“夢想是美好的,現實是骨感的”。雖然我們都希望需求確定以后盡量不去更改需求,但更改需求的情況還是比較常見。比如你確實沒有考慮到這一點,比如開發同學發現技術成本太高,再比如市場情況有了變化等等,這時候作為產品經理要做的是快速整理新的需求,判斷新需求是否需要在當前版本添加或更改,盡快和開發等相關部門制定出合適的變更方案,整理更改后的文檔。
不要害怕去更改需求,更改需求并不是什么丟臉的事情。記得看過一句話,從來沒有改過需求的產品經理不是好的產品經理。為什么?我的理解是說明你的思維是固定僵化的,也說明你缺乏自我驅動性,完成任務就不管了,沒有繼續觀察產品,用戶和市場。
其次,準備好測試所需的文檔和計劃
和測試人員的溝通同樣重要,需要讓測試人員清楚的明確需求的目的,需求的目標人員,功能點的設計目的,一起確定需要測試的測試點。只有這樣,測試人員才能更好地梳理測試用例并執行。
如果你的團隊里沒有測試人員,又正好不愿意雇傭外包測試人員。那么只好你自己來寫測試用例,安排測試計劃并且執行了。那么測試用例如何來寫呢?一般測試用例包含幾個方面“測試的前提條件,測試步驟,期望結果,實際結果”。所謂測試前提條件是指該功能要運行需具備的前置操作或運行。下圖是一個測試用例的模板,可以供大家參考。
因為沒有專業測試人員,那么測試者只能是團隊成員和部分種子用戶了。在測試用例之外,你還需要制定一個測試計劃,比如需要多少臺測試機,安卓和IOS各占多少,團隊成員和種子用戶各占多少,如何收集整理他們反饋的問題等等。這一個計劃根據各自團隊實際情況而定,這里就不展開說明了。
第三,對接運營、客服、市場推廣等部門
一個產品的上線和發布,后期的運營,不是只靠產品和開發就可以的,還需要依靠運營,客服、市場等部門的共同努力。因此需求提交之后,你還需要和上述部門闡明需求。主要是下面幾點
- 告知重要的功能點,讓運營等部門理解需求的出發點,和他們共同制定產品的推廣計劃和策略;
- 告知涉及用戶的重要功能點,整理一份初步的Q&A,便于客服人員提前準備用戶咨詢話術;
- 了解市場推廣部門的特殊需求,比如某個應用市場首發,比如第三方聯合做的推廣活動,及時響應這些需求。
理論上這些前期都要和相關部門對接,但是架不住別的部門事情多啊,計劃趕不上變化之類的,這個時間點再認真確認一次還是很有必要的。
第四,整理BUG等級表,清晰描述BUG
測試之后必然會有BUG。BUG也不會少,那是不是所有BUG都得馬上改呢?如果你的團隊有專職測試人員,就不用你操心了。但是如果你沒有專職測試,那么這事還得自己來。BUG根據嚴重情況列優先級,如果時間緊張,一些不影響使用的小BUG可以放到后面改。崩潰的BUG當然馬上改了。
優先級列完了,你還要將BUG描述清楚,BUG出現的頁面,BUG出現的場景,重現的截圖或視頻等等。
本期總結:
做好需求變更的準備,整理好文檔;
需要和測試、運營、客服、市場推廣等部門提前溝通,準備好必要的文檔;
梳理好BUG優先級,清晰描述或重現BUG
作者:肥寒,微信公眾號“產品狗日記”。8年產品經理,做過數字閱讀、社區、電商。
本文由 @肥寒 原創發布于人人都是產品經理。未經許可,禁止轉載。
不是在開發前期的需求評審會上就會評估開發成本投入產出比,除非后期boss或者產品這邊著急上線壓縮開發時間,才會重新評估再把這一版不重要的砍掉嗎
個人認為第一點(開發人員認為成本太高導致的需求變更)在需求分析階段讓開發和架構參與進來,了解主要功能并評審,對于成本高的,復用性低的,提出技術解決方案,再做討論,這樣雖然不能100%保證在開發階段沒有該類需求變更,但多少是可以避免一些的。
贊
基本都能在需求評審階段填坑
贊
收藏
產品經理就是堵槍眼的,交給項目之后,你得站在產品交付給用戶的角度去審視整個工作環節,發現風險及時與項目溝通,發現問題第一時間找到最專業的人解決,如果沒有最專業的人,就把自己變成最專業的人。
跟進開發進度、隨時根據技術要求優化文檔原型、發現偏差并糾正,后期參與產品驗收,總結經驗,事情多了去了