QCon北京「鸿蒙专场」火热来袭!即刻报名,与创新同行~ 了解详情
写点什么

软件专家的对话模式(第二部分)

  • 2015-03-05
  • 本文字数:3648 字

    阅读完需:约 12 分钟

在软件专家对话模式系列文章的第一部分中,你已经了解到业务人员需要什么以及如何在收集用户故事的过程中识别需求。在那篇文章里,我还描述了用户故事模板:

  • 为了避免_<_需要解决的问题 >,作为< 角色 >我想要< 功能 >;
  • 为了获得_<_预期的利益 >,作为< 角色 >我想要< 功能 >。

这两种模板可以使开发人员能够注意到预期功能背后的需求。第一部分的其中一个主要观点就是,在收集 _ 用户故事 _ 的过程中,谈论业务人员想要什么或者预期功能是什么更容易,但确定目标,即这些预期背后的业务需求,要困难许多。

当你开启一次 _ 用户故事会话 _ 并开始谈论功能时,你一定会注意到,你的谈话对象经常使用“类似需求”的词语。在这些需求里,哪些才是真正的需求?

寻找需求的问题

问题是寻找恰当的业务需求的第一个工具。如果你提出了一个高明的问题,那么它会让你获得相关信息。我深信,如果正在同你交谈的业务人员没有提供你正在寻找的信息,那意味着你在错误的时间提出了一个错误的问题。

请把前面那句话再读一遍。这揭示了支撑软件专家对话模式的其中一个关键假设。假设你应该完全负责对话的展开,你是将要提供软件的专家,你就是知道需要什么信息的那个人。如果没有这种假设,就很容易由业务人员承担对话失败的责任——并认为他们无法有效交流。在业务人员身上寻找这些问题的原因并不能通向任何有意义的解决方案——而是要明白,这是你自身的不足!这就是为什么这项假设如此重要。

因为有两种不同层次的业务需求:需要避免的问题和希望获得的利益,所以也有两组问题来帮助你发现这些需求。

在以你的谈话对象试图避免的问题这样一个形式进行需求挖掘时,基本问题是“为什么”。试图回答“为什么”的问题,我们通常侧重于过去的问题。类似的结果可以通过使用一些更具体的问题来探索需要解决的问题领域得以实现:

  • 它为什么重要?
  • 它的难点在哪里?
  • 你要预防什么?
  • 你会损失什么?
  • 你试图避免什么?
  • 如果你得不到这项功能会怎样?
  • 你会损失多少钱?

这类问题的主要目的在于,弄清楚你的谈话对象想要这项功能的动机,或者,换句话说:他们为这项功能赋予了什么样的价值。或者,简单来说,这项功能有什么业务价值。

要找出可以获得的利益,基本问题是“为了什么”。当我们回答这个问题的时候,我们通常关注未来的利益,正如下面这些更具体的问题,它们就属于这一类:

  • 它会带给你什么?
  • ……的用途是什么?
  • 你想要获得什么 / 多少利益?
  • 如果我们实现了它会怎样?
  • 然后什么将成为可能?
  • 可以实现什么?
  • 有什么与其相关的新机遇?
  • 它有什么真正的新东西?

现在,你可能想知道,如何知道在哪里寻找需求。这是避免问题的方向,还是获得利益的方向?答案非常简单:听听你的谈话对象说什么。你可以借助一些中立问题开始对话:

  • 是什么使你想要这项功能?
  • 在这项功能里,重要的是什么?

然后,仔细听听答案,并寻找表明特定类型业务需求的表达(见本系列第一部分)。然后,你的谈话对象在哪个方向说得更多,你就可以开始提出与之相关的问题。

寻找具体需求

——是什么使你想要这项功能?

——噢, 感觉有那项功能会很酷!

好吧,它可能确实“会很酷”,但跟业务需求没有一点关系。这时,一组精确问题会很有用:

  • 你是如何知道……?
  • 你将如何衡量……?
  • 如何?以什么方式?
  • 有什么特别的东西让你……?
  • 什么人?什么地方?什么时间?和什么人?多少?
  • 请举一个例子……

精确问题的语境有助于鼓励谈话对象根据所谓的“语义具体化( semantical concretism )”规则明确地进行表述。“具体化(Concretism)”是由 Tadeusz Kotarbiński 开拓出的哲学领域之一。根据该规则,句子中包含的名称要能够指代现实世界中存在的东西,只有这样的句子才是正确的。因此,句子“它会很酷”从语义具体化的意义上讲是不正确的,而句子“人员 X 将会把订货单发送给我们”是正确的。

寻找与具体业务相关的需求

