英国哲学家培根曾经说过，时间就是金钱，时间就是力量，时间就是生命；也许在其它地方它有着更深刻的含义，但是在项目开发中，我更体会出了一种无奈！
目前，我们国家大多数的软件公司，都有着极不明确的项目开发计划，大多都围绕着短期的市场需求转，因为它直接关系着老板的腰包，很少有经过长时间的市场调研的。于是，当市场开始需要什么东西时，大家一窝蜂的都去做，很少有人能够静下心来和用户仔细交流沟通，原因就是时间太紧，他们担心这段交流沟通的时间会延迟项目的开发时间，会被其它公司占领先机；因为，就像有的程序员所说的，我们根本就不知道客户究竟想要什么，因为客户他自己就不知道自己想要什么。他们争着看谁在最短的时间里能够拿出一点东西，即使用户有一百个的不满意。然而老板认为这样他们就抢占了先机，就能够拿出来作为同用户进行谈判的筹码，也不管它的性能的优劣，然后就把推销的光荣而艰巨的任务丢给销售或业务人员，市场的占有份额完全靠这些人员的推销能力，也不管他用什么途径，至于以后的问题嘛，以后再慢慢说。于是问题就逐个暴露出来了：
由于为了抢占市场，需要尽快地制定一份需求分析说明，但是这份需求并不是较为完善的（当然了，在没能达到用户的满意之前，也不可能有百分之百的完善，因为众所周知的原因，客户的需求是不断的变化的。我们这里说的是尽可能的完善），因为我们并未同我们诸多的想象中的（或是预期的）客户进行较多的沟通，可能的就是依赖个别的比较或是非常熟悉这方面的人员来简单的分析制定一些需求计划文档（有的甚至根本就没有任何文档，完全地凭口头的指示）。其实原因很简单，因为老板有要求，必须要在多长时间内搞出来，否则。。。。。。所以一切从简了，简到不愿浪费一点点的时间同客户进行任何的交流。
这就牵涉到一个问题，如果那些制定需求的人对所开发的行业确实是专家级的，能够考虑到面临客户的尽可能多的需求变化时，这将是非常幸运的，然而，不可能我们每家公司都有一些这方面的专业人才，何况现在的社会提倡打倒权威，我们的客户似乎也特别热衷于此，他总能提出一些需要你改变需求的问题，不为别的，只为让你知道这方面他也是“行家”，所以开发之前我们也要尤其尊重这些人的看法，即使他们真的一无所知。然而时间就是金钱，我们不会浪费时间去和这种人辩解，不会和他们沟通这个问题的比较好的处理办法，因为我们没有时间，我们会认为我们所做的就是最好的，即使用户有一百个的不满意；所以为了避免出现类似的情况，为了避免浪费向那些白吃用户们解释的时间，我们有的项目组（或公司），干脆就闭门造车了。
接下来，就很简单了，需求分析有了，赶紧搭建框架，建立数据结构，分配任务了，也不去管什么文档了。这时候的老板恨不得你明天就能拿出来一个东西。没话说了，开始敲代码了。
这里就又出现几个问题：
有时候（并不是所有时候），可能我们公司比较成熟的技术，刚好是现在的客户所厌倦或是不喜欢的，他们通过某些途径知道或是了解到了一些比较新的技术，有些对他们来说只是些美丽的花瓶，但他们就要求用这个，没办法，顾客就是上帝嘛，我们引进。这时，如果碰到一些比较慷慨的老板，还好办些，可以花高薪聘请一些高手，假若要是这样的话，也还不算太差，这样我们就可以省却很多用来解决项目开发过程中可能碰到的难题的时间，同时，他们都有着比较良好的开发项目的习惯（我自己以为，如果没有良好的开发项目习惯的人，水平再高，也不能称得上是高手，最多只能说是字典），他们在分析处理问题时，本身就会考虑很多用户需求本身的变化。这样，我们也会省出一部分开发时间和一部分重构的时间。
然而，并不是所有的老板都很慷慨，也并不是说所有的人都是高手（甚至有的公司为了降低开发成本，根本就没有或不会去招聘高手），于是，在开发阶段问题就出来了，一些入门级的程序员，面对着崭新的从未接触过的行业需求，痛苦而无奈的敲着乱七八糟的代码，他们面对着很多早已经不是问题的问题而陷入查找解决资料的泥沼中，不能自拔，同时还要进行着莫名的需求的变更。并且，有些公司，为了加快项目的进度，在开始阶段，就开始加班加点地工作，终于有些人员承受不住这种折磨，开始纷纷跳槽走了，然而，他们不知道的是只不过从这个地狱跳到了另一个地狱；另一部分人，虽然没有走，但是心情烦躁起来，开始变得失落，没有任何的成就感，整天似乎就是为了工作而工作，没有了乐趣，编程再也不是一种享受了，而是一项任务，效率越来越低，但是还要赶时间，因为时间太紧了；同时，走的一部分人员，又需要有新的人员来补充，重新了解需求，了解已走的人的编程习惯，修改甚至重写一些不太完善或即将完善的代码，如果没有较为完备的文档，花费的时间就更长一点。然而我们没有时间，不可能让他花费那么多的时间去熟悉，去了解，他需要匆忙上阵，还要能够解围保驾，于是，他就开始按照自己新的一套风格做自己被要求要做的东西，周而复始，代码越来越难以维护。然而时间还是这样不紧不慢的走着，需求就在这个时间的流逝中，开始不断地发生着或大或小的变化，于是，大家也跟着日复一日地修改以前编写的代码，同时还要继续增加那些新的需求里的功能。
好了，终于有一天，你自以为可以长出一口气了，因为，在你看来，需求里的功能似乎都已经有了，始乎这个项目也已经开发完毕了。于是，开始向老板汇报，开始拿去向用户演示，虽然那些笨蛋什么都不会，但是还要给他们解释，给他们做培训，请他们提要求，因为，这时候才发现，那些白吃们拿着自己想要的money。当然，客户们也不会放弃展现自己才华的机会，各种意见、需求变更，纷纷从地底冒了出来，然后对这些意见和需求重新评估，重新调整规划，重新修改需求文档，调整数据结构，因为客户虽然不是上帝，但是人家掌握着财政大权，掌握着我们的经济命脉。于是，一切似乎都又不那么美好，一切都又变得乱七八糟，为了应付不同的客户，我们开始针对不同的用户进行不同的修改，因为时间，也许只有这样，我们才可能尽快地满足某个用户，一个又一个版本出现了，当大部分客户开始要求修改一些东西时，不同的版本一个接着一个开始修改，，再加上有些版本的升级，以致后来有的公司，同一个软件竟有上百个不同的版本。我们一边添加着新的内容，一边修改着软件中的bug,同时抱怨着时间太紧。我们不断地抱怨说，如果某个问题当时给我多长多长时间的话，现在就不会怎样怎样, 似乎一切都是时间的错。
然而说实话，即使一切并不都是时间的错，但时间在这里还是起到了至关重要的作用，最起码，如果时间不是很紧迫，我们可以制定一份相对较为完善的需求分析，我们也能够进行一些合适的业务知识的培训，不可否认，这样对我们整个项目开发会有不少帮助。
然而，我想说的，其实并不单单的是市场需求的时间紧，这只是一个客观原因，这个问题我们是避免不了的，但这真的是时间紧吗？我看未必，如果真的是因为时间紧，那极有可能是我们在不知不觉中浪费了太多。想想上面的情况，我们可以通过其它途径来加快整个项目的进程，比如，高薪聘请一些高手，这对于一个软件公司绝对是很有必要的，这样最起码可以减少一些不必要的查询如何解决那些早已不是问题的问题的时间，同时他们还能够预测到某些做法可能会出现的问题，毕竟他们是有经验的，这样也会减少不必要的回头率。其实这节省的是时间，也是金钱。还有，如果刚开始我们能够尽可能多的同用户进行交流沟通，也会减少我们诸多的需求变更，这样节省的也不仅仅是时间。
当然一个项目开发的成功与否，还有很多其他重要的因素，即使这个时间，也还有很多方方面面，然而，一个项目刚开始时，如果先把成本放在第一位，一切都要考虑降低成本，最终会发觉会消耗更大的成本，因为，时间是项目开发中最大的成本。所以，一旦我们能够把握住这个项目在时间上的进度，这个项目即使刚开始做，也已经是很成功的了！
声明：这只是我在项目开发过程中的一些感想体会，仅代表个人观点，并不针对具体公司和具体人员！同时这份文章还在继续更新中，欢迎大家一起来探讨，项目开发的得失！