文章： 与项目干系人沟通业务价值

我先告诉你一个秘密：我根本不关注你在“DD”前放哪个字母，我也不太关心代码是怎么写的、软件开发时的输入输出是什么。倒不是因为我不知道它有多重要——而是因为，我更关注的是它的交付价值。你做的东西，怎么节省我的时间、钱和/或避免项目失败？我明白，团队里如果没有你这个天才成员——我的生活将会变得一团糟，工作将不再正常运转。我了解并且也很珍惜你的开发工作为我创造的价值。

那么当IT团队想要真正理解项目干系人的需求、提升认可度、在组织中获得更高知名度、获得更多资金，或吸引更多强人加入项目时，为什么他们有时会觉得受到了挑战？因为他们只有很少的时间跟项目干系人交流所要交付产品的价值——或是想方设法让项目干系人清楚地表达出他们通过软件真正想实现的利益是什么。

在组织中，需要通过大家都能理解的语言，与项目干系人沟通你将为他们做哪些事情。你要帮助他们找到合适的沟通语言。但是，怎么才能做到这点呢？

项目干系人能得到什么好处？

首先，我们来明确什么是“项目干系人”。我喜欢Scott Ambler的定义：“任何直接用户、间接用户、用户经理、高级经理、运营人员、项目出资人、客户支持（服务台）人员、审计人员、程序或投资组合经理、与项目有集成或交互的其他项目开发人员、受软件开发或发布潜在影响的维护人员等”。 ¹

为什么你的项目干系人并不总能理解你所交付产品的价值呢？因为项目负责人——甚至敏捷项目负责人——谈论项目或过程时，经常谈的都是功能特征。这不是他们的错，项目干系人也常这样做。“我们需要更快的流程、更好的用户界面、更高效、有系统支持的工作流。”是的，但是这些对项目干系人又意味着什么呢？这些对他们有什么好处？作为一个整体，它对你的组织整体又有什么意义呢？

你要使用利益相关的语言，与项目干系人沟通项目有什么价值，而不是谈功能特征。功能特征是你的系统或流程要做的事情，利益才是人们所关注的东西。

特征和利益这两个词最直接的定义是（来自市场行业）：

• 特征：特殊的或重要的属性
• 利益：对项目干系人有意义的好处

Frederieke Ubels是荷兰bol.comScrum的Scrum过程教练，她对我说过，她认为利益比特征更通用：“每个人都想感到幸福和安全、赚钱、使客户满意等。功能特征可以促进利益达成，但是对它的使用没那么普遍，可用场合没那么多，”她说。“功能特征可用也可不用，这取决于你评估它们的价值是否重要。”

推销利益；用功能特征作支撑

从一开始，市场人员就已告诉了我们项目会提供哪些利益。我并不是真想要一个轮子，我想要的是更容易滚动的东西——更好点儿，它能让交通更方便，节省我的时间和体力。我不想要一辆新车，我想要的是能让我快速从A处去到B处的东西，它能让我节省时间、安全，并且看上去很酷，还会让我在驾驶它时感觉良好。

项目也一样。我不想去数据库里找某种方法。我想在需要时，就能得到想要的信息，能让我省时省力。我不想分析客户需求，我想让客户满意，这样他们就会还来我们这儿买东西，我的公司就能赚更多钱。

节省时间、感觉安全、少费力气、赚更多钱，这才是真正的利益所在。这些才是创造了业务价值的事情。对我们来说，知道如何向项目干系人“推销”（或者，我更应该说成是“沟通”）非常重要。

人们会对能与情感相关联起来的事物产生需求。神经营销学表明了它们起作用的方式。基本上，某种东西让我们对它产生了有形的联系——尤其是与情感联系起来，或可以看到、摸到、听到、闻到或尝到，它就会在大脑中留下深刻的记忆。大脑中的这个部位也负责做决定。所以，如果你能找到某种方式，与项目干系人建立起情感层次上的联系，那么当你寻求资源和支持时，他们就更容易理解你，站在你这边，帮你达成使你增值的目标。

但是只沟通利益还不够。你还需要向人们大脑中的“逻辑”部分谈谈他们想了解的现状、数据、对事物的研究。这会儿就该说你的功能特征了。功能特征是让你的软件具备实现所讲利益（交付给项目干系人的业务价值）的能力。

开始时先谈一下你将交付的价值，谈论时可以用功能特征来辅助支撑你的信息。随着你做得越来越好，你可以从市场专家那里偷偷学一下他们在告诉项目干系人产品如何满足需求时所讲的那些故事。 一个故事就可以清楚地表明：你完全理解他们心里真正想要的是什么。

例如：故事可能像下面这样（稍微有些夸张）：

