Google+话题探讨分享:应用快速迭代(敏捷模式)和用户不升级

文章描述:当移动应用“敏捷迭代”遇到“用户不升级”.

某个深夜在Google+参与一个话题的讨论,事后觉得这个话题有价值,就继续做思考整理。顺便把stream里的内容转贴在文末留以备份,方便沉淀,也可以让大家继续参与交流讨论。

APP升级习惯调查 是这个话题讨论的源头,这篇日志是从移动应用快速迭代升级与用户忽视或者不升级应用之间带来的冲突,引发的一连串的思考和分析。

根据这个话题,我也做了一些延伸的思考。

在移动应用的研发中,应用快速迭代(敏捷模式)和用户不升级应用真的是矛盾对立的么?用户不升级会导致产品失败么?快速迭代是不是不适合移动应用的开发呢?就如文中所说:“你后面越做越强有屁用啊,人家都不升级。第一印象决定了产品命运。”

真是这样么?

其实后来仔细想后,反倒释然,这又是一个骑马乘舟的结论,一开始的主体给忽视了,产品后面越做越强?

无论是什么产品,最本质的是解决用户的需求,移动应用只是一种在移动终端提供需求解决方案的新形态。那么本质就在于这个应用满足什么需求,以及针对这个需求予以解决的方式,最终面对用户的就是我们常说的产品的质量。从而影响用户对其的认知、接受、使用、信任、爱戴、心仪。

我们先从快速迭代说起,快速迭代并不意味着产品放弃应有的品质,靠慢慢升级来补足,就是说,哪怕是1.0版本的应用,它应该具备的是解决这个需求的完整模型,注意,是完整,不是完美。如果一个产品、应用一开始没让用户了解其带来的价值,一开始就失败了。

快速迭代和发布只是研发的一种理念和思维,强调快速应变,以及持续改进产品质量,这点应该在以BS的应用得到了很好的验证。我想也正是服务端这种应用的迭代模式,快速迭代可以把服务质量始终牢牢把握在自己手里,现在移动终端应用却是客户端模式,依赖升级,才有笔者的那番思考吧。

某种意义上,一个应用的初始版本就表征了这个应用的价值定位,如果这点些在发布之初都没做好,失败得其所,没啥好说的。

当然用户为什么还保留这个应用在终端,原因各式各样,移动终端的用户行为确实是个有意思的研究课题。

至于这个产品的发展和前途,最本质的还是在于产品自身,和用户升级与否没有必然联系。所以产品成败,和敏捷迭代无关,于用户不升级无关。

有个经典的例子是IE6浏览器。

当然,Android、Iphone的应用开发者去做一些降低用户升级软件成本、或者引导的努力是值得的,比如升级提醒等。

但是话说回来,如果用户觉得这个应用有价值,愿意留在自己的终端,并使用,这已经算是第一步的成功了(不包括那种暂时不碍眼,懒得删的)

至少表明你这个应用cover的需求满足用户某种需要,至于是不是每天升级,是不是即时升级,这不是关键,我觉得半年升级一次的用户,很多都是appstore升级模式,以及多次升级的体验和经历,教育出来的,用Iphone的朋友应该很了解,大部分应用的升级都是一些小功能的变动,bugfix,并且频繁发布版本。这种体验认知一旦建立,用户半年升级一次显然是合理而明智的。这种升级的现状,确实是用户升级所付出的成本远高于收益,一次次可以,多次用户就受不了,尤其是装了很多应用的用户,虽然这些应用都同时留驻在用户的终端,但用户对于应用的价值和依赖程度也分三五九等的。所以这种升级行为,笔者描述的情况,人各有异,但大体不可能太勤奋,实在太正常了。就如你让某人某天即兴唱一次红歌还可以,让他天天唱只能当治病了。

有些时候,是我们产品人的习惯,已经脱离平常用户行为,不正常甚至有点病态了。

所以多数招聘的情景下,对于产品控和Geek,有一种复杂的情感,即爱之又忧之,对一个东西钻得很深,特别有激情,但是特别容易钻牛角尖,把简单问题复杂化,反而体会不到普通用户的疾苦和痛楚。

好了,有点偏题了,所以,做移动终端应用的同学,不要把产品的问题归结为用户的问题,产品的核心体验,不应依赖升级去解决,不要指望用户等3秒、等下个版本才能得到想要的(这个想要就是需求,不是用户的某个功能要求,用户很多时候对自己的需求是含糊不清的,甚至是错误的)。

敏捷所提倡的持续优化产品质量,当用户的基础需要满足后,获得用户的青睐,接受之后,迭代升级是产品如何让用户更喜欢,更依赖,逐步加深对产品积极体验的有效方式。

还是那句话,真是好东西,人人抢着要,真是重要的电话,错过一次还会再打过来。

最后,不影响用户的核心需求满足的前提下,用户是宽容的,或是残忍的。前者会继续使用这个不完美但解决问题的产品,后者可能直接卸载删除并大骂离开。越是大众产品,被骂得越多越惨,可以参考BIT。这种局面每个产品都实际的面临着。因为每个用户对于产品的需求都是非常不同的。

