被困在系統裡的，何止外賣騎手

還記得不久前的一篇《外賣騎手，困在系統裡》的文章在各大平臺和朋友圈刷屏了，餓了麼一文回應,上了熱搜又引得無數網友的罵聲。

“系統”一個諸多程式設計師花了數年搭建的新時代工具，更是成了這個事件的輿論中心，演算法彷彿在吞噬時間，蔑視生命。用巨大的時間邏輯在一個個外賣員身上榨乾鮮血，獲得所謂的利益。

當然，它指出了一個可怕的事實，伴隨著“配送時間”、“好評度”等硬指標的外賣騎手，正在系統裡無法自拔，他們扮演的是一場”無限遊戲“裡的NPC。

似乎存在的意義就是給別人送食物，迴圈往復，就像活在一個龐大的系統裡。相反那些系統的操控者，也在依託演算法，不斷的在壓縮外賣員的時間。

這篇文章似乎在喚醒人們關注這個特殊的群體，並提醒我們，為我們服務的外賣員，為了按時的到達，他們整日都在奔波，最終的結果卻釀成了無數的慘劇。

似乎很多的人，很多的行業都被困在了系統裡。很多的人，不禁在問這個時代怎麼了？沒有智慧機，沒有外賣的時候，我們仍然能夠活的很開心，過得很快樂。

我們被困在系統裡，源於什麼呢？有時候是該停下來好好的思考這樣的問題。當然作為產品經理的一員，其實你會發現：我們每個產品經理，都被困在系統裡！

一、此“經理”非“經理”

一提到產品經理，相信很多人想到的都是張小龍或者喬布斯那一類的大神，他們用自己的行動去影響世界，甚至改變世界。

很多人都夢想成為這一類的大神，用自己的想法去改變世界，年薪百萬，迎娶白富美，從此走向人生巔峰。然而現實卻啪啪的打臉，必定那樣的人只是少數，大多數的產品經理還是做著很基礎的工作。

產品經理是CEO學前班！記得當年李開復老師一句話帶起的節奏，直到現在還影響著苦逼的產品狗們。

對於不瞭解產品經理的人來說：哇，你好厲害，年紀輕輕的就當經理了，小夥子前途不可量啊，我相信這樣的讚美，很多的產品小夥伴都聽到過。

每當這個時候，我只會選擇笑笑，不知道說什麼好。

有些人覺得你好厲害呀，要對整個產品負責，只要有和產品相關的事情，第一眼想到的都是你。

產品出BUG了，這個產品要怎麼運營，這個產品的商業模式是否要在改改，這個相關的業務到怎麼操盤，這個需求是不是要在梳理一下，這個功能結構圖是不是要在規劃一下，產品經理你是怎麼搞得，這麼簡單的事情都做不好麼？

客戶沒規劃二期，就因為你的功能做的太垃圾，產品經理你怎麼規劃的？我們的平臺為什麼只有那麼幾個會員，產品經理不好好的和運營配合呀？為什麼我們同類的產品那麼成功，我們的卻那麼的差？產品經理你怎麼做的競品分析呀？為什麼我們的APP一堆差評，一堆吐槽的。產品經理你好不趕緊拿出方案來最佳化呀！

相信這一類的吐槽，這些的不滿，每個產品小夥伴或多或少都經歷過，甚至有的小夥伴會在想你到底想怎麼搞？

我們頂著“經理”的title,每天操著賣白粉的心，領著微薄的工資，當產品出了問題又要去各種求爺爺告奶奶的。

為了解決問題，我們不得不去開發同學面前賣萌，甚至要忽悠客戶這個做不了，專案要上線，這些需求放到二期來完成。所以很多時候，產品經理上能忽悠客戶，做的需求，下能賣萌，說服開發同學。

我們為什麼要去做這麼多事情呢？

——很簡單：雖然我們是“經理”但是我們沒權。

當然，長時間的下去我們也會累，也會爆發，很多時候做為領導，雖然你畫的餅可能有時候也香，但是你就給那麼點人，卻要做那麼多的事，您心裡就沒點B數嗎？

所以有些鍋，我們產品經理實在背不動。

二、魚和熊掌都想兼得

我們生活在一個矛盾的世界裡，很多的人都想什麼都要有收穫，什麼都想做，什麼都想一次性就上，總覺得自己，就是完美主義的化身，自己就是改變世界的人。

但現實魚和熊掌都是不可兼得的，相信這個道理大家都懂，但真正做到的人卻不多。魚與熊掌不可兼得，大家都知道這句話、都懂這個道理，但能做到的人不多。

記得有一段時間，由於工作的原因，在加上身體的不舒服，整個人體重一度超過了201斤。

為了改變，我一度下定決心開始減肥，當然我選擇了最簡單的方式跑步。每個星期都堅持跑30公里以上，花了大半年的時間，我終於開始瘦了一些，那段時間是相當的有成就感和高興的。

後來有一段時間，由於自身的懶惰，放棄了堅持跑步的習慣。

有一段時間看著自己不斷增長的體重，於是又下定決定去跑步。雖然很痛苦，但是我還是堅持跑完了6公里，當然跑完的結果是真整個人都不是特別的舒服，印象中第二天還感冒了。

這大概就是最簡單的魚和熊掌不能兼得的例子，你要擁有健康的身材，又喜歡大吃大喝，不去努力怎麼怎麼可能呢？

這裡想起之前參與的一個電商專案，領導給我們定的目標：平臺註冊使用者翻倍，年營收不低於800W。

接下來的話就是各種拆分：看你平臺一個月迭代幾個版本，完成了銷售反饋的多少需求，策劃了多少次活動….後來有幾次開會，領導直接表示，我不管你怎麼做，我要的是結果，結果說明一切。

