項目復盤思路:產品上線后要如何做復盤?

進行了2個多月的APP大改版即將結束,為此產品技術團隊真的是盡心盡力,猛追猛趕,非常辛苦。然而越是大項目,越需要在結束時好好總結,這篇文章就來聊聊項目復盤應該怎么做。

在復盤前,產品經理或項目經理,需要擬好一個提綱,按目標達成度、計劃執行情況、資源協調情況、變更管理,從設計到編碼、從測試到發布、團隊協作幾個方面,分別設定問題,并提前發給團隊成員,收集大家的反饋。復盤時,召開全體產品研發設計測試會議,針對每個問題,思考解決方案,形成結論。復盤后,將會議結論匯總成文,發給全體參會人員,讓大家進一步了解如何規避問題,為接下來的新項目做準備。

下面重點講述提綱中需要確認的問題,包括以下幾個方面。

一. 目標完成度

  • 我們的產品要解決什么問題?是否定義得很清楚?是否對典型用戶和典型場景有清晰的描述?
  • 我們達到目標了么(原計劃的功能做到了幾個,按照原計劃交付時間交付了么?)?
  • 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么? 我們離目標更近了么?(需要上線后觀察再回答)

二. 計劃執行情況

  • 開發前,是否有充足的時間來做計劃?
  • 團隊在計劃階段是如何解決同事們對于計劃的不同意見的?
  • 你原計劃的工作是否最后都做完了? 如果有沒做完的,為什么?
  • 有沒有發現你做了一些事后看來沒必要或沒多大價值的事?
  • 是否每一項產品需求都有清楚定義和衡量的交付成果?
  • 是否項目的整個過程都按計劃進行?項目出了什么意外?有什么風險是當時沒有估計到的,為什么沒有估計到?
  • 在計劃中有沒有留下緩沖區,緩沖區有作用么?
  • 將來的計劃會做什么修改?

三. 資源協調情況

  • 我們有足夠的資源來完成這個項目么?
  • 項目所需時間和其他資源是如何估計的?精度如何?
  • 測試的時間、人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (產品設計/文案/運營策略)是否低估了難度?
  • 你有沒有感到你做的事情可以讓別人來做(更有效率)?

四. 變更管理

  • 是否存在需求變更?變更了幾次?每次變更的原因是什么?
  • 需求變更時,是否每個相關的員工都及時知道了變更的消息?
  • 我們采用了什么辦法決定每次變更,是「推遲」還是「必須實現」?
  • 變更的出口條件(也就是什么叫“改好了”)有清晰的定義么?
  • 對于可能的變更是否能提前制定應急計劃?
  • 員工是否能夠有效地處理意料之外的工作變更?

五. 從設計到編碼

  • 產品設計工作在什么時候,由誰來完成的?是合適的時間、合適的人么?
  • 產品設計工作有沒有碰到模棱兩可的情況,團隊是如何解決的?
  • 團隊是否運用單元測試(Unit Test),測試驅動開發(TDD)、UML、LINT,或其他工具來幫助編碼?這些工具有效么?
  • 什么功能產生的Bug最多,為什么?
  • 在發布之后發現了什么重要的bug? 為什么我們在設計/開發的時候沒有想到這些情況?(需要上線后觀察再回答)
  • 代碼走查(Code Review)是如何進行的?是否嚴格執行了代碼規范?

六. 從測試到發布

  • 團隊是否有一個測試計劃?這樣的計劃是否有效?
  • 是否進行了正式的驗收測試?
  • 團隊是否有測試工具來幫助測試?效果如何?
  • 團隊是如何測試并跟蹤產品開發效果的?從軟件實際運行的結果來看,這些測試工作有用么?應該有哪些改進?
  • 在發布的過程中發現了哪些意外問題?如何解決的?后續如何避免?

七. 團隊協作

  • 團隊的每個角色是如何確定的,是不是人盡其才?
  • 項目執行過程中是否有團隊成員變更?變更是否帶來的問題?如何解決的?
  • 團隊成員之間有互相幫助么?
  • 當出現需求描述、項目管理、合作方面的問題時,團隊成員如何解決問題?

八. 總結

  • 關于以上問題,有什么經驗教訓?如果歷史重來一遍,我們會做什么改進?
  • 你覺得團隊目前處于「萌芽/磨合/規范/創造」階段的哪一個階段?為什么?
  • 你覺得團隊在這個里程碑相比前一個里程碑有什么改進?
  • 你覺得目前最需要改進的一個方面是什么?

每次的項目復盤,都建議針對以上問題,全體成員在會上都發表意見,提出自己的看法,并群策群力尋找最優的解決辦法。具體到會議的組織,有如下建議:

  • 保持會議輕松愉快的氛圍,可以考慮換一個開會的環境,有飲料、零食、音樂的幫助更好。
  • 大領導最好不要出現,讓大家暢所欲言。(即使出現,也要夾著尾巴,不要為自己以前的行為辯護,作好聽眾)
  • 堅持對事不對人的原創,強調:如果再有一次機會,會如何改進?而不是挖歷史舊帳。
  • 照顧到上述提綱中提及的各個方面,可以深入團隊最感興趣的部分。
  • 讓所有人都有充分發言的機會。
  • 務必有人記錄發言要點,最后列出所有改進意見。
  • 最后大家可以投票,如果我只有三票,投給哪些改進意見。
  • 各小組負責人保證要采取行動,優先執行票數最高的一些改進意見,持續優化所有需要改進的點。

歡迎關注作者的微信公眾號:「互聯網悅讀筆記」

項目復盤思路:產品上線后要如何做復盤?

「優秀團隊項目復盤經驗總結」

================明星欄目推薦================

優優教程網 UiiiUiii.com 是優設旗下優質中文教程網站,分享了大量PS、AE、AI、C4D等中文教程,為零基礎設計愛好者也準備了貼心的知識樹專欄。開啟免費自學新篇章,按照我們的專欄一步步學習,一定可以迅速上手并制作出酷炫的視覺效果。

設計導航:國內人氣最高的設計網址導航,設計師必備: http://hao.uisdc.com

收藏 79
點贊 1

復制本文鏈接 文章為作者獨立觀點不代表優設網立場,未經允許不得轉載。