【IT168 技术文章】
知识份子用非常先进的途径传播非典性肺炎的恐慌。
也许在起“没头没尾”这个名字的时候已经有了预感，我并没有在项目中坚持到最后，而是在项目完成之前离开了这个项目。项目由负责客户端设计开发的同仁接手担任技术经理。几个月的开发经历给我带来了很多的想法，很多的收获。写项目开发笔记的过程也让我认识了很多好朋友。这是最后一篇项目开发笔记，主要说的项目小组在选择项目开发语言心态中的一些变化。这里记录下项目小组对所采用的技术心态的三个变化。
技术心态的三个阶段
由于对应用新技术项目小组成员的心态产生了很多的变化，为这些变化我们也付出很大的代价。首先是对技术的心态变化直接导致项目小组成员工作心态的变化，然后是对技术的心态变化影响对项目中其它一部必须完成部分的投入，最后是影响了我们的项目的进度。也许把一些问题归罪去心态不好，或是归罪于心态的变化，并不完全正确。可是我想可以通过总结减少这些心态的变化，使得每个人可以在项目中调整好遇见问题时自己的心态，从而对项目相关的事情做出正确的判断与处理。
项目小组对采用新技术开发项目心态有过三个阶段，可以说这三个阶段的出现是很有代表意义。下面是对这三个阶段的描述。并且说明心态的变化分别给项目带来什么样的正面负面的影响，以及对项目成本的影响。
1.狂热
项目初期对应项目之间制作了一些DEMO。并从资料与DEMO中得出了将要采用的方式（可以参见以前的项目开发笔记）。可以说这个时期项目小组的成员为这个技术框架的建立激动不已。大家集中了很多的热情在进行对项目模式的讨论，并且做了很多的实验，大量的DEMO。为项目以后的发展打下了一定的技术基础。
好处
1.参与的项目小组成员从广度上了解项目技术框架，为日后的开发打下一定的技术基础；并使各个项目小组成员很快的进入角色。
2.项目小组中决大部分成员只有VB之类的基础，而对基于DOTNET开发的技术不熟悉。通过这种狂热，使得项目小组成员很快的熟悉了这种新的开发工作与开发方式。
坏处
1. 广泛的去制作DEMO使得对技术的框架的研究出现一种不求甚解的风气。具体的来说就是很多时候天天讨论FACADE，天天讨论最终应该把系统划成几层。而对效率，安全性，例外的处理之类的框架设计中要考虑的东东放在了后面。也就是说，对技术框架的狂热让我们对工作时间，工作重点的分配产生了混乱。
2. 需求与设计被放到了一个次要的位置。由于我本人对业务情况并不是很了解，所以我并没有去与项目小组的成员一起去将需求进行详细的考证，以及变成设计。而是只从我的角度对需求进行了最粗粒度的划分，可以说是对后来项目的进展没有起到任何作用。这个在以前的文档中也有描述。
3. 仅从DEMO得出项目的可行性分析，而没有得到开发的可行性分析。导致项目在初期走过了很多的弯路。
综合上面所说的好处与坏处，我的体会是项目开发过程中出现了好的因素也要保持清楚与冷静的头脑。始终以项目本身为思考的出发点与归宿。不是项目中所有的人都在狂热的工作与研究就是好事，而是应该具体的去考虑对项目的发展有没有好处？
2. 失望与沮丧
项目的中期，由于对应开发方式进行变化（主要是指客户端采用DELPHI进行开发）的准备并不是很充分。特别是开发方式的变化与适应的时间太短。对两种语言通过Web Service进行接口的问题思考与准备并不充分。所以虽然我们的方案具有很多的优点，可是对应的开发过程却显得非常的艰苦。由于开发效率的低下，项目的时间又非常的紧，加上又有个别项目小组的成员在开发过程中不断的宣传从时间的因素上来看不应该用这种新的技术来进行项目的开发。导致从对技术框架最初的热情很快的转到了对项目所采用技术非常的失望与沮丧，很多的项目小组成员都认为我们做一个错误的选择，并将项目的延期之类的责任都推到了这个原因上。
我感觉对这个事情的处理上体现的非常不成熟。我并没根据项目小组成员在不同的时期所出现的心态进行自己的分析，以及找出方法对应进行调整。在上一个阶段，我是狂热分子而没有清醒的意识，在这一个阶段，我也成为了一个失望者与沮丧者，并没有去仔细分析情况出现是由于选择开发方式的错误还是由于对开发方式研究的深度不够。这种全面的失望与沮丧的情绪对项目的影响是巨大的，我们的开发效率变的低起来，我们也不再为项目本身而感到骄傲。直到进入下一个心态阶段。值得庆幸的是，虽然这个时期有失望情绪，但我们还是坚持了当初定义好的开发的规则。对于定义出的技术框架还是坚持了下来。
3. 平淡与麻木（体会到非常好的选择）
项目的最后时期项目小组成员对对项目使用什么样的技术已经不再关心。也就是说，可以用一种比较正常或麻木的心态来看待技术问题。通过仔细的考察项目本身所具有的特点可可以得出以下的结论：
1.本项目必须采用Web Service的方式来完成这个项目
2.项目选型时，开发web service
