講成功的太多了， 講有用的也太多了， 這次， 我來講講沒用的， 同時也講講失敗。
什麼是負擔超載
萬物皆有其承載上限， 即便是無底洞，
這些上限， 很清晰的在我們工作生活中， 也許並不是那麼的引入矚目。
Android可允許調用的方法上限為65536千年蟲事件（指電腦處理的日期上限， 也叫電腦2000年問題， 指由於年份使用的是兩位十進位數字來表達， 無法處理跨世紀日期處理， 進而引發各種各樣的功能紊亂， 系統故障）1970起始年事件（與千年蟲類似， 指一些程式日期在1970之前， 會導致系統紊亂。 PS：現在你知道為什麼許多產品， 生日都會在1970年以上了吧）當我們所做的事情， 超過了固定的上限時， 便會出現負擔超載， 進而引發一系列的問題， 在這些問題當中就包含了“死亡”。
這在我們的產品裡是相同的。
當我看到一個1.0的產品異常簡單時，
實際上， 不只是1.0， 在我們每次進行版本反覆運算時， 都不需要太多的功能。
不是因為我們偷懶， 也不是因為開發成本。
同時開放過多的功能， 也會造成用戶的負擔超載。
負擔超載導致死亡的原因
這是我寫的第一篇講死亡的， 負擔超載大概是最高頻， 但卻最隱秘的死亡原因。
很多創業朋友在失敗後， 通常會去找團隊， 找資金， 找市場的原因， 但卻很少提到負擔超載。
為什麼負擔超載會導致死亡呢？
有寬度 ， 沒深度
我們要堆功能很容易， 但要做有深度的功能卻很難， 負擔超載的情況下， 我們會盲目的去做許多的功能， 可每一個功能的思考深度都是缺少的， 甚至我們自己都不清楚為什麼要做某個功能。
負擔超載第一個影響的便是產品經理的思維， 太多的需求， 以至於我們沒有時間去深思熟慮。
功能都是相同的， 但不同的用法卻取決於我們如何應用相同的功能， 寬度是指我們的功能量多， 深度卻是指我們的應用方法巧妙且有效。
1 天的時間， 我們可以堆出數十個功能， 也可以只輸出 1 個功能， 但通過位置， 應用方法， 文案讓這個功能劇本更有效的深度， 更符合人性。
功能不會符合人性， 符合人性的只有我們的應用方法。
盲目開發， 資源分散
現在許多創業團隊其實都不是在做技術創新， 真正的做技術創新， 技術創業的團隊非常的少， 我們已經進入了應用創新時代。
也就是說， 我們的功能是大同小異的，
我提倡的是“從容不迫”的開發狀態， 顯然， 這並不那麼容易實現， 因為影響研發工作量的， 恰恰是我們產品經理。
一旦產品經理產生了負擔超載的現象， 研發就會出現功能量超載的問題， 再優秀的技術大牛， 面對誇張的負擔超載， 也只有將大部分的精力分散到完全無關的功能當中。
盲目開發， 恰恰是許多產品沒有核心功能的原因， 過多的研發資源投入到了極為普通的應用功能當中， 無法打造更新的，
匆忙運營， 開花不結果
許多創業團隊， 不是因為項目不好， 而是被自己拖死的， 我們已經知道了負擔超載對產品經理， 對研發的致死因素， 可負擔超載的影響遠遠超過我們的預測， 它對我們的運營階段來講， 也同樣是一種看不見的致死病毒。
超載負擔的結果往往意味著產品的某個版本 同時上線了多個功能， 典型的重災區在我們的1.0階段。
我需要強調， 運營和產品是兩條並行的線， 彼此合作， 彼此借力， 而由產品部分引發的負擔超載， 會成倍數的增加運營的負擔， 以至於開花不結果。
我們在運營時， 往往需要借助運營點， 這需要產品提供一些可被運營的媒介， 然而， 當出現多個運營點時， 並且每一個點都是一個所謂的亮點所謂的核心時，運營體系便會走向崩潰。
我時常和朋友提到，運營比產品更加刺激，在我們努力開發出一個版本時，運營可能已經做完了三到四個運營事件，儘管我是產品經理，但我非常的尊敬運營體系的朋友，他們的注意力需要非常的專注，才能有效的控制一次運營事件。
我們的市場並沒有留下足夠的時間，讓運營像產品一樣深思熟慮，也正因為如此，運營的多工並行難度遠超過產品，畢竟我們還有相對充足的時間去糾正，去修改，比如需求變更。
當我們交付給運營的產物出現超載時，如果沒有被運營主觀上的減少運營點,那基本可以預測未來的運營階段必然是混亂的。
我已經提到了在運營事件當中，運營朋友對這個事件的專注度要求非常高，一個獨立且完整的運營事件，包括運營策略，前期準備，事件開展，程序控制，轉化策略，資料分析，複盤 等多個環節，而這些都會集中在一個星期以內完成。
在這樣的環境下，同時並行兩個以上的運營點，會直接影響運營的過程，這也是為什麼許多從事運營行業2-3年的朋友，對運營的瞭解尚顯簡陋的原因。
負擔超載的情況下，我們無法專注的做好一件事情，自然無法窺視到一件事情所經歷的各個階段，也自然無法將結果調整到最好。
我們總是在來回切，就像切一些自己不喜歡的歌曲，很多時候，事情剛剛開始，就已經結束了，畢竟還有那麼多的運營點沒有被運營。
當我們的源頭，產品經理出現負擔超載時，我們的運營基本上就可以預判後期的工作節奏以及成果了。
當然，多數情況下，會是只開花，不結果
人多也是一種負擔
我們有時候會近乎偏執的相信自己是正確的，比如，負擔超載的上述 3 個結果，我們都可以歸結到人數上，那我們招人就可以了，增加人手就可以了。
這是對的，但也正因為他是正確的，所以我們離死亡更進一步
1000人以上的企業，與10人的企業，他的複雜度不一樣，他的風險不一樣這個我們是一目了然的，但大部分的時間，我們並沒有意識到 2 個人和 3 個人也是不一樣的。
當我們決定增加團隊時，負擔超載最大的致死因素就開始發生作用了，需求的負擔超載變成了任務超載，現在，他變成了人員超載。
並不是把人放在一起就是一個團隊，不考慮招人成本情況下，我們來看看已經招到人以後產生的致死因素。
新成員融入風險
新成員融入團隊是伴隨著雙向風險的，其中，對團隊而言，新成員的思想會對我們產生衝擊，我們會消耗更多的時間在於新成員的溝通上。
當已經出現負擔超載的情況時，再招人不但不能立即幫我們分擔，降低負擔，反而會為我們增加更多的負擔，讓這種負擔超載的情況變得更為嚴峻。
原本，我們加班能完成的事情，引入新成員以後，不僅僅仍然要加班，而且現在加班也做不完了。
團隊向心力的衝擊
當我們一個人自己做一件事情時，毫無疑問，我們是一心一意的，當我們兩人一起做事時，我們尚且能做到彼此尊重，互相理解。
而這層脆弱的向心力，隨著人數的增加，會逐漸崩壞，我們很難通過人與人的溝通來產生企業文化，更多的需要由規範，原則，無數次的事件來形成企業文化。
而當新成員進入一個團隊時，必然會對團隊向心力產生衝擊，並且，這往往和我們引入的人才能力成正比，越優秀的人才，對我們的向心力衝擊越大。
這是有原因的:
有經驗的人才，往往由於自己所經歷過的環境，形成了自己判斷事情的標準，我們的技能雖然比較專業，但同樣的，我們的可塑性是比較薄弱的。我們很難找到與自己想法完全相同的人， 儘管這樣的人確實存在，但我們所能接觸到的人，相對於所有人來講，實在是太少了。最後的結果是什麼呢？我們找了更多的人，但他們並不是來幫我們解決問題的，這很殘酷，但也很現實。
我相信，不論對於招聘者，還是對於應聘者，我們都希望能很好的協作，我也相信，我們都想要幫對方解決問題，都不是來找茬的。
但我們卻忽略了，人數，也是負擔超載的一種結果。
我們迎來了更多的爭執，我們在討論上花的時間越來越多，我們的需求也越來越多，負擔超載不但沒有被降低，反而越來越多，在結果到來之前，我們便早早預測到了結果，但卻無能為力，除非我們能夠學會控制自己，減少負擔。
建議
我們既然已經提到了負擔超載是死亡原因之一，我想給大家一些建議，但文章中不準備展開描述了。有機會的話我會單獨再寫一篇詳細闡述如何避免負擔超載。
最有效的辦法，減少需求量
產品經理是負擔超載的源頭，如果我們能控制需求量，這將會對規避負擔超載有重大價值。在我的習慣裡，一個大版本是由固定的節奏的，比如 他會包含 1 個運營點，1 個功能模組，諸多的細節調整。
砍需求，比新增需求更專業
砍需求，恰恰是專業的一種表現方式，只有我們充分的認識需求，能夠判斷需求的價值，能夠進行需求對比，和選擇，我們才能砍需求，而不是指隨意任性的砍需求。
你能做的，真的沒有那麼多
其實我們能做的事情，並不多，許多時候，即便是把功能做出來了，並且做的和別人一模一樣了，也不見得我們真的能應用這個功能。支付寶，花了許多時間，許多成本才明白他真的做不了社交。（傳言支付寶經過三個月的討論，決定放棄社交）。
我們真的不那麼強大， 能做的事情，真的很少。
勿以世界為敵，做我們能做的事情，把他做好。
#專欄作家#
本文原創發佈于人人都是產品經理。未經許可，禁止轉載。
並且每一個點都是一個所謂的亮點所謂的核心時，運營體系便會走向崩潰。我時常和朋友提到，運營比產品更加刺激，在我們努力開發出一個版本時，運營可能已經做完了三到四個運營事件，儘管我是產品經理，但我非常的尊敬運營體系的朋友，他們的注意力需要非常的專注，才能有效的控制一次運營事件。
我們的市場並沒有留下足夠的時間，讓運營像產品一樣深思熟慮，也正因為如此，運營的多工並行難度遠超過產品，畢竟我們還有相對充足的時間去糾正，去修改，比如需求變更。
當我們交付給運營的產物出現超載時，如果沒有被運營主觀上的減少運營點,那基本可以預測未來的運營階段必然是混亂的。
我已經提到了在運營事件當中，運營朋友對這個事件的專注度要求非常高，一個獨立且完整的運營事件，包括運營策略，前期準備，事件開展，程序控制，轉化策略，資料分析，複盤 等多個環節，而這些都會集中在一個星期以內完成。
在這樣的環境下，同時並行兩個以上的運營點，會直接影響運營的過程，這也是為什麼許多從事運營行業2-3年的朋友，對運營的瞭解尚顯簡陋的原因。
負擔超載的情況下，我們無法專注的做好一件事情，自然無法窺視到一件事情所經歷的各個階段，也自然無法將結果調整到最好。
我們總是在來回切，就像切一些自己不喜歡的歌曲，很多時候，事情剛剛開始，就已經結束了，畢竟還有那麼多的運營點沒有被運營。
當我們的源頭，產品經理出現負擔超載時，我們的運營基本上就可以預判後期的工作節奏以及成果了。
當然，多數情況下，會是只開花，不結果
人多也是一種負擔
我們有時候會近乎偏執的相信自己是正確的，比如，負擔超載的上述 3 個結果，我們都可以歸結到人數上，那我們招人就可以了，增加人手就可以了。
這是對的，但也正因為他是正確的，所以我們離死亡更進一步
1000人以上的企業，與10人的企業，他的複雜度不一樣，他的風險不一樣這個我們是一目了然的，但大部分的時間，我們並沒有意識到 2 個人和 3 個人也是不一樣的。
當我們決定增加團隊時，負擔超載最大的致死因素就開始發生作用了，需求的負擔超載變成了任務超載，現在，他變成了人員超載。
並不是把人放在一起就是一個團隊，不考慮招人成本情況下，我們來看看已經招到人以後產生的致死因素。
新成員融入風險
新成員融入團隊是伴隨著雙向風險的，其中，對團隊而言，新成員的思想會對我們產生衝擊，我們會消耗更多的時間在於新成員的溝通上。
當已經出現負擔超載的情況時，再招人不但不能立即幫我們分擔，降低負擔，反而會為我們增加更多的負擔，讓這種負擔超載的情況變得更為嚴峻。
原本，我們加班能完成的事情，引入新成員以後，不僅僅仍然要加班，而且現在加班也做不完了。
團隊向心力的衝擊
當我們一個人自己做一件事情時，毫無疑問，我們是一心一意的，當我們兩人一起做事時，我們尚且能做到彼此尊重，互相理解。
而這層脆弱的向心力，隨著人數的增加，會逐漸崩壞，我們很難通過人與人的溝通來產生企業文化，更多的需要由規範，原則，無數次的事件來形成企業文化。
而當新成員進入一個團隊時，必然會對團隊向心力產生衝擊，並且，這往往和我們引入的人才能力成正比，越優秀的人才，對我們的向心力衝擊越大。
這是有原因的:
有經驗的人才，往往由於自己所經歷過的環境，形成了自己判斷事情的標準，我們的技能雖然比較專業，但同樣的，我們的可塑性是比較薄弱的。我們很難找到與自己想法完全相同的人， 儘管這樣的人確實存在，但我們所能接觸到的人，相對於所有人來講，實在是太少了。最後的結果是什麼呢？我們找了更多的人，但他們並不是來幫我們解決問題的，這很殘酷，但也很現實。
我相信，不論對於招聘者，還是對於應聘者，我們都希望能很好的協作，我也相信，我們都想要幫對方解決問題，都不是來找茬的。
但我們卻忽略了，人數，也是負擔超載的一種結果。
我們迎來了更多的爭執，我們在討論上花的時間越來越多，我們的需求也越來越多，負擔超載不但沒有被降低，反而越來越多，在結果到來之前，我們便早早預測到了結果，但卻無能為力，除非我們能夠學會控制自己，減少負擔。
建議
我們既然已經提到了負擔超載是死亡原因之一，我想給大家一些建議，但文章中不準備展開描述了。有機會的話我會單獨再寫一篇詳細闡述如何避免負擔超載。
最有效的辦法，減少需求量
產品經理是負擔超載的源頭，如果我們能控制需求量，這將會對規避負擔超載有重大價值。在我的習慣裡，一個大版本是由固定的節奏的，比如 他會包含 1 個運營點，1 個功能模組，諸多的細節調整。
砍需求，比新增需求更專業
砍需求，恰恰是專業的一種表現方式，只有我們充分的認識需求，能夠判斷需求的價值，能夠進行需求對比，和選擇，我們才能砍需求，而不是指隨意任性的砍需求。
你能做的，真的沒有那麼多
其實我們能做的事情，並不多，許多時候，即便是把功能做出來了，並且做的和別人一模一樣了，也不見得我們真的能應用這個功能。支付寶，花了許多時間，許多成本才明白他真的做不了社交。（傳言支付寶經過三個月的討論，決定放棄社交）。
我們真的不那麼強大， 能做的事情，真的很少。
勿以世界為敵，做我們能做的事情，把他做好。
#專欄作家#
本文原創發佈于人人都是產品經理。未經許可，禁止轉載。