需求性质:什么是伴生性需求

作为 产品经理,我们工作的重点之一就是收集整理需求,那在这些需求中,哪些是刚需,哪些优势伴生性需求呢?本文和大家分享的就是伴生性需求相关内容, 伴生性需求在整个产品生命过程中占据极大的比重,如果说创造性需求是可以燎原的星星之火,伴生性需求便是为火焰燃烧提供的若干枯草。

什么是伴生性需求

在我们做产品时,存在许多没有太大价值,但又必须具备的功能,这部分需求我统一定义为“伴生性需求”,属于某些主干需求的衍生枝干。

·  当我们决定开发账号系统后,除了注册和登录是必须的功能,与之相对应的还会包含修改密码,找回密码这些非常规功能,此时,修改密码,找回密码就属于典型的伴生需求,

·  我们向用户提供了上传照片的功能,对应的就需要提供删除照片,尽管用的人非常少,使用频率也非常低。

伴生性需求必须存在,但却不是非常的紧急 ,实际上,许多团队,往往会将伴生性需求挑选出来,必要时将这部分需求舍弃,置入下个版本的迭代计划。

正如他的定义一样, 伴生性需求必须存在,但缺少这部分需求,并不会造成多数用户的不满 ,损失非常有限。

产品经理加班的情况仅次于研发人员,实际上我们是一群和时间赛跑的人,与团队中的其他成员一样,我们也希望这个版本能够尽快的上线,投入到市场使用,然后获得非凡的成就。

而即使再多的资源,再多的人力,也没有办法同时开启所有需求,这是伴生性需求的一个特点,他总是承担着我们减负的第一个重担。

伴生性需求的舍得特色

成熟的产品经理懂得砍需求,懂得对需求做减法,这个能力看上去很飘渺也很个性,可能大家听了许多次也只能幻想,手握数千需求,谈笑间,便砍去· 五百,对于这中间如何少的,为什么有些需求能砍,为什么有些需求不能砍,想来会非常困惑。

需求有主次,我们做产品的过程中,在每个版本里都会体现出需求的主次,需求的顺序,MVP  理念,需求优先级乃至于  kano  模型的都可以体现出这个观点。

我们会围绕核心需求投入许多资源,这些核心需求也就是我们的主要需求,同样的,我们会舍弃次要的需求,必要时,我们会舍弃一些看上去非常核心,但实际上他是仅次于主要需求的一个最大的次要需求。

现在告诉大家一个方法,能够极大的增加大家砍需求的能力。

现在我们有5 个需求,但我们的资源以及我们的时间只允许做 3 个需求,你会舍弃那些需求呢?

1.  为用户上传的照片增加贴纸功能

2.  做一个开放式的群聊,全平台用户可参与群聊进行互动

3.  开放上传原图,用户可选择上传原始尺寸的照片

4.  允许单次上传多张照片,即批量上传

5.  开发断点续传的功能,用户上传照片失败,可点击继续上传,已上传的照片不需要重新上传

这个题目其实很难回答,  也缺少正确答案,在不同的环境下,我们会有不一样的选择,需求的取舍与很多因素有关,并不是单一因素造成的,但是,将问题稍加修改以后,我想你现在会进行取舍了。

现在我们有5 个需求,但我们的资源以及我们的时间只允许做 3 个需求,你会舍弃那些需求呢?

