产品需求沟通：如何表述清楚需求？

经过长时间的思考，需求的变化当然是造成这一结果的主要原因。另一个不容忽视的因素是需求表达不清。面对模糊的需求文档，开发人员无法完成既定的开发工作。如何表达清楚的需求？我们需要尽可能多地做两件事：1.usercaseese完全建立产品；2.努力在需求文档中做到清晰、完整、一致、可测试四点。那么对产品和开发的影响就可以降到最低，你的项目也可以在规定的时间内完成。如何建立产品的Usercasediagramusercasediagram，也称为基于面向对象思想和用户视角的用例图设计。下图是一个非常简单的例子。它有点类似于创建产品的用户角色。您需要能够从使用的角度描述用户是如何逐步操作产品的。用例是一种通过讲故事清楚描述需求的概念，很容易被用户和开发者理解；但缺点是无法清楚地描述如何实现，内部信息很少涉及。一旦我们不能理解产品的实现机制或内部工艺架构，我们必须使用其他方法来理解需求，这个过程可以理解为打开黑盒。这样，通过不断观察黑盒，打开黑盒，分析黑盒，然后打开黑盒的过程，我们可以准确把握整个产品的需求。例子就是这样一种帮助我们理解需求的方式。当然，如果程序员希望在阅读例子后制作程序，这是相当胡说八道的。。。因为例子本身只是用来解释用户的需求，所以很难准确地描述和定义产品的功能和结构。因此，我们还需要另一个交付物来清楚地表达产品的功能、工艺和结构，如产品需求文档。产品需求文档应有几个基本要素：相应的产品不同，需求标准不同，但有一些一般要素，仍可供参考：明确：许多写需求文档的人没有学习正式语言，所以我们看到许多需求文档是用自然语言写的。这种需求分析最大的缺点是它的二义性。因此，我们需要限制文档的表达，比如尽量只使用主谓宾的基本表达，避免修改句子，避免容易产生误解的表达。例如，我们正在建立一个社会保障卡系统，您可以描述需求：每个公交IC卡只能属于一个用户，社会保障卡有卡号和金额。医院可以使用社保卡，可以用来支付医疗费用。完整性：既不能说在提出需求的时候还有一些需求没有得到确认，也不能说在开发接近完成的时候有一些需求遗漏。不完整的需求是导致开发返工的最直接因素，也是令人发指的行为。需求的完整性要求产品人员具备良好的产品管理技能和对现有产品结构的清晰理解。大多数时候，产品人员面临着拍头或临时决定的需求。很难在第一时间提取完整的需求。我该怎么办？问！问问自己，问问客户，问问开发。任何交付给开发的行为，在你无法确认完整的需求或至少核心需求之前，都注定是不负责任的。一致性：需求可分为三个方面：业务需求、用户需求和开发需求。用户需求需要与业务需求一致，开发需求需要与用户需求一致，这不是胡说八道，而是三种需求之间的继承关系。否则，辛苦开发出来的东西很可能会偏离最初的实现目标。这种一致性也必须在具体实现过程中细化。用户需求往往在整个过程中不断变化，产生所谓的“需求变化”，不应超过既定范围，至少不应超过原始业务目标。可测试：许多人认为项目和产品的测试应该从编写代码输出测试产品开始，或者开发人员在编写代码时应该开始履行测试的职责，以便理解它是合理的。但是实际上，就像完整性的要求一样，测试过程应该从需求分析开始。需求分析作为测试的输入输入和参考，应进行测试。比如我们说“设计一个网站可以让用户第一时间了解车票市场”。这个需求可以测试吗？当然不是！车票是指火车票、汽车票还是两者都是？了解车票市场包括哪些方面？这些都没有在需求中解释，这意味着它们不能被测试，也不具有可测性。所以，我们的目标是确保需求的可测试性，包括前几个需求因素。当所有需求都可以测试时，确保产品从需求分析到设计开发再到最终交付都真正围绕着业务目标和用户的需求。产品可以更接近成功。如何解决“需求变化”带来的问题？我只能谈论这个“世界问题”。毕竟，这是项目开发中不可抗拒的外部原因。很多时候，产品经理或项目经理无法控制。在面向对象的开发模式下，管理者能做的就是尽可能避免变化可能造成的计划延迟。对于产品经理来说，他们不仅要控制进度，还要把握变化可能对核心功能的影响，因为你是舵手，你是“总设计师”。然而，有一句话：忽视需求过程或需求变化导致项目返工是项目失败的最大因素，大量项目的失败往往注定要处于需求阶段。正在做产品经理的人不妨审视一下自己的工作，发现情况不好赶紧处理。举两个典型的需求变化的例子：1。需求人员口头与开发人员沟通，留下另一句话：这些地方暂时讨论不清楚，不管，你先做，然后一段时间后提出新的需求，完全不管不同需求对开发工作的影响。2.告诉开发人员需要做xx产品，但是现在很忙，开发人员需要先做其他类似的产品。以上两种情况都会导致项目失败，尤其是当一些外行冒充专家时...