需求台账

目的

本制度在于通过对传统研发活动（非 MSF）建立需求台账，对产品线和平台的“传统研发活动”的需求管理进行管控，以帮助团队顺利迁移到 MSF 研发模型。

范围

  • 缺陷（BUG）不在本制度范围内。
  • MSF 需求管理不在本制度范围内。

背景

我们研发团队每天每周的需求不少，呈现出一种零零碎碎持续不断的状态，对应地，我们的研发团队也长期处于零零碎碎持续不断研发的局面，团队主要精力也都是在应付这些零碎需求（还有它们产生的 BUG），这其实是不太正常的！虽然从客户那里来的需求的确可能是零碎的、持续的，但是健康的研发活动应该是有一定预见性的、有计划的、主要处于有规律的研发活动周期的，对当下的我们而言，就是应该主要处于 MSF 研发模型的工作流控制内的。

但是眼下， MSF 刚刚推广，大量的研发活动还是处于传统研发模式。不幸的是我们认识到，如果对这些的传统模式研发活动加以管控，我们的团队并不能自觉地迁移到 MSF 模型中去。因此本制度的目的就在于对传统研发活动施加适当控制，以便尽快地完成整个公司的研发活动向 MSF 模型迁移。我们希望通过一段时间的努力，形成这样的局面：

  1. 大量的细碎需求，变成了可以通过修改配置和脚本的二次开发，从而在本名单中剔除。
  2. 产品侧在商务上的密切配合，完善产品规格，避免研发资源的浪费。
  3. 通过对这些需求的管控，尽早形成符合 MSF 要求的数字资产，从而方便今后将这些资产合并到 MSF 研发模型中。
  4. 把主要的研发活动都转移到 MSF 团队，类别的意思就是“从零碎不断的研发”到“有计划的批量研发”。

要求

  1. 每个产品线有且有一个此表。各个产品线和平台，都要建立此台账。各个产品线（平台）有且只有一份此台账。
  2. 全面收录，无遗漏。各个产品线的非 MSF 项目的需求活动都必须登录在这个表中。（MSF 项目的需求，则必须进入 SRS ，并按照 MSF 流程进行审核）
  3. 需求备案制。此制度体现了需求管理备案制的思想，备案并不意味着审核，具体地说：1) 产品线必须履行全面备案职责；2) 总监们自主决定是否对特定需求发起适宜的管理活动。
  4. 实现为微文档。建议使用“微文档”实现这个表，以便于大家共享，而且让总监们直接填写此表。
  5. 产品侧意见要在研发侧之前收集。

关于表的具体说明

表格分为四个模块：功能规格、项目管理、产品侧意见和观点、研发测意见与观点，还有一个可选模块：评审意见。具体条目如下：

  • 需求名称 此列是该需求的名称。
  • 产品名称 此列请填写一个产品线登记在册的规范产品名称。（以此推进产品线规范地管理产品族！）

  • 三级规格 此列请填写该需求对应的一二三级规格名称。这说明我们是以三级规格的颗粒度来的进行需求管理的。如果用户提出的功能需求的颗粒度太粗，比如：某用户提出了一个比较复杂的功能，它是一个二级规格，且需要细化为一系列的三级规格才能实现这完整的功能。那么，这时我们就要在表格中每行对应一个三级规格地填写，而不是把整个二级规格写到一行。另一方面，如果用户的需求过细，这里我们就填写其对应的三级规格名称。

  • 提出时间 此列请填写首次提出该需求的时间。团队从这个时间开始思考并调研是否去实现这个功能需求，而不是已经做出了决定要实现它的时间。

  • 进度状态 填写者需要从下列多个状态中选一个：
    1. 需求调研
    2. 市场侧审核
    3. 无需方案直接编码
    4. 方案初版
    5. 方案一审
    6. 方案二审
    7. 方案三审
    8. 依方案编码
    9. 测试验真中
    10. 需求结案
    11. 需求取消
  • 产品侧意见于观点-产品线 产品线的产品侧人员，包括：应用工程师、产品经理、产品部经理，从市场和产品类别角度给出自己的详细意见和观点。之所以提出“详细”，是因为没有其它文档记录这些信息，所以要详细些。
  • 产品侧意见于观点-产品总监 产品总监从市场和产品类别角度给出详细评审意见和观点。同上。
  • 研发侧意见于观点-产品线 产品线的研发侧人员，包括：架构师、软件工程师、测试工程师、产品线总工，从技术角度给出意见和观点。之所以这里没有提出“详细”，是因为可能有《设计方案》已经阐述了详细信息，那么这里记录要点即可；但是，文档中没有的信息，例如研发总监的评审意见，还是要写详细的。
  • 研发侧意见于观点-研发总监 产品总监从技术角度给出的详细评审意见和观点。因为在此刻评审意见没有其它技术文档来记录，所以还是要写详细的。