获取信任和确立愿景

不多有人会对改变自身行为习惯感到温馨，特别是对于指引改变的人没有足够了解和信任的时候，这种感受尤其强烈。由此便会出现观望、消极、非暴力不合做、甚至是抵触反对的态度。说到底“因人废言”、“对人不对事”仍是常有发生的。是否愿意做出改变，有很是大的因素缘自提出改变建议的人。一样的建议经由不一样的人提出，可能会产生彻底不一样的结果。对于信赖的伙伴，咱们一般都会报以更开放和更积极的态度，并愿意尝试；反之，咱们首先产生的想法可能就是质疑和反对。

变革愿景的确立也能够看做是得到信任的过程——除了对变革者的信任之外，对愿景也存在信任问题。使用新的架构是否真的能够提升知识沉淀的水平？采用新的工具和工程实践是否真的能够提升交付效率？对于陌生领域的未知，对于愿景适用性的怀疑，都会下降变革的意愿，阻碍在行动上发生改变。

信任源自两个方面——能力和意图。人们信任那些有能力实现承诺又能够站在别人的角度思考问题的人；人们相信那些确实能带来提升又顾及当前实际状况的愿景。经过戏剧性的、引人注意的情景或可视化展现，展示出卓越的能力以及良好的意图是获取信任和确立愿景的好办法。

卓越的能力

若是你但愿发生改变的人来自团队之外，好比其余部门、客户团队等等，有的时候展示出卓越的能力就足够使你得到信任并引起行为变化了。管理大师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洞见