沒有流程規(guī)范就沒有管理，感覺是隨意帶來高效，往往是隨意帶來的是混亂，熵增定律是不能違背的，面對復雜紛繁的事和人，是需要規(guī)范流程和制度來協(xié)作和串聯(lián)的！
今天就給大家分享一個《項目管理規(guī)范標準流程V3.0》實例，供大家參考；
一、 規(guī)范背景
1) 目的
2為了適應公司的發(fā)展，對項目管理流程進行修改和完善；
2規(guī)范項目管理流程，指導項目各成員更好的完成項目；
2通過實施有效的項目流程，滿足在以下三方面項目管理有所進步：
n產(chǎn)品滿足需求
n質量符合預期；
n項目時間符合計劃
2通過對需求、計劃、設計、開發(fā)、測試、發(fā)布、維護的全程控制，減少項目風險。
2規(guī)范的流程是一筆可以積累的財富，可以不斷的提升我司項目管理的能力
2) 適用范圍
公司常規(guī)涉及的所有項目和項目集；
3) 術語定義
|
術語 | 定義 |
PM | Project Manager, 項目經(jīng)理 |
DCC | Document Control Center文檔管理控制中心 |
QA | Quality Assurance品質保證 |
TDT | Technology Development Team 技術開發(fā)團隊 |
UED | User Experience Design 用戶體驗設計 |
二、 項目管理流程圖
說明：
1、整個項目不限于本流程中所規(guī)定的。
2、本流程僅對關鍵點進行了規(guī)定，可以靈活安排項目中的事項。
3、項目過程中提倡會下溝通確定相應問題，盡力減少涉及人數(shù)較多的大型會議。
4、項目過程中出現(xiàn)任何問題請及時暴露出來，以便及時推進解決。
5、產(chǎn)品需求不涉及的環(huán)節(jié)和DCC溝通后可以不提供相應文檔。
三、 項目文檔簡介
注：
1.項目經(jīng)理不明確指定則由產(chǎn)品經(jīng)理擔任。
2.特殊情況某些文檔不需要編寫時請和DCC人員確認。
3.變更申請和問題處理報告不發(fā)生則不必提交。
四、 項目階段劃分
|
階段 | 參與角色 | 內容 |
需求階段 | 產(chǎn)品經(jīng)理 | 收集新項目需求、用戶反饋、市場和商務反饋、競品研究、運營需求、內部系統(tǒng)優(yōu)化等多方需求信息。并初步形成《需求設計說明書》。 《需求設計說明書》初稿可將需求分為功能需求、性能需求、數(shù)據(jù)需求等，并注明需求優(yōu)先級。 |
產(chǎn)品經(jīng)理 項目經(jīng)理 | 綜合各方面信息和《需求設計說明書》，初步確定項目目標、項目重點等，找準項目定位，并初步規(guī)劃時間。 | |
產(chǎn)品項目 UED 開發(fā)人員 | 開發(fā)人員根據(jù)《需求設計說明書》初稿和產(chǎn)品/項目經(jīng)理進行初步技術可行性分析，確定哪些需可以實現(xiàn)，哪些需求不能實現(xiàn)，哪些需要討論等，并初步對需求進行篩選。 | |
產(chǎn)品經(jīng)理 項目經(jīng)理 UED 客戶端主管 服務端主管 測試主管 運營主管 數(shù)據(jù)主管 相關人員 | 1. 產(chǎn)品經(jīng)理會前下發(fā)《需求設計說明書》初稿文檔，并確認每一位評審者都收到需求文檔，并且理解了評審要求（強烈建議當面溝通）。 2. 參與評審者應在會前整理問題清單。 3. 產(chǎn)品經(jīng)理組織需求評審，對《需求設計說明書》初稿進行評審，項目經(jīng)理、研發(fā)、測試、配置管理等人員參與，并提出意見，產(chǎn)品經(jīng)理匯總所有評審意見并形成《需求評審記錄》郵件，會后將評審結果及文檔發(fā)布給相關人員 4. 產(chǎn)品經(jīng)理根據(jù)評審意見組織相關人員修正《需求設計說明書》，如有需要，需再次評審。 5. 產(chǎn)品經(jīng)理形成正式的《需求設計說明書》。 6. UED根據(jù)正式的《需求設計說明書》進行交互設計并完成《交互設計說明書》。 7. 會議上需和各部門主管確定項目各個環(huán)節(jié)的實際負責人。 | |
立項階段 | 項目組成員 DCC 相關領導 | 1. 項目經(jīng)理根據(jù)需求分別和客戶端、服務端、測試、數(shù)據(jù)、運營等負責人溝通初步確定項目的時間后初步制定《立項報告書》初稿（必須包含項目計劃，注明項目里程碑時點，確定項目組成員和定義好相關工作）； 2. 立項會議，項目經(jīng)理和項目成員介紹項目的大體情況，項目的大體階段劃分，每個負責人所需要承擔的大體任務，確定后續(xù)項目管理運作辦法（項目日報、項目周會等）等，并評審《立項報告書》，經(jīng)項目組成員、管理層評審通過后，上述文檔作為公司和項目組關于項目目標和約束條件達成共識的實施文件而正式生效。同時為后續(xù)制定各個詳細開發(fā)和測試計劃做下鋪墊。 3. 項目經(jīng)理根據(jù)會議評審結果對《立項報告書》進行修改，然后發(fā)送給所有相關人員。 4. 《立項報告書》評審通過后，客戶端、服務器、測試、數(shù)據(jù)等的負責人根據(jù)項目的整體進度制定相應的開發(fā)和測試計劃。 |
設計階段 | 服務端負責人 客戶端負責人 數(shù)據(jù)端負責人 | 1. 研發(fā)負責人根據(jù)《需求說明書》和《立項報告書》確定詳細的《開發(fā)計劃》。 2. 研發(fā)負責人根據(jù)《需求說明書》編寫《設計說明書》。 3. 研發(fā)負責人組織相關人員參加《開發(fā)計劃》和《設計說明書》的評審工作。 |
測試負責人 | 1. 測試負責人根據(jù)《需求設計說明書》、《立項報告書》編寫《測試計劃》和《測試用例》。 2. 測試負責人組織相關人員評審測試計劃和測試用例，會后發(fā)布會議記錄。 3. 評審完畢后根據(jù)會議討論內容對測試計劃和用例進行修改完善，修改完成后發(fā)給相關人員。 注意：測試用例編寫、評審部分可貫穿設計、開發(fā)兩個階段 | |
開發(fā)階段 | 研發(fā)人員 產(chǎn)品經(jīng)理 | 1. 研發(fā)人員進行代碼編寫，調試。 2. 研發(fā)人員進行功能自測試。 3. 開發(fā)過程中，如《需求設計說明書》和《交互設計》有更新，請及時通知相關人員并提交最新需求說明書文檔給DCC。 4. 研發(fā)人員更新代碼到指定位置，根據(jù)需要提交編譯后版本，在測試管理系統(tǒng)上建立相關的版本并存放在規(guī)定的FTP對于項目的目錄下。 5. 研發(fā)人員提交測試任務，并郵件通知相關人員，版本郵件發(fā)送請按照相關標準發(fā)送。 |
測試階段 | 測試負責人 客戶端負責人 服務端負責人 數(shù)據(jù)負責人 項目經(jīng)理 產(chǎn)品經(jīng)理 | 1. 測試人員檢查研發(fā)人員提交的測試任務是否滿足測試條件，如果不滿足可以拒絕測試，并填寫拒絕測試的原因。 2. 測試人員接受該測試任務后，按照《測試計劃》組織相關人員，對項目進行測試，對于有性能測試要求的項目需進行性能測試。 3. 測試負責人對測試中發(fā)現(xiàn)的Bug上報Bug管理系統(tǒng)，并把測試報告發(fā)給相關人員。 4. 研發(fā)人員修改Bug，并重新提交測試版本。 5. 服務端負責人提交《上線部署方案》，相關管理者對此進行審批。 6. 部署人員審核部署工單，并參考《上線部署方案》進行系統(tǒng)上線部署。 7. 部署完成后測試人員對線上系統(tǒng)進行測試驗證，如有問題提交到管理系統(tǒng)。 8. 數(shù)據(jù)分析人員確定數(shù)據(jù)需求已經(jīng)完成并正?？捎谩?/span> 9. 最后一個測試版本結束后，項目經(jīng)理組織會議評審遺留bug，測試結果是否滿足發(fā)版條件等。 10. 項目經(jīng)理和所有相關方確認各環(huán)節(jié)情況是否具備發(fā)布條件。 |
發(fā)布階段 | 項目組成員 商務人員 相關領導 | 1. 項目經(jīng)理預先評估提交的版本是否滿足發(fā)布標準，如果滿足則進行下一步。 2. 項目經(jīng)理協(xié)助檢查項目中各個文檔是否按規(guī)定提交，DCC人員發(fā)版前檢查各項文檔是否齊全規(guī)范。 3. 項目經(jīng)理組織版本發(fā)布評審，根據(jù)公司版本發(fā)布判定標準，進行版本發(fā)布判定。各負責人對負責項進行檢查，最后完成《版本發(fā)布評審記錄》。 4. 客戶端負責人確定最終版本，并對最終版本進行封版，發(fā)布流程完成后項目經(jīng)理協(xié)調開發(fā)人員生成各個渠道版本，并提交測試驗證。 5. 產(chǎn)品經(jīng)理提供《產(chǎn)品手冊（包含客服文檔）》給項目組成員、客服人員和DCC。 6. 產(chǎn)品經(jīng)理通知客服及相關部門版本發(fā)布的信息。 7. 項目經(jīng)理協(xié)助商務人員對版本進行發(fā)布。 |
維護階段 | 運營負責人 研發(fā)負責人 項目經(jīng)理 | 1. 運營、市場、客服或者數(shù)據(jù)部門收集問題或投訴，并將問題和結果反饋給項目經(jīng)理。 2. 項目經(jīng)理安排測試和研發(fā)人員進行問題重現(xiàn)。 3. 研發(fā)人員對問題類型評估（拒絕問題或者解決問題），進行缺陷修正和故障處理支持。 4. 項目經(jīng)理匯總Bug數(shù)據(jù)和重點問題，并分析原因。 5. 問題處理完成，項目經(jīng)理組織開發(fā)、測試和其他人員完成問題處理報告。 6. 運營人員在一定時間內提供運營報告給項目組和相關人員。 7. 當項目正式運營后，項目經(jīng)理編寫項目總結報告，并召開項目總結會議（小項目可省略會議）。 8. DCC檢查： 1) 檢查關鍵文檔的輸出和存檔。 2) 發(fā)布檢查報告（按月發(fā)布，管理層審核）。 |
五、 變更管理流程
說明：需求變更涉及關鍵路徑時請遵守此流程，請更新《需求設計說明書》、《交互設計說明書》、并通知項目組所有成員和相應主管，涉及到代碼改動和用例改動的還需要重新進行開發(fā)時間評估，完成后遵照項目管理流程進行。
六、 項目管理制度
1.產(chǎn)品和設計文檔、技術文檔需要同步，開發(fā)人員根據(jù)文檔進行軟件設計，測試人員根據(jù)文檔進行軟件設計；
2.所有項目變更需要通知項目組所有成員以及相關主管；
3.項目開發(fā)過程中任何可能影響到項目進度的問題，需要主動告知項目經(jīng)理協(xié)調解決；
4.項目組成員以及成員項目角色的變更需要及時通知項目組成員，相關部門負責人有且僅有一個。
企業(yè)項目管理標準規(guī)范流程V3.0【干貨實例】
版權聲明：本文內容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。
