我們在這里不會談社交媒體上的影響力，這需要動用種類繁多的運營和技術手段，本篇文章里要解決的問題非常簡單：如何才能讓他人跟隨你的建議行動，
影響力無關權力
上級對下級的影響力就一定天然成立嗎？雖然權力階梯存在，但并不意味著權力絕對有效，因為強制力雖然可以保證事情得以發生，執行效果卻并不掌握在 leader 手中，我們都明白如果團隊成員并不認可和理解接下來的愿景，他們會做的只是取悅般地服從而已：我不會花心思把它做得更好，它的成功與否也與我無關，
我們每個人一定見過一種型別的角色，雖然他們不具有特殊頭銜，但是他們的意見總會被認可，他們的建議常常被采納，甚至你會發現當同事們遇到麻煩時第一時間想到的找他們尋求幫助——這便是影響力的魅力，相反，我相信在我們每個人的職業生涯中，有無數經理以及領導是被我們所厭惡或者陽奉陰違地對待的，我曾經閱讀過一本非常好談領導力的圖書：You Don't Need a Title to Be a Leader，這個標題在這里稍作修改依然成立：You don’t need a title to have influence.
我們在影響誰
在討論如何影響「他們」之前，我們首先要搞清楚「他們」究竟是怎樣一類人群——只不過是一群程式員不是嗎？——這恰恰是他們的特殊之處，與傳統文職人員或者藍領工人都不盡相同，雖然軟體制造如今看來是與勞動密集型產業無異，“極客精神” (geek) 的特質依然保留在他們的骨子里，
如果你在 google 中搜索 ”how to manage geeks”，有一篇經久不衰的文章會出現搜索結果前列:Opinion: The unspoken truth about managing geeks. 這篇發布于09年文章里觀察到的現象以及得出的結論現在看來毫不過時，采用文章中的原話一言以蔽之就是：
IT pros will prefer a jerk who is always right over a nice person who is always wrong.
與其他行業的人員相比不同之處在于，程式員服從的并非某個頭銜或者某套流程，這里服從的本質上是對他人發自內心的尊重，而尊重來源于對一個事實的判斷：你可否把事情做對，這個前提是如此地重要，以至于讓作業中的其他內容都顯得黯然失色，正如我在參考的原文中所說的那樣，哪怕你是個混蛋也無所謂，在該前提下程式員的種種行為用傳統的職場觀念來衡量起來是匪夷所思的，例如程式員之間的爭吵通常圍繞的是更好的解決方案是什么，而不是誰來做以及如何能干得更少；上級的建議也不會是必須遵循的金科玉律，他們會按照自己的想法實施，不幸的是他們的想法永遠都是對的，
與需要巧言令色討好其他職位的角色不同，贏得程式員尊重的標準答案僅此而已，然而對于外行而言如果你意識不到這條潛規則的存在，你會在和程式員打交道的程序中步履維艱，
當我們意識到這個事實之后，便有了塑造影響力的方向，
塑造影響力
把事情做對并無訣竅可言，它等同于在考驗你的綜合能力，你對業務理解要正確，用代碼表達業務要到位，然而這聽上去像是人人都應該做到及格線，只是昭示著你來到了這個圈子而已，我們如何借此來擴大我們的影響力呢？
我的建議是「專精」：你的答案要比他人更接近正確才行，
剛剛我們一直在回避一個問題，即對于「正確」的定義，當我們在聊「正確」的時候，我們其實聊的是實實在在的東西，代碼的正確性包含它的復雜度、可維護性以及執行效率等等，并且它們是絕對的，在解決同一個問題時如果你的代碼行數更少、運行時間更快、可讀性更好，那勝出便當之無愧，
如果上面的敘述還過于抽象的話我們不妨看這么一個例子：如果有人建議在你所在的前端專案中引入端到端測驗，你會如何考慮？「正確」要解決的第一重問題是要不要做；第二重問題是我應該如何去做，
在解決第一重問題時，我們需要知道：
- 端到端測驗是什么？
- 專案中有什么問題是必須使用端到端測驗來解決的？
- 端到端測驗是唯一的方案嗎？單元測驗是否也能達到同樣的效果？
- 端到端測驗是否適用于我們的專案？
這四個問題看起來平平無奇，但每一個問題的背后都涵蓋巨大的資訊量，例如最后一個問題當在考量端到端測驗在專案中的可行性時，我們既需要對這項技術的橫向（與其他測驗技術之間的差異）和縱向（目前的技術生態和業內實踐）知識都有所了解，對當前專案的現狀也要掌握得一清二楚，因為維護成本高昂的端到端測驗并不適用于快節奏的交付專案，
如果提出建議的人只是偶然間在某篇文章中讀到了「端到端測驗」這么一個時髦的技術詞匯（buzzword）而拋出來討論，恰巧你又有實踐端到端測驗的經驗，并且不認為當下是一個引入端到端測驗恰當時機，那么你便可以有理有據的反駁他，影響力于是在此彰顯，
從這個影響力落地的例子不難看出達成「專精」并無他法，它等同于你在某個領域內知識積累的厚度，而如何達成這個目標呢？我們其實是在嘗試回答一個純粹又古老的問題：如何讓自己從新手成長為專家？每個人都有自己的答案，
讓聲音被聽見
去他的“酒香不怕巷子深”——如果你現在已經「身懷絕技」，請務必要讓別人看見，沒有對話施加影響力自然也就無從談起，那如何被看見呢？每天的作業按部就班，團隊內的技術趨于穩定，沒有機會給到我，
我的建議是不要被動地等待機會，而是為自己創造機會，
你要相信缺陷是永遠存在的，我們每個人都在編碼程序中經歷過妥協，過去的妥協便是未來的改進之處，作為每天接觸代碼一線人員識別到它們并不難，識別并修復它們是最好的機會，你不妨選擇一些你擅長的領域先把自己投資進去：之所以稱之為「投資」是因為你可能需要動用到作業之外的時間去整理它們、尋找解決方案以及準備材料說服大家，
并非每一次提議都會得到支持，你的預期是應該把拒絕作為常態，這種拒絕大部分時候不是來自對于你建議的否定，而是沒有足夠的資源把你的提議落地，但是沒有關系，在和團隊分享的程序中正確性已經得到了大家的肯定，影響已經發生，反觀整個程序也是你技術成長的痕跡，
如果你寧愿等待機會，那么你需要考慮這樣一個問題，當機會來臨時你可否抓住它？現狀并不是看到機會之后我再去完善我的知識體系，而是我不斷地積累知識體系去靜候每個機會的降臨，
- 測驗覆寫率治不好你的精神內耗
- 昂貴的質量
- 理解流程
- 幫助團隊成長是唯一的出路
- 開源社區的暗面
- 去年做 Tech Leader 犯過最大的錯
- 技術寫作的困境
- 擁抱原則與面對現實
- 代碼與質量的思考與隨筆
- 從對 Vue 中 mixin 的批評，到對模塊間依賴關系的探討
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/523215.html
標籤：其他
上一篇：重塑影響力