很少有人會對改變自身行為習(xí)慣感到舒適，特別是對于指引改變的人沒有足夠了解和信任的時候，這種感覺尤為強烈。由此便會出現(xiàn)觀望、消極、非暴力不合作、甚至是抵觸反對的態(tài)度。說到底“因人廢言”、“對人不對事”還是常有發(fā)生的。是否愿意作出改變，有非常大的因素緣自提出改變建議的人。同樣的建議經(jīng)由不同的人提出，可能會產(chǎn)生完全不同的結(jié)果。對于信賴的伙伴，我們通常都會報以更開放和更積極的態(tài)度，并愿意嘗試；反之，我們首先產(chǎn)生的想法可能就是質(zhì)疑和反對。

變革愿景的確立也可以看作是獲得信任的過程——除了對變革者的信任以外，對愿景也存在信任問題。使用新的架構(gòu)是否真的可以提高知識沉淀的水平？采用新的工具和工程實踐是否真的可以提高交付效率？對于陌生領(lǐng)域的未知，對于愿景適用性的懷疑，都會降低變革的意愿，阻礙在行動上發(fā)生改變。

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

卓越的能力

如果你希望發(fā)生改變的人來自團隊以外，比如其他部門、客戶團隊等等，有的時候展現(xiàn)出卓越的能力就足夠使你獲得信任并引發(fā)行為變化了。管理大師Peter Drucker說，績效即領(lǐng)導(dǎo)力，人們總是更愿意相信績效更好的人的意見。這也不難理解，畢竟變革最直接的意愿是希望變得更好， 見賢思齊，從已經(jīng)是“卓越的”人身上學(xué)習(xí)是自然的選擇。

前一段時間，我所在團隊跟北美的某個客戶合作。由于是第一次合作，客戶提出采用特性分支的辦法（Feature Branch），把每個需求都做一個分支，然后再由客戶自己的技術(shù)人員做代碼審查，最后決定是否要合并到主干中去。這種方法當然是有問題的，各種分支合并的痛苦是顯而易見的。但客戶對團隊的代碼質(zhì)量和交付速度都沒什么信心，認為這種方式反而是最保險的。于是，我們決定要以卓越的交付能力贏得客戶的信任，然后建議客戶改變這種開發(fā)模式。

第一天，我們不僅完成了計劃內(nèi)的所有需求，還超額完成了一些功能點。第二天，以兩倍于前一天的速度，完成了更多的功能。到第三天，當前計劃周期內(nèi)的所有功能都已完成，開始后續(xù)功能的開發(fā)。而且除少量界面調(diào)整之外沒有返工。

當我們再次跟客戶提及關(guān)于特征分支的不足時，客戶主動安排了負責(zé)代碼審查的人聽取我們的建議。要知道我們與客戶的時差有十三小時，也就是他要在晚上9點多的時候跟從未見過面的中國團隊做溝通并認真聽取這個團隊的建議。而這一切不過是三天之內(nèi)發(fā)生的改變。

