敏捷开发辅助新项目验证与落地

敏捷开发辅助新项目验证与落地

精益创业中的反馈循环

在《精益创业》这本书中提到的一个反馈循环为开发-测量-认知。即,使用最小的力量开发一个产品,将其投入到小范围的市场中进行假设验证,最后收集反馈进行认知更新,并迭代到开发中。在这个循环中,如果一切顺利的话,我们会将产品逐渐优化。如果测量验证出现非期望的结果,我们可以及时终止投入,减少沉没成本。

何为MVP

MVP,英文为:Minimum Viable Product。即最小有价值(可用)产品。许多人将关注点放在可用,却忽视了验证可用。部分产品经理在设计产品及进行排期的时候,是按产品的功能堆迭进行排期的。即一期包含了什么功能,二期包含了什么功能。却从来没有去想一期验证了用户需要什么功能,二期验证了用户需要什么功能。

我们在某一个系统设计的时候,在最初阶段,没有对数据库索引做设计。我们认为,在当时的阶段,尽快将业务逻辑实现,并验证模型设计是适合业务应用的,那才是当务之急。做索引设计只会分散我们的注意力和时间,而无益于我们验证设计是否符合需求。按照需求的持续发展,我们在根据实际情况进行索引的设计与增添,是完全来得及的。也就是说,就那个阶段而言,模型设计与业务逻辑实现才是MVP,索引设计不包含在MVP之中。而这一切,基于我们要验证什么需求,而不是基于我们想要推出什么功能。

验证需求而不是满足需求

我们在设计一款产品的时候,需求来源往往有两个。一个是用户明确提出他对某个具体的功能或者服务有需求;另一个是产品设计者通过某些调研判断某个功能或者服务能解决用户当前意识不到的需求,即创造用户需求。举个例子,老年人可以方便的使用微信,不是简单的老年人也能学习微信,微信方便易学,而是老年人不得不去学。所以微信为老年人创造了需求。

无论一个需求来源于何处,基本上他都是一个假设性的需求。我们所做的每一款产品,并不是在解决或者满足用户的需求,而是在持续不断的验证用户确实有这些需求。如果我们能够站在这个角度去思考产品设计的时候,我们就该知道,当对产品进行迭代排期,需要达成的目标是,每一次更新验证了什么,而不是每一次更新解决了什么。

所有的需求都有多个解决方案,没有一个人的解决方案是绝对可行的。但是我们却可以验证某个实践确实解决了问题。也就是说,做出来才是第一要务,设计是为了做的更好,本质仍在于做出产品。

敏捷开发辅助新产品实践

敏捷开发一个核心要义就是快速迭代。

用户的需求如果是非常紧急的,即缺少了某种解决方案会非常不方便。比如下班高峰期打不到出租车,需要更多的车投入运营等;或者用户的需求是被创造出来的。比如不玩微信玩抖音,不玩抖音看电视。无论是什么样子的需求,用市场的角度去解析,都是“不稳定”的。需求时刻在变,要求迭代要足够快速,用迭代来验证需求已经改变;用产品更新来让持续产生用户价值。

如果我们意识不到迭代的重要性,认为目前没有迭代的情况下,用户仍能很好的处理好自己的问题,而不积极去推进自己的产品迭代,那相当于,我们自己放弃了验证用户需求的机会。其结果会是两种,如果用户有多个依赖,那么,用户需求会被其他的迭代更快的产品所验证和满足,如果用户只能使用自己的产品,比如,规定了我们只能使用某一款笔记本,工作沟通工具等,且其迭代周期不够,那么当用户需求急升的时候,就会是该产品无法承受而被迫革新的时候。被革新虽然是常有的事,但是作为该产品的负责人和参与者,不一定希望自己的产品是这样的结尾 。

总结

敏捷开发模式希望通过坚持快速迭代来不断验证用户需求,最终保持产品持续走在最具竞争力的位置。即时验证用户需求不及预期,也可以降低沉没成本并即时调整航向。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值