摘要: 需求管理是一门艺术。程序员
开发产品的时候,咱们天天都会面对各类各样、没完没了的需求,有的来自外部用户的反馈,有的来自内部团队的idea,有的是产品的BUG,有的是新的功能...算法
看起来只要实现全部需求,产品就能够变得更好,而后吸引更多的用户,接着赚更多的钱,以后招更多的人,再完成更多的需求...小程序
问题是,需求会源源不断地进来,咱们永远也不可能清空全部需求,996也作不完,这辈子都不可能。后端
咱们能作的,是不断将需求排序,实现优先级最高的需求。那么问题来了,咱们应该如何给需求排序?微信小程序
乔布斯曾经说过:浏览器
People don't know what they want until you show it to them.
用户真的不知道他们想要什么吗?不少时候并不是如此。微信
我负责产品,天天都会和用户交流,他们知道本身想要什么功能,有时会作好简单的交互设计、帮忙想一想算法、甚至给我开源代码。网络
问题在于,用户只是产品的使用者,他们对于产品的理解没有咱们那么深入,因此他们提出的需求有时会偏离问题的本质,须要咱们进一步分析与挖掘。ide
咱们不是乔布斯,没有能力创造需求;咱们也不是张小龙,没有1亿人教咱们作产品。所以,咱们应该多与用户交流,以用户需求为核心肯定优先级:优化
当咱们作产品的时候,创造的欲望是很是惊人的,总会有一些新的idea让咱们激动不已,巴不得明天就能上线。可是,咱们应该克制本身的创造欲,尊重用户的意见。咱们的产品是给客户用的,不是给本身玩的。
流量红利已经枯竭的时代,获取一个新用户比留住一个老用户难太多了,所以提升留存率显得很是重要。重视每个用户反馈,及时修复他们发现的BUG,优先实现他们想要的功能,是提升留存率最有效的方式,没有之一。
墨菲定律是这样的:
Anything that can go wrong will go wrong.
程序员应该都知道,代码怎么可能没有BUG呢?不少时候只是咱们没有发现,或者是知道了却没有及时修复。
然而,对于当前产品的BUG,咱们每每容易忽视。多是BUG隐藏的太深,咱们和用户都没有发现;多是用户发现BUG,可是没有反馈;也多是咱们选择性失明,以为问题不大。
事实上,用户对产品质量的要求很是严格,再小的问题他们也会发现,也会吐槽。用户反馈的话咱们还能知道,不然咱们可能很晚才发现BUG,若是没有监控的话。
还有一种微妙的状况,当用户反馈貌似不可能出现的BUG时,咱们会本能的以为产品应该没有问题,问题应该出在用户那里,大概是他的浏览器或者网络,或者某种没法解释的缘由致使的。其实,这只是咱们在逃避问题,代码的运行方式是肯定的,没有什么不能解释的地方,若是什么地方不太对劲了,那基本上是BUG。这里分享一个咱们的经历:
某个用户反馈,他在邀请成员加入团队的时候发现,偶尔会有那么一次邀请失败。
咱们检查了一下监控数据,发现确实有失败过,影响的用户不止一个,可是不多。
而后,咱们检查了一下先后端代码,发现没有问题。
既然业务代码没有问题,那应该没有BUG,这事大概是什么奇怪的缘由致使的,咱们什么也不用作吧...
后来,又有几个用户反馈同一个问题,报错也越来来越多,咱们不可能再骗本身了!
再次检查,业务代码确实没有问题,可是报错的代码位置的行号和列号都偏移了,这么诡异?
不难猜想,生产环境运行的是旧代码!检查一下果真是这样。
接着,不难发现部署的Docker配置文件有问题,致使某个节点部署的后端代码是旧的...
咱们老是这样,不停地向前走,不断地追求新的成就,逃避当下的问题。听着是否是很像咱们的生活?
对于产品BUG,咱们应该第一时间修复,或者设置一个Deadline,新的功能能够稍微延后。
若是咱们不停地开发新功能,那当初开发这个有BUG的旧功能到底是为了什么?若是咱们忽略当前用户反馈的问题,那咱们费这么大劲拉新是为了什么?
需求管理是一门艺术,须要考虑和权衡的东西不少,暂时给你们一个简单的优先级排序,仅供参考:
严格按照这个顺序操做是不可能的,这是给你们提供2个思考维度。实际工做中,每一个需求的影响范围、紧急程度、难易程度也须要考虑。
你有什么更好的想法吗?欢迎留言讨论!本文做者为Fundebug的技术总监,欢迎添加微信交流:KiwenLau。
Fundebug专一于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线,Fundebug累计处理了10亿+错误事件,付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎你们免费试用!