昀哥 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歲這個階段,這是職場員工最為心智成熟以及對行業趨勢具備較深的理解的時候,如果是技術研發型員工,往往能對一家企業在技術上關鍵節點的突破帶來真正的助力,這并非年輕的新員工所能替代,”
-完-
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/213781.html
標籤:其他
上一篇:【軟體測驗理論基礎】記錄第一個Bug的誕生,為什么軟體缺陷叫Bug/Defect?
下一篇:tomcat環境搭建
