万字干货:手把手教你做需求管理

通过这篇文章,总结自己在工作实践中需求管理的方法论——普拉姆方法。总结这个方法论的特点是,用最轻量化的投入,与他人协作,并管理需求,推动需求上线。这套方法论组合了项目管理、敏捷开发的知识,希望能对大家有所帮助。本文适合0-2岁产品经理阅读,产品大牛、敏捷管理大师请绕过。

本文大纲如下:

1. 为什么要做需求管理?

  • 1.1 我们的工作是否像救火
  • 1.2 需求管理是什么?
  • 1.3 宗旨是什么?
  • 1.4 结尾

2. 需求管理中的干系人和角色

  • 2.1 什么是干系人
  • 2.2 需求管理中的角色
  • 2.3 如何识别干系人和角色

3. 需求管理的三个模式与公交模型

  • 3.1 破解“越快越好“的局面
  • 3.2 急诊室的场景
  • 3.3 让需求管理运转——公交模型
  • 3.4 总结

4. 急诊模式在需求收集中的应用

  • 4.1 再谈需求人和负责人
  • 4.2 急诊模式的应用流程
  • 4.3 关于时间的把控
  • 4.4 结语

5. 收集需求的模板

  • 5.1 应用场景
  • 5.2 模板样式
  • 5.3 结语

6. 需求池的核心:优先级和重要性

  • 6.1 什么是需求池?
  • 6.2 优先级——需求的分类和排序
  • 6.3 重要性——优先级的辅助
  • 6.4 统一的看优先级和重要性
  • 6.5 结语

7. 排期站会——需求收集的最后一站

  • 7.1 为什么要站着开会
  • 7.2 排期站会的一般流程
  • 7.3 排期站会的道具
  • 7.4 结语

8. 登机模式与需求设计

  • 8.1 何为登机模式
  • 8.2 产品文档要用共享文档
  • 8.3 结语

9. Trello的使用技巧——看板模式与需求研发

  • 9.1 鸡肋的邮件
  • 9.2 看板与需求卡片
  • 9.3 Trello的使用技巧
  • 9.4 结语

10. 需求管理的证伪

  • 10.1 遭遇危机
  • 10.2 优化需求管理流程
  • 10.3 优化需求池
  • 10.4 普拉姆理论的缺陷

1. 为什么要做需求管理?

1.1 我们的工作是否像救火

总是做迫在眉睫的事情,会令人丧失目标。——《普拉姆原则》

我在工作中体会到每天忙东忙西的处理需求,虽然每天都很充实,但确实极为耗费精力,时间长久就会缺乏动力。

上面讲的是个人的角度,如果一个组织或者团队面对大量的需求,在处理需求的时候,没有节奏和规划,会产生消极的影响。从小的方面看会影响团队士气,往大的方面看,会影响组织实现既定的目标。

我的工作环境是,作为后台产品经理,处在业务运营团队和技术团队之间,要作为一个桥梁,保障业务运营团队从我这里输出高质量的需求,也要保障具有不同知识背景团队,能过通过需求,高效沟通,快速推进需求上线。
于是,我就通过工作实践,形成了自己的管理需求方法论——普拉姆方法。

存在即有标识。——《普拉姆原则》

为了便于总结和归纳,我给这个方法论起了个名字。在需求管理中,需求的名称也是很重要的因素,之后会提到。

1.2 需求管理是什么?

我的定义是, 通过协作,管理需求内容和进程,实现成功发布。

便于理解这个概念,在这里讲一个海湾战争的故事。

在海湾战争中,美军在前期并没有派出大规模的地面部队进行战术打击。而是,派出一批批的特种部队渗透到敌人境内,侦查清楚敌人重要的军事目标,并将精准坐标和信息,传递给后方。顷刻之间,海洋上的战舰派出飞机和战斧导弹对其进行精准轰炸,并取得战术和战略上的胜利。

在这个例子中,特种部队是业务运营团队,飞机和战斧导弹是技术团队。产品经理通过需求管理的方法论,用高效和轻量化的方式,去精准的做出需求,实现预期的效果。

1.3 宗旨是什么?

普拉姆方法的宗旨是积 极主动,知识共享,相互尊重。

什么是宗旨?可以理解为这套方法论的价值观。这套方法论的每一个细节,都应该遵循这个宗旨来实践,并遵循这个宗旨发展和进化。

