为什么公司每天要求写日报
关于如何编写需求，有很多建议。 关于为什么要编写需求的讨论不多。 在决定如何编写需求之前，花一些时间思考为什么要编写需求。
为什么要写要求？无论您是通过对话，带有接受标准的用户故事，传统的结构化需求和用例，还是图表和注释来传达需求，您都可以将其共享以达到最终目的–创造合适的产品。 不要仅仅遵循一些规定，而要完成文档要求的动议 。 退后一步，考虑以下要求编写目标。
增进对市场需求（您的需求）的了解。 确定交付选择的顺序。 与您的工程团队合作（并设定期望）。 与利益相关者一起管理期望。 提高产品创建过程的效率。 记住为什么您的团队创造了他们创造的东西。每个团队都会根据自己的独特情况对上述每个目标给予不同的重视。 上述每个目标对于您的团队来说都是最紧迫的目标。 万物平等，恕我直言，目标是按照重要性递减的顺序。
了解您的市场尽管撰写要求只是间接地有助于您的理解，但了解您的市场需求是编写要求所支持的最重要目标。 没有一个单一的标准化结构来获取市场了解 ，每个产品经理都有自己的方法，范围从“在您的脑海中”到便签纸，餐巾纸，画布，思维导图，Wiki和大文件。 它们的共同点是，它们都可以帮助产品经理进行信息的综合和分析，就需要交付的重要信息做出决策。
壁挂式流程存在缺陷，不仅因为它们抑制更改，而且因为它们阻碍了反馈循环。 根据您对市场需求的了解来记录需求的简单动作将发现机会，以提高您对市场的了解。 当您应用需求完整性和正确性规则时，您会发现您缺少某些信息，并且某些分析是不完整或有缺陷的。 撰写要求会形成反馈循环，迫使您重新审视并提高对市场的了解。
顺序传送就什么对您的市场，特别是对您的客户和潜在客户，重要和重要的观点提出看法。 将其与贵公司的愿景或策略结合起来，特别是贵公司打算如何为您的市场服务。 综合考虑竞争格局 ，特别是竞争对手（客户可以选择的替代解决方案）如何竞争以及如何竞争。
当您的需求文档确定了您要解决的目标时，实现这些目标对他们和您而言价值多少以及相对的战略重要性，该文档就可以告诉您要构建的每个“事物”的相对价值。 这是构建内容顺序的关键因素。
与交付协作我喜欢Jeff Patton的公司（ Comakers）的名字 。 它传达出发现哪些问题值得解决是产品经理和工程团队之间的共同努力。 有趣的是有价值的问题的解决，而不仅仅是发现值得解决的有价值的问题。 口头表达，图形表达或散文表达的需求是合作与交流的一部分。 价值与可行性，时机和成本的交集决定了您的团队可以实现的目标。
请注意，排序决策通常与解决方案决策紧密结合。 换句话说，您不能独立地解决“何时”和“如何”，而必须同时解决“为什么”的问题。
管理期望当利益相关者知道期望什么时，他们会得到更好的服务。 知道预期的一部分就是知道您的预期范围–理想的是根据市场需求进行交流，更常见的是根据“什么”和“如何”进行共享。 您传达的要求反映了“为什么”，并且是管理期望的关键组成部分。 管理期望（例如， 预测“何时” ）还远远不止这些，但能够说“这些是我们打算解决的问题”是一个很好的起点。
提高效率从定义上讲，不知道为什么进行构建的团队将构建不需要的东西 。 从定义上讲，忽略机会以变得更聪明以应对变化的需求的团队也将创建不需要的东西。 您记录的需求使团队可以将精力集中在需要的东西上。 当您变得越来越聪明（了解更多有关您的市场，适应市场变化等信息）以及团队消耗这些更新的节奏时，将影响团队保持专注于（按定义）移动目标的能力。 记录和传达需求的方式的清晰度会影响交流的有效性。 所有这些因素都有助于提高团队的效率，从而提高其创造价值的能力。 我的经验是（ 遵循告诫以减少收益） 遵循要求规则的少量额外时间可以避免花费大量时间进行澄清和重新沟通，从而为我腾出了更多时间来“变得更加聪明”。
记住意图企业软件人员非常了解软件应用程序可以生存数十年。 我们也知道不知道为什么产品中存在特定功能，由谁使用，提供了多少价值，或者如果我们改进（或删除）该功能会发生什么，这是什么样的感觉。 如今，软件即服务已受到关注，越来越多的面向消费者的产品将具有相似的较长生命周期。 当您记录需求时（在构建内容时），请勿将其丢弃。 保留这些要求，在您忘记了为什么要构建某些内容之后，它们将在以后提供上下文。 这对于晋升后接任工作或前往绿色牧场的人来说尤其重要。
结论和更多 请记住为什么我们要编写要求。 在考虑如何编写需求时，请考虑不同技术对您重要的目标的影响。
翻译自: https://www.javacodegeeks.com/2013/07/why-write-requirements.html
为什么公司每天要求写日报