做為無所不能的産品經理,雖不是上知天文下知地理,但是也要對産品相關的知識領域有所涉獵。項目管理就是與産品密切相關的一個知識領域,同時也是産品經理日常工作中經常要負責的一部分内容。别問我為什麼不是項目經理負責,因為很多公司沒有……
本文結合實際工作實踐以及親身使用
CORNERSTONE項目管理工具經驗,深入淺出介紹在靈活開發的網際網路公司中一個項目從無到有所經曆的各個環節,當然項目管理這門學問還有很多需要深入探索的領域,以下僅僅與各位産品/項目經理們,學習交流一下。
一、做産品還是做項目?
産品就是項目,項目就是産品。
在很多靈活開發的網際網路公司中,産品是項目制,功能也是項目制,在策劃一個新功能的時候,對于産品經理來說就是在策劃一個項目。
在PMBOK第六版的官方指南中,項目指為創造獨特的産品、服務或成果而進行的臨時性工作,項目有固定的起止時間周期。
在大一點的網際網路公司,多個産品經理為同一個産品服務,每一個産品都會絞盡腦汁想一個idea去實作産品、使用者的價值提升。
每一個idea就是一個項目,當項目經曆了立項、啟動、執行、上線、收尾,這個項目就變成了産品的一個功能或一個服務。
二、項目的生命周期

