【起点精选】需求的过滤筛选和排序:二性三度一数据

作者:地球科学    来源:未知    发布时间:2019-12-18 20:14    浏览量:

其次再给这六个维度的分制加上一个权重,谁的权重高,谁的权重低,无非是影响维度的影响力而已,按照你们当前业务发展重点来制定。

同一个问题用户反馈的数据量

  1. 总结

二是在沟通的过程中很多事情需求方也未必能想得到,如果产品经理帮他们想到了或是根据他们的需求给出了更好的方案,这样肯定会达到更好的效果,也会提高需求方对于自己的信任度。

该需求可能影响的业务人员或部门

如果是做产品运营的,因为他们的互联网思维意识比较强,所以无论对于概念的理解还是功能的使用上都会更熟悉,在需求的沟通过程中也会更顺畅一些。相对而言,跟市场、客服部门的同事沟通起来就会差一些,因为这些部门的人有很多都属于小白用户。

首先跑一个SQL语句,select avg、max和min,几十毫秒就能输出目前平台中已有内容标题长度的平均值、最大值和最小值

因公司内部需求而做的产品,很大程度上也是供公司内部人员使用的。在产品设计中,我们有一条原则是先有后优,本身也是后台,更注重实用性,所以本着优先上线、缩短开发成本的原则,对于产品的交互和美观性方面的要求相对也都会低一些。

产品经理:“好嘛~~,我先了解了解嘛”,态度一定要积极。

针对用户的反馈做一些相关的数据分析,看问题的用户覆盖范围

我就说产品经理也要懂一点数据分析的知识嘛

理想的情况,如果业务部门跟产品经理合作的过程中,双方都能够积极的配合,会使得产品上线的过程更加顺利。反之,则需要产品人员的主动意识和责任心更强一些。

来自老板的战略规划,一定是扯淡的

不同的需求,对产品经理也会有不同的影响。前者的优点在于可以充分发挥产品经理自己的想法;而后者的优点在于需求比较明确,产品人员只需给出解决方案即可。缺点在于沟通成本会比较高,对产品经理自身想法的发挥也会有局限性。相比较而言前者产品的风险性会更高,之所以这么说是因为后者的需求很多时候满足的都是公司内部,例如CRM系统满足编辑使用,这类产品虽然用户量不大,至少有其用处。面向用户的产品,如果用户每需求那产品最终就会被关闭,产品经理就要看到自己的努力付诸东流了。

对于此方法,磊叔屡试不爽,也分享给大家。

至于怎么优化,要综合三个方面进行考量:

该需求是否有其他类似的实现方式

我曾经做过一个奖品管理系统,需求方提出了他们想看到的数据,我当时规划的后台已经能够满足他们,后来我给他们添加了一个统计功能,便于他们查看某个活动奖品的发放情况以及花费的费用等,因为当时觉得这些会是他们非常关注的信息,他们看到后就感觉很欣喜,觉得很有用。

该需求是否有成本更低的实现方式

需求的背后通常都是同事自己在工作中遇到了困难,希望通过开发产品来节省自己的时间和力气、提高工作效率。例如说想在管理后台增加定时上线功能;在向产品人员提需求的过程中,运营方会说明自己在工作中遇到的问题,但是具体的解决方案就要靠产品经理自己了。

如果这个需求实现了,那么这个需求的频度是怎样?

我曾经做过一个EDM系统,其中有一个细节给我的印象很深:运营人员把他们的一个需求描述的很复杂,还跟我描述了他们做邮件营销的整个工作流程,拿他们的工作文档给我看,其实终归他们只是需要看一下自己的营销邮件发送时间与别的产品是否有撞期的情况。想要的东西其实很简单,但却费了很多唾沫。

这套“二性三度一数据”的方法其实也是建立在很多前辈宝贵的总结基础上,再次也感谢他们的贡献。

图片 1

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

