2013年6月工作小结-- 再论需求与设计,别总去跑马拉松
2013-06-30 10:18
281 查看
理论上来说,在项目终验前,整个开发团队会变得相当轻松,甚至有点无所事事的感觉。然而,总有个别的Team会打破这个规则,来证明软件开发世界里同样存在着多样性与特殊性。比如我们的项目,它就像一场马拉松赛跑,你从头至尾都不能松懈,否则就只能面临淘汰。
跑一场软件开发世界的马拉松是很多开发人员梦寐以求的事情,我们是幸运的,也是悲催的。幸运的是我们有机会跑一场像样的马拉松,并且跑完了全程。悲催的是我们选择的赛道并不那么平坦。世界上没有十全十美的事情,也就没有十全十美的项目。面对项目,我们必须坦然,也要释然。
尽管我们已经进入项目验收的末期,但我们却依然不能放缓前进的步伐。因为我们不是在修Bug,我们在处理客户的新需求。这是在项目中经常会出现的情况,也称之为补充合同。这里面包含的内容主要就是需求变更和需求扩展的内容。如果需求一直在动,那么开发人员就要一直忙个不停,这也就是我们长期处于马拉松赛程的原因。
在处理需求时,经常是需求改动,开发人员行动,这是很正常的事情。但是如果发生了需求小改动,而开发人员有大行动时,这就说明了项目发生了问题,至少是在设计上出现了问题。一个良好的系统设计,应该能应对一定范围内的需求扩展。
在实际获取系统需求和制定系统设计时,由于客户在IT方面的不专业,导致他们对于系统的描述不精确,需求人员捕获到的需求也就不全面。而设计人员出于时间、范围等因素的考虑,往往做出最简易的设计,以便尽早交付。这就导致了客户在验收过程中,会提出种种问题。为了解决客户的问题,就必须修改设计。
![](http://img1.51cto.com/attachment/201306/101647718.png)
![](http://blog.51cto.com/e/u/themes/default/images/spacer.gif)
其实,客户对于系统的挑剔性(简单、易用、响应快)就和我们对于各种工具的挑剔性一样。我们总是满世界里找适合自己的工具,并对这些工具吹毛求疵,因为我们是这些工具的客户。我们才不管这个工具在设计上有多复杂,我们只需知道这个工具能不能满足我们的需要即可。
作为IT系统的设计人,应该多为客户着想,多为开发人员着想,将系统设计的更灵活一些,别总让大家去跑马拉松。
本文出自 “这个人的IT世界” 博客,请务必保留此出处http://favccxx.blog.51cto.com/2890523/1235694
跑一场软件开发世界的马拉松是很多开发人员梦寐以求的事情,我们是幸运的,也是悲催的。幸运的是我们有机会跑一场像样的马拉松,并且跑完了全程。悲催的是我们选择的赛道并不那么平坦。世界上没有十全十美的事情,也就没有十全十美的项目。面对项目,我们必须坦然,也要释然。
尽管我们已经进入项目验收的末期,但我们却依然不能放缓前进的步伐。因为我们不是在修Bug,我们在处理客户的新需求。这是在项目中经常会出现的情况,也称之为补充合同。这里面包含的内容主要就是需求变更和需求扩展的内容。如果需求一直在动,那么开发人员就要一直忙个不停,这也就是我们长期处于马拉松赛程的原因。
在处理需求时,经常是需求改动,开发人员行动,这是很正常的事情。但是如果发生了需求小改动,而开发人员有大行动时,这就说明了项目发生了问题,至少是在设计上出现了问题。一个良好的系统设计,应该能应对一定范围内的需求扩展。
在实际获取系统需求和制定系统设计时,由于客户在IT方面的不专业,导致他们对于系统的描述不精确,需求人员捕获到的需求也就不全面。而设计人员出于时间、范围等因素的考虑,往往做出最简易的设计,以便尽早交付。这就导致了客户在验收过程中,会提出种种问题。为了解决客户的问题,就必须修改设计。
![](http://img1.51cto.com/attachment/201306/101647718.png)
![](http://blog.51cto.com/e/u/themes/default/images/spacer.gif)
其实,客户对于系统的挑剔性(简单、易用、响应快)就和我们对于各种工具的挑剔性一样。我们总是满世界里找适合自己的工具,并对这些工具吹毛求疵,因为我们是这些工具的客户。我们才不管这个工具在设计上有多复杂,我们只需知道这个工具能不能满足我们的需要即可。
作为IT系统的设计人,应该多为客户着想,多为开发人员着想,将系统设计的更灵活一些,别总让大家去跑马拉松。
本文出自 “这个人的IT世界” 博客,请务必保留此出处http://favccxx.blog.51cto.com/2890523/1235694
相关文章推荐
- spring MVC工作机制与设计模式-读后小结(一)
- spring MVC工作机制与设计模式-读后小结(二)
- 《火球——UML大战需求分析》(第2章 耗尽脑汁的需求分析工作)——2.5 小结与练习
- 2013年6月工作小结-- 终验前的忙碌
- 需求与设计人员如何配合工作
- 2013年5月工作小结 -- 源源不断的需求变更与Bug
- 2013年5月工作小结 -- 需求变更与Bug
- 小结:实例解析DAO设计模式工作流程(无框架)
- 工作流程引擎挂起的需求与设计
- 工作流程引擎回滚应用场景与设计需求
- spring MVC工作机制与设计模式-读后小结(三)
- 《火球——UML大战需求分析》(第2章 耗尽脑汁的需求分析工作)——2.5 小结与练习
- API设计的基本工作流程及需求分析
- 2013年6月工作小结-- 项目终验前的忙碌
- 需求与设计人员如何配合工作?
- 翻旧账,自己参加工作一年时写的设计文档
- [工作中的设计模式]享元模式模式FlyWeight
- 一个特殊需求的环形Buffer设计
- 数据库设计 Step by Step (5)——理解用户需求
- 设计师和开发人员更快完成工作需求的20个惊人的jquery插件教程(上)