也许是尝到了读书的甜头，比如说技术阅读吧。

　　若干年前，我自学TCP/IP协议，认真啃过《TCP/IP Illustrated》后，做一些ftp、telnet、http的小demo，特别是后来成功运营的BT服务器，都感觉特别简单。

　　再后来看了若干本Java书籍、设计模式书籍后，开发代码非常快，并且通读Jetty、HSQLDB、Struts等源码，几乎没有障碍。

　　这一切经历，让我觉得，看书太有效了。

　　工作几年后，出来和人合伙做公司，我是IT负责人，做项目头一年，从商业角度来看，败得一塌糊涂。

　　要知道，我没有出来前，技术水平和项目开发能力都是被团队认可的，并且在那几年，看了很多过程管理和项目管理的书，尤其是深入研究过RUP。

　　忽然感觉读书没用，书籍欺骗了我。

　　经历了那次惨败后，我才明白，管理是一种实践，就像游泳一样，无论你看了多少游泳教程。

　　任何管理方法都有其适用场景，也就是前提，一开始就照搬书，往往会过分关注书中的方法，而忽视了场景，就如在沙漠上种蘑菇，无论怎样施肥都没用。而你不看书，你可能会特别关注场景或环境变化，自己摸索方法，这样成功概率更大。

　　所以，如果你以前没有项目管理、过程管理的意识和经历，切忌看大量相关书籍，或者干脆不看书都好。没有实践经验前，理论几乎没法指导你，只会约束你。

　　管理类书籍前期只需略读，在有一定项目经验和项目管理意识后，才开始深入阅读，结合项目学以致用。

　　过程管理和项目管理一样，也是一种实践活动。任何高效的流程，都是有其适用条件，如项目本身及人员素质，并且随着时空的变化，导致上一个项目中用得好好的流程，无法应用到下一个项目，比如同样的模块，采取外包和内包，开发流程就不同。

　　刚才我说到的RUP，即使非常熟悉它，而不知道怎么根据项目环境来裁剪，使用效果也是大打折扣，或者说非常危险，比如RUP工件中并没有强调原型和界面视图，这对特别重视界面的网站项目，指导就很受限。

　　刚毕业时，我把开公司想的很简单，市面上不是有很多公司制度表格的书籍吗，照抄就行了。后来我才明白，根本没法用，就是一个组织结构，不同行业、同一行业不同业务、不同规模或是公司不同阶段，都不一样。

　　技术上升到一个阶段/层次，需要提升的往往不是技术：

　　第一阶段/层次：纯技术 往往能够通过书本和demo练习，可以学会并且熟练。这阶段可以速成很多纯技术高手

　　第二阶段/层次：技术+业务 这时候就要理解业务，评估功能点的轻重和缓急，然后把技术镶嵌进去

　　第三阶段/层次：技术+业务+商业 比如资金、进度和人员约束

　　以上三种阶段/层次，只是告诉我们，上升到一个新的阶段后，你需要考虑更多的东西，同时受制约也越多，纯技术几乎没法让项目成功。

　　当然，上面没有考虑到管理，这个横向(横切)维度，如果也加上，项目需要权衡的因素就更多。

　　没有一本书，告诉你在这些受制约环境下，你该如何应用你的技术，因为每一种场景都不同。

　　也许，当你看了大量书籍后，并且忘了书中的一招一式，还能够应用自如时，你才真正达到了能力的最高境界：随心所欲(有知识无意识)。