1.目的

規範網際網路軟體產品開發專案管理過程，指導開展專案研發、管理等活動。

2.適用範圍

本章程的作用範圍為網際網路軟體產品開發立項至結項管理過程。

1.對專案經理開展產品規劃及設計活動以及專案管理手段和應遵循的開發流程提供了指導；

2.對專案團隊的日常管理活動及內容進行了指導；

3.角色及職責定義

專案經理：

進行產品開發過程中的業務目標、進度、成本、質量控制。

挑選專案團隊並進行團隊建設，激發、鼓舞和改進團隊的生產效率。

識別專案干係人，定期向干係人彙報，並作為團隊和外部的介面，遮蔽外界對團隊的干擾。

確保專案中流程被遵循，組織、監督、培訓專案各實踐活動。

產品策劃

確定產品的功能，拆分使用者故事。

需求功能確定優先順序。

接受或拒絕開發團隊的工作成果。

參與產品開發過程中的有關會議。

UI

根據使用者故事，負責產品的功能互動及介面設計

組織開展人機互動及使用者體驗，不斷跟蹤改進，提高產品表現力。

參與產品開發過程中的有關會議。

開發

根據使用者故事，負責產品的技術架構設計及功能開發

評估、設計及維護產品相應模組，確保模組的穩定性、易用性、高效性。

參加產品開發過程中的有關會議。

測試

根據使用者故事，設計產品測試標準，確保產品品質滿足市場需求。

合理分配測試資源，組織產品測試並優化測試流程及測試標準，提高測試效率。

編寫產品測試用例，提交測試問題，編寫測試總結報告，以測試角度來確定產品版本是否釋出。

4. 專案管理過程

按照網際網路軟體產品專案開發過程，可將整個專案管理過程分為立項過程、規劃過程、執行與監控過程、結項過程。下面分別闡述在每個階段過程中該如何進行專案管理。

4.1立項過程

網際網路軟體產品開發專案的立項過程，通常是指從準備專案啟動會到召開會議這個階段，在立項過程中，需要完成專案目標，需求範圍的初步確認，專案團隊成員，其他資源的安排。

確定專案的初步目標並達成共識

對於專案目標，需要和干係人在以下幾點上達成共識：

專案的背景、目標使用者、核心人員及產品定位是什麼

專案的資源投入預算是多少

專案的資源投入是多少

各人員在專案中扮演的角色和對專案的作用是什麼

準備啟動會議文件

文件內容包括：

使用者畫像

產品定位

市場策略

業務目標

技術可行性

研發成本預算

路標規劃

召開專案啟動會

參加人員包括：

管理層代表

專案經理及專案團隊

其他干係人代表

主要議題包括：

申明專案目標範圍及對組織目標的貢獻。

管理層正式任命PM，設定期望，統一思想

文件內容的宣講。

與PM小組確定專案管理要求

專案啟動會完成後，需要與PM小組成員確定專案立項機制以及公司專案管理要求。

4.2規劃階段

在規劃階段，團隊需要共同完成產品的版本規劃，迭代計劃

版本規劃

從產品的關鍵特性列表中按照優先順序規劃產品每個版本需要完成哪些特性，在規劃完成後需要在專案干係人內達成共識。具體可參考《版本規劃樣例》

迭代如何劃分

迭代劃分是指將特性列表拆分形成使用者故事列表，並將其對應的主要任務劃分到各個迭代中去，形成粗粒度的專案迭代計劃。這個過程主要考慮以下幾個因素：

有些任務間是有依賴關係，某個任務的開始或結束是以另一個任務的開始或結束為前提，在劃分時必須考慮這種前後依賴關係。

在安排每個迭代的任務時，需要對各種因素進行綜合考慮，如平衡每個迭代中任務的技術難度和價值差異。

除了進行初步的迭代任務劃分，還需要確定專案過程中迭代任務調整的規則，如迭代任務未完成時是將剩餘任務延至下一迭代還是延長迭代週期。

確定人員分工

專案經理需要根據每個人員的能力和特點，初步擬定大致分工。在進行任務分工時需考慮以下因素：

任務難度與人員能力相匹配，對於明顯超出能力範圍或過於簡單的任務容易造成負面影響。

