借用敏捷方法，开发人员讨论了在某些情况下，在服务器端之前在客户端工作的原因是有道理的。
任何高级开发人员都知道，到目前为止，更好，更容易地开始在后端开发软件项目，然后再转到前端。就个人而言，当我有可能时，我更喜欢这种方法。
但是，我们有一个非常重要的因素，通常会让我们改变这个顺序：客户端或用户（以下简称用户）。
不幸的是，在大多数情况下，用户虽然认为他们在创建故事或要求时知道他们想要什么，但他们总会忘记或省略事情，并且他们相信事情是以特定方式完成的，事实上，他们是实际上完全不同。换句话说，70％的质量要求取决于用户。
大多数时候，开发人员和产品团队都非常优秀，技术娴熟，专业。由于缺乏技术技能，项目通常不会失败。有时，不可能看到质量差和需求管理是导致项目大部分时间失败的原因。
作为旁注，管理和分配任务给团队与需求管理无关; 很多团队将任务与需求混合在一起。它们需要完全单独管理。当您管理要求时，通过确保用户收到他们要求的所有内容，确保您的应用程序能够完成预期的工作; 当您管理任务时，您确保开发团队中的人员正在完成工作，他们没有被阻止，他们交付，交付物是优质产品。敏捷方法通常只负责任务管理并略微触及需求。
回到正轨，缓解需求问题，当用户不清楚他们需要什么时，建议使用功能原型。在软件开发中，它不是创建应用程序的最佳方式; 通常，这需要多达50％的时间和资源来完成项目，但是当您尝试交付项目时，您最大限度地降低了无限循环变更和软件重构的风险，因为应用程序将无法满足其实际需要做。
在Functional Prototype上，首先使用所有导航和数据验证来创建整个前端。您不能使用后端，数据库设计或类似的东西。用户有责任查看，导航和验证原型是否符合他们的需求。通常，这需要进行多次测试，直到一切都到位。
当然，用户会忘记一些事情，并会在完成功能原型后进行调整，但是你已经将其减少了10比1，因为通过查看应用程序的有形部分，用户更容易记住他们的内容需要，他们忘记了什么，或者工作过程是如何完成的。更改并对前端进行任何类型的调整会更容易，而不必重构整个应用程序（即前端和后端）并且必须运行回归测试。
完成Functional Prototype循环后，我们继续连接前端和后端。正如我之前所说，在开发方面，它不是处理项目的最佳方式。如果从后端开始，您将发展得更快更有效。
使用功能原型，您所做的是在没有明确和质量要求时将项目失败的风险降至最低，否则，项目将变得混乱，因为用户不知道他们实际需要什么项目即使他们认为他们这样做了。
