零壹移動互聯
需求管理制度（2.0版，2023年）
修改記錄
目錄第一章總則 3
第二章職責與分工 3
第三章需求總體說明 4
第四章需求提交 7
第五章需求評估 7
第六章需求開發 10
第七章系統測試 11
第八章需求上線 13
第九章生產問題管理 14
第十章需求變更控制與管理 14
第十一章需求進度監控及查詢 17
第十二章附則 17
第1條為規範零壹移動互聯（以下簡稱「零壹」）需求管理，明確各階段的工作內容、處理流程、參與人員以及相關干係人的職責，在保證需求質量的同時，提高需求實現效率，特制訂本制度。
第2條本制度適用於研發部的所有系統開發需求。
第3條本制度適用的讀者包括需求開發負責人、需求提交人員、需求評估人員、開發人員、測試人員、生產運維人員、專案管理員等。
第4條職責分工
第5條需求分類
按需求的提交部門可以分為研發部內部需求和業務部門需求。
按需求的內容可分為功能開發需求、平台**類需求、資料需求。
按需求的緊急程度可以分為緊急需求和普通需求。
按需求開發工時的大小可以分為大型需求、中型需求和小型需求。
第6條需求開發管理流程圖
需求開發管理流程為：
（建議由專案管理員統一管理需求）
需求管理主要包括以下內容：
需求的評估、開發、測試和上線階段的管理細則遵循本制度中相關規定。不涉及功能開發的平台類需求和資料需求可根據實際情況對需求開發管理過程的部分工作進行裁剪。
各階段包含的活動及流程請見以下各章節中的詳細描述。
第7條需求提交
為提高需求質量和處理效率，減少需求變更的次數，研發部各小組（開發、ui、測試）與產品部門就需求內容和實現方式等達成一致，可形成會議紀要存檔，並與《需求申請表》（或郵件的形式）同時提交需求審批。
需求提交前需確認的內容包括：
（一）與開發人員溝通，確定需求型別。
（二）需求的可行性分析。各部門\小組進行可行性分析時需關注的內容為：
1.研發部對需求的技術可行性進行初步分析，並幫助需求提交人員識別關聯系統。
2.需求關聯系統的歸屬開發人員就需求是否符合業務發展規劃，以及需求對系統中已有業務功能的影響進行評估。
3.產品部、開發人員、測試人員對需求的業務邏輯、風險、合規等進行初步評估。
第8條需求會簽
原則上中、大型專案或需求，需要通過會簽流程，徵求各部門相關同事或領導審批，審批通過方可進入到後續開發流程。此條制度視公司具體情況需要，靈活運用。
第9條需求評估流程
需求評估流程說明及職責分工：
（一）需求調研，需求文件完成開發後，產品經理需將需求提交至專案管理人員統一管理，專案管理人員需要將需求文件傳送至研發部想幹的各分部門會簽。會簽通過後組織需求評估會議。
（二）專案管理員審核相關要素，包括：參與會簽審批的干係人是否齊全，各干係人是否審批通過。
附：緊急需求另行處理（待完善，可劃分為業務需求、緊急需求、生產qc等三種型別）
（三）需求評估會上要評估的內容包括：
1.確認需求內容，分析需求合理性：需求開發負責人從技術層面對需求的技術可行性、效能等進行初步評估；測試部及其他相關產品部門從業務角度，對需求的業務邏輯、業務流程、業務目的、風險、合規等方面內容進行評估。
2.初步確認需求的實現方式。
3.初步評估需求的開發工作量。
4.明確需求系統設計、編碼、測試、上線階段的里程碑以及各階段的交付物和負責人。
5.確定需求評估結論。
（四）需求評估完成後，填寫《需求評估表》（待設計**），需填寫的內容包括：
1.不予開發或者有變更的事項；
2.該需求對其他關聯系統的影響；
3.需求所需人力、工時、里程碑以及整體評估結論等。
（五）評估表填寫完畢後，評估人員需當場簽字確認，專案管理員檢查需求評估表的資訊是否填寫完整、準確。
第10條需求評估考慮層面
需求評估主要從技術角度和業務角度進行考慮。
若需求評估通過，會後需求提交人員根據需求評估的結論更新需求，更新後的需求將作為研發部開發的最終依據（避免需求多次變更）。
若出現下列情形之一的，評估組出具意見後可退回需求至產品部重新更新需求或需要徵得各部門領導審批。
（1）技術層面
1.需對系統結構進行大規模改造的。
2.涉及系統架構變更的。
3.與其他需求有重複的。
4.需求中有不合理事項的。
5.需求不明確需做補充的。
6.當前技術無法實現的。
7.評估時發生重大變更，且變更審批未通過的。
（2）業務層面
1.與目前的業務操作流程、運營有矛盾的。
2.需大規模的更改原有的業務流程,增加大量人工後續處理成本。
3.業務需求與業務目的不符的。
4.新需求引起的新業務流程未在需求內一併體現的。
5.業務流程未理順,業務規則未明確或者沒有體現，有可能導致上線後,無法正常進行業務運作，或者存在運營風險的。
因以上原因被退回的需求，需求提交部門如對需求評估小組的評估結果存在爭議，可提交各部門領導進行仲裁。
第11條需求開發流程
（略，具體流程有開發部門制定）
第12條設計開發：需求評估通過後，由需求開發負責人安排、協調需求的設計和開發工作。
（一）開發人員根據需求評估會上通過的業務需求進行設計開發，同時完成《需求技術文件》。
（二）技術文件通過需求開發負責人的審核後，開發人員提交專案管理人員。此技術文件有必要從架構、環境、安全、效能等層面對技術文件進行評審，及時提出評審意見。
（三）專案管理員審核相關要素，包括：技術文件是否符合要求、評審人員參與度、是否評審通過。審核通過後需求進入開發階段。
如審核不通過，專案管理員將技術文件退回給開發人員，開發人員處理完畢後再提交相關干係人評審。
（四）技術文件評審通過後，開發人員將評審通過後的技術文件更新到svn中並開展開發工作。
緊急需求必須通過需求評估後，才可開展設計開發工作。設計開發階段的部分工作在專案管理員審批通過後，可根據實際情況進行裁剪。
第13條單元測試&整合測試
（一）編碼完成後，開發人員需進行單元測試、系統整合、編譯部署、及主功能測試。測試通過後編寫《單元測試報告》、版本部署操作文件，並提交需求開發負責人審核。
（二）需求開發負責人審核通過後，開發人員將源**、《單元測試報告》、版本部署操作文件更新到svn，需求開發負責人將《單元測試報告》、版本部署操作文件上傳到svn。
第14條系統測試：單元測試（包含系統整合）通過後進入系統測試階段，
系統測試流程為：
系統測試流程說明：
（1）需求開發負責人向專案管理員提交系統測試申請。
（2）專案管理員審核相關要素，包括：需求是否通過評估、技術文件是否通過評審、單元測試是否通過、《需求技術文件》、《單元測試報告》及版本部署操作文件是否上傳svn。審核通過後專案管理員向研發部質量管理部測試經理下系統測試通知單。
如審核不通過，返回開發子流程。
（3）測試經理分配系統測試人員。
（4）系統測試人員驗證svn中的技術文件、版本部署及需求主功能。驗證通過後制定測試計畫，如驗證不通過，返回開發子流程。
（5）系統測試計畫、測試案例、測試報告由系統測試人員編寫並組織評審，系統測試主管和需求開發負責人必須參加評審。
第15條需求上線：測試驗收工作結束後，進入需求上線
階段。需求上線主要分為業務上線、技術上線。
員工培訓管理制度V2
第一章總則 第一條 目的 根據湖北德力紙業 業務發展和組織能力提公升的要求，為規範和促進湖北德力紙業 培訓工作持續 系統的進行，逐步引導湖北德力紙業 職能部門以培訓需求為基礎，以實際效果為標準 提公升培訓質量。第二條 適用範圍 適用於湖北德力紙業 全體員工。第三條 檔案制訂依據 根據湖北德力紙業 的...
自營店財務管理制度 v2
一 本制度適用範圍 2 二 銷售管理 2 1 銷售業務操作要求 2 2 臨時調整銷售 2 3 門店 2 4 地鋪收款 2 5 地鋪銷售發票開具 3 6 顧客退貨 3 7 顧客換貨 3 8 用門店產品進行贊助 3 9 工服發放 4 10 門店 業務處理 4 11 從門店借樣品 4 三 貨品管理 4 1...
XZ 07考勤管理制度V2
編號 xz 07 考勤請假管理制度 第一章總則 第一條為維護公司正常的工作秩序，嚴肅工作紀律，保證良好的工作作風，結合 灃西新城管委會員工考勤管理暫行辦法 特制訂本制度。第二章考勤規定 第二條行政部負責考勤管理，每月月末最後一天將公司當月考勤情況彙總，經常務副總經理簽字後，報送管委會辦公室人事部門，...