獲取信任和確立願景

時間 2019-11-21

標籤獲取信任確立願景简体版

原文原文鏈接

不多有人會對改變自身行爲習慣感到溫馨，特別是對於指引改變的人沒有足夠了解和信任的時候，這種感受尤其強烈。由此便會出現觀望、消極、非暴力不合做、甚至是抵觸反對的態度。說到底「因人廢言」、「對人不對事」仍是常有發生的。是否願意做出改變，有很是大的因素緣自提出改變建議的人。一樣的建議經由不一樣的人提出，可能會產生徹底不一樣的結果。對於信賴的夥伴，咱們一般都會報以更開放和更積極的態度，並願意嘗試；反之，咱們首先產生的想法可能就是質疑和反對。微信

變革願景的確立也能夠看做是得到信任的過程——除了對變革者的信任之外，對願景也存在信任問題。使用新的架構是否真的能夠提升知識沉澱的水平？採用新的工具和工程實踐是否真的能夠提升交付效率？對於陌生領域的未知，對於願景適用性的懷疑，都會下降變革的意願，阻礙在行動上發生改變。session

信任源自兩個方面——能力和意圖。人們信任那些有能力實現承諾又能夠站在別人的角度思考問題的人；人們相信那些確實能帶來提升又顧及當前實際狀況的願景。經過戲劇性的、引人注意的情景或可視化展現，展示出卓越的能力以及良好的意圖是獲取信任和確立願景的好辦法。架構

卓越的能力

若是你但願發生改變的人來自團隊之外，好比其餘部門、客戶團隊等等，有的時候展示出卓越的能力就足夠使你得到信任並引起行爲變化了。管理大師Peter Drucker說，績效即領導力，人們老是更願意相信績效更好的人的意見。這也不難理解，畢竟變革最直接的意願是但願變得更好，見賢思齊，從已是「卓越的」人身上學習是天然的選擇。異步

前一段時間，我所在團隊跟北美的某個客戶合做。因爲是第一次合做，客戶提出採用特性分支的辦法（Feature Branch），把每一個需求都作一個分支，而後再由客戶本身的技術人員作代碼審查，最後決定是否要合併到主幹中去。這種方法固然是有問題的，各類分支合併的痛苦是顯而易見的。但客戶對團隊的代碼質量和交付速度都沒什麼信心，認爲這種方式反而是最保險的。因而，咱們決定要以卓越的交付能力贏得客戶的信任，而後建議客戶改變這種開發模式。函數

第一天，咱們不只完成了計劃內的全部需求，還超額完成了一些功能點。次日，以兩倍於前一天的速度，完成了更多的功能。到第三天，當前計劃週期內的全部功能都已完成，開始後續功能的開發。並且除少許界面調整以外沒有返工。工具

當咱們再次跟客戶說起關於特徵分支的不足時，客戶主動安排了負責代碼審查的人聽取咱們的建議。要知道咱們與客戶的時差有十三小時，也就是他要在晚上9點多的時候跟從未見過面的中國團隊作溝通並認真聽取這個團隊的建議。而這一切不過是三天以內發生的改變。學習

經過展示某項技術或實踐卓越的能力，令人相信它是變革的方向，的確是一種確立變革願景的方法，但它所適用的範圍並無想象中那麼普遍。若是你打算這麼作，那麼你至少應該展示出幾倍的差別。以前提到過，Andrew McAfee教授指出新舊技術相差十倍的時候，咱們纔會有明顯的改變意願。讓人相信這是可能的方向，也須要那幾倍的差距才行。假若達不到這個量級，你就該從其餘角度入手，而不要死盯着「卓越能力」不放。測試

這裏我能夠給你一個直觀的感覺：若是要作Web應用的話，用Ruby On Rails替換Java，研發效率是幾倍的提高；而改用Scala Lift就沒有那麼多的改變。因此對Ruby On Rails能夠集中體現它在研發效率上的卓越能力，而Scala Lift你就要另想辦法了。編碼

持續達成承諾

若是沒法突顯卓越的能力，持續達成承諾也是創建信任確立願景的一種方法。並且持續達成承諾自己仍是一種引人注意的情景，會給人留下很是深入的印象。但要作到持續達成承諾，首要並非承諾達成，而是可以創建持續承諾和持續展現的機制。3d

若你但願發生改變的人來自團隊之外，一個天然的選擇是利用計劃會（planning meeting）展現會（showcase）等方式，造成固定的承諾和展現機制。若是你但願的是團隊內改變，回顧會（retrospective）是做出承諾的好機會。可是回顧會不利於展現，所以你須要尋找持續展現的機會。

我建議的一個方法是利用團隊中的分享講會（mini session）。分享講會是團隊中用以進行快速知識分享的平臺，通常時長15分鐘之內，原則上是每人每2－3周就要在團隊內進行一次分享。那麼就至關於你在必定的週期內有15分鐘能夠自由向團隊宣講的時間，用以展現改進是最好不過的了。一般我在團隊中最早確立的實踐是分享講會，除了做爲知識共享平臺以外，也是但願能夠利用這個機會推動一些改變。分享講會另一個優點是無需做出明確的承諾，只須要對上一次的遺留問題做出迴應，就能起到持續達成承諾的效果。