通過展現(xiàn)某項技術(shù)或?qū)嵺`卓越的能力，使人相信它是變革的方向，的確是一種確立變革愿景的方法，但它所適用的范圍并沒有想象中那么廣泛。如果你打算這么做，那么你至少應(yīng)該展現(xiàn)出幾倍的差異。之前提到過，Andrew McAfee教授指出新舊技術(shù)相差十倍的時候，我們才會有明顯的改變意愿。讓人相信這是可能的方向，也需要那幾倍的差距才行。倘若達不到這個量級，你就該從其他角度入手，而不要死盯著“卓越能力”不放。

這里我可以給你一個直觀的感受：如果要做Web應(yīng)用的話，用Ruby On Rails替換Java，研發(fā)效率是幾倍的提升；而改用Scala Lift就沒有那么多的改變。所以對Ruby On Rails可以集中體現(xiàn)它在研發(fā)效率上的卓越能力，而Scala Lift你就要另想辦法了。

持續(xù)達成承諾

如果無法突顯卓越的能力，持續(xù)達成承諾也是建立信任確立愿景的一種方法。而且持續(xù)達成承諾本身還是一種引人注意的情景，會給人留下非常深刻的印象。但要做到持續(xù)達成承諾， 首要并不是承諾達成，而是能夠建立持續(xù)承諾和持續(xù)展示的機制。

若你希望發(fā)生改變的人來自團隊以外，一個自然的選擇是利用計劃會（planning meeting） 展示會（showcase）等方式，形成固定的承諾和展示機制。如果你希望的是團隊內(nèi)改變， 回顧會（retrospective）是作出承諾的好機會。但是回顧會不利于展示 ，因此你需要尋找持續(xù)展示的機會。

我建議的一個方法是利用團隊中的分享講會（mini session）。分享講會是團隊中用以進行快速知識分享的平臺，一般時長15分鐘以內(nèi)，原則上是每人每2－3周就要在團隊內(nèi)進行一次分享。那么就相當于你在一定的周期內(nèi)有15分鐘可以自由向團隊宣講的時間，用以展示改進是最好不過的了。通常我在團隊中最先確立的實踐是分享講會，除了作為知識共享平臺之外，也是希望可以利用這個機會推進一些改變。分享講會另外一個優(yōu)勢是無需作出明確的承諾，只需要對上一次的遺留問題作出回應(yīng)，就能起到持續(xù)達成承諾的效果。

之前我談到過一個團隊，就是那個用WPF給客戶開發(fā)新一代客戶關(guān)系管理系統(tǒng)的團隊。團隊里最早有個架構(gòu)師，他完全不信任任何數(shù)據(jù)綁定技術(shù)（Data Binding）。認為一旦采用數(shù)據(jù)綁定，很難對UI的更新進行細致的控制，此外測試也會變得更加復(fù)雜和困難。所以在項目早期，我們是完全不依賴任何數(shù)據(jù)綁定技術(shù)的。然而數(shù)據(jù)綁定在WPF中除了展示數(shù)據(jù)以外還有更多的作用，完全拋棄它的結(jié)果是很多UI樣式的控制需要編碼實現(xiàn)。這帶來了其他一些問題。

后來我利用分享講會為團隊介紹WPF中的數(shù)據(jù)綁定技術(shù)，當然前幾次的時候大家的質(zhì)疑比較多，比如怎么寫測試啊，怎么控制UI更新啊之類的。在每次分享會上，我都對上一次的問題進行回答與演示，重構(gòu)項目中已有的代碼，展示兩種技術(shù)的優(yōu)劣。大約在三四次之后，團隊其他成員也開始分享他們利用數(shù)據(jù)綁定技術(shù)重構(gòu)代碼的經(jīng)驗了。

在這個例子里，我不僅獲得了團隊的信任，還確立了變革的愿景。數(shù)據(jù)綁定技術(shù)在持續(xù)展示中獲得了團隊的信任，并希望以此為方向改進現(xiàn)有代碼。對于沒有數(shù)倍優(yōu)勢的技術(shù)和實踐來說，這是一種漸進式確立愿景方法。通過持續(xù)地對質(zhì)疑作出回應(yīng)，很好地展示了改進的相關(guān)性和適用性；持續(xù)的小幅改進最終仍然會累積成令人矚目的深刻印象，從而使大家相信它們是變革方向。

良好的意圖

除了卓越的能力之外，良好的意圖也是構(gòu)成信任的重要因素。然而說到良好的意圖，你可能會覺得莫名其妙，難到為了得到更好的代碼結(jié)構(gòu)、更恰當?shù)墓ぞ?、更有效率的工程實踐不是良好的意圖嗎？難道變得更好本身不就是良好的意圖嗎？

無可否認，無論是更好的代碼結(jié)構(gòu)、更恰當?shù)墓ぞ摺⒏行实墓こ虒嵺`，所有這些都是良好的結(jié)果，但良好結(jié)果并不意味著良好的意圖。能夠產(chǎn)生信任感的良好意圖是指心存對方最大利益，愿意為對方考慮的態(tài)度。

有這么兩個團隊。第一個團隊跟客戶有兩三個小時時差，如果早上9點左右來上班呢，那么就會趕上客戶的午飯時間。然而等客戶吃完飯后，又會碰到這邊團隊的午飯時間。兩下一 除，和客戶有效溝通的時間就很有限了。最終交付日期越來越近了，這個團隊的負責(zé)人很著急這個情況，希望增加重疊工作時間。他認為為了達到最好的結(jié)果，團隊提前達到公司是最好的方式。于是他與客戶方的負責(zé)人溝通了這個問題，得到了客戶的肯定。然后在跟團隊溝通的時候，有些成員因為個人原因，就很抵觸這個方案。試行了一段時間，一兩周后也就不了了之了。

