敏捷时代，需求文档应该这么写
作为产品经理，需求文档（Product Requirement Document，简称 PRD）是一份很重要的交付。从立项那天开始，就需要一直维护。而这份最多可达上百页的富文本文档，不仅消耗了产品经理的大把时间，也杀死了项目组其他同事不少脑细胞，最终成为一份「重要但难维护难阅读」的「剩典」。
有没有想过「敏捷 PRD」？就像风靡全球的敏捷开发那样。事实上，这是非常值得一试的方法。Teambition 简洁好用的看板界面，不仅完美的支持「敏捷开发」，也完美的支持「敏捷写需求文档」，我们且称之为「Scrum PRD」。这份「Scrum PRD」，较之传统方法，有非常明显的优势：
一、线性思路 vs. 先框架再细节
这并不是说所有产品经理写文档的思维方式都是线性的，而只是针对类似文档（word）等文本编辑工具的特性而言，这些工具本身是强调叙述性的。当然你也可以借助一些脑图工具或大纲工具来帮助构思。
而 Teambition 看板工具，则天然的具备从框架到细节的优势，其本身充分体现了彼此独立又紧密相连的对象间的关系。而我认为，这种关系就是一个大产品中各个功能之间的关系。
二、一个人的战场 vs. 多人协作完成
一份文档格式的产品需求文档（PRD），往往跟该产品经理的叙述思路紧密关联，第二个人很难介入，所以基本都是一个人单枪匹马维护。
而看板式的功能列表，就像去除了冗余修辞和转承的动宾短语，让每一个人都能低成本的获取核心信息，也就使得每个项目组成员均可添加缺失的「动宾短语」（一个功能）在列表中，或者补充某一个「动宾短语」（一个功能）的功能说明。Teambition 使得利用团队力量完善需求文档（PRD）成为可能。
三、阅读者的迷失 vs. 阅读的逻辑性
传统形式的需求文档（PRD）就像一份长篇大论的说明文，虽然有目录结构帮助理解全文框架，但交互并不友好。而看板形式的功能列表，既让阅读者清楚了解「每一期迭代的计划」，也可随时随地在看板页面看整个产品的布局和思路，在具体任务页面看单个功能的细节设置。清晰的逻辑保障了阅读者获取信息的完整性和有效性。
四、局部更新 vs. 单个功能独立版本管理
一份文档形式的需求文档（ PRD），如若要更新，首先需要在文档中先找到相应的板块，然后更新内容，并且在前页标出「更新时间、更新内容」，大至功能逻辑的更改，小到文案的微调，操作上都是繁琐的步骤，并且项目组成员阅读成本也非常高。而功能列表的看板，则只需找到需要更新的任务，直接编辑内容，并在列表中标记好「最近更新时间」即可，并不影响其它功能。这样的方式，在每个功能都有相应开发拥有者的情形下，优势非常明显。
那么，整体而言，用 Teambition 撰写需求文档，到底有哪些好处呢？
1. 从框架到细节，从用例（Use Case）到功能
框架是指整个产品的骨架，Teambition 的看板设计能够很好的呈现出框架形态；而细节则是对于每一个功能的具体描述，Teambition 的「任务」能够清晰的承载项目细节，让项目参与者读懂需求。
2. 利用分组来管理项目分期
在 Teambition 上能够轻松对项目进行分期管理。同时，任务看板的设置能够保证「上下文」完整和过程可追溯，任何变动都「有据可循」。
3. 团队协作，不再是传说
协作使我们能够达成更加了不起的目标。利用 Teambition，撰写需求文档（PRD）这件事，也变得可协作。项目中的多名产品经理或产品设计师，可共同完善功能列表及描述。项目成员随时补充遗漏的板块，并指派给产品经理完善。项目成员对于单个功能有任何困惑，也可以在「任务」的评论区域进行讨论。
4. 阅读者的安全感与逻辑性
Teambition 的层级设置使敏捷需求的呈现富有逻辑， 当期项目范围及优先级一目了然。项目成员可轻松查看整个产品的思路布局以及细节设计。
5. 获取更新信息简单方便
Teambition 能够呈现出每一处细小的更新，更新内容一目了然。
6. 根据开发情况更新需求文档（PRD），不再痛苦
当需求发生变动时候，项目参与者可以直接在 Teambition 中针对单个功能直接更新，不影响其它功能。对于无法完成的功能，直接移到下一期，保证项目范围的准确与实时。
当然，更不用担心存档问题。既可以直接以项目的形式存档，也可以导出数据上传公司知识库（wiki）。
