互聯(lián)網(wǎng)行業(yè)項目管理規(guī)章制度

1、互聯(lián)網(wǎng)IT行業(yè)項目管理制度一、制度目的為規(guī)范項目研發(fā)、加強項目管理，保證信息系統(tǒng)符合業(yè)務一致性、內(nèi) 控合規(guī)性、系統(tǒng)穩(wěn)定性、系統(tǒng)安全性，使我公司新產(chǎn)品開發(fā)能夠嚴格遵循 科學管理程序進行，公司根據(jù)企業(yè)實際情況和研發(fā)產(chǎn)品的特點，特制定本制 度。二、適用范圍本制度適用于產(chǎn)品技術人員及其關聯(lián)公司的產(chǎn)品開發(fā)與項目管理全過 程。附件涵蓋產(chǎn)品需求申請表模板，產(chǎn)品設計PRD文檔模板，產(chǎn) 品測試文檔模板。三、制度說明本制度中軟件開發(fā)指新產(chǎn)品系統(tǒng)開發(fā)和現(xiàn)有產(chǎn)品系統(tǒng)升級改造。本制度中軟件開發(fā)遵循項目管理和軟件工程的基本原則。項目管理涉 及立項管理、項目計劃和監(jiān)控、配置管理、合作開發(fā)管理和結(jié)項管理。軟 件工程涉及需求管

2、理、系統(tǒng)設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、驗收測試、試運 行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)轉(zhuǎn)換。各軟件開發(fā)項目組應嚴格遵循本制度所附流程和模版若需調(diào)整需經(jīng) 過相關評審。四、主要角色及職責角色名稱主要職責備注角色名稱主要職責備注技術總監(jiān)指導和監(jiān)督相關崗位按照技術中心項目管理制度進 行日常系統(tǒng)的維護,包括系統(tǒng)備份、權限管理等依據(jù)管理層在產(chǎn)品研發(fā)方面的策略，不斷的對產(chǎn)品進行 版本升級，滿足公司及市場日益變化的業(yè)務需要解決產(chǎn)品發(fā)生的突發(fā)事件，比如服務器崩潰等項目經(jīng)理制定項目計劃，跟蹤項目整體進度，確保項目目標的實現(xiàn)， 帶領項目團隊準時、優(yōu)質(zhì)地完成全部工作。負責產(chǎn)品的開發(fā)流程，系統(tǒng)升級，數(shù)據(jù)審計和信息安全管 理。產(chǎn)

3、品經(jīng)理進行用戶需求調(diào)研和使用行為分析，利用數(shù)據(jù)資源挖掘用 戶的消費習慣和需求，提升產(chǎn)品競爭力，對用戶體驗負責， 提升用戶粘度；協(xié)同研發(fā)部門進行產(chǎn)品設計、產(chǎn)品研發(fā)。開發(fā)工程師負責產(chǎn)品的研發(fā)工作，高質(zhì)量的完成技術經(jīng)理分配的開發(fā)任務UI工程師負責產(chǎn)品的界面設計，廣告設計工作需求分析師負責產(chǎn)品的升級需求的業(yè)務需求分析測試工程師負責制定產(chǎn)品質(zhì)量管理流程、質(zhì)量控制等工作四、開發(fā)管理過程 （一）需求管理依據(jù)公司業(yè)務開展及軟件產(chǎn)品應用現(xiàn)狀所提出的需求，均須遵循本制 度內(nèi)容執(zhí)行。需求分類：（1）根據(jù)其緊急程度，分為緊急類需求和非緊急類需求；（2）根據(jù)其實施優(yōu)先級，分為緊急、高、中、低級四個級別；審批流程（1）需

