知识图谱构建案例_停止构建“即时案例”软件

知识图谱构建案例

几十年来，一个流行的说法是“建造它，它们会来”。 在软件中，事实并非如此。 确保我们正在构建“ Just-in-Time”软件，而不是“ Just-in-Case”软件。

在制造和库存管理的背景下，术语“ Just-in-Time”（JIT）和“ Just-in-Case”（JIC）在您看来似乎很熟悉，但是它们同样也适用（甚至更好！）软件开发。

简而言之，请确保您要构建的任何东西都具有已知需求和定义明确的范围！尝试构建您认为满足或超过当前和未来可能需要的产品或程序的方法太容易了，甚至常常有点乐趣。那里的问题是通常没人在乎！

对于功能超出其要求的系统，没有给予任何奖励。而且更重要的是，通常会有大量的沉没成本投入到过度设计中。

作为一个极端的例子，让我们参考一下您可能听说过的这家名为亚马逊的小公司。 2014年，亚马逊推出了新的消防电话，最终使他们损失了约1.7亿美元。事后看来，大量验尸告描述了一种产品，除了没有人特别关心的额外功能外，没有其他区别。（在此处阅读更多信息：杰夫·贝索斯（Jeff Bezos）的《消防电话惨案》的内幕）亚马逊在构建最终用户真正想要和/或需要的东西时显然迷失了方向。

在更小，更个人的方面，请想象以下情形。如果您不是一个“技术专家”，并且一时兴起，您会决定从头建立一个站来提升自己。最有可能的是，您将花数月时间随意学习基本的技术技能，将看起来似乎足够的东西打在一起，然后继续生活。您的成品不太可能像您期望的那样完美和美观，并且您所学的技能可能会随着时间的流逝而Swift消失。

另一方面，如果您突然失业，而获得理想工作的前景取决于拥有一个站来提升自己，那么结果可能会大不相同！在这种情况下，您将有动力在短时间内创造出值得骄傲的东西??

在第一种情况下，您正在构建您不特别想要或不需要的“即时案例”，并且输出反映了这一点。在第二种情况下，您在最需要的时刻构建了“ Just-in-Time”（即时）功能，并确定了它！不仅使最终结果更好，而且为达到该目标所花费的时间和精力也得到了改善。 IOW-这是精益操作。

不要从Mo鼠山上爬山

无论我们是在谈论世界上最大的公司之一，还是最小的“企业家”，这个概念通常说起来容易做起来难。让我们以大多数人认为最简单的概念为例，看看我们能以多快的速度向南走。

目前，我们编写的大多数应用程序都需要某种用户登录和身份验证。在过去，选择是有限的，而且很简单。您为用户提供了输入用户名和密码的位置，并且使他们能够在忘记密码时重置其密码。这种基本方法适用于许多系统，但不是全部。

如今，我们用于设计登录工作流程的选项多种多样，包括（但不限于）：

交登录-Facebook，Google，Twitter或其他第三方
使用电子邮件/密码登录
匿名登录
两因素验证
多因素验证
接触ID
面部识别
保持用户登录与自动注销

所以……我们还没有写过一行代码，我们已经必须决定要建造一座山还是一座积雪。考虑一下您的用户群体及其对复杂性和复杂性的需求。例如，真的需要多因素身份验证吗您是在保护政府机密，还是有人喜欢的食谱清单您的用户实际想要和需要什么您是否有可能从小规模开始，然后按照用户区的建议添加进去

有时用户确实知道他们想要什么

这将我们带到了我们的第一个过度工程解决方案，即用户反馈。无论您多么努力地猜测用户群的需求和意图，您都可能永远无法掌握全部情况。那简直就是野兽的本性。您拥有的意见以及相对较小的“专家”团队几乎无法捕获用户的意见，也无法直接听取他们的意见。

考虑一下-有什么更具代表性的用户意见示例是您的主题专家小组，还是来自潜在的数十，数百或数千个现实世界用户的反馈

与其他任何事情一样，收集用户反馈可以采取多种形式，但是在进行此操作时要牢记以下几点。

提出正确的问题

如果您没有提出正确的问题，则反馈没有太大价值。确保收集到的反馈的结构合理，可以帮助您采取有意义的步骤进行改进。例如，向某人问一个开放性问题，例如“您如何看待我的应用可能无法提供比要求他们以1到10的等级对3个非常具体的功能或优势进行排名的有价值的见解。

在正确的时间提出正确的问题

捕获最相关的用户反馈。例如，不要在结帐并购买商品后立即询问您的用户对登录过程的想法。在这种情况下，向用户询问结帐流程可能会产生更好的反馈，因为该流程在用户的脑海中是新鲜的。

以最适当的方式收集反馈

有很多收集反馈的方法，您需要确定哪种方法最适合这种情况。例如，向用户询问“提交”按钮最喜欢的颜色是什么，与用多种按钮颜色进行拆分测试并根据实际用户交互来查看“获胜者”是谁一样有效。用户反馈并不一定总是要口才有价值。

通过常识过滤器运行它

作为最后一道防线，确保您收集的任何反馈至少通过常识性嗅觉测试始终是一个好主意。确保您的问题和测试没有任何可能使结果产生偏差的内在偏见。这也将我们引向下一个重点…

有时用户不知道他们想要什么

好吧，所以也许客户并不总是对的……对吗尽管我们的目标是构建实时软件，但这并不意味着最小的范围始终是正确的选择。

例如，在上述关于登录功能的方案中，用户不太可能完全不知道哪种类型的解决方案最适合他们的需求。仅仅因为他们无法详细说明两因素身份验证和多因素身份验证之间的区别，并不意味着它们不是满足其需求的有效选项。

