一个需求的一生

1 评论 3604 浏览 18 收藏 11 分钟

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

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

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

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

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

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

一个需求的一生

一、需求的产生

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

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

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

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

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

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

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

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

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

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

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

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

二、需求的处理

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

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

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

一个需求的一生

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

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

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

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

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

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

一个需求的一生

禅道里各类角色的职责

任务有两类:一类是开发任务,有前端任务和后端任务;另一类就是测试任务。

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

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

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

三、需求的终结

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

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

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

四、总结

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

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

#专栏作家#

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

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

题图来自 Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 是不是第一句话的第一个词少了一个“需”

    来自陕西 回复