您可能熟悉这样的情况：看似简单的请求会引发意想不到的困难。通过“构建-测量-学习”，我想向您介绍一种合适的方法，您可以通过它逐步接近最佳解决方案，并将错误开发的风险降至最低。
“简单”的扩展
让我们看下面的例子：客户使用保险公司的在线服务。当然，个人数据 - 特别是电子邮件地址 - 也必须输入在线表格中。然而，由于客户精通网络，他也可能对特殊的在线保险产品感兴趣。因此，通过电子邮件告知该客户此类产品及其有吸引力的价格是有意义的。
没有什么比这更容易的了：只需征得客户的许可即可。
开发团队也不认为这是一个问题。只需在发送按钮前面安装一个复选框，并将结果保存在数据库中。然而，需求工程师询问营销部门或保险机构如果在工作中使用数据库 B 和 C，应如何评估存储在数据库 A 中的该 糖尿病邮寄名单 客户的车牌号，这并非完全错误。
此外，数据保护部门清醒地表示，此类个人数据当然值得保护，并且不得在任何上下文中存储。最后，法务部门还指出，此类广告邮件能否合法发送很大程度上取决于同意文本的内容。
项目的构思和实施很快就会变成一个小项目，根据公司的规模，可能需要付出相当大的努力。因此，还必须构建一个小型商业案例来证明该项目的经济可行性。
质疑假设，在假设中思考
但如何避免这种跨部门的努力呢？毕竟，公司的系统环境已经发展了很多年，您不能从一个绿地站点开始。
首先，重要的是要清楚你实际上在做出什么假设。我们的示例假设客户通常愿意出于广告目的而同意，以便更好地了解有吸引力的产品。但这真的适用于所有精通在线的客户吗？客户如何从这些促销电子邮件中受益？最后：各自的产品真的那么有吸引力吗？
很快我们就会发现，人们太容易根据自己的一厢情愿和客户的需求得出结论。现在本身并不禁止做出假设。然而，您应该始终意识到这些通常只是假设，有时可能会被证明是不正确的。
为了能够尽可能地设身处地为客户着想，您应该首先考虑您想要覆盖的目标群体到底是什么。例如，您可以为此使用角色。然而，我个人更喜欢不太详细的分析，因为它们通常可以更快地测试单个假设。出于心理原因，随着工作量的增加，人们对所做出的假设正确性的确信程度往往会增加。如果为各个角色分配了名字和面孔，那么这些假设通常就不再受到质疑和实证检验。不幸的是，这让我们回到了问题的开始。