敏捷開發，在互聯網公司項目中的各個環節

全文共 4038 字，閱讀需要 8 分鐘

———— / BEGIN / ————

做為無所不能的產品經理，雖不是上知天文下知地理，但是也要對產品相關的知識領域有所涉獵。

項目管理就是與產品密切相關的一個知識領域，同時也是產品經理日常工作中經常要負責的一部分內容。

別問我為什麽不是項目經理負責，因為沒有……

本文結合實際工作實踐以及項目管理方面書籍所學，深入淺出介紹在敏捷開發的互聯網公司中一個項目從無到有所經歷的各個環節，當然項目管理這門學問還有很多需要深入探索的領域，以下僅僅對沒有過多項目管理經驗的產品新人做一個入門引導。

一、做產品還是做項目？

產品就是項目，項目就是產品。

在很多敏捷開發的互聯網公司中，產品是項目製，功能也是項目製，在策劃一個新功能的時候，對於產品經理來說就是在策劃一個項目。

在PMBOK第六版的官方指南中，項目指為創造獨特的產品、服務或成果而進行的臨時性工作，項目有固定的起止時間周期。

在大一點的互聯網公司，多個產品經理為同一個產品服務，每一個產品都會絞盡腦汁想一個idea去實現產品、用戶的價值提升。

每一個idea就是一個項目，當項目經歷了立項、啟動、執行、上線、收尾，這個項目就變成了產品的一個功能或一個服務。

二、項目的生命周期

一個產品從無到有，從生到死會經歷多個需求、互動、設計、計劃、開發、提測、上線、hotfix、解決線上問題、運維、運營的生命周期閉環。

而在產品生命周期當中也會包含多個項目的生命周期，每一個項目都會經歷項目啟動、項目執行、項目監控、項目收尾（PMP中項目的五大過程組在這裡被縮減成為了四個，其中項目啟動包含了項目啟動和項目規劃）。

1. 項目啟動

1.1 需求收集

這個階段其實是產品經理最擅長的領域，即為什麽要做這個項目？

在這裡可以參考精益創業畫布中的9個要素去回答：

回答好上面的9個問題後，就可以拿著你的idea去和其他產品pk了，能不能獲得老闆們的資源傾斜成功立項，就看你的項目能不能真的打動老闆。

在這之中，對於老闆來說，往往更關心項目成本和收益：即用最少的人力、時間成本，得到更大的收入、用戶價值提升。

在這個階段，對於負責項目的產品經理來說，需要輸出的是需求文檔及原型，這是你用來打動老闆的基礎，也是需要與涉及項目團隊成員溝通需求的基礎。

1.2 項目啟動會

在立項會上順利從老闆那裡獲得資源後，項目可以真正開始啟動了，這時就需要召開一個項目啟動會，將項目涉及的各個團隊召集到一起，給大家講一個充滿想象力的美好故事，讓大家為了這個目標而努力。

好吧扯淡完了，具體需要做哪些呢：

1. 明確項目要做什麽，其實在這個環節，就是給各團隊的同學講為什麽要做這個項目，這個項目能解決什麽問題，帶來什麽樣的收益，用項目價值去打動各團隊一起努力比老闆說必須做這個理由更有說服力和感染力，也會讓所有人全心全意去為項目努力付出

2. 明確各團隊的職責，即為了這個項目需要做哪些功能的新增或對現有功能的優化。

3. 明確時間節點，即針對於上面提到的功能或優化，各團隊開發、測試以及聯調的時間節點，明確時間節點可以保證項目可以在計劃的時間內完成。

4. 明確項目乾系人：項目負責人、技術負責人、測試負責人，在遇到問題時可以找到對應負責人溝通。

這個階段，在項目啟動會完要出一份會議紀要，周知項目涉及的所有成員。

注意：不僅僅是與會人員，有時在項目啟動會參與的同學也許僅僅是各團隊的主要負責人，並不一定是最終參與項目開發和測試的同學。

所以在會議結束後將會議的內容整理成郵件，群發涉及各團隊的所有成員。

會議紀要郵件中可以附上項目需求文檔及原型，方便項目成員理解，同時還需要在會議紀要中明確項目啟動會中確定的幾個關鍵要素：

項目負責人

項目中各團隊需要做的功能或優化的功能點

項目的時間節點：開發時間、測試時間、聯調時間和上線時間

1.3 需求討論及需求分析

作為產品經理，你可能是某一個項目的負責人，也可能是項目相關團隊的產品經理。

無論哪一個，你都需要針對自己團隊負責的任務進行需求整理，與自己團隊的開發、互動視覺設計、測試確認需求、評估需求。

基於需求文檔與開發、測試、設計進行溝通，確認需求並由相關人員給出工時。

在需求確認階段要注意的是：每個迭代的人力成本和時間成本是有限的，並不是所有的需求都要在一個迭代乾完，參照MVP設計原則，項目也是按照一期二期這樣規劃的。

所以在需求確認過程中，確認需求的優先級及排期，哪些必須一期實現，哪些需要在二期進行完善。

在進行需求優先級排序的過程中可以參考KANO模型，同時也要根據需求點的工時排列，保證在當前排期內可以完成。

這個階段，輸出的文檔並非需要由產品負責，而是由具體的開發人員、測試人員、設計人員給出各自負責功能的任務項拆分，細化到天的顆粒度，保證任務是在監控的範圍內。

2. 項目執行與監控

2.1 項目執行

