Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

目录:

Table of Contents

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

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

问题表格链接如下:
东南亚
https://alidocs.dingtalk.com/spreadsheetv2/nl9VZGGEto1EAYYQ/edit?chInfo=im&utm_medium=im_card&utm_source=im&onlineEdit=true&docKey=meonaANvxg1jnXxj&dentryKey=nl9VZGGEto1EAYYQ&type=s 
中国
https://alidocs.dingtalk.com/i/nodes/oP0MALyR8k7Ap630toEzDr6983bzYmDO?iframeQuery=sheet_range%3Dst-e2ca1f37-59317_4_7_2_1 
分子公司
https://alidocs.dingtalk.com/spreadsheetv2/aqzJGPQzFvnEqMeW/edit?dentryKey=aqzJGPQzFvnEqMeW&dd_user_keyboard=false&dd_progress=true&dt_editor_toolbar=true 

目前识别出的较重大卡点/问题如下:
(详见表格链接):
https://alidocs.dingtalk.com/spreadsheetv2/jOg9E00AiQOzr28e/edit?dentryKey=jOg9E00AiQOzr28e&dd_user_keyboard=false&dd_progress=true&dt_editor_toolbar=true&sheet_range=s1_0_0_1_1

系统迭代更新记录:

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

产品驱动机制

一.目标:

从产品经理接收业务需求后进行开发的流程转变为产品和业务共同提出需求,实现从需求到产品的转化。实现技术驱动业务,引领业务发展

二.策略:

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

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

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

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

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

产品需求管理

一、优先级划分:

...

IT信息部需求管理方案及相关说明

IT Information Department Requirements Management Plan and Related Guideline

一、需求管理模板(Demand Management Template):

* 注:当前需求管理统一由IT信息部收口管理,需求与问题管理表单如下,请点击以下链接:

Note: The current requirements management is centrally overseen by the IT Information Department. The requirements and issue management forms are as follows. Please click the link below:

点击(Click):HERP4.0业务需求管理表(HERP4.0 Requirements Form)

