研发管理

img emu

一个需求镀金的教训

发表于2004/10/25 20:28:00  2272人阅读

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

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

代码反向工程处理的)。

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

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

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

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

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

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

阅读全文
0 0

相关文章推荐

img
取 消
img