今天早上临下公车时，无意间看到报纸上的大标题：软件工程师--用改变拿着高薪。我还够不上“工程师”这个称呼，也够不上“高薪”，但
“改变”两字确是我们时刻所面对的。大项目我没做过，小项目倒是做过几个，所以以下所写的个人想法纯粹针对小项目，特别是拖着时间的，带着领导的小项目。
记得有一次在学校做项目时忽然有一个感觉：写代码的速度跟不上需求的变化。着实让那时的我吃惊不少，照这样项目永远都完成不了。后来就去找我们的指导老
师，我们的想法是，需求就应该是先定下来的，然后按照定好的需求再一步步做：分功能，建数据表，提取公用的函数，代码。然后画界面写业务，最后测试。项目
完成！其结果是被指导老师深刻教育了一翻，说些什么已不记得了，但心中却甚是不服的。 那时的想法多么美好，现在看来简直就是痴人做梦。
昨天又一次结束了向领导汇报项目的工资。有些小想法，就摆这写写。小弟做的是政府项目，一切需求领导说了算，什么时候说了什么时候算，过了这村到下个店，换种说法，那得按店里的说法。
今天小领导A说这样，明天大领导B说那样。后天A一看：不对啊，我不是让你这样的嘛，你看现在这个不符合要求。于是我怯生生的接上一句话：B长说要这样。
那小领导一听，竖然起敬：对，这样是更好，更全面。此时的我除了纳闷就剩不下什么了，只能用经理的以句话磊排解下心态的郁闷：领导的心思你别猜，你猜来猜
去也猜不明白。手中拿着汇报以后的会议记录--也就是项目的新需求和修改，郁闷了：怎么每次都有这么多的不符合领导要求的地方，汇报前可是仔仔细细对过上次的会议的记录的。其实郁闷也就这么一下而已，俗话说：习惯成自然。放在此时也未尝不可。
话归正题。软件开发中，永远不变的是“改变”。
既然改变是不可避免的，那么最理想的情况就是开发的程序能随时应付任何的变化。这其实是另一个痴人的梦。没法完美，那就只好退求其次，一段时间接受任何的
变化 或者 随时应付部分的变化。前者就是项目的需求分析阶段了，项目还没动工，至少业务相关部门还没开始，只有此时猜能接受任何的变化
。:）后者才是应付随时改变的需求的有效措施。所以一个项目的好坏，经的起多少需求变化是一个很重要的判断标准。
另：说说我认为的项目成功与否的想法：
1、客户（发起这个项目的人或组织）是否满意？
2、参与项目的人是否对整个项目满意？
3、项目是否达到了预期的效果？
4、项目经的起多少需求变化？
5、写程序的人是否对自己写的那部分程序满意？
6、用户（用这个系统的人）是否满意？
第4、5、6条3条往往是被遗忘的部分。也不是一个项目交付使用的必要条件。但我认为这其实也是非常重要的。第4条是证明一个项目能否经得起考验的一个条
件。第5条，如果说写程序的人自己对自己写的都不满意，这个项目肯定还是可以改进的。第6条，应该说是用户体验的问题，是否满意并不指界面是否漂亮，还包
括用户习惯，给用户的心理感受（比如做一个长时间操作时，一般都会想到放一个进度条，显示完成时间。如果在超过了预计的时间呢？经常遇到进度条都到了
99%，这剩下的1%却花了那99%的好几倍时间。是否想过在超出预计时间后显示：实际执行时间比预计的要长，很抱歉给您带来不便）。
就这样吧。我也不知道写了写什么。各位看官，能看就看，不能看也欢迎丢砖。
:) 