二、产品驱动机制(Product Manager-Driven Mechanism

1.目标(Objective):

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

Transform the development process from passively receiving business requirements from product managers into a collaborative effort where both product and business propose demands,enabling end-to-end translation from requirements to product.

2.策略(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 into product roadmaps..

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

Product Iteration: Align product lines with performance metrics, then collaboratively prioritize feature planning and iteration across all product lines to achieve strategic objectives.

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

1、优先级划分(Prioritization):

Image Added

...

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

    1. 重要性的标准

  2. :是否为公司战略业务、预计创造的量化价值(或如果缺失的损失金额)
    1. :是否为公司战略业务、预计创造的量化业务价值(或如果缺失的损失金额),

  3. 业务阻断性、流程完整性
    1. 业务阻断性、流程完整性,对外合作影响范围涉及品牌形象此类;

    2. 紧急性的标准:如果延迟30天、60天,对业务的量化影响;

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

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

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

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

二、总体流程:

  1. 需求提出:由专属产品经理和业务负责人共同提出,提需求时即包括重要紧急的量化分析;
  2. 开发量评估:由专属产品经理和开发人员共同估算;
  3. 基于以上两项,形成优先级顺序,形成开发计划;
  4. 每周度review计划的进展和优先级调整;(周例会)
  5. 形成月度或季度需求台账;

需求管理全过程管理

(* 注:根据项目或需求适当剪裁 )


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

2.Categorized into A, B, and C based on workload:

3.Workload is estimated collaboratively by product managers and development teams.

4.Optimization Priority:

...

2、总体流程(Overall Process):

2. Overall Process:


...

四、需求&Bug的定义与规范(Definition and Standards for Requirements & Bugs

访问地址(Access Address:):https://wiki.hiseas.com/x/mQC1AQ

...

五、需求对接人(Requirement Contact Person

业务业务线/部门
负责人人需求对接人产品经理
目的地管理销售-国内地接成都/重庆销售办尹钧单团-叶星辰;散拼-孙绍光张云龙
广州/武汉销售办单团-方燕娟;散拼-李乐怡张云龙
上海/杭州销售办单团-周烨玮;散拼-严彩红张云龙
北京/沈阳销售办王嘉程张云龙
渡凡旅游
林潇君(产假)、宋伟和王彦明张云龙
销售-海外地接泰国销售办(Thailand Sales Office)Puff泰国总监-R、泰国代表-Steven张敏张云龙(keyen)
马来西亚销售办(Malaysia Sales Office)马来西亚总监-Ben
马来西亚代表-Margo
中东非销售办(Middle East and Africa Sales Office)中东非代表Flora、韦海月
越南销售办(Vietnam Sales Office)越南代表-Zoe李祎
印尼销售办(Indonesia Sales Office)Patrick Huang
海外销售二组(兰州)(Overseas Sales Group 2 (Lanzhou))薛润萍Nancy、权小圣
海外销售一组(兰州)(Overseas Sales Group 1 (Lanzhou))海外销售一组-Crystal、Michelle
操作中心-成都
Mango李根辛海
操作中心-兰州
Alina李根辛海
地接-中东非
FloraFlora辛海
地接-意大利
lunaluna辛海
地接-巴尔干
张杰
辛海
地接-北冰
王玮玢Carrie(付晓静) , 李涵;辛海
地接-希腊
沈洁沈洁辛海
地接-日本
Koko
辛海
地接-美国
王凯王凯辛海
地接-英国
崔国晨崔国晨辛海
地接-意大利
谢海瓯谢海瓯辛海
地接-西班牙
钟敏芝钟敏芝辛海
地接-德国
阳鹤阳鹤辛海
地接-法国
高铭高铭辛海
OTA
秦伟秦伟辛海
景点门票
LeonLeon辛海
瑞士酒店
NeferNefer辛海
入境-欧洲
魏巍魏巍辛海
入境-东南亚
CindyCindy辛海
出海众赢
伊立峰伊立峰辛海
企业项目
李明昊李明昊辛海
地接-渡凡
王楠王楠辛海
职能财务
孙丹祝小莉康君
法务
杨一棵杨一棵杨瑞
人事
曾汇杨烁宇许丹丹
经管
Ada邱璐唐靖凯

需求管理全过程管理

阶段

检查项目

详细描述

需求输入

1. 来源可靠性

需求是否来自客户、市场调研、业务部门或其他正规渠道,是否有足够的依据和可靠性。

2. 充分和准确性

需求是否描述清楚,是否完整覆盖了所有有价值的需求信息,如需求的功能、性能、安全等等,是否准确无误。

3. 可行性和可实现性

需求是否能够实现,是否需要进一步的研究和分析,是否具有实现的可行性。

4. 普适性和标准合规性

需求是否符合相关标准和规范,是否是产品和服务可扩展的。

5.⭐️ 目标性和实用性

需求是否符合产品和业务目标,是否具有实际价值和可用性。(业务价值分析)

6. 可跟踪性和可管理性

需求是否能够被有效地跟踪和管理,是否有足够的指标和标准来进行跟踪。

7. 优先级和紧急程度

需求是否具有优先级和紧急程度,是否需要进行排序和重点关注。

8. 规范性和记录整理

需求输入是否符合产品需求管理规范,是否有足够的模板和记录档案来支持验证和管理,以及整理形成完整的记录。

需求检查

1. 需求战略一致性

提出的需求是否符合产品定位和战略规划。

2. 需求体验性

需求是否可能造成客户/用户体验下降。

3. 需求冲突性

需求实现是否会对现有功能造成冲突。

4. 需求重复性

需求是否与已有需求存在重复或相似之处。

5. 规范性

需求数据格式、定义是否规范正确。

6. 需求可拆分性

需求是否可被拆分为多个子需求。

7. 需求合规性

需求在法律合规性方面是否有风险。

需求分析

需求分析模型

1. 功能性和性能要求

对需求描述中所涉及的各项功能和性能要求进行详细的分析,以确立具体的实现方案。

2. 用户和场景分析

对所需求相关的用户类型、使用场景、需求来源和喜好进行分析,以便对需求进行更精准的定义和拆解。

3. 技术可行性和设计可行性

对所需求的技术方案进行分析评估,以确定实现方案和设计方案是否可行、是否符合产品的技术设定和架构。

4. 通用性和扩展性

对所需求涉及的通用性和扩展性进行分析,以便在设计阶段考虑扩展性的需求,以及如何保证通用性的需求。

5. 成本和人力资源评估

对所需求的实现所需的成本和资源进行评估,以便制定实际可行的计划和方案,并在产品设计、研发和运营中合理地考虑成本和人力资源的管理。

6. 风险评估

对所需求涉及的技术方案、人员、时间、预算等不确定因素进行评估,以及对实现和商业风险进行分析,以便制定相应的应对方案。(风险登记册

7. 需求标签和分类

对需求进行标注和分类,以方便在后续的计划和实施过程中进行跟踪和管理。

8. 与其他需求间的关系

对需求与其他需求之间的关系进行分析和评估,以确保需求的整体一致性和高度聚合性。

需求评审

1. 完整性和一致性

需求描述是否完整覆盖了所有有价值的需求信息,是否与其他相关需求相互一致。

2. 清晰度和明确性

需求的描述是否明确,是否不含任何二义性,是否需要进一步详细说明。

3. 准确性和规范性

需求描述是否准确无误,符合产品和服务的相关标准和规范,是否符合产品需求管理规范。

4. 可行性和风险评估

需求是否可行,是否需要进一步的研究和分析,是否具有一定的风险,如技术实现难度等。

5. 实用性和用户价值

需求是否具有实际价值和可用性,是否满足了用户的需求,是否符合市场需求的变化。

6. 优先级和紧急程度

需求是否具有合理的优先级和紧急程度,是否需要进行排序和重点关注。

7. 可跟踪性和可管理性

需求是否能够被有效地跟踪和管理,是否有足够的指标和标准来进行跟踪。

8. 记录整理和筛选

需求检查过后需要将有效、可行的的需求整理成清单的形式进行筛选,形成可实施的计划。

争议处理

1. 争议来源和背景

要了解争议的来源和背景,例如对于核心业务功能、创新点、战略目标等是否存在争议。

2. 争议关键点和主张

确定争议所涉及的具体点和与会者的主张,了解争议的差异和背后的原因。

3. 文档和证据准备

要准备相应的文档和证据,以便明确提出主张和支持理由,并为工作会议做好充分的准备。

4. 参与者和决策机构

要确定有关参与者和决策机构,以确保争议的处理和决策过程具有合法性和风险控制。

5. 引导和推动协商

通过合理的引导、协商和讨论,使争议变为真正的合作机会,并能够就具体方案达成一致的认识。

6. 技术实现和成本评估

对所涉及的技术方案进行技术评估和成本评估,以确保争议最终决策所选方案的可行性和可持续性。

7. 风险评估和规划

对所涉及的风险进行评估和规划,以确保争议所选方案的风险控制、防范和预防。

8. 需求确认和管理

最终确认和管理所选方案中所涉及的需求和责任,确定实现和管理的重点和关键时间点,并进行相应的规划和跟踪。

计划排期

1. 需求优先级

评估需求的优先级,并根据其优先级确定具体实施的时间表和截止日期。

2. 项目资源

评估项目所需的各种资源,包括人员、设备和材料等,并确定它们在什么时间可用。

3. 风险评估

识别可能延迟或妨碍实现项目目标的风险和障碍,并采取相应措施进行控制和规避。(风险登记册

4. 进度追踪和管理

设置项目进度和里程碑,并确保它们与实际进展保持一致。及时跟踪进度,并在需要时进行重新调整。

5. 依赖关系

确定项目中不同需求和任务之间的依赖关系,确保它们之间的关系合理、有效和稳定。

6. 可行性和可持续性

评估项目实施的可行性和可持续性,并根据所需的资源和时间表制定相应的可持续性方案。

7. 人员管理和分配

根据项目需求和资源评估确定所需的人员,并进行合理分配和管理。

8. 成本和预算

评估项目实施所需的成本和预算,并确保其在界面内得到合理的支持。进行项目开销的跟踪、报告和管理。

需求反馈和复盘

1. 用户反馈

收集用户的反馈和建议,对用户的需求进行重点分析和处理,以便调整产品设计和功能。

2. 处理优先级

根据收集到的反馈和建议,评估其对产品的影响和重要性,确定所需的优先处理级别。

3. 设计调整

基于用户反馈和建议进行设计调整,改善产品功能、界面和用户体验,以及识别和修复缺陷和漏洞。

4. 需求复盘

在开发和实施阶段,对需求的实现情况进行定期复盘,以确保产品需求与用户需求的一致性和产品质量。

5. 意见收集

搜集相关人员的意见和建议,以便改进需求管理和产品开发的流程和方法。

6. 项目更新

对产品需求和项目进展的更新和公告,以便相关人员了解产品状态和开发进度。

7. 测试和验证

对需求的实现进行测试和验证,评估其对产品质量和用户体验的影响。

8. 问题解决

跟踪和解决在需求实现过程中的问题、错误和差错,以便改进产品质量和需求管理的流程和方法。