现在的位置: 主页 > 主打产品 > 文章列表

在变更执行的时候

作者:北京财贸天阶投资顾问有限公司 来源:www.usasheng.com 发布时间:2018-10-15 13:36:56
 

实战解法:如何做好需求变更? 实战解法:如何做好需求变更?

问题分析

首先对笔者所在项目做一个简单介绍:产品层面,我们是一个C端产品,需求主要来源于运营和策划,就产品阶段而言正处于转型期,现阶段主要以新功能探索为主;项目层面,由于功能较为复杂庞大,可切割空间不大,因此每个版本周期都较长(每个版本的产品准备周期,研发周期分别都在15~20个工作日左右),从产品设计到研发并上线的主干流程是具备的,如下:

实战解法:如何做好需求变更?

笔者定义需求变更包含两个层面,一是在产品设计阶段:需求评审结束,PRD文档定稿后再对需求稿进行更改,定义为需求变更;二是研发排期结束,定稿开发测试上线计划,之后凡是计划外的变化都定义为需求变更。

一开始项目上并没有对需求变更的流程规范做清晰的定义,因此项目实际推进过程中会出现诸多由变更引发的问题,下面结合实际问题做逐一说明:

问题一:变更多:一开始,项目最大的问题是需求变更很多,如果只是猛的一头扎进流程中去,反而浪费时间,所以我们尝试去分析这些变更的原因,看看是否能在源头堵住变更。经过判断,发现相当一部分变更是因为需求设计不够健壮或者交互对需求的理解不到位,在后续的阶段发现,进而才开始修改或新增需求。

问题二:变更不规范:变更是在所难免的问题,大家坐下来聊一聊,如果感觉不错那就把这个变更做了吧,这是我们之前的做法。但,由于缺乏一个明确的基本流程规范,一到变更的时候,处理事情往往丢三落四,进而会出现以下问题:

变更需求提出人太多,不知道听谁的变更提出的太晚,留给项目的时间不多了变更到底做不做,什么时候做等信息,在各个角色间的信息不同步

问题三:问题带来风险:项目过多关注于讨论变更本身以及变更的意义,往往忽略了实施变更往往会冲击原有计划,缺乏完整的风险分析;在变更执行的时候,没有相对固定的套路和章法,执行过程很松散,缺乏一些有效的监控,过程风险演变不得而知。

解决方案

我们在给出解法的同时还需注意到,项目管理所依赖的流程和规范若太强则使项目运转繁琐低效;但过弱则又使项目松弛散漫。因此,设计对应办法的时候需要充分考虑各种方案,选取最简单的方式来实现规范管理。

针对问题一,我们决定优化原有的主干流程,增加一个承上启下的环节做需求确认;针对问题二和问题三,我们规范了变更如何审批,变更如何执行两个过程;建立方式监控项目对变更工作量的承受情况。

主干流程优化

项目上根据实践经验发现仅靠需求评审无法完全保证需求方清楚的澄清所有需求,以及交互方充分的理解需求方的要求,其本质原因在于PRD并不能完整的描述清楚整个场景,许多需求层面的细节和串联即便在需求评审结束后依然可能覆盖不全;只有随着交互设计师把需求完善成结构严谨的逻辑图和场景说明,往往才会发现一开始需求设计不到位的情况,在大版本的情况下,等到整个交互稿都拿出来了再去做变更,变更代价过大/感受也不好。

因此,对于较为复杂的设计,在交互评审之前会拆分一个环节出来,做一个交互主场景的评审。通过新增的环节,确保需求的健全和完善,减少流入后续阶段的需求变更数量。

这个做法适用于策划变更PRD频繁,以及功能过于复杂伴随较大的潜在变更风险两个场景。PRD频繁变更频繁并不完全因为功能逻辑设计有漏洞,还有可能是产品规划/商业分析论证等前置流程没做好,这种背景下光是增加一个主场景的评审是没用的,读者需要仔细分析。

这样一个交互主场景的评审,具体操作建议如下:

时点:这个环节安排在需求评审结束后,交互评审开始前,且建议在需求评审后尽快安排,大概2个工作日内安排;内容:交互理解策划PRD说明后,初步制作交互稿,粒度达到覆盖主要的场景及完整的逻辑流程,然后召开主场景评审会与策划/需求方进行确认,确保需求理解正确和需求的健全。参与人:需求提出方(如运营,市场等),策划,交互变更规范明确

变更流程的规范涵盖两个主要方面,一是明确变更管理的基本理念;二是明确一旦要做变更,需要依序执行的步骤。

管理变更的理念>>

变更管理的核心在于评估需求变更的价值,然后决定做不做以及是否在当前版本做,我们尝试从更多角度去思考,包括说产品的规划,需求的特点。

推荐阅读/观看:南京网站建设 http://njwzjs.com.cn


  • 上一篇:马云计划下个周前往俄罗斯确定对Mail.ru的投资
  • 下一篇:最后一页
  •