一个需求的一生

求这个词对产品的意义，就像代码这个词对于开发的意义；一个需求由提出到解决经历了哪些过程？一个需求的“一生”是怎样的？让我们随着作者的思路看下去。

相信对于产品人员来说，听到频率最高的一个词莫过于“需求”了。

业务人员或者客户会对产品说：这里要加一个需求/功能；产品会对各方人员解释说：这个需求是这样的，这个场景是那样的……为了加需求和改需求，产品和开发相爱相杀的案例也不少。

可以说，产品的日常工作，最绕不开的一个词，就是需求了。

我们每天要接收需求，要处理需求，要传达需求。需求这个词对产品的意义，就像代码这个词对于开发的意义。

对于产品每天都要打交道的“需求”，我突然想聊一聊“一个需求的一生”这个话题。首先我们看一下关于需求的流程：

一、需求的产生

需求是怎么来的呢？很多人会以为需求产生的源头是产品经理。其实并不全是。需求方有几类人员：客户、老板、产品、业务/销售、测试。而需求的产生也并不是一开始就是需求（此类需求称为“纯需求”），也有从bug转化过来的需求（此类需求称为“bug转需求”）。

纯需求一般是客户提出来较多，业务/销售传达的纯需求也是客户的想法。客户在日常使用产品的时候，会发现有的产品的流程和实际业务有出入，会觉得“系统不好用”。这个时候他们经常会联系技术支持人员或者业务人员，传达自己的想法。

客户在提需求的时候也会有不同，一种是根据实际业务提需求，一种是根据竞品提需求。

如果是根据实际业务提需求的话，在提需求的时候，客户会告诉你实际的业务流程、当前系统存在的问题以及他所期望的效果。虽然这类需求算是比较明确的，但是产品在接到这类需求的时候，还是需要多问多思考；因为有的时候客户提的需求有可能是“伪需求”。

他们可能觉得业务上需要这个，那就得增加这个功能；其实有些问题可以通过更好、更优的方案来解决。这就需要产品深入地思考客户的“痛点”到底是什么，通过对客户的诉求抽丝剥茧，找到他们真实的需求。

如果全部按照客户的描述去产出方案的话，虽然能够满足客户的需求，但是对整个产品未必是有益的。

除了根据业务提需求，客户还会根据竞品提需求。有可能客户试用了或者看到了其他竞品的某个功能，觉得很不错。会过来跟我们提需求：“人家XX系统的那个签合同的功能可好了，现在你们系统没有，很不方便，需要加一个”。

这种需求其实是比较明确的，连竞品帮产品都找好了。产品如果确定了要做这个需求的话，直接去梳理一下竞品的逻辑，然后根据自己系统做好调整就可以了。

还有一类需求是bug转需求，这些一般是由测试人员发现。

测试人员在测出或收集bug的时候，会将这些东西推送到产品经理那里，由产品给出解决方案和排期。还有一些比较复杂的bug，在迭代里做不完，就会转成需求。产品可以有更多的时间进行规划。

产品经理和老板也经常会根据系统的规划提出需求，产品和老板会根据自己对用户、业务、当前系统的了解，对系统提出改进和优化。这个时候就会有一些优化的想法，这些也是“需求”。

当然，不管是产品还是老板，在提需求的时候都应当实事求是，考虑自己产品的定位和开发的能力。不然的话，只根据自己天马行空的想法来，提出类似“手机主题颜色根据手机壳变化”这种无理需求，很容易被吐槽，也很容易挨打。

二、需求的处理

需求产生后，需要产品人员去进行处理。接到需求后，不管是大需求还是小需求，产品需要找到提出需求的人，去了解这个问题的前因后果。通常由于开发资源、产品时间的问题，很多需求会来不及做。

那么很多需求就会堆积在产品人员这里。如果产品没有对这些需求做好整理和排期的话，很容易遗漏需求，会容易这个需求“永不见天日”，问题就没办法解决。

在整理需求的时候，产品人员需要记录需求的模块、页面、提需求的人、需求提出的时间、需求来源、具体问题、排期、优先级等问题。你写的越详细，等过段时间忘了这个需求的时候，看需求记录能够让自己快速回想起该需求的相关内容。实在不行，找到提出这个问题的人，再重新了解一遍就够了。

当需求了解得很透彻了，产品经理就需要静下心来思考怎么解决这个问题。如果是小需求的话，产品可以快速地给出解决方案，把这个问题放在最近的迭代里即可。

如果是比较复杂的需求，则需要立项，把这个当着一个项目来做了。（可查看以往的文章→ 产品新人第一次负责项目应该怎么做？ ）

大需求的话，则需要产品画出原型，写好PRD。

这个时候“需求”已经变成为“方案”了。

此时产品可以邀请业务人员、其他产品进行方案评审，方案评审通过后进行技术评审。这一轮一轮的评审和修改过去后，这个需求已经变成“成熟方案”了。

当方案确定后，项目经理要在禅道（需求管理工具）里建项目。而产品则需要在该项目下建任务。

禅道里各类角色的职责

任务有两类：一类是开发任务，有前端任务和后端任务；另一类就是测试任务。

在写开发任务的时候需要注重描述方案、功能、交互。

而测试任务除了这些外，还需要产品确定好此次修改的影响范围。产品需要和开发人员，不管是前端还是后端，确认好此次改动的范围、改动的影响范围，这样测试人员在测试的时候就能够提前评估测试的工作量，最大程度地扩大测试范围。

不然的话，测试很容易漏掉一些需要测试的地方，容易导致上线后产生其他的bug。

三、需求的终结

当这个需求开发完了，测试完了，这个需求也就结束了。需求在进入开发之前，产品人员要做的是将需求准确地传达给开发人员。开发人员将需求开发完成后，测试就可以对这个功能进行测试了。

这时候产品需要确认测试用例，然后自己也需要进行测试。主要测试页面样式是否和自己的想法一致，功能是否有效，业务流程能不能顺利进行等等。

当功能上线后，这个需求在禅道里被点击“完成”后，这个需求也就终结了。

四、总结

用户所看到的是一个完整、优秀的产品，而对产品、测试、开发人员来说，这些都是由一个个或大或小的需求组成。尤其是产品，要有整体规划产品的格局和视野，也要有拆解需求、处理需求的细心和效率。

一个优秀产品的开始和迭代，都是在不断提出需求，解决需求的过程中完善的。

#专栏作家#

异彩，微信公众号：一只蜗牛慢慢跑，人人都是产品经理专栏作家。从事房产管理系统的产品工作，关注To C产品的交互设计、运营、结构设计和商业模式。在成为一名优秀的产品人的路上努力前行。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于CC0协议