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

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

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

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

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

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

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）。在真实的世界里做产品。

本文

版权声明

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