1.  为用户上传的照片增加贴纸功能  [伴生需求

2.  做一个开放式的群聊,全平台用户可参与群聊进行互动

3.  开放上传原图,用户可选择上传原始尺寸的照片

4.  允许单次上传多张照片,即批量上传  [伴生需求

5.  开发断点续传的功能,用户上传照片失败,可点击继续上传,已上传的照片不需要重新上传

是不是很容易识别出来,基本所有的伴生需求, 在优先级里都是可以被舍弃的,但并不是完全舍弃,只是在下一个阶段或者未来的某个时机,再来做,也许到那时,该需求就已经不再是伴生性需求,而是创造性需求了 。

只要我们能识别出需求性质,是被出伴生性需求,我们就能自己尝试去砍功能。

伴生性需求的特征

作为减负的一个绝佳选择,是伴生需求的应用特征,  而我们能够如此应用还要归功于伴生性需求本身的特色,即 伴生需求无法单独存在,对其他功能具备极强的依赖和从属性质。

修改密码的功能对于我们来讲太常见了,这个功能便是典型的伴生性需求,若我们的账号系统,仅支持第三方账号登录以及短信验证码登录时,该功能便失去了存在的价值。

离开了自定义密码这样一个字段,修改密码的功能在逻辑上就已经不成立了,换言之, 修改密码便是设置密码的伴生性需求

同样是设置密码的伴生性需求还包括了” 找回密码 “ 这个功能。

如果设置的功能都不存在,那么围绕密码展开的修改密码以及找回密码就不再具备任何意义了。

我们所认识的伴生性需求,最典型的特征便是依附于其他功能而存在,本身是无法单独存在于产品内的。

作为一款图片社交产品,允许用户删除照片以及对照片设置隐藏加密功能,也是一组鲜明的伴生性需求。

不论是对照片做任何形式的处理,或者业务,都需要建立在照片成功上传的基础之上,围绕照片展开的一系列功能均属于从属且依赖于被上传的照片而存在。

这些功能的操作主体便是被上传的照片。

可如果这个主体不存在,这些功能还会发生  效应吗?  若用户上传照片的功能被阻塞,那么这个照片的本体就不复存在,也就无法再围绕该主体展开功能型操作了。

现在,许多产品做的很重,而且这个问题的两处重灾区一个是从0 到 1 的过程中,堆积了大量需求,1.0 版本研发了一年多的时间上线,在这些问题的背后,便是我们将若干的伴生性需求当成了真正的用户需求。

现在,你是否学会如何舍弃某些需求,以及如何辨识出伴生性需求呢?

伴生性需求”做功能“

伴生性需求本身是作为需求存在,可在做的时候,我们却不能将他当做需求来理解,这部分需求更多的是以功能补充的形式存在,极少用户反馈里会提及到这些。

因此,这也是最适合新人入门的一个领域,借助对伴生性需求的驾驭,会帮助我积累更多的功能库,逐步的掌握功能的使用方法以及开发过程。

我们关注伴生性需求,不需要考虑他是否符合人性,是否存在需求,是否存在影响力,只需要去思考如何做会更好一点,这会逐渐的增加我对功能的驾驭能力。

许多新人会容易犯的一个错误,不太重视文案,过多的将精力花费到了功能设计以及看各种资料上, 这其实是舍本逐末的做法。

《精益至上》  这本书里提到了这样一个案例:

某电商网站的用户新增很难提升,在一次优化尝试下,数据呈现了客观的增长,这个小小的优化,只是将注册按钮的位置做了一些调整,可以说没有进行任何功能的新增,只是调整了局部的布局。

与之同样的,我们也能从文案中看到差异,我们以一句简单的注释来举例:

1.  参与活动,有机会赢苹果 7

2.  赢苹果 7 ,参与活动,你也可以

两句文案很难说谁好谁坏,但我们能清晰的从这两句话感受到不同的信息,第一句,我们认为参与活动是主体,赢得东西是辅助的,第二句,则变成了赢苹果7 是主要的,而活动只是辅助的信息。

在做伴生性需求时,当尽善尽美,此时我不需要为整个产品的商业价值负责,不需要为用户需求负责,但我们需要对功能负责,让功能更容易被大家接受,不显得粗糙,难用。

仅仅是将伴生性需求做出来,是无意义的,而且会极大的损害自己的成长,这个阶段的我们更多的与功能贴近,尝试更好的去表达功能,而布局和文案的使用反而是这个阶段对我们的两大挑战。

来源:人人都是产品经理

时间: 2024-11-05 07:50:44

需求性质:什么是伴生性需求的相关文章

软件需求模式 读书笔记三

通过这一个月的阅读,我终于读完了<软件需求模模式>这本书,前两个读书笔记已经把这本书的几种模式介绍了,之前有基础需求模式,信息需求模式,数据实体需求模式,用户功能需求模式.这次介绍的是性能需求模式,适应性需求模式,访问控制需求模式和商业需求模式. 性能需求模式包括五种的性能的需求模式:影响时间(系统需要多少时间完成一个请求).动态容量(系统能够同时处理多少件事).吞吐量(系统处理时间的速率).静态容量(系统可以保存多少某种类型烦的实体)和可用性(什么时候系统对用户是可用的,以及多么可靠). 当

《软件需求》读书笔记3

<软件需求>读书笔记之三 需求来源.需求收集方法 软件需求可以来自方方面面,这取决于所开发产品的性质和开发环境.需从不同用户代表和来源收集需求,这说明了需求工程是以相互交流为核心的性质.下面是几个软件需求的典型来源. 1). 访问并与有潜力的用户探讨为找出新软件产品的用户需求,最直截了当的方法是询问他们. 2). 把对目前的或竞争产品的描述写成文档 文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则. 3). 系统需求规格说明 一个包含软.硬件的产品需要一个高档次的系统需求规格说

社交需求和社交产品的更替

