產品經理如何進行項目管理(3):工件篇
“聞道有先后,術業有專攻”,一個優秀的項目經理在產品迭代的過程中,有著不可小覷的作用。然而在大部分互聯網公司,由于團隊規模的限制,產品經理往往會承擔一定的項目管理職能,那么產品經理應該如何做好項目管理呢。我曾在任職期間以產品經理身份兼任項目經理一職,就產品經理如何進行項目管理這一話題給大家帶來分享。
在《產品經理如何進行項目管理(1):基礎理論篇》中,提到項目管理有四大工件,這四大工件也是我在項目管理過程中使用并持續改進的。
需求清單
需求清單在其他的一些互聯網產品團隊中,也被稱為需求池,顧名思義需求清單是一個用來記錄各渠道來源的需求、所涉及的產品、需求的優先級、需求狀態以及發布時間的一個清單。
需求清單中有幾項是需要特別注意的:
- 描述:描述是用來記錄需求的詳細信息,描述中的語言一定不能產生歧義,否則會給開發團隊帶來困擾。
- 優先級:優先級決定了需求調研的先后順序、需求開發的先后順序,我們采用四象限的方式來定義需求的優先級。
- 狀態:狀態標記了需求目前所處的情況,需求清單應該是一個公開的清單,任何人都可以查看清單的信息,因此狀態一定要跟實際情況一致,及時反映需求的進展。
- 提出人:提出人信息是為了方便對需求進行追溯,由誰提出的需求,后續關于該需求的變更都要及時告知提出者。
任務清單
任務清單列表是一組當前迭代選出的任務代辦事項列表,該列表由項目組成員維護,并交由測試人員監控。
項目組成員根據迭代計劃對需求進行分解,將需求分解為一個個可以獨立部署的任務計劃,測試團隊根據項目組成員給出的任務清單跟蹤任務完成情況并督促開發人員提測,做到持續集成。項目組成員確保把最優資源投入到高優先級需求上。
這里有兩個難點:
- 需求分解:作為產品經理代理項目經理,很難做好需求分解和進度評估工作,需要產品經理有一定的技術功底,能夠大概知道背后的實現邏輯如何;另外你還必須充分信任開發團隊,信任他們所給出的時間節點。
- 持續集成:持續集成在一定程度上,增加了代碼合并的工作量,也容易引人其他開發成員帶來的bug,但只有做到持續集成,才能算是敏捷的開發
項目周報
項目周報是對一周項目迭代的情況匯報以及下周項目組的工作計劃,另外對于項目管理過程中出現的一些問題,例如流程上的漏洞、資源的欠缺都要及時向上反饋,以便獲得領導的支援,切忌報喜不報憂。
迭代總結
迭代總結是在整個項目管理過程中,比較重要的一個環節。很多產品經理甚至專業的項目經理都容易疏忽這一點。迭代總結的重要性在于,它能如實的反映項目迭代過程中存在的一些問題,并根據這些問題進行跟蹤改進。
記錄問題只是其中的一部分,重要的是作為項目經理的你有沒有事后去推動改良這些事情,不然迭代總結只是一個形式主義。
作者:周沛沛(微信號nyyzpp),點我吧產品經理。文能寫文檔,武能改BUG。
本文由 @周沛沛 原創發布于人人都是產品經理。未經許可,禁止轉載。
謝謝前輩,感覺一下清晰了很多,有了些調理;想請教下,怎么區分需求和BUG呢,前文說每天需要上傳代碼測試,測試人員每天是否也要提出的BUG呢,這樣是否也要我們記錄在需求清單里面呢,資源控制要怎么做呢?
怎么根據需求拆分任務呢??
你好,請問文中第一張圖,用的需求管理工具叫什么啊?
伙伴云
如何根據需求拆解任務?
迭代總結里面的內容推出產品經理貌似能力不行嘛,哈哈哈哈
即使再優秀的產品經理都有可能存在犯錯的情況,迭代總結中的內容,恰恰說明產品經理意識到自己的問題,而不是固守自封
怎樣才能讓項目周報看起來一目了然
形式不重要,重要的是講清楚事情。
1. 本周做了什么:
做了什么不重要,而是要匯報做了事情的結果
2. 下周要做什么:
同樣要匯報預期結果,比如跟誰討論什么什么事情,為什么要討論,討論之后要達到什么結果
3. 遇到了什么問題:
遇到了什么問題,怎么解決,需要誰的配合,是否需要上級的支援
可以考慮金字塔思維方式,先匯報結果(項目的進展,項目的情況,項目的結論),再匯報論點,再匯報論據。