为什么我们程序员总是这么累、做出来的东西这么差？

目前国内的很多项目是这样开始的：上头说，这个（或是产品或是项目）开始做吧，你你，张三，技术好一点，带着大家做吧。就这样，开始了！
张三说，哥几个，咱开始吧！小A这块你比较熟，你负责吧！小B和小C，你们觉得哪几块怎么样？*&^*&^*(一番讨论)，好吧，就这样，小B你这块，小C那块；还剩这个，我来吧。我们要注意协调啊，大家有问题一起讨论！我们要统一编程风格，我们就采用那个《××编码规范》吧。等会儿我们一起讨论需求！

这个算是Kick-Off了！

接下来的需求讨论，大家热血沸腾的讨论了大致的功能点，和几个过细的细节问题。还强调一下：大家把各自的那块写成文档啊，免得以后别人看不懂！
就这样，每个人就开始了各自的一块！满怀信心并且热情高涨！

很显然，这样写出的文档可能参差不齐、风格不一。

接下来又说：数据库很重要，我们先把数据库定下来吧！好，大家一致同意，坐在一起讨论，你把你这块的设计好，我把我这块的设计好，然后，大家再讨论一下，数据相互交换的"互通有无、取长补短"，半天时间或一天把数据库设计搞个差不多了。

这样，手脚快的甚至可以开始Coding了。

慢慢的，问题就开始出现了。

由于讨论方法问题、文档编写问题、各人个性问题等等啦，很多需求细节没有顾及到（如：用户信息具体包括哪些字段；谁可以删除用户记录，是不是所有用户记录都可以随意删除；等等），麻烦就开始了，程序员不得不自己冥思苦想，把需求"想"出来，或者跟其他人（如张三）。但是在这种情况下，讨论的效果会很小，原因有：
（1）大家各负责一块，你应该是对你这块最了解的，讨论了别人也插不上话
（2）在这样的项目组架构下，当事人可能自己就根本不会想到跟别人讨论，理由同上条
（3）别人各自有"事"，根本没时间顾得上
（4）根据经验，从程序员的角度想需求，往往华而不实，离客户需求很远
反正凡此种种，自己一个人就边想边做，边做变想；还偶尔改改数据库，当然还不会忘了通知其他人。

当然项目组其他人也不会好到哪里去，基本一样！

这样，恶梦就开始了！

小B说，我这里要这个数据，小C你给我加上！
小C说，考，又得改，为什么不早说？
而此时，作为负责人的张三早就无能为力了，而蜕为跟其他人一样的全能的程序员。

在这个过程中，还有一点是，各程序员正充分发挥自己的"创造力"，不但去想需求，还会把自己新学的一些东西发挥一下。使用新东西很要命的，看书和做着玩儿的时候一点问题没有，一用到实际项目中就他妈这里也不行那里也有问题。只得往里耗时间，并且抱着一副"不信我搞不定"的凌云壮志，原本以为一天搞定的东西，结果一周过去了还没搞定。（顺便说一下，我很讨厌这种恶俗的自以为是的程序员心态！关于这个问题我会在其他地方具体谈谈）

这个时候，项目必定已经明显延期了！张三只能说：大家抓紧啊，比计划延迟很多了！（计划？听说过有计划嘛？）说完就埋头赶自己的模块了。

再往后，灾难就开始了。
——项目延期
——功能越来越多
——模块间关系越来越复杂
——有些功能更加模糊，即使负责人也不能完整、流畅的说出来
——甚至有可能被模块负责人"不小心"忘掉了（真的是忘掉了嘛？）
——数据库已经不堪入目
——测试就随便找些数据过过场
——最惨的，项目组开始失去信心了
——不停的加班，效率已经下降了很多
——整个项目组的感觉就像：被蜘蛛网缚住的蝉，连动弹一下都很吃力了
——绝望了

这个时候，领导要求去给客户安装……


哈哈，醒醒吧，现实没有那么恐怖，就当刚才是个噩梦。
现在再来这个项目过程中究竟有多少问题？
（下篇再说吧）