“积极主动,知识共享,相互尊重”的宗旨,是我借鉴了美国西南航空的价值观。美国西南航空是美国航空业受到911事件巨大打击的背景下,依然能够盈利的廉价航空。在航空业极为复杂的管理模式下,使用廉价航空的经营方式实现盈利,还是令人十分震撼的。所以,阅读了相关书籍之后,将美国西南航空的价值观的精华,吸纳为普拉姆方法的宗旨。

(1)积极主动

积极主动是核心,具体指团体之间的成员积极主动的承担责任去做事情。

在《高效能人士的七个习惯》中,积极主动也被列为很重要的素质。在管理每个需求的过程中,每个人都要有担当或者忽略角色的做事情。这也是敏捷开发中推崇的。一个产品经理在不同的需求中,可能既是梳理需求、输出原型的角色,又可能是测试的角色。但是, 团队中每个工作的角色在变,通过管理需求达成的目标不会变。

请明确讲清需求的目标!我会像战士,即使身陷重围,也会向胜利的方向战斗!——《普拉姆原则》

(2)知识共享

知识共享,是指分享不同团队的领域知识,减少沟通的未知区域,减少沟通中的误解。

有一个Johari窗格的沟通理论,专门提到沟通分为四个区域,即开放区、盲目区、隐秘区、未知区。通过扩大开放区,来提升沟通的效率和效果。

同时, “公则生明”,即将信息公开透明,可以增加协作团队之间的信任。比如,公开展示各需求的进度。

讲个题外的故事,俞永福对产品经理说过,产品经理要有树靶子的意识。自己的需求就是靶子。公司内部的任何人都可以打靶子。每个产品经理有责任,维护好自己的靶子,不被打漏。所以,产品经理自己要让自己的需求健壮,不被打漏。

从另外的角度看, 尽早的把问题暴露,可以最大的降低解决问题的成本,防止问题积累成一个“惊喜”。

(3)相互尊重

相互尊重,是指尊重每一个人的人格、劳动及输出成果。

在管理需求的过程中,要与不同岗位的人打交道。每个人站在不同的立场,必然会有看待问题的不同角度。所以,大家在合作的过程中,要相互尊重。内在的思想是人格上的尊重,外在的表现是尊重别人的劳动成果。不要站在自己的立场和知识背景,去简单评判别人的劳动。

对他人劳动的尊重,就是对他人的尊重。

1.4 结尾

这是文章的的开篇,湿货很多。可能都是大家知道的常识。不过, 常识并不常用 。把常识内化为行动之中,可以让事半功倍,至少不会犯错。

2. 需求管理中的干系人和角色

识别出需求的干系人,是需求管理中非常重要的起点。之后的需求管理活动要与干系人及角色,进行紧密的合作。

2.1 什么是干系人

干系人,是来自于项目管理中的概念。

项目干系人是能影响项目决策、活动或结果的个人、群体或组织,以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。他们也可能对项目及其可交付成果施加影响。干系人可能来自组织内部的不同层级,具有不同级别的职权;也可能来自项目执行组织的外部。——《项目管理知识体系指南(PMBOK指南)(第5版)》

总结的简单点, 干系人是与需求相关的人或者组织。

而且干系人在需求管理中起到很重要的作用。特别是在做跟业务流程密切结合的需求时,找到并找对干系人极为重要。在需求中的每个人,都会从自己的立场出发提需求,可能会不经意间破坏别的业务线的流程,所以这个时候就需要产品经理从全局的角度去思考需求,或者找到那个能从全局思考的干系人去帮助找到需求中的障碍。

有人就会有角色,每个角色必然有不同的关注点,被忽略的关注点都变成了坑。——《普拉姆原则》

这里再扩展一点,就是需求可能存在二律背反的情况。也就是说,提一个优化改善的需求,可能会损害其他流程或角色的利益。有时,产品经理要找到需求的受害者,从而更全面的了解需求。

不害人的需求,不是完整的需求。——《普拉姆原则》

所以, 找到和找对需求的干系人,对于需求管理非常重要。

2.2 需求管理中的角色

在《西游记》中,六小龄童扮演的角色多达16个,最知名的就是孙悟空,还有道士、和尚之类的角色。而唐僧的角色,就有三位演员扮演过。同理,在需求管理中,干系人是一个个的演员,而演员可以担任多个角色。

