技术项目的沟通艺术:讲故事

日期: 2017-07-04 作者:Niel Nickolaisen翻译:陈晓诚 来源:TechTarget中国 英文

在过去三年中,我们已经更新了公司内的几乎所有和技术相关的方面。我们已经将大量服务迁移到云,更换了我们的电话和网络系统,并实施了CRM和联络中心软件的软件即服务版本。 我们将所有生产系统的机械硬盘替换为固态硬盘。我们实施了超融合基础设施,实现了SOC认证,并通过采用微服务架构,使我们面向客户的遗留应用更现代化。

我们在敏捷和DevOps 上也取得进展——我们已经为DevOps中应用级安全性的发明,申请了三项专利——我们已经利用这些专业知识和这些最新的技术开发了一系列的新应用和服务。 所有这一切都需要时间、金钱和人员。那么问题是,我是如何说服企业的其他成员来批准我们在这些领域所需要的投资?这不是反问……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

在过去三年中,我们已经更新了公司内的几乎所有和技术相关的方面。我们已经将大量服务迁移到云,更换了我们的电话和网络系统,并实施了CRM和联络中心软件的软件即服务版本。

我们将所有生产系统的机械硬盘替换为固态硬盘。我们实施了超融合基础设施,实现了SOC认证,并通过采用微服务架构,使我们面向客户的遗留应用更现代化。我们在敏捷和DevOps 上也取得进展——我们已经为DevOps中应用级安全性的发明,申请了三项专利——我们已经利用这些专业知识和这些最新的技术开发了一系列的新应用和服务。

所有这一切都需要时间、金钱和人员。那么问题是,我是如何说服企业的其他成员来批准我们在这些领域所需要的投资?这不是反问句。

虽然我们对面向客户的应用进行了更新和重构,但是我们在三年内放慢了产品和服务创新速度。我们在市场上付出了代价,为了更现代化的更新产品平台,为了更加灵活的未来,我们做出了牺牲。

三年前,我强烈地认为这是一个有价值的投资,但企业的其他人员也会这样认为吗——特别是我的同事和老板?

沟通艺术:“为什么”的重要性

我并不是伶牙俐齿的人。如果我成为一个销售,我肯定会饿死。我不会表达。我不是一个优秀的沟通者。然而,我的职位,让我必须定期做出令人信服的业务案例。鉴于我缺乏销售技能,我必须想办法说服他人去做我认为应该做的事情。我被迫去思考技术项目的沟通艺术。

最初几次,我试图为一个项目做案例,我花了几天收集数据和技术事实。我详细介绍服务器容量,生产量指标和周期时间的降低。我练习我的演讲。我设想每个提问。一切都按照我计划的进行。当我完成演讲后,我觉得我能立即获得批准。

但是,我收到的唯一提问是,“我们为什么要这样做?”

同样的情况发生了好几次,然后我意识到听众很容易在数据和技术事实之中迷失。既迷失又迷茫。

在我努力寻求如何让我的案例获得批准时,我读了一本名为“Made to Stick: Why Some Ideas Survive and Others Die”的书。从Made to Stick中,我学到的最重要的教训是人们关注并会记住故事。

我改变了我的方法,并努力掌握讲故事的艺术。当我为我们的遗留ERP进行零定制重做案例时,我讲述了我们创建新条目需要多长时间,添加新税务地区需要多少人员,以及要获得例如产品盈利能力这样简单的问题的答案,有多么困难。

我的听众与这些故事产生共鸣,因为他们是条目创建,财务和盈利能力报告流程的所有人。当他们听了这些故事,我只需要将我的项目与这些流程中的痛点的解决方案相关联。

我没有谈到服务器容量,生产量指标或周期时间的降低。为什么没有?因为这些技术指标,虽然对我的下属有意义,对我的业务同行和老板则没有意义。

要成为一个讲故事的人,我也发现,故事中最重要的元素是“为什么”。事实上,我现在相信这个故事的“为什么”比“什么”要重要得多。而我几乎从来不需要讲到“如何”——“如何”是一个实施细节,不应该是业务案例中的一部分。

沟通艺术:如何收集故事

故事从何而来?

在我处理业务时,我收集那些会在某一时刻构建业务案例的微小故事。例如,对于我们的ERP的零定制重做,我必须克服一个基本的信念,即我们的流程是如此独特,标准的ERP功能不仅对我们无效,而且实际上使我们面临风险。

我如何克服呢?通过收集几个月的例子,证明我们高度定制的ERP,比更换后,更有风险。例如,在一次会议中,我们的内控官要求我们将一个新项目列入我们的名单:他需要我们在供应商名单中添加一个新的供应商。

问题是,这个供应商位于印度一个尚未纳入我们税务结构的地区。在印度,每个地区的税务都不同,所以需要两个会计师和四个IT人员,花费六个星期的时间,将这个印度地区纳入我们的税务结构。如果我们使用的是标准账目图表和税务结构(而不是我们古怪的,高度定制的版本),那么这个工作只需要一个员工不到一天的时间就能完成。我将这些信息添加到我的“重做ERP”理由中,还有其他类似案例。当我们需要解释为什么要重做ERP时,我有几十个故事来做为理由。

收集故事需要耐心。有了一些技术方案,需要几个月的时间收集足够的证据来证明我的案例,当我站在听众面前时,我希望能够得到肯定的答案,他们不但批准项目,还会拥护项目。更好的是,由于他们可以与故事产生共鸣,并记住故事,我的听众还可以向企业的其他成员解释项目的原因。

通过讲故事来建立一个业务案例对我非常实用,我不再需要解释单调的细节,比如投资回报率,服务器速度和生产量。