拋棄35歲員工是一種罪
昀哥 2020年11月10日
在《別急着拋棄35歲員工》中王新喜說：「年齡焦慮，尤其是35歲焦慮，蔓延在每個互聯網中年男人的頭上。有人一針見血指出，科技互聯網行業對高齡員工的偏見，是因為這些員工從事的工作沒有完全擺脫勞動密集型的本質。」為什麼IT高科技企業包括新興互聯網公司要有能包容35歲員工生存的環境呢？下面我從學費、二樓打一樓、遠見三個維度講述其中道理。
學費篇
以交易收銀為例，一旦出問題，就是大問題，而且是大面積的大問題，很有可能就像日本福島核電站一樣難以收場。這就是為什麼不能隨便攢幾個工程師就開干交易收銀系統的原因，不要以為老兵可以被隨隨便便幹掉，他們交過昂貴的學費。
很多年前在一場令人精疲力竭的大項目之後，面對各種抱怨和不愉快，我說：公司為大家繳納了如此高昂的學費之後，就不應該讓這些人離開，否則學費就等於給別人交了。
並不是我的思路清奇，而是每一位經歷過血海腥風的老兵都會這麼想。
交什麼學費？
沒經歷過的人，真的是無法想像。
說出來後果可能嚇死你。
「賺客」，知道吧？
每個電商其實都有規則漏洞、程序漏洞，黑產和賺客們都在默默地薅羊毛。
有心人可以去「賺客吧」靜靜地觀察一個月，然後再做電商運營，知己知彼百戰不殆。攻防戰，攻防戰，前提是你知道對手是誰。
沒有交過學費的，甚至連「賺客」都沒聽說過，更別提對付他們了。
我第一次登上央視二套就是因為中了賺客們的埋伏，十年前的我們少不更事，盲目信任某浪某易「一線互聯網公司」的品牌和技術，傻傻地與某浪某易合作抽獎活動，投放了將近兩千萬元的網站充值卡（5、10、15、20元面額不等）作為獎品，沒想到賺客們早已破解了這兩家網站的看似嚴密的活動規則，事先準備了大量成熟活躍的某浪帳號某易郵箱，薅走了大量的充值卡。
最近一次再度目睹賺客是2019年1月20日凌晨1點到10點，整整9個小時，羊毛黨徒們狂歡，從拼多多領取（而不是搶購）100元無門檻優惠券，據信拼多多損失高達數千萬元。
幸好拼多多有專業團隊寫就的用戶服務協議，能夠有效地在這種薅羊毛事件中保護拼多多，比如：
- 賬戶保管：凡經您的賬號和密碼成功登錄使用拼多多平台，即視為您的使用行為；您應當對您的賬戶進行的所有活動及後果負法律責任。您不得以任何形式擅自轉讓或授權他人使用您的賬戶，因您主動泄露、出借賬戶信息或因您遭受他人攻擊、詐騙等行為導致的損失及後果，拼多多並不承擔責任，您可以通過司法、行政等救濟途徑向侵權行為人追償。（註：撇清盜號連帶責任）
- 交易秩序：您的購買行為應當基於真實的消費需求，不得實施惡意購買、惡意維權等擾亂拼多多平台正常交易秩序的行為。基於維護拼多多平台交易秩序及交易安全的需要，拼多多發現上述情形時有權採取關閉相關交易訂單，限制賬戶使用功能、中止或 終止服務等措施而無需事先通知您。（註：關閉訂單，關停賬戶，有法可依！）
- 商品信息：您充分理解， 拼多多平台上存在海量信息，因為互聯網技術及人力的局限性，拼多多不能保證平台上所有商品的信息均準確、完整、可靠、有效、沒有錯誤和沒有誤導性。除拼多多有明顯過錯外，對於因商品信息導致的糾紛，拼多多不承擔任何責任。（註：以往公司經常因為商品信息不準確或標價錯誤，而被消費者牽涉入官司中）
- 異常訂單處理：如拼多多發現您通過拼多多平台下達的訂單存在違反法律規定或者本協議約定的異常情形的，拼多多有權採取關閉相關交易訂單、限制賬戶使用功能、中止或終止服務等措施而無需事先通知您。（註：針對薅羊毛黑產們的大殺器！）
- 禁止行為：使用拼多多平台外掛和/或利用拼多多平台當中的 BUG 來獲得不正當的利益；（註：針對賺客們的大殺器！）
- 服務中斷：您理解並同意，拼多多需要定期或者不定期地對拼多多平台、設備進行維護或者檢修，因此造成的拼多多服務在合理時間內的中斷，拼多多無需為此承擔任何責任，但拼多多將儘可能事先通知您。（註：緊急事件發生的時候，可以主動關停服務！）
這是什麼？這特么就是金山銀海般的學費買來的寶貴戰鬥經驗，在雪崩之下挽救公司前程命運。
「買了豬肉直接往自己身上貼」，聽說過嗎？是不是覺得很荒謬？
可在現實生活中，無數「高科技公司」、「互聯網公司」都是這麼做的。他們對於決定了向客戶提供服務質量的關鍵環節，也會從第三方採購通用或經過簡單定製後的IT系統。
貼豬肉的最大問題是什麼？
它無法「擁抱變化」，無法「傳承」。
首先，不管是互聯網的輕公司還是重公司，業務方向、業務流程、數據流、部門組織結構都會隨需而變，甚至是劇烈變化，無法修改和傳承的IT系統等同於死物，讓人求生不能求死不得，要麼淪為信息孤島，要麼被人快速遺棄。
其次，買了一套或幾套現成的、通用的、割裂的IT系統，知其然不知其所以然，自己的隊伍既沒有得到鍛煉，也沒有可以一代一代傳承下去的經驗教訓、設計理念和技術架構。鐵打的營盤流水的兵，如果連營盤都是水貨，那後面人還玩什麼啊。
想上市嗎？我教你啊！
知道上市前有一個聘請外部事務所對公司做內部企業安全審計的環節嗎？
你確信你能過嗎？你確信不會被認定是數據造假、財務造假而被集體訴訟嗎？
十年前，年少無知的我們既沒有見識過成千上萬的企業員工，也沒有能預見到這些系統使用者里性情中人的概率有多大，所以等到處於數據鏈條最末端的財務和審計發現上游數據千奇百怪的時候，已然覆水難收。這也告誡產品設計者和系統開發者，永遠不要指望業務培訓和業務規範能奏效，在一個擁有成千上萬員工、百萬量級商戶和數以千萬計用戶的公司里，系統做好限制才是王道。
由於我們2011年就開始着手上市事宜，當年引入了德勤企業內部安全審計，所以在事情還沒有演變到不可收拾的地步之前，我們能夠開始着手建立各種制度、規範和系統，全都為了依法合規，最終幾年後登陸NASDAQ。
什麼是（技術上的）合規？
- 數據是平的。一個數據的產生肯定有前因後果，來龍去脈，不可能架空飛來，是的，審計就是要看數據是不是平的。審計秉持的態度是，企業可能在作假，我們要找出造假的證據。數據不平，就有可能是造假。
- 變更有操作記錄，即事後有跡可尋，保證歷史可回溯。這也就是為什麼我們開發了數據庫自動化運維繫統iDB，開發了運維自動化平台，開發了研發協作平台，開發了大數據協作平台的原因之一。
- 重要變更有審核記錄，即事前有看門人。我們的iDB里就留存着DBA審核工程師提交的數據庫變更請求的審核證據。
- 安全有效的保護，如數據庫備份的可恢復性測試需有書面證據證明。
- 責權利對等，即系統權限與員工崗位職責要對等。再譬如不要共用帳號。
後來人啥都不知道？那就再交一遍學費吧。
總而言之，言而總之，對於那些公司為了他的成長付出過高昂學費的，包括出了事故的，系統雪崩了的，集群腦裂宕掉的，被秒殺打垮了的等等，一定要保留住他們的火種，不然他們走了，就意味着公司交的學費化為烏有，公司是可以請新人，但所有的錯誤可能都重新犯一遍。
「為什麼要重新犯一遍錯呢？不能立個規矩說不要犯這個錯誤嗎？」，有些領導看到這兒估計會喃喃自語。
有產品專家這麼說道：
產品團隊管理的麻煩之處在於，它的知識傳承太感性，很難通過制度和流程的設置，讓經驗與教訓一代代傳遞下去。一顆雷你踩過之後，希望在這裡插一根旗杆，表示此處有雷，後來者繞路吧……這往往是沒用的。新人還得原封不動地再踩一次才恍然大悟。但如果直接禁止他去踩這個位置，又非常地挫傷積極性。
所以你會看到跟鬼打牆似的，一代又一代產品經理小白不見黃河心不死不撞南牆不回頭，攔都攔不住。
二樓打一樓篇
研發體系相對其他工種來說，更是「時間的朋友」。從古典軟硬件開發的角度，有着完備的知識體系，畢竟是「計算機科學」，算法、數據結構、TCP/IP、操作系統、編譯原理、加密解密、數據庫、內存、CPU、多線程、動態鏈接庫、序列化反序列化、安卓開發、iOS開發、網絡安全……立志從事這個行業的新人一本書一本書地讀，一個實驗一個實驗地做，一個點一個點地死磕，沒有捷徑。
我常說，剛工作一到三年的「打工人」，就是一年級小朋友，這個階段他們更沉醉於「開發語言的特性」上，沉迷於層出不窮的新「框架」。
隨着工作閱歷的增加，項目經驗的增加，到了三到六年工作經驗，就是二年級小朋友了。
到了哪個山頭就唱什麼歌，到了哪個歲數就干對應的事。二年級小朋友該幹什麼？
面試的時候，我經常嘲笑那些覺得自己看了springmvc/thinkphp框架源代碼就自以為了不起的工程師，看了又怎麼樣， 你不還是不會解決實際的商業問題，不還是照樣跌倒在高並發高負載高可用的真實場景面前。這實際上是另外一種設計模式的理念。
即一說到具體的商業問題，立刻就與之前臨摹過或者開發過的某種設計模式對上。比如「活動-活動規則」模式，一說鼓勵金打標，就立刻跟活動對上，鼓勵金打標只是活動類型之一，凡是活動必然有開始日期和結束日期，有活動規則，有活動預算，有活動標誌符號，做過電商的都知道商品角標。再比如「申請-審核-流水-操作日誌」模式，一說到費率變更，立刻就知道要有費率變更工單申請，有費率變更審核記錄，有費率待操作流水記錄，有操作日誌，這一系列全套表結構直接從原來做過的「訂單-交易流水-第三方支付操作日誌」或「退款申請-審核記錄-流水記錄-操作日誌」複製出來。
所以，二年級小朋友應該更多關注對商業設計的訓練。
你已經到了小學的中高年級了，要學會去研究優秀的商業系統是如何實現的，這個世界是如何構建出來的，而不是天天琢磨自己手中那把鎚子。
再上一層樓，七到十年的工作經驗，就是三年級小朋友了。
對各種商業的業務層設計和實現能如數家珍了，就會向業務層下面望去。那裡是平台層，再往下是基礎設施層。
如果說業務層的商業設計還屬於繁華的沿海區，那麼平台層就到了中西部了，基礎設施層可能到了戈壁灘甚至進了無人區。在這裡，我們遇到的問題往往沒有太好的參照物。
舉例，我們在2011年做電商業務的時候，沒有什麼可供參考的商業級別（高可靠性、高擴展性、耦合性低、降低開發者心智負擔型）的定時任務管理和調度平台、並行計算調度和管理平台、可靠消息推送平台、大數據協作調度和管理平台……
我們在2015年決心將商業系統全部遷入Docker集群的時候，沒有什麼k8s，只有mesos，甚至Docker公司連容器內互聯互通、容器與其他業務集群如何通訊都不成熟不健全，都需要摸着石頭過河。
2016年我們在全盤容器化的業務之上試圖將所有生產開發、持續集成、持續發佈都串聯起來，打造一個完美的混合雲跨機房協作平台，哪兒有什麼可參考的。
2017年我們做異地多活調度和管理平台，哪兒有什麼可參考的，頂多知道要做單元格管理，只能是自己量體裁衣。
是的，三樓打二樓，二樓打一樓，打的就是視野、高度和寬度。
這就是研發。
產品又有不同。
有人這麼形容產品經理的成長：
產品能力是不可能勻速提高的，定期培訓、維護項目什麼的都很難促成。產品能力的快速提高通常是在一段時間內，承受了巨大的項目壓力時，迅速地做出了反應，然後直接level up。只是這樣的機會並不多，能夠抗住高壓想出解決方案的，也不多。
我們可以認為，產品經理以平平淡淡過一生的方式，是不可能level up的，這是與研發體系不大一樣的地方。
產品經理的二樓和三樓，還真的與王國維的《人間詞話》三境界相似：
「古今之成大事業、大學問者，必經過三種之境界：
『昨夜西風凋碧樹。獨上高樓，望盡天涯路』。此第一境也。
『衣帶漸寬終不悔，為伊消得人憔悴。』此第二境也。
『眾里尋他千百度，驀然回首，那人卻在，燈火闌珊處』。此第三境也。」
對，就是一種體悟，一種頓悟。
那麼產品經理的「頓悟」從何而來呢？我以為分三步：
第一步，公司願意投資他，為他埋單，願意墊付巨額學費；
第二步，聰明的產品經理會在本公司產品快速試錯的過程中，教學相長和走訪客戶，不斷總結不斷提高，形成哲學，凝練方法論，找到一絲絲感覺；
第三步，高速成長的行業里，一大批聰明的產品經理們在高速追逐競賽中互相學習互相超越，最終形成感覺，頓悟。
同樣的道理，這都是公司花了錢喂出來的「神槍手」，你把他們裁掉了、氣走了、趕走了，那你的公司也就沒有活下去的意義了。
遠見篇
遠見從何而來？
心理學原理中就有一個著名的隧道視野效應。一個人若身處隧道，他看到的就只是前後非常狹窄的視野。因為視野不寬，所見有限，所以無法對當前的環境和處境做出準確判斷，更意識不到事物的長遠發展趨勢，從而容易使人做出目光短淺的決策。
所以隨着歲數和閱歷的增長，到了一定級別之後，相對來說就更有閑暇時光，有更多的心力腦力體力去關注更高層面的事情。就這些幹部而言，如想要帶動團隊和企業的發展，便不能缺乏遠見和洞察力，只有視野開闊，方能看得高遠。如果幹部將自己置身於隧道當中，那他只能看到身前的一點光亮，必然不能夠做出高瞻遠矚的決定。
長時間地專註於技術和商業，未必能獲得遠見。
功夫在詩外，還需要有更多的空閑時間，投放在那些看上去與當下的商業行為無關的知識樹和技能樹上。
996、997、111106，把人的全部身心填滿，一年級和二年級的小朋友可以有，三年級以上的決定了更高層級體系建設和組織行為的同學就不要這麼做了。
35歲員工好不容易走出隧道，看見了赫赫清光就在前方，然後公司咔嚓給人裁了，你說是誰的損失？
一言以蔽之，通過對「交學費」、「二樓打一樓」、「遠見」三個維度的分析，我認同王新喜在《別急着拋棄35歲員工》一文中的觀點：「一家科技企業，為了降低用工成本，盲目淘汰35歲老員工或是一種短視，而那些厚積薄發的人才，它所能帶來的經驗積累與爆發點往往也在35~40歲這個階段，這是職場員工最為心智成熟以及對行業趨勢具備較深的理解的時候，如果是技術研髮型員工，往往能對一家企業在技術上關鍵節點的突破帶來真正的助力，這並非年輕的新員工所能替代。」
-完-