4、求申請人提交產(chǎn)品需求申請單（詳見附件1）至業(yè)務歸管 部門進行業(yè)務評審，評審通過后，報至產(chǎn)品技術中心。（2）產(chǎn)品技術中心根據(jù)產(chǎn)品需求進行分析，形成評審報告進行內(nèi)部評 審，評審通過后列入部門工作計劃，并提交至公司中高決策層。評審報告 內(nèi)容主要包括預計工作量和成本、風險、可行性分析等（詳見附件2：產(chǎn) 品需求文檔（PRD）模板）。（二）立項管理經(jīng)評審確認后的產(chǎn)品需求由產(chǎn)品技術中心提交公司中高決策層，討 論通過后立項。（三）項目計劃與監(jiān)控對于產(chǎn)品需求，軟件開發(fā)采用項目形式管理，項目經(jīng)理負責整個項目 的計劃、組織、協(xié)調(diào)和控制。技術總監(jiān)配合項目經(jīng)理、產(chǎn)品經(jīng)理與項目干系人進行有效溝通，在項 目目標、項目計劃和

5、工作方法上達成一致。（四）系統(tǒng)設計在系統(tǒng)設計階段中，邀請用戶或者業(yè)務一線人員充分參與，確保系統(tǒng) 設計能滿足系統(tǒng)需求。項目組結(jié)合需求規(guī)格說明書或者系統(tǒng)原型進行數(shù)據(jù)庫設計和功能設 計，并形成DB設計書。項目組組織相關人員對核心功能的相關設計進 行評審，出具評審報告，評審人員應對評審意見簽字確認。項目組進行詳細設計，出具單元測試案例。詳細設計說明書 中，需要定義系統(tǒng)輸入輸出說明和接口設計說明。詳細設計評審和DB設計評審均以業(yè)務需求規(guī)格說明書為依據(jù)， 確保系統(tǒng)設計滿足全部需求。對已確認的系統(tǒng)設計進行修改需項目經(jīng)理及技術組負責人及測試負 責人審批。（五）系統(tǒng)實現(xiàn)系統(tǒng)實現(xiàn)包括程序編碼、單元測試和集成測試。

6、在系統(tǒng)實現(xiàn)時保證開發(fā)、測試和生產(chǎn)環(huán)境獨立，為各環(huán)境建立訪問權 限控制機制，并明確項目成員的職責分工。對生產(chǎn)環(huán)境、測試環(huán)境與開發(fā) 環(huán)境在物理或邏輯方面應該做到隔離。項目組進行單元測試和集成測試，出具單元測試報告、集成測 試報告和系統(tǒng)測試用例，測試人員簽字確認測試結(jié)果（詳見附件3 :xxx系統(tǒng)一測試報告、附件4:xxx系統(tǒng)一測試用例）。項目組完成用戶操作手冊（參照附件5）,凡涉及應用系統(tǒng)的變 更，應對手冊及時更新。（六）系統(tǒng)測試及驗收測試項目測試組依據(jù)項目整體計劃制定項目測試計劃。2產(chǎn)品技術中心確保開發(fā)、測試、驗收、上線運營環(huán)境獨立，為各環(huán)境 建立訪問權限控制機制。搭建驗收環(huán)境供內(nèi)部測試網(wǎng)絡運營中

7、心在驗收測試環(huán)境進行驗收測試，并在驗收測試報告簽字確認。業(yè)務部門邀請合作伙伴參與測試，確保與系統(tǒng)控制活動相關的功能得 到充分的測試，確保系統(tǒng)生成的與編制財務報告相關的報表的正確性。驗收測試通過后，進一步完善用戶操作手冊。（七）系統(tǒng)試運行網(wǎng)絡運營中心根據(jù)項目規(guī)模及影響決定試運行策略。研發(fā)事業(yè)部組織制定試運行計劃并提交網(wǎng)絡運營中心審批。研發(fā)事業(yè)部進行相關系統(tǒng)部署工作，準備培訓資料，對相關用戶和信 息技術人員進行培訓。試運行達到試運行計劃規(guī)定的終止條件時，項目組編寫試運行 報告。此報告應由項目組和試運行單位審批確認，并提交系統(tǒng)主要使用 部門負責人審批。（八）系統(tǒng)驗收研發(fā)事業(yè)部及業(yè)務歸管部門組織驗收小

