做不完的需求 | 这个需求也要这周搞完?

需求,是永远也做不完的。

这边项目进度不达预期,那边新需求一个接一个提过来,待办事项越列越长……

像这样的窘境,各位同行朋友应该多少有所体会。

就像人来车往的十字路口,如果不加管理,很容易就会出现大拥堵;既占用了大量资源,又不能产出匹配的成果。

所以,就像交警指挥交通一样,我们需要对“需求”进行合理排期。

01

说到“需求排期”,或者“需求管理”,总有一种“产品经理居高临下指挥团队工作”的感觉。

为了避免产品新人有所误会,这里还是要强调一下。

从本质上讲,“需求”需要怎么去排期,是由各个需求自身的情况所决定的。

“先做这个需求,后做那个需求”,并不是基于产品经理个人的喜好或权威,而是因为某个需求本身就是更紧急的、更重要的。

从实操层面上看,需求的优先与否,是由各方干系人共同博弈的结果。

需求方的意见,执行团队的情况,领导的态度,现实的限制,等等。

产品经理并不是超越所有干系人的更高一级的存在。

产品经理只是其中的一个声音,或者是其中组织、协调、汇总的角色;也因此,想要做好“需求排期”,重要的是,诚实、敏感地观察现场情况,以及了解做事的基本常识。

除非你是要去管理一个庞大的产品矩阵,否则,“需求排期”并不需要很复杂。

02

首先,我们需要简单地对“需求”进行拆解。

举个例子:

今天老板把你叫到办公室,说了这么一段话:

“有个需求要你搞下……因为某些商务上的原因,A类产品需要引导用户走X流程来购买……对,在这个页面开始,改为跳转这个页面……嗯?用户的信息要自动带出来啊,干嘛让用户再填一遍……对,最后A类产品到这个地方来支付……”

你从办公室里面出来,心里估摸着,这个需求也不是很复杂,于是就打算着手开干了。

但是,且慢。

仔细想想,这里面真的是“1个需求”吗?

其实不然,这里面有2个需求。

1)A类产品引导用户走X流程来购买。

这里涉及到A类产品,且因为“某些商务上的原因”,需求较为紧急。

2)进入购买页时,自动带入用户信息。

这里涉及所有的产品,虽然有利于提高用户体验,但是不急于这一时。

更重要的是,“需求2”是否实现,完全不影响“需求1”!

如果不进行拆解,囫囵吞枣地当做“1个需求”去做,就有可能出问题。

简单来说,可能有2种情况。

  • “需求2”涉及的范围广,需要的工作量较大;所以,“需求1”虽然紧急,却被无关的“需求2”拖了进度,导致上线时间延后。
  • 团队优先完成了“需求1”,并部分上线了;因为每个开发周期都有新的紧急项目,所以未完成的“需求2”,在接下来的几个开发周期中,都被排在了后面。

第2种情况,我个人是很讨厌的。

往往需要我花费很多精力去沟通推进,最终延迟了非常多时间,“需求2”才能完成上线。

并不是需求方的“1次沟通”,就是“1个需求”。

产品经理需要根据需求范围、工作量、紧急程度等因素,对“需求”进行拆解,分开处理。

03

我认为,需求在拆解之后,原则上每个需求都应该单独立项,分开处理。

这样,沟通效率更高,而且项目管理起来也更简单、更灵活。

当然,也有例外的情况。

大多数时候,产品经理手上都会积压着若干待处理的需求。

在对这些需求进行排期时,需要观察各个需求之间的关系。

有时候,几个需求合在一起处理,效率反而更高。

比较常见的情况有以下几种:

1. 几个需求,都在同一个模块内

举个例子:

  • 表单页,新增一个上传文件模块。
  • 表单页,优化一个底部弹窗。
  • 表单页,调整错乱的样式。

虽然这几个需求之间没有关系,但是都涉及同一个模块。

如果紧急程度都差不多,那安排到一起处理,效率会高很多。

2. “需求1”的实现,会影响到“需求2”

比如说:

  • 对登录注册模块进行改版。
  • 新增一种登录方式。

容易想到,如果登录注册模块改版了,那在做“需求2”时,就得按照新的样式去策划。

如果,先按照旧的样式把“需求2”搞出来了;那等到做“需求1”时,“需求2”也得重做。

这肯定是会被diss的。

所以,这种情况,就得合并成一个项目去处理。

另外,如果“需求1”不紧急、“需求2”紧急,那么合并后,“需求1”的紧急程度也得同步提升。

3. 可以用一个更大、更通用的需求,把几个关联的小需求cover掉

