没有人喜欢输出臃肿、详细的产品需求文档，事实上，也没有人喜欢使用这类的需求文档。
打造出色的产品需要大量的研究和全面的规划，但是我们应该从哪里开始呢？产品经理通常从产品需求文档（PRD）开始。产品需求文档定义了您将要构建的产品，它概述了产品的用途、特性、功能和操作步骤。
在需产品需求文档完善之后，产品经理将与利益相关者分享 PRD，并寻求他们的意见，一旦评审完成——所有利益相关者达成一致，需产品需求文档可作为业务和技术团队帮助构建、发布或推广产品的指南。
一、敏捷开发模式下的需求收集
敏捷开发模式下的需求收集过程并不轻松，但别担心，像 PingCode 这样的工具能轻松帮助你解决需求管理中的障碍。以下是需要记住的几点：
敏捷开发模式下的需求管理方法（如：用户故事）是产品负责人（Product Owner） 最佳工具之一，不使用这些方法的产品负责人往往会陷入规范需求细节的困境。
另一方面，敏捷模式下的需求管理依赖于产品负责人、设计和开发团队之间就客户的理解达成共识，这样就可以将需求的实施细节留给开发团队自己去补充，从而减少产品负责人的压力，让产品负责人专注于更高层次的需求定义。开发团队是完全有能力这样做同样的，因为需求是基于团队共同的理解而建立的。
二、在团队之间达成共识
如果你也对上面提到的“建立共同理解”的实践感兴奋，但不知道如何创建它，那你可以从以下一些方面入手：
- 在进行客户访谈时，可以让设计师与开发团队的成员一起参加，这样他们就可以直接接收到用户的想法，而不是依赖于产品经理的文档进行揣摩。这也可以使得他们有机会对用户的最新想法或需求进行更深入地探讨。
- 尝试让开发站在用户的角度去考虑，这会使得每个团队成员都有独特的观点和见解，并了解用户故事是如何影响产品开发的。
- 找个时间和团队一同梳理缺陷以及产品待办列表，这种方式可以确保每个人对需求的理解都在同一水平，并了解为什么产品负责人建立优先级的考量角度。
大家可以按照如下步骤开始：
- 首先找一个文档协作工具创建客户访谈记录文档，比如 PingCode
- 然后通过客户访谈金字塔将访谈收集的信息转化为可以理解的需求
要注意的反模式
- 在开始任何项目之前，整个项目已经被详细的规划
- 在工作开始之前，所有团队都需要签“军令状”
- 设计人员和开发人员不知道需求何时更新
- 需求开始后就不再更新
- 产品负责人在没有团队参与的情况下梳理需求
当你已经和团队就一组用户故事进行多次会议讨论，并得出的结论是还需要考虑更多维度。这个时候你可能需要去验证一些新的假设，考虑这些用户故事如何融入与整体规划，去思考讨论中一些开放性问题的答案。
三、使用统一的模板保持需求内容的精简
在编写需求文档时，整个团队使用统一的模板、工具很有意义，比如这样每个人都可以跟进并提供反馈。在 我们接触的很多公司，都是使用 PingCode 文档管理工具创建产品需求文档模板，然后团队成员再以统一的模板创建产品需求。我们发现，这样做能够为需求文档收获更多的背景信息，帮助团队理解项目的需求及其对用户的影响：
1. 定义需求文档细节
我们建议在页面顶部包含以下高阶方向:
- 参与者：谁参与其中？包括产品负责人、团队、合作伙伴。
- 状态：程序的当前状态是什么样的？打开的，进行中的，已完成的，关闭的等等。
- 优先级：哪些紧张而且重要的？
2. 团队目标和业务目标
将需求与团队目标和业务目标关联。
3. 背景以及与战略的相关性
我们为什么要这样做？这是否符合公司的整体目标？
4. 做出合理假设
列举该功能的一些设想，比如技术、业务或用户需求等方面的。
5. 用户故事关联涉及的背景信息
将该需求链接到涉及的用户故事、客户访谈内容（包括截图）等，提供足够的细节来完善整个故事，并为这个用户故事设定成功的指标。
6. 用户交互和设计
在团队为每个用户故事有了解决方案之后，将设计稿和线索上传到文档附件。
7. 问题（缺陷）管理
在团队构建解决方案的过程中，他们也经常会产生意料之外的问题或缺陷。创建一个 “缺陷列表或者Todo” 的表格来跟进这些事项。
8. 改进
明确的标记出那些目前超出范围但以后可能会考虑的内容，并让团队专注于手头的工作。
Tips：敏捷宣言提醒我们可以灵活地创建需求。有些团队通过用户故事关联关系以识别问题和找出解决方案。有时候，整个团队人员（产品负责人、开发人员和设计人员）会拜访客户，然后对客户提到的某个特定问题进行头脑风暴。无论需求是如何产生的，重要的是团队将其视为定义和沟通客户问题的一种方式。
四、”一页纸”方法的关键要点：
使用”一页纸”需求管理方法的优势：
1、统一的来源，信息简单明了。产品需求文档成为一个相关信息的集合，能够节省团队成员访问这些信息的时间，并提供给他们一个找寻其他信息的入口。
1、灵活性，使用简洁页面进行协作的好处之一是可以灵活地编写文档！并能够根据需要优化文档的格式，不会被一些需求软件的固定字段所限制。
3、完善的背景和细节，在产品需求文档中插入多个链接，有助于理解复杂的内容，并根据读者的需要逐步展示信息。在一个需求文档中链接详细的资源可能包括:
- 访谈记录
- 相关研究资料或分析报告、文章
- 以前的讨论或者技术文档、数据
- 外部的产品演示视频或者其他来自外源的相关内容
4、直接关联到下一个工作环节，PingCode 很多客户 都是在 PingCode 知识库中撰写需求，在确定之后会将相关页面关联到开发任务下，实现文档管理工具与项目管理工具之间的关联同步，这也意味着我们可以自动地从需求页面上看到每个问题的当前状态。
5、广泛的征集意见，在知识库中构建产品需求，当必要时能够轻松的让不同团队中人参与进来，有时候他们能在讨论中给出很好的反馈、建议，或者从类似的项目中提供经验教训。
6、团队协作，通过 PingCode 知识库构建需求，可以让团队中的每一个人都参与进来，避免完全按照自己的想法构建需求。也可以鼓励开发人员、设计等团队成员评论、提出问题、想法等。这对于远程团队尤为重要。
每种方法都有缺点，使用”一页纸”需求管理方法的缺点有：
1、文档可能会过时：当用户故事发布并获得用户的反馈后，你可能修改原有方案，这将会覆盖原有的内容。这需要团队根据自身习惯权衡利弊，并选择合适的方式。
2、难以激起人的参与感：“我能做些什么来鼓励人们发表评论？“，“我怎样才能鼓励人们在我们的文档贡献更多内容？” 这是一个很难解决的问题。
当进行灵活的需求管理时，产品负责人将有更多的时间来了解并跟上市场的步伐。保持需求的信息丰富但简短，使开发团队能够使用最适合其架构和技术堆栈的任何实去实现。
一旦项目的需求被完善，我们建议使用前文提到的方式，直接关联到开发环节的相应用户故事。这能够让开发过程更加透明：比如很容易看到每一项工作的状态，让产品负责人以及下游团队（如营销和支持）做出更明智的决策。
记住要在项目过程中保持敏捷，在团队构建、交付和获取反馈时持续改进用户的体验，始终保持高质量的标准和健康的工程文化 – 即使这会影响交付的功能数量。
