现在我们的需求梳理方式，基本上就是一句话。什么意思呢？就是有一个需求文档，项目负责人把要做的事情依次列出，再对其进行评估，如果需要设计原型，就安排产品进行功能原型设计，如果需要提供解决方案，那么就先安排自己或其他开发成员提供解决方案。
好像没有什么问题？其实，真正的产品需求文档，也就是俗称的 PRD 文档，是很规范的，就不说什么形式上的问题，比如文档信息、版本更新历史、名词解释等等。就光内容的要求，就很精细。就拿 APP 的 PRD 文档来说，是需要把原型的图片贴到文档里的，然后要对每个功能和交互进行说明，比如点击这个按钮，会出现什么弹窗，弹窗的布局是什么样子的，内容是什么，文本是什么颜色的，是使用什么字体的等等。比如，XiaoPiu 的官方示例：
这样详细的好处是，在之前的文章《16 - 项目的任务质量如何保证》中已经有过类似的叙述，那就是避免需求边界不清晰，导致后续的返工。
但是，对于我们现阶段而言，项目的需求应该怎么梳理呢？这个怎么说呢？如果是在大公司，分工比较明确，那么这样做无可厚非，精益求精未尝不可，但是，如果是中小型公司，或者只是一个部门，要自负盈亏，考虑到实际工作中的产出，或者说性价比，那么就感觉有点过度精细了，说好听点，是追求极致与差不多这个度怎么把控的问题，说直白点，是怎么利益最大化的问题。
所以，从实际情况出发，虽然 PRD 文档规范化，有诸多好处，但是投入产出比显然很低的，因为没有那么多人手把这个需求做到这么精细的程度，加上平时沟通也很及时，有什么问题及时沟通处理就行，而且，PRD 文档规范化还有一个重要的目的是，为了和其他部门或其他公司进行沟通交流使用的。
可是，只是我们部门内部使用的需求文档，就没必要这么精细了，只要能做好这件事情就行。但是，虽然是一句话需求，但还是有优化空间的，我们做不到整个文档规范化，但对这一句话的需求，可以规范化。
上面说的是 PRD 文档的规范问题，但其实，对于需求的整理，可以遵循需求的 INVEST 原则。需求的 INVEST 原则最早由 极限编程（XP）的倡导者 Bill Wake 提出。这一原则旨在指导敏捷开发中用户故事的拆分与编写，帮助团队更高效地管理需求，确保故事的可交付性和价值性。
INVEST 原则主要用于优化用户故事的描述，使其满足以下特性：
独立性（Independent）：故事之间减少依赖，便于单独开发和测试。
可协商性（Negotiable）：避免过早锁定细节，鼓励通过沟通逐步完善需求。
有价值（Valuable）：每个故事必须为用户或客户提供明确价值，避免资源浪费。
可估算（Estimable）：团队能评估工作量以制定迭代计划。
短小（Small） ：单个故事工作量控制在几天内，以降低风险。
可测试（Testable）：明确验收标准，确保功能可验证。
结合我们部门自身情况，需求来源其实很多的，所以可分为两种，一种是部门外，另一种是部门内，如果是部门外，需要加上角色；如果是部门内，角色可不加。可以简化为，是谁？要做什么？为什么？
这里就以设备管理功能，写一个示例参考：
深圳客户希望能看到自己有多少台设备，方便统计和日常维护。
- 是谁：深圳客户
- 要做什么：看到自己有多少台设备
- 为什么：方便统计和日常维护
通过这种方式，既能保证需求的清晰性和可操作性，又能在现有资源条件下实现需求梳理的优化，为项目的顺利推进奠定基础。