以下是我在从事后端系统的工作中遇到的角色:

(1)需求人

顾名思义,真正提出需求并描述需求细节的角色。这个角色可以是任何干系人,毕竟产品经理是一个负责从四面八方收集需求的人。需求人一般要与其所在的部门联系在一起,有助于判断所提需求的立场。

(2)负责人

负责人也来自于业务部门。收集需求人的需求,从业务角度对需求进行梳理和判断,并转发给产品经理和研发同事。当业务团队远大于技术和产品团队时,负责人的角色就非常重要。如果业务团队的人数小于等于技术团队时,可以省去这个角色。

负责人,就像一个漏斗和筛子一样,初步筛选一遍需求。毕竟,评估需求也是要花费时间,特别是占用研发同事的时间。

(3)产品经理

需求管理的组织者、推动者。以“积极主动”的态度,与需求管理的角色进行沟通。

(4)研发经理

研发资源的管理者。在这里的研发经理,一般是带四、五个人小团队的级别。因为,他们能够了解每个研发工程师的工作和能力,协助评估业务需求。

(5)研发工程师

实际参与研发需求的程序员。

(6)测试工程师

参与需求测试的测试人员。可以根据公司的组织架构,增加测试经理的角色。测试经理的级别也是带四、五个人小团队。

在需求管理中,产品经理要当成一个桥梁,与不同的角色,进行沟通和协作。 在后面,需求管理的流程和需求看板的管理方法,都会与这些角色紧密相关。

2.3 如何识别干系人和角色

了解所在公司的组织架构,以及团队组织架构,是识别干系人和对应角色的关键。

产品经理可以根据组织架构,明确了解到研发和测试的相关角色。

同时,产品经理可以跟业务团队进行沟通,了解业务团队的业务背景和知识,以及团队文化。

识别出潜在的需求人,才是真正的考验。

以上,就是需求管理中干系人的相关内容。

3. 需求管理的三个模式与公交模型

普拉姆方法的运行流程包含三个模式:急诊模式、登机模式、看板模式。本章将介绍这三个模式与公交模型的关系,提供一套应对”越快越好“类需求的方法。

3.1 破解“越快越好“的局面

在接到来自各部门的需求时,每个需求都会打上”越快越好“的标签。站在提需求者(需求人和负责人)的角度,研发资源是稀缺的,老板的要求是急迫的,如果不表达需求的急切性,需求就排不上。

这就像飞机迫降之后,每个人都会带着”越快越好“目的奔向出口,如果没有空乘人员的指挥,最后大家慌不择路的堵在出口,最终导致延误了逃生时间。

处理工作的模式:划散乱为规律,划应急委预测。——《普拉姆原则》

所以,可以借鉴急诊室的场景 ,来规划”越快越好“的需求,让需求管理有序的运行起来。

3.2 急诊室的场景

产品经理面对的需求,就是来看急诊的病人。病人都会觉得自己应该马上得到最快的医疗救治。但是,医疗资源有限,只能让医生先救治最危重的病人,病情较轻的病人要先等待一下。这个时候,需要有一个预检分诊的流程,预先对病人进行判定和分诊,从而让急诊室高效的运转起来。

因此, 借鉴急诊室的做法,我们对需求增加一个”预检分诊“的预处理模式。从而对”越快越好“的需求,进行区分,在研发资源稀缺的情况下,让真正紧急的需求获得资源。

3.3 让需求管理运转——公交模型

设想一下,病人去急诊楼就医的时候,我们安排了”预检分诊“(预处理)的流程。那么就需要安排一个房间,让病人们在那里等候,并安排医生进行诊断。然后,病人根据预检医生的诊断,再从这里出来,去对应的诊室去看病。

所以,要让这个流程在需求管理中正常的运行,就需要采用 公交模型 。

公交模型,是我结合火车模型发布模式,起得一个通俗易懂的名字。

(火车模型发布模式是)以固定的周期持续发布产品,如果某项既定功能未完成,就挪到下个周期发布的开发方法——《启示录——打造用户喜爱的产品》

公交模型,就像我要从到家到公司要换乘3趟公交车去上班,到公交站等车。每趟公交车之间都有发车间隔和到站时刻,并且周而复始的经过公交站。所以,我就按照规划好的路线,从公交站坐车,再到下一个换乘站乘车。

