目录：

4.0上线初期需求&问题管理文档：

* 注：鉴于系统上线初期，暂时使用下表管理各渠道系统使用过程反馈，预计在Q1完成1期系统反馈初步收尾后，由IT信息管理部统一收口需求，另行发布统一需求&问题收反馈通道。

HERP4.0业务原始需求收集表2025：https://alidocs.dingtalk.com/i/nodes/m9bN7RYPWdlGx6mzCvxgx5P3WZd1wyK0?utm_scene=person_space&iframeQuery=viewId%3DrmVnkPC%26sheetId%3DuOMOceA

4.0系统迭代计划&历史记录：

https://wiki.hiseas.com/x/04sNAQ

产品驱动机制（Product Manager-Driven Mechanism）

一．目标（Objective）：

从产品经理接收业务需求后进行开发的流程转变为产品和业务共同提出需求，实现从需求到产品的转化。

Transform the development process from receiving business requirements from product managers into a collaborative effort where both product and business propose demands, achieving the conversion from requirements to product.

二．策略（Strategy）：

1.     深度理解战略，知道公司总体目标。

Deep Understanding of Strategy: Gain a comprehensive understanding of the company's overall goals.

2.  深度理解业务：将公司的总体目标拆解到系统产品中，跟产品进行融合。

Deep Understanding of Business: Decompose the company's overarching goals into system products and integrate them with product development.

3.  产品迭代：通过业绩目标融入产品线后，产品和业务业务一起梳理为了实现公司战略目标，应该在这所有产品线上规划与迭代哪些功能。

Product Iteration: After incorporating performance objectives into the product line, product and business teams collaboratively plan and iterate on functions across all product lines to achieve the company's strategic goals.

4.  产品落地：将分析出的需求进行拆分按照重要性，紧急程度，研发预估排期进行排期后交付给研发开发进行MVP版本快速迭代，快速试错。

Product Delivery: Break down the analyzed demands based on importance, urgency, and R&D timeline estimates. Deliver these to R&D for MVP (Minimum Viable Product) iterations to facilitate quick testing and adjustments.

5.  上线后复盘：产品功能上线后，产品和业务一起跟进产品上线后效果，并进行优化迭代。

Post-Launch Review: After product functions are launched, product and business teams jointly track post-launch performance and carry out optimization and iteration.

产品需求管理（Product Requirement Management）

一、优先级划分（Prioritization）：

1. 根据重要紧急，划分为P0\P1\P2\P3；

   1. 重要性的标准：是否为公司战略业务、预计创造的量化业务价值（或如果缺失的损失金额）,业务阻断性、流程完整性，对外合作影响范围涉及品牌形象此类;

   2. 紧急性的标准：如果延迟30天、60天，对业务的量化影响；

   3. 据此分为：P0-重要且紧急、P1-重要不紧急、P3-紧急不重要、P4-不重要不紧急 四个级别；

   4. 需求由产品经理和业务线共同提出，必须回答以上量化的问题；

2. 根据开发的工作量从少到多，分为A、B、C，A为工作量最少、C为最多，工作量由产品和开发同事计算；

3. 根据P0\P1\P2\P3和ABC，设定优化级顺序，最优先为P0A（低垂的果子）、最滞后为P3C（投入大效果低）

1. Priority Levels: Requirements are categorized into P0, P1, P2, and P3 based on importance and urgency:

• Importance Criteria:

  • Alignment with company strategic goals.

  • Quantifiable business value it is expected to generate (or loss amount if missing).

  • Business disruption, process completeness, and impact on external partnerships or brand image.

• Urgency Criteria:

  • Quantifiable business impact if delayed by 30 or 60 days.

• Priority Levels Explanation:

  • P0: Important and urgent.

  • P1: Important but not urgent.

  • P3: Urgent but not important.

  • P4: Neither important nor urgent.

• Requirements must be jointly proposed by product managers and business lines, with quantified answers to the above criteria.

• Development Workload Classification:

• Categorized into A, B, and C based on workload:

  • A: Minimal workload.

  • C: Maximum workload.

• Workload is estimated collaboratively by product and development teams.

• Optimization Priority:

• Prioritization is determined by combining priority levels (P0, P1, etc.) with workload classifications (A, B, C).

• The highest priority is P0A (low-hanging fruit), while the lowest priority is P3C (high input, low impact).

二、总体流程（Overall Process）：

1. 需求提出：由专属产品经理和业务负责人共同提出，提需求时即包括重要紧急的量化分析；

2. 开发量评估：由专属产品经理和开发人员共同估算；

3. 基于以上两项，形成优先级顺序，形成开发计划；

4. 每周度review计划的进展和优先级调整；(周例会)

5. 形成数据看板；

II. Overall Process:

1. Requirement Submission: Requirements are jointly proposed by the designated product manager and business owner, accompanied by a quantitative analysis of importance and urgency at the time of submission.

2. Development Effort Evaluation: Development workload is estimated collaboratively by the designated product manager and development team.

3. Prioritization and Development Plan: Based on the above two steps, prioritize requirements and create a development plan.

4. Weekly Review: Progress and priorities are reviewed and adjusted weekly during the regular meetings.

5. Demand Ledger: Create a monthly or quarterly demand ledger to track requirements.

需求&Bug的定义与规范（Definition and Standards for Requirements & Bugs）

访问地址（Access Address:）：https://wiki.hiseas.com/x/mQC1AQ

需求对接人（Requirement Contact Person）