(不好意思各位，我只是说了一些问题并没有解决的方法，所以还请各位包涵)

对于项目管理，我的经验与各位比起来肯定是少的很多，毕竟我没有带过什么大型项目，以前所带的也只是一些小小的项目，到现在这家公司里面，我就是一纯粹的coder。

然而，没吃过猪肉，总还见过猪跑的，只是到底是病猪还是健康的猪那另当别论。项目管理的书也看了不少，对我来说，纯属纸上谈兵，所以不能大放撅词说：我精通于XXX，一直致力于探索和传播软件思想，帮助人们正确地开发软件。

既然这样，我也就只能随便谈谈了，谈的好夸两句谈的不好也别骂我。

项目管理，固名思义，就是对一个项目进行管理，而管理管理，无非就是对人和事进行统筹安排。安排的好项目就能成功，安排不好嘛，黑黑。

而完成一个项目，一般都必须事先完成调研，期间协作开发，最后安排测试并上线。在初期可能会对于需求看的比较重，毕竟项目最初都是由需求的产生而产生，然后再根据项目的大小，合理的安排人手进行开发。期间肯定或多或少的会遇到问题（生理的、心理里的、后勤方面的，技术方面的等等不一而足），而项目管理就是需要协调好这些问题，能解决的解决，不能解决的想办法解决。最终项目结束后还有一段测试和上线以及BUG修复等工作。维护一定时间后，这个项目才算是完成了。（这都是我自己理解的）

对于大型公司，项目管理可能会相对简单，因为需求由BA团队去搞定，项目管理可能就真的只是对项目的开发进行管理了，测试则由QA团队完成。

如此说来，项目管理者更多的是处于一个协调者的位置，对于项目的进行协调，对于开发人员的进度协调，对于客户再增减需求的协调，对于上级领导的压力协调等 。好的项目管理人员是把手下当兄弟看，一些小事能挡则挡，尽量不会让他们被外界所干扰，而差的管理人员则仅仅是把手下当工具使用，有事自己解决。

 在这里还是有点小故事的，人员的名字嘛咱就不提，事件嘛无非就是一些没有协调好的事件，人物：A（技术部门领导），B技术部门I主管，C技术部门II主管，D技术部门I和II之间的协调人员（很奇怪的是，这个D的级别居然比C高，如果不是B呆的时间长，恐怕。。。），发生了一些事情后，B是公司原来的人员，A是后来进来的，C和D是A招进来的，在一些事件中，ABCD不可避免的发生一些理念上的冲突，B提出了意见，可能言语比较冲？CD则不开心了，认为是故意针对他们这些新来的。于是开会的时候A对B犯的一些错误进行了严厉的批评，认为一个老同志，犯这些错误，不应该呀，据说，声音是沉痛的，心情是悲哀的，完全是一种哀其不幸怒其不争的口吻（据说，据说，没有亲见［我是指语气］），对于CD的问题，则是更加沉重，要求大家眼光不能老是局限于错误，失败都是成功他妈了，盯着错误，就会看不到未来，而我们是属于互联网公司，眼光要放长远一些，一些新的事物在开端的时候，难免会有一些错误出现。一次两次这样大家都认为是正常的，可是最后却是经常这样。A对于B则开始逐渐的排挤，直至想办法辞退。（很抱歉有些个人感情在里面，有些地方也进行了艺术加工，但大体情况是这样的，我也作好被辞退的心理准备了）。

现在一切都讲究人文管理，在项目组人员能力可控的情况下，对于项目管理人员来说，关心的就是内部协调和外部沟通了（内部不能乱，外部需求则需要挡住），这点和个人接单其实差不多，在最初谈合约的时候，答应了哪些功能，开发了一半的时候，客户需要增减需求，你是怎么办？对于你个人来说，这其实也是一个项目管理，一个小型的项目管理。如果你连这也控制不住的时候，那么你在带一个稍大一点的团队怎么办？带一个超大型团队怎么办？

说的都是人的关系，最后再谈谈技术，从一个项目管理的角度上来说，完成一个项目，不是用最新最强的技术，而是需要用自己和项目组成员最熟悉的技术，只有这样，整个项目从技术角度上来看才能都处于自己的掌握之中，否则那真是技术也搞不定，人员也搞不定，纯属自讨苦吃了。C就是这样的一个人（但他好象能够把人员搞定，不过人员的水平嘛。。。也就是能够设计31张表连查的那种了）C是一个走在技术前沿的先锋人物，对于我们这些草根开发人员他一向是不屑一顾的，用着最新的技术，拿着最高的工资（他们团队的开发人员平均比我们团队高上2K左右），开会的时候冒出一些技术术语，然而对于真正的应用，是根本不了解（连个XXX都不会配，不说太多）。。。

