打字猴:1.704233234e+09
1704233234
1704233235
1704233236
1704233237
1704233238 图6-12 尽可能多的放弃,反而能提供更多价值
1704233239
1704233240 这是一个理想化的模型,假设功能列表里待开发的功能模块有A、B、C三个,价值和成本如表6-2以及图6-12所示。来对比以下两种做法。
1704233241
1704233242 第一种是传统做法,先做A和B,到第20天,可以发布一个用户价值为5.3.8 的产品。
1704233243
1704233244 第二种是新做法,先做A,再做B。这样,到第10天,就可以发布一个用户价值为5的产品,第20天依然可以发布一个用户价值为8的产品。
1704233245
1704233246 如果简单地把曲线下的面积理解成产品持续提供给用户的价值,那么可以从图中得出明显的结论:只要条件允许,“尽可能多地放弃”反而能提供更多的用户价值。这里的放弃不是要把更多功能丢掉,而是不要集中完成,分批次地迭代实现。
1704233247
1704233248 这样做的另一个好处是,可以提前10天开始获取用户和市场的反馈,而这就足以让我们能提前几天制定出更合理的产品策略。比如,在开始做C之前,发现价值为4的D模块,就可以改为先做D。
1704233249
1704233250 真实场景中可能会出现以下情况,需要加以留意。
1704233251
1704233252 ►发布的频次,并非越频繁越好。因为发布本身也需要占用时间和支付成本,如果发布次数太多,正式版的最终发布时间会不断延迟,最终严重影响产品整体的市场节奏。
1704233253
1704233254 ►越轻量级的产品,越容易打包出一个尽量小的MVP。能独立发布的前提条件是要有一个MVP,但并不是每个产品都能很容易地打包出一个MVP,这取决于产品形态。从大实体到软硬结合、CS结构、BS结构,越重的产品打包MVP的难度越大。
1704233255
1704233256 ►不完美的产品先让种子用户去用。提前发布的产品,直接推给全体用户时一定要慎重。最好能和“种子用户”的概念结合起来,让他们来完成试用。
1704233257
1704233258 我们经常听到迭代、敏捷、试错、小步快跑、持续交付等这些说法,其实它们都表达了相似的价值观——尽可能早地改正错误。一年有52周,如果4周迭代一次,则有13次改正的机会,如果2周迭代一次,就有26次改正的机会。迭代的话题属于研发生产环节,后面的章节还会细聊。
1704233259
1704233260 6.2.2  案例:QQ的MVP
1704233261
1704233262 看一个真实的功能打包案例:QQ,当时还叫OICQ,1988年开始产品规划,1999年2月推出图6-13所示的Beta1,这是QQ的第一个公开版本。因为各种考虑和限制因素,只能优先实现三个特性,应该怎么选?
1704233263
1704233264
1704233265
1704233266
1704233267 图6-13 QQ早期版本的注册界面
1704233268
1704233269 这是一道腾讯的面试题,网上有很多版本的答案,我按照自己的理解梳理了一遍。我们不去回答在下面的12个特性里到底选哪3个,而把分析焦点放在每一个选项到底应该先做,还是缓缓。
1704233270
1704233271 1. 卡通头像
1704233272
1704233273 2. 不可窃听的安全通讯
1704233274
1704233275 3. 聊天室
1704233276
1704233277 4. 很小的.exe文件
1704233278
1704233279 5. 皮肤Skin
1704233280
1704233281 6. 速度超快0.5秒反应
1704233282
1704233283 7. 聊天记录管理器
[ 上一页 ]  [ :1.704233234e+09 ]  [ 下一页 ]