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

发表于:2017-7-31 15:37

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:wideplum    来源:人人都是产品经理

分享:
  通过这篇文章,总结自己在工作实践中需求管理的方法论——普拉姆方法。总结这个方法论的特点是,用最轻量化的投入,与他人协作,并管理需求,推动需求上线。这套方法论组合了项目管理、敏捷开发的知识,希望能对大家有所帮助。本文适合0-2岁产品经理阅读,产品大牛、敏捷管理大师请绕过。
  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)需求管理流程
  需求管理流程,是指在需求管理中,按照顺序依次进行需求管理活动。
  需求管理活动按先后顺序分为三个阶段:
  需求收集
  需求设计
  需求研发
  再强调一遍,这三个阶段是依次进行的。先进行需求收集、在进行需求设计、最后进行需求研发。
  每一阶段的需求管理活动对应一个指导原则。指导原则就是急诊模式、登机模式、看板模式。急诊模式指导需求收集,登机模式指导需求设计,看板模式指导需求研发。
  在文章的开头,我用急诊室的场景,介绍了急诊模式。后续的章节中,我会介绍剩下的两种模式:登机模式和看板模式。
  (2)需求管理周期
  需求管理周期,简称”周期“,是需求管理活动按顺序重复出现,并完成需求管理活动的时间叫做需求周期。
  普拉姆方法的需求周期,是80小时,即2个星期。80小时原则,来自于项目管理中的工作分解结构。根据项目管理的一般经验,将一个项目中的工作,按照80小时的工作量进行拆分比较合理。所以,每一类需求管理活动按照2周的工作量进行。
  换句话说,需求收集、需求设计、需求研发是三辆同时发车但路线不同的公交车,三辆公交车运行一趟的时间是2周。每个需求相当于是乘客,要根据路线(需求管理流程)在公交站等车。当然,每个需求的终点就是发布上线。
  (3)需求时间
  在需求管理活动中,进行某一项具体活动的时间点,就是需求时间。
  一般,需求时间意味着规则。比如,需求设计阶段的周二的下午2:00,需要开排期站会,这是一个约定好的时间,需求的相关方都必须要来。排期站会后面再介绍。
  (4)运转模式
  如果一个需求从开始到发布上线的生命周期来看,公交模型是下面这个样子。
  从需求管理周期的角度,无数需求按照公交模型去运转着。从参与到需求管理的角色来看,每一个周期中的需求收集、需求设计、需求研发阶段,参与者的工作是连续可预测的。每个角色各司其职,让需求管理顺畅的进行下去。
  3.4 总结
  这章通过介绍急诊室的故事,也就是急诊模式,来引出破局”越快越好“类需求的方法,以及后面要介绍的登机模式和看板模式。这三个模式用来分别指导需求收集、需求设计、需求研发三个阶段的需求管理活动。
  同时介绍了推动需求运作的公交模型,让需求管理活动具有预测性和规划性。
  本章之后,将依次介绍三个模式和三个阶段对应的方法和工具。

31/3123>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号