一个需求镀金的教训

一个OA项目，原来的需求文档已经面目全非了，得益于版本管理，找到了需求差异分析前的最后一个版本：
---------------------------------------------------------------------------------------
3.1.2.6. 安排其他用户日程
 用户在查看同事日程安排页面中点击“添加日程安排”按钮
 系统显示日程安排添加页面
 用户选择时间，填写事务详情，预计需要时间，选择事务类型，是否公开
 用户点击“提交”按钮
 系统检查时间冲突
  时间上没有冲突
   系统记录新事务
   系统显示操作成功页面
  存在时间冲突
   系统提示存在冲突的事务，提示是否修改事务
    用户确认添加
     系统记录新事务
     系统显示操作成功页面
    用户选择修改事务
     系统返回到日程安排添加页面
---------------------------------------------------------------------------------------

写完这个版本之后我出差去做需求差异分析，其他同事则按照暂定的需求文档开始做编码（时间紧迫，设计被跳过了，后来的设计文档都是从

代码反向工程处理的）。

在我出差期间，有个同事提出了，一个日程安排在某些情况下应该可以指派给多个同事，因此产生了一个“日程草稿”的概念，即一个日程可

以先起草然后再反复指派给多个用户。负责开发这一模块的兄弟们觉得大有道理，于是照此开发。

出差回来后我更新了需求文档，但是这一部分用户并没有提出异议，因此没有修改。直到上周开发基本完成，这周一开始做SIT。这时我才发现原来我现在要安排一个日程的话一定要先起草一个“日程草稿”再把它指派给自己或者别人。这就好比我要发个email，就要先写个email保存到草稿箱里面，再去草稿箱里面把它找出来发。

这当然是不能接受的，于是要求兄弟们按尽可能少的修改工作量进行修改，也就是说把保存草稿再取出草稿这个过程包装起来，自动保存后直

接指派出去。但是由于检查时间冲突并做出响应的流程并不是为草稿设计的，不得不修改了流程、设计并重新编码。今晚和兄弟们一起加班修正这个问题，希望明天可以开始SIT.

“一个日程安排在某些情况下应该可以指派给多个同事”是一个没有被确认的需求镀金，在没有被仔细考察的时候就轻率的被依以设计，造成了今天的困境。