耦合度高的儘量分配給同一個人，避免不必要的溝通消耗。

鼓勵團隊內部“任務認領”，提高人員的工作積極性和主動性。

確定迭代執行模式

如一週迭代、兩週迭代，每個迭代包含的工作內容等。

具體的迭代計劃可參考《迭代計劃樣例》

制定其他輔助計劃

制定溝通計劃、風險計劃和質量計劃是必要的，溝通計劃主要包含以下幾個方面：溝通物件、溝通方式、溝通頻率即可，如：

風險計劃包括風險項、負責人、重要性、應對措施，如下：

質量計劃包括：bug分佈滿足何種條件可以釋出，有幾個致命bug必須停止開發新特性等。。

搭建基礎技術架構

如果是一個全新的專案，需要重新開發系統框架，則這個工作應該在迭代0完成，否則會影響後期的工作開展。系統框架的每次改動必然會導致大量的重複工作量，從而給穩定的團隊節奏帶來很大的毛刺。

3.3專案執行和監控過程

迭代N的執行

A、迭代N的需求細化

考慮每個迭代需要完成的使用者故事；

使用者故事需包含幾個部分，工作量評估、功能性需求、非功能性需求。具體的可參考《使用者故事模板及樣例及拆分說明》

使用者故事編寫完成後需要在團隊內部進行需求評審，一方面是為了向團隊成員解讀該需求，另一方面團隊成員也可在評審時給出指導性意見。

B、測試用例評審

測試人員根據使用者故事要求編寫對應的測試用例，並組織專案團隊進行測試用例評審。根據評審意見修改測試用例

C、開發

將使用者故事的需求開發的過程。

D、開發自測

在開發過程中，每完成一個功能點，都需要及時的進行開發自測並通知產品策劃人員進行驗收體驗。

E、驗收

開發完成後，產品策劃需要對開發完成的成果進行驗收，驗證其是否符合使用者故事的要求，驗證通過後方可流到測試環節，否則需與開發詳細討論其不符合性，其驗收的checklist可以參考《產品驗收checklist及模板》

F、測試和迴歸

提交測試時，必須要有正確的版本。測試人員根據測試用例進行測試，在IT平臺中提交測試bug，並根據測試的角度給出產品是否釋出的意見，輸出《測試報告》

G、bug修改

在IT平臺中獲取分配給自己的bug進行修改。

H、showCase

階段性必須有可體驗版本進行showCase.需要

確定showCase時間：某個迭代開發、自測完成，準備提交測試前

會議前1-2天發出體驗版給到參與人員

會議期間，由專案經理組織大家體驗、反饋問題、記錄問題。

專案經理根據問題情況，與開發或產品確定問題的解決時間併發出會議紀要。

I、灰度釋出

迭代一定版本後，由專案經理與團隊共同決定是否需要進行灰度釋出。

監控方式

每日站立會

主持人輪流擔任，負責控制節奏，記錄問題，以備會後跟蹤。

每人講自己昨天做了什麼，有什麼問題，今天的計劃是什麼；

其他人瞭解別人的工作情況，並發現指出可能存在的問題。

對於發現的問題，鼓勵認領，其餘由專案經理指定責任人。

時間通常控制在15分鐘內。

會議期間，更新任務牆，任務牆樣式如下：

週報

反饋專案計劃的執行情況，強調本週工作要達成的目標

暴露出專案的問題，特別是需要領導或其他團隊需要協助的問題。

週報可在IT平臺中輸出。

月報

反饋專案當月的執行情況，包括進度、人力及質量。

反映專案存在的問題和風險。

迭代回顧

每人講述本次迭代做的好的地方和不好的地方

回顧上個迭代不好的地方，看看改進情況。

讓每個人發言。

每次迭代回顧會議完成後，可更新燃盡圖

3.4結項階段

專案經理指導產品策劃收集總結專案的產品運營資料，同時指導團隊成員從自身角色進行總結，包括測試、開發、UI等。

專案經理與專案團隊成員給出專案總結報告，內容可參考《專案經驗教訓總結-專案團隊》，《專案經驗教訓總結-專案經理》

召開結項會議，各成員進行結項彙報。

PM小組將過程文件和經驗教訓總結進行歸檔。