下面是话题讨论的部分摘录:由于是基于流的open即兴讨论,只是选摘和话题关系紧密的……….

Junyu Wang -    Public

这个问题看得有点浅. 问题本质, 用户在 make decision 的时候会平衡 ROI 就是了. 得到的是升级带来的好处, 付出的是升级的操作成本. 想让用户升级, 要么增加好处, 要么降低成本.
从经验来看, 降低成本比较容易促使用户升级. 例如 Chrome, 例如豌豆荚 (还不够低).
Android 电子市场允许自动升级后, 感觉就非常爽, 手机里面的应用始终是最新的, 也不需要你花时间维护. iOS 就非常难过.

jary xie - 这个话题蛮有意思,升级最本质的还是取决于用户收益,门槛高低对结果有影响,但不关键,这就是appstore升级体验不佳,用户乐此不疲升级的原因,关键取决于收益的刺激强度,当然不排除很多小白用户不了解iphone还可以升级这回事。不过,对于应用开发者,提高自己产品的价值是最核心的,在产品价值恒定的前提下,降低升级门槛会促进升级。

Huiwen Ji - 降低成本只是敲门砖,后面要让开了门的人感知到明显的好处跟进作为positive reinforcement,这样下次用户的ROI expectancy才会提升。

Junyu Wang - 如果成本为0, 那就没有这个问题了. android自动升级是批量转嫁成本,引导用户开启这个功能一样也是要有成本的,但由于是批量的,回报也比较高。如果默默的自动开启,出了问题,将来会产生抵触。

jary xie -即便门槛为0,我也会选择升级有收益期待的,不会升级本身价值平庸的应用,并可能随时准备删掉,升级是花费流量和时间成本的,举个例子,假若面前摆着chrome和世界之窗浏览器,前者有门槛我也会升级,后者无论如何都无所谓。这与用户的价值预期有关。手机上的应用很多处于后者的位置,当然,如果是后者,升级门槛还高,那就完蛋了。自动批量升级有利有弊,appstore重点培养的是应用的质量,升级是这个生态中的环节,需要具体权衡了。

劉牛牛 - 如果电子市场自动升级默认选择wifi下升级就可以了。或者点一下全部升级也算是成本非常低。对于很多用户平说,会认为新版起码不比旧版差,360不就培养了很多升级控吗。

jary xie - 其实目标围绕升级讨论容易偏离目标,作为应用开发者,用户持续需要才是首当其冲的问题.

劉牛牛 - 如果开了自动升级,很可能会出现升级以软件出现问,但自动升级也可以解决这个问问。1.0稳定1.1出问题,那赶快出1.2修复问题。

Arsalan Ma - 当软件弹出窗口说,嘿,我们已经准备好了X.X.XXX的升级,你点一下有如下更新哦,亲。
如果是Google家或者有类似背景、血缘的软件,我就点下去;
如果是迅雷、暴风、360或者类似背景的软件,我就卸载它;
豌豆荚是个特例,因为最近的几次更新没有带来任何操作上的改进,他的资源库越来越臃肿,找东西也越来越难了,而且在新的XT882/870手机连接时,总会自动关闭。

周零零七 - 在对豌豆荚的好感方面,一群Googles有很大影响,信任Googlers,信任豌豆荚。

Eric Levison - 但是用豌豆夹, 一大堆应用升级后, 一般用户不会每个应用都打开看看升级了啥吧.

Cong Li - 我会建议软件开发者在用户首次运行经过自动升级后的软件界面作出提示,扼要交代这次升级增加了哪些主要功能或修复了哪些 BUG,就像 Google Maps 升级后运行那样。

Liu Bobby - roi。。说句老实话我从来不知道有些升级是做什么用的。“这个升级解决了XX安全漏洞”——除了pro以外谁知道是啥意思?反正升级不升级只不过是看省事不省事而已。我觉得最差的例子就是acrobat reader,这玩意每次打开的时候检查是否有更新,但是更新的时候要把acrobat reader关掉。但打开reader的时候一般都是有文要读的时候,so。

时间: 2024-10-22 22:36:15

Google+话题探讨分享:应用快速迭代(敏捷模式)和用户不升级的相关文章

敏捷开发-快速迭代

今天跟大家分享的是"敏捷开发.快速迭代".我们大都采用的是"瀑布开发模式",有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理.经过YH系统的开发,也且生体会到了这一弊端. 有问题就要去解决它!于是我想到了"敏捷开发".借鉴敏捷开发模式,来改善软件开发过程,提高项目的开发效率. 要想借鉴,首先得弄懂以下3个问题. 1. 什么是敏捷开发 百度百科中是这样解释的:敏捷开发是一种以人为核心.迭代.循序

快速迭代的互联网研发模式下测试如何突破?