8、組從業(yè)務需求和功能需求及 技術需求進行系統(tǒng)評估驗收。驗收小組依據(jù)驗收情況整理形成產(chǎn)品驗收報告提交信息系統(tǒng)研發(fā) 事業(yè)部及業(yè)務歸管部門審閱。（九）系統(tǒng)上線系統(tǒng)上線應遵循穩(wěn)妥、可控、安全的原則。研發(fā)事業(yè)部提交系統(tǒng)上線發(fā)布申請。研發(fā)事業(yè)部在系統(tǒng)發(fā)布前檢查經(jīng)測試人員、相關業(yè)務歸管部門負責人 審批確認的系統(tǒng)發(fā)布申請、相關測試報告是否齊全，并提交公司 決策層審批確認。（十）數(shù)據(jù)轉(zhuǎn)換研發(fā)事業(yè)部配合數(shù)據(jù)轉(zhuǎn)換/初始化各相關部門，根據(jù)網(wǎng)絡運營中心和 研發(fā)事業(yè)部負責人簽字確認的數(shù)據(jù)遷移計劃/數(shù)據(jù)初始化計劃進行 數(shù)據(jù)轉(zhuǎn)換/初始化操作。研發(fā)事業(yè)部將數(shù)據(jù)轉(zhuǎn)換/初始化結(jié)果記錄在數(shù)據(jù)遷移結(jié)果報告/ 數(shù)據(jù)初始化結(jié)果報告中，由網(wǎng)絡

9、運營中心負責人審閱并簽字確認。（十一）結(jié)項管理系統(tǒng)結(jié)項后，將系統(tǒng)交由運維團隊進行維護支持工作。（十二）配置管理1產(chǎn)品技術中心統(tǒng)一使用SVN進行版本控制。軟件開發(fā)過程中各項目管理文檔和工作成果均作為配置項進行管理， 其中包括：需求文檔、設計文檔、代碼、測試用例、測試數(shù)據(jù)、數(shù)據(jù)轉(zhuǎn)換 記錄以及項目相關文檔。五、開發(fā)模式我公司采用混用開發(fā)模式，以傳統(tǒng)瀑布式開發(fā)模式加入敏捷開發(fā)特點， 多討論、多溝通，減少冗雜，做到項目的科學管理，完成產(chǎn)品的快速迭代 升級。（一）前期準備、評審階段此階段主要內(nèi)容為需求分析，制定相應的解決方案，并對方案進行分 析。需求分析：專業(yè)業(yè)務需求人員需明確產(chǎn)品需求，分析其版本功能、業(yè)

10、 務背景、需解決問題、用戶操作場景等主要信息。解決方案：包括系統(tǒng)功能、技術方案等，內(nèi)容格式可自由擴展，但需 明確滿足產(chǎn)品需求的方式、方法。方案評審：須經(jīng)業(yè)務專家級人員及業(yè)務經(jīng)驗豐富的人員參與評審，做 出關鍵評審意見，在此基礎上進一步充實解決方案，形成項目列表。同時 完成針對每個開發(fā)功能，拆解為詳細的開發(fā)步驟，估算出工作量。（二）項目實施階段本階段重點內(nèi)容為確立產(chǎn)品最終需求，使團隊成員更加清晰了解產(chǎn)品 需求、開發(fā)、測試等多個環(huán)節(jié)，合理安排工作任務，做到科學規(guī)范，合理 裁剪，快速敏捷。項目實施所涉及的過程管理，參照本制度中開發(fā)管理過 程等內(nèi)容。工作任務安排如下圖：XXX階段任務安排執(zhí)行者：時間：執(zhí)

11、行者：時間：結(jié)束X月X日執(zhí)行者：時間：開發(fā)者：小王時間：X月X日-X月X日n。月X號具體事項E建/具體事項F（三）迭代開發(fā)階段本階段實施過程中，需遵循科學的開發(fā)管理過程，并根據(jù)實際情況進行相應的調(diào)整?？缭桨姹旧夁^程中的小版本迭代升級為短周期迭代，周期半個月， 一個月，兩個月不等?？焖俚^程中，技術團隊應時刻重視團隊合作，每 個迭代過程必須遵循科學的開發(fā)管理過程，根據(jù)實際的情況進行裁剪。迭代開發(fā)周期結(jié)束后，需提交可驗證的交付物，團隊成員針對此迭代 階段進行評審、總結(jié)，在下一個迭代過程發(fā)揚優(yōu)勢，規(guī)避劣勢。迭代開發(fā)交付的成果為經(jīng)過測試團隊嚴格測試、需求分析人員認 可、滿足本次迭代需求的有價值的成

