然而人们的习惯是难以改变的,本人进入一家单位后,自己是从最底层的程序员做起,糊里糊涂编了一堆代码,到最后却由于当初设计人员的失误,这些代码后来又做了很多次改动,本人犹如在一个烂泥潭里打滚,实在有些厌倦.和我一同进入单位的一个人,一开始对此极其不满,和上司说了几次,但是头们觉得写文档是额外的工作量,只要程序开发出来,能够用就行了,很少考虑进一步维护的问题.然而我们却走了几次弯路,正所谓欲速则不达. ----先不要谈他们了，请问你现在CODing是否有流程图和其它文章吗？换句话说，如果找人接替你的工作，你认为他会很快上手吗？我觉得改进的方法就是让一小部人先动起来，然后带动一大部份人嘛。你找老总谈，不是不只是谈呢？如果有现成的资料，也许更容易打动老总。

　　其中一次是头们草草地决定上一个项目,而且觉得只要两个月就出来了,但是实际上半年后才开发完毕,但是开发出来的程序,一运行就需要占用大量的系统资源.根本无法推广到我们的用户那里(我们开发用的机器配置都很高,但面向的用户却还是386或486水平,遗憾的是他们设计时根本没有考虑到这一点).---软件的开发要涉及不同的角色，如果你的RD人员，那么你做的很对。因为这个问题应该由顾问提出，如实反映客户操作环境，以及对软件的要求。如果当时顾问没有起到作用，那么在开发过程中，项目经理也应该看到这个风险，加以处理。

　　另一次是一个比较简单的数据库应用,该程序仅仅是把一些收集到的一些信息全部显示出来,有一个人开发显示用的界面,另一个人开发录入信息的界面.然而由于一开始考虑得不够周到,经常发现库中缺少一些必要的项,于是又修改数据库的结构,每次结构的改变,都需要前台、后台程序做相应的修改.又是一堆烦琐的无谓的劳动.直到后来暂停下来,仔细地分析了各种可能变化的因素,才设计了一个比较好的结构,这已经一年时间过去了.--一般最头疼的就是改数据库结构，因为数据库一改，所有程序都要改。所以，一方面在计划阶段就应该把数据库的功能点以及弹性多少定下来，另一方面，真的有必要改数据库吗？举个例子，表1：学生编号，姓名，性别，出生年月等。开发过程中发现应该在基本属性表中加入“出身”项，那么再做一个关联：关联表1：学生编号，出身。这样就不完了？非得改成 表2：学生编号，姓名，性别，出生年月，出身呢？

　　本人在学校时,软件工程的基本概念是清楚的,但却没有什么经验,而且说实话,学校里很多知识是很教条的,实际中如何运用还是不太清楚,因此刚参加工作时,本人对于单位里如此无组织的开发持观望态度,然而结果却很令本人失望.于是我开始了行动,经过一番激烈的争论,本人列举了一大堆失败的事实,终于让顶头上司意识到无组织开发的效率低下,本人也终于成了技术部门主管。然而回首这段往事,不禁感慨万千,我初步估算了一下,从我进入该单位到现在,有四分之三的工作都是重复劳动,或者是无效的劳动. ---重复的劳动应该能提高效率。无论怎么重复劳动，都应该将变更记录下来，至少最后就知道是什么原因导致的“重工”吧。

Steve

对于做软件开发的，有一些作坊式的小公司的确没有软件工程的概念，以为这样的东西并不是想象那么困难，过于乐观，听了客户的想法后就马上写或者改代码。。。到后面无法收尾。。。这样的情形相信大家看的不少，象这样的公司，是不太可能有长远的发展的。

我想说的是另一种情况，在一些处于生存期的软件公司，为了生存，会答应客户非常苛刻的合同条件（比如：不可思议的工期），在这种情况下，就算有再好的软件工程理论或者大公司的工程经验，也基本上不能在这种场景下使用，往往是确定了项目的总范围和特性后，就简单设计后编码了。。。

有一个案例：一个朋友今年4月接了个软件项目，这个项目应该是一个项目群，下面有若干个软件项目和系统集成项目，但是公司的资源非常有限，一个两个人就支撑一个小的项目，而且工期压的非常紧（大约4个月，按照朋友的估计，至少要7个月）。。。基本上是一个死亡项目。这个朋友曾经在大公司中很规范的按照软件工程做事，做项目中间，这个朋友经常和老总在做法上发生冲突，老总说他太理想化，应该在质量，范围上降低优先级，把进度放在第一位。。。这种说法也有道理的，所以他就控制了一个关键的文档（比如：数据模型文档；项目范围/特性文档），需求分析很快就过了，设计也很快就过了，跑步进入编码，质量可想而知。。。他感觉很郁闷。但是现实就是现实啊。。。。

One Aim,One God,One Life. || 最爱:偶家阳阳 || 博客:愚人camer || MSN:camellxr@hotmail.com

4个月还是7个月的工期？这应该由项目全部成员决定吧。如果老总要压缩周期，就要加人手。不是靠减少质量等级与缩小范围。

也许我的观念有点不对。在这种情况下，我认为写文档只是辅助作用。应该抓紧做现场开发。让RD参与调研，能快速进入状况。这也是赌一赌呀。嘿嘿

Steve