中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

進行了2個多月的APP大改版即將結束，為此產品技術團隊真的是盡心盡力，猛追猛趕，非常辛苦。然而越是大項目，越需要在結束時好好總結，這篇文章就來聊聊項目復盤應該怎么做。（注：本文內容部分來自鄒欣《構建之法》一書，有興趣的同學建議仔細閱讀）。

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

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

目標完成度

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

計劃執行情況

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

資源協調情況

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

變更管理

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

從設計到編碼

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

從測試到發布

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

團隊協作

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

總結

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

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

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

最后還可以在會議結束后大家一起聚個餐，休整一下，以備再戰！

#專欄作家#

申悅，人人都是產品經理專欄作家，36氪產品總監，微信公眾號：互聯網悅讀筆記（ID：pmbox）

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自攝圖網，基于CC0協議