12、果。迭代過程監(jiān)控：涵蓋晨會、夕會、周會、站立會，時間為10-20分 鐘。團隊成員需做如下總結(jié)：昨天的成果、今天的計劃、遇到的問題。項目可視化方式包含：任務燃燒圖,BUG趨勢圖，明細任務顯示圖等。（四）集成測試階段本階段按測試計劃（詳見附件5：xx系統(tǒng)_測試計劃_模板） 進行兼容性測試、功能測試、性能測試，確保產(chǎn)品整體穩(wěn)定性，可靠性； 制定BUG趨勢圖，測試工程師需對出現(xiàn)的BUG進行跟蹤管理，可采用禪 道項目管理軟件等。（五）產(chǎn)品上線產(chǎn)品開發(fā)經(jīng)過以上過程，完成內(nèi)部評審后，方可上線。產(chǎn)品開發(fā)過程需求分析需求確認解決方案項目進度任務分配過程監(jiān)控進度跟蹤質(zhì)量管理4,自適應團隊集成測試通過后 發(fā)布測試版

13、內(nèi)測產(chǎn)品需求申請表提出人提出部門提出時間年 月曰版本系統(tǒng)模塊問題描述提出部門意見領導簽字：日期：產(chǎn)品部意見領導簽字：日期：技術組意見領導簽字：日期：執(zhí)行人簽字：日期：產(chǎn)品需求（PRD ）文檔編號：日期：2015年10月09日編號文檔版本修訂內(nèi)容修訂原因修訂日期修改人12一、引言.錯誤!未定義書簽。產(chǎn)品概述及目標： .錯誤!未定義書簽。產(chǎn)品路線圖：錯誤!未定義書簽。預期讀者：錯誤!未定義書簽。成功的定義和判斷標準：錯誤!未定義書簽。名詞說明：錯誤!未定義書簽。二、需求概述錯誤!未定義書簽。需求概覽：錯誤!未定義書簽。用戶類與特征：錯誤!未定義書簽。運行環(huán)境：錯誤!未定義書簽。設計和實現(xiàn)上的限制：

14、錯誤!未定義書簽。時間要求：錯誤!未定義書簽。產(chǎn)品風險：錯誤!未定義書簽。三、功能需求錯誤!未定義書簽。功能結(jié)構(gòu)錯誤!未定義書簽。產(chǎn)品功能描述錯誤!未定義書簽。貨主版錯誤!未定義書簽。車主版錯誤!未定義書簽。管理后臺錯誤!未定義書簽。3.產(chǎn)品規(guī)則錯誤!未定義書簽。四、 非功能性需求錯誤!未定義書簽。性能要求：錯誤!未定義書簽。易用性需求：錯誤!未定義書簽。安全性需求：錯誤!未定義書簽。運行環(huán)境約束：錯誤!未定義書簽。外部接口：錯誤!未定義書簽。一、 引言這部分的內(nèi)容有：產(chǎn)品概述及目標、產(chǎn)品roadmap、預期讀者、成功的定義標準 和判斷、參考資料、名詞說明產(chǎn)品概述及目標：解釋說明該產(chǎn)品研發(fā)的背

15、景以及核心功能。產(chǎn)品路線圖：為產(chǎn)品規(guī)劃的藍圖，每個關鍵階段完成的核心任務。產(chǎn)品研發(fā)是個不斷迭代的 過程，需要經(jīng)過若干個版本的迭代，對一個功能點做了 N個迭代后最終又回歸到了 第一個迭代是很常見。產(chǎn)品經(jīng)理需要做好心理準備。產(chǎn)品roadmap并不需要全部 規(guī)劃好所有的階段目標，但是對產(chǎn)品未來發(fā)展趨勢的一種預估，要達到目標，需要更多的更新和迭代。清晰的呈現(xiàn)產(chǎn)品的roadmap可以幫助產(chǎn)品經(jīng)理把握產(chǎn)品的全 貌，更好的控制研發(fā)過程。預期瞄：文檔的使用對象4.功的定義和判斷標準：旨在說明產(chǎn)品的目標。名詞說明：名稱、說明。名稱就是對文檔中會出現(xiàn)的比較新的名稱，說明則是對這些名稱進行解釋。二需求概述需求概覽：

