需求性质：什么是伴生性需求.docVIP

需求性质：什么是伴生性需求 　　伴生性需求在整个产品生命过程中占据极大的比重，如果说创造性需求是可以燎原的星星之火，伴生性需求便是为火焰燃烧提供的若干枯草。 　　 　　什么是伴生性需求 　　在我们做产品时，存在许多没有太大价值，但又必须具备的功能，这部分需求我统一定义为“伴生性需求”，属于某些主干需求的衍生枝干。 　　当我们决定开发账号系统后，除了注册和登录是必须的功能，与之相对应的还会包含修改密码，找回密码这些非常规功能，此时，修改密码，找回密码就属于典型的伴生需求， 　　我们向用户提供了上传照片的功能，对应的就需要提供删除照片，尽管用的人非常少，使用频率也非常低。 　　伴生性需求必须存在，但却不是非常的紧急，实际上，许多团队，往往会将伴生性需求挑选出来，必要时将这部分需求舍弃，置入下个版本的迭代计划。 　　正如他的定义一样，伴生性需求必须存在，但缺少这部分需求，并不会造成多数用户的不满，损失非常有限。 　　产品经理加班的情况仅次于研发人员，实际上我们是一群和时间赛跑的人，与团队中的其他成员一样，我们也希望这个版本能够尽快的上线，投入到市场使用，然后获得非凡的成就。 　　而即使再多的资源，再多的人力，也没有办法同时开启所有需求，这是伴生性需求的一个特点，他总是承担着我们减负的第一个重担。 　　伴生性需求的舍得特色 　　成熟的产品经理懂得砍需求，懂得对需求做减法，这个能力看上去很飘渺也很个性，可能大家听了许多次也只能幻想，手握数千需求，谈笑间，便砍去·五百，对于这中间如何少的，为什么有些需求能砍，为什么有些需求不能砍，想来会非常困惑。 　　需求有主次，我们做产品的过程中，在每个版本里都会体现出需求的主次，需求的顺序，MVP 理念，需求优先级乃至于 kano 模型的都可以体现出这个观点。 　　我们会围绕核心需求投入许多资源，这些核心需求也就是我们的主要需求，同样的，我们会舍弃次要的需求，必要时，我们会舍弃一些看上去非常核心，但实际上他是仅次于主要需求的一个最大的次要需求。 　　现在告诉大家一个方法，能够极大的增加大家砍需求的能力。 　　现在我们有5个需求，但我们的资源以及我们的时间只允许做3个需求，你会舍弃那些需求呢？ 　　为用户上传的照片增加贴纸功能 　　做一个开放式的群聊，全平台用户可参与群聊进行互动 　　开放上传原图，用户可选择上传原始尺寸的照片 　　允许单次上传多张照片，即批量上传 　　开发断点续传的功能，用户上传照片失败，可点击继续上传，已上传的照片不需要重新上传 　　这个题目其实很难回答， 也缺少正确答案，在不同的环境下，我们会有不一样的选择，需求的取舍与很多因素有关，并不是单一因素造成的，但是，将问题稍加修改以后，我想你现在会进行取舍了。 　　现在我们有5个需求，但我们的资源以及我们的时间只允许做3个需求，你会舍弃那些需求呢？ 　　为用户上传的照片增加贴纸功能 [伴生需求] 　　做一个开放式的群聊，全平台用户可参与群聊进行互动 　　开放上传原图，用户可选择上传原始尺寸的照片 　　允许单次上传多张照片，即批量上传 [伴生需求] 　　开发断点续传的功能，用户上传照片失败，可点击继续上传，已上传的照片不需要重新上传 　　是不是很容易识别出来，基本所有的伴生需求，在优先级里都是可以被舍弃的，但并不是完全舍弃，只是在下一个阶段或者未来的某个时机，再来做，也许到那时，该需求就已经不再是伴生性需求，而是创造性需求了。 　　只要我们能识别出需求性质，是被出伴生性需求，我们就能自己尝试去砍功能。 　　伴生性需求的特征 　　作为减负的一个绝佳选择，是伴生需求的应用特征， 而我们能够如此应用还要归功于伴生性需求本身的特色，即伴生需求无法单独存在，对其他功能具备极强的依赖和从属性质。 　　修改密码的功能对于我们来讲太常见了，这个功能便是典型的伴生性需求，若我们的账号系统，仅支持第三方账号登录以及短信验证码登录时，该功能便失去了存在的价值。 　　离开了自定义密码这样一个字段，修改密码的功能在逻辑上就已经不成立了，换言之，修改密码便是设置密码的伴生性需求 　　同样是设置密码的伴生性需求还包括了”找回密码“这个功能。 　　如果设置的功能都不存在，那么围绕密码展开的修改密码以及找回密码就不再具备任何意义了。 　　我们所认识的伴生性需求，最典型的特征便是依附于其他功能而存在，本身是无法单独存在于产品内的。 　　作为一款图片社交产品，允许用户删除照片以及对照片设置隐藏加密功能，也是一组鲜明的伴生性需求。 　　不论是对照片做任何形式的处理，或者业务，都需要建立在照片成功上传的基础之上，围绕照片展开的一系列功能均属于从属且依赖于被上传的照片而存在。 　　这些功能的操作主体便是被上传的照片。 　　可如果这个主体不存在，这些功能还会发生 效应吗？ 若用户上传