加入收藏 | 设为首页 | 会员中心 | 我要投稿 PHP编程网 - 黄冈站长网 (http://www.0713zz.com/)- 数据应用、建站、人体识别、智能机器人、语音技术!
当前位置: 首页 > 运营中心 > 产品 > 正文

产品死亡原因之「负担过载」

发布时间:2017-03-15 21:41:16 所属栏目:产品 来源:枯叶咖啡馆
导读:副标题#e# 导读 讲成功的太多了,讲有用的也太多了,这次,我来讲讲没用的,同时也讲讲失败。 什么是负担过载 万物皆有其承载上限,即便是无底洞,也不是真正的无底,他的深度无法超过地球的直径。 这些上限,很清晰的在我们工作生活中,也许并不是那么的引
副标题[/!--empirenews.page--]

QQ截图20170315095654.jpg

导读

讲成功的太多了,讲有用的也太多了,这次,我来讲讲没用的,同时也讲讲失败。

什么是负担过载

万物皆有其承载上限,即便是无底洞,也不是真正的无底,他的深度无法超过地球的直径。

这些上限,很清晰的在我们工作生活中,也许并不是那么的引入瞩目。

  • android可允许调用的方法上限为65536

  • 千年虫的设定,是指计算机处理的日期上限,(也叫计算机 2000 年问题,由于年份使用的是两位十进制数来表达,无法处理跨世纪日期处理,进而引发各种各样的功能紊乱,系统故障)

  • 与千年虫问题相同的是, 1970 起始年,如果程序日期在 1970 之前,也会导致相同结果,(现在,你知道为什么许多产品,生日都会在 1970 年以上了吗)

当我们所做的事情,超过了固定的上限时,便会出现负担过载,进而引发一系列的问题,在这些问题当中就包含了“死亡”

这在我们的产品里是相同的。

当我看到一个1. 0 的产品异常简单时,总是会有一种莫名的认同感,1. 0 真的不需要太多。

实际上,不只是1.0,在我们每次进行版本迭代时,都不需要太多的功能。

不是因为我们偷懒,也不是因为开发成本。

同时开放过多的功能,也会照成用户的负担过载

负担过载导致死亡的原因

这是我写的第一篇 讲死亡的,负担过载 大概是最高频,但却最隐秘的死亡原因。

很多创业朋友在失败后,通常会去找团队,找资金,找市场的原因,但却很少提到 负担过载。

为什么负担过载会导致死亡呢?

  • 有宽度 ,没深度 

    我们要堆功能很容易,但要做有深度的功能却很难, 负担过载的情况下,我们会盲目的去做许多的功能,可每一个功能的思考深度都是缺少的,甚至我们自己都不清楚为什么要做某个功能。

负担过载第一个影响的便是产品经理的思维,太多的需求,以至于我们没有时间去深思熟虑

功能都是相同的,但不同的用法却取决于我们如何应用相同的功能,宽度是指我们的功能量多,深度却是指我们的应用方法巧妙且有效。

1 天的时间,我们可以堆出数十个功能,也可以只输出一个功能,但通过位置,应用方法,文案让这个功能剧本更有效的深度,更符合人性

功能不会符合人性,符合人性的只有我们的应用方法

  • 盲目开发,资源分散 

    现在许多创业团队其实都不是在做技术创新,真正的做技术创新,技术创业的团队非常的少,我们已经进入了应用创新时代。

也就是说,我们的功能是大同小异的,于应用创新而言,我们的开发成本已然降到了最低。

1. 0 阶段,其实大部分的功能, 2 年左右的研发都能够完成,其实初创团队并不需要寻找技术大牛,许多的技术大牛,做着普通的事情,唯一不普通的只是事情的数量

我提倡的是“从容不迫”的开发状态,显然,这并不那么容易实现,因为影响研发工作量的,恰恰是我们产品经理。

一旦产品经理产生了负担过载的现象,研发就会出现功能量过载的问题,再优秀的技术大牛,面对夸张的负担过载,也只有将大部分的精力分散到完全无关的功能当中。

盲目开发,恰恰是许多产品没有核心功能的原因,过多的研发资源投入到了极为普通的应用功能当中,无法打造更新的,更具备深度的,更个性化的功能

  • 匆忙运营,开花不结果

许多创业团队,不是因为项目不好,而是被自己拖死的,我们已经知道了负担过载对产品经理,对研发的致死因素,可负担过载的影响远远超过我们的预测,它对我们的运营阶段来讲,也同样是一种看不见的致死病毒

过载负担的结果往往意味着产品的某个版本 同时上线了多个功能,典型的重灾区在我们的1. 0 阶段。

我需要强调,运营和产品是两条并行的线,彼此合作,彼此借力,而由产品部分引发的负担过载,会成倍数的增加运营的负担,以至于开花不结果。

我们在运营时,往往需要借助运营点 ,这需要产品提供一些可被运营的媒介,然而,当出现多个运营点时,并且每一个点都是一个所谓的亮点 所谓的核心时,运营体系便会走向崩溃。

我时常和朋友提到,运营比产品更加刺激,在我们努力开发出一个版本时,运营可能已经做完了三到四个运营事件,尽管我是产品经理,但我非常的尊敬运营体系的朋友,他们的注意力需要非常的专注,才能有效的控制一次运营事件。

我们的市场并没有留下足够的时间,让运营像产品一样深思熟虑,也正因为如此,运营的多任务并行难度远超过产品,毕竟我们还有相对充足的时间去纠正,去修改,比如需求变更。

当我们交付给运营的产物出现过载时,如果没有被运营主观上的减少运营点,那基本可以预测 未来的运营阶段必然是混乱的。

我已经提到了在运营事件当中,运营朋友对这个事件的专注度要求非常高,一个独立且完整的运营事件,包括运营策略,前期准备,事件开展,过程控制,转化策略,数据分析,复盘 等多个环节,而这些都会集中在一个星期以内完成。

(编辑:PHP编程网 - 黄冈站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读