当一家公司发展到一定规模的时候，可能就不如初创时那么有朝气了，初创时，没有包袱，轻装前进，高标准，严要求。而江山渐渐坐稳，”创新”渐渐就会成为一个熟悉而陌生的词汇。
如果整天喊着创新而实际上产品没有任何新意的时候，应该注意一下是否那些管理人员在其中起着阻碍者的作用。所谓创新，如果不能充分调动基层员工的积极性，那是不可能做到的事情，而无意识的妨碍基层员工进行创新，更多是出于管理者自身本位主义的考虑，管理者们应该知道”不破不立”的道理，但是”破”对他们来说，风险太大，远不如原地踏步，或是拿来主义，这样才稳妥，这样最不济犯错也是别人先犯。这个时候，很难去对他们奢求”用户第一”的自我要求。
回过头来，如果产品自身千疮百孔，被用户整天批得体无完肤。与其开发一些未必靠谱的产品，还不如埋下头来把当下的问题搞定。创新要在一定基础之上，缺乏叫座的产品做铺垫，所谓的”创新”只是空中楼阁。
创新还是撞墙，这是个问题。
–EOF–
再有几天 QCon (Beijing) 技术大会 就开始了。QCon 是这几年出现的最有价值的技术会议，”绝对有技术含量”，相信北京这次也会让每个人不虚此行。这还是第一次在国内举办，很多国外的大师都来了，有机会能参加也是一件好事。
受邀主持网站架构案例分析这一场，所以有机会提前看到各位技术演讲人提交的 PPT。前天晚上看到豆瓣首席架构师洪强宁的 《豆瓣技术架构的发展历程》，击节称赞! 这个 PPT 会成为一份相当经典的架构参考文档。
据说现在已经一票难求了，如果要购票的话，可以用我的折扣代码。买票的时候报我的 BLOG 或者我的名字就可以省点钱。
–EOF–
按：这其实是某一本书的推荐序(我这段时间没写 Blog 净帮着人忽悠了)。不过遇到了不靠谱的出版社不靠谱的编辑，据说整篇文章最后”只采用一两句行不行”? 当然不行。以后如果有出版社找我免费写推荐序或者书评，请自己考虑好再来浪费我的时间，多谢配合。
有的时候朋友们聚在一起聊天，会谈到国内国外技术人员的差异。我常喜欢说一句话”国内的 IT 公司基本上是劳动力密集型高科技企业“。比如就国外 Web 2.0 站点来说，Craigslist 、Wikipedia 等流量比较大的网站不过数十人的小团队而已，如果放在国内，这样规模的网站起码要几百人乃至更多人员才能足够支撑。国外程序员一个人做的事情，国内可能要一个团队来做，当然可能还做不好。这里面或许有企业管理效率低下的因素存在(宁愿相信是这样的原因)，不过大家都不愿意说的另一个因素是我们技术人员生产力效率低下。这种差异来自不是智力、体力上的差异，而是因为做事情的方式和方法，存在大量的重复劳动和人工劳动，对技术不能充分有效运用。如果不能对工作方式方法进行改进，我们永远都是技术流水线上的编码工人。
我们常说，重复的行为才能形成习惯，只有良好的习惯能导向成功。或许有人某些书籍或者聆听了某些”教诲”会逆反性的产生不以为然的想法，”这个我早就知道……” — 我自己常常就是这样自以为是。问题是，只是”知道”而没有行动起来加以”运用”，这样即使知道再多的技巧也不会形成良好的习惯，自然无法产生实质的改进，这可能也是技术人员惰性的一方面吧。其实我们需要的是能有更多的技术人员真正的行动起来，利用这些经验/教训/技巧…提升自己，也去积极影响他人，形成更良性的互动，不要让”持续改进”成为一句空话。另外，必须要补充的是，如果技术人员持续从事低效率的工作，极有可能逐渐厌烦技术，疏远技术，乃至对技术绝望，而一个高效的技术人才能从技术中获得真正的快乐。
也想告诉那些所谓的管理人员，不提升每位技术人员的生产力而希翼增加人手来解决技术困境的想法是不切实际的。那样做除了给企业增加负担，使组织更加混乱低效，很难起到什么实质作用。好的管理者必须能够引导下属持续提升生产力，不能一味用死板的流程制度限制团队的整体节奏。彼德克鲁克这之类的管理大师的大腿人人都好抱，但那是屠龙之术，您暂时还可能用不上，来点痛快实在的才是王道。
–EOF–
文章有删节。出版社的名字我就不直接说了，不过类似的经历的人还有潘加宇。你猜这是哪一家?