“增加月度收入”、“减少隐性成本”基本就是具体需求了,同时它们几乎适应于任何现有业务。寻找与你正在开发的软件所面向的业务相关的需求。例如,作为一名在线书店的用户,我有如下需求:

  • 不能创建一个新账户(问题);
  • 不能每次购买都输入所有的数据(问题);
  • 购买一天后拿到书(利益);
  • 不能针对每一本书的递送单独支付(问题)。

这个简短列表中的部分条目将会转化成一项功能,但不是全部,因为它们中部分条目已经超出了 IT 系统的范围。

寻找有启发作用的需求

寻找那些让你的业务谈话对象想站起来大喊的需求,“是的!那就是我想要的!”。这些需求才是应该写进 _ 用户故事 _ 的需求。要决定哪个需求最接近业务人员真正想要传达的东西,你可以使用下列问题:

  • 如果避免了它,会有什么影响?
  • 如果实现了它,会有什么影响?
  • 如果现在你不得不同一个问题妥协,那么你会选择哪一个?
  • 如果现在你只能获得其中一项利益,那么你会选择哪一项?
  • 如果现在你不得不剔除一项利益,那么你会选择哪一项?

一方面,这些问题能够帮助我们得到满足这些业务需求的结果;另一方面,帮助我们设定优先级,确定最重要的需求。

需求发现实战

现在,让我们综合所有关于需求发现的信息。我们将以业务人员和开发人员之间的对话为例。这样的对话经常发生,而且一般说来,遵循同样的模式:

  • [**** 业务人员]:请注意,我想要在这个页面上增加一个可以生成部分报告的按钮……
  • [**** 团队]:应该展示哪些数据?如果没有数据,展示什么?这个需求与流程的整体设想一致吗?你想过部分数据聚合的影响吗?这可能需要更多重构……
  • [**** 业务人员]:嗯,我得问问……

团队提出的问题似乎没什么特别的——它们只是一些深入的精确问题。通常,情景语境是关键。在像上面这样的情况下,为了说“不!”,团队使用了大量详细的问题,有时还是技术问题。

当与团队中的某个成员交谈时,这个列表中的问题相当不错,因为你的谈话对象完全有能力回答它们。当使用同样的问题与没有准备好回答它们的人交谈时,因为他或她没有该领域的适当知识,团队的反应可能被视为故意带有攻击性。因此,如果你想说“不!”,就直接说“不”。这样当然更果断,而不是用许多不可理解的问题折磨你的谈话对象。此外,这样的对话经常出现的结局是,双方互相说服对方,一项特定的交互功能有用还是没用。

那是不是说同业务人员接触的时候通常应该避免这种类型的问题呢?当然不是!在某些时候,你最终还是不得不问他们。重要的是,首先发现需求,然后提一些更具体的或更偏技术的问题

我在这里描述的对话会如何进行下去呢?

  • [业务人员]:请注意,我想要在这个页面上增加一个可以生成部分报告的按钮……
  • 现在停一下。即使你确信这项需求不合理或者根本没有意义,也要停一下。不要争论,不要说服,而要发现需求。
  • [团队]:你希望通过这个部分报告获得什么?
  • [业务人员]:我不想在月底等待销售图表。
  • 正如你所看到的,团队的问题是关于希望获得的潜在利益,但业务人员指出了一个需要避免的问题。是的,这可能发生。在这样情况下,要跟随谈话对象。
  • [团队]:所以关键是等待销售图表的时间?
  • [业务人员]:是的!

这时,一项业务需求已经被列为一个需要避免的问题:“我想要避免在月底等待销售图表”。

有了这项需求,就可以继续定义验收标准了。换句话说,必须确定你的谈话对象如何知道问题已经解决或者利益已经获得。为什么制订验收标准如此重要?稍后我们会谈论这个问题。

  • [团队]:为了保持最新,你想要看到什么特定的图表,以什么频率?
  • [业务人员]:实际上,我需要关键客户的图表,一周两次即可。

如果团队想要总结他们刚刚从客户那里了解到的内容,那会是像这样的东西:“我想要避免在月底等待销售图表。如果我能够一周两次看到关键客户的销售图表,那么我就能避免这一点。”有了这些知识,团队就可以继续对话了。

  • [团队]:哦!所以我们可以这样做……或者这样做……或者那样做……在你看来,这些解决方案中的哪一个最好?
  • [业务人员]:那看上去很有趣……

为了能够提供可选的方案建议,团队努力识别需求,并确定验收标准。这就是需求背后的秘密。针对新功能不“符合”架构的情况,最常用的策略是:提出证据,说服,并竭力提出自己的想法。当你把关注需求放在第一位时,你就能找到一个可选的解决方案。一方面,它能让业务人员满意;另一方面,团队也能接受。

在 _ 软件专家对话模式 _ 系列文章的第三篇,我们将重点讨论如何自觉地运用词语以及如何管理对话流程。

