1#

    通过不断学习、自学、经验积累到一定的阶段,就会引爆“悟”的能力,这样的悟是指掌握某领域一些原先看不到的规律,原先所无法体会到的知识体系化的美好。悟的年龄点,和人的IQ、环境、学习、实践、思考和总结等有关。多数人能悟透下述的一方面或多方面:技术、管理、文学、艺术、做人、快乐的人等


==================================================================


    如果我们谈IT咨询规划顾问,或者谈大型IT项目的项目经理,很多时候往往需要的都是综合能力。对于综合能力在这里不再谈沟通,ppt和演示,团队协同,写作能软技能能力。而重点来谈谈业务和技术方面综合能力的演进过程和路线。



   拿IT项目经理来说,如果没有真正做过比较专职化的项目经理,很难真正的理解到项目经理的工作内容和实践,项目管理中的实际问题。而你真正做了项目经理,你又会发现很多工作内容原来就在做,只是没有系统化和体系化。正如管理不在于知,而在于行一样道理,很多事情如果没有实践很难真正系统化和体系化形成经验和能力



    前面工作3-4年基本以软件开发为主,没有做过专职的需求,也没有做过专职的测试,但是在软件开发过程中自然涉及到这些内容,通过软件开发实践,以问题驱动的方式自然会对整个软件生命周期中的需求和测试环节提出更深入的理解。旁观者清,旁观者往往更多的是问题和场景驱动,通过问题和场景来反思上下游过程存在的问题和不足,以理解各个过程的核心要素



   在8年后我基本在逐步开始做外部大型项目的项目管理,IT业务咨询方面的工作。个人核心观点就是这个层面往往已经不是靠单个岗位上工作经验的积累,更多的是靠整个IT领域相关知识的积累。如果原来多年的积累就只关注点上的知识,要在学习能力下降后的现在考虑快速的面上的拓展是相当困难的事情。前面8年的工作基本涉及到软件开发,业务领域知识,需求,架构,测试,开发平台,IT项目管理,cmmi,产品开发等多个方面的知识,这些知识基本也是以核心业务域+软件工程的拓展。有大环境,有项目实战,再加上自己兴趣驱动就容易去拓展和深入。可以讲现在在实际工作中使用到的知识涉及到的方面太多,而这些又刚好基本都在原来学习和实践过,有些是亲自参加,有些是参与专题讨论和评审,制定方案。所以讲现在之学习和实践必将为后续工作所用,即使是跨行业,那么你仍然可以学习原来的学习方法和解决问题思维



原来我讲过学习的前导性和学习的外延性的问题。其核心就是学习知识不仅仅是一个类似知识树的静态结构,而是一个通过前导-》当前-》外延拓展有效串联的动态学习链。当前工作开展不下去是前导知识缺失,当面工作完结而主动思考和总结减少了拓展和外延的机会。工作中学习的过程其好处就是实际问题驱动,

只有问题驱动的学习是最有价值,也产生价值的学习,学习的过程就是不断前导外延双向拓展的过程,各个知识点不断抽象进行系统化和体系化的过程。



回到正题,知识有一个完整的演进路线,并不是说学习过程一定遵循这些演进路线,只是提供一种参考。个人经验来看仅仅谈从软件开发走到最好的咨询管理岗位的学习和渐进路线。



在技术层面:前面三年重点是编码能力提升,好的编码本身就是设计,在编码过程中加强重构。后面三年过渡到系统分析设计能力提升,一个是本身架构设计能力的提升,在架构设计能力提升中自然会更加关注需求和测试,关注整个软件生命周期,架构中开始关注技术架构和框架方面的内容,也关注RUP,MDA,DDD,FDD,敏捷等各种方法的核心思想,并选择性的使用。后面接着可以关注大型产品研发方面内容,关注技术平台和产品平台的概念,关注SOA和组件化架构这些内容。

在技术层面,如果不是完全纯粹的技术线发展,要知道cmmi和软件工程体系知识重要性远远高于数据结构和算法。



在业务领域层面:对于技术路线刚开始很少会关注到真正的业务域,所以我们说虽然从事技术或软件产品,仍然最好是能够适当的做不同业务域的软件,只有真正做该业务域的时候你才会真正关心业务需求和流程。在前阶段的自我学习往往都是理论和宏观的概念,很难真正的去细化。做企业信息化不管互联网如何发展,企业价值链分析思路,ERP说涉及到业务域仍然是核心内容。大的业务线条如供应链(计划,库存,采购),财务,合同,市场营销和CRM,产品研发,HR等都需要有所了解。在中后期阶段,重点感觉是企业架构和各个业务域的核心业界标准和模型的学习。比如谈供应链的时候会谈到scor模型,谈产品研发会谈到cmmi和ipd等。而且你原来涉及到的是一个行业,跨行业的时候还会出现很多差异化的内容,比如09年我做电力行业项目的时候,发现电网企业很多业务和系统和传统制造型企业有很多的不同。做运营商项目的时候又不得不去研究eTOM和SID等模型和规划体系。但是不管怎么变,核心业务仍然是通的。

知识很多时候并不一定必须是从下向上抽象,很多时候也可以从顶向下构建,先构建完整的总体框架,然后根据需要逐步研究和深入。



原文:

http://blog.sina.com.cn/s/blog_493a8455010151jj.html