作为架构师，你应该如何挖掘真正的业务需求？
|
在上一篇文章中，作为架构师的你，已经了解到业务人员需要什么以及如何在收集用户故事的过程中识别需求。在那篇文章里，我还描述了用户故事模板：
这两种模板可以使开发人员能够注意到预期功能背后的需求。 那篇文章里，一个主要观点就是，在收集用户故事的过程中，谈论业务人员想要什么或者预期功能是什么更容易，但确定目标，即这些预期背后的业务需求，要困难许多。 当你开启一次用户故事会话并开始谈论功能时，你一定会注意到，你的谈话对象经常使用“类似需求”的词语。在这些需求里，哪些才是真正的需求？ 问题是寻找恰当的业务需求的第一个工具。如果你提出了一个高明的问题，那么它会让你获得相关信息。我深信，如果正在同你交谈的业务人员没有提供你正在寻找的信息，那意味着你在错误的时间提出了一个错误的问题。 请把前面那句话再读一遍。这揭示了支撑软件专家对话模式的其中一个关键假设。假设你应该完全负责对话的展开，你是将要提供软件的专家，你就是知道需要什么信息的那个人。 如果没有这种假设，就很容易由业务人员承担对话失败的责任——并认为他们无法有效交流。在业务人员身上寻找这些问题的原因并不能通向任何有意义的解决方案——而是要明白，这是你自身的不足！这就是为什么这项假设如此重要。 因为有两种不同层次的业务需求：需要避免的问题和希望获得的利益，所以也有两组问题来帮助你发现这些需求。 在以你的谈话对象试图避免的问题这样一个形式进行需求挖掘时，基本问题是“为什么”。试图回答“为什么”的问题，我们通常侧重于过去的问题。类似的结果可以通过使用一些更具体的问题来探索需要解决的问题领域得以实现：
这类问题的主要目的在于，弄清楚你的谈话对象想要这项功能的动机，或者，换句话说：他们为这项功能赋予了什么样的价值。或者，简单来说，这项功能有什么业务价值。 要找出可以获得的利益，基本问题是“为了什么”。当我们回答这个问题的时候，我们通常关注未来的利益，正如下面这些更具体的问题，它们就属于这一类：
现在，你可能想知道，如何知道在哪里寻找需求。这是避免问题的方向，还是获得利益的方向？答案非常简单：听听你的谈话对象说什么。你可以借助一些中立问题开始对话：
然后，仔细听听答案，并寻找表明特定类型业务需求的表达（见上一篇文章）。然后，你的谈话对象在哪个方向说得更多，你就可以开始提出与之相关的问题。 ——是什么使你想要这项功能？ ——噢，感觉有那项功能会很酷！ 好吧，它可能确实“会很酷”，但跟业务需求没有一点关系。这时，一组精确问题会很有用：
精确问题的语境有助于鼓励谈话对象根据所谓的“语义具体化（semantical concretism）”规则明确地进行表述。“具体化（Concretism）”是由Tadeusz Kotarbiński开拓出的哲学领域之一。根据该规则，句子中包含的名称要能够指代现实世界中存在的东西，只有这样的句子才是正确的。因此，句子“它会很酷”从语义具体化的意义上讲是不正确的，而句子“人员X将会把订货单发送给我们”是正确的。 “增加月度收入”、“减少隐性成本”基本就是具体需求了，同时它们几乎适应于任何现有业务。寻找与你正在开发的软件所面向的业务相关的需求。例如，作为一名在线书店的用户，我有如下需求：
这个简短列表中的部分条目将会转化成一项功能，但不是全部，因为它们中部分条目已经超出了IT系统的范围。 寻找那些让你的业务谈话对象想站起来大喊的需求，“是的！那就是我想要的!”。这些需求才是应该写进用户故事的需求。要决定哪个需求最接近业务人员真正想要传达的东西，你可以使用下列问题：
一方面，这些问题能够帮助我们得到满足这些业务需求的结果；另一方面，帮助我们设定优先级，确定最重要的需求。 现在，让我们综合所有关于需求发现的信息。我们将以业务人员和开发人员之间的对话为例。这样的对话经常发生，而且一般说来，遵循同样的模式：
团队提出的问题似乎没什么特别的——它们只是一些深入的精确问题。通常，情景语境是关键。在像上面这样的情况下，为了说“不！”，团队使用了大量详细的问题，有时还是技术问题。 当与团队中的某个成员交谈时，这个列表中的问题相当不错，因为你的谈话对象完全有能力回答它们。当使用同样的问题与没有准备好回答它们的人交谈时，因为他或她没有该领域的适当知识，团队的反应可能被视为故意带有攻击性。因此，如果你想说“不！”，就直接说“不”。这样当然更果断，而不是用许多不可理解的问题折磨你的谈话对象。此外，这样的对话经常出现的结局是，双方互相说服对方，一项特定的交互功能有用还是没用。 那是不是说同业务人员接触的时候通常应该避免这种类型的问题呢？当然不是！在某些时候，你最终还是不得不问他们。重要的是，首先发现需求，然后提一些更具体的或更偏技术的问题。 我在这里描述的对话会如何进行下去呢？
这时，一项业务需求已经被列为一个需要避免的问题：“我想要避免在月底等待销售图表”。 有了这项需求，就可以继续定义验收标准了。换句话说，必须确定你的谈话对象如何知道问题已经解决或者利益已经获得。为什么制订验收标准如此重要？稍后我们会谈论这个问题。
如果团队想要总结他们刚刚从客户那里了解到的内容，那会是像这样的东西：“我想要避免在月底等待销售图表。如果我能够一周两次看到关键客户的销售图表，那么我就能避免这一点。”有了这些知识，团队就可以继续对话了。
为了能够提供可选的方案建议，团队努力识别需求，并确定验收标准。这就是需求背后的秘密。针对新功能不“符合”架构的情况，最常用的策略是：提出证据，说服，并竭力提出自己的想法。当你把关注需求放在第一位时，你就能找到一个可选的解决方案。一方面，它能让业务人员满意；另一方面，团队也能接受。 由InfoQ主办的面向中高级移动开发者的GMTC全球移动技术大会（点击文末阅读原文链接了解详情）将要召开了，携程高级技术经理、《React Native入门与实战》联合作者魏晓军将为我们带来搭建React Native生态的分享。大会目前正值6折售票期间，欲购从速！ （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
