第31件事 管理需求

小O很勤奋,也在经常思考:当知道用户真正想要的是什么之后,需要去评估哪些需求或功能该做,哪些不该做;如果该做的话,哪些优先做,哪些后面做;接下来的工作就是确定优先做的需求或功能是在这个版本迭代实现还是下个版本迭代实现。小O也向老K师傅说了自己的思考和心得。看到小O能如此主动思考,老K很欣慰。接下来,老K计划把管理需求的一些方法论传授给小O,算是给最近一段时间的培训画上一个句号。

管理需求这个环节,可从需求获取开始到需求的上线及其用户反馈结束,形成一个闭环循环的流程。前面阐述了产品的需求优先级是怎么定义的,本节将阐述:需求的工作量如何估算;研发优先级如何定义;使用什么方法或工具来管理需求;在项目迭代过程中遇到需求变更时怎么处理。

1.需求工作量的估算

在产品实践中,经常碰到这样的问题:完成某个需求的工作量有多大?如何去估算工作量?本小节就来介绍需求工作量的科学估算方法。常用的方法是斐波纳契数列(Fibonacci Sequence),又称黄金分割数列,指的是这样一个数列:1、1、2、3、5、8、13、21、…,这个数列从第三项开始,每一项都等于前两项之和,随着数列项数的增加,前一项与后一项之比越来越逼近黄金分割的数值0.6180339887…

下面以斐波那契数列为例,介绍需求工作量的估算(工作量以小时为单位)。

(1)选定参照物

选择一个中等工作量的功能或需求作为参照物,视为数字5。这里以微博的登录功能为例,功能主要有账户与密码的验证、记住登录状态和取回密码。登录功能的工作量视为数字5,这个数字5是工作量的参照数字,以它作为基准。

(2)团队成员定义工作量

以5~7人组成团队,每个人用斐波那契数列的数字1、2、3、5、8、13、21、…定义当前需求或功能的工作量,当然是基于与参照物数字5的对比。如果登录功能的工作量是5,那么发布微博的功能工作量有多大,5位团队成员分别给出数字答案:34、55、89、144、233。可以看出,5位成员给出的答案分歧很大。

(3)进一步明确需求

如果团队成员的分歧很大,需要澄清和进一步明确需求。分歧很大的原因是没有明确发布微博到底有哪些主要功能,这与在实际的产品工作中遇到的问题是一样的,只说产品要做某个功能,大概说了一下,就询问研发人员的工作量有多大,研发人员也估算不出来,因为需求不明确。所以当成员之间的数字分歧比较大时,需要相关人员明确到底有哪些功能,比如发布微博的主要功能有:发布最多有140个字的文本微博,或发布一张图片微博,或发布音乐、视频、话题和投票微博,需要有敏感词过滤功能,一段时间内不能发布相同的微博,账号被封的用户发布不了微博。明确主要功能之后,成员再次给出估算数字,这一次大家的答案是:34、55、55、55、89。从答案中可以看出,这一次团队成员的分歧不是很大。

(4)确定结果

如果团队成员的分歧不大,使用较高的那个数字作为需求或功能的工作量,或者使用出现次数较多的数字作为工作量。选取55作为发布微博功能的工作量,因为这个数字出现了3次。

按照上述方法逐条对需求定义其数字。通过这种方法,我们还可以估算转发、评论、私信等功能的工作量。

除了上述方法外,还可以采用十二生肖来估算工作量:鼠、牛、虎、兔、龙、蛇、马、羊、猴、鸡、狗、猪。当然也可以创建你自己的度量方法。

2.需求变更

产生需求变更在实际的产品工作中是正常的,没有需求变更是不正常的。导致需求变更的主要原因有:产品经理自己没有想清楚,比如,需求文档有逻辑漏洞,不细致,不准确;也有的是产品经理的“完美主义”情结在作怪;再有就是技术能力和资源的问题。对变更的需求进行评估,需要评估影响的范围有多大,是否有必要进行变更。确定需要变更时,还要看看是否一定要在当前这个迭代变更,有的变更可以放到下个迭代进行,也可以在下个迭代开始之前,有一个小的迭代版本,在这个小的迭代版本里实施变更。在需求已经通过评审并进入项目环节时,尽量减少不必要的需求变更。

一旦确定需求需要变更,通常要以口头和书面文档形式通知相关人员。表5-2所示是需求变更记录表,表中包含的内容有编号、当前需求变更所属的是什么、变更前的需求主要描述是什么、变更后的需求主要描述是什么、为什么要提出需求变更、是谁提出的、是在哪一天提出的、最后是变更后的需求文档存储的地址。需求变更记录表以及更变文档都需要放在一个约定好的固定的位置,这样相关人员都能及时获取。

