第4章需求文档撰写

第四章：需求文档撰写——用户故事编写、业务流程文档（BPD）、异常处理规则定义、验收标准制定

好，咱们进入第四章。说实话，很多RPA项目死就死在需求文档上。不是技术不行，是需求没写明白。我见过太多团队，开发两周，改需求改三周。嗯，今天咱们就把这块彻底讲透。

用户故事，说白了就是一张“小卡片”。它不复杂，但特别容易写歪。我个人的习惯是，用三句话搞定：

举个例子，财务部的张姐每天要手动下载银行流水。她的用户故事可以写成：

作为：财务部对账专员
我想要：每天早上8点自动登录网银，下载前一天的流水文件
以便：我不用每天花40分钟重复操作，能腾出时间做账务分析

你看，这样写，谁都能看懂。但这里有个坑——用户故事不能太“大”。我曾经遇到一个项目，业务方写了个“我想要一个智能财务机器人”。这哪是故事，这是史诗。得拆，拆成“登录网银”、“下载流水”、“解析Excel”、“写入系统”这样的小故事。

我的小技巧： 写用户故事时，让业务人员用“我”开头。一旦他们开始说“我们部门需要”，你就得警惕了——这很可能是个模糊需求。

用户故事是“做什么”，BPD是“怎么做”。我习惯用泳道图，因为角色清晰，责任明确。你想想看，一个流程里，系统做什么、人做什么、机器人做什么，全在一张图上。

画BPD时，我一般遵循这几个原则：

我记得有一次，团队画了个BPD，密密麻麻全是线。业务方看了半天说：“这跟我实际干的不一样。”为什么？因为画图的人把“理想流程”当成了“实际流程”。所以，BPD一定要和业务人员一起画，你画一笔，他确认一笔。

  避坑指南： 我曾经见过一个项目，BPD画得特别漂亮，但开发到一半发现，有个步骤业务人员自己都说不清楚。结果返工了两周。所以，BPD画完后，让业务人员“走一遍”，用嘴模拟操作，看能不能走通。

RPA最怕什么？不是跑得慢，是跑着跑着卡住了。异常处理，说白了就是“如果出错了，机器人该怎么办”。我一般把异常分成三类：

这里有个关键点：异常处理规则必须和业务人员一起定。为什么？因为有些异常在技术上看是“错误”，但在业务上可能是“正常”。比如，银行流水里出现一笔负数，技术上可能报错，但业务上知道那是退款。

注意： 别把所有异常都交给机器人处理。我曾经犯过这个错，让机器人自动处理所有异常，结果它把一笔错误的退款当成正常数据提交了。后来我学乖了——拿不准的异常，一律交给人工。

验收标准，是项目交付的“尺子”。没有这把尺子，开发说“做完了”，业务说“还没好”。我一般用“Given-When-Then”格式来写：

Given（给定）：系统中有10笔待处理的报销单
When（当）：机器人执行报销处理流程
Then（那么）：10笔报销单全部处理完成，状态更新为“已提交”，且无报错

验收标准要满足三个条件：

我个人的习惯是，在验收标准里加一条“异常场景”。比如：“当网银系统宕机时，机器人自动重试3次后发送告警邮件，并暂停执行。”这样，业务人员就知道，机器人不是万能的，但出了问题有人知道。

一个小建议： 验收标准写完后，让业务人员用“如果...那么...”的句式读一遍。如果他能读通，说明标准写清楚了。如果读不通，那就得改。

文档写完了，不是扔给开发就完事了。我一般会做三件事：

嗯，说到版本管理，我吃过一次亏。项目上线后，业务说“这个功能不对”，我一看文档，发现他们用的是旧版。从那以后，我要求所有文档必须标注“最后修改日期”和“修改人”。

好了，第四章就到这里。记住一句话：需求文档不是写给机器看的，是写给人看的。写清楚，写明白，项目就成功了一半。