之前一直想写一篇关于社交产品的文章,想将互联网时代以来的社交产品的发展脉络进行一个总结.无奈一直没有多少时间(主要是因为楼主很懒...啊哈哈),所以一直没能完成.现在必须得逼着自己写了~ 某个互联网大牛说过,一个好的互联网产品,要么改变人与人的沟通方式,要么改变人们获取信息的方式.仔细一分析,确实如此,因此我得写两篇文章分析改变沟通方式的产品脉络,还有一篇是改变获取信息方式的产品脉络,现在先写下第一篇,一定要完成啊,不然就砍手!! 人与人之间的沟通需求,随着IT行业的发展慢慢进行了转变.但是,总

需求的鉴别与分析

需求的鉴别与分析: 从这些暴露的问题来看,设计师不应预先想定一种解决办法来辨认设计目标.初步需求陈述应确定设计的实际目标,它应该尽可能概括些,但要同时确定问题的基本性质. 注意: 对需求的陈述不应给解答的性质强加一些不必要的限制,对需求陈述重新进行适当检查,目的在于分析最初的问题表述和进一步鉴别设计的基本特征,自我分析的过程. 需求的本质与要求满足,限制思维范围.潜在的与显在的. 爱斯基摩人的9点问题: 思维定势与突破. 需求分析目的: 对需求的陈述实质就是一个抽象过程,其目的是确定设计任务的核

需求评审五个维度框架分析及其带来的启示-3-典型需求评审

典型情境是指软件开发的常见情境,本文选择如下来进行分析: 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审 传统瀑布模型下的需求评审 对传统瀑布模型现有需求评审的分析 传统瀑布模型在需求阶段末期安排有关键的需求里程碑评审,其特征参见2.8节情况1.在业界实际操作中,往往出现如下情况: 1,召集包括领导在内的各方代表,历经1-2小时会议,评审30页以上需求规格说明书,走过场式各方签字通过评审: 2,各方对需求规格书有各种各样意见,历经

高质量的需求工作

高质量的需求工作 任何一项工作都需要有一个评定其好坏的标准,软件需求工作也不例外.这里所说的软件需求工作包括以下几个方面:需求管理和需求本身的质量.具体如下: 需求管理 需求管理包括需求计划,需求调研,变更管理及文档管理 需求计划评定: 需求计划制定是否符合项目计划 需求计划是否能够被坚定执行 制定计划时是否考虑客户的可用时间 需求调研: 需求收集的方法是否符合项目实际情况(需求收集方法有许多,会在以后的文章中介绍) 调研前是否告知客户调研内容 调研时是否做好调研记录 调研后是否有会议纪要或确认

软件工程(五)---理解需求

软件工程(五)---理解需求 1.需求工程是一个不会因为软件项目的变化而变化的通用过程. 2.在项目开始阶段,任务的意图是确定基本问题理解.所需解决方案的性质和想要解决问题的人. 3.使需求获取困难的三个问题是范围.理解和波动性. 4.利益相关者并不是将要购买正在开发中的完整软件系统的人. 5.对于不同的客户来说,提出相互矛盾的要求是相对普遍的,每个人都认为他或她的版本是正确的. 6.一个好的解决方案会带来什么样的经济效益.谁是工作的幕后主使以及谁会使用这个解决方案是是项目启动期间使用的上下文无

需求管理之被遗忘的需求

先说一个小笑话.有一个生产队队长,他对专家说:"如今我们生产队的地越来越多,牛越来越忙只是来了.我想要这么一种牛,他吃的草和普通牛一样多,可是干的活是普通牛的十倍. "专家说:"这种牛是能够造出来的,如今有基因project."队长说:"好吧,你给这造几头这种牛."于是专家找到了生物实验室.让生物实验室的人搞一个基因project,把牛造出来. 于是project浩大,投资无法保证,合作多半是不愉快的收场. 现实世界里非常多人分析需求的过程就相似

案例分析:从一则笑话分析需求的陷阱

某日,老师在课堂上想考考学生们的智商,就问一个男孩:“树上有十只鸟,开枪打死一只,还剩几只?” 男孩反问:“是无声枪么?” “不是.” “枪声有多大?” “80~100分贝.” “那就是说会震的耳朵疼?” “是.” “在这个城市里打鸟犯不犯法?” ‘不犯.” “您确定那只鸟真的被打死啦?” “确定.”老师已经不耐烦了,”拜托,你告诉我还剩几只就行了,OK?” “OK.鸟里有没有聋子?” “没有.” “有没有关在笼子里的?” “没有.” “边上还有没有其他的树,树上还有没有其他鸟?” “没有.”