您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 需求管理 > 正文

5分钟让你学会做需求管理

发表于:2018-10-05 作者:从零开始的菜月昂 来源:简书
  需求管理中的角色——以后台产品为主
  需求人,即真正提出需求并描述需求细节的角色。这个角色可以是任何干系人,毕竟产品经理是一个负责从四面八方收集需求的人。需求人一般要与其所在的部门联系在一起,有助于判断所提需求的立场。
  负责人,负责人就像一个漏斗和筛子一样,初步筛选一遍需求。毕竟,评估需求也是要花费时间,特别是占用研发同事的时间。
  产品经理,即我们自己,需求管理的组织者、推动者。以“积极主动”的态度,与需求管理的角色进行沟通。
  研发leader,研发资源的管理者。在这里的研发经理,一般是带四、五个人小团队的级别。因为,他们能够了解每个研发工程师的工作和能力,协助评估需求优先级。
  研发工程师,即实际参与研发需求的程序员。
  测试工程师,即参与需求测试的测试人员。可以根据公司的组织架构,增加测试经理的角色。测试经理的级别也是带四、五个人小团队。
  在需求管理中,产品经理要当成一个桥梁,与不同的角色,进行沟通和协作。在后面,需求管理的流程和需求看板的管理方法,都会与这些角色紧密相关。
  需求管理周期
  在比较成熟的互联网公司中,一般会采用类似笔者所在部门实践的火车模型发布模式。火车模型发布模式是以固定的周期持续发布产品,如果某项既定功能未完成,就挪到下个周期发布的开发方法。
  版本迭代的周期,一般是80小时,即2个星期。80小时原则,来自于项目管理中的工作分解结构。根据项目管理的一般经验,将一个项目中的工作,按照80小时的工作量进行拆分比较合理。所以,每一类需求管理活动按照2周的工作量进行。
  严格遵守需求管理活动的三个阶段:需求收集、需求设计、需求研发。固定的周期,可以按版本号来区分,赶不上已经封板的版本功能的需求,则往下一个版本进行排期。
  具体流程可以参照以下的流程图
  其中,圆角方形代表操作步骤,直角方形代表输出物。
   http://www.51testing.com/attachments/2018/07/15243603_201807120959001S3iB.jpeg
  在这里复述一下整体的步骤。
  1、需求人提交需求。提交需求的模板,之后的章节会介绍。
  2、负责人收集需求文件,初步评审需求。在这里,如果需求存在不合理的状况,特别是业务流程不合理,负责人可以将需求打回需求人重新整理。
  3、产品经理、研发leader初步评审,并放入待排期列表。产品经理拿到负责人评审通过的需求,与开发经理进行初步评估,判断需求是否可行。可行的需求放入待排期列表。待排期列表的模板,之后的文章也会介绍。不合理的需求,也会打回。
  4、根据待排期列表,需求人、负责人、产品经理、研发leader评定待排期列表中的需求,生成待开发列表。在这个过程,会应用一个工具——排期站会。这个工具,之后也会介绍。经过排期站会后,形成待开发列表。
  收集需求的模板
  模板应用在需求收集阶段,方便需求人提供和描述相应需求,便于负责人、产品经理、研发经理等角色评审需求。
  利用此需求模板,可以快速提取需求信息,便于存档和查阅。
   http://www.51testing.com/attachments/2018/07/15243603_201807120959002pEJE.png
  模板中各字段大致需要这么填:
  需求提交部门,填写需求人的所在部门。
  功能使用角色,比如可以填写业务主管、业务经理等。可以是使用者的职位描述。
  使用频次,即单位时间内预计使用功能的次数。比如,10次/月。方便判断此需求的优先级。
  提交时间,记录需求提交的时间,便于使用“先入先出”原则。
  “先入先出”原则,来自于仓储的概念,指的是先进入仓库的商品先出库。比如,食品行业有保质期的要求,需要生产越早的食品,越早出库。
  优先级和重要性,这是需求管理和需求池中的核心,下面会有具体介绍。
  简单的说,优先级是对需求按不同的类型进行划分。通常见到的优先级划分是高、中、低,或者用简单的数据代替。优先级是部门与部门之间的需求比较。
  重要性是对需求打分,对优先级的补充,是部门内部需求的比较。
  系统功能位置,对于系统功能优化类的需求,可以注明原有需求的位置,或者想要添加的功能页面。
  业务背景,或者叫需求背景。可以想象一下,如果需求是一部小说的话,是不是要在开头介绍下这个小说发生的时间、地点、人物等。
  预期完成效果,描述需求实现后,预期实现的效果。
  需求说明,以任何形式来描述需求内容。
  需求池的核心:优先级和重要性
  需求池,就是放多个需求的地方。需求池是更像是一个游泳池,需求有不同的泳道。而泳道代表着需求的不同状态。
  需求的状态一般包括:筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。
  每一种状态的需求,可以汇集成一起。比如,待排期状态的需求,可以汇总成列表样式,叫做待排期列表。
  所以,需求池是多种状态的需求,以合适的形式展现的需求汇总。
  需求池列表模板可以包含这些字段:
   http://www.51testing.com/attachments/2018/07/15243603_2018071209590037kW0.png
  待开发状态以后的需求,可以用看板的样式进行展现。
  优先级——需求的分类和排序
  需求的优先级是再熟悉不过的名称了。
  优先级表现形式,一般是数字123、汉字高中低,或者字母ABC等。优先级可以用来给需求进行排序,优先级高的需求,优先开发。
  同时,优先级也可以对需求进行分类。或者说,对不同的优先级给予一个不同的释义。
  举一个例子:
  优先级等级
  5:涉及公司战略和规划相关的需求
  4:业务发展/收入增长类相关的需求
  3:降低成本类相关的需求
  2:提升工作效率相关的需求
  1:提升系统用户体验类相关的需求
  需求优先级的定义,可以根据所在公司和组织、所经营的业务进行综合评估和划定。
  需求的数量一般会比需求优先级要多。所以,多个需求可能会同一个优先级,同一个优先级的需求这时候就需要用重要性来排序。
  重要性——优先级的辅助
  重要性是对需求进行打分,分数的范围是1-100分。每个需求会被赋予1个分数,每个需求的分数是唯一的。
  例如,需求A、需求B、需求C,分别赋予了97分、85分、90分。那么,根据分数从大到小进行排序,那么优先做分数大的需求。
  另外,在做重要性评分的时候,建议每个需求之间不要打连续的分数。比如,需求A的重要性打95分,需求B的重要性最好打92分。分数中间的间隔,用来插入需求。毕竟在工作中,有很多突发的需求会插入进来,以调整研发计划。
  排期站会
  在敏捷开发中,站会是一个很有用的工具。在5-10分钟的时间中,快速交流信息,推进项目。
  之初,排期会议也是安排在会议室之中,大家坐着沟通信息。实际上,人一旦没有紧迫感,就容易天马行空的沟通起需求的细节。值得注意的是,排期会不是需求评审会。
  一般,排期会上要评定20-30个以上的需求,每个需求讨论3-4分钟,将是个极为漫长的过程。
  所以,让大家站着开会,以一种不太舒服的方式,压缩自己的思路,快速沟通问题。
  举行排期站会的一般流程如下:
  1.发送会议邀请
  排期站会的举办时间是以固定时间举办。按照之前文章提到需求管理周期,一般是2周举办一次。具体的开会时间,要与各方协调,特别是避开例会时间。
  与会人一般包含:需求人、负责人、产品经理、研发经理、测试经理等。
  2.在规定时间开会,提前公布讨论需求组的顺序
  站会中讨论的需求,会来自不同需求组(关于需求组的概念,请上一章:需求池的核心:优先级和重要性)。每个需求组对应着不同的人,为了避免浪费大家的时间,按照讨论组的顺序,让对应的人按顺序参加会议。
  3.按顺序召集大家开会
  首先介绍当前需求的开发情况,由会议主持人(一般是产品经理)介绍当前的开发状况,特别是沟通时间点。
  4.评审进入下一阶段的需求
  主持人可以针对需求池的内容,沟通可以进入到下一阶段的需求。
  但是,主持人要控制住节奏,防止大家陷入需求细节的讨论。对于一时没有定论的需求,要标注出来,邀请需求相关方在会后讨论。
  需求开发看板
  最后给大家找个看板的样例,看板模式简直可以说是程序员开发的利器,划重点,开发巴巴喜欢!
   http://www.51testing.com/attachments/2018/07/15243603_201807120959004tLqJ.png
  在开发需求的过程中,各需求的相关人不用再去寻找邮件,或者翻看电脑保存的文档。
  每个人都可以通过看板,看到每个需求的实时状态。每个人都可以去拖动卡片。提前预知自己的工作量。比如,测试工程师就可以通过看板,大概预知有多少卡片在待测试状态,从而预估自己的工作量。
  当然,看板和卡片可以用采用多种形式展现。