產(chǎn)品在研發(fā)階段、測試階段、驗收階段時，產(chǎn)品經(jīng)理的各種心理活動丨IDCF

點這里??星標關(guān)注，獲取最新資訊！

需求評審?fù)瓿闪耍瑴y試用例、UI方案、技術(shù)方案也都評審?fù)瓿闪耍a(chǎn)品經(jīng)理終于可以松一口氣了。

研發(fā)偶爾會找你確認需求細節(jié)

有幾種情況：

1、需求文檔寫的很清楚，研發(fā)看文檔不細心，這種情況最好的方式就是把需求文檔對應(yīng)的地方截圖圈給研發(fā)，一句話都不用說，如果你忍不住diss幾句也可以的。

2、需求邏輯很復(fù)雜，研發(fā)需要多次溝通再確認，單純看文檔可能不能完全理解，雖然評審過但是很容易忘記和遺漏。

3、也有可能是研發(fā)過程中發(fā)現(xiàn)一些細節(jié)需求沒有考慮到，經(jīng)過溝通后還需要產(chǎn)品經(jīng)理補充需求。

需求開發(fā)完成后，研發(fā)需要根據(jù)測試用例自測，自測完成后提測給到測試同學(xué)，測試階段就開始了。

問題不斷，麻煩不斷

測試階段就是測試給研發(fā)找問題的階段，測試以找bug 為目標，研發(fā)也有bug率考核，期間有很多爭吵。

產(chǎn)品經(jīng)理經(jīng)常被測試研發(fā)拉上來評估某個問題是不是bug，自此產(chǎn)品經(jīng)理變成了判官。

簡單的直接就判了，復(fù)雜點的問題可能是需求沒有考慮到的，要么就需求變更，要么就把問題當作下一次迭代的需求，也就是問題轉(zhuǎn)優(yōu)化。

產(chǎn)品經(jīng)理身上掛的bug 竟然比研發(fā)還多??????

每個迭代都會有很多問題，這些問題都是變成單據(jù)轉(zhuǎn)來轉(zhuǎn)去，很多問題確實不太好處理要轉(zhuǎn)優(yōu)化的或者需要產(chǎn)品來判斷補充的，都掛到產(chǎn)品經(jīng)理名下了，等著產(chǎn)品處理，要是處理不及時，產(chǎn)品經(jīng)理名下的bug可能比研發(fā)還多。

所有需求最終都要轉(zhuǎn)給產(chǎn)品經(jīng)理做驗收

需求單測試完成后狀態(tài)就變成待驗收狀態(tài)并轉(zhuǎn)到產(chǎn)品經(jīng)理這了。

驗收是一件很重要的事情，要檢查是不是和自己提出的需求一致，體驗好不好，因為最終面向客戶的是產(chǎn)品經(jīng)理，如果有問題還要被客戶投訴或者抱怨，所以驗收要細致，有問題有缺陷要及時提出來讓研發(fā)修改好。

最怕在驗收的時候，在實際操作功能體驗時發(fā)現(xiàn)需求還要優(yōu)化，時間又來不及了，內(nèi)心還是很著急的，要想辦法溝通研發(fā)看能否幫忙快速處理，如果研發(fā)短時間搞不好還要安排最快看什么時候可以上線。

最后還有一個發(fā)布評審會

產(chǎn)品需求全部驗收通過，測試的必解bug全部處理完成后，還要開一個發(fā)布評審會，這個會也可能是提前就計劃好了，在某一天開。

項目經(jīng)理組織團隊研發(fā)、測試、產(chǎn)品在一起過一下即將發(fā)布的需求明細情況：主要是Bug統(tǒng)計情況，有多少bug，解決了多少，還有多少沒解決，沒有解決的問題要一個一個過，確定這些問題是否影響上線，如果不影響就帶bug發(fā)布，影響就要推遲或者某個需求不發(fā)。

決定權(quán)一般由大家一起達成共識，測試要負責(zé)質(zhì)量是最重視的，產(chǎn)品經(jīng)理要負責(zé)用戶體驗，面對用戶壓力也要衡量清楚，而技術(shù)對市場和用戶敏感度低，最容易放行。

研發(fā)、測試、驗收三個階段，產(chǎn)品經(jīng)理更多都是在溝通和推進自己的需求快速上線，過程中難免要處理一些棘手的問題，最怕的是最后才發(fā)現(xiàn)需求有問題，上線在即，焦急萬分。

做項目會有風(fēng)險管理，問題發(fā)現(xiàn)越晚風(fēng)險越大，甚至導(dǎo)致項目延期，所以我們必須在需求階段就要把所有情境都考慮到，特別是業(yè)務(wù)主線需求，一點問題都不能有，產(chǎn)品經(jīng)理要去多理解用戶和感受所有用戶群體的痛點。

團隊在做產(chǎn)品項目時，環(huán)節(jié)越多說明管理的越細，對穩(wěn)定性具有較高的保障，而環(huán)節(jié)少效率會高一點，但是對團隊質(zhì)量要求高。

1. 研發(fā)階段：
• 需求理解：產(chǎn)品經(jīng)理能夠更準確地理解技術(shù)實現(xiàn)的可行性，提出更合理的需求。
• 風(fēng)險評估：能夠評估技術(shù)風(fēng)險，提前規(guī)劃可能的解決方案，減少項目延誤。
2. 測試階段：
• 測試策略：產(chǎn)品經(jīng)理可以更好地與測試團隊溝通，制定有效的測試計劃和策略。
• 問題定位：在測試過程中發(fā)現(xiàn)的問題，產(chǎn)品經(jīng)理能夠更快速地理解并參與定位問題根源。
3. 驗收階段：
• 驗收標準：制定更加科學(xué)的驗收標準，確保產(chǎn)品滿足既定的質(zhì)量和功能要求。
• 溝通協(xié)調(diào)：在驗收過程中，能夠更好地協(xié)調(diào)研發(fā)、測試、運維等團隊，確保產(chǎn)品順利上線。
4. 跨部門協(xié)作：
• 高效溝通：具備技術(shù)背景的產(chǎn)品經(jīng)理能夠使用技術(shù)語言與研發(fā)團隊有效溝通，減少誤解。
• 項目管理：更好地管理項目進度，平衡業(yè)務(wù)需求與技術(shù)實現(xiàn)的邊界。
5. 持續(xù)優(yōu)化：
• 產(chǎn)品迭代：理解DevOps文化中的持續(xù)改進理念，推動產(chǎn)品的快速迭代和優(yōu)化。
• 流程改進：能夠識別研發(fā)流程中的瓶頸，推動流程優(yōu)化，提高研發(fā)效率。

課程顧問：黛西Daisy

15910317788

報名費用

官方指導(dǎo)價7500元 / 人，

?? 即刻報名，立享參團價格！！

• 第十二期：7月20日（僅余1席）
• 第十三期：9月20日
• 第十四期：11月20日