EdTech Thinking #12 - 与 AI 一起做产品系列之——需求文档

OCTO

Apr 28, 2023

摘要

本周话题：与 AI 一起做产品系列之——需求文档
文章：大学阶段的 Midjourney：人工智能创造的视觉表现
教育之美：终身学习之美

与 AI 一起做产品系列之——需求文档

系列链接：

（一）建立愿景
 （二）名为 SmartGloss

前文回顾

上一期与 AI 一同总结出了产品的愿景、目标群体以及名字——SmartGloss，并且，还让 AI 帮我描述了用户使用 SmartGloss 时的具体画面：

本期目标

原本在上期末尾提了这期是要开始画产品原型的，但在向 AI 咨询后，才意识到要先将目前的想法和需求整理成一份需求文档。其实，就个人开发一款产品的情况而言，没有需求文档也问题不大，甚至产品原型或 UI 设计稿都可以没有。但由于我的目的不只是完成这样一款产品，更重要的是在于学习如何利用 AI 工具来生产，所以经历产品生产的完整流程能更全面地体会 AI 所能带来哪些价值。

过程记录

我之前并未正式写过产品需求文档，当然，作为开发人员，接触过不少。通常而言，产品需求文档能够用来指导所有后续工作：项目管理、设计产品原型、UI/UE 设计、开发、测试。因为需求文档最重要的是描述了这款产品包含多少功能，以及各项功能的详细说明，我认为最有价值的就在功能的详细说明里。那在功能的详细说明里又包含哪些内容呢？

一开始，我尝试让 AI 直接根据我们之前讨论过的信息整理出需求文档：

显然，这样一份基本的需求文档，是无法指导其他团队进行后续工作的。假设 SmartGloss 是让产品、UI、开发、测试各一人的团队来生产，那么，基于这样一份需求文档，团队势必需要大量言语沟通才有可能对这款产品达成一个统一共识，之所以会这样，是因为需求文档中的功能描述不够具体造成的。

这次使用 AI 帮助我完成需求文档的过程并没有那么顺利，最终产出了这样一份，我觉得可以用来指导后续工作的需求文档：

Smartgloss 需求文档

641KB ∙ PDF file

Download

部分截图：

整个过程下来，我总结了部分经验：

AI 跟我对 SmartGloss 在大多细节方面的设想并不一致，他有自己的“想法”，但这其实是好事，因为我主要还是用 AI 来扩充我的思路，这种不一样有利于为我提供额外思路。
先自己思考功能的具体描述，再让 AI 帮忙补充，是一种比较好的方式。

没必要跟 AI 完全“同步”你的所有想法，更别想着让 AI 写出一份完全让你满意的功能描述，不然会降低整体效率。
要拆分功能，当然，也能让 AI 帮你拆分，再基于这一个个小功能去与 AI 讨论，会更容易得到合适的回答。

可以不用给出特别完整的提问，AI 其实也能“明白”。

总之，就我目前看来，人类还是作为思考的主体，AI 作为补充，是很好的合作方式。当然，与 AI 合作生成的这份 SmartGloss 需求文档，也还不是那么完善。前面我提到的：一个功能的详细说明都是些什么内容？我觉得就是功能的规则描述，例如：用户用鼠标选中文本后，该如何显示释义内容？自动弹出一个窗口显示还是先显示一个 Logo 再让用户点击 Logo 弹出窗口？Logo 显示在什么位置？Logo 何时消失？等等一些列细致的规定。通常来说，对于一个功能的规则，分为常规情况和特殊情况。多数需求文档，对于特殊情况下，功能该如何表现的描述可能偏少，但这大概率会导致后续团队的工作遇到问题，从而要与产品沟通确认才能解决。

需求文档中对功能规则定义的完善程度，对整个产品生产的过程和结果是具有直接影响的，特别是对于复杂的产品以及一定规模的团队而言。但要在需求文档阶段考虑到所有情况其实是很难的，常规的做法是通过试用其他产品的类似功能来完善我们产品的功能细节，再者就是参考软件产品功能通常会遇到的情况来定义规则，也依赖需求文档编写者的经验和对功能所处领域的了解程度。现在又多了 AI 工具来帮助我们完善需求文档中的功能规则定义，相信在产品研发的前期就能够考虑到更多方面的情况，从而定义出更详细的规则，减少后续因需求不明确导致的功能修改和返工，降低成本和风险。

以上就是本期全部内容，下期将利用 AI 工具进行产品原型设计和 Logo 生成。