如何提高需求输出的效率？

子文 2023-07-24 22:48:33

一、前言

我们在做产品的过程中经常会遇到紧急的迭代需求，要求我们必须在非常短的时间内去完成。而如果留给需求设计的时间越短，过程当中留给我们思考的时间就会越少，这意味着我们做出来的功能更容易出现缺陷。

为了避免功能上线后出现缺陷，我们往往会通过加班、推迟交付需求的方式去提高需求的质量。可问题是，在上线时间点已确定的情况下，这种方法又会挤压研发、测试、验收的周期，同样会增加上线后出现缺陷的概率。

需求的质量会影响上线后的效果，需求的耗时又会影响研发的周期，我们似乎是遇到了一个难解之题。

细想的话可以看出，如果要降低上线后出缺陷的概率，就要想办法提高需求的质量、减少需求输出的耗时，即提高需求输出的效率，工作效率提升了，上面的困境也会迎刃而解。

道理大家都懂，但提升效率要实现起来并不是一件容易的事情，因为产品需求的输出是一个复杂的过程。

我们来把这个过程做一下拆分，就会发现其通常包含了需求调研、需求分析、界定需求范围、流程图设计、原型设计、编写需求文档、需求评审这么多工作内容。

如果我们找出了哪些工作内容存在较大的优化空间，去思考做这件事情的更优方法，或许就会找到提升效率的答案。

根据我自身在产品需求工作中的经验，针对不同的工作内容，总结出了以下几点方法。

很多产品人在刚开始做需求的时候，包括我自己在内，常常容易忽视需求调研的工作，把大量的时间花在了原型设计和需求文档上面。

这样做大概率会出现这样一种情况，就是完成需求后，因为需求方的不满意，而反复去修改。我们知道，当需求已经输出完成后，再去修改流程、原型、文档，将会耗费我们大量的时间。

当我们花了0.5天调研，只用了3天就完成了需求设计，看似很高效，结果因为方案被驳回，而多出了3天反复修改的时间，让原本4-5天可以做完的需求，前后总共用了6.5天。而且，周期越长越是复杂的需求，这样损耗的时间将越多。

我在刚毕业做产品的时候，经常遇到上述的情况，后来经过反思和尝试，总结出了一个规律：

就是尽可能地多花时间在需求调研和需求确认阶段，最好是完全清楚和理解需求方的诉求后，再开始去做需求方案。根据我以往的经验，一般至少需拿出40%的时间向需求的提出者、功能的使用者、其他干系人调研和确认，有时这个阶段甚至有60%的占比。

看似这种方式花费了大量的时间在前期工作上面，留给需求设计的时间非常有限，但在此过程中，因为我们加深了对需求的理解，明白了需求方的目的，进而提高了需求的确定性，所以通常最终的成效会是：降低了返工概率，减少了需求阶段的耗时。

需求范围也是影响我们效率的一个因素，同样是实现考勤需求，往简单了做可以只做成类似日历签到的模块，但是往大了做可以做成一个独立的产品，比如钉钉。

如果需求的范围太大，功能做的过于复杂，就会使成本增高，周期延长，如果功能太简单，又无法很好地满足需求。

因此，最理想的情况是我们只做那些重要的功能，提高功能的性价比，使其既满足业务上的诉求，又最大程度地节省成本。

当然，实际情况下我们控制需求范围并不那么容易，是因为存在一些客观上的困难：

我们在需求调研时，通常会收集到大量的零散需求，这些需求方提出的需求中，除了有核心诉求，还会有发散出的非核心的诉求，稍不控制，我们很容易就会过度设计，降低了性价比。
即便是已经非常准确提炼出了需求方的核心诉求，那么如何设计出高性价比的功能也会成为我们面前的难题，因为设计同样的功能，不同的产品经理给出的方案也会有所差异，有的清楚用什么方案去满足诉求性价比会更高，而有的会做出更复杂的功能，同样会扩大需求的范围。

解决的办法是：

需要在调研时，通过需求分析去判断哪些功能是必要的，哪些只是锦上添花；询问其这么做的原因，判断使用场景是否真实存在；是否能去掉，如果不能去掉，能不能放到以后实现。
需要我们脑海中积累的有足够多的功能方案，才能基于前面的需求调研，能够在短时间内给出高性价比的方案，可以通过2种途径积累，一方面是平时多体验其他产品的功能，另一方面是通过大量的项目经验去积累功能方案。