“过些日子，有些迭代完成了......我们的CRM客户打开电脑，立即就能搜索并找到他们需要的任何形式的客户信息：可能是航运地址、他们的第一笔订单、最常用的采购条目列表。订单信息还可以交叉参考，可以查看同一公司、外部公司的客户订单情况，还能看到订单变化趋势。他们将变得更加精明，更依赖我们的CRM系统，他们的客户也将更满意。当我们的CRM客户将更富有、更满意时，当然，作为回报，我们也会更富有。而且，从此以后，我们都将过着幸福的生活。”

提问，直到你理解了产品的业务价值是什么

当你不知道软件能提供什么业务价值时怎么办？或者更糟糕一点，连你的项目干系人也不知道想从软件中得到什么好处时怎么办？这时你就需要问大量的问题来寻找答案。如果你更喜欢“5 Whys（5个为什么分析法）” ²，那就用它吧。如果你想了解怎么用更从容的谈话风格来提问，试试下面的方法：

“那又怎么样呢？”能帮助理解业务价值是什么的问题

（假设项目干系人知道他们想要的业务价值是什么）

• 我的项目干系人能从中得到什么好处？
• （项目干系人想要这项功能特征的）目的是什么？
• 你（项目干系人）想用这个软件做什么？
• 这个（功能特征）能带来什么好处？

能帮助项目干系人发现/理解真正的利益（业务价值）是什么的问题
（假设项目干系人讲不清楚他们想要的利益是什么）

• 为什么我（项目干系人）想要或者需要这个（功能特征）？
• 有了它，我（项目干系人）能够做些什么？
• 为什么这个（功能特征）比其它的更好？
• （作为项目干系人）为什么关注这个功能特征？

要了解真正的利益（业务价值）是什么，开头先问 为什么要有这里的每一项功能。记住这个答案，接下来再问它 如何与项目干系人的需求联系起来？这将帮你从感性的层次上理解 项目干系人能得到什么好处。

有时，可能你有多个项目干系人——而且他们可能对真正的业务价值是什么的看法并不一致，比如，一位客户服务经理可能说“让做重复业务的客户满意”是他想要的利益。而他的主管可能会说，赚钱（而不是满意的客户）是他想要的利益。这时，你可以去印证是否让客户满意的目标也是赚钱。一直提问，直到你弄明白了真正的利益是什么。如果需要，你可以创建“利益层级”，用特定的功能特征支撑特定的利益。

以用户故事的形式开头

我不是来自IT行业，对软件开发真的是什么也不懂。但是在市场和领导岗位工作了20多年，如果换种沟通方式，用利益相关的语言来沟通的话，我肯定能知道软件的价值是什么。“先讲业务价值”我经常这样建议我的客户。“你需要让客户关注你正在为他们做什么！”

像Chris Matts ³和Andy Pols ³、Dan North ⁴、Liz Keogh ⁵等聪明人会去谈行为驱动开发（Behavior-Driven Development）和项目干系人故事（不是用户故事User Stories），通过它们来理解项目干系人寻求的业务价值。用普通用户故事的形式来开头是个好方法。团队会努力去获知真正的业务价值是什么。

作用一名（角色，人物），
我想要（目标，功能特征能做什么，它为什么有用），
以便于（利益/商业价值）

然而，从单纯沟通的角度看，当人们看到这种普通的用户故事的形式，马上就会建议把它颠倒过来，这并不奇怪（我现在了解到它是Chris Matts在2008年建议的）。下面是我的版本：

我们将（获得利益/业务价值）
为（角色，人物）所用，
因为我们有（功能特征能做什么，它为什么有用）。

或者从普通的用户故事的形式，简单跳过“我想要”这部分，直接聚焦到最终用户和业务价值上来。这样团队受到的约束最少，因为什么功能特征都没提到。

下面是个简化版的苹果公司Siri开发人员在工作中的例子：

作为一名最终用户，
我想不需要在手机上输入就实现修改日历和完成搜索，因为这样能节省时间而且免得麻烦（如果我正开车，这样做也会更安全）。

用上面提到的方式来沟通，首先讲能提供的利益是什么：

我们将节省时间，避免麻烦，提升安全性，
为我们最终用户所用，
因为我们有一个“智能个人助理”，它能通过自然语言的用户界面来修改日历、完成搜索。

我并不是说，在软件开发时，使用“利益优先”的方式一定最“正确”。我想说的是：使用利益相关的语言交流，是 获知和 沟通业务价值非常有效的方式。

使业务价值信息更具黏性