需求確認、工時評估完成後，正式進入項目執行階段，由相關成員進行開發、設計及測試。

2.2 站立會、周會

每日站立會以及周會是保證項目正常進行的手段之一，通過每天的站立會溝通，確認團隊成員是否遇到了問題，針對問題進行及時溝通與解決，保證項目可以正常進行。

如果項目時間較長，通過周會可以統計周期內好的現象以及遇到的問題，通過會議總結，讓各團隊了解當前項目進度以及遇到的阻礙。

對於跨團隊的項目，往往沒有時間聚集起所有團隊成員一起進行會議溝通，可以由項目負責人與各團隊負責人進行周期性溝通，確認可團隊的項目進度。

這個階段，項目負責人會輸出項目周報，周報的內容主要包含項目當前進度，項目遇到的問題與阻礙，項目下一階段的計劃，涉及各團隊的關鍵裡程碑節點。

2.3 聯調

聯調往往是跨團隊項目需要考慮的問題，只要項目涉及的團隊大於兩個，就需要進行項目聯調，保證各自團隊負責的功能模塊不會因為新的需求出現問題。

如果涉及多團隊涉及從前到後的流程變更，需要在聯調前，召集各團隊測試負責人進行溝通，明確測試範圍、測試時間以及回歸範圍，保證項目上線時新功能模塊的使用以及之前兼容功能的正常使用。

在測試聯調階段，需要每日召開團隊間的站立會，確認各團隊之間測試遇到的問題，如環境問題、版本問題等，提高測試效率，保證上線時間和上線品質，不要因為測試不充分出現上線後回滾的問題。

2.4 項目監控

項目監控，是保證項目進度，保證項目可以在規定時間內保質按時上線。

簡單來說就是：對項目風險的管理——遇到項目風險如何處理，如何解決。

項目風險的可能性有很多，比如開發的delay、測試出現嚴重bug、業務需求方在項目進展過程中頻繁變更需求導致工時無限延長等等。

項目管理指南中指出了項目管理的鐵三角：範圍、成本、時間。但是在筆者看來，項目管理的本質是對人的管理，通過溝通與跟進保證項目的風險出現的可能性盡可能低。

這裡的溝通可能是向上溝通也可能是平行溝通，發現問題背後最本質的原因，基於此去解決問題，如果風險過大真的導致項目的delay，那麽也要許溝通項目的各個相關方，保證當前線上不會出現問題。

3. 項目收尾

結束是新的開始，項目也好、產品也好，只要沒有死，就一定還會有新的開始。

在產品的生命周期中，包含著無數個項目，這其中有好的項目也有不好的項目。

每一次的項目上線或收尾，都需要對項目進行一次複盤和回顧，發現項目過程中的優點與不足，優點繼續保持，不足找到解決方案，在下一次項目中盡可能的避免。

在項目上線後，召集項目成員進行項目的總結與複盤，同時基於項目上線後的效果進行監控，為項目的下一期規劃提供指導意見。

如果通過項目發現與市場、用戶完全不契合，那麽盡快放棄尋找新的方向；如果項目效果還不錯，還有值得優化提高的地方，尋找可以優化的點進行新的排期與規劃，通過不斷的迭代提升產品價值，為用戶創造更大的價值。

三、異地跨團隊項目的坑

因為業務系統的融合，最近做了一個涉及兩地跨團隊的項目：後端兩個業務系統之間的對接，涉及業務訂單發票的全業務流程對接。

坑一：項目並沒有召開啟動會，兩方團隊對項目的重視程度不一致，導致一方將優先級排的較高，而另一方僅僅認為是換接口而已，雙方沒有就項目達成認知上的共識，在對接過程中積極程度不一樣。

坑二：業務流程是從老流程到新流程的切換，雙方前期僅僅對於業務概念進行溝通，雙方認為各自對業務流程達成了一致。

但是有一種你認為並不真的是你認為，這個問題在真正項目上線小流量測試的時候才發現，原來雙方對業務流程的認知偏差很大，導致線上不斷暴露問題。

坑三：在遇到項目風險和項目delay時，雙方團隊的負責人一直在針對線上問題而解決問題，並沒有認識到問題出現的本質原因是雙方流程上的差異，最終導致的結果就是一直在針對暴露的問題而修複，問題不斷暴露，產生了持續性的delay。

對於有較為充足的項目經驗的產品或者項目經理來說，這個項目中的坑都是小兒科的問題，但是對於一些初入職場負責項目管理的產品來說，還是有可能踩到的。

當產品負責人感覺到自己已經深陷入項目的坑中，不如先跳出整個項目，重新去梳理遇到問題的原因，從一個旁觀者的視角去分析一下遇到的問題，尋找解決方案。

當局者迷，旁觀者清。

四、總結

做項目與做產品一樣，都是一個不斷迭代不斷打磨的過程，對於產品經理來說尤其是對於沒有項目經理配合的產品經理來說，並不是產品需求確認後就可以坐等產品上線了。

在產品開發過程當中，不僅要考慮未來產品的規劃，還要關注當前產品的進度，通過溝通、監控、協調，保證當前功能可以正常上線，否則再多的規劃如果無法真的落地，也終究是規劃。

做產品就是做項目，一個優秀的產品經理也必然是一個優秀的項目經理，也許你並不需要考PMP，但是你要對實戰中的項目管理有自己的認知和方法，這樣才能保證你的產品健康的活下去。

———— / END / ————