结束语：项目管理要好搞好，除了需求的稳定（即使不稳定，那也要能够控制在一段时间后再更新，而不是三天两头就有新的需求进入项目），技术的熟悉（不求最新，只求最好），人员那才是最重要的（千万别是人心散了，队伍不好带了）

这样一篇带有个人感情的文章放首页，不介意吧？？？

我不知道这篇文章会写成怎么样，但既然算是一个想法，我想也可以放到首页被大家鄙视或者怎么怎么一番吧。（很多新人发随笔的时候是否都选择了发首页？我是想到哪里写到哪里，可能会就显得乱了）

最近一段时间园子里讨论框架算是比较热烈的，我是每天订阅首页更新的，所以也想着来说几句。

开头先表明，我正式的工作中用的并不是.net，看.net的书和一些简单的开发，是我在03、04年的时候吧。再往后几乎就没有用过了。但是我想编程的思想都一样的，说一点框架不算为过吧。

在工作中，很多公司、个人都选择了使用框架进行开发，大多数开发人员都会熟悉一到两个框架，并可能对某一个框架有着很深的了解，在看到别人解决不了的问题的时候，有时候也会冒上一句：你如果用XXX框架，只要用XXX方法就可以解决了，有必要那么烦吗？

是的，框架确实简化了很多开发工作，什么ORM啦，页面自动生成啦，（对于VS那种拖控件生成页面的方式，一向很感慨的），对于用户来说，他需要的几乎只是一个业务实现和逻辑控制。很多公司也确实是这样工作的，但是我想说的是：在这样的环境下，你除了会使用这些框架，你对程序的一些底层，你还熟悉吗？

＜被神话的框架＞http://www.cnblogs.com/birdshover/archive/2008/11/26/1341568.html，说的基本也是这样的问题。

企业应用框架，那是为的快速开发，个人应用框架，除了快速开发外，最重要的应该是学习实现框架所用的一些架构、思想，而不是为了用而用（接单除外）。

很郁闷的就是看到一些人（我们公司的另一部门的项目经理）在项目开发的时候居然用上了最新的框架，对于一些新的框架，虽然有部分技术是先进的，但是BUG也是很多的，在项目一开始的时候，他自己就说了，我们要用XXX框架，然后手下一帮子人花了一个多月先学习这个框架，最后在开发的时候问题多多，可是他在向领导介绍的时候说的是：我们采用了业界最领先的框架。结果在做关系映射的时候，数据库里的数据如果默认是0，创建外键的时候就会报错，但他从来没有找自身的原因，而是把责任推到我们部门，说我们不会设计数据库，int字段默认不应该为0，应该用NULL，被雷倒了。［题外话：拿着那么高的工资，做的却是一些不切实际的事情，怪不得去哪家公司哪家公司就差不多完蛋了（对不起，不能多说，我还要混饭吃，同时猜测我们公司会在什么时候被他们整跨）］

在开发的时候认识几个程序员，都在自己写着框架，然后开源发布了，不料在自己的论坛里，很多使用框架的人居然在问：这个框架带留言板吗？这个框架带XXX吗？一直被雷着。。。

整理一下思路先。

框架，我们是要用的，但是要看用的范围和用的度。在企业开发的时候，我们可以尝试采用框架，毕竟在使用框架的时候，有很大一部份被忽略掉的就是效率（估计没有人会说框架的运行效率高的），可是在做WEB应用的时候，数据量并发很大的时候，如果你对框架底层并不熟悉，那么建议还是不要使用框架，而是寻求一些简单的解决方案（比如在使用SQL的时候直接手写，这样调试起来也会方便一点，不要象我们公司那些人，用Hibernate查询，生成的SQL居然横跨了31张表，太牛叉了）

对于个人，我们并不建议使用框架，但可以学习框架的设计思想，毕竟这些框架在实现的过程中，大都采用了一些很常用也很实用的设计模式，看完一个框架（我说的看完是指仔细读完源码），那些设计模式也就几乎都了解了，当然看代码的时候也可以对应那些设计模式的书。几乎所有的框架都会有自己的特色，但同时也会有自己的缺点，不可能会有完美的解决方法，否则目前就只会流行一种框架而不是框架满天飞了。

（看框架前，请先尝试自己写点代码，不要啥都没学就直接看、用框架，那只是一种白痴行为，不过现在很多培训点就是这样的。怪不得软件业越来越不 值钱了，创造力几乎都没有了，虽说要学印度，但也要教别人基础的吧。。。）

最后再放点屁：先学好基础，打实基础，再用框架，再学框架，否则到最后都是一场空。（如果你辛苦用的框架，作者不更新了，你怎么办？就象linux的某个文件系统一样，业界认为这个文件系统很好，可是作者却因为杀死老婆坐牢去了，再好的东西没有维护，不再更新，你敢用吗？）