16、一是業(yè)務流程圖，對產(chǎn)品整個業(yè)務流程的發(fā)生過程做圖形化的展示，是對產(chǎn)品 整體功能流程的闡釋。二是需求清單，對本次要開發(fā)的需求任務做分類，給出簡明扼要的需求描述并 標注優(yōu)先級。用戶類與特征：產(chǎn)品的最終用戶，確定產(chǎn)品的最終使用者，并對使用者的角色和操作行為做出 說明。運行環(huán)境：該功能上線后需要在以下操作系統(tǒng)中正常運行:Microsoft Windows XP、Windows Server、Windows Vista、Windows 7、Windows 8等版本；跚和實現(xiàn)上的限制：比如控件的開發(fā)環(huán)境、接口的調(diào)用方式等等時間要求：此需求需要在2014年3月30日完成需求評審，在2014年5月1日前完成開

17、發(fā)，在上線時間等等。里程碑時間交付物產(chǎn)品風險：描述產(chǎn)品可能存在的風險，比如性能瓶頸，沒有解決的問題，用戶不當使用的風險等等。三、功能需求功能結(jié)構(gòu)產(chǎn)品功能的框架圖。產(chǎn)品功能描述產(chǎn)品功能需求的詳細描述。貨主版車主版管理后臺產(chǎn)品規(guī)則涉及產(chǎn)品中的各種規(guī)則，比如積分細則，會員等級劃分等等性能要求:用戶在軟件響應速度、結(jié)果精度、運行時資源消耗量等方面的要求。易用性需求：用戶在界面的易用性、美觀性，以及對面向用戶的文檔和培訓資料等方面的要求。安全性需求：用戶在身份認證、授權控制、私密性等方面的要求。運行環(huán)境約束：用戶對軟件系統(tǒng)運行環(huán)境的要求。外部接口：用戶對待開發(fā)軟件系統(tǒng)與其他軟件系統(tǒng)或硬件設備之間的接口的

18、要求。附件（三）xxx_測試報告頒布日期：2015年11月06日受控狀態(tài)：受控非受控分發(fā)范圍：產(chǎn)品技術中心目錄概述錯誤!未定義書簽。背景錯誤!未定義書簽。目標錯誤!未定義書簽。測試范圍錯誤!未定義書簽。測試環(huán)境錯誤!未定義書簽。參考文檔錯誤!未定義書簽。測試過程錯誤!未定義書簽。測試概述錯誤!未定義書簽。測試用例執(zhí)行率錯誤!未定義書簽。遺留缺陷錯誤!未定義書簽。測試分析錯誤!未定義書簽。功能測試分析錯誤!未定義書簽。測試結(jié)論錯誤!未定義書簽。結(jié)論錯誤!未定義書簽。風險及局限性錯誤!未定義書簽。建議錯誤!未定義書簽。測試報告背景說明編寫本報告的目的，測試所依據(jù)的文檔和測試參與方。目標說明測試的目標測試范匚二1 乙說明測試的測試范圍及測試內(nèi)容序號測試范圍測試內(nèi)容1界面測試驗證界面是否滿足UI及需求定義測試環(huán)境說明軟件測試所需的測試環(huán)境，包括操作系統(tǒng)、數(shù)據(jù)庫、配置，手機型號、品牌等。數(shù)據(jù)庫服務器配置主機IP型號配置操作系統(tǒng)Tomcat版本數(shù)據(jù)庫管理端客戶端配置主機IP品牌配置操作系統(tǒng)測試手機手機品牌型號配置操作系統(tǒng)參考文檔說明本測試報告所用到的參考資料等。文檔已創(chuàng)建或可用已被接收或已經(jīng)過復審作者或來源備注XXXXXX是否口是否口SVN測試過程測試概述說明測試的測試模塊，測試方法，測試時間、測試地點、測試人員等|本