有的团队，他们的项目干系人不理解项目的业务价值。通过与这样的团队一起工作时，我发现这种情况通常是因为团队不懂怎么用业务价值相关的语言，跟他们的项目干系人沟通所交付产品的价值。要改善这些情况，首先要理解项目的业务价值是什么，然后，开始使用与业务价值相关的信息与项目干系人沟通。这是首先要做的几步。但是，你怎样做才能让项目干系人牢记你所有的业务价值，以便让他们在组织内外沟通项目的业务价值时，也能讲出你所说的那些业务价值呢？你可以通过增强信息粘性使他们更容易记住。

做过新闻记者后，再去做执行沟通教练，让我明白使用简单、易理解的语言，将意思和情感传达到行动是多么有效。在Chip Heath和Dan Heath合著的 Made to Stick ⁶书中，他们简洁地描述出了我这么多年所教的东西。下面是他们给出的使信息更容易被记住的“黏性六要素”：

1. 简单——要记住的最重要的事情是什么？
2. 出乎意料——如何才能抓住项目干系人的注意力？
3. 具体——与业务价值相关的情境是什么？
4. 可信——为什么项目干系人应该相信这些？
5. 关注——项目干系人能得到什么好处？
6. 行动——我现在该做些什么？

把这些元素融入到你要沟通的业务价值信息中，这样做的目的是使项目干系人能留下深刻的印象。即使是最好的信息，也不一定全部包含这些元素，不过它们通常会包含三四种。

我曾经和一个IT团队合作。团队的职责是为一家大型医院开发一套病人跟踪系统。他们没有从项目干系人那里得到所需要的支持，而且他们也没有与项目干系人沟通他们的项目交付物的价值。当他们理解了项目干系人想实现的利益后，他们把所交付产品的业务价值用下面的方式总结出来：

我们的系统可以挽救生命。全国任何地方的医生和护士都可以快速访问到病人记录。通过简单注册，他们就可以立即就能查看到病人的情况和服用过的药物。他们在给病人最好的医疗照顾时会感到更安全。

上面的信息包含如下元素：

简单、具体、出乎意料 （“我们的系统可以挽救生命”）、
关注 （“他们在给病人最好的医疗照顾时会感到更安全。”）、
行动 （“通过简单注册”）

上面信息的优点是：它足够强大和简单，可以让团队和项目干系人记住并能明确说出它的业务价值。再去谈团队所开发系统交付的业务价值时，它会作为沟通的基础。

加强沟通建立信任

那么，对你来说，提升你跟项目干系人之间关于项目利益的交流效率，这件事本身可获得的利益又是什么？最大的利益是能建立起信任关系。为了了解清楚项目干系人可获取哪些业务价值，你需要（至少开始建立）与他们有某种关系。这个发生在沟通业务价值的过程中。当你谈论项目的业务价值时，如果与项目干系人产生了共鸣，这个过程就会促使他们信任你——尤其是当你能交付这些价值时。它会成为一个自保持的循环，你谈论你的项目能实现的利益（或业务价值）越多，你跟项目干系人之间的信任关系就越强，你能创造的价值也就更大。

增进理解的实用工具

下次你从项目干系人那儿收集需求时，开头就开始谈利益或业务价值。确保利益是真实的。用可视化的方式把要实现的利益呈现出来是非常好的方式，并且对于达成对利益的共同认知也是种非常有效的方法（效果图 ⁷、各种思维导图、可视化的盒子都有助于完成这个过程）。

下面是在Denmark的一家大型公司中，使用可视化的盒子的一个例子。他们在盒子正面画上了项目的牌子和Logo，侧面上写着可实现哪些利益；背对着你的那面，写着项目的功能特征。

最后再给大家一些其他建议，通过下面的方法，增强团队和项目干系人的沟通效果：

• 理解真正的利益
• 用功能特性来支撑观点
• 提问题
• 创造利益至上的用户故事
• 使业务价值相关的沟通信息具有黏性
• 在沟通过程中重点建立信任关系

亲自试试沟通业务价值的不同之处。它将促进团队与项目干系人更好地互相理解、共同达成目标，并在工作中建立起信任关系。

关于作者

Jenni Jepsen致力于帮助个人、团队和组织，运用策略沟通来提升业务目标的一致性、为项目干系人创建价值、在过程中建立信任关系，在这些方面她有20多年的工作经验。她的沟通业务价值的方式，指出了增进理解、促进协作和迅速达成结果（有效引领团队成功）的途径。Jenni在关于企业如何提升业务价值方面从事演讲、写作和咨询的工作。

 

参考：

1. Active Stakeholder Participation: An Agile Best Practice
2. 5 Whys 
3. Business Value Driven Software Development
4. Introducing BDD
5. They’re not User Stories
6. Made to Stick 
7. Agile product management using Effect Maps

查看英文原文： Communicate Business Value to Your Stakeholders

---

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至 [email protected]。也欢迎大家通过新浪微博（ @InfoQ）或者腾讯微博（ @InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。