上一篇博客詳細論述了產品開發過程中遇到的問題,看來不光是我自己感受到了,其實大家都有那種很累但是又沒產出的感覺,是整體的流程機制出了問題,所以纔要搞流程變革,而其中和我們開發人員最密切相關的就是IPD流程,瞭解了IPD的目標、核心理念以及涉及人員之後,來詳細聊聊IPD的流程。
- 概念與設計階段:項目建立、組織、架構與概要設計的評審
- 開發階段:產品的詳細設計、開發測試到上線的迭代流程
- 驗證階段:產品的內部驗證和客戶試用
- 發佈階段:已經驗證過的產品的正式發佈,大面積公開發布
- 生命週期階段:產品對外發布後進入維護、優化甚至下線的一個流程
在此之前我們只有迭代,也就是隻有開發階段,而且開發階段還不怎麼規範。需要注意的是這5個生命週期也不一定需要全部經歷,當然最好是儘量都走,很多情況下如果是比較小的迭代或者敏捷迭代,就不一定需要走。
概念與設計階段
第一個階段主要就是定義目標和成員,並且分解任務和需求,在進行第一個階段的時候包含以下幾個步驟和涉及的人員:
步驟 | 步驟目標 | 人員 | 任務內容 |
---|---|---|---|
1 | MM組下達任務書 | MM組 | 思考以下幾個問題:Why:爲什麼要開發這個產品?What:開發什麼產品,從而要滿足客戶的什麼需求?Who:都有誰來參與產品的開發?When:每個階段的時間安排,比如何時進入開發階段?How:如何開發這個產品?How much:產品開發的投資收益是多少? |
2 | 組建PDT | MM組 | 組建項目組、指派一條龍的項目經理,PDT包括(產品經理、架構師、產品Marketing、服務、運維、軟件、安全、測試、項目財務等) |
3 | Kick Off | PDT核心成員 | 項目啓動儀式,項目的啓動要有儀式感,此時是項目的核心成員參與,包括開發leader等、但此時尚未指派具體工作,具體模塊到底由誰做還不確定 |
4 | 輸出WBS | 項目經理和架構師 | WBS(Work Breakdown Structure)項目工作任務分解,進行具體的任務拆解,可能還需要按照模塊進行大的拆解, |
5 | 需求分析與架構設計 | 項目經理和產品經理以及架構師 | 有了初步的WBS後,項目經理可以會同相關的產品經理和架構師,主要工作是進行需求分析和架構設計,對產品的需求是怎麼理解的、對場景等的理解。架構師也需要做技術路線分析與方案。當然如果有需要,UE/UI需要定義主設計、運維需要定義運維策略,總之這一步就是在WBS的拆解基礎上進行詳細的產品設計 |
6 | 需求與概要設計評審 和技術方案評審 | MM組和技術委員會 | 第一個TR點,主要包括產品和技術兩個方面的評審,是不是符合最開始的項目任務書的要求,以及爲什麼這麼做,這麼做有什麼風險,評審通過後或者同期,架構師進行需求匹配與分解,產品市場定義運營策略、財務進行成本評估 |
7 | 計劃決策 | MM組和技術委員會 | 評審完畢後進入第一個ChekPoint決策點,在評審和資源劃分後認爲可行 就將項目推入具體的開發階段 |
開發階段
第二個階段就涉及到具體的開發細節了,也就是我們通常認爲的迭代主流程,也是耗時最久的一個流程,在此過程中項目經理全程監控項目進度(1-10),架構師團隊在正式代碼開發前對過程中的需求變更、技術評審等流程提供支持(1-6)、財務在正式代碼開發前跟蹤成本和費用(1-6)。產品市場在測試階段開始進行同時產品經理和產品市場可以開始進行局部培訓,產品市場可以開始制定發佈計劃與前期售賣計劃(9),除去跨流程的人員外在進行第二個階段的時候包含以下幾個步驟和涉及的人員:
步驟 | 步驟目標 | 人員 | 任務內容 |
---|---|---|---|
1 | 詳細設計 | 產品開發測試設計 | 產品經理爲主、開發和測試參與幫助進行產品的詳細設計,用戶場景、用戶功能以及規約等形成整體的PRD(產品原型),同步進行的是UE/UI的整體視覺設計、交互設計等出一個視覺設計稿,如有需要還可以確定前期的用戶驗證 |
2 | 詳細設計評審 | 項目經理和產品主Owner | 第二個TR點,詳細設計的評審,可以拉一些前端人員或者設計驗證組等一起進行詳細設計的評審,這個評審一定要特別細膩和完整,成員由項目經理靈活指定 |
3 | 任務分解 | 主副leader | 主leader負責技術開發,輔leader主要負責具體的故事的負責。主副leader要對排期進行評估,分配到人 宣講之前!這一點非常重要,誰的任務誰參加任務宣講反講。 |
4 | 宣講&反講 | 產品開發測試設計 | 建議產品在宣講時按照規範結構講解,先說說背景再到story,把前因後果都講清楚,設計部分建議設計來講,建議聽講的開發測試再聽到講完story再統一提出一些問題,不要中途打斷 |
5 | 一頁紙方案 | 開發測試 | 需要開發人員提出一頁紙的設計,我個人覺得這個環節特別棒,很多坑在開始前就能通過充分討論規避掉,接下來的開發任務就是照本宣科就可以了,可以規避很多的開發風險 |
6 | 實現方案評審評審 | 技術委員會 | 第三個TR點,一頁紙方案的評審,在這個環節主要對一頁紙設計的方案進行評審,並進行好的差的的評比 |
7 | 開發 | 前後端開發人員 | 正常的開發流程,按照排期和一頁紙設計的方案進行正常的開發流程 |
8 | Demo演示 | 開發測試 | 前後端開發人員對開發好的模塊給測試進行Demo主流程演示,確認是否達到了可以測試的標準 |
9 | 測試環境流程 | 測試 | 測試要進行模塊測試、集成測試、labs演示和安全測試, |
10 | 版本上線 | 開發測試產品 | 產品的迭代上線,我認爲這裏需要加上運維這個角色 |
驗證階段
第三個階段比較簡單,耗時比較短,涉及人員也比較少,在進行第三個階段的時候包含以下幾個步驟和涉及的人員:
步驟 | 步驟目標 | 人員 | 任務內容 |
---|---|---|---|
1 | 早期客戶驗證 | 銷售 | 進行早期的客戶驗證,在小部分的客戶羣體進行產品試用,例如推出10-20家左右的客戶 |
2 | 產品優化與驗證 | 項目經理組織 | 對產品進行優化,fix修改,依據客戶的反饋對產品進行調整 |
3 | 可獲得性分析 | 產品經理 | 產品經理依據優化和客戶驗證進行可獲得性分析,爲接下里的可獲得性決策提供依據 |
4 | 可獲得性決策 | MM組和技術委員會 | 第二個ChekPoint決策點,決策是否要將該產品鋪開到市場上去 |
發佈階段
在可獲得性決策通過後就進入發佈階段,第四個階段比較簡單,耗時比較短,涉及人員也比較少,在進行第四個階段的時候包含以下幾個步驟和涉及的人員:
步驟 | 步驟目標 | 人員 | 任務內容 |
---|---|---|---|
1 | 產品發佈與市場宣傳 | 產品市場 | 進行產品的發佈,產品的宣傳和驗證 |
2 | 產品發佈與市場宣傳流程 | 項目經理等 | 項目經理對產品進行驗收和總結,是產品積累的重要階段,設計驗證組進行盈利分析 |
生命週期階段
發佈完成後進入生命流程階段,第五個階段比較簡單,耗時比較短,涉及人員也比較少,在進行第五個階段的時候包含以下幾個步驟和涉及的人員:
步驟 | 步驟目標 | 人員 | 任務內容 |
---|---|---|---|
1 | 組建LMT | MM組 | 組建LMT,也即產品生命週期管理團隊 |
2 | 持續產品運營流程 | 產品市場 | 產品市場爲主持續進行產品的運營,項目經理和架構師進行產品維護和管理,設計驗證組進行維護與改進成本,產品經理和開發進行維護與改進支持 |
3 | 下線決策 | 產品市場 | 產品市場決定產品是否需要下線 |
4 | 下線決策流程 | 項目經理開發產品 | 下線決策後,項目經理進行產品生命週期終止計劃,開發產品進行下線支持 |
5 | 退出市場決策 | MM組 | 第三個ChekPoint決策點,決策產品是否退出市場,退出後IPD流程結束 |
瞭解了整個流程後我覺得最爲關鍵的兩個應該就是概念與設計、開發流程,也就是我們的評審和迭代主流程,其它的雖然也重要但是和開發人員其實關係不大,瞭解瞭解也沒壞處,總體而言整個流程是圍繞IPD核心理念設計的。