4. 急诊模式在需求收集中的应用
4.1 再谈需求人和负责人
在《需求管理的三个模式与公交模型》中谈到,需求就像来急诊室的病人,只有经过“预检分诊”的过程,判断出需求的轻重缓急,从而匹配出对应的资源。
那么,在实际的场景下应该如何应用急诊模式呢?
首先回忆一下《需求管理中的干系人和角色》中,提到了角色有需求人和负责人。
需求人,这个角色来自于公司或者组织的任何方面,他们是提出需求的人。
负责人,这个角色负责收集需求,特别是业务需求。当业务团队的人数,远远大于研发团队时,这个角色非常的重要。
需求人和负责人在应用急诊模式时,处在比较重要的位置。
4.2 急诊模式的应用流程
急诊模式的应用流程如下图:
其中,圆角方形代表操作步骤,直角方形代表输出物。
在这里复述一下整体的步骤。
需求人提交需求。提交需求的模板,之后的章节会介绍。
负责人收集需求文件,初步评审需求。在这里,如果需求存在不合理的状况,特别是业务流程不合理,负责人可以将需求打回需求人重新整理。
产品经理、研发经理初步评审,并放入待排期列表。产品经理拿到负责人评审通过的需求,与开发经理进行初步评估,判断需求是否可行。可行的需求放入待排期列表。待排期列表的模板,之后的文章也会介绍。不合理的需求,也会打回。
根据待排期列表,需求人、负责人、产品经理、研发经理评定待排期列表中的需求,生成待开发列表。在这个过程,会应用一个工具——排期站会。这个工具,之后也会介绍。经过排期站会后,形成待开发列表。
在需求收集阶段,以上所有步骤是应用急诊模式的过程。
4.3 关于时间的把控
在《需求管理的三个模式与公交模型》中,公交模型下,会有三辆“公交车”,即需求收集、需求设计、需求研发。因为需求管理的时间周期可以是2周,所以每辆“公交车”的发车周期是2周。
换句话说,在需求收集阶段,执行急诊模式的操作步骤的时间是2周。
其中,需要关注几个需求时间。
在需求管理活动中,进行某一项具体活动的时间点,就是需求时间。
(1)需求收集的开始时间和结束时间
关注需求收集的开始时间和结束时间,因为二者相减,约等于2周,或者说约等于2周的工作时间。因为每个公司的工作习惯不一样,可能会涉及到固定时间点的例会等,所以,需求开始时间和结束时间设置要灵活。
同时,需求收集的开始时间和结束时间,要有一定原则性。产品经理要尽量影响需求人,不要赶在紧邻结束时间提交需求。就好比,在现实生活中赶火车,总要提前一会儿到达车站,毕竟还要有检票进站等环节。同样,需求人在临近结束时间提交需求,负责人评审需求和产品经理评审需求的时间,都不能保证,会影响需求的质量,以及之后的排期站会的质量。
所以,为了规避这种情况,可以在需求收集结束前5天,发送排期站会的会议邀请,以此提醒大家马上就要排期需求了,赶紧提交需求。
(2)排期站会的时间
排期站会的具体内容和形式,后面的文章会提到。这里先提一下排期站会的时间。
排期站会的时间紧邻需求收集的结束时间。换句话说,需求收集一结束,立刻开始排期站会。
因为排期站会,需要需求人、负责人、产品经理、研发经理及研发工程师参加,所以要多方协调一个大家都有空的时间进行。
排期站会的时长控制在一个小时内。
4.4 结语
本章介绍了在需求收集阶段,应用急诊模式的流程步骤。
之后将介绍,在需求收集阶段的3个工具:
需求提交模板
需求排期列表
排期站会
5. 收集需求的模板
本章介绍一套收集需求的模板。通过模板规范需求的内容,以及提升沟通的效率。
5.1 应用场景
模板应用在需求收集阶段,方便需求人提供和描述相应需求,便于负责人、产品经理、研发经理等角色评审需求。
利用此需求模板,可以快速提取需求信息,便于存档和查阅。
5.2 模板样式
此需求模板在填写上有如下说明:
(1)需求提交部门
填写需求人的所在部门。
(2)功能使用角色
比如可以填写业务主管、业务经理等。可以是使用者的职位描述。
(3)使用频次
单位时间内预计使用功能的次数。比如,10次/月。方便判断此需求的优先级。
(4)提交时间
记录需求提交的时间,便于使用“先入先出”原则。
“先入先出”原则,来自于仓储的概念,指的是先进入仓库的商品先出库。比如,食品行业有保质期的要求,需要生产越早的食品,越早出库。
再形象一点,把处理需求的过程理解为一根管子,新进入管子的需求,就先从另一头流出。
因为需求对应的场景和业务可能会变化很快,如果积压时间太久的需求,就变贬值,跟不上现有业务的发展,所以要应用“先进先出”的原则。
(4)优先级和重要性
这两个概念下一章重点介绍。
简单地说,优先级是对需求按不同的类型进行划分。通常见到的优先级划分是高、中、低,或者用简单的数据代替。
优先级:是部门与部门之间的需求比较。
重要性:是对需求打分,对优先级的补充,是部门内部需求的比较。
(5)需求涉及部门
一个系统需求,会牵一发而动全身。通过填写此需求可能涉及到的其他部门,来评估需求带来的可能影响。
也能驱动需求人在提需求时,增加跨部门思考的维度,提升需求的可行性。
不害人的需求,不是完整的需求。——《普拉姆原则》
(6)系统功能位置
对于系统功能优化类的需求,可以注明原有需求的位置,或者想要添加的功能页面。
(7)业务背景
或者叫需求背景。可以想象一下,如果需求是一部电影的话,是不是要介绍这个故事发生的时间、地点、人物等。以此类比,填写相关的需求背景。
(8)预期完成效果
描述需求实现后,预期实现的效果。
(9)需求说明
以任何形式来描述需求内容。
(10)需求文档
任何形式的需求文档,都不如流程图简单明了,便于沟通。
5.3 结语
此文档偏向于应用在后端产品或者系统需求。
如果是前端需求,可以根据业务需要选择填写。
6. 需求池的核心:优先级和重要性
本章重点介绍需求池中的核心:优先级和重要性。
6.1 什么是需求池?
需求池,顾名思义就是放需求的地方。需求像下饺子一样,储藏在需求池中。
在我看来,需求池是更像是一个游泳池,需求有不同的泳道。而泳道代表着需求的不同状态。
需求的状态一般包括:筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。
每一种状态的需求,可以汇集成一起。比如,待排期状态的需求,可以汇总成列表样式,叫做待排期列表。
所以,需求池是多种状态的需求,以合适的形式展现的需求汇总。
结合,之前文章提到的内容,需求池列表可以是长成如下样子。
当然,需求池中不同状态的需求,可以用多种形式进行展现。比如,待排期的需求可以用列表的样式进行展示。待开发状态以后的需求,可以用看板的样式进行展现。
6.2 优先级——需求的分类和排序
需求的优先级是再熟悉不过的名称了。
优先级表现形式,一般是数字123、汉字高中低,或者字母ABC等。优先级可以用来给需求进行排序,优先级高的需求,优先开发。
同时,优先级也可以对需求进行分类。或者说,对不同的优先级给予一个不同的释义。
举一个例子:
需求优先级的定义,可以根据所在公司和组织、所经营的业务进行综合评估和划定。
但是,有一个问题,需求的数量一般会比需求优先级要多。所以,多个需求可能会同一个优先级,那么同一优先级的需求又该如何区分呢。
6.3 重要性——优先级的辅助
刚才说了优先级,具有对需求分类的作用。重要性是对优先级的辅助。
重要性是对需求进行打分,分数的范围是1-100分。每个需求会被赋予1个分数,每个需求的分数是唯一的。
例如,需求A、需求B、需求C,分别赋予了97分、85分、90分。那么,根据分数从大到小进行排序,那么优先做分数大的需求。
如下列表:
需要注意的是,重要性的分数只是用来做排序,不代表其他信息。比如,重要性是100分的需求不是50分需求的2倍。
另外,在做重要性评分的时候,建议每个需求之间不要打连续的分数。比如,需求A的重要性打95分,需求B的重要性最好打92分。分数中间的间隔,用来插入需求。毕竟在工作中,有很多突发的需求会插入进来,以调整研发计划。
6.4 统一的看优先级和重要性
从整体的角度看,优先级和重要性两者的关系。
优先级和重要性是需求池的核心!什么是核心?优先级和重要性一旦确定,将贯穿需求的整个生命周期,所有的资源将根据优先级和重要性来被安排。
换句话说,如果是高优先级和高重要性的需求时,不管在需求的哪一个状态,都会被优先分配资源。
优先级和重要性在处理跨部门需求的时候,尤为重要。原因在于,优先级可以用来比较不同部门之间的需求。因为优先级已经对需求进行了分类。
同时,重要性只用作一个部门内需求的比较,重要性的分数不能跨部门比较。比如,采购部门重要性100分的需求,与销售部门重要性是90分的需求,在分数上是没有可比性的。
(是不是有点晕了?先跳出来。)
优先级和重要性,只是处理需求的工具。更重要的是,如何给需求划分优先级和重要性。
我觉得这些方法有很多,但是可以借用项目管理的一个概念——项目组合管理。
项目组合管理是指在可利用的资源和企业战略计划的指导下,进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化,确保项目符合企业的战略目标,从而实现企业收益最大化。
这个概念有点绕,只要关注一个词——“符合企业战略”。所以,划分需求的优先级和重要性,是紧密围绕着企业和组织的战略。
而如何划分优先级和重要性,可以看做是项目组合管理方法论的范畴。可以使用SWOT分析、KANO模型等等,这些都是得到优先级和重要性的工具。
所以,在符合企业或组织战略的核心目标下,通过项目组合管理的方法,先对收集到的所有需求标注好优先级,再对这些需求进行分组,形成需求组。分组的依据可以是部门,可以是项目。对这一组内的需求,赋予不同的重要性分数。因为需求组之间划分的标准不同,所以不同需求组的需求,重要性分数不具有可比性。
因此,从实现企业战略的角度,高优先级的需求在划分给不同需求组后,可能并不会赋予很高的重要性。
6.5 结语
优先级和重要性,只是处理需求的手段。它们背后的核心要义是企业和组织的战略目标。
7. 排期站会——需求收集的最后一站
上一章介绍了制定需求优先级和重要性。在此基础上,可以组织需求方和研发方在一起开排期站会。一是评定进入到需求设计阶段的需求,同时也是增进各方沟通信息的好时机。
7.1 为什么要站着开会
在敏捷开发中,站会是一个很有用的工具。在5-10分钟的时间中,快速交流信息,推进项目。
之初,排期会议也是安排在会议室之中,大家坐着沟通信息。实际上,人一旦没有紧迫感,就容易天马行空的沟通起需求的细节。值得注意的是,排期会不是需求评审会。
一般,排期会上要评定20-30个以上的需求,每个需求讨论3-4分钟,将是个极为漫长的过程。
所以,让大家站着开会,以一种不太舒服的方式,压缩自己的思路,快速沟通问题。
7.2 排期站会的一般流程
举行排期站会的一般流程如下:
(1)发送会议邀请
排期站会的举办时间是以固定时间举办。按照之前文章提到需求管理周期,一般是2周举办一次。具体的开会时间,要与各方协调,特别是避开例会时间。
与会人一般包含:需求人、负责人、产品经理、研发经理、测试经理等。
(2)在规定时间开会,提前公布讨论需求组的顺序
站会中讨论的需求,会来自不同需求组(关于需求组的概念,请上一章:需求池的核心:优先级和重要性)。每个需求组对应着不同的人,为了避免浪费大家的时间,按照讨论组的顺序,让对应的人按顺序参加会议。
制定讨论顺序时,尽量要考虑每个需求组的数量,和需求组的重要性。因为,先行讨论的需求,就会有优先获得需求的优势。
(3)按顺序召集大家开会,首先介绍当前需求的开发情况
由会议主持人(一般是产品经理)介绍当前的开发状况,特别是沟通时间点。
(4)评审进入下一阶段的需求
主持人可以针对需求池的内容,沟通可以进入到下一阶段的需求。
但是,主持人要控制住节奏,防止大家陷入需求细节的讨论。对于一时没有定论的需求,要标注出来,邀请需求相关方在会后讨论。
7.3 排期站会的道具
(1)站会的场地
站会的场地可以选在工位旁,较大的过道或者走廊上。这样便于参会人快速到达和撤离开会现场。也可以让一些让其他同事,快速参加会议。
(2)展示会议内容:电视/白板/看板
一般大家要围绕着需求池来开会。而展示需求池的道具,可以一块儿屏幕或者投影。这样可以集中大家的焦点,和快速展示信息。
(3)倒计时器
在每一个讨论模块设置倒计时器,到时铃响。提醒大家关注时间。
7.4 结语
站会的首要目的是公布信息,增进沟通和了解。
大家在开会的过程中,了解微信和邮件中以外的信息,增加对需求的了解。需求相关方的信任和了解。