99年开始跟着三五个人的团队到现场开发，那时候的开发还是小作坊式的，没有什么框架，一堆老程序，完了在老程序上进行修修改改。一到现场需求总是源源不断，层出不穷。需求分析的重要性也是那时经历过无数次阵痛后铭刻在心里的。几个大项目，没有一个是漂漂亮亮的拿下的，贵州中试院的mis系统，一年多才勉强验收，一直都在想，什么时候能干净利落地几个月拿下一个项目。那时候跟随的团队，还进行的是面向过程的开发，一些基础的类也是在工作中缓慢积累着，大部分时间都还要新写很多公用的东西，比如日历，比如上传等，好像那时候网上没这么多现成可用的东西，或者是自己没怎么去找，这样就可想而知开发效率了，除此之外还要疲于完成各种各样的需求，整天都在加班，没下班时间，没周末，更没时间学习，没时间进行技术储备，最终的结果确是还是有好多需求没完成，而自己的技术积累也是少之又少，努力了并没好结果，这个恶性循环本身说明了一定是哪里出现了问题。
现在想想，可归纳成如下几点原因
1、需求分析不到位：一份好的需求分析，应该作为整个开发和验收的蓝本、依据。需求分析要细到页面如何排放。需求分析还能达到成为测试中的实现目标的范本的作用。需求细化是需求分析的重点，需求的梳理是需求分析的另一个重点，而需求的确立成为了需求分析中的一个难点和重点。什么样的需求是值得实现，什么样的需求是可以忽略，这个问题是要业务部好好考虑的问题，但往往业务部根本就没办法进行判断，因为有些需求是带有引导性的，是要有一定预计性的，预计性的东西谁又能说个准儿呢。
2、团队的技术储备不到位：新技术的研究，学习，熟练运用这是需要相当一段时间，技术层面的问题本身解决起来也是耗时的，如果把这些时间掺杂到项目正式开发期里，那么会占掉相当一部分时间，或者还有可能因此最后让这个项目成为不确定项目而无法进行控制。所以项目开发前掌握，熟悉所有技术难点，项目开发过程中只专注业务逻辑的实现，这样项目开发周期才有可能会大大缩短。
项目的顺利完成是项目团队的基本目标（而对于我们这样支撑部的开发组而言，我们这个开发团队的基本目标就是给业务部提供好的软件产品，好的技术支持）要保证项目顺利完成要注意以上两点，那么第二点，技术储备对团队来说就应该是一个硬指标了。一个好的团队就一定要有学习新技术的机制。而且这不应该是工作以外去做的事情，它应该成为每个技术员必需的工作才对了。除开这个硬指标外，我理想中的技术团队还应该是：有个相对全能的人,我的大多数问题都能解答（或许我这个想法太奢侈太懒惰，呵呵），有着深厚友谊，亲密无间（或许又是个奢侈的想法，现在工作利益关系，同事间都没有真正的朋友，但我真觉得这个是性格关系，真正的朋友也可能在工作中遇到。）。。。还有什么呢？暂时想不出了。今天就到这儿吧。