毕竟运营人员是直接跟用户打交道的,他们会把一些用户的反馈转述给产品经理。如果是转述用户的需求,就需要寻找满足需求的方法。这也分两种情况:如果是用户提出的新功能就要衡量是否有必要开发新产品满足;如果是对现有产品的改善建议,那就要寻找现有产品的缺陷,继而优化改善。

很简单,首先给这六个维度分别加上一个分制,5分制,10分制,100分制,无非是影响接下来过滤、筛选和排序的粒度而已,随你高兴。

实际情况中,如果产品经理一味听从需求方而没有自己判断的话,会发生一种情况就是把需求的满足方式设计的特别复杂,结果给开发人员带来了很大工作量。但是当产品经理的设计与需求方的设想有出入的时候,多半还是要产品方作出让步。

如果我们简单分析一下产品的需求,就能看到一个清晰的模式:

有两点需要产品经理注意:

该需求是否有效率更高的实现方式

第一类是明确的提出一些新功能需求

如果这个需求实现了,那么这个需求的广度是怎样?

我个人在产品经理与需求方沟通过程中总结了一个原则,就是:听他的,但不跟他走。

2.2 广度

一是由于需求方因为不懂技术,所以提需求的时候不会去考虑能否实现(虽然很少会碰到无法实现的情况)。如果有这种情况,需要产品经理的脑子灵活一点,找一种折中的方式解决。

该需求可能影响的用户数

跟需求方打交道,有时候也看产品经理的运气,合作的愉快程度跟需求方的职能和工作经验有关。如果需求方的工作经验很丰富的话,他们会帮产品经理想到很多点。

广度,即此需求覆盖用户的范围或产生影响的范围等,从侧面也反应需求的重要性。是嘛,如果需求覆盖的用户或者业务部门很少,我们的态度就是“要做的话请给我一个理由先”。至于如何界定“覆盖的范围”,磊叔抛砖供大家拍:

听他的——要听运营方的需求,毕竟产品的最终目的是要满足他们的需求。不跟他走——虽是满足运营方的需求,但是产品经理不应被牵着鼻子走,不能他说什么就是什么。而且产品经理与需求人员在合作的过程中各司其职,需求人员负责的是功能和内容能否满足,而产品经理则需要决定界面的排版和详细的功能。

若把产品经理比作流水,把需求比作落花,那么大概就是唐寅赋诗“落花有意随流水,流水无心恋落花”的意境吧。

考虑与产品未来的发展方向是否一致,有时候如果用户反馈的意见与产品未来的发展不一致,即便是呼声很高,产品经理也要继续坚持。

来自业务部门的实际需要,一定是马上实现的

来自业务部门的需求,大致可以划分为两类:

是的,我们除了相对主观的二性和三度分析之外,还需要相对客观的数据分析来做更强大的支撑。

也有需求方由于担心技术实现难度,所以在提需求的时候会提的比较简单,有些工作宁可自己做。这时候就需要产品经理发挥自己的能力,给需求方提供一些更好用的工具。

该需求是否是战略发展的要求

如果需求方的经验不多或是小白用户,在沟通的过程中,产品经理会非常被动。特别是当由产品部去发起做一个供公司内部人员使用的产品时,就需要不断的去了解产品使用者的工作流程,去问他们在这中间遇到的问题,这不仅需要产品经理积极的推动能力,还需要有很大的耐心,如果对方属于比较强势的那一种的话,恐怕还需要产品经理受一点委屈。

今天,磊叔再次从自身实际工作中的血泪经验出发,分享大家一套枯燥却又极有用的需求过滤、筛选和排序方法。这套方法总结为七字真言:二性三度一数据

第二类是反馈用户的需求

再跑一个SQL语句,select VARIANCE,几十毫秒就能输出目前平台中已有内容标题长度的方差,也就是最大值和最小值的分布情况

