本文作者：劉博文（Berwin），花名“玖五”，暢銷書《深入淺出Vue.js》作者、知名技術博主、講師、阿里巴巴淘系技術部前端技術專家，現負責淘系618、雙11等超大型營銷活動主會場的終端渲染架構。
回想起年初剛來杭州那會，是疫情正嚴重的時候，那時候剛來杭州要住半個月的酒店，然後才能進入阿里巴巴溪西園區（後續簡稱”園區”），時間過得飛快，一晃已經來杭州半年了，這半年經歷了很多，也學到了很多，寫一篇文章總結下這半年來自己的成長。
勇於挑戰權威
要勇於挑戰權威，發現現有技術體系的問題，並解決它。
記得當時剛來杭州時，心情是非常忐忑的，對未來非常憧憬，能和那麼多很厲害的工程師一起工作是一件特別爽的事，再加上我們團隊是做雙十一大促會場的，技術人都知道雙十一對工程師來說意味着什麼。入職後，一大堆技術名詞和各種技術體系鋪面而來也確實讓我感受到了技術的強大，所以就一直以學習的心態在瞭解和接觸現有的技術體系。
進入園區後第二個月就開啓了618戰役，感謝主管墨冥的信任，當時我承擔了一個非常重要的專項PM（Project Manager），它在整個618戰役裏都算是風險和挑戰都非常高的專項，也是因爲這件事幹的還不錯，上線後非常穩定，因此我獲得了618戰役獎勵優秀PM的一個“厲害了Work哥 - 此時此刻非我莫屬”獎，獎狀在淘寶樓裏掛了三四個月，入職不到3個月就獲獎應該算是比較值得自豪的事了。
說這個當然不只是爲了顯擺，就在我以爲自己表現非常好的時候到了轉正面試的時間，雖然通過了試用期，但得到的反饋是對我的表現沒有超出預期，我的執行力雖然很強，但我“沒有對現有技術體系帶來變化”。
換句話說，招我來的目的不是來當資源的，618戰役雖然打的不錯，但說實話換個人上去又能差到哪裏去？大家對我的期望是對現有比較成熟的體系帶來變革。
那怎麼對現有體系帶來變革？經過大家的引導和我自己的思考，答案是：”發現現有體系的問題“。我剛來覺得這裏技術體系特別牛，加上沉澱了這麼多年的雙十一，已經是比較成熟的技術，覺得這是一個權威，不可能有問題，所以一直抱着膜拜的想法在瞭解和學習現有體系，所以這就是問題所在。
這時候我學會的最深刻的一個成長是：“要勇於挑戰權威，發現現有技術體系的問題，並解決它。”
身爲PM如何推進事情
感謝主管的培養和信任，給了我很多試錯空間，入職到現在這半年時間從第一次當PM到現在，犯了很多錯誤，在一次次犯錯後也學習到了很多當Project Manager的知識，本小節將這些成長總結起來分享給大家。
▐ 解決合作阻礙
在推進項目時，有時會遇到一些阻礙，例如：不配合，難合作，主動性差等問題。絕大部分能來到阿里工作的同學不會是“能力”或“態度”問題，所以大部分阻礙可以歸結於：
1、信息不一致
2、目標不一致
3、優先級不一致
解決障礙，就是在解決以上這三點，信息不一致可以靠“溝通”和“換位思考”解決，而“目標不一致”和“優先級不一致”可以靠“上升”解決，只要事情足夠重要，給出幾種解決方案，上升到某個級別問題一定會被按照最合理的方案解決。
▐ 建立自己的權威
入職大概三個月左右的時候，我發現PD（產品經理，在阿里巴巴我們稱爲 Product Design，即：“產品設計”）在與我合作的過程中對我是有點不信任的，例如：相同的答案PD會相信我師兄和主管、我給了方案後PD會再去找我主管詢問是否有更好的方案等。這也讓我有了很多成長，當時我還特地去向二級主管請教一些方法。
拉人佐證自己的判斷
案例一：在沒有建立起自己的權威前，很多時候PD並不相信我給出的方案。那麼這種情況解決方案是：假設有3種方案，將各自的利弊信息同步給PD後，如果都不滿意，可以拉其他人，例如拉自己的主管進來，佐證自己的判斷。（但前提是自己要做好功課，先和主管溝通好達成一致，再將信息同步給PD）。
案例二：假設現有兩種方案各有利弊，完美的方案需要團隊A配合，那麼可以拉着自己的PD去和團隊A的PD談（前提是要先和自己的PD達成一致，並且以自己爲主導拉PD只是來佐證自己的判斷），一方面向團隊A的PD佐證自己提的需求是重要的，另一方面也可以向自己的PD佐證這個需求確實沒那麼簡單。如果事情推進遇到阻塞，回到“解決合作阻礙”小節，最終問題一定會被解決。
拉主管進來是爲了佐證自己的判斷，而不是和PD一起把複雜問題拋出去。
拉主管佐證要先溝通好達成一致，不是突然把主管拉進來佐證自己，避免主管的判斷和自己不一致當場被打臉
資源不足而PD說我都要怎麼辦？
先和主管達成一致，客觀評估需求是否真的重要到需要拉其他同學來幫忙開發，在一個更宏觀的角度評估哪個需求優先級更高，然後再給PD同步結論，如果不接受拉主管進來還是相同的結論，再不接受再拉主管的主管也是相同的結論。權威就是在日常這樣一點點建立起來的。
與PD合作的藝術
回到最初的問題，PD爲什麼要找我主管尋求幫助？
1、她想把事情更好地推進下去
2、她覺得找主管會有更令她滿意的方案
本質上是我還沒有建立起自己的權威，另外PD是信息弱勢方，所以如果我給出的方案她不滿意時，她會去找她更信任的人尋求幫助看是否有更好的方案，那麼如果這時真得到了一個更滿意的方案，那麼她會覺得這招管用下回還會再去，這時候我的權威就會崩塌。
解決方案是：提前做功課給到PD的信息永遠是權威的判斷，在不信任自己時拉人佐證自己的判斷是對的，或者和PD一起去找其他人繼續推進&解決問題，逐漸讓PD意識到即便是找了其他更信任的人也會得到相同的結論，我的結論就是正確且權威的。
積累自己的信用
作爲新同學，可能會發現同一件事，同一個解法，PD經常會不信任新同學。
這裏日常工作本質上是累積信用和消費信用的過程，解決方案是：在日常工作中一點點累積自己的信用，當機會來臨要勇於消費信用去推動事情，這也是體現“此時此刻，非我莫屬”的阿里巴巴價值觀。
當然，打了敗仗，信用也會消耗，經常打敗仗即便不是新同學也很難讓人信任，所以還是要靠自己的本事來積累信用並建立權威。
▐ 項目風險同步
這半年時間，關於風險同步我犯過兩次錯誤，這兩次錯誤也分別讓我學到了兩種關於項目風險的經驗。
**風險同步：Case 1
**
事情發生在今年的88大促，當時我爲會場底層渲染架構全新升級了一版，在一個極短的時間用新開發的2.0追上了正在運行的1.0的大部分功能，然後在88大促切換到2.0，可以類比在天上給飛機換引擎。切換2.0後如預料中的一樣，出了一些小問題。
問題在於，給飛機換引擎這個動作和行爲，我沒有通知給業務方，導致出了問題的時候，業務方很驚訝，爲什麼之前一直好好的這次突然出了這麼多問題？業務方對這個事沒有任何預期。
在這件事上，我學到的是：在做一件事時，要通知到所有可能會因爲這件事而受到影響的人，把自己的計劃，方案，風險等信息完全同步給可能會受到影響的人，好處是：
人多力量大，如果方案確實不成熟，有漏洞大家可以一起完善提高穩定性
大家都知道這件事，而且計劃、方案、風險、預案都得到了大家的認可，即使真的出問題也不會給大家“驚喜”
風險同步：Case 2
事情的背景是，有一次我負責一件事，這件事在過程中我發現進度有延遲的風險，但當時我選擇了自己抗下來，加加班，趕趕進度。後面我低估了這件事的嚴重性，導致最後實在扛不住了才暴露風險，緊急加人解決了這件事，雖然這件事沒引起問題，但是這個最後臨門一腳才暴露風險這個行爲是不對的。
通過這件事，我也學會了如何做事是對的（感謝主管孜孜不倦的教導），暴露風險不是懦弱和能力不行的體現，暴露風險是一個PM的專業素質，不要自己硬扛風險和壓力，過程中有風險需要幫助應及時提，避免到最後扛不住纔將風險暴露出來。
▐ 誤區：不敢上升和暴露風險
新人入職都會進入一個誤區：
1、爲什麼我負責的項目，大家都在爭論不休，是不是我能力不行？
2、爲什麼我負責的項目，好多事我都解決不了需要靠更高級別的同學來拍板，是不是我能力不行？
3、爲什麼我負責的項目，又又又又有風險了，是不是我能力不行？
現在我可以很明確的告訴大家，不是，完全不是！
推進項目受阻有很多原因，絕大部分都不是自己這個位置能解決的，上升是非常高效的解決方案。
項目遇到風險也是同樣的道理，除了確實是自己能力導致的風險以外，絕大部分風險都是客觀存在的事實，和自己能力沒關係，即時且充分暴露風險尋求資源解決風險纔是王道，這反而是一名專業的PM應該具備的基本素質。
PM的職業素養
PM的目標只有一個：“確保項目按時保質上線”，但過程也同樣重要，阿里巴巴有句土話我很喜歡：沒有過程的結果是“垃圾”，沒有結果的過程是“放屁”。
在推進項目的過程中，一名合格的PM需要具備的基本素養是：
- 擁有Owner的心態
- 做關鍵技術決策
- 充分暴露風險
- 調動能調動的一切力量
內心時刻銘記一句團隊內廣爲流傳的名言：所有關於事的困難可以靠堅持解決，所有關於人的困難可以靠換位思考解決。
▐ 關於情緒控制
項目複雜且生產關係也複雜的時候，會遇到各種困難和阻塞。溝通工作時很容易情緒失控，但身爲一名合格的PM，任何時候，不應該被情緒控制自己的判斷。
任何時候，都應該基於客觀事實理性分析問題，不應該帶有主觀的執念。
這也是未來我要加強訓練的一點，過去這半年，我經常情緒失控，未來我會克服這一點，做一名專業的Project Manager。
▐ 關於方案評估
評估某個方案是否可行，不應該只是評估技術上是否可行，還要考慮按照這個方案推進後，會帶來怎樣的影響。
關於這點我曾犯過一次錯，在技術方案的評審上，我只判斷了技術的可行性就同意了某個方案，但是我沒有考慮按照這個解決方案推進後會帶來很大的其他影響。後面我師兄及時制止了這件事的發生，但是已經答應了PD按照某個方案推進結果又反悔，對於我這種新人甚至是我們團隊在PD心中，都是非常消耗信用的一件事，“積累信用可能需要好久，但消耗信用，僅僅只是一次無意間的失誤”，要珍惜自己的信用，“信用”，纔是PM推進事情時的通行證。
▐ 避免無意中踢皮球的情況
客戶（運營、產品、其他人）有疑問來向自己諮詢的時候，即便不是自己負責的域，也不要直接和客戶說你去找誰誰誰。正確的做法是先把問題攬下來，然後團隊內部找對應的同學拉個羣解決。
我就曾遇到過這種被踢皮球的情況，我有疑問找了A，A說讓我找B，B讓我找C，C說他不負責這事，然後我直接找了他們共同的主管，問題解決。
我知道他們不是故意踢皮球，但在我找不到他們1號位是誰的時候，用這種方式對我來說是最快速解決問題的方案。這首先對於客戶的體感不好，另一個是我向他們共同的主管尋求幫助後，他們的體感也不好。所以，要有owner心態，“讓業務方幸福，讓主管信任”。
前端工程師的職業素養
前面說了很多關於PM我犯的錯和收穫到的成長，那麼作爲一名前端工程師，這半年也收穫了一些成長。
▐ 做一名有“標籤”的人
要做一名有標籤，有特色，有影響力的人，在公司工作了一段時間後，在人們心中不應該只是一名“前端工程師”，應該是一名XXX的前端工程師。
標籤應該自己去努力獲取，有兩個標籤是我現在在努力獲取的：“雙十一前端PM” 和 “不到30歲的P8”。
▐ 讓事情因爲自己而與衆不同
一個靈魂拷問：今天我負責的事，我做完和其他人做完有什麼不一樣？今天我作爲Project Manager負責某個項目，如果換做其他人來，會有什麼區別？
今天獲獎也好，得到一個好績效也好，真的是因爲自己做得好，還是因爲主管把自己放在這個位置得到了更多的資源所以做得好？如果把其他人放到這個位置，和自己會有什麼區別？這是一個值得思考的問題。
一個特別大的誤區是：認爲自己技術好，所以比其他人做的好。今天能進阿里的同學技術上都不會差，再加上大部分工作都不是去造火箭，所以 “技術好 !== 拿到好結果”，技術好會增加拿到好結果的概率，但不是一定能拿到好結果。
所以，要讓自己負責的項目，因爲PM是自己，而變得不一樣。要讓自己的團隊，因爲自己的存在，而變得不一樣。
▐ 學會換位思考
換位到更高維度思考，很多時候不理解的事就理解了。換位到合作伙伴的維度思考，就理解他爲什麼會不配合，難合作，主動性差。換位到客戶的角度思考，就理解她爲什麼會不信任自己。
還是那句話：所有關於事的困難可以靠堅持解決，所有關於人的困難可以靠換位思考解決。
▐ 溝通的藝術
這是有一次和主管聊天中學到的，和人溝通，一定要學會聆聽，解決衝突或問題時，第一步是“聆聽”，先聆聽，充分了解信息後，再基於客觀事實把事攤開了，並基於客觀事實講述正確的做法是什麼，然後再去指點哪些地方可能不足。
如果不聆聽就做判斷，試想在沒有得到足夠信息輸入時就做判斷，判斷真的客觀麼？還是自己主觀上有傾向？就算自己對情況完全瞭解，不需要輸入也可以做判斷，那信息的輸出方會不會認爲自己做的判斷不夠客觀？因爲自己都沒有聽他說的是什麼就做判斷，他一定會質疑自己的判斷是否公正。
總結
半年來，成長遠不止這些，還是感謝舒文把我帶到這個團隊，賜予機遇和指導。感謝主管墨冥這半年來不斷地言傳身教並給予機會試錯，相信未來，我會在實戰中承擔更大的職責，相信未來，我會讓我們團隊因爲我的存在變得不一樣。
原文鏈接
本文爲阿里雲原創內容，未經允許不得轉載。