需求决策RMT

RMT = requirement management team ,需求管理团队

首先我基于公司当前的实践谈下RMT，后续再基于业界再看下有什么区别以及外部好的实践

RMT会议目的：通过RMT会议决策需求优先级，确保是经过各方代表共同决策的，决策在有限的资源和时间做正确的事

RMT成员： 产线主管、规划主管、研发主管、架构师、MO代表、市场行销代表、交付代表、质量代表（若有）、硬件代表（若有）

RMT决策会分为立项RMT决策会和版本RMT决策会

立项RMT决策整个立项周期核心需求（需求池中选择）

版本RMT决策整个版本周期需要真正实际落地的需求（细化到系统需求力度，钻石级需求），大的核心需求已经在立项确定，其他技术需求和质量需求需要在

先看下版本RMT流程

实际上在立项已经做过几次RMT （需求粗选、需求优选），在立项的时候其实已经圈定整个立项周期核心的关键价值需求，那么每次版本RMT实际上关键价值需求点基本上是已经明确的（需要决策圈定的关键价值里面的需求优先级），需要决策的应该是市场洞察新增识别的紧急需求（这种应该要少）、质量需求以及技术需求等

下面我们细细来讲下每个活动，在开第一次版本RMT1（需求范围）之前实际上应该是在规划内部，规划和研发已经初步对齐清楚，并且预研识别（非重大预研，重大预研应该在立项前已经识别并结项消除）。这个地方是之前期望研发粗估工作量，但是后续发现不太可行（改成了每个特性小组评估不多于4个需求，这个改进也挺好的。当然这个是根据开了几次RMT得出结论，这个与需求颗粒度以及开发容量有关系）特性小组一般是不多于8人，敏捷迭代开发周期1个月（其中3个星期开发周期，1个星期上主线时间）

规划内部应该讨论清楚需求可以解决客户什么问题，客户当前现状是什么样的，给客户带来什么价值，解决问题目标客群是哪些，规划回答清楚几个问题后，内部要对此版本需要做的需求内部形成初步结论。TL可以参与到规划结论性讨论，提前了解需求，同时需要识别预研项和技术风险。

RMT1-RMT2之间需要细化用户需求（PD）和系统需求（TL/PD/PM），如果TL未参与RMT1前的讨论，那么再开完RMT1后，最佳实践是由规划给研发（TL、PM）讲解下决策需求范围，让TL能够更好的理解需求，开展后续工作

版本第二次RMT2（决策钻石级需求）是最终明确可落地版本的需求（无偏差），基于系统需求评估后的工作量进行需求决策，与RMT成员同步

RMT运作时间周期： 可以一个月一次，同时召开下一个版本的RMT2和下下一个版本的RMT1

如果两个决策会需要拆开，那么以2个星期频率为佳，会议时长不超过30min