互联网公司中,产品部门的需求主要来自于两方:一是来自于产品内部自己的idea;二是来自业务部门,至于说到业务部门具体指哪些,可能是产品运营人员和公司高层,也可能是来自于市场或者商务等,这由公司的性质和业务决定。

2.1 频度

  1. 三度,即频度、广度和可替代度

该需求同其他需求相比是否使用的频率更高或更低

必要性,即此需求是否一定要实现。至于如何界定“一定”要实现,磊叔抛砖供大家拍:

需求方:“我要列表页的内容标题放的长一点,多放几个字”。

1.2 持续性

  1. 怎样用:这样用

事实上,磊叔认为,可替代度是最能反映需求价值的,最能决定需求是否能降临人世。

频度,即此需求未来被使用的多少,从侧面也反映需求的重要性。是嘛,如果业务部门提的需求它们自己未来都用的少,我们的态度就是“费介事干嘛”。至于如何界定“使用的多少”,磊叔抛砖供大家拍:

经过和需求方沟通,大致了解到该需求是为了避免日后可能出现内容标题过长导致页面显示出错的问题

对于线上系统的需求,是否有效率更高,成本更低但更原始的实现方式

说实话,这类需求简直就是扯淡。不过为了完成这个例子的分析,磊叔还是硬着头皮分步骤说明:

该需求是否是其他高频业务的重要组成部分

该需求是否可由先有已实现功能进行小幅加强后代替

  1. 二性,即必要性和持续性

该需求是否是业务部门的日常工作

该需求是否处于用户经常使用的场景中

到这里,“啪啪啪”几个报表,再加上我们的建议(该需求做还是不做,还是以其他形式实现),提交领导指示!

如果这个需求实现了,那么这个需求的可替代度是怎样?

三度主要从假设需求已经实现的基础上进行评估。如果理解困难,可以加上一句话:“如果实现这个需求”,例如:

该需求在未来的一个或多个版本中是否处于重要的位置

该需求是否是老板指派

怎么用?举个例子:

其实,上述的分析对于产品经理输出一份能够堵住所有人嘴,同时让所有人信服的需求分析报告而言还是略显飘渺,所以我们还需要一个有力的武器提供更加客观的支持,它就是:数据分析。

该需求是否会对规划中的其他产生长尾影响

试想,如果需求A可以被某种成本更低、效率更高的方式B代替,那么需求A的价值大概就和小拇指甲盖那么大吧。强烈建议各位产品经理优先评估需求的可替代度,能够从最大程度上过滤掉很多脑残需求的。

该需求可能影响的其他功能或需求的数量

产品经理每天面对洪水般的需求,面对一个都不能得罪的需求方,必须要有一个强大的武器来帮助我们有效、科学的过滤、筛选和排序。

2.3 可替代度

可替代度,即此需求是否可被其他处理方式代替。至于如何界定“是否可被其他方式代替”,磊叔抛砖供大家拍:

该需求是否解决了某个重大问题

然后在Excel里面跑一个贝叶斯预测,依据现有内容标题长度的情况预测未来的可能情况

该需求是否在未来的几个月甚至更长时间都要发挥重要作用

上述理由很充分也很必要,接下来就从数据角度来分析现有情况和做一个适当的预测

来自产品经理的个人意愿,一定是必须的

打完收工,回家约会。

来自用户的使用反馈,一定是重要的

持续性,即此需求会产生多长时间的影响。说人话的解释就是,实现满足了该需求的功能或业务,能用多久?至于如何界定“能用多久”,磊叔抛砖供大家拍:

其实我们将每个需求从必要性、持续性、频度、广度、可替代度和数据分析等六个维度进行了标记,那么怎么才能看出哪个需求合理,哪个需求不用做,哪个需求晚点做呢?

1.1 必要性

  1. 一数据,即数据分析和预测

该需求是否会影响其他业务的发展

下一篇:没有了

相关新闻推荐

友情链接: 网站地图
Copyright © 2015-2019 http://www.kai-wang.com. AG亚游国际有限公司 版权所有