关于作者

Michal Bartyzel——目前为止,我从事解决开发团队效率问题已经有十年的时间了。我致力于改进应用程序的架构和重构应用程序,以及改进我们所说的业务人员与开发团队之间的合作关系。目前为止,我已经对波兰最好的开发团队提供了 500 多天的培训和咨询。我得出这样一个结论,语言技巧是 _ 软件工艺 _ 的关键。这既适用于与业务人员的合作,也适用于开发人员的工作,我在我设计的、侧重于重构、代码及架构修改的培训中对此进行过阐释。我在这里对我目前为止研究得出的许多技术进行了描述。在众多会议期间,我还在我的博客和_Programista_ 杂志上分享了我目前正在研究的一些新技术。

查看英文原文:**** Conversation Patterns for Software Professionals. Part 2

2015-03-05 07:102190
用户头像

发布了 1008 篇内容, 共 407.2 次阅读, 收获喜欢 345 次。

关注

评论

发布
暂无评论
发现更多内容

Java项目实战营总结

eoeoeo

这套获50w+星标的算法神仙文档,足你解决90%的对手,牛逼

编程 程序员 架构 面试

爱了!阿里巴巴 Java 面试参考权威指南(泰山版)5月版开源

Java 编程 程序员 架构 面试

mPaaS 月度小报 | CodeDay#6 成都站落幕,下一站北京;上新季:新容器、新官网、新视觉

蚂蚁集团移动开发平台 mPaaS

移动开发 mPaaS

对EF Core进行扩展使支持批量操作/复杂查询

Spook

EF Core

开源即巅峰!阿里首次分享:Java架构师全栈“成长笔记”

Java架构师迁哥

JAVA 九种排序算法详解(下)

加百利

Java 数组 排序 7月日更

手机如果能折叠能卷的话,电脑为什么不能呢?

船医特拉法尔加

开发者 工具 柔性屏

渗透工程师必看-网络安全法条例-国家安全法介绍和案例

学神来啦

运维 黑客 安全 渗透

数据归档 - 冷热数据处理大师

趣链科技

数据处理 区块链+

区块链时代下,企业如何打造数据要素的“新竞争力”?

旺链科技

大数据 产业区块链

云端赛车-Amazon DeepRacer 的前世今生

亚马逊云科技 (Amazon Web Services)

人工智能 开源

监测生命体征、活动水平的可穿戴电子产品设计方案

不脱发的程序猿

物联网 ADI 可穿戴电子产品设计方案 监测生命体征、活动水平 智能传感器

银行4.0时代的营销与风控之路

索信达控股

大数据 金融科技 数字化转型 银行数字化转型 营销数字化

阿里的架构师一致好评!IT界首版全栈架构师全栈“成长笔记”开源!

Java架构追梦

Java 阿里巴巴 架构 面试 成长笔记

共36万字!为上岸Alibaba,我把Github上Java面试题都整理了一遍

Java 编程 程序员 架构 面试

Go 学习笔记之 字符串数据类型

架构精进之路

Go 语言 7月日更

腾讯上线零点巡航,用Java手撕一个人脸识别系统

北游学Java

Java 腾讯 人脸识别

Hive学习笔记(一)

五分钟学大数据

hive 7月日更

云图说|应用魔方AppCube:揭秘码农防脱神器

华为云开发者联盟

低代码 华为云 AppCube 云图说 应用魔方

卧薪尝胆30天!啃透京东大牛的高并发设计进阶手册,终获P7意向书

Java 编程 程序员 架构 面试

部分简单网页的基础了解

Emotion

html html5 Html报文解析 内部样式、 CSS语法

linux网络编程—7层网络以及5种Linux IO模型以及相应IO基础

Linux服务器开发

后端 网络编程 Linux服务器开发 网络模型 IO模型

云原生打包工具:Buildpacks

QiLab

Docker 云原生 k8s buildpacks

手把手教你实现聚光灯效果

ThingJS数字孪生引擎

大前端 可视化 智能灯控 数字孪生

MySQL连接数管理

Simon

MySQL

CDH 安装搭建(二)

大数据技术指南

CDH 7月日更

DICOM--网关(路由器/适配器)

birdbro

医学影像 DICOM PACS dicom4che DICOMWeb

灵魂拷问:我们该如何写一个适合自己的状态管理库?

尔达Erda

开源 云原生 大前端 API 运维开发

记某百亿级mongodb集群数据过期性能优化实践

杨亚洲(专注MongoDB及高性能中间件)

Java MySQL 数据库 mongodb 分布式数据库mongodb

字节跳动有状态应用云原生实践

火山引擎开发者社区

云原生 后端

软件专家的对话模式(第二部分)_研发效能_Michał Bartyzel_InfoQ精选文章