以前我談到過一個團隊，就是那個用WPF給客戶開發新一代客戶關係管理系統的團隊。團隊裏最先有個架構師，他徹底不信任任何數據綁定技術（Data Binding）。認爲一旦採用數據綁定，很難對UI的更新進行細緻的控制，此外測試也會變得更加複雜和困難。因此在項目早期，咱們是徹底不依賴任何數據綁定技術的。然而數據綁定在WPF中除了展現數據之外還有更多的做用，徹底拋棄它的結果是不少UI樣式的控制須要編碼實現。這帶來了其餘一些問題。

後來我利用分享講會爲團隊介紹WPF中的數據綁定技術，固然前幾回的時候你們的質疑比較多，好比怎麼寫測試啊，怎麼控制UI更新啊之類的。在每次分享會上，我都對上一次的問題進行回答與演示，重構項目中已有的代碼，展現兩種技術的優劣。大約在三四次以後，團隊其餘成員也開始分享他們利用數據綁定技術重構代碼的經驗了。

在這個例子裏，我不只得到了團隊的信任，還確立了變革的願景。數據綁定技術在持續展現中得到了團隊的信任，並但願以此爲方向改進現有代碼。對於沒有數倍優點的技術和實踐來講，這是一種漸進式確立願景方法。經過持續地對質疑做出迴應，很好地展現了改進的相關性和適用性；持續的小幅改進最終仍然會累積成使人矚目的深入印象，從而使你們相信它們是變革方向。

良好的意圖

除了卓越的能力以外，良好的意圖也是構成信任的重要因素。然而說到良好的意圖，你可能會以爲莫名其妙，難到爲了獲得更好的代碼結構、更恰當的工具、更有效率的工程實踐不是良好的意圖嗎？難道變得更好自己不就是良好的意圖嗎？

無能否認，不管是更好的代碼結構、更恰當的工具、更有效率的工程實踐，全部這些都是良好的結果，但良好結果並不意味着良好的意圖。可以產生信任感的良好意圖是指心存對方最大利益，願意爲對方考慮的態度。

有這麼兩個團隊。第一個團隊跟客戶有兩三個小時時差，若是早上9點左右來上班呢，那麼就會遇上客戶的午餐時間。然而等客戶吃完飯後，又會碰到這邊團隊的午餐時間。兩下一除，和客戶有效溝通的時間就頗有限了。最終交付日期愈來愈近了，這個團隊的負責人很着急這個狀況，但願增長重疊工做時間。他認爲爲了達到最好的結果，團隊提早達到公司是最好的方式。因而他與客戶方的負責人溝通了這個問題，獲得了客戶的確定。而後在跟團隊溝通的時候，有些成員由於我的緣由，就很抵觸這個方案。試行了一段時間，一兩週後也就不了了之了。

另外一個團隊在北京，而客戶在紐約，時差相差十二小時。這個團隊與客戶的有效溝通時間就更加有限了。這個團隊的負責人也考慮怎麼纔可以增長有效溝通時間。她想到可能的方案有三種：早上6點上班到下午4點下班午休2小時；下午1點上班到晚上9點晚飯1小時；還有就是團隊成員輪值接口人的角色，與客戶單獨約時間溝通。單從溝通效果而言，前兩個方案確定是最好的，可是不管那種安排都會極大地影響團隊成員的我的生活。考慮這方面因素，反而是第三個方案最優。因而她向團隊建議了第三個方案其他兩個方案備選。最後的結果是，這個團隊的成員爲了更好的溝通效果，選擇把工做時間改到了下午1點到晚上9點，到項目結束爲止，共堅持了近3個月的時間。

這兩個例子都是但願更好的結果——與客戶多些重疊工做時間。第二個團隊遇到的局面要比第一個團隊困可貴多，但結果偏偏是第二個團隊成功而第一個團隊失敗了。很重要的差異就在於第二團隊的負責人展示了良好的意圖——在權衡方案優劣的過程當中不只考慮最好的結果，同時還注意了團隊成員的最大利益。因而在得到團隊信任以後，團隊自發朝向更好的結果作了改變。此外，這個例子一樣說明，職權雖然能夠發動改變——第一組仍是試驗了一段的——但缺少良好的意圖，改變是不會持久也不會成功的。

你可能還會有疑問，難道把項目作好讓你們在職業發展或經濟上獲得回報不是考慮你們的最大利益嗎？難道這不是爲團隊着想嗎？首先咱們不應忽略「感覺到尊重」的重要性，很難度量比起職業發展和經濟回報哪一個更重要。其次增長重疊時間最終受益的是客戶、公司還有團隊，而其中必須發生行爲改變的是團隊。僅此一點，沒有額外的表示是不足以展現良好意圖的。

外在收益

對於變革的願景而言，良好的意圖意味着與現實狀況的相關性和適用性。做爲工程師，咱們的確有些很差的習慣，好比會由於新和酷而對某些技術或實踐格外推崇，好比會格外強調某些工具或實踐在技術上的收益，當咱們給出採納這些技術的建議時，並無表現出爲他人的最大利益着想的態度，也很難令人相信這些技術或實踐是將來變革的方向。

我就碰到不少人跟我講，但願在項目上使用Clojure，由於Clojure是函數式語言；但願在項目上使用MongoDB，由於MongoDB是NoSQL；但願在項目上用Node.js，由於Node.js是異步模型。我固然能夠理解函數式語言、NoSQL和異步模型的好處，可是這裏的問題是，這些好處與所作的項目是不是相關的？若是是相關的，如何讓非技術背景的利益相關方也能理解這種相關性？

展現相關性和適用性最好的方法是站在外在收益的角度進行思考，好比：