从公交模型中,可以提炼出几个概念:出行路线、发车间隔、到站时刻。

在公交模型中,出行路线称为”需求管理流程“,发车间隔称为”需求管理周期“。到站时刻,称为”需求时间“。

(1)需求管理流程

需求管理流程,是指在需求管理中,按照顺序依次进行需求管理活动。

需求管理活动按先后顺序分为三个阶段:

  1. 需求收集
  2. 需求设计
  3. 需求研发

再强调一遍,这三个阶段是依次进行的。先进行需求收集、在进行需求设计、最后进行需求研发。

每一阶段的需求管理活动对应一个指导原则。指导原则就是急诊模式、登机模式、看板模式。急诊模式指导需求收集,登机模式指导需求设计,看板模式指导需求研发。

在文章的开头,我用急诊室的场景,介绍了急诊模式。后续的章节中,我会介绍剩下的两种模式:登机模式和看板模式。

(2)需求管理周期

需求管理周期,简称”周期“,是需求管理活动按顺序重复出现,并完成需求管理活动的时间叫做需求周期。

普拉姆方法的需求周期,是80小时,即2个星期。80小时原则,来自于项目管理中的工作分解结构。根据项目管理的一般经验,将一个项目中的工作,按照80小时的工作量进行拆分比较合理。所以,每一类需求管理活动按照2周的工作量进行。

换句话说,需求收集、需求设计、需求研发是三辆同时发车但路线不同的公交车,三辆公交车运行一趟的时间是2周。每个需求相当于是乘客,要根据路线(需求管理流程)在公交站等车。当然,每个需求的终点就是发布上线。

(3)需求时间

在需求管理活动中,进行某一项具体活动的时间点,就是需求时间。

一般,需求时间意味着规则。比如,需求设计阶段的周二的下午2:00,需要开排期站会,这是一个约定好的时间,需求的相关方都必须要来。排期站会后面再介绍。

(4)运转模式

如果一个需求从开始到发布上线的生命周期来看,公交模型是下面这个样子。

从需求管理周期的角度,无数需求按照公交模型去运转着。从参与到需求管理的角色来看,每一个周期中的需求收集、需求设计、需求研发阶段,参与者的工作是连续可预测的。每个角色各司其职,让需求管理顺畅的进行下去。

3.4 总结

这章通过介绍急诊室的故事,也就是急诊模式,来引出破局”越快越好“类需求的方法,以及后面要介绍的登机模式和看板模式。这三个模式用来分别指导需求收集、需求设计、需求研发三个阶段的需求管理活动。

同时介绍了推动需求运作的公交模型,让需求管理活动具有预测性和规划性。

本章之后,将依次介绍三个模式和三个阶段对应的方法和工具。

4. 急诊模式在需求收集中的应用

4.1 再谈需求人和负责人

在《需求管理的三个模式与公交模型》中谈到,需求就像来急诊室的病人,只有经过“预检分诊”的过程,判断出需求的轻重缓急,从而匹配出对应的资源。

那么,在实际的场景下应该如何应用急诊模式呢?

首先回忆一下《需求管理中的干系人和角色》中,提到了角色有需求人和负责人。

  • 需求人,这个角色来自于公司或者组织的任何方面,他们是提出需求的人。
  • 负责人,这个角色负责收集需求,特别是业务需求。当业务团队的人数,远远大于研发团队时,这个角色非常的重要。

需求人和负责人在应用急诊模式时,处在比较重要的位置。

4.2 急诊模式的应用流程

急诊模式的应用流程如下图:

其中,圆角方形代表操作步骤,直角方形代表输出物。

在这里复述一下整体的步骤。

需求人提交需求。提交需求的模板,之后的章节会介绍。

负责人收集需求文件,初步评审需求。在这里,如果需求存在不合理的状况,特别是业务流程不合理,负责人可以将需求打回需求人重新整理。

产品经理、研发经理初步评审,并放入待排期列表。产品经理拿到负责人评审通过的需求,与开发经理进行初步评估,判断需求是否可行。可行的需求放入待排期列表。待排期列表的模板,之后的文章也会介绍。不合理的需求,也会打回。

根据待排期列表,需求人、负责人、产品经理、研发经理评定待排期列表中的需求,生成待开发列表。在这个过程,会应用一个工具——排期站会。这个工具,之后也会介绍。经过排期站会后,形成待开发列表。

