需求管理制度V2.0

零壹移动互联

需求管理制度（2.0版，2015年）

修改记录

-1-

目录

第一章总则 (3)

第二章职责与分工 (3)

第三章需求总体说明 (5)

第四章需求提交 (7)

第五章需求评估 (7)

第六章需求开发 (10)

第七章系统测试 (11)

第八章需求上线 (13)

第九章生产问题管理 (14)

第十章需求变更控制与管理 (14)

第十一章需求进度监控及查询 (17)

第十二章附则 (17)

-2-

第一章总则

第一条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制订本制度。

第二条本制度适用于研发部的所有系统开发需求。

第三条本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。

第二章职责与分工

第四条职责分工

-3-

-4-

第三章需求总体说明

第五条需求分类

按需求的提交部门可以分为研发部内部需求和业务部门需求。

按需求的内容可分为功能开发需求、平台网站类需求、数据需求。

按需求的紧急程度可以分为紧急需求和普通需求。

按需求开发工时的大小可以分为大型需求、中型需求和小型需求。

-5-

第六条需求开发管理流程图

需求开发管理流程为：

（建议由项目管理员统一管理需求）

需求管理主要包括以下内容：

-6-

需求的评估、开发、测试和上线阶段的管理细则遵循本制度中相关规定。不涉及功能开发的平台类需求和数据需求可根据实际情况对需求开发管理过程的部分工作进行裁剪。

各阶段包含的活动及流程请见以下各章节中的详细描述。

第四章需求提交

第七条需求提交

为提高需求质量和处理效率，减少需求变更的次数，研发部各小组（开发、UI、测试）与产品部门就需求内容和实现方式等达成一致，可形成会议纪要存档，并与《需求申请表》（或邮件的形式）同时提交需求审批。

需求提交前需确认的内容包括：

（一）与开发人员沟通，确定需求类型。

（二）需求的可行性分析。各部门\小组进行可行性分析时需关注的内容为：

1.研发部对需求的技术可行性进行初步分析，并帮助需求提交人员识别关联系统。

2.需求关联系统的归属开发人员就需求是否符合业务发展规划，以及需求对系统中已有业务功能的影响进行评估。

3.产品部、开发人员、测试人员对需求的业务逻辑、风险、合规等进行初步评估。

第八条需求会签

原则上中、大型项目或需求，需要通过会签流程，征求各部门相关同事或领导审批，审批通过方可进入到后续开发流程。此条制度视公司具体情况需要，灵活运用。

第五章需求评估

第九条需求评估流程

-7-

需求评估流程说明及职责分工：

（一）需求调研，需求文档完成开发后，产品经理需将需求提交至项目管理人员统一管理，项目管理人员需要将需求文档发送至研发部想干的各分部门会签。会签通过后组织需求评估会议。

（二）项目管理员审核相关要素，包括：参与会签审批的干系人是否齐全，各干系人是否审批通过。

附：紧急需求另行处理（待完善，可划分为业务需求、紧急需求、生产QC等三种类型）（三）需求评估会上要评估的内容包括：

-8-

1.确认需求内容，分析需求合理性：需求开发负责人从技术层面对需求的技术可行性、性能等进行初步评估；测试部及其他相关产品部门从业务角度，对需求的业务逻辑、业务流程、业务目的、风险、合规等方面内容进行评估。

2.初步确认需求的实现方式。

3.初步评估需求的开发工作量。

4.明确需求系统设计、编码、测试、上线阶段的里程碑以及各阶段的交付物和负责人。

5.确定需求评估结论。

（四）需求评估完成后，填写《需求评估表》（待设计表格），需填写的内容包括：

1.不予开发或者有变更的事项；

2.该需求对其他关联系统的影响；

3.需求所需人力、工时、里程碑以及整体评估结论等。

（五）评估表填写完毕后，评估人员需当场签字确认，项目管理员检查需求评估表的信息是否填写完整、准确。

第十条需求评估考虑层面

需求评估主要从技术角度和业务角度进行考虑。

若需求评估通过，会后需求提交人员根据需求评估的结论更新需求，更新后的需求将作为研发部开发的最终依据（避免需求多次变更）。

若出现下列情形之一的，评估组出具意见后可退回需求至产品部重新更新需求或需要征得各部门领导审批。

（一）技术层面

1.需对系统结构进行大规模改造的。

2.涉及系统架构变更的。

-9-

3.与其他需求有重复的。

4.需求中有不合理事项的。

5.需求不明确需做补充的。

6.当前技术无法实现的。

7.评估时发生重大变更，且变更审批未通过的。

（二）业务层面

1.与目前的业务操作流程、运营有矛盾的。

2.需大规模的更改原有的业务流程,增加大量人工后续处理成本。

3.业务需求与业务目的不符的。

4.新需求引起的新业务流程未在需求内一并体现的。

5.业务流程未理顺,业务规则未明确或者没有体现，有可能导致上线后,无法正常进行业务

运作，或者存在运营风险的。

因以上原因被退回的需求，需求提交部门如对需求评估小组的评估结果存在争议，可提交各部门领导进行仲裁。

第六章需求开发

第十一条需求开发流程

（略，具体流程有开发部门制定）

第十二条设计开发：需求评估通过后，由需求开发负责人安排、协调需求的设计和开发工作。

（一）开发人员根据需求评估会上通过的业务需求进行设计开发，同时完成《需求技术文档》。

（二）技术文档通过需求开发负责人的审核后，开发人员提交项目管理人员。此技术文档有

-10-