大家好！
今天，请您的注意力以自己的方式翻译一篇不可替代的文章，它将帮助您正确地使用乍看之下您不理解的最隐蔽和最琐碎的传统知识。 最主要的是不要放弃并聪明地提出问题。 美国银行的贾斯汀·富勒先生概述了正确做法。
祝您阅读愉快！
所以这一天到了。 也许这是您的第一个工作日，或者您已经在这个地方工作了十年-没关系。 它发生在每个人身上：您终于遇到了您根本不了解的任务。
怎么办 刚开始并希望一切都可以正常工作吗？ 还是承认老板因为您不了解而无法执行此操作？
我认为您猜对了，正确答案既不是一个也不是另一个！
我注意到，在编程中，就像在其他职业中一样，几乎不可能在不必面对一个完全难以理解的任务的情况下工作一周（有时是工作日）。
但是不用担心！ 有个好消息。 您不仅可以解决此问题，而且还可以使您受益。
毕竟，与过去所做的一切相比，这样做必须扩大您的知识和技能。
接下来，我将告诉您如何弥合为您设置的需求与完成任务所需的知识之间的鸿沟。
关于“要求”
正如您已经注意到的，我使用“要求”一词。 根据您在哪里工作，这个词可能有某些含义。
以我的经验，在大型公司中，他们喜欢需求，而在小型公司中，他们有时“不提出要求”。 我认为这是我们应该在这里谈论的。
事实是，最终，所有程序员都做同样的事情：他们解决问题。
您可以获取有关如何解决此问题的详尽的一百页传统知识（我曾经参加过一个小时的会议，讨论按钮上的文本）。 或许是这样：CEO走过你的办公桌，仿佛无意中问到：“您会在星期五之前完成这项任务吗？”
在这两种情况下-任务都是为您设置的，必须确保您完全理解它； 唯一可以接近她的方法！
关于阶段
并非所有任务都需要下面列出的所有步骤。 只有最复杂的任务才需要仔细完成本文将要讨论的所有步骤。
有很多问题可能仅基于表达的要求或由于您的个人经验不足而无法回答。
您可能需要咨询其他开发人员，团队负责人，产品负责人，业务分析师甚至祖母！ 也许每个人都可以解决问题！
但是，这很正常。 这意味着您将收集不同的知识并将其收集为一个整体-这样您就可以实现最佳结果！
最后，最后一个警告：不要过度用形式化！ 这里最重要的是快速了解任务。 无需人工屏障和红丝带！ 所需要的只是解决您当前不了解的问题的系统计划。
第一阶段：分析问题在此阶段，我们正在尝试了解您的要求。 直到我们尝试决定如何做！
抓住这种差异很重要。 在未意识到所有后果的情况下进入职业生涯可能会很危险，或者更糟的是，无法完全理解您被要求做的事情。
我们对问题进行分类对任务进行分类意味着确定必须完成哪些工作才能解决它。 以下是一些任务类型的示例：
请记住，此选项列表不限于此。
在这种情况下，我们必须确定您期望进行的工作。 这很重要，因为它将直接影响您将从事的工作。
对于模糊需求，此阶段尤其重要，例如：“我们需要一种在更新站点后以某种方式清除客户端缓存的方法。”
以下是对此要求的一些可能解释。
- 您必须快速实施某种机制来清除缓存，以便客户端始终接收最新更新。
- 有必要研究所有存储这些客户端缓存的方法，并确定在每次站点更新后摆脱这些缓存的最佳选择。
- 客户端缓存应该已经被清除，并且您需要查找并修复阻止此问题的错误。
在此阶段，如果您不确定要解释什么意思，则需要寻求澄清，然后才能继续工作。
用一两个简单的陈述来表达问题的实质。总结复杂的需求，好像在回答“您今天在做什么？”这样的问题。 它可能不是那么简单，但是您应该尝试将问题的实质简化为一两个句子。
如果以这种方式汇总任务失败，则可能意味着应将其分为几个子任务。 原则上，此步骤将变成石蕊测试，表明您是否设法以足够小的碎片形式组织任务。
这是一个很好的摘要示例：“更新网站时，我们在文件上附加一个唯一的编号，以便浏览器理解它必须使用最新版本的代码。”
为了简单起见，该任务通过了“石蕊测试”，也许不需要将其分解成较小的碎片。
这是一个不好的例子：“更新网站时，我们在文件上附加一个唯一的编号，因此浏览器知道它必须使用最新版本的代码。 我们还必须向CDN发送一条消息，以这种方式通知它需要更新文件。 还必须设想iOS和Android的应用程序会将更新发送到应用程序市场。 更多...”
在这种情况下，测试肯定是失败的。 需要大量工作，也许每个任务都需要分别识别和跟踪。
突出关键细节现在，您应该（以自由格式，最方便的方式）列出需要完成的主要工作。
同样，这应该是每个主要阶段的非常简单的压缩。
这不是分步指南或详细的故障排除指南。
请记住，在继续分析分配给您的任务时。 在此阶段，我建议做笔记。 就个人而言，我将使用Notes应用程序。
我们的缓存任务非常简单，很有可能不必以这种方式进行概述。 让我们看一个更复杂的例子。
我们的下一个任务是实现新的机遇：“每个用户都应该收到针对我们内部产品的定向广告。 该广告应根据我们收集的数据量身定制，以满足用户的需求。”
为了隔离此任务的主要元素，我们必须清楚地想象实现每个元素需要做什么。
- 我们现有的广告将需要以与某些特定用户参数相关联的方式进行分发。
- 对于我们的营销部门，我们需要提供一种方法，使我们可以将新广告与一个或多个用户数据相关联（在这种情况下，营销人员不应编写任何内容！）
- 该系统将必须汇总与我们广告环境相关的用户参数。
- 最后，您需要创建一种可以接收用户ID并展示广告的系统。
这样的列表的优点是可以迅速与团队或老板达成一致！ 因此，在此示例中，您可以将该列表显示给团队负责人，他决定列表中还缺少另一个非常重要的要点：
归根结底，我们最后要惹恼的是我们最喜欢的用户！ 花一些时间和时间思考任务仅需花费额外的几分钟，我们就可以避免将来数小时或数天的麻烦。 因此，重要的是制定和计划一项重要的任务，然后再着手编写代码。
在继续之前，我想回答您可能提出的批评。
也许您认为：“在正常交付的业务中，应在为开发人员提出要求之前完成此类工作” –我完全同意！
但是，可悲的是，我们的世界并不完美。 有时，开发人员无法满足的要求就摆在货架上。 因此，在着手开发之前，我们必须尽一切努力正确评估需求。
确定您要解决的问题。回答问题：“为什么有人必须使用它？” 或“在这种情况下我要解决的实际或感知问题是什么？”
希望答案是显而易见的。 在此处给出的第一个示例中，答案是：“用户将始终看到最新更新。” 在第二种情况下，通过广告，“用户将始终看到相关的通知，而不是不感兴趣的通知。”
这两个答案的使用应该是显而易见的！ 对任务及其目标有更深入的了解，您可以做出更合理的决策，并制定适当的实现业务目标的实施方案。 如果有可能找出错误的解决方案和毫无意义的任务，那么就可能不会浪费时间和精力进行搜索，这从定义上说不会帮助解决问题。
第二阶段：解释和评估需求在此阶段，您应该已经想象了您必须做什么以及为什么要做。
接下来，您需要了解将要执行的操作，将如何执行以及为什么要这样做的详细信息。
清除与任务相关的重要术语。
对于作为团队一部分的新手开发人员，或者如果您在大型公司工作，此步骤可能更重要。 在这两种情况下，您很可能会遇到需求中不熟悉的术语。
这些可能是业务概念，例如产品名称，客户或流程。 可能存在与开发相关的术语，例如，工具，应用程序，模型，服务或库的名称。
您需要确保您完全清楚地理解所有重要术语，以便可以正确执行任务。
也许您已经了解到您需要发明一种访问汇总的用户信息的方法，但是您是否理解“将其添加到dao”意味着什么？
您可能知道您需要格式化广告数据，但是您是否知道“ MADF”（广告新闻提要的标记）是什么？
我一个都不懂。
这就是为什么您需要隔离并定义所有重要术语的原因。 混淆定义是正确解决问题的正确方法。
决定应如何完成任务。在此阶段，您应该已经知道如何执行任务。 此过程的详细信息可能会有所不同，具体取决于您在哪里工作以及分配了哪些特定任务。
在某些团队中，没有人会向您确切说明如何实现需求，他们只会说应该在输出中获得什么功能。
在其他情况下，将详细介绍您采取的每个步骤。
您很可能会处于某种中间情况。
如果团队没有为您提供指示，那么在此阶段您将几乎无能为力。 如果您已收到说明，请开始熟悉必须经历的阶段。
此步骤似乎是完全自然的，但重要的是要注意我们执行该操作的顺序。
自然，我们想立即投入任务的所有细节并对其进行研究，直到我们设定的目标对我们完全清楚为止。
但是，由于您已经花了一些时间来理解问题，因此您现在应该对整个问题有一个更清晰的认识，评估实现该问题所需采取的步骤。
确定是否正在处理任务。在这个阶段，分析和解释阶段合并在一起。 在分析阶段，您专注于整体情况和大型目标-我们做什么以及为什么这样做。
在解释阶段，重点关注细节-我们如何做到这一点。
第二阶段称为“解释和评估”，因为现在您可以将“如何”与“什么以及为什么”关联起来。 您根据整体情况解释细节。 您评估详细信息并确定原始问题是否已解决。
yourself心自问：指示我采取的步骤是否会导致结果（被指定为任务的最终目标）？ 计划的结果真的解决了原来的问题吗？
如果您确定所有问题都可以解决，并且细节有意义，那么您就可以开始工作！ 否则，有必要进入第三阶段以解决各种冲突。
第三阶段：我们严格解决问题在此阶段，您应该能够自信地断言自己了解任务和解决方案。 剩下的就是该决定是否正确。
为了创造最高质量的产品，如果有些事情显然是错误的，我们所有人都必须能够承担责任并大声疾呼。
另一方面，我们不会提出不当的主张。 不能说某事是错的，因为“看起来如此”或仅仅是“不喜欢”。 必须提出具体和精心设计的论据。
因此，我们概述了胜任分歧的基本规则
知道何时不同意- 在我彻底弄清问题之前，分歧是无法接受的。
只有绝对确定您了解不同意/，才有可能说“这是错误的”
如果您不能自信地提出问题和计划解决方案，那么您就无法不同意。 如果不确定自己是否正确理解所有内容，则不能不同意。 仅确保您最了解问题，您才可以不同意。
如果您认为自己没有所有必要的信息，那么可能是时候停止并复查已完成的所有步骤，然后声称要求不正确。 - 一个人只能出于主观原因而同意。 寻找真正的潜在问题。
“我不喜欢这样做”是一种主观判断。 客观原因是：“因为涉及许多操作，这将导致性能问题”。 其他主观原因的示例：“在另一个项目中，我们以不同的方式进行了此工作”或“我将以不同的方式实施此解决方案，但这当然是一个问题。” - 您应该准备周全的解释来支持您的主张。
如果您无法解释为什么出问题了-您可以确定自己是对的吗？ 我建议您写下该决定对您而言错误的原因，并阐明如何解决该决定。
如果您无法提供这样的解决方案，请从一开始就清楚地告诉我。
与他人不同意时要小心。 倾听所有人的声音并理解所有内容都需要花费大量时间-只有这样您才能同意。
如果到目前为止，您认真地遵循了所描述的所有步骤，那么您很有可能精通所有内容。 但是，请尽量不要将自己锁定在计算中-您可能错过了一些东西！
我喜欢用这样的话开始讨论：“不是我不同意你的意思，我只是不了解。” 后来，如果有必要，可以表达强烈的分歧，但是首先要弄清楚。
知道如何正确地反对
为了保证我们的分歧是客观的，我们将采取许多措施来帮助我们理解我们的论点是否合法。
客观分歧使我们能够证明至少以下事实之一：
- 决策不充分
- 决策误导
- 任务或解决方案不合逻辑
- 解决方案不完整
缺乏信息不是怨恨的理由； 这仅意味着在创建解决方案时，您来自不完整的数据。 也许传统知识的起草者不知道已有的系统能够执行必要的行动。
被告知错误意味着根据不正确的信息创建解决方案。
传统知识起草者认为，这种情况是现有系统可以做些事情，但实际上并没有提供这种可能性。 例如，SEO团队要求您让Google在您的应用程序中使用用户帐户对页面进行索引。 Google无法做到这一点。 这意味着您的seokhniki误解了Google搜索机器人的功能。
不合逻辑的任务或不合逻辑的解决方案根本没有意义。 一个典型的示例（从开发人员的角度来看）是实现一项功能，该功能会降低其他一些功能。 这样的要求可以被认为是不合逻辑的，因为它带来的危害大于帮助。
解决方案是不完整的，有时是有目的的。 在软件开发中，我们经常尝试创建MVP（最小可行产品）以开始使用。 这意味着在第一个操作中，您可以有意地延迟并非绝对必要的功能的实现。
实际上，只有当决策不能解决为您设置的问题时，或者上述步骤不足以创建可行的产品或充分的机会时，才可以认为决策是不完整的。