大家好，我是若川。今天推薦一篇95年的博文的文章。他的故事應該挺多人知道。如果不知道可以看他的博客 https://github.com/berwin/blog
點擊下方卡片關注我、加個星標
時間好快，眨眼間，加入阿里已經一年了。這一年發生了很多事，整體上非常地充實且精彩，在一件又一件事情中，我不停地犯錯，一路走來，步履蹣跚，也收獲到了很多成長。每次結束一件事后，經過短暫寧靜的生活便再次踏上新的征程。
之前寫過一篇《暢銷書《深入淺出Vue.js》作者，在阿里淘系6個月的收獲成長》，因此文本主要講述“后半年”收獲的成長。
1. 關于“思考”
Mentor：你平時周末都做些什么？
我：沒事的時候通常會看看書，寫寫代碼，研究一些自己感興趣的東西
Mentor：可以把一些平時做事的時間換成什么都不做，坐在那“思考”，想一些東西
以上對話來自一次我向導師詢問的一個問題：“我應該如何再進一步，7和8的區別是什么”（大致是這個問題，原問題記不清了????）。
7和8之間就級別本身的區別優勢是 “可以調動更多資源”。之所以需要調動更多資源是因為需要做更復雜的事。復雜的事哪來？“思考得來”，當然也可以靠主管分配，但誰又能保證主管一定會把那個機遇分配給自己。
完全靠主管分配機遇，這也違背我內心一直以來所堅定的信念：“讓事情因為自己而與眾不同”。今天能通過面試進入到阿里巴巴的同學，能力都不差，主管把機遇分配給另一個人絕大概率拿到的結果不會比我差多少，一件事情究竟是因為我去做才拿到好結果，還是大家去做都能拿到好結果，不太好說，這達不到“讓事情因為自己而與眾不同”的標準。
只有自己憑空創造出的機遇并最終拿到了結果，才符合“讓事情因為自己而與眾不同”，也更能展現出自己的水平。
所以一個更可靠的發展路徑是：
多思考項目未來的發展方向和現有技術體系的問題
做判斷并按照正確的方向執行
事情足夠大就會衍生出調動更多資源的需求
時機成熟后，可能會晉升到下一個級別以方便調動更多資源
這會衍生出一個新問題，“如果自己思考的項目未來發展方向和大團隊方向不一致怎么辦？”
其實不用擔心，可以和主管多溝通對焦，如果自己思考得來的方向客觀事實上是正確的方向（各方面受益都更高）或者是絕大多數人都信任是一個正確的方向，那么正確的方向一定會替換掉錯誤的方向。
2. 技術與業務兩條腿走路
一定要 “技術與業務兩條腿走路”。這是我主管和我導師對我的忠告，當兩個經驗豐厚的大佬不約而同地給了相同的建議，足以證明這句話的分量，這也引起我深思。
自從我開始工作，我都是只搞技術，我對業務其實不太感興趣，我很崇拜那些知名的技術很強的世界頂級工程師，一直以來我的夢想都是想成為他們中的一員，想成為前端行業技術吊炸天的世界頂級工程師。
但現在我漸漸意識到，不能只搞技術，也要多思考思考自己的業務，這對自己是有好處的，對業務多思考的好處是：
提前對技術體系做布局，引領技術與項目，避免業務突然變化時陷入被動
對現有支撐業務“較為成熟”的“有瓶頸”的技術體系做出改革與突破
避免讓自己成為“工具人”
讓“技術”和“業務”互相成就彼此，共同成長。業務發展倒逼技術改進，技術改進成就業務，相佐相成。身為技術同學，可以基于對業務的預判用技術落地項目輔佐業務，業務的成功再反過來成就技術。
千萬不要陷入到一個巨大的誤區：技術的自嗨，其實并沒有多大貢獻。
所有偉大的技術創新，都是那些對社會有巨大貢獻的技術，偉大技術的誕生，都是基于一個不被滿足的“需求”，基本上偉大的技術都是這樣被創造出來的（Git、React、Vue又或是支撐公司業務背后的技術體系）。
只有對業務足夠了解，思考的足夠深，才能知道用戶需要什么，才有可能引領未來支撐業務的技術體系，才有可能創造出改變世界的偉大的技術。
一門心思只搞技術，很難做到“引領”和“創新”。大概率只能做到學習現有已被其他人創造出來的技術，學到精通，成為某領域專家，但很難引領某個技術領域。
3. 穩定發揮
發揮穩定型（線性增長）選手比階段性發揮波峰波谷選手更有優勢，穩定（可預測性）本身就是一種優點。發揮不穩定的選手，缺點是不可預測，換位思考如果自己是主管，有一件很重要的事，你敢交給發揮不穩定的選手么，萬一碰上發揮較弱的時間段，就悲劇了。
這個道理，在電子競技、體育競技等領域都相通，發揮不穩定是不可能拿到冠軍的。
剛進入一家公司，在一個新環境都會有點著急，急于拿到成績得到認可，這本身其實是件好事，但不要把勁使大了，把自己變成了那個波峰波谷型選手。放輕松一點，少使點勁，讓自己線性成長穩定發揮。畢竟，職業生涯本就是一場“沒有終點的長跑”，大家比拼的并不是短期內誰跑的更快，而是“堅持”，在這條賽道上能跑贏的，不是那些跑得快的人，而是為數不多堅持跑的人，他們能跑贏，只是因為還在跑。
4. 求同尊異
某一刻，我終于理解了這四個字，這要從一件事說起。
最開始，為了幫助團隊成員“提升個人寫作”、“提升表達能力”、“提升個人技術成長”，我提出了文章計劃，團隊成員每個人大概每5個月寫一篇文章，同時發明了 “貝利體系” 作為獎懲機制，每人每月按照一定的數量自動掉貝利，貝利掉多了需要接受懲罰，發表了文章后獎勵貝利，只要保證每5個月寫一篇文章貝利就不會達到懲罰線，具體數值都是我計算好的，并寫了段程序自動執行，拿到手里的貝利可以用來兌換一些禮物，有HHKB、AirPods等可以兌換。
后來“文章計劃”受到了大家的集體挑戰，覺得給大家造成了非常大的壓力和負擔，“文章計劃”就宣告結束，不過 “貝利體系” 被我保留了下來，雖然不強制大家寫文章了，但依然鼓勵自愿寫文章的同學，并給予貝利獎勵。
這時我對貝利體系進行了一些思考，并重新定位：“衡量體系”，衡量團隊成員對“團隊建設”、“組織文化”、“橫向貢獻”的貢獻值，助力團隊和文化的橫向建設。簡單來說，就是所有對團隊橫向有付出的同學，我都會按照貢獻的大小付出的多少來獎勵貝利，且有一個排名，排名高代表橫向貢獻多，我會給予貢獻多的一些同學發一些禮品，貝利本身也可以自行兌換禮物：HHKB、AirPods等。
我希望貝利體系和團隊橫向的事情，例如：團建、招聘、安全生產、寫文章、技術分享、對現有產品提改進建議、組織大家健身、組織大家玩桌游等有更深度的結合。
因此，有一天，我提出一個想法：讓貝利少的人舉辦團隊的團建，并給予舉辦團建的人獎勵貝利，主要考慮給團隊橫向貢獻少的同學多些機會做些貢獻。且在團建過程中結合貝利有一些有趣的玩法，例如可以按照貝利的多少設定初始裝備（貝利高，團建玩游戲時略有優勢，但又不失平衡）。
但這個提議被團隊負責團建的同事拒絕（因為他認為貝利不客觀公正，無法客觀衡量誰貢獻少）。當時我覺得這是一個對團隊有幫助的好事，可能它暫時不完美，但我會持續優化，我是在“堅持做正確的事”。而且當場我問同事覺得哪里有缺陷需要改進也說不上來，再加上我覺得自己在做正確的事，在讓這個團隊變得更好，所以我就和同事大吵了一架，對，我又雙叒叕和人吵架了，而且這次格外激烈。
我對自己進行了深度的反思，“貝利體系”打被我憑空創造出來之后，無論是面向用戶，還是面向合作方，都不是很受歡迎。面向客戶，團隊成員覺得這是一種壓力和負擔。面向合作方，團隊橫向負責人沒有與貝利體系合作的動力和需求。這件事本身不是大事，但做這件事卻非常難，貝利誕生到現在一直被大家抵觸，被大家無視，還有人覺得這是幾個人之間的小眾游戲。
但我又不想放棄，我想讓我們團隊因為我的存在變得不一樣，而我又堅信這是正確的事，是一件好事。為此我和主管聊了兩三次，學到了一些知識和做事的方法，總結提煉出精華：
不要以自己為中心去思考問題，要換位到“團隊視角”，“合作視角”全方位立體多維度思考問題
推進事情要考慮：“共贏”，“利他”
貝利體系誕生以來，所有的“規則”（包括哪些貢獻應該獎勵，獎勵多少）都是我一個人定，大家內心是“不認可”的，因此外在表現就是“你自己玩你自己的，我不參與”。換位思考，每個人都會抵觸自己“不認可”的事情。
這一刻我終于體會到，也理解了什么叫“求同尊異”，每個人都不一樣，也不是所有人都和自己想法一樣，要尊重不同的建議和聲音。一件事，只有大家認可了才能贏得尊重和成功，要贏得客戶的認可，贏得合作伙伴的認可。
后續：
這件事之后，現有的“規則”我都通過匿名調查問卷的方式投票決定，調查大家認為哪些應該獎勵，應該獎勵多少，哪些不應該獎勵，并根據調查問卷的結果進行了修改。
所有的規則，完全由匿名投票大家共同決定，規則制度“公開透明”，由全體成員“共同參與”。并且提供了日常的“實名”和“匿名”雙通道接收意見反饋，并給反饋意見的同學獎勵貝利。獲取貝利和消耗貝利的方式也變得更加的多樣化。且這些新的多元化的獲取和消耗貝利的方式都是由團隊成員大家共同貢獻出來的。經過一系列的調整，整體認可度相比之前有了很大的改善，貝利體系在向著更好的方向邁進。
年前也按照大家的貝利數量給大家發放了同等價值的禮品，并啟動新一輪周期，大家都很開心。
這件事雖然不大，但是它教會了我 “如何推進事情”，未來我大概率會打破現有已經“成熟”甚至“固化”的技術體系，為現有技術體系做一些改進，讓它變的更好，那么推進并贏得大家的“認可”和“尊重”與這件事是相同的，通過這件事，我提前得到了鍛煉，這是無價的寶藏。
5. 身為PM如何做事
感謝主管的培養和信任，不止給我很多試錯空間，還在我犯錯后教我如何做才是正確的做法。
5.1 “風險”和“進展”及時同步
關于風險同步在《我在阿里半年收獲的成長》有提到過，最近又有了新的感悟：不要擔心“做的不好”或“不完美”而不敢同步進展和風險，因為“差的信息”比“沒有信息”要好很多！
及時同步“風險”和“進展”的好處是：如果真的做錯了，會得到及時的糾正和幫助，可以保證項目是安全的，項目安全永遠是第一位。不要擔心大家會覺得自己菜，自己菜不菜根本沒人關心，大家關心是：
項目能不能“按期”、“高質”交付
你是否在成長
哪怕中途做一步錯一步，也比中途“毫無音訊”強無數倍。 即便是中途做一步錯一步，但由于及時同步了風險和進度，在不停地犯錯中一點點把項目做好，最終大家也會看到自己的成長。會對自己很放心，下次類似的事情交給自己會讓人安心，因為再差再差，自己也不會把事情搞砸。
5.2 線上問題如何應對
線上出了事故后，立刻向上匯報，不要自己先悶著頭去修復！避免業務方找過來時主管完全不知情，這種情況整體都會很被動！
反饋問題的方式：
站在用戶視角描述發生的問題
影響面預估（面向用戶的影響面，不是判斷技術哪里報錯，判斷不清楚默認當做重大影響處理）
處理策略
如果有原因，提供原因
5.3 不要把自己當做唯一的資源
當接到一個任務后，首先考慮的是 “怎樣把這件事做的更好”，“誰來做更合適”，不要把自己當做唯一的資源。
合適的事讓合適的人來負責，接到任務后第一個想的是如何把事做好，誰來做更合適，如果自己擅長某一塊可以自己去做，如果某一塊有更合適的人選，那就應該找到合適的人來做，而不是自己去做。
5.4 “悲觀”態度給答復
如果評估不準某個功能是否可以按期上線，一律按 “悲觀” 態度給反饋（本質其實是：提升專業性，預判風險，做好預期管理）。新手PM都會犯一個錯，那就是，雖然心里感覺大概率在Deadline前開發不完，但還是會和產品說：“我試試”。
我見過的，除了我還有新手PM也犯了這個錯，那就是一句：“我試試”（覺得大概率來不及，但還是和產品說感覺來不及，但我努努力試試）。最終沒有按期上線時產品就會找過來問為什么沒有上線，“不認可”這個結果。
所以，如果評估不準，或感覺有風險，一律給悲觀答復。如果一開始有來不及的可能，在一開始就給來不及的“明確反饋”。
5.5 做技術判斷
技術PM最重要的核心競爭力和職責叫做：技術判斷。像雙11這種級別的大促，每個功能所涉及的上下游鏈路都會非常復雜，橫跨N多個團隊，這就意味著，同一件事，可以有N種解決方案，而不同團隊看待問題的視角不同，因此大家給出的方案和傾向性很多時候會有沖突，這時候技術PM要做的就是給一個技術判斷，方案1、2、3、優缺點是什么，讓高年級同學拍板。而不是把一個問題拋上去讓高年級同學們想方案。因為信息是越底層知道的越多，越上層對細節的信息越少。
6. 總結
不知不覺，來阿里已經一年了。這一年是我近幾年來成長最快的一年，自己的思維和想法，都有了質的提升。非常感謝舒文把我帶到這個團隊，以我的學歷正常很難進到這個團隊，經常感嘆自己真的是憑運氣遇到貴人。還非常感謝墨冥（我的主管），這一年來不斷地言傳身教并給予機會試錯，這一年來的成長（可參考這兩篇文章《暢銷書《深入淺出Vue.js》作者，在阿里淘系6個月的收獲成長》，《暢銷書《深入淺出Vue.js》作者，在阿里淘系1年的收獲成長》）絕大部分來自墨冥的教導，再次感嘆自己的好運氣。
相信未來，我會在實戰中承擔更大的職責，相信未來，我會讓我們團隊因為我的存在變得不一樣。
最后，在舒文身上學到了一個原則，特別認同：
學會堅持，“長時間的積累”永遠比“為了短期高收益頻繁切換”收益高，無論是“日常做事”、“投資”還是“職業規劃”、“人生規劃”等。
舒文經常說：“做成一件事情”有很多因素，“堅持”是成本最低的一種。
最近組建了一個江西人的前端交流群，如果你也是江西人可以加我微信 ruochuan12 拉你進群。
今日話題
略。歡迎分享、收藏、點贊、在看我的公眾號文章~
一個愿景是幫助5年內前端人走向前列的公眾號
可加我個人微信?ruochuan12，長期交流學習
推薦閱讀
我在阿里招前端，我該怎么幫你（可進模擬面試群）
2年前端經驗，做的項目沒技術含量，怎么辦？
點擊上方卡片關注我、加個星標
·················?若川簡介?·················
你好，我是若川，畢業于江西高校。現在是一名前端開發“工程師”。寫有《學習源碼整體架構系列》多篇，在知乎、掘金收獲超百萬閱讀。
從2014年起，每年都會寫一篇年度總結，已經寫了7篇，點擊查看年度總結。
同時，活躍在知乎@若川，掘金@若川。致力于分享前端開發經驗，愿景：幫助5年內前端人走向前列。
)
