从“技术执男”到“技术暖男”

技术执男

如果把不懂女性心思的理工男称为理工直男，那么就可以把不懂客户心思，片面执着于理想中的“最佳技术实践”的技术咨询师，称为“技术执男”。

曾经是两者兼备的我，当听到下面这段技术执男初上DevOps转型咨询项目的故事，不禁从中看到自己多年前刚刚工作时的影子。

冲突

小z在tw已经工作快5年了。做过DevOps、全栈开发、Inception和Tech Lead。一个月前，他上了一个DevOps转型咨询项目，和一位咨询团队的管理教练结对，给客户开发团队提供IT治理、敏捷运作和工程实践的辅导。没想到刚上项目的第一个月，就和客户发生了冲突。

小z看到客户刚刚采购了DevOps工具链，于是想到工具平台上的流水线，正好可以把持续交付和效能度量落实到开发过程中。但要搭流水线，需要客户方提供支持。于是他找到所辅导的团队中的一位后端开发人员小a，说：“咱俩一起搭流水线吧。”正在忙手头工作的小a抬起头来，略带迟疑地看着他，然后说：“嗯，好的。”接着又忙自己的事情了。

看到小a无动于衷，小z有点着急。第二天，他又找到小a，说：“你和前端开发小b一起把流水线做了吧。”

前端开发小b是另一位客户前端开发人员。这下小a不干了：“你是什么角色？！你要摆正自己的位置！”

小z想进一步解释，但小a并不想听，只是说：“你先回去吧。”

影响力

当小z把这段故事讲给我时，多年前我为当时的单位推行ISO9001所经历的相似遭遇，立即浮现在眼前。

此时如果我是小z，该怎么办？

幸好我最近学了高琳和Hubert老师的影响力和故事力的课程。从中学到了一句金句：“改变别人是神经病，改变自己是神。”

小z无法直接改变小a，而是需要影响到小a，让小a自己愿意改变。就像《盗梦空间》所讲的故事那样。

一个月前，小z自己就是dev，目标就是自己把代码写好，把软件顺利交付出去。但现在，他的角色转变为教练。他需要影响客户的dev，让别人把代码写好。

另外，工作不到2年的小a，并不是外包人员，而是客户的内部人员。搭流水线并不是他的KPI。给他发号施令，自然轮不上作为外包的小z。

要影响小a，该考虑哪些因素呢？

高琳老师的影响力公式是：影响力= (实力+魅力+沟通力) x 同理心

但如果将其运用在我等理工直男和技术执男身上，我认为如果学会了讲故事，那么就会自带魅力和沟通力。所以此时可以把公式简化为：影响力= (实力+故事力) x 同理心

对于技术执男来说，技术实力自不必说。

但故事力和同理心，就是我们所欠缺的。

先说同理心。我给同理心下的定义，是基于自己和所有利益相关者的目标的交集，来说话办事的心智模式。

在上面的故事中，有几个利益相关者呢？

小z自然是一个，还有小a，另外还有客户DevOps转型项目接口人、客户CIO。他们各自都有什么目标呢？需要深挖一下。

需要注意的是，利益相关者的目标，甚至是自己的目标，都有浅层和深层之分。不要止步于浅层的目标，要多挖深层的目标。挖得越深，效果越好。

该如何有效地挖利益相关者的深层目标呢？其实思路和用科学的方法探索未知世界是一样的——大胆假设，小心求证，调整假设，再次求证，循环往复，接近深层。

具体该如何做对方深层目标的假设呢？做法大家其实都熟悉，就是通过持续的观察、揣摩、旁敲侧击的提问、从对方身边的同事和经理那里探究等等，来做出假设。

做完假设，还需要进行验证。根据反馈，不断调整假设。

说完了同理心，再看看故事力。故事力是什么呢？就是用讲故事的方式来潜移默化地让人接受你的道理。为什么不直接讲道理？因为太枯燥嘛。好莱坞不断推陈出新的大片，讲的都是同样的“英雄之旅”的道理，但为何新片一出，大家还是愿意看呢？因为各不相同的故事很吸引人。不明说道理，但在引入入胜的故事中，间接地体现出要讲的道理，让人易于接受，力道更大。

如何才能让故事吸引人呢？只要有转折就行。无转折，不故事。只要有转折，就能吸引人。用高琳老师的话说，检验一个故事是不是讲得好，只要看听众在听到转折时，会不会接着问：“然后呢？”

技术暖男

技术暖男

让我们看看，上面的技术执男，是如何通过下面同理心和故事力的三步法，转变为能懂客户心思的技术暖男的。

1. 抱着同理心识别各方目标交集

经过深挖，小z发现，自己的目标，是要影响客户来自愿做DevOps工程实践；小a的目标，是在完成后端开发工作时候，不要总是被需求频繁变更所打断；客户DevOps项目转型接口人的目标，是要让DevOps转型看到值得向领导汇报的成效；客户CIO的目标，是提升研发效能和产品质量，但更深层的目标，是应对来自业务部门的挑战——“业务部门一方面只提一句话需求，导致IT加班和他们确认需求，另一方面还抱怨IT响应慢”。

小z把上面4个目标取了个交集，找出了这4方的共同目标：用DevOps工具链，来度量从业务发出“一句话需求”，到该需求最终上线的全过程的各种活动的时长，从而可视化需求频繁变更导致的返工的时长占比，并呈现给业务部门，以便与业务部门协作，提高需求分析的质量，降低返工，从而让IT和业务部门，都能达成减负增效。

2. 准备一个有转折的故事并练习

基于各方目标交集，小z准备了一个要给小a讲的故事，来体现如何达成这个目标交集。

“我以前辅导客户的一个开发团队，和你们有同样的痛点，就是需求总是频繁更改。

本来开发人员的工作就安排的满满的了，但业务方的一句话需求，逼得开发人员只好停下手头工作，不断找业务人员确认需求。但经常找不到业务人员。本来可以花一天写好的需求设计文档，因为断断续续找业务人员需要花一周。这样一来，所耽误的计划内的工作，就只好自己加班解决了。

该如何解决这个问题呢？我正好看到了《团队拓扑》这本书，里面提到了工具平台团队。由此想到可以利用工具平台能够自动记录各个活动的时间的特点，来度量‘一句话需求’所造成的需求分析返工的时长，并让业务部门看到，从而可以促使业务部门和IT部门进行协作，通过DevOps转型所引入的质量内建实践，减少低质量的需求分析返工，缓解对计划内工作的时间挤占，从而缓解加班。

我把这个想法和那个开发团队的负责人讲了一下，那位深受‘一句话需求’之苦的负责人很感兴趣，并促使该团队，率先试点持续交付工具平台，度量各个开发活动的时长。最后通过工具平台发现，在引入了‘需求拆分用户故事’、‘用户故事验收条件’、‘开卡’和‘验卡’这些质量内建活动后，一句话需求已经杜绝，需求确认时长比以前降低了50%。开发人员再也不用频繁加班，以赶上被需求确认所耽误的开发工作了。”

写好了上面的故事，小z自己练习把故事讲了几遍，直到能讲得很熟练。

3. 找个合适的场合把故事自然地讲给对方听

冲突发生后。小z心里也不好受。他在识别完各方目标交集和练习完讲故事后，就在晚上给小a发了一条微信：“对不起 小a 那天我和你沟通流水线搭建的事情 做法比较武断 没有考虑你的感受 多有冒犯 想和你约个时间 请你吃午餐 ”。

第二天一早，小a回复：“没问题 今天中午一起吃饭”。

小z兴奋地把故事稿放到兜里，然后出门，走在上班的路上。