產品上線后如何進行復盤?
本文從目標完成度、計劃執行情況、資源協調、變更管理、設計到編碼、測試到發布以及團隊協作等多個維度,詳細梳理了產品上線后復盤的重點問題。通過這些問題,項目組成員可以深入思考并交流,將復盤轉化為持續改進的動力,為后續的產品優化和團隊協作提供有力支持。
我們在進行系統建設或者產品研發的過程中,經歷了測試特別是UAT測試后,需要階段性的對需求開發全過程進行復盤,特別是大型項目而言,因為后續還有歷史數據處理,正式上線全員培訓,二次優化等工作,復盤總結有利于發現當前階段出現的問題或者多次返工、阻斷性問題等等。避免下一個階段出現類似的錯誤,能進一步提升效率。
在復盤前,PM要充分動員項目組的所有成員,包括參與的業務部門、項目組、產品組、開發組、測試組等等。一定是圍繞目標達成度、計劃執行情況、資源協調情況、變更管理、從設計到編碼、從測試到發布以及團隊協作等方面設置問題,并提前發送給團隊成員,以收集大家的反饋。
這里主要總結一些我們需要重點關注,復盤的問題。圍繞這些問題,我們需要每一個項目組成員去進行復盤思考,把做得好的,做得不好的,都能提出來進行溝通交流。具體包括且不限于以下問題:
【目標完成度】:
1. 我們的產品旨在解決哪些問題?這些問題的定義是否清晰明確?對于典型用戶和典型場景的描述是否足夠清晰?
2. 我們是否達成了既定目標?原計劃的功能實現了多少?是否按照原計劃的交付時間準時交付?
3. 用戶量以及用戶對關鍵功能的接受程度與我們事先的預期是否相符?我們距離目標更近了還是更遠了?(此問題需上線后觀察再作答)
【計劃執行情況】:
1. 在開發前,是否預留了充足的時間來制定計劃?
2. 在計劃階段,團隊是怎樣解決成員間對于計劃的不同意見的?
3. 你原計劃的工作是否全部完成?若未完成,原因是什么?
4. 有沒有發現自己做了一些事后看來毫無必要或價值不大的工作?
5. 每一項產品需求是否都有明確的定義和可衡量的交付成果?
6. 項目的整個過程是否都嚴格按照計劃進行?期間出現了哪些意外情況?有哪些風險在當時未被預估到?為何會出現這種情況?
7. 在計劃中是否設置了緩沖區?緩沖區起到了實際作用嗎?
8. 未來的計劃需要做出哪些調整和修改?
【資源協調情況】:
1. 我們是否擁有足夠的資源來確保項目的順利完成?
2. 項目所需的時間以及其他資源是如何進行預估的?預估的精度如何?
3. 測試所需的時間、人力以及軟件/硬件資源是否充足?對于那些非編程類的資源(如產品、設計、文案、運營策略等),是否低估了其難度?
4. 你是否覺得自己所做的某些工作可以由他人來完成,且效率會更高?
【變更管理】:
1. 需求是否發生了變更?變更的次數是多少?每次變更的具體原因是什么?
2. 當需求變更時,是否所有相關員工都能及時獲取變更的消息?
3. 針對每次變更,我們采取了何種決策方式,是選擇“推遲”還是“必須實現”?
4. 變更的出口條件(即怎樣才算“改好了”)是否有清晰明確的定義?
5. 對于可能出現的變更,是否能夠提前制定相應的應急計劃?
6. 員工能否有效地應對意料之外的工作變更?
【從設計到編碼】:
1. 產品設計工作是在何時、由何人完成的?時間和人員的安排是否恰當合理?
2. 產品設計過程中是否遇到過模糊不清的情況?團隊是如何解決這些問題的?
3. 團隊在編碼過程中是否運用了單元測試、測試驅動開發、UML、LINT等工具?這些工具的實際效果如何?
4. 哪些功能在測試過程中出現的bug最多?導致這種情況的原因是什么?
5. 在產品發布后,發現了哪些重要的bug?為何在設計和開發階段沒有預見到這些情況?(此問題需上線后觀察再作答)
6. 代碼走查是如何開展的?是否嚴格執行了代碼規范?
【從測試到發布】:
1. 團隊是否制定了測試計劃?該計劃的實際效果如何?
2. 是否進行了正式的驗收測試?
3. 團隊是否使用了測試工具來輔助測試?其效果怎樣?
4. 團隊是通過何種方式測試并跟蹤產品開發效果的?從軟件的實際運行結果來看,這些測試工作是否有效?存在哪些需要改進的地方?
5. 在發布過程中出現了哪些意外情況?是如何解決的?今后應如何避免類似情況的再次發生?
【團隊協作】:
1. 團隊中每個角色是如何確定的?是否做到了人盡其才?
2. 在項目執行過程中,團隊成員是否發生了變更?變更是否引發了問題?如果有,是如何解決的?
3. 團隊成員之間是否相互協助?
4. 當出現需求描述、項目管理以及合作方面的問題時,團隊成員是如何解決的?
當然上述的問題,不一定都需要每個人回答。我們可以根據項目的自身特點,或者產品系統的研發流程等等,去進行調整。
例如,我們在進行產品研發的過程中,會單獨對產品組的同事進行一個小范圍的復盤。我們會列出相應的問題,由各個產品經理進行復盤,并將復盤的內容與項目組、研發、測試不同角色進行分享,這樣才能有效的拉通各個角色分工,讓不同角色的同事明白自己的工作存在哪些缺漏或者值得提升的地方。
本文由人人都是產品經理作者【老司機聊數據】,微信公眾號:【老司機聊數據】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
- 目前還沒評論,等你發揮!