表5-2 需求变更记录表

00106.jpg

3.需求管理工具

需求管理起源于需求获取,终结于需求的关闭,产品经理需要跟踪需求的进展和状态。图5-6所示的这个表完整表示了需求管理的过程。

00114.jpg

图5-6 需求管理表

对图5-6所示的各项内容具体描述如下。

  • 编号:需求的唯一数字标识,便于统计。
  • 提交人:负责录入和解释需求。
  • 版本:所属的版本号。
  • 模块:产品的功能模块。
  • 名称:简要概括需求的主体特征。
  • 描述:需求的主要描述。
  • 任务类型:新增功能、功能改进、体验提升、Bug修复、内部需求等。
  • Ticket编号:需求或Bug对应在Trac、Jira、禅道等管理工具上的编号。
  • 需求评审完成时间:需求文档经过评审,获得通过的时间。
  • UI完成时间:页面设计和制作经过评审,获得通过的时间。
  • 技术评审完成时间:技术人员接收到需求之后,技术方案设计完成并通过评审的时间。
  • 技术提测开始时间:编码完成,可以提交给测试人员开始测试的时间。
  • 需求优先级:商业价值,即重要性+紧迫性,5点度量,从1到5,5最高。
  • 研发优先级:投入产出比,商业价值/工作量,5点度量,从1到5,5最高。
  • 状态:包括待讨论、暂缓、拒绝、需求中、开发中、设计中、测试中、已发布等。
  • 负责PM:状态进入“需求中”后确定。
  • UED设计师:状态进入“设计中”后确定。
  • 开发工程师:状态进入“开发中”后确定。
  • 测试工程师:状态进入“测试中”后确定。
  • 发布时间:需求的发布时间。
  • 备注:其他信息,如被拒绝的理由、被暂缓的理由和重启条件、其他等。

这里特别强调需求的优先级和研发的优先级,前者由商业价值决定,即由“重要性+紧迫性”决定,5代表特别重要且特别紧迫(加急),4代表重要且紧迫,3代表重要不紧迫,2代表紧迫不重要,1代表不紧迫且不重要。产品经理根据定义需求优先级的方法对需求逐一进行优先级排序之后,还要进行研发优先级的排序。为什么呢?因为在项目实践中,要求研发人员完全按照产品经理定义的需求优先级来安排研发,这个不太现实,因为这还会涉及需求的工作量以及研发资源的调配等问题,所以就出现了研发的优先级。当然,研发的优先级定义的大原则肯定是尽量遵从需求的优先级,尽可能地按照需求的优先级来安排研发优先级。此外,研发的优先级等于商业价值除以工作量。有些需求或者Bug非常简单,研发工作量非常少,完成这些研发基本上是“举手之劳”的事。按照公式,在分子即商业价值一定的情况下,分母(即工作量)越小,整个比值就会相对较大,这也解释了为什么有时候在一个迭代版本里顺便将一些小的需求也一并做了的原因。

在产品实践工作中,一般情况下虽然遵从上述规律,却研发的优先级等于商业价值除以工作量,但有的时候会碰到一些特殊的情况,那就是风险。在考虑投资回报率(商业价值/工作量)的同时,也要考虑同时带来的风险,这种情况下的解决方案是开发优先级先根据ROI排序,再根据风险、新知识、常识调整排序。

内部使用的需求管理工具因公司而异,只要内部达成共识,建立体系规范,贯彻执行,需求和bug管理都可以使用诸如Trac、Jira或禅道之类的管理工具。

也许是经验不够,且入产品这行的时间不久,小O经常犯研发人员非常讨厌的一个毛病,那就是需求变更频繁。出现这种情况的原因很简单,就是小O自己也没有想清楚,说到底还是产品内功没有修炼到家。之前在估算需求工作量的时候,也基本上是拍脑门,有时甚至会被研发人员忽悠。现在好了,有方法论作支撑了,在版本和迭代规划方面,将会更加得心应手。

00004.jpg

在敏捷开发模式中,经常会使用斐波那契数列来科学估算需求工作量。产品经理定义需求优先级之后,因为涉及需求工作量以及研发资源的调配等实际问题,还需要确定相应的研发优先级,研发的优先级等于商业价值除以工作量。研发的优先级定义的大原则肯定是先遵从需求的优先级,尽可能地按照需求的优先级来安排研发优先级。