一個産品從無到有,從生到死會經曆多個需求、互動、設計、計劃、開發、提測、上線、hotfix、解決線上問題、運維、營運的生命周期閉環。
而在産品生命周期當中也會包含多個項目的生命周期,每一個項目都會經曆項目啟動、項目執行、項目監控、項目收尾(PMP中項目的五大過程組在這裡被縮減成為了四個,其中項目啟動包含了項目啟動和項目規劃)。
- 項目啟動
1.1 需求收集
為需求生命周期搭建流程,可以自定義更改按收集、評審、排期、設計、開發、釋出設立多個階段,在不同階段把任務分發給産品、設計或者開發人員,讓需求完成無縫銜接。這個階段其實是産品經理最擅長的領域,即為什麼要做這個項目?
在這裡可以參考精益創業畫布中的9個要素去回答:
服務的使用者群體是誰?
解決的問題是什麼?
解決方案是什麼?
你的優勢是什麼?
衡量效果的關鍵名額是什麼?
與競品相比,你的門檻優勢是什麼?
項目成本有多少(人力成本、時間成本)?
項目收益有多少(收入、使用者感覺)?
回答好上面的9個問題後,就可以拿着你的idea去和其他産品pk了,能不能獲得老闆們的資源傾斜成功立項,就看你的項目能不能真的打動老闆。
在這之中,對于老闆來說,往往更關心項目成本和收益:即用最少的人力、時間成本,得到更大的收入、使用者價值提升。
在這個階段,對于負責項目的産品經理來說,需要輸出的是需求文檔及原型,這是你用來打動老闆的基礎,也是需要與涉及項目團隊成員溝通需求的基礎。
1.2 項目啟動會
在立項會上順利從老闆那裡獲得資源後,項目可以真正開始啟動了,這時就需要召開一個項目啟動會,将項目涉及的各個團隊召集到一起,給大家講一個充滿想象力的美好故事,讓大家為了這個目标而努力。
好吧扯淡完了,具體需要做哪些呢:
- 明确項目要做什麼,其實在這個環節,就是給各團隊的同學講為什麼要做這個項目,這個項目能解決什麼問題,帶來什麼樣的收益,用項目價值去打動各團隊一起努力比老闆說必須做這個理由更有說服力和感染力,也會讓所有人全心全意去為項目努力付出
- 明确各團隊的職責,即為了這個項目需要做哪些功能的新增或對現有功能的優化。
- 明确時間節點,即針對于上面提到的功能或優化,各團隊開發、測試以及聯調的時間節點,明确時間節點可以保證項目可以在計劃的時間内完成。
- 明确項目幹系人:項目負責人、技術負責人、測試負責人,在遇到問題時可以找到對應負責人溝通。
這個階段,在項目啟動會完要出一份會議紀要,周知項目涉及的所有成員。
注意:不僅僅是與會人員,有時在項目啟動會參與的同學也許僅僅是各團隊的主要負責人,并不一定是最終參與項目開發和測試的同學。
是以在會議結束後将會議的内容整理成郵件,群發涉及各團隊的所有成員。
會議紀要郵件中可以附上項目需求文檔及原型,友善項目成員了解,同時還需要在會議紀要中明确項目啟動會中确定的幾個關鍵要素:
項目負責人
項目中各團隊需要做的功能或優化的功能點
項目的時間節點:開發時間、測試時間、聯調時間和上線時間
在
裡,可以同時并行管理多個項目。每個項目清晰明确可見責任⼈、任務狀态、優先級、類别、時間等多元度資訊,幫助企業快速⾼效的對項⽬進⾏全周期管理。
1.3 需求讨論及需求分析
作為産品經理,你可能是某一個項目的負責人,也可能是項目相關團隊的産品經理。
無論哪一個,你都需要針對自己團隊負責的任務進行需求整理,與自己團隊的開發、互動視覺設計、測試确認需求、評估需求。
讨論功能可供團隊成員互相交流,共享資訊,解決自己在工作中遇到的各種問題。
基于需求文檔與開發、測試、設計進行溝通,确認需求并由相關人員給出工時。
在需求确認階段要注意的是:每個疊代的人力成本和時間成本是有限的,并不是所有的需求都要在一個疊代幹完,參照MVP設計原則,項目也是按照一期二期這樣規劃的。
是以在需求确認過程中,确認需求的優先級及排期,哪些必須一期實作,哪些需要在二期進行完善。
在進行需求優先級排序的過程中可以參考KANO模型,同時也要根據需求點的工時排列,保證在目前排期内可以完成。
這個階段,輸出的文檔并非需要由産品負責,而是由具體的開發人員、測試人員、設計人員給出各自負責功能的任務項拆分,細化到天的顆粒度,保證任務是在監控的範圍内。
- 項目執行與監控
2.1 項目執行
需求确認、工時評估完成後,正式進入項目執行階段,由相關成員進行開發、設計及測試。CORNERSTONE的甘特圖功能可友善管理者弄清項目的剩餘時間,評估工作進度,調整工作任務,更好地把握項目的整體。
2.2 站立會、周會
每日站立會以及周會是保證項目正常進行的手段之一,通過每天的站立會溝通,确認團隊成員是否遇到了問題,針對問題進行及時溝通與解決,保證項目可以正常進行。
如果項目時間較長,通過周會可以統計周期内好的現象以及遇到的問題,通過會議總結,讓各團隊了解目前項目進度以及遇到的阻礙。
對于跨團隊的項目,往往沒有時間聚集起所有團隊成員一起進行會議溝通,可以由項目負責人與各團隊負責人進行周期性溝通,确認可團隊的項目進度。
這個階段,項目負責人會輸出項目周報,周報的内容主要包含項目目前進度,項目遇到的問題與阻礙,項目下一階段的計劃,涉及各團隊的關鍵裡程碑節點。
2.3 聯調
聯調往往是跨團隊項目需要考慮的問題,隻要項目涉及的團隊大于兩個,就需要進行項目聯調,保證各自團隊負責的功能子產品不會因為新的需求出現問題。
針對這一需求,提供了全局報表(項目進度)。友善管理者了解項目分布、進度計劃、品質風險等,并從中擷取客觀的實時資料,幫助管理人員分析、評估項目,全面了解組合内項目狀況,以便作出及時決策。
如果涉及多團隊涉及從前到後的流程變更,需要在聯調前,召集各團隊測試負責人進行溝通,明确測試範圍、測試時間以及回歸範圍,保證項目上線時新功能子產品的使用以及之前相容功能的正常使用。
在測試聯調階段,需要每日召開團隊間的站立會,确認各團隊之間測試遇到的問題,如環境問題、版本問題等,提高測試效率,保證上線時間和上線品質,不要因為測試不充分出現上線後復原的問題。
2.4 項目監控
項目監控,是保證項目進度,保證項目可以在規定時間内保質按時上線。CORNERSTONE中管理者可根據項目建立情況,可實時更新項目狀态,預警項目風險。簡單來說就是:對項目風險的管理——遇到項目風險如何處理,如何解決。
項目風險的可能性有很多,比如開發的delay、測試出現嚴重bug、業務需求方在項目進展過程中頻繁變更需求導緻工時無限延長等等。
在可視化的平台活動圖上,任意自定義不同緯度統計卡⽚,可⼤⼤⽅便項⽬經理全⾯掌握項⽬進度和團隊表現,了解每位成員⼯作産出與⼯時,提前化解潛在⻛險;同時⽀持⼀鍵分享卡⽚内容。
這裡的溝通可能是向上溝通也可能是平行溝通,發現問題背後最本質的原因,基于此去解決問題,如果風險過大真的導緻項目的delay,那麼也要許溝通項目的各個相關方,保證目前線上不會出現問題。
- 項目收尾
結束是新的開始,項目也好、産品也好,隻要沒有死,就一定還會有新的開始。
在産品的生命周期中,包含着無數個項目,這其中有好的項目也有不好的項目。
每一次的項目上線或收尾,都需要對項目進行一次複盤和回顧,發現項目過程中的優點與不足,優點繼續保持,不足找到解決方案,在下一次項目中盡可能的避免。
在項目上線後,召集項目成員進行項目的總結與複盤,同時基于項目上線後的效果進行監控,為項目的下一期規劃提供指導意見。
如果通過項目發現與市場、使用者完全不契合,那麼盡快放棄尋找新的方向;如果項目效果還不錯,還有值得優化提高的地方,尋找可以優化的點進行新的排期與規劃,通過不斷的疊代提升産品價值,為使用者創造更大的價值。
三、總結
做項目與做産品一樣,都是一個不斷疊代不斷打磨的過程,對于産品經理來說尤其是對于沒有項目經理配合的産品經理來說,并不是産品需求确認後就可以坐等産品上線了。
在産品開發過程當中,不僅要考慮未來産品的規劃,還要關注目前産品的進度,通過溝通、監控、協調,保證目前功能可以正常上線,否則再多的規劃如果無法真的落地,也終究是規劃。
做産品就是做項目,一個優秀的産品經理也必然是一個優秀的項目經理,優秀的産品/項目經理,搭配上好的項目管理工具,必然會對項目開發起到事半功倍的效果,項目管理工具我隻推薦
。