测试同学的日常 ~每次出故障,老板总是会问,你这个怎么测的?! ~交付延期,发布时间却不变,只能压缩的就是测试时间了.怎么办,加班来补吧. ~测试环境又挂啦. ~你就不能少重构几次?每次重构都要回归所有功能. ~功能急着上线,却没几个用户使用. ~说好的自动化,在经过无数个紧急项目后,仍然没有完成. ~哦弥陀佛,项目明天就要发布了,千万不要有故障. 测试作为研发环节中不可缺少的角色存在着,但大多数中小型公司的测试团队却以最弱小的姿态生存.在互联网模式的冲击下,快速迭代.持续发布.不断试错成为研发

快速迭代的开发方式中的QA实践方法

背景 尽管"小步快跑"的快速迭代开发方式早已成为互联网软件开发的主流指导思想,但大量开发团队在落地这一开发方式时最常遇到的问题就是"如何QA",因为,传统软件行业的QA方式(手动测试,回归测试等)无法适应每天多次上线的迭代节奏.这时,开发团队往往会面临这两种窘境: 要么是为了速度不顾质量,导致线上故障频发:要么是为了质量而固定发布窗口,导致业务不够敏捷. 那么,在快速迭代的开发方式下,究竟应该采用怎样的QA实践才既能控制住风险又能跟上节奏? 本文对小博无线技术团队在

快速开发模式与敏捷模式的关系

我们目前快不起来,不在于我们是否采取敏捷方式,而是我们基础太薄弱 1.开发人员不理解现有业务 2.开发人员不理解现有代码 3.开发人员不理解现有数据表关系.关键字段变化.VIEW.SP.报表 4.开发人员不理解MAP在典型场景中的实际应用,不了解MAP到底有多少函数可以帮助开发 5.开发人员大多是新人,对开发过程规范不了解.我们目前采取CMMI开发过程规范,光主节点就有78个.开发部门的老人也大部分只是只开发过一个子系统,对其他子系统的业务.代码.数据库也不了解.只是MAP和开发过程规范比武汉开

从“憋大招”到快速迭代 细数Windows 10变化背后的小秘密

 Windows 10一周岁了.这个史上最不一样的Windows被赋予了太多标签,"增长速度最快的Windows "."最安全的Windows"."最好用的Windows"."最后一个独立版本Windows"--微软(中国)操作系统工程院院长谢育涛表示,Windows10也是史上最有中国印记的Windows. 史上"最"不一样的Windows 微软正试图以完全不同的方式去思考Windows在改变科技行业过程

软件测试-快速迭代的app产品需要测试用例评审吗?

问题描述 快速迭代的app产品需要测试用例评审吗? 目前快速迭代过程中,需求变更很快,写的测试用例也需要不断变更,一直在想真的需要测试用例评审吗?该如何做比较有效率,请高手给意见 解决方案 快速迭代,如果需求变得快,说明团队磨合不够,如果测试和开发一起介入需求,形成有效沟通,测试用例不细也没关系

产品是如何快速迭代的

今天在微博上又一次看到有人转发小马哥的:"小步快跑,快速迭代"理论,刚好鄙人近期收集了一些快速迭代的资料,接下来结合自身的经验来浅谈产品的快速迭代方式.这篇文字可能会偏项目管理一些,不过我认为项目管理也是产品经理基本素质之一. 关于立项 这一点相信大家都不陌生,每个产品在经过 BRD.MRD (当然,这两个过程并不是所有产品经理都能参与)之后,就会进入立项阶段.在传统的立项过程中,我们更多的是走流程,项目负责人提出立项申请,项目组进行可行性讨论分析,然后召开大会进行立项评审,负责人根据

张小龙:学习和快速迭代比过去的经验更重要 一切从用户角度出发

看了一篇关于微信事业群WXG领导人张小龙的报导,他说的挺好,"学习和快速迭代比过去的经验更重要",正如<把口红卖给男人>里面的一个观点不谋而合,过去的经验或许会把你困在思维的框中,阻碍思考.从用户的角度出发才是做产品的初衷. 据腾讯第二季度财报信息显示,旗下的微信与WeChat合并月活跃用户已经达到了4.38亿.微信是国内迄今为止增速最快的在线即时通信工具,从0到1亿用户,用了14个月的时间,从1亿到2亿,用了不到半年的时间,而历史上,QQ即时通讯工具的用户从零到积累2亿用

小米崔宝秋:开源软件助产品快速迭代

摘要: 在小米首席架构师崔宝秋看来,产品的快速迭代让互联网企业根本没有试错的机会.要快速创新.快速推出产品并快速占领市场,最好的方法就是拥抱开源,使用开源软件为自己的硬件 在小米首席架构师崔宝秋看来,产品的快速迭代让互联网企业根本没有试错的机会.要快速创新.快速推出产品并快速占领市场,最好的方法就是拥抱开源,使用开源软件为自己的硬件产品快速构建软件平台. 小米的MIUI系统,可以认为是利用开源Android 操作系统 的成功典范.通过对系统的功能及UI进行优化.硬件适配.软件预装,MIUI系统在