比如说,某个流程,已经收到了好几个“负面反馈”。

那么,可能就得考虑,是不是需要对整个流程进行调整,而不是“一个反馈打一个补丁”。

比如说,有好几个产品都有类似的特殊处理需求。

那么,可能就得考虑,是不是做一个适用全部场景的通用功能。

当然,什么时候需要把需求“升级”,这个度并不好把握。

有时候反而会事倍功半。

比如说,花了大力气搞了个通用的系统,结果没过多久这个业务就不做了,那功夫也就白费了。

04

上面,我们又是拆解需求、又是合并需求,其实都还在“分析”阶段。

最终,我们得把需求真正安排下去,才能落实“执行”。

对于每个需求经办人来说,自己的需求都是最要紧的。

如果你问他们要什么时候完成,大概率会得到“最好这周完成”的回答。

但这又怎么可能呢?

“紧急”和“紧急”之间,“重要”和“重要”之间,肯定是有差异的。

要区分这些差异,其实也不是很困难。

只要对公司和产品有基本的了解,当我们把需求统一进行对比时,各自的优先级也就能大体区分得出来。

完全不用像有些方法说的,各种打分、各种计算,搞得那么复杂。

区分优先级之后,怎么进行排期,其实也很简单。

我认为,只需要遵循一个基本原则,那就是:

先做紧急的,再做重要的,然后在这期间穿插着做不重要的。

大家都知道,“四象限法则”里面,有“紧急重要”和“紧急不重要”。

但是,我认为,在实操层面,这个“紧急不重要”,是个没有意义的概念。

如果它不重要到可以忽略不做,那它压根就不在工作安排的范围内,也就无所谓“紧不紧急”了。

如果它非常紧急且非做不可,那再讨论“重不重要”就没有意义了,做就完事了。

比如说,领导就是要改某个图,虽然不重要,但是下周例会上,领导就要看到结果。

那还纠结什么“重不重要”?赶紧开干就是了!所以,判断为“紧急”的需求,无需赘言,优先做就是了。

做完“紧急”的需求,再安排“重要”的需求。

这个应该很好理解。

那么,为什么是“穿插着做不重要的”,而不是“做完重要的,再做不重要的”?

那是因为,“紧急”和“重要”的需求,永远都没有“做完”的时候。

每个开发周期,都会有新的“紧急重要”需求。

所以,只能在各个开发周期内,当团队工作量没有饱和的时候,穿插着搞点不重要的项目。

比如说,在做一些大项目的时候,同时塞点“改个弹窗”、“加个静态页”之类的小需求。

有时候,不重要的需求,可能也是工作量不小的大项目。

但是,也一样。

在每个开发周期,只分配很少的资源在这个不重要的项目上。

可能要经历好几个开发周期,一点点地去完成这个项目。

但是,要注意,当这个项目进入最后阶段时,需要有意识地调高其重要级,倾注更多的资源进去。

这样才能确保,经过漫长的、断断续续的开发流程后,项目还能达到要求的质量。

基于这样的基本原则,再结合团队的情况和做事的常识。

这样去安排工作,我觉得,就足够了。

要知道,实际一线的工作情况,远没有书上说的那么“精益”。

抓大放小,灵活应对,反而才是合理的。

05

众所周知,“原则”都是用来“违反”的。

所以,这里说一个我最近负责的“打脸”的项目。

那是一个用户学习系统,用户在这里学习、练习、考试,同时还有学习时长的要求和考核。

需求范围比较大,而且相互之间关联密切。

按照上面说的,我应该把它当做一个完整的项目,统筹安排。

问题是,这个需求非常紧急!

就是那种“早上刚提了需求,下班前就要给方案,明天要设计完,周末就要上线“的需求。

没办法,我只能强行把这个项目拆分成“学习模块”、“练习模块”、“考试模块”、“时长记录模块”、“时长考核模块”。

  • 因为学习时长不达标,最快也得几个月后才会有影响,所以“时长考核模块”先忽略。
  • “学习模块”先策划。
  • 策划“练习模块、考试模块”时,“学习模块”进入设计阶段。
  • 策划“时长记录模块”时,“练习模块、考试模块”进入设计阶段,“学习模块”进入开发阶段。
  • “学习模块”先上线。虽然功能不完备,但能满足最基本的业务需求。
  • ……

后续模块开发时,前面不完备的模块,自然需要进行返工。

但这也是没有办法的事情。

只能“成本”换“时间”。

因此,还是那句话,要具体情况具体分析。

#作者#

简明产品论,微信公众号:简明产品论(ID:JianMingPM)。在真实的世界里做产品。

本文

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部