获取信任和确立愿景
很少有人會對改變自身行為習慣感到舒適,特別是對于指引改變的人沒有足夠了解和信任的時候,這種感覺尤為強烈。由此便會出現觀望、消極、非暴力不合作、甚至是抵觸反對的態度。說到底“因人廢言”、“對人不對事”還是常有發生的。是否愿意作出改變,有非常大的因素緣自提出改變建議的人。同樣的建議經由不同的人提出,可能會產生完全不同的結果。對于信賴的伙伴,我們通常都會報以更開放和更積極的態度,并愿意嘗試;反之,我們首先產生的想法可能就是質疑和反對。
變革愿景的確立也可以看作是獲得信任的過程——除了對變革者的信任以外,對愿景也存在信任問題。使用新的架構是否真的可以提高知識沉淀的水平?采用新的工具和工程實踐是否真的可以提高交付效率?對于陌生領域的未知,對于愿景適用性的懷疑,都會降低變革的意愿,阻礙在行動上發生改變。
信任源自兩個方面——能力和意圖。人們信任那些有能力實現承諾又可以站在別人的角度思考問題的人;人們相信那些確實能帶來提高又顧及當前實際情況的愿景。通過戲劇性的、引人注意的情景或可視化展示,展現出卓越的能力以及良好的意圖是獲取信任和確立愿景的好辦法。
卓越的能力
如果你希望發生改變的人來自團隊以外,比如其他部門、客戶團隊等等,有的時候展現出卓越的能力就足夠使你獲得信任并引發行為變化了。管理大師Peter Drucker說,績效即領導力,人們總是更愿意相信績效更好的人的意見。這也不難理解,畢竟變革最直接的意愿是希望變得更好, 見賢思齊,從已經是“卓越的”人身上學習是自然的選擇。
前一段時間,我所在團隊跟北美的某個客戶合作。由于是第一次合作,客戶提出采用特性分支的辦法(Feature Branch),把每個需求都做一個分支,然后再由客戶自己的技術人員做代碼審查,最后決定是否要合并到主干中去。這種方法當然是有問題的,各種分支合并的痛苦是顯而易見的。但客戶對團隊的代碼質量和交付速度都沒什么信心,認為這種方式反而是最保險的。于是,我們決定要以卓越的交付能力贏得客戶的信任,然后建議客戶改變這種開發模式。
第一天,我們不僅完成了計劃內的所有需求,還超額完成了一些功能點。第二天,以兩倍于前一天的速度,完成了更多的功能。到第三天,當前計劃周期內的所有功能都已完成,開始后續功能的開發。而且除少量界面調整之外沒有返工。
當我們再次跟客戶提及關于特征分支的不足時,客戶主動安排了負責代碼審查的人聽取我們的建議。要知道我們與客戶的時差有十三小時,也就是他要在晚上9點多的時候跟從未見過面的中國團隊做溝通并認真聽取這個團隊的建議。而這一切不過是三天之內發生的改變。
通過展現某項技術或實踐卓越的能力,使人相信它是變革的方向,的確是一種確立變革愿景的方法,但它所適用的范圍并沒有想象中那么廣泛。如果你打算這么做,那么你至少應該展現出幾倍的差異。之前提到過,Andrew McAfee教授指出新舊技術相差十倍的時候,我們才會有明顯的改變意愿。讓人相信這是可能的方向,也需要那幾倍的差距才行。倘若達不到這個量級,你就該從其他角度入手,而不要死盯著“卓越能力”不放。
這里我可以給你一個直觀的感受:如果要做Web應用的話,用Ruby On Rails替換Java,研發效率是幾倍的提升;而改用Scala Lift就沒有那么多的改變。所以對Ruby On Rails可以集中體現它在研發效率上的卓越能力,而Scala Lift你就要另想辦法了。
持續達成承諾
如果無法突顯卓越的能力,持續達成承諾也是建立信任確立愿景的一種方法。而且持續達成承諾本身還是一種引人注意的情景,會給人留下非常深刻的印象。但要做到持續達成承諾, 首要并不是承諾達成,而是能夠建立持續承諾和持續展示的機制。
若你希望發生改變的人來自團隊以外,一個自然的選擇是利用計劃會(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和異步模型的好處,但是這里的問題是,這些好處與所做的項目是否是相關的?如果是相關的,如何讓非技術背景的利益相關方也能理解這種相關性?
展示相關性和適用性最好的方法是站在外在收益的角度進行思考,比如:
- 是否能夠完成之前做不到的功能?有什么樣的方法可以展示?
- 是否有助于縮短交付時間?有什么樣的方法可以展示?
- 是否有助于降低維護成本?有什么樣的方法可以展示?
- 是否有利于知識的傳遞和管理?有什么樣的方法可以展示?
- 是否降低了溝通成本?有什么樣的方法可以展示?
所謂外在收益是指不僅是工程師可以獲得、站在非工程師的角度也能理解的收益。從這些角度去思考就是在思考他人是否能夠獲得收益,從這些角度去展示就是在展示他人如何能獲得這些收益。如果你沒有辦法找到合理的外在收益,那么就要重新審視一下,變革的愿景是否是合理的了。
如果你已經獲得了必要的信任并明確了變革的愿景,也就是說大家都已經認可了變革的重要性,那么符合變革愿景的行為改變是否就會如期發生了呢?很可惜,并不是這樣的。
文/ThoughtWorks徐昊(八叉)
更多精彩洞見,請關注微信公眾號:ThoughtWorks洞見
轉載于:https://juejin.im/post/5ca17775e51d453f36125f12
總結
- 上一篇: win7 注册表编辑已被管理员禁用 解决
- 下一篇: 分享一个在线代码测试