什么是负担过载
万物皆有其承载上限，即便是无底洞，也不是真正的无底，他的深度无法超过地球的直径。
这些上限，很清晰的在我们工作生活中，也许并不是那么的引入瞩目。
Android可允许调用的方法上限为65536
千年虫事件（指计算机处理的日期上限，也叫计算机2000年问题，指由于年份使用的是两位十进制数来表达，无法处理跨世纪日期处理，进而引发各种各样的功能紊乱，系统故障）
1970起始年事件（与千年虫类似，指一些程序日期在1970之前，会导致系统紊乱。PS：现在你知道为什么许多产品，生日都会在1970年以上了吧）
当我们所做的事情，超过了固定的上限时，便会出现负担过载，进而引发一系列的问题，在这些问题当中就包含了“死亡”。
这在我们的产品里是相同的。
当我看到一个1.0的产品异常简单时，总是会有一种莫名的认同感，1.0真的不需要太多。
实际上，不只是1.0，在我们每次进行版本迭代时，都不需要太多的功能。
不是因为我们偷懒，也不是因为开发成本。
同时开放过多的功能，也会造成用户的负担过载。
负担过载导致死亡的原因
这是我写的第一篇讲死亡的，负担过载大概是最高频，但却最隐秘的死亡原因。
很多创业朋友在失败后，通常会去找团队，找资金，找市场的原因，但却很少提到负担过载。
为什么负担过载会导致死亡呢？
有宽度 ，没深度
我们要堆功能很容易，但要做有深度的功能却很难， 负担过载的情况下，我们会盲目的去做许多的功能，可每一个功能的思考深度都是缺少的，甚至我们自己都不清楚为什么要做某个功能。
负担过载第一个影响的便是产品经理的思维，太多的需求，以至于我们没有时间去深思熟虑。
功能都是相同的，但不同的用法却取决于我们如何应用相同的功能，宽度是指我们的功能量多，深度却是指我们的应用方法巧妙且有效。
1 天的时间，我们可以堆出数十个功能，也可以只输出 1 个功能，但通过位置，应用方法，文案让这个功能剧本更有效的深度，更符合人性。
功能不会符合人性，符合人性的只有我们的应用方法。
盲目开发，资源分散
现在许多创业团队其实都不是在做技术创新，真正的做技术创新，技术创业的团队非常的少，我们已经进入了应用创新时代。
也就是说，我们的功能是大同小异的，于应用创新而言，我们的开发成本已然降到了最低。1.0阶段，其实大部分的功能，2年左右的研发都能够完成，其实初创团队并不需要寻找技术大牛，许多的技术大牛，做着普通的事情，唯一不普通的只是事情的数量
我提倡的是“从容不迫”的开发状态，显然，这并不那么容易实现，因为影响研发工作量的，恰恰是我们产品经理。
一旦产品经理产生了负担过载的现象，研发就会出现功能量过载的问题，再优秀的技术大牛，面对夸张的负担过载，也只有将大部分的精力分散到完全无关的功能当中。
盲目开发，恰恰是许多产品没有核心功能的原因，过多的研发资源投入到了极为普通的应用功能当中，无法打造更新的，更具备深度的，更个性化的功能。
匆忙运营，开花不结果
许多创业团队，不是因为项目不好，而是被自己拖死的，我们已经知道了负担过载对产品经理，对研发的致死因素，可负担过载的影响远远超过我们的预测，它对我们的运营阶段来讲，也同样是一种看不见的致死病毒。
过载负担的结果往往意味着产品的某个版本 同时上线了多个功能，典型的重灾区在我们的1.0阶段。
我需要强调，运营和产品是两条并行的线，彼此合作，彼此借力，而由产品部分引发的负担过载，会成倍数的增加运营的负担，以至于开花不结果。
我们在运营时，往往需要借助运营点 ，这需要产品提供一些可被运营的媒介，然而，当出现多个运营点时，并且每一个点都是一个所谓的亮点 所谓的核心时，运营体系便会走向崩溃。
我时常和朋友提到，运营比产品更加刺激，在我们努力开发出一个版本时，运营可能已经做完了三到四个运营事件，尽管我是产品经理，但我非常的尊敬运营体系的朋友，他们的注意力需要非常的专注，才能有效的控制一次运营事件。
我们的市场并没有留下足够的时间，让运营像产品一样深思熟虑，也正因为如此，运营的多任务并行难度远超过产品，毕竟我们还有相对充足的时间去纠正，去修改，比如需求变更。
当我们交付给运营的产物出现过载时，如果没有被运营主观上的减少运营点,那基本可以预测未来的运营阶段必然是混乱的。
我已经提到了在运营事件当中，运营朋友对这个事件的专注度要求非常高，一个独立且完整的运营事件，包括运营策略，前期准备，事件开展，过程控制，转化策略，数据分析，复盘等多个环节，而这些都会集中在一个星期以内完成。
在这样的环境下，同时并行两个以上的运营点，会直接影响运营的过程，这也是为什么许多从事运营行业2-3年的朋友，对运营的了解尚显简陋的原因。
负担过载的情况下，我们无法专注的做好一件事情，自然无法窥视到一件事情所经历的各个阶段，也自然无法将结果调整到最好。
我们总是在来回切，就像切一些自己不喜欢的歌曲，很多时候，事情刚刚开始，就已经结束了，毕竟还有那么多的运营点没有被运营。
当我们的源头，产品经理出现负担过载时，我们的运营基本上就可以预判后期的工作节奏以及成果了。
当然，多数情况下，会是只开花，不结果
人多也是一种负担
我们有时候会近乎偏执的相信自己是正确的，比如，负担过载的上述 3 个结果，我们都可以归结到人数上，那我们招人就可以了，增加人手就可以了。
这是对的，但也正因为他是正确的，所以我们离死亡更进一步
1000人以上的企业，与10人的企业，他的复杂度不一样，他的风险不一样这个我们是一目了然的，但大部分的时间，我们并没有意识到 2 个人和 3 个人也是不一样的。
当我们决定增加团队时，负担过载最大的致死因素就开始发生作用了，需求的负担过载变成了任务过载，现在，他变成了人员过载。
并不是把人放在一起就是一个团队，不考虑招人成本情况下，我们来看看已经招到人以后产生的致死因素。
新成员融入风险
新成员融入团队是伴随着双向风险的，其中，对团队而言，新成员的思想会对我们产生冲击，我们会消耗更多的时间在于新成员的沟通上。
当已经出现负担过载的情况时，再招人不但不能立即帮我们分担，降低负担，反而会为我们增加更多的负担，让这种负担过载的情况变得更为严峻。
原本，我们加班能完成的事情，引入新成员以后，不仅仅仍然要加班，而且现在加班也做不完了。
团队向心力的冲击
当我们一个人自己做一件事情时，毫无疑问，我们是一心一意的，当我们两人一起做事时，我们尚且能做到彼此尊重，互相理解。
而这层脆弱的向心力，随着人数的增加，会逐渐崩坏，我们很难通过人与人的沟通来产生企业文化，更多的需要由规范，原则，无数次的事件来形成企业文化。
而当新成员进入一个团队时，必然会对团队向心力产生冲击，并且，这往往和我们引入的人才能力成正比，越优秀的人才，对我们的向心力冲击越大。
这是有原因的:
有经验的人才，往往由于自己所经历过的环境，形成了自己判断事情的标准，我们的技能虽然比较专业，但同样的，我们的可塑性是比较薄弱的。
我们很难找到与自己想法完全相同的人， 尽管这样的人确实存在，但我们所能接触到的人，相对于所有人来讲，实在是太少了。
最后的结果是什么呢？我们找了更多的人，但他们并不是来帮我们解决问题的，这很残酷，但也很现实。
我相信，不论对于招聘者，还是对于应聘者，我们都希望能很好的协作，我也相信，我们都想要帮对方解决问题，都不是来找茬的。
但我们却忽略了，人数，也是负担过载的一种结果。
我们迎来了更多的争执，我们在讨论上花的时间越来越多，我们的需求也越来越多，负担过载不但没有被降低，反而越来越多，在结果到来之前，我们便早早预测到了结果，但却无能为力，除非我们能够学会控制自己，减少负担。
建议
我们既然已经提到了负担过载是死亡原因之一，我想给大家一些建议，但文章中不准备展开描述了。有机会的话我会单独再写一篇详细阐述如何避免负担过载。
最有效的办法，减少需求量
产品经理是负担过载的源头，如果我们能控制需求量，这将会对规避负担过载有重大价值。在我的习惯里，一个大版本是由固定的节奏的，比如 他会包含 1 个运营点，1 个功能模块，诸多的细节调整。
砍需求，比新增需求更专业
砍需求，恰恰是专业的一种表现方式，只有我们充分的认识需求，能够判断需求的价值，能够进行需求对比，和选择，我们才能砍需求，而不是指随意任性的砍需求。
你能做的，真的没有那么多
小龙哥如果将微信的源代码送给你，你能再做一个微信出来吗？
其实我们能做的事情，并不多，许多时候，即便是把功能做出来了，并且做的和别人一模一样了，也不见得我们真的能应用这个功能。支付宝，花了许多时间，许多成本才明白他真的做不了社交。
我们真的不那么强大， 能做的事情，真的很少。
勿以世界为敌，做我们能做的事情，把他做好。
原标题：产品死亡原因之「负担过载」