另一個團隊在北京，而客戶在紐約，時差相差十二小時。這個團隊與客戶的有效溝通時間就更加有限了。這個團隊的負責(zé)人也考慮怎么才能夠增加有效溝通時間。 她想到可能的方案有三種：早上6點上班到下午4點下班午休2小時；下午1點上班到晚上9點晚飯1小時；還有就是團隊成員輪值接口人的角色，與客戶單獨約時間溝通。單從溝通效果而言，前兩個方案肯定是最好的，但是無論那種安排都會極大地影響團隊成員的個人生活?？紤]這方面因素，反而是第三個方案最優(yōu)。于是她向團隊建議了第三個方案其余兩個方案備選。最后的結(jié)果是， 這個團隊的成員為了更好的溝通效果，選擇把工作時間改到了下午1點到晚上9點，到項目結(jié)束為止，共堅持了近3個月的時間。

這兩個例子都是希望更好的結(jié)果——與客戶多些重疊工作時間。第二個團隊遇到的局面要比第一個團隊困難得多，但結(jié)果恰恰是第二個團隊成功而第一個團隊失敗了。很重要的差別就在于第二團隊的負責(zé)人展現(xiàn)了良好的意圖——在權(quán)衡方案優(yōu)劣的過程中不僅考慮最好的結(jié)果，同時還注意了團隊成員的最大利益。于是在獲得團隊信任之后，團隊自發(fā)朝向更好的結(jié)果做了改變。此外，這個例子同樣說明，職權(quán)雖然可以發(fā)動改變——第一組還是試驗了一段的——但缺乏良好的意圖，改變是不會持久也不會成功的。

你可能還會有疑問，難道把項目做好讓大家在職業(yè)發(fā)展或經(jīng)濟上得到回報不是考慮大家的最大利益嗎？難道這不是為團隊著想嗎？首先我們不該忽略“感受到尊重”的重要性，很難度量比起職業(yè)發(fā)展和經(jīng)濟回報哪個更重要。其次增加重疊時間最終受益的是客戶、公司還有團隊，而其中必須發(fā)生行為改變的是團隊。僅此一點，沒有額外的表示是不足以展示良好意圖的。

外在收益

對于變革的愿景而言，良好的意圖意味著與現(xiàn)實情況的相關(guān)性和適用性。作為工程師，我們的確有些不好的習(xí)慣，比如會因為新和酷而對某些技術(shù)或?qū)嵺`格外推崇，比如會格外強調(diào)某些工具或?qū)嵺`在技術(shù)上的收益，當我們給出采納這些技術(shù)的建議時，并沒有表現(xiàn)出為他人的最大利益著想的態(tài)度，也很難使人相信這些技術(shù)或?qū)嵺`是未來變革的方向。

我就碰到很多人跟我講，希望在項目上使用Clojure，因為Clojure是函數(shù)式語言；希望在項目上使用MongoDB，因為MongoDB是NoSQL；希望在項目上用Node.js，因為Node.js是異步模型。我當然可以理解函數(shù)式語言、NoSQL和異步模型的好處，但是這里的問題是，這些好處與所做的項目是否是相關(guān)的？如果是相關(guān)的，如何讓非技術(shù)背景的利益相關(guān)方也能理解這種相關(guān)性？

展示相關(guān)性和適用性最好的方法是站在外在收益的角度進行思考，比如：

• 是否能夠完成之前做不到的功能？有什么樣的方法可以展示？
• 是否有助于縮短交付時間？有什么樣的方法可以展示？
• 是否有助于降低維護成本？有什么樣的方法可以展示？
• 是否有利于知識的傳遞和管理？有什么樣的方法可以展示？
• 是否降低了溝通成本？有什么樣的方法可以展示？

所謂外在收益是指不僅是工程師可以獲得、站在非工程師的角度也能理解的收益。從這些角度去思考就是在思考他人是否能夠獲得收益，從這些角度去展示就是在展示他人如何能獲得這些收益。如果你沒有辦法找到合理的外在收益，那么就要重新審視一下，變革的愿景是否是合理的了。

如果你已經(jīng)獲得了必要的信任并明確了變革的愿景，也就是說大家都已經(jīng)認可了變革的重要性，那么符合變革愿景的行為改變是否就會如期發(fā)生了呢？很可惜，并不是這樣的。

---

文/ThoughtWorks徐昊（八叉）

更多精彩洞見，請關(guān)注微信公眾號：ThoughtWorks洞見

轉(zhuǎn)載于:https://juejin.im/post/5ca17775e51d453f36125f12

總結(jié)

以上是生活随笔為你收集整理的获取信任和确立愿景的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。