有幾次又開始問：為什麼銷售提的需求到現在都還沒做？對應的渠道合作為什麼還是一點進展都沒有，你是幹什麼吃的？為什麼我們的平臺，維護成本要那麼高？到底什麼時候才能把成本降低呀？

我說的這些問題，不是隻是說給你們聽的，我需要的是解決，我是希望看到結果的。

結果呢：平臺一堆的BUG，每週很多的新工作不斷的插進來，原來制定的計劃無法完成，很多的目標都是漸行漸遠。

三、打雜的日常，撕逼的無奈，考核的無語

關於產品經理的工作，在很多的中小型企業是沒有明確的劃分，所以很多工作了很多年的產品經理，一直在做著打雜的工作，雖然他們也有一顆改變世界的心，但現實卻啪啪的打臉。

老實說，產品經理的工作內容很繁雜，又繁又雜。

為了做好需求，不得不多次去做使用者調研，每天都在和使用者打太極，大量的時間浪費在了需求調研之上，晚上熬夜加班，整理需求，做對應的解決方案。

結果呢：被開發懟的體無完膚，這個需求做不了，那個實現需要排期，專案交付之前，又被客戶叫去一頓說，有的需求要推翻重來。

專案開發的過程中，你一邊要陪著開發同學加班，雖然也沒你啥事，另一邊又要盯著專案進度，一邊跟設計師確定UI規範，一邊跟測試核對測試用例，甚至有的時候，還要思考這個需求怎樣拒絕客戶，還不會讓客戶生氣。

好不容易上線了，你又要隨時關注使用者的資料，有問題的話要優先解決。甚至有的時候，還要記錄不同部門的反饋，針對這些需求你要去排期，做相關的產品迭代。

期間還要去考慮如何的拉新，裂變等一系列的投放。除了這些工作，你還要騰出精力應付隨時甩鍋的開發同學，或者運營同事，甚至既管過程又盯結果的老闆。

反正一句話：無論遇到什麼問題，找產品經理就對了。當然我們做好本職工作是很有必要的，必定這是我們的職業特色，老闆給我們發工資。

但你永遠都想不到，還有什麼稀奇古怪的事情在等著你：

• 市場要召集客戶做會銷，產品經理你做個產品介紹PPT；
• 運營要搞個裂變活動，產品經理你來把控一下活動細節；
• 渠道要談個大客戶，產品經理一起去演示一下產品；

最後考核：老闆卻問你，一天天的在忙啥？還能不能做點正事？這一分鐘你是不是很有想打人的衝動？？

四、成為系統的一部分

當然不得不說，技術的進步推動了社會的發展，大自然是公平的，優勝劣汰，跟不上的終將被淘汰。新產品的出現，必定將取代舊的產品，即使你抗議也是沒什麼用的，它一定會消失的。

這是一個行業的沒落，不論是人還是產品，我們都會面臨同樣的問題，誰也無法逃避。

最後的結果，大部分是人工一定會被機器所替代，外賣行業未來也一定會有一些好的解決方案，這需要的是時間，到那個時候是不是外賣小哥又要全部被解僱。

所以，不管在什麼樣的環境，我們都要有居安思危的意識，以及終身學習的觀念，因為你永遠不知道明天和失業哪一個先到來。

在這個資訊時代，你眼中的的世界，未必就是你認為的世界，很多時候你只不過是坐井觀天罷了。

而你，甚至對此不自知。

在這裡我想到了演算法，比起之前的主動選擇，現在的演算法，更像一個陷阱，而你卻不由自主的就陷進去了。

想到了一個詞“資訊繭房”，它最早是美國哈佛大學法學教授、奧巴馬的法律顧問凱斯·桑斯坦2001年在《網路共和國》一書中提出的；2008年，桑坦斯在他的另外一本著作《資訊烏托邦》中對這個概念做了更充分的分析和討論。

他用“個人日報”來形容使用者在海量資訊中根據自己的喜好選擇有興趣的資訊，從而對其他內容的忽略，最後形成“資訊繭房”。

在當時，這種行為其實是使用者主動選擇的結果，相反的今天由於演算法的推薦很多你感興趣的的資訊已經可以自動推送給你。如果說過去的網，需要使用者自己主動編織的話，那麼如今因為演算法的興起，這張網已經主動給你編織好了。

“資訊繭房”無處不在的今天，下一步的你究竟該如何行走，你是否思考過這樣的問題呢？我們是寄希望於資本和科技公司主動在社會責任和企業效益之間尋找平衡？還是說強烈的意志去躲開這些應用，砸碎自己的資訊繭房？亦或者選擇隨意而安，學會和它共存呢？

如果我們無法改變系統，為什麼就不能和他共生，成為系統的一部分，不然一個碎唸的你怎麼去拯救一個碎唸的外賣小哥呢？

當然要拯救外賣小哥也很容易，你不點外賣，自己做飯就搞定了。但是放棄這種便捷的生活，你願意麼？

有時候，沒有霹靂手段，就少點菩薩心腸，無力的同情是最廉價的。

當然外賣小哥被困在系統裡，引起了廣泛的關注，並且能夠達到緩解，首先是因為這個群體足夠大，其次是被困的系統就餓了麼和美團兩個。

相反，作為產品經理的你，可能就很無奈，你要想翻起多大的波瀾，實在太難了。

其次每個公司都算一個獨立的系統，對於產品經理的理解和定位很多時候是不相同的，當我們從一個系統到另外一個系統，我們能做的只有適應，否則生存都是一個很大的問題。

當然很不止產品經理被困在系統裡，大多數的當代社畜都一樣，產品經理可能只是其中的一個縮影罷了。

本文由 @斷念 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。