在需求收集阶段,以上所有步骤是应用急诊模式的过程。

4.3 关于时间的把控

在《需求管理的三个模式与公交模型》中,公交模型下,会有三辆“公交车”,即需求收集、需求设计、需求研发。因为需求管理的时间周期可以是2周,所以每辆“公交车”的发车周期是2周。

换句话说, 在需求收集阶段,执行急诊模式的操作步骤的时间是2周。

其中,需要关注几个需求时间。

在需求管理活动中,进行某一项具体活动的时间点,就是需求时间。

(1)需求收集的开始时间和结束时间

关注需求收集的开始时间和结束时间,因为二者相减,约等于2周,或者说约等于2周的工作时间。因为每个公司的工作习惯不一样,可能会涉及到固定时间点的例会等,所以,需求开始时间和结束时间设置要灵活。

同时,需求收集的开始时间和结束时间,要有一定原则性。产品经理要尽量影响需求人,不要赶在紧邻结束时间提交需求。就好比,在现实生活中赶火车,总要提前一会儿到达车站,毕竟还要有检票进站等环节。同样,需求人在临近结束时间提交需求,负责人评审需求和产品经理评审需求的时间,都不能保证,会影响需求的质量,以及之后的排期站会的质量。

所以,为了规避这种情况,可以在需求收集结束前5天,发送排期站会的会议邀请,以此提醒大家马上就要排期需求了,赶紧提交需求。

(2)排期站会的时间

排期站会的具体内容和形式,后面的文章会提到。这里先提一下排期站会的时间。

排期站会的时间紧邻需求收集的结束时间。换句话说,需求收集一结束,立刻开始排期站会。

因为排期站会,需要需求人、负责人、产品经理、研发经理及研发工程师参加,所以要多方协调一个大家都有空的时间进行。

排期站会的时长控制在一个小时内。

4.4 结语

本章介绍了在需求收集阶段,应用急诊模式的流程步骤。

之后将介绍,在需求收集阶段的3个工具:

  1. 需求提交模板
  2. 需求排期列表
  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 结语

站会的首要目的是公布信息,增进沟通和了解。

大家在开会的过程中,了解微信和邮件中以外的信息,增加对需求的了解。需求相关方的信任和了解。

8. 登机模式与需求设计

之前的章节已经将需求收集和急诊模式讲完了。本章介绍需求设计和登机模式。

8.1 何为登机模式

做需求,犹如坐飞机,通过各种渠道买好了机票,但并不是意味着马上坐上飞机,而是进行check-in。

面对从各个部门提出来的大量需求,有时在需求收集阶段,不能简单快速的评估出全部细节。这个时候需要增加一个需求设计阶段,对已经定好排期的需求,进行check-in,将机票转化为登机牌,然后凭借登机牌,登上飞机。

这里的登机牌就是产品文档,登上飞机就是进入到需求开发阶段。

之前,在需求收集阶段,收集到的资料大部分是可以归为需求文档,也就是描述: 我想要什么,实现什么样的效果。 或者说, 需求文档不涉及到具体界面功能流程、交互设计、UI设计。

实际上,需求文档也不应该涉及这些。原因是,提供需求文档的人(需求人和负责人)并不擅长用非业务语言描述,同时也会增加他们提交需求的工作量,从而影响需求质量。

专业的人做专业的事。

什么是产品化?将需求转化为可以投入资源的行动项。——《普拉姆原则》

这样的话, 需求设计阶段,就需要讲需求文档转化为产品文档,真正将需求描述转化为产品解决方案,转化为让研发同学可执行的方案。

当然也有特例,如果需求是业务逻辑的修改,不涉及界面操作,这时的需求文档其实等价于产品文档。

8.2 产品文档要用共享文档

这里并不讨论在需求设计阶段怎么书写产品文档,因为书写产品文档是用于沟通的工具,格式并不是特别重要。

这里要提的是产品文档要采用共享文档的格式。 在之前,本人将写好的产品文档是以邮件的形式发送给相关人。但是,随之而来的问题就是,更新和保存文档,就变成了问题。

以邮件的形式,总会是存在漏看文档,和不易查找文档的方式。

所以,产品文档要使用现在共享文档的方式。国内已经有很多类似的产品,比如墨刀之类。我使用的是Google文档。使用的原因是体验好,功能完备。