在许多情况下，即使需要扩大范围和预算，也必须优先考虑行业专家的意见。在那些情况下，您仍在构建JIT，因为只有最低限度的功能才能拥有可行的产品。所以……这是一条很长的路要提醒您，仅仅是因为您的目标是构建JIT，并不意味着您会抓住每一个机会的范围。这只是意味着您必须构建必须构建的内容。

工程过度的症状

在任何项目的生命周期中，总是有足够的机会对几乎所有事物进行过度思考和过度设计。这里是一些需要注意的常见领域。

功能太多（示波器蠕变）

当然，这是JIC工程最常见的原因，但这并不意味着最容易避免。只有通过对满足最低可行产品（MVP）定义的产品狂热地痴迷才能避免这种情况。最低限度可行的产品是具有足以满足早期客户需求的功能的产品。这些早期采用者可以为您提供有价值的反馈，以用于将来的产品开发。（维基百科）

例如，将我们的登录方案扩展到上面，这意味着您可能必须管理用户。您的应用程序的目标之一可能是您希望它在用户生日时自动为用户生成一个漂亮的针对性别的生日消息。该团队认为这将是一个不错的选择，并且可能会使用户参与度提高一到两个点。

为此，您至少需要捕获用户的生日和性别。然后，您需要创建流程来产生此消息，消息本身可能会经过多轮设计和修订，以就最终演示文稿达成协议。

因此……看似简单的请求最终会为预期的最小回创造大量的设计，开发和质量保证时间。除非您的产品非常成熟，并且您无法选择增加参与度的方法，否则此类功能将无法满足MVP或JIT开发的标准。

力求在骑自行车时像法拉利一样表现

面对现实吧……工程师只是喜欢对事物进行工程设计??。在工程师看来，有些人可能认为过度工程只是尽最大可能。您的应用程序是否需要像法拉利那样在最高性能和可靠性下运行还是从某种意义上说它更像是一辆自行车，它需要足够可靠才能完成工作，而又没有任何不必要的复杂性

照片由 马克·Kleen的 上 Unsplash

您的应用程序是否真的需要以下任何一项或全部

能够处理100,000个并发用户。
事务处理速度为每秒数千个事务。
能够即时故障转移到备份服务器。
全球每个主要人口区域的数据中心。
实时监控并通知潜在的威胁和错误情况。

还是只是为人们创建一个应用程序来存储他们喜欢的葡萄酒以及图片和品酒笔记无论哪种情况，都必须提前定义非常具体的要求，以使您知道您正在花费时间和精力在正确的情况下进行构建。

当然，每个人都希望有一个高性能的应用程序，但是如果您构建的应用程序具有比以往任何时候都需要的容量更多的功能，那么您就浪费了很多钱。

当需求不存在时关注合规性问题

这通常可能有点走钢丝。遵守各种法规可能是必不可少的弊端，但是如果定义不明确或不了解，也会导致JIC的发展。

例如，您实际上是在不存储任何用户付款数据的情况下，就在浪费时间讨论站的PCI合规性吗

当您不捕获或存储有关用户的任何个人识别信息时，是否担心遵守GDPR

您确定您没有在与您的业务或需求无关的合规性计划上浪费任何资源吗

总而言之，只需确保您没有将成本浪费在真正不需要的合规性工作上。

构建完美的捕鼠器

要再次聘请工程师……最好的工程师想要完美??。现在，这本身就是一个令人钦佩的目标，通常可以带来丰厚的回。但是，一切都有时间和地点。

您是否在项目开发的某个阶段仅需要证明一个概念快速而肮脏的原型是否可行在那些情况下以及其他情况下，编写“少于干净”的代码通常不仅可以接受，而且实际上更可取。

不过，请快速注意概念验证（POC）陷阱！有时，这些POC进行得非常顺利，以至于立即将其转换为生产代码。现在，突然之间，您的快速和肮脏的代码使它成为了生产版本，而您却因内置的技术债务而走出了起点！

[技术债务（也称为设计债务或代码债务）是软件开发中的一个概念，反映了因选择简单（有限但通常较快）的解决方案而不是使用会花费较长时间的更强大的方法而导致的额外返工的隐含成本。。 维基百科 ]

同样，这里总是涉及平衡行为。有时，建立JIT意味着还花时间在第一时间正确地做它，而不会招致不必要的技术债务，这会使您长期陷入困境。在其他时候，JIT意味着在需求和结果允许短期关注的情况下进行快速构建。始终意识到您有多少宝贵的资源被用于创建或修复技术债务。

使您的焦点狭窄而简洁

为了确保您正在按时而不是按时创建软件，我的最后一条建议是在需要时尽量缩短开发和反馈周期。

过去有一段时间，软件开发是基于“大爆炸理论”构建的。换句话说，将收集需求，编写规格，然后开发团队将消失数月，然后返回“成品”向客户展示。最大的问题是，当产品准备发布时，需求已经发生了变化……有时甚至是很大的变化。

当然，所有这些都导致越来越多的人采用了当今用于创建软件的多种敏捷方法。

[有关我们在公司如何完成此任务的更多详细信息，请单击 此处 ]

关键是，如果您依靠主题专家来从项目开始就知道他们想要构建的内容的每个细节，就无法创建JIT软件。每个软件开发项目都有自己的生活和个性。就像孩子一样，必须让您的项目随着时间的推移而成长和成熟。使您的焦点狭窄而简洁，并精确地聚焦在此时所需的内容上。消除这种情况，收集反馈，确定下一步的优先级，然后重新开始循环。

保持您的焦点狭窄，简洁，并专注于此时所需的焦点

从这里开始，您已经赢得了构建JIT软件的大部分工作。

翻译自: https://hackernoon.com/stop-building-just-in-case-software-8y6j38yj