夜雨聆风学习资料网

ARTICLE · 1113614

AI写的需求文档含糊,是它把你没定的事写成了通顺的句子

AI写的需求文档含糊,是它把你没定的事写成了通顺的句子

接定制开发已经十几年了,这两年收到的需求文档明显变得很美观了。排版整齐、分点清楚、每一段都是完整的句子,读起来很有条理。

但是拿到手之后的第一件事情通常并不是排期,而是回头去找写这份文档的人,并且问他一系列的问题。

例如:优化搜索模块的用户体验,使搜索结果更加智能、精准,提高用户的满意度。

每个字我都认识,但是这句话我没法动手。

什么是智能呢?联想要不要出现?会出现几条呢?是从哪里获取信息的呢?输入一个字就可以得到结果了,还是两个字才得到结果呢?一条都没有匹配上的时候,是留个空框还是干脆不显示呢?

这些都是要写到代码里面去的决定,没有一个。

这句话的作者一般情况下文笔是不错的。他是还没想好要什么,然后让 AI 帮他写。AI 就把他没想好的那部分,写成了通顺的句子。

AI在文字上的能力最强,但这也是它在协作中最大的风险。

给它一句“做一个更智能的客服系统”,它可以还你三千字,标题层次分明,每一部分都像模像样。

它不会停下来去问你到底想要多少条、要多长时间、失败了怎么办,做错了返工的又不是它。

你没有决定的地方它无法填补,就用一个形容词来覆盖掉,覆盖得很自然。

含糊就这样被包装成了专业。

Part 1

另外一种含糊是故意为之的。

并不是不会写具体,而是不敢写具体。

写清楚就等于把话说死了,以后做的不对,责任就在自己身上。写成优化体验、更加智能,怎么做都能算数,怎么做也都能挑毛病。

在这一层模糊之中是有保险的。

在自己的公司里我一直都是这样讲的,你想什么就说出来吧,能给你的就给你,不能给的我会说明原因。

要什么不说清楚、等着别人猜,这样的毛病很常见。

放在需求里完全一样:你不写清楚,做的人就只能猜了,猜错了还要返工,而返工的成本最终还是要由你承担。

Part 2

那到底怎么改。

我的做法是,拿到一份由AI写的需求稿子之后,并不急于判断它写得怎么样,而是逐句地只问一件事:做的人能不能按照这句话去做。

能的话就留下,不能的话就不是需求,而只是感想。

留不下来的那些,分成三部分。

第一种是用户的操作行为。

谁在什么地方做了什么事情。输入了什么、点击了哪里、从哪个页面进入的。这部分一定要是能够看到的行为,并不是心理活动。

"用户希望快速找到商品"并不是用户的操作行为,"用户在搜索框中输入两个字"才是。

第二点就是系统的反应。

当系统接收到这样的一个动作之后会怎样做、会给出什么、会在多长时间之后给出答案,在没有给出答案的时候又会有什么样的表现。这部分要带有具体的数字以及边界条件。

最容易漏掉的地方就是失败路径:没有搜索到怎么办?超时怎么办?输入的全是空格怎么办??

真正让人返工的很少是主要流程,多半是这些角落。

第三点才是重点,也是大多数人不会写的:还没有决定的事情。

很多人认为需求文档中不能出现未定,一旦承认有未定就显得不够专业,所以用漂亮的空话把未定遮住。这是错误的做法。

一份真正的可以用来交流的需求文档,敢于写出“此处我没有确定”这样的内容。

写作方法也很简单:把没有确定下来的那一条单独列出,并且要写清楚是谁来决定、什么时间决定、在决定之前先按照哪个方案往下做。

这样对方就可以开工了,而你也没有把话说死,而且是明着没说死,不是偷偷没说死。

把开头的那一句话按照下面的方式修改一下,大概就是这样的:

用户动作:用户在搜索框中输入内容,不会点击任何按钮,并且会在 0.5 秒之后自动弹出联想。系统响应:联想最多八条,来源为最近三十天内有过交易的商品名称。输入不足两个字不给出联想结果。没有找到匹配的结果时不会出现联想框或者空白面板。还没有确定的是:联想里是否要带价格我还没定,在设计稿出来之后再做决定,本周五之前给出答复。在此之前先按照不含价格来处理。

这是为了说明写法而编造的一个例子,并不是某个真实项目的需求。

但是你对着数字一数,修改之后的字数并没有增加很多,而承接这个工作的人员已经开始可以开工了。

另外一层意思就是把观点变成事实。

体验不好是观点,从点提交到看见结果要等8秒是事实。

你说体验不好,对方一定反驳你,他会说哪里不好、我觉得挺流畅的。你说要等8秒,他没有反驳的能力,只能问你想要等多久。

只讲事实不讲观点,在生活中管用,在需求文档上更管用。用观点来提出要求,那么你就需要把话说重一些才行,而当你夸大了事实之后,对方自己就会进行反驳。

而需求文档带来的反驳不会在当时发生,它会在验收的时候出现,在东西做好之后,对方才会说这不是他们想要的。

顺便提一下一个比较常见、但其实改错了的方向:把含糊的地方改得更长一些。

有人一听要具体就将三千字扩到八千字,每段加限定词、加背景、加目的说明,这样读的人就会更加疲惫了,并且问题并没有减少。

含糊的反面就是可以执行,和字数多少没有关系。

评判的标准只有一个:对方看完之后还要再来问你几次。少问一次就说明改对了,一次都不用问就是写到位了。

这两年我自己也坐在了写需求的那端。我现在同时有四五个项目让AI来写代码,天天给它下达需求。

同样的道理反过来也一样成立:我用含糊的语言去描述我的需求,它并不会来问我,它会自己选择一个最常见的方式来实现我的需求,并且在验收的时候我发现方向错了。

跟人协作时你还能指望对方来问一句,跟 AI 协作连这一句都没有。所以我给 AI 写需求,比给人写还要具体。

最后要说的是和我自己做的东西有关的。我做的是一款可以降低AI味的软件,每天都有人拿来各种稿件来问我能不能修改。

遇到需求文档这样的情况时,我会先说明一下:它改的是AI味,即从用词、句式、段落结构和行文节奏那一层来改变,使一段机器腔的文字读起来像人的文字一样。

但是它不能弥补你没有做出的选择。你没定联想要出几条,它不会替你决定,只会把那句话换个说法,还是空的。

信息缺失和语感僵硬是两码事。前面所说的那些,要靠自己去补充。

补充好了之后,如果整篇文章读起来还是有拼接的味道,同事们一眼就能看出是用对话框复制过来的,那么这就算是它应该做的事情了。

在和别人进行沟通之前,自己要先整理好自己的思绪。

如果脑子里理不清楚,那么就可以先用文字把思路表达出来,然后再删除那些不必要的话语,直到对方一看就能明白你想表达的意思,以及需要他做什么。

把话说清楚也是一种对人的尊重,总比絮絮叨叨地说一大堆话要好得多,没有一个关键词,让人反复回来跟你确认。

AI 能帮你把话说得通顺,替不了你去想。需求文档到最后的时候,拼的就是你是否真的完成了这些决定。

相关学习资料