使用在线共享文档的最大优势是,可以随时保存,使用链接分享,随时保持文档的最新状态。同时,可以多人共同编辑文档,更新信息,减少沟通的成本。

同时,还能对文档进行积累和保存。

8.3 结语

在需求管理的需求设计阶段,对需求重新进行评估和设计,从而转化为产品文档,并使用在线共享文档的形式,进行协作,减少沟通成本。

9. Trello的使用技巧——看板模式与需求研发

经过多个章节,终于到了需求研发的阶段。这个时候,使用看板模式进行需求管理。普拉姆需求管理方法的介绍,也快接近尾声。

9.1 鸡肋的邮件

邮件已经成为公司最基本的沟通工具。但也是最鸡肋的工具——食之无味,弃之可惜。

所以, 在需求管理的方法中,尽量让需求的形式或者载体,不仅仅依附于邮件,而应该采用多种形式。比如,在需求池中,需求就是以一行数据的形式存在。

在需求研发阶段,采用看板模式,以卡片的形式存在。

9.2 看板与需求卡片

(1)看板

看板的管理方法,是一个来自于制造业的专门知识。

看板管理,是指为了达到JIT准时生产方式而控制现场生产流程的工具。——百度百科

这里只是才用如下图进行示意,感兴趣的读者可以查阅相关资料,学习看板知识。

看板由不同的“泳道”组成,需求以卡片的形式,从最左端开始,运行至最右端结束。
一般“泳道”的划分,可以按照需求的状态划分。也就是说,需求卡片从左向右的流转,就是需求状态的流转。

(2)需求卡片

需求卡片是需求在看板中的载体。这里可以记载需求的所有信息。

但是包含如下信息:

  • 需求名称
  • 需求的相关人:需求人、负责人、产品经理、研发工程师
  • 部门
  • 需求完成时间
  • 需求描述

在开发需求的过程中,各需求的相关人不用再去寻找邮件,或者翻看电脑保存的文档。

每个人都可以通过看板,看到每个需求的实时状态。每个人都可以去拖动卡片。提前预知自己的工作量。比如,测试工程师就可以通过看板,大概预知有多少卡片在待测试状态,从而预估自己的工作量。

当然,看板和卡片可以用采用多种形式展现。比如,用真实的板子和纸片进行管理。也可以采用电子虚拟的形式进行管理,比如使用Trello。

9.3 Trello的使用技巧

现在,有很多管理工具,在使用看板的方式。但是,综合感受还是做得太复杂。而Trello的最大邮件就是简单,而且兼容很多插件,可以灵活应对多种场景。

当然,Trello最大的优势是免费。

Trello做为工具,本身极为容易上手,这里只是简单介绍一些使用技巧。

(1)卡片

Trello的卡片功能非常强大。

这里要特别强调的是善于使用标签功能。

标签功能,像是办公文具中的条状彩色便利贴。对不同卡片进行分类。

因为Trello有搜索和筛选功能,在实际的应用中,可以将不同的“部门”作为标签打在卡片上,这样就可以对卡片进行筛选。

这里提示的小技巧是,将同一类的信息的标签,赋予同一种颜色,以便于管理。比如,不同部门(如销售部门、运营部门等)的标签是红色,不同系统的标签是绿色。

另外,“附件”功能,可以添加在线共享的需求文档的链接,便于查看更详细的需求细节。

同时,可以利用“清单”功能,创建此需求的研发工作项目(WBS),使用@可以指定到具体的人。

(2)插件

使用Trello建议使用Chrome浏览器,因为在Chrome的应用市场中,提供了很多Trello的免费插件,增强Trello的功能。

  • Card Color Titles for Trello:使用让卡片的标签,显示出文字。Trello的自带功能,标签只能显示一个色块。
  • Trello Card Numbers:展示Trello的每个列表一共有多少张卡片。在看板管理中,每个“泳道”是有限额和容量的概念,也就是说每个列表应该是有最多装多少卡片的限制。如果一个“泳道”塞满了卡片,就是会出现堵车。
  • TrelloExport:可以将Trello的看板看片导出成Excel。
  • True age for Trello card:展示一个卡片在一个列表中呆了多长时间。卡片就像库存,如果卡片长期在一个区域长期搁置,就会变成呆滞库存,成为需求管理的负担,应该尽快去掉。

