极速六合_极速六合计划_极速六合走势图_极速六合_首页-彩70

极速六合_极速六合计划_极速六合走势图_极速六合_首页-彩70

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

时间:2019-01-06 05:32来源:未知 作者:站长 点击:
通过这篇文章,总结自己在工作实践中需求管理的方法论普拉姆方法。总结这个方法论的特点是,用最轻量化的投入,与他人协作,并管理需求,推动需求上线。这套方法论组合了项目

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

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

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

  我的工作环境是,作为后台产品经理,处在业务运营团队和技术团队之间,要作为一个桥梁,保障业务运营团队从我这里输出高质量的需求,也要保障具有不同知识背景团队,能过通过需求,高效沟通,快速推进需求上线。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  单位时间内预计使用功能的次数。比如,10次/月。方便判断此需求的优先级。

  一个系统需求,会牵一发而动全身。通过填写此需求可能涉及到的其他部门,来评估需求带来的可能影响。也能驱动需求人在提需求时,增加跨部门思考的维度,提升需求的可行性。

  对于系统功能优化类的需求,可以注明原有需求的位置,或者想要添加的功能页面。

  或者叫需求背景。可以想象一下,如果需求是一部电影的话,是不是要介绍这个故事发生的时间、地点、人物等。以此类比,填写相关的需求背景。

  需求池是更像是一个游泳池,需求有不同的泳道。而泳道代表着需求的不同状态。

  需求的状态一般包括:筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。

  每一种状态的需求,可以汇集成一起。比如,待排期状态的需求,可以汇总成列表样式,叫做待排期列表。

  当然,需求池中不同状态的需求,可以用多种形式进行展现。比如,待排期的需求可以用列表的样式进行展示。待开发状态以后的需求,可以用看板的样式进行展现。

  需求优先级的定义,可以根据所在公司和组织、所经营的业务进行综合评估和划定。

  需要注意的是,重要性的分数只是用来做排序,不代表其他信息。比如,重要性是100分的需求不是50分需求的2倍。

  优先级和重要性是需求池的核心!什么是核心?优先级和重要性一旦确定,将贯穿需求的整个生命周期,所有的资源将根据优先级和重要性来被安排。

  换句话说,如果是高优先级和高重要性的需求时,不管在需求的哪一个状态,都会被优先分配资源。

  项目组合管理是指在可利用的资源和企业战略计划的指导下,进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化,确保项目符合企业的战略目标,从而实现企业收益最大化。

  这个概念有点绕,只要关注一个词——“符合企业战略”。所以,划分需求的优先级和重要性,是紧密围绕着企业和组织的战略。

  在符合企业或组织战略的核心目标下,通过项目组合管理的方法,先对收集到的所有需求标注好优先级,再对这些需求进行分组,形成需求组。分组的依据可以是部门,可以是项目。对这一组内的需求,赋予不同的重要性分数。因为需求组之间划分的标准不同,所以不同需求组的需求,重要性分数不具有可比性。

  因此,从实现企业战略的角度,高优先级的需求在划分给不同需求组后,可能并不会赋予很高的重要性。

  排期会上要评定20-30个以上的需求,每个需求讨论3-4分钟,将是个极为漫长的过程。

  所以,让大家站着开会,以一种不太舒服的方式,压缩自己的思路,快速沟通问题。

  排期站会的举办时间是以固定时间举办。按照之前文章提到需求管理周期,一般是2周举办一次。具体的开会时间,要与各方协调,特别是避开例会时间。

  站会中讨论的需求,会来自不同需求组(关于需求组的概念,请上一章:需求池的核心:优先级和重要性)。每个需求组对应着不同的人,为了避免浪费大家的时间,按照讨论组的顺序,让对应的人按顺序参加会议。

  站会的场地可以选在工位旁,较大的过道或者走廊上。这样便于参会人快速到达和撤离开会现场。也可以让一些让其他同事,快速参加会议。

  一般大家要围绕着需求池来开会。而展示需求池的道具,可以一块儿屏幕或者投影。这样可以集中大家的焦点,和快速展示信息。

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

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

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

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

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

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

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

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

  看板由不同的“泳道”组成,需求以卡片的形式,从最左端开始,运行至最右端结束。

  一般“泳道”的划分,可以按照需求的状态划分。也就是说,需求卡片从左向右的流转,就是需求状态的流转。

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

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

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

  Trello Card Numbers:展示Trello的每个列表一共有多少张卡片。在看板管理中,每个“泳道”是有限额和容量的概念,也就是说每个列表应该是有最多装多少卡片的限制。如果一个“泳道”塞满了卡片,就是会出现堵车。

  TrelloExport:可以将Trello的看板看片导出成Excel。

  True age for Trello card:展示一个卡片在一个列表中呆了多长时间。卡片就像库存,如果卡片长期在一个区域长期搁置,就会变成呆滞库存,成为需求管理的负担,应该尽快去掉。

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

  这样修改之后,需求的生命周期就会从结构上,最快缩短到4周以内,即在2个需求管理周期内完成。

  同时对需求站会的开会时间,进行修改。将时间改在需求收集阶段接近尾声的位置,即每2周的周四开站会。这样给人感觉就是开完会之后,排好的需求在下两周就可以进行开发。

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

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

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

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

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

  不管任何需求管理的技巧,都应该围绕这个宗旨展开,这是超越任何方法论的方法。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、招聘、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里分享知识、招聘人才,与你一起成长。

(责任编辑:站长)
织梦二维码生成器
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片