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

一个需求的一生

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

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

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

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

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

一个需求的一生

一、需求的产生

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

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

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

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

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

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

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

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

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

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

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

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

二、需求的处理

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

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

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

一个需求的一生

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

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

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

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

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

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

一个需求的一生

禅道里各类角色的职责

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

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

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

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

三、需求的终结

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

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

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

四、总结

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

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

#专栏作家#

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

本文原创发布。未经许可,禁止转载

题图来自 Unsplash,基于CC0协议

新一代大数据用户行为分析与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合分析用户行为数据和业务数据,可以自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客们必备的互联网数据分析软件。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据分析模型,是数据分析软件领域首款应用定量分析与定性分析方法的数据分析产品

发表评论

评论已关闭。

相关文章