获取信任和确立愿景

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

image

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

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

卓越的能力

如果你希望发生改变的人来自团队以外，比如其他部门、客户团队等等，有的时候展现出卓越的能力就足够使你获得信任并引发行为变化了。管理大师Peter Drucker说，绩效即领导力，人们总是更愿意相信绩效更好的人的意见。这也不难理解，毕竟变革最直接的意愿是希望变得更好， 见贤思齐，从已经是“卓越的”人身上学习是自然的选择。

前一段时间，我所在团队跟北美的某个客户合作。由于是第一次合作，客户提出采用特性分支的办法（Feature Branch），把每个需求都做一个分支，然后再由客户自己的技术人员做代码审查，最后决定是否要合并到主干中去。这种方法当然是有问题的，各种分支合并的痛苦是显而易见的。但客户对团队的代码质量和交付速度都没什么信心，认为这种方式反而是最保险的。于是，我们决定要以卓越的交付能力赢得客户的信任，然后建议客户改变这种开发模式。

第一天，我们不仅完成了计划内的所有需求，还超额完成了一些功能点。第二天，以两倍于前一天的速度，完成了更多的功能。到第三天，当前计划周期内的所有功能都已完成，开始后续功能的开发。而且除少量界面调整之外没有返工。

当我们再次跟客户提及关于特征分支的不足时，客户主动安排了负责代码审查的人听取我们的建议。要知道我们与客户的时差有十三小时，也就是他要在晚上9点多的时候跟从未见过面的中国团队做沟通并认真听取这个团队的建议。而这一切不过是三天之内发生的改变。

image

通过展现某项技术或实践卓越的能力，使人相信它是变革的方向，的确是一种确立变革愿景的方法，但它所适用的范围并没有想象中那么广泛。如果你打算这么做，那么你至少应该展现出几倍的差异。之前提到过，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更新啊之类的。在每次分享会上，我都对上一次的问题进行回答与演示，重构项目中已有的代码，展示两种技术的优劣。大约在三四次之后，团队其他成员也开始分享他们利用数据绑定技术重构代码的经验了。

在这个例子里，我不仅获得了团队的信任，还确立了变革的愿景。数据绑定技术在持续展示中获得了团队的信任，并希望以此为方向改进现有代码。对于没有数倍优势的技术和实践来说，这是一种渐进式确立愿景方法。通过持续地对质疑作出回应，很好地展示了改进的相关性和适用性；持续的小幅改进最终仍然会累积成令人瞩目的深刻印象，从而使大家相信它们是变革方向。

image

良好的意图

除了卓越的能力之外，良好的意图也是构成信任的重要因素。然而说到良好的意图，你可能会觉得莫名其妙，难到为了得到更好的代码结构、更恰当的工具、更有效率的工程实践不是良好的意图吗？难道变得更好本身不就是良好的意图吗？

无可否认，无论是更好的代码结构、更恰当的工具、更有效率的工程实践，所有这些都是良好的结果，但良好结果并不意味着良好的意图。能够产生信任感的良好意图是指心存对方最大利益，愿意为对方考虑的态度。

有这么两个团队。第一个团队跟客户有两三个小时时差，如果早上9点左右来上班呢，那么就会赶上客户的午饭时间。然而等客户吃完饭后，又会碰到这边团队的午饭时间。两下一 除，和客户有效沟通的时间就很有限了。最终交付日期越来越近了，这个团队的负责人很着急这个情况，希望增加重叠工作时间。他认为为了达到最好的结果，团队提前达到公司是最好的方式。于是他与客户方的负责人沟通了这个问题，得到了客户的肯定。然后在跟团队沟通的时候，有些成员因为个人原因，就很抵触这个方案。试行了一段时间，一两周后也就不了了之了。

另一个团队在北京，而客户在纽约，时差相差十二小时。这个团队与客户的有效沟通时间就更加有限了。这个团队的负责人也考虑怎么才能够增加有效沟通时间。 她想到可能的方案有三种：早上6点上班到下午4点下班午休2小时；下午1点上班到晚上9点晚饭1小时；还有就是团队成员轮值接口人的角色，与客户单独约时间沟通。单从沟通效果而言，前两个方案肯定是最好的，但是无论那种安排都会极大地影响团队成员的个人生活。考虑这方面因素，反而是第三个方案最优。于是她向团队建议了第三个方案其余两个方案备选。最后的结果是， 这个团队的成员为了更好的沟通效果，选择把工作时间改到了下午1点到晚上9点，到项目结束为止，共坚持了近3个月的时间。

这两个例子都是希望更好的结果——与客户多些重叠工作时间。第二个团队遇到的局面要比第一个团队困难得多，但结果恰恰是第二个团队成功而第一个团队失败了。很重要的差别就在于第二团队的负责人展现了良好的意图——在权衡方案优劣的过程中不仅考虑最好的结果，同时还注意了团队成员的最大利益。于是在获得团队信任之后，团队自发朝向更好的结果做了改变。此外，这个例子同样说明，职权虽然可以发动改变——第一组还是试验了一段的——但缺乏良好的意图，改变是不会持久也不会成功的。

[图片上传失败...(image-9b03dd-1554085138976)]

你可能还会有疑问，难道把项目做好让大家在职业发展或经济上得到回报不是考虑大家的最大利益吗？难道这不是为团队着想吗？首先我们不该忽略“感受到尊重”的重要性，很难度量比起职业发展和经济回报哪个更重要。其次增加重叠时间最终受益的是客户、公司还有团队，而其中必须发生行为改变的是团队。仅此一点，没有额外的表示是不足以展示良好意图的。

外在收益

对于变革的愿景而言，良好的意图意味着与现实情况的相关性和适用性。作为工程师，我们的确有些不好的习惯，比如会因为新和酷而对某些技术或实践格外推崇，比如会格外强调某些工具或实践在技术上的收益，当我们给出采纳这些技术的建议时，并没有表现出为他人的最大利益着想的态度，也很难使人相信这些技术或实践是未来变革的方向。

我就碰到很多人跟我讲，希望在项目上使用Clojure，因为Clojure是函数式语言；希望在项目上使用MongoDB，因为MongoDB是NoSQL；希望在项目上用Node.js，因为Node.js是异步模型。我当然可以理解函数式语言、NoSQL和异步模型的好处，但是这里的问题是，这些好处与所做的项目是否是相关的？如果是相关的，如何让非技术背景的利益相关方也能理解这种相关性？

展示相关性和适用性最好的方法是站在外在收益的角度进行思考，比如：

• 是否能够完成之前做不到的功能？有什么样的方法可以展示？
• 是否有助于缩短交付时间？有什么样的方法可以展示？
• 是否有助于降低维护成本？有什么样的方法可以展示？
• 是否有利于知识的传递和管理？有什么样的方法可以展示？
• 是否降低了沟通成本？有什么样的方法可以展示？

所谓外在收益是指不仅是工程师可以获得、站在非工程师的角度也能理解的收益。从这些角度去思考就是在思考他人是否能够获得收益，从这些角度去展示就是在展示他人如何能获得这些收益。如果你没有办法找到合理的外在收益，那么就要重新审视一下，变革的愿景是否是合理的了。

如果你已经获得了必要的信任并明确了变革的愿景，也就是说大家都已经认可了变革的重要性，那么符合变革愿景的行为改变是否就会如期发生了呢？很可惜，并不是这样的。

---

文/ThoughtWorks徐昊（八叉）

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见