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