9.4 结语

本章介绍了需求研发的看板模式,从而引申出了Trello的使用技巧。

Trello只是工具,关键还是背后的需求管理方法。

10. 需求管理的证伪

这是普拉姆需求管理的最后一章。最后,再聊一些关于需求管理的感悟。

10.1 遭遇危机

之前文章提到的需求管理方法,包括三个阶段:

  1. 需求收集
  2. 需求设计
  3. 需求研发

其中,每个阶段分别对应了三个模式:

  1. 急诊模式
  2. 登机模式
  3. 看板模式

其中,让整个需求管理流程顺畅进行的是 公交模型 。也就是说,需求收集阶段、需求设计阶段、需求研发阶段,变换成2周为一个管理周期的公交车,让需求按照固定线路上车,完成需求的生命周期。

这样的流程设计,可以让需求得到充分的评估和讨论。但是,缺点是一个需求给人的感知是经历一个月以上的时间,才能完成。

同时,需求池区分了不同的状态进行展示,其实存在重要性和优先级信息在需求研发阶段逐渐模糊的情况,特别是在测试工程师面对需求时,对于需求的重要性和优先级就无法正确判断。在有临时需求插队时,情况会更加严重。
在收集需求人意见的情况,对普拉姆需求管理方法进行优化。

10.2 优化需求管理流程

根据公交模型,将之前的三辆公交车(即三个阶段:需求收集、需求设计、需求研发),去掉需求设计阶段,缩减为两量公交车(即需求收集、需求研发)。

这样修改之后,需求的生命周期就会从结构上,最快缩短到4周以内,即在2个需求管理周期内完成。
同时对需求站会的开会时间,进行修改。将时间改在需求收集阶段接近尾声的位置,即每2周的周四开站会。这样给人感觉就是开完会之后,排好的需求在下两周就可以进行开发。

10.3 优化需求池

需求的优先级和重要性在任何阶段都应该是不变的。比如,即使需求进入到了测试阶段,高优的需求应该优先获得资源。

所以,根据以上的思想,对需求池的信息进行精简,主要是去掉状态信息,让处在研发、测试或者设计状态的需求,全部放在一个列表中,根据优先级和重要性进行排序。

需求的状态展示,就依托看板模式。

其中,Title是填写需求名称,Link是此需求的Trello卡片链接,可以快速将需求查看需求相关信息。Members是涉及此需求的需求人、负责人等。Label是指哪一个类别的需求,比如可以填写部门。

这样,只要没有完成的需求,就可以处在这个需求池中,根据重要性和优先级进行排序,所有资源根据这个需求池的顺序进行安排。

10.4 普拉姆理论的缺陷

用了将近10章的篇幅,将普拉姆需求管理方法的最佳实践阐述完。但是,还有几个问题,虽然有解决的理论,但是没有经过实践检验得出可行的方法。

问题一:如何评估工作量?

这是一个难题。在敏捷开发中,采用估点的方式,得到比较之后的相对工作量。但是,在实践中却是比较难实现。或者说,如何让需求人和负责人清晰明确的了解所提需求的工作量。

问题二:如何确定需求完成的deadline?

由问题一引发出如何评估需求完成的deadline。在实践中,需求人和负责人最想知道的是最终完成时间。但是,时间上进行会存在估不准的情况。毕竟,大家都不是先知。如何才能比较正确评估出完成时间呢?是不是要采用置信区间呢?

问题三:如何处理长期堆积在需求池中的需求?

资源永远是有限的。所以需求池中的需求,可能会积压很长时间。达到三个月的需求,应该是如何处理呢?如何说服需求人,去处理长期挤压的需求。也许出现需求积压的问题是需求缺少规划。

最后

我所写的都是屎, 唯有一点要坚持。

我将实践之后的需求管理理论写出来,里面有肯定有很多纰漏和漏洞。

虽然胡扯的地方很多,但是有一个观点,我一定会坚持。那就是普拉姆方法的宗旨:积极主动,知识共享,相互尊重。
不管任何需求管理的技巧,都应该围绕这个宗旨展开,这是超越任何方法论的方法。

水平有限,希望对你有所帮助。

作者:wideplum,产品经理/PMP认证/工业设计硕士,微信公众号wideplum,专注PM职业技能成长。

关键字:产品经理

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部