需求管理

需求管理是指以用户为中心，以用户的需求为出发点，集中精力来估计和管理用户需求，并试图利用该信息制定生产决策，以实现用户效用最大化的一种活动。对这一定义的理解要注意以下两点:(

需求管理

• 历史需求零散度分析
  • 需求分析统计
    • 取样
      • TAPD
    • A需求
      • 0~1人天工时需求占比：46.15%
      • 仅产品需求
    • B需求
      • 0~1人天工时需求占比：39.88%
      • 仅产品需求
    • C需求
      • 0~1人天工时需求占比：46.08%
      • 仅产品需求
    • D需求
      • 0~1人天工时需求占比：37.24%
      • 包含产品&技术需求
        • 产品占比：24.07%
        • 技术占比：62.96%
        • 项目占比：15.74%
        • 测试占比：2.78%
    • E需求
      • 0~1人天工时需求占比：54.51%
      • 包含产品&技术需求
        • 产品占比：33.07%
        • 技术占比：67.69%
        • 项目占比：4.62%
        • 测试占比：1.15%
  • 建议优化方案
    • 产品需求
      • 产品人员
        • 产品需求建立内审逻辑
          • 去除伪需求
          • 合并需求
          • 确定优先级
          • 所有需求必须由产品Leader进行内审
        • 制定产品Leader职责DOD
          • 作为零散需求第一道收口
      • 技术&测试&项目人员
        • 需求评审
          • 针对研发预估工时在1人天以下的需求，技术&测试&项目同学要有“拒绝”意识
          • 客观评估该需求的价值和紧急程度
          • 是否直接打回，请产品再重新规划；如果可以，并给予产品更好的规划建议
        • 作为零散需求第二道收口
    • 技术需求
      • 零散处理方案
        • 技术需求统一由Leader负责创建，具体开发同学无创建需求权限
        • 项目同学&测试同学无创建需求权限
        • 按项目、功能进行技术优化方案的整合梳理，由Leader负责，如涉及到其他组，由Leader主动对接沟通
        • 各组的技术需求由技术Leader评估其重要性，给出各组明确的优先级，在完成重点产品需求基础上预留人力完成
        • “团级会议”进行确认各组技术需求情况
      • 制定技术组长职责DOD
        • 从组长抓起，明确组长的职责
        • 组长带头，不断改变团队氛围
• 需求分类
  • 需求来源
    • 产品方获取
      • 行业研究
      • 调研问卷
      • 实习轮岗
      • 数据分析
      • 现场访谈
    • 客户方反馈
      • 客服咨询
      • 用户投诉
      • 公开渠道评价
    • 业务方提出
      • 资金
      • 风控
      • 贷后
      • ……
  • 需求分类
    • 业务需求
      • 资金
        • 资金接入
        • 担保项目
        • 监控告警
        • 资金运营
        • 资金转化
      • 信贷
        • 营销运营
        • 核心流程
        • 权益
        • API渠道
        • 加复贷
      • 贷后
      • 风控
      • 电销
      • 财务
      • 合规
    • 产品需求
      • 新功能
      • 功能优化
      • 埋点
      • 数据统计
    • 技术需求
      • 系统重构
      • 功能重构
      • 性能优化
      • 监控优化
  • 需求预估颗粒度
    • Xs
      • 开发工时0.5人天及以下
    • S
      • 开发工时0.5~1人天（包含1人天）
    • M
      • 开发工时1~5人天（包含5人天））
    • L
      • 开发工时5~10人天（包含10人天）
    • Xl
      • 开发工时10人天以上
• 需求TAPD模板
  • 分三类模板类型
    • 产品需求
    • 技术需求
    • 数据统计需求
  • 创建需求时可选择对应的分类，然后每个分类有自己的流转流程
• 需求定义（描述）
  • 需求范本
    • 业务侧内部学习
    • 技术侧也需进行相关培训？
  • 需求内审
    • 产品内审的基本标准
      • 去除伪需求
        • 需求场景还原
          • 需求筛选的第一步，如果还原不了则是假需求，场景还原要问几个问题，能回答出来且逻辑自洽即可
          • 谁（角色）在什么情况（背景）下，遇到了什么问题（需求）？当前的处理方法是什么？
          • 场景还原需要将相关场景进行穷举，避免因场景遗漏导致后续产品设计时出现漏洞
          • 需要注意的是，有的需求场景还原完整，但不符合本产品定位，此类需求对本产品无价值，但需求本身没问题，该需求可以作为外延产品的需求储备
      • 规划合并需求
      • 确定优先级
    • 制定产品Leader职责DOD
      • who
      • How to
• 需求迭代节奏
  • 版本迭代机制建立
  • 迭代内需求优先级机制建立
    • 优先级必须1~N
    • 优先级评估机制
      • 重要
        • 商业价值
        • 用户价值
      • 紧急
        • 分6类
        • P0的Bug、P1（重要紧急）、P2（紧急不重要）、P3（重要不紧急）、P4（不紧急不重要）、伪需求
  • 建立固定的需求评审节奏
    • 需求统一评审
    • 减少被打扰时间
    • 团队不断形成默契配合
• 需求评审
  • 需求预评审
    • 开发Leader提前安排该需求具体的开发人员
    • 提前查看与消化需求，带着问题进行需求评审
      • 一般不做会？即使预留时间
      • 技术团队内部要提前进行一轮需求提前查看，并进行内部初评估
    • 颗粒度预评审
  • 产品需求准入
    • 产品目标
      • 定期目标对齐
        • 季度目标
        • 月度目标
        • 周目标？
      • 评估一个需求是否好坏的基本标准：满足产品既定目标
      • 在既定目标下，需求预计收益
    • 线上问题修复
    • 响应性需求
      • 运营需求
      • 业务需求
    • 颗粒度控制（预估工时）
      • Xs~Xl
      • 在建立定期固定的需求评审的前提下，在产品发了需求出来之后，技术团队内部要提前进行一轮需求提前查看，并进行内部初评估
      • 目前没有固定的需求评审节奏
        • 产品至少提前1天发需求邮件
        • Leader分配具体的开发、测试同学
        • 在需求评审前完成需求查阅，并各自记录问题
        • 需求评审之前，该需求开发测试进行内部预评审（可非正式会议））
        • Leader负责制
  • 建立固定的需求评审节奏
    • 降低需求零散评审次数
    • 团队形成固定的工作节奏
  • 需求场景还原？
  • 量化评估
    • 需求价值量化？
      • 潜在用户数*转化率*使用频次*用户价值-关联指标的负面影响
      • 感觉目前不合适
    • 需求性价比
      • 需求的性价比：基于高价值的需求再计算对应的成本最终根据性价比排序；
      • 人力成本=所需人天*人天费用；
      • 性价比=需求价值/人力成本
      • 感觉目前不合适
• 需求过程管控
  • 需求变更管控流程
• 需求验收
  • 上线需求当天完成验收
    • 包含产品&技术需求
    • 非条件限制必须当天完成验收
  • Leader（产品&技术）负责制
    • 上线当天Leader同步一起参与
      • Leader要知晓当天上线需求整体情况
      • Leader要确保当天上线需求完成验收
    • Leader确认没有问题后，组内成员方可离开
    • 作为Leader职责DOD的一部分
• 需求回顾分享会
  • 各业务线按月组织已上线需求收益分享会
    • 业务需求
    • 产品需求
    • 技术需求
  • 下个月的月度规划会
    • 业务
    • 产品
    • 技术