精华内容
下载资源
问答
  • 企业内部软件开发的特点和模式

    千次阅读 2014-05-02 16:32:58
     在现代企业中,信息系统已经...通常说来,大多数企业内部开发团队是企业内部辅助主营业务的、非赢利性的组织。这类带有普遍性的企业内部软件团队是本文的关注点。 和专业软件公司开发过程一样,企业内部软件
    

        在现代企业中,信息系统已经越来越成为企业管理的重要支撑。因应各种业务需求对软件系统的要求,大多数企业都形式不同地建立了自己的软件开发团队,视企业的规模从一两个兼顾支援网络硬件、进行简单开发的人员到大规模的专业软件开发组织都有。通常说来,大多数企业内部开发团队是企业内部辅助主营业务的、非赢利性的组织。这类带有普遍性的企业内部软件团队是本文的关注点。
        和专业软件公司开发过程一样,企业内部软件开发也涉及对过程、工具、质量、人员等各个层面的管理问题,所以目前成熟的或者正在探讨中的各种软件开发模式都可以被企业内部软件开发借鉴和参照。但是,在服务、非赢利的前提下,企业内部软件开发的各方面都有有别于专业软件公司的特点。目前关于企业内部软件开发模式和管理的探讨比较少,很多人,甚至企业内部开发团队的成员本身,都没有明确企业内部软件开发和专业的软件公司开发工作的不同,在项目管理、文档控制等方面经常教条的模仿专业软件公司的开发模式。这种认识上的模糊性削弱了企业内部软件开发团队在软件的生命周期中本来具有的优势。
    1企业内部软件开发的特点
        企业内部软件开发有什么值得注意的特点呢?以下通过在几方面和专业软件公司对照的方法来进行一些分析:
    1.1软件开发团队和用户的利益关系。
        专业软件开发公司和用户是商业关系,直接目的是销售产品和服务获得收益,用户本身的收益和软件公司不是明确相关的。虽然大部分软件公司从产品和产业长期发展的角度都把类似“实现客户价值”这样的价值观列为公司的主要宗旨,但实际操作中很难彻底摆脱商业关系,在开发的各个环节受制于开发费用等商业因素。而企业内部软件团队的收益和生存直接和企业联系,业绩考核也是和企业目标相联系的。这是一个本质的差异。
    1.2软件开发项目所处的系统环境。
        企业的软件系统往往多样和复杂的,针对企业的软件开发项目面对的大多是一个已经存在很多信息子系统的软件环境。如果由专业软件公司单独来定制开发企业软件,因为是阶段性的参与企业信息系统,所以除非客户有明确的界定,否则很难设身处地的,从信息系统的整体长远发展来考虑需求和建立方案。如果专业软件公司开发的是通用的商业软件,更不可能预见最终用户的系统环境。对比之下,企业内部IT部门相对熟悉业务并且要长期经营整个信息系统,所以在每个开发项目中都需要从全局角度和长期角度来考虑项目的必要性和方案细节,要考虑和已有系统的集成。
    1.3开发过程中和直接用户的交互关系,
        企业内部IT部门和用户部门是同一组织内不同职能机构的关系,企业内部软件人员和直接用户是同事关系。和专业软件公司比起来,这一点又引起很多用户交互方面的重要的差异。
    1.3.1沟通方式和沟通效率。
        内部软件团队可以方便的召集用户、灵活的协调时间、有丰富的途径和平台来协调各种问题。项目完成后用户和软件开发人员仍然会长期共处,可以不断地交流并对软件进行改进。而专业软件公司在和用户打交道的时候受限于很多商业因素,沟通效率通常远低于企业内部软件团队。
    1.3.2需求分析和需求变更管理。
        开发过程中用户的需求往往是模糊和多变的,除了实际使用环境的不确定因素,用户对IT的理解和对资料的整理水平不足也是引起需求多变的重要原因。专业软件公司虽然有专业的分析人员和方法,但由于商业关系和业务复杂性,常常无法深层次地介入用户的实际工作层面,进而全面理清那些用户的需求是合理的,那些是不合理的,那些是可以简化的,那些是需要加强的….,等等。面对强势的客户更是没办法从合理的角度对需求进行梳理。为了控制项目的进度和人力资金投入,软件公司往往不得不通过成文的方式对需求进行界定。另外出于“专业表现”的要求和商业利益的需要,软件公司也会有意无意加入一些可能不见得切合实际的需求目标。这样最终软件会出现整体或部分偏离实现客户价值的方向的可能。而在企业内部软件开发团队主导的项目中,用户对项目的需求更强调实用性、方便性和快速见效。用户对将来需求变化引起的沟通和商业上的麻烦不太担心。企业内部开发团队经常可以根据实际业务需要对用户的要求进行否决和更改,也可以在用户要求之外增加系统目标。
    1.3.3软件的测试和交付过程。
        企业内部软件团队可以方便的从组织上把用户当作测试团队的一部分。在确认软件功能基本完成,没有根本性缺陷的情况下,可以比较早的当作软件项目已经的交付。更多的测试可以放在开始使用之后的长期运行过程中进行。专业软件公司在和用户配合测试方面则比较复杂,引入用户、计划和协调等都没有企业内部软件部门容易,交付也要严格的多。所以通常软件公司在测试方面投入的人力和成本要比企业内部软件团队多很多。
    1.4软件开发的规范:
        专业软件公司开发的大多是中大型的、商品化的软件产品。在设计开发过程中有很多在结构规范、通用性、界面美观、文档完备等方面的要求,开发周期也都较长。而企业内部开发大多为中小型的软件或者是基于已有大型应用系统的二次开发,注重实效,注重量身定做,注重速度,对文档和通用性等方面的要求比较灵活。
    1.5 其他可能的差异。
        企业内部软件开发团队的规模通常比专业软件公司小,组织上的分工不象专业软件公司那么完整,各种资质的评估和认证要求也不迫切。
    以上这些不同大多是显而易见的,但是对软件开发过程的影响却是根本性的,企业内部软件开发需要在认清自己定位和处境的情况下,建立更加适合自身及企业利益的软件开发模式。
    2企业内部软件开发和敏捷开发思想
        有必要提一下近几年新兴起的敏捷开发思想。作为对一直以来软件工程各种模式中条块分割清楚、文档繁琐、周期冗长等问题的突破和尝试,敏捷开发思想近几年越来越引起软件开发机构和开发人员的关注。根据敏捷思想创始者们宣布的敏捷开发宣言,敏捷开发的价值观和原则如下:
    敏捷软件开发价值观的表述:
     
    人和交互重于过程和工具。
    可以工作的软件重于求全责备的文档。
    客户协作重于合同谈判。
    随时应对变化重于循规蹈矩。
     
    敏捷软件开发的12条原则:
     
    对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要。
    我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。
    经常交付可以工作的软件,从几星期到几个月,时间尺度越短越好。
    业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
    围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。
    在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
    可以工作的软件是进度的主要度量标准。
    敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
    对卓越技术与良好设计的不断追求将有助于提高敏捷性。
    简单——尽可能减少工作量的艺术至关重要。
    最好的架构、需求和设计都源自自我组织的团队。
    每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。
     
        从罗列的这些原则来看,敏捷开发思想强调激发人的主动性和协作,强调去除不必要的文档和设计,强调顺应需求的变化,强调尽快的交付阶段成果和持续改进开发。对于专业软件公司来说,要实践敏捷思想里提出的拥抱变化、客户密切协作、不断交付等理念,有赖于软件开发之外的客户关系处理等工作,有赖于商业元素和客户价值的平衡,在实践中要做到并不容易。
        相比之下,对照前文提到的企业内部软件开发的特点,可以看出敏捷开发思想和企业内部软件开发有着近乎天然的联系。事实上很多企业内部软件开发过程都有意无意的和敏捷开发思想相贴近。但是因为指导思想上的模糊,使得很多企业内部软件开发中可以利用的优势被教条地搬用“规范”过程和标准所限制。相信随着对软件开发过程认识的加深,敏捷开发思想会对企业内部软件开发会带来越来越大的影响。
    敏捷开发只是一种理念,并不是对瀑布或迭代等方法的颠覆,而是一种启发和演进。对于它的原则不同人有不同理解,实践起来也有各种不同的模式。目前已经有很多基于敏捷开发思想的方法被提出并经过一定实践,但都不能作为标准。总的来说,敏捷开发思想本身仍然是站在专业的、面向客户的商业化开发环境角度提出的。企业内部软件开发还需要根据实际情况,参照敏捷开发思想,对各种软件开发方法进行取舍,摸索更加适合自己的模式。
    3企业内部软件开发的模式。
        企业作为软件的直接使用者,实际业务上的变化和管理上的调整变革会频繁地引起对软件系统的变更要求。企业内部软件团队需要管理自行开发软件的整个生命周期和购买大型应用系统后的生命周期,所以宏观来看,企业内部软件开发是一种持续开发的类迭代模式。而对每一次阶段性的开发项目,则需要根据项目的规模,结合敏捷的思想,灵活地掌握开发过程。
        和专业软件开发公司一样,企业内部软件开发团队同样要建立文档代码管理、项目管理、质量管理的各种制度和工具,但形式上可以更加注重实用性和有效性。另外和专业软件开发公司相比,企业内部软件管理需要特别加强用户队伍的建设,争取使用户成为信息系统的有机组成部分,这样对信息系统和企业业务都有不可估量的正面影响。
    软件工程归结的几个基本的阶段:规划和计划、需求分析、设计、编码和实现、测试、维护和支持,对所有项目和阶段都是适用的。仔细观察目前林林总总的软件开发模式,都可以辨认出这几个阶段,不同的是每个阶段的引入时机或持续长度。对于企业内部软件开发来说,因为企业内部软件团队的目标和企业的目标一致以及内部软件团队的特殊位置,所以在这些经典的开发阶段之外,还应该加入一些其他的重要阶段或需要特别关注的内容:
        首先应该加入的阶段是实施阶段,这是一个在经典软件工程模型中被弱化的阶段,经常被列入交付或者支持的范畴。对于商业化的开发来说,,客户或其他评审机构评审验收合格,软件开发已经基本完成。所谓实施就是给用户培训,后面用户怎么用是用户的事。如果是大型应用系统,如购买的ERP、PLM、SCM、CRM等系统,实施过程大可另做项目或交给专门的第三方实施公司。但对使用企业来说,实施非常重要。即便是小型软件,如果没有后续的推进、进度控制和项目协调,都很可能"用不起来"或者"用的不好"。这样对于企业来说软件仍然是没有完成的。明确独立的实施阶段,可以使软件开发团队在实施的组织和方法论等方面更加专注。
        其次是系统集成分析。这一工作通常是覆盖规划到系统设计阶段的工作,可以加在规划或需求分析等阶段内部,也可以单独列出。对于已具备一定规模的企业信息系统来说,这一工作需要特别强调和严格引入。主要内容是对照信息系统的整体规划,考察新开发项目和现有系统的集成。即便没有明确的信息系统整体规划,也要在分析用户需求和系统设计时,时刻注意把需求放在系统集成环境下进行功能定义和功能分配。用户对系统集成大多是没有考虑的,商业模式下的软件开发方法也很少提及。但这是企业内部IT应该进行的工作。忽略这个集成分析,随着时间积累,将造成信息系统即使局部很高效和很完备,但整体上却臃肿和低效率,进而使企业在实际管理上承担难以估计的代价。
        各个企业内部软件团对所面临组织环境和系统环境千差万别,各个具体项目有各自的特殊情况,所以不可能存在一种普遍适用的具体开发模式。各个企业内部软件团队要根据自己的实际情况开发,逐步建立自己的开发方法和全面的系统支撑环境。
    4结束语
        从分工的角度来看,独立于软件使用企业之外的专业软件组织的存在是必需的。专业软件组织在软件本身的开发规范和开发技术等各个方面,都具备非专业组织无法达到的深度和广度。但是,软件开发过程的管理和控制是一个非常复杂的领域,这种复杂性不仅来自软件开发本身,更来自于需求的复杂、需求的多变以及很多其他超出软件领域本身的因素。软件工程实践中反复探索但仍然长期困扰从业人员的诸多问题,例如需求难以控制、软件品质难以控制、预算经费难以控制、项目进度难以控制等,都不能单纯靠专业软件人员或软件组织来解决。另外一个软件的成功与否,最终还是要通过实现客户价值来体现。而如何实现客户价值,也不是纯粹的软件问题。
        企业内部软件团队在解决这些超出纯粹软件开发的问题时,有着自身特殊的优势。目前对企业内部软件开发特殊性的研究是软件工程研究方面比较弱的一个领域。从整个软件行业来说,进一步还应该研究企业内部软件组织和独立运营的专业软件组织之间的配合。这些研究对突破各种软件开发困境将会是非常有意义的工作。


    转载自:http://blog.sina.com.cn/s/blog_5f042e930100d6cm.html


    展开全文
  • 企业IT项目开发之七宗罪(下篇)

    万次阅读 多人点赞 2014-01-01 01:01:45
    前一阵公司给我下达了任务,一直在忙着打造面向SAAS的企业级微信平台,彻底实现零代码配置,小小一个微信,当面向企业级而且是SAAS时,呵呵,还真的有许多需要注意的地方,非常感谢公司内最强的业务架构师我们的大姐...

    即使没有翅膀,心。。。。。。也要飞翔!


    在新年前一天预祝大家新年好,在新的一年里工作顺利,身体健康。


    前一阵公司给我下达了任务,一直在忙着打造面向SAAS的企业级微信平台,彻底实现零代码配置,小小一个微信,当面向企业级而且是SAAS时,呵呵,还真的有许多需要注意的地方,非常感谢公司内最强的业务架构师我们的大姐设计出来这么优秀的一款全动态微信业务。所以写完了中篇,一直没时间来得及写下篇。


    下篇的开头,大家也看到了标题:即使没有翅膀,心也要飞翔!!!


    为什么提这个标题呢?企业IT项目开发之七宗罪上、中篇大家看后很多人都说:目前形势就是这样,有什么办法?也有人说:道理都懂,大环境这样,有什么办法。


    对,对,说得都不错,我们无法去改变环境,我们天生不是天使,我们没有“翅膀,可这就代表我们要就此沦落吗?


    NO!


    我们的心一样可以飞翔!


    环境落后没有关系,可悲的是心态也落后。


    步入正题


    以下我拿一个数据来说明问题,2005-2011年世界上只有3家IT公司保持着每年利润超10亿美元,利润超10亿美元哦,哪三家?


    NO1. IBM,抛弃了Laptop后反而更强了,为什么?


    NO2. TCS, 塔塔,世界上最大软件外包,网友们要问了,一个外包,做这么大,对吧!为什么?


    NO3. APPLE,那是勿庸置疑的!


    我们不说APPLE,只说TCS 和 IBM。


    IBM,大家如果注意IBM的人会发觉,IBM的WAS系列即Websphere系列经历了2次变化。


    一次是WAS7开始IBM专门规划出了一个SOA产品区,里面有Websphere Process Server(ESB), Business Process Management, IBM iLog规则引擎,TAM,WebSeal,MQ,然后把WAS归在了这个区。


    第二次变化是再次把WPS(Websphere Process Server),BPM,ilog等又划出了SOA,归成了中件间产品。


    为什么IBM要对其经典的产品,去做这样做两次大的变动呢?我们放在下文中说,我们先举例子,因为太多的道理你可能一下子不能够去接受,回过头你再来看,你就会明白了。


    欧债危机持续,企业客户没钱啦


    随着经济危机,主要是欧债危机引起了金融保险行业的大规模的萧调,大家都知道,金融系统的IT往往都是大型的业务系统,当金融业受到了影响,IT业势必也受到了很大的影响。


    那么我们国内很多IT公司都是怎么生存的呢?


    国内IT公司在经济危机之前的生存之道


    大部分都是做项目的,或者是卖人头的,对吧!


    就是我前篇讲到的学好SSH,货卖帝王家,SSH满天飞。


    根据客户的需求,业务要求,做4个月,6个月的开发项目。


    有的项目短,做个2个月,搞个项目,然后按照人月数用UCP,FP什么的estimation方法一估,然后报给客户多少多少钱。


    在欧债危机前,因该是2008年前,或许我们靠着公司好的名声,经营之道,管理有方,好的PM,好的客户关系,或多或少是可以不断的接到这样的单子的。


    往往做这样的单子的时候,我们用最简单的“软件开发生命周期”,就是我们说的七步曲即:确定问题、需求分析、设计、开发、测试、布署上线、维护。


    项目管理基本分成两种模式:瀑布式项目管理和敏捷项目管理,对吧,这个大家都知道。


    关键的问题在于这个地方,即不管任何一个需求,项目大小,你都必须要走确定问题、需求分析、设计、开发、测试、上线、维护,如果在项目中或者是项目后期有超出需求的部分,我们把它定为:需求变更,一个需求变更也必须要走完这7七步走完这七步不算完,还要把以前开发过的代码和工程再重新测试、布署、上线。


    如果有了BUG,BUG的修改也是要走这七步的,对吧?


    因为你的需求变化了,不代表我只完成变更后的部分就完成了任务了,因为你的变更可能会引起我已经开发好的功能上出现了BUG,这个问题想必大家都是碰到过的,这样的BUG叫Regression Bug。


    在经济危机没有来时,你这样做,OK的,客户理应给钱,因为是他自己要变更需求的吗,对吧,否则的话你需求变更我也能做啊,但是没钱因此我的质量就不给你保证,客户也怕,所以愿意掏这个钱。


    现在经济危机来了,企业怎么生存啊,还能这样生存吗?


    《哈佛商业评论》上面有一篇文章文章说,IT已经不像以前那么关键了,因为IT的普遍应用,就像水电一样,成了一种基础设施,不再是企业核心竞争力的来源。


    经济危机,就是企业没钱啦,没钱,但IT一样需要,”不再是企业核心竞争力的来源“不代表我就不要IT了,不代表技术无用论,这边的“不要了”只是代表“相关技术的普及"了。


    普及就是SSH,J2EE, EJB,Webservice这种东西,你会我会大家都会了。


    于是,大量的还在拿SSH做项目的公司面临着比以前多2倍,不。。。是10倍之多的竞争对手。


    于是,你会我会大家会。


    于是,大打价格战,你卖40万,我卖30万,成了自由叫卖市场。


    于是,工程价格是下来了,GDP上升了,平均工资上升了,程序员的工资还是要付的。


    于是,加班不要钱,会个SSH,工作个5,6年还拿着一个月8K,9K,1万块钱到头了,没有年终奖了,Team Building取消了。


    于是。。。。。。还有很多。


    最后,于是,程序员成了民工还不如了,哈哈哈哈哈。


    但是,但是,说多了于是还有一个但是。always 有一个但是,导演总是不给我们一个happy ending,呵呵,像一些美国大片一样有多个结局哦!!呵呵!!


    但是,还是有一部分企业在这种大环境下脱颖而出,挣足了钱


    这些企业越做越好,人头数就是head count反而年年越来越多,在这样的大环境下,还能持续的挣到钱,这些公司的IT人员反而越来越脱离业务越来越走技术路线了,反而比原来那些天天“业务业务”挂口头的公司挣得更多了。


    为什么?


    这还是要从客户的角度去出发。


    前面说了,经济危机,客户没钱,项目一样要做,按照以前那样,我的一个项目,走完软件开发生命周期7步,如果有变更再按照瀑布或者是敏捷开发来走一遍需求变更,对不起,客户受不了。


    反正以前的项目已经做了差不多了,新的项目客户要求的是


    业务上的功能可以随时变,当这个变更需要被提出时,如果你是开发商,你说:我们需求都可以做,给时间,然后我们翻代码,对不起啊,客户不会再让你这么做了


    如果你是开发商,你和客户说:你的需求我们都能做,然后重新估算,走变更流程的话,告诉你,你从2008年后开始就很难接到新的项目了。


    可能,以前你可以一年接1000万到2000万的单,2008年后你可能一年不如一年,一年能接个500万,300万就了不得了,有的连100万的单子都接不到了,真的,于是你就要面临危机啦!!!


    喂喂喂喂,知道了吗,危机感啊!!!


    那有人说了,我业务上的需求功能都变化了,原来是a+b+c*(x/y)现在成了a+b*(x+c-d)了我还不变代码啊?


    业务彻底变了我还不改动程序啊,改动了程序后我还不重测试,重布署啊,这都是人力啊,都要给钱的啊。


    当然不是说全部100%能够做到,但至少可以说70%以上的需求可以做到不改动代码,就算改动代码了也只需要重新测试新开发的功能就可以了。


    这就是SOA提倡的东西,这边不是说SOA的原则,我们说SOA可以做到什么。


    SOA可以做到什么?我们粗看一下,有的人觉得很空洞,有的人觉得“很深奥,看不懂写点什么”,那就先来看一段SOA架构理念吧:


    1. 模块和模块之间耦合度降到最低!


    2. 业务间的规则可以由客户自由定义!


    3. SOA不是一种软件,它是一种设计、实现的思想,它帮助一家企业建立起一个业务的infrastructure!


    4. 它可以迅速实现客户的需求,为客户提供垂直的业务需求,可以快速的把客户的业务从需求直接变成IT实现!


    当然还有很多,我先就举上面几条市面上见得最多的”行话“,怎么去理解上面4句话呢?我们用大水词来理解吧,上面这4句说的就是:


    1. 我新做的东西,应该按照模块化开发思想,就是你原来的系统给新接入的模块将来的接口要预留好(有人说了,我2011年开发的东西怎么知道你2012年的模块是什么样的,怎么给你预留接口啊,对的,可以预留看,你看下去)。


    2. 由于我接口已经予留好了,新的模块就像搭积木一样,就是乐高积木啊,把新的东西”插“上原有的模块就可以用啦,如果这个模块不好了,旧了,我拿掉它,再换一个模块。甚至可以做到本来一个项目,10个模块,每个模块都由一个开发商去实现,然后再找第十一个开发商来搭积木一样的去完成前10个模块的集成啊。


    3. 然后就是诸如:a+b+c*(x/y)现在成了a+b*(x+c-d)这样的业务变换,我不需要去用个eclipse打开工程然后改动里面的代码,一改就是改jsp, action, service层,dao层对吧,改完后急着上线,然后BUG又是一堆,改不完的BUG,加不完的班,不要,程序员不要走这种路了。


    4. 像这样的业务改变,你有一个界面,让业务人员就可以自己去通过拖拖拽拽自己去实现需求的变化了啊,这边的业务人员指的是企业里面用你开发的这套系统的最终用户,他们自己经过简单的培训就可以用你的系统自己去定义自己的业务变更啦。


    如果你的系统能够满足客户这样的需求,啊呀,在现在这个大环境下,当人家公司接不到项目时,你一定能够接到项目。


    那又有人说了,客户都可以自定义化了,我这个项目结束后不就没有后期维护,后期开发任务了吗,我就不能够长期的稳定的去获得一个客户这边的项目来源了吗?


    错!!!


    你错了,客户的需求是不断的在变的,由其是业务系统,那个业务变化太大量了,就说一个CRM系统,一个CRM系统它面临的是每个月都在变的业务,为什么?促 销,打折,双11,双12,圣诞打折,这些业务都在变啊。


    我的系统因为耦合底低,可以做到模块间的任意互换,然后我又有这种业务人员自定义规则的界面,所以我新做的模块可以0影响到原有的已经布署的代码,而且我新做的模块的布署是不需要原有的服务器在某天的零晨停一下,然后我重去布署一下这种做法的,取而代之的是24*7的一种模式,所以我管你客户需求怎么变,新的需求拿来,我都是只需要重新估算新的功能的工作是量,可能新的功能里面有70%的业务是可以由客户中的业务人员去自定义完成的,因此这70%我留给客户,30%这个人工费我会收,客户也觉得应该给你。


    因为你做的东西不影响原有系统的功能,不影响原有的系统运行,不会有太多或者就算有regression bug也是降到最底的度,因此客户才会源源不断的每个月,给你个20%,30%,10%,然后过几年系统大升级,软硬件中间件一起换也找你,就算客户新的模块是找另一个开发商做的,但是在集成时碰到问题还是要咨询你啊。


    于是,项目钱,这个大头是可以挣到了。


    于是,维护费,每个月定期的,而且这种维护因为不是传统的那种翻写原来的工程,改动原有的系统,而只是搭积木一样的,你可以雇用相对便宜的年纪轻的程序员,利润也有了。

    于是,你还可以收咨询费。


    从原来的几个悲惨的“于是”,变成了多条腿走路,多方位收钱的于是啦,呵呵!


    关键是这样的项目是怎么做的,说了这么多,这样的项目是长个什么样的呢?


    记得我当年在公司里面临第一次升职选择时,公司给了我两条路:PM道路和技术道路。我选择了技术道路。于是我第二天接到了美国总部一个Chief Architect,就是主任架构师的第一轮考核电话。


    老外,很牛B,你们知道他是怎么考核的吗?相当的夸张:


    嘿,你,看看公司的员工内部系统,里面有考勤,在线学习资料,请假,报销,你在公司这些年一直用这个系统吧,现在请给我写一下,如果让你设计这个系统,你会怎么去设计?给你30分钟,嗯。。。。。。对,就30分钟,现在是4:10分,请你在4:40分把你写的东西通过email发给我,as much more as you can think。


    我花了25分钟,最后他用了一个excellent把我给录取到了公司的架构师队伍,从而我成为了中国这边唯一一个能够进入到美国核心技术队伍的成员。


    那我是怎么写的呢,当然,我也只是给大家参考。 我是这样写的


    首先,这个系统不管是考勤、请假、报销都有一个”流程“性的东西,因为每做一步,系统都会有相应的EMAIL告诉你或者是某个环节的审批人:你目前有一个什么什么样的任务,还经常会收收到系统的EMAIL要求我上传这个附件,那个附件,驳回,拒绝,通过啦等等等,因此我会采用工作流,如果客户是大型企事业客户我会推荐他们去用一些商用软件如:IBM Lombardi,或者是Oracle的Pega Rulz。如果是中小型客户我会推荐一些开源的工作流如:jbpm, aris或者是activity。


    其次,该系统中存在大量的”上传单据“,”发票复印件“,”病历扫描件“,”会议文件“,”PPT“等文件上传文档的接口,因此,我不会自己去拿个common upload去做这么多的界面。


    首先,如果我自己做,如果时间允许,我会去做,但是我自己做这些上传文件的界面和系统,我还面临着上传完后根据我的上级,上上级,上上上级这样的一个”按照权限“查看附件的一个权限系统问题。


    那我自己做了上传系统后,除了解决按照权限查看调阅这些文件系统外我还需要面临着去做,我上传了第一次,传了不够,加点东西,传错了撤销重上传这么一个版本控制的问题。因此我会选用CMS即Content Management System。


    比较适中的好的CMS系统如:Microsoft Soft Share Point Server即MOSS系统,或者是纯免费开源的OPENCMS进行二次开发来帮助我做到上述这些事情。


    然后,这个系统有考勤,有报销,有请假,有在线学习资料课程管理,我肯定会按照模块一个个开发,然后模块与模块间的集成怎么办?对吧?这个系统是单点登录的,这个勿庸置疑,你登录了企业公司内的AD域就可以登录这样的一个系统,模块和模块间又要低耦合,那就是按照模块分离开发和布署原则,那只有上PORTAL了,所以Websphere Portal Server或者是liferay portal纯开源免费的这个是。如果不用portal那就是模块和模块间用web service接口,即组件合开发SCA概念。但是组件开发如果按照Webservice来对接,就意味着如果我新做一个模块,需要和原有模块的webservice间的连调问题,因此我们可以考虑采用esb统一webservice路由后所有的新做模块按照这个统一的接口,然后像搭积木一样把新的模块“搭”上去。



    还有就是这个系统,同时还连接着公司的财务,进销存等其它系统,它们之间肯定会有类似自动”定单“的东西或者是数据交换存在,那就存在着异步调用,那我肯定会用JMS,但是JMS里队列我要自己去实现,你有那个能力那个精力自己去实现一个企业级的队列?

    给我时间,又说给我时间。

    人家企业开发集成4个月,6个月哪有这么多时间给你去自己光开发一个队列系统,你当人家企业是小白鼠啊,经济危机,没钱没时间,OK,所以我会上MQ,开源的我有activeMQ给企业选择,如果是商业级的我推荐用IBM Websphere MQ。

    前面刚才说到了单点登录,这个单点登录是逃不掉的,而且你光单点登录是不够的,还要去集成企业内的权限系统,你自己去重头写一个?当然如果现在是一个新产品开发,你可以花2-3个月甚至更长时间把个权限系统做完美了,现在是企业级开发,业务系统,我肯定会去想,如何拿灵活的,组件化的模块,成熟的组件去实现我这个需求,因此我会选SSO组件和企业权限组件如:IBM TAM,或者是WebSeal或者是YALE CAS去集成这个SSO和权限,这样,利用这些组件本身强大的访问LDAP即AD的能力我可以把精力专注在如何去组成这个系统上而不是拿个SSH,天世界的天天敲代码把这些东西重头到尾做一遍。


    然后是安全上的考虑,我会考虑:

    1. 我要从应用层面上来说防止跨站式入侵,SQL入侵,脚本注入入侵,中间人攻击入侵等

    2. 我要从系统层面上来考虑病毒的入侵,恶意的DDOS攻击等

    3. 数据的传输安全层面我要考虑数据如何保护,哪些层面,哪些传输是需要加密需要保护的

    4. 硬件层面的时间同步

    5. 由于系统中很多层面上用到了加解密认证等东西,我肯定要考虑一个证书、口令管理系统,不可能我只把个证书放在WEB-INF目录下就完了,什么certificate.bin这样的东西就可以整个项目都拿来用了,这是不对的,不能这么干,肯定要有自己的证书和加解密管理库的。


    扩展性上的考虑:哪些层面我是可以集群的,由于是组件化设计和开发,因此哪些面可能面临数据集中访问,访问量大,可以集群扩展,一上集群后你原有的开发的程序会有很多东西需要做同步,和改动,这些我是怎么考虑的。


    兼容性上的考虑,有些客户有钱,有些客户没钱,有钱的上WAS, WEBLOGIC,没钱的上TOMCAT, JBOSS,那我的系统不可能做4套,对WAS一套,WEBLOGIC一套,对TOMCAT一套然后对JBOSS一套。我系统肯定只有一套,在WAS, WEBLOGIC, TOMCAT, JBOSS上都可以运行或者只需要装相当有限的扩展LIB库就可以运行起来对吧?


    数据库层面,JAVA跨数据库,我肯定要最起码支持主流的ORACLE, DB2, MSSQLSERVER吧,不可能会为这几个数据库各做一个版本,我肯定是只有一个版本,然后我的SQL语句就可以在DB2时支持DB2, ORACLE时支持ORACLE, MSSQLSERVER时支持MSSQLSERVER吧?(提示:当碰到绕不过去的必须使用到某个数据库的特性来写SQL时,请参照hibernate dialect的原码即实现原理去写你的SQL)


    基本写了上述这些,然后后面几天的面试与考核当然就是围绕着我第一天写的这篇文章里的技术点进行详细考核了。


    大家不知道看出来没有,出现了一堆的新东西,由其是最后3项,安全性,扩展性和兼容性。


    这里不是说我列一下这些名词就可以了,你必须把这些列出的名词都玩一把吧。


    而且我说了”商业的我会选用哪款产品,为什么,开源的我又会选用什么产品,为什么“。


    所以,要成为架构师不是说嘴上能够列出一些名词就可以了,你必须都玩过,就拿个Webservice来说,你说你会Webservice,OK,用Axis2怎么实现,JAXWS怎么实现,XFIRE怎么实现,SPRING-WS怎么实现,QOS是什么,这些你都必须学过用过才能够说得出一个所以然啊!!!不是说我光会个jaxws就说:我精通webservice了!!!


    对于实现上述这样的一个系统错误的做法是什么样的呢?


    自己设计一套数据库去做权限,很多公司这么做,就是基于RBAC原则,当然,我们可以这么做,前提是:你做的是核心系统,就是一家企业的系统从没有到有都是让你来做的,那么我们先会从权限系统下手,可以重新设计一套。


    但是当你触及到的是业务系统时,你大多时间面临的是去集成客户的权限系统和你自己的系统,因此你要想清楚如何去拿你模块自身带有的权限系统去集成客户已有的权限系统,而不是试图去用你已有的权限系统去劝说客户走你的权限模型。


    碰到审批流程化的东西时,如大量的用VISIO画出来的逻辑去写一堆的IF, ELSE,SWITCH CASE语句,HOHO,千万不要这么做。


    如果有一个流程的分支改变了,先不说你自己用IF ELSE实现的艰巨与复杂,如果一旦你改变了,可能你能够通过分析以前一堆的IF ELSE代码找到你将要新加的IF ELSE的地方,也可能因为你多加了一个IF ELSE而让原先跑得通的流程全部作废,坏掉。用引擎吧。


    如果有一个诸如:原来是a+b+c*(x/y)现在成了a+b*(x+c-d),请考虑使用规则引擎,而不是去写一堆的store procedure,因为规则引擎提供了客户自定义规则流,规则描述的图形化界面从而可以让客户去自己修改规则。

    逆波兰表达式不是让你用在这边来做复杂的企业规则的实现的,编译器原理学了不是让你自己去开发引擎的,除非你做的是科学计算机,企业级开发里请尽量使用规则引擎吧。

    因为有了规则,你可以任意去改变客户的业务规则,因为有了规则,你可以把DAO, SERVICE打包成规则上传后规则会通过CLASS LOADER自动加载而运用到客户现有的系统中从而实现不重启机器又能达到改动规则的目的,因为有了规则引擎,改变规则的事情可以交由客户的业务人员去做,因为他们自己的业务是经常的在变的,而我们程序员要做的就是给客户提供这些A,B,C,D,,E,F,G的元素,然后让客户自己去组合。


    我还看到过有用”伪规则“的开发商,这样的开发商真的要被人骂了,就是他已经有了规则这样的思想了,把规则的组织去交由客户,但是他没有用规则引擎而是做了一堆的STORE PROCEDURE,差不多有2百个之多。然后客户如果要改规则了,只要改其中的20几个STORE PROCEDURE,然后他们还会教客户如何拿个ORACLE的PLSQL/DEVELOPE客户端去让客户自己写CASE WHEN。。。天哪,把客户的业务人员也变成了IT开发人员,你够牛B,不多评价了。


    请考虑PORTAL,或者是基于WEBSERVICE的SCA编程模型,而不是自己做一堆的WAR包,然后WAR包间互相用api调用的方式来依赖,本来你已经把模块分离了,这下好,模块又依赖到了一起,伪耦合。


    有时在面对大量上传,文档管理模块时请考虑使用CMS系统或者理念,而不要自己去用记数据库的方式去实现版本控制,更不用提CMS所具有的权限整合能力了。


    做一个工程,涉及到工作流,规则引擎,CMS,SSO,PORTAL,本来这个工程已经挺大了,你除了把要实现的业务代码实现一遍,你还要自己拿个SSH,去实现工作流,规则,CMS, SSO, PORTAL本已经有的那些底层功能,那我问你,到底是在做项目还是在做这些产品,你说我都自己实现,HOHO,你牛B,等你做出来后,客户早就飞走了,项目早结束了。


    回过头来看IBM与TCS为什么成功


    所以回过头来,我们说因为IBM把它的精力集中在了开发这些BPM, CMS, SSO, BUSINESS RULZ ENGINE中间件上面了,同时,许多企业也认清了目前的大环境以及现在的客户对于项目的这一系列快,变更不触及到原有,任意替换,分析模块等要求,因此这些开发商需要有相应的,成熟的,稳定的组件拿来用啊。


    所以IBM专做这些组件,靠这些组件它发了财了。


    IT界有句笑话吗,说:有人说山上有黄金,于是来了许多人去挖黄金,结果谁都没发财!那谁最后发了财呢?山底下那个卖铲子的老头发了财了。


    那TCS呢,TCS凭借着他第一个是印度人廉价的优势,第二个它及时的把从原来的做外包,变成了”方案外包“,就是我不只,不光光只有人头给了你,而是我能够为你的项目,你的需求,从软硬件上提出一个整体的solution,就像我在回答我们的那个美国的chief architect的问题时所说的那些,数据库层我怎么样做,安全层我怎么样做,扩展性怎么样做,对于上传文档管理我是怎么去解决的,对于流程化的东西我是怎么去解决的。


    他能够提出大量的这样的solution,然后它把咨询顾问人员派到你客户这边,然后开发人员在印度、在China这边的这种“offshore(离岸式)”方式来进行开发。


    然后这样的一个系统一旦上线,我们说了,因为它是一个”解决方案“级别的,那围绕着这样的系统会有一堆的需求变更,后续开发,集成,甚至和第三方集成,那都是会被TCS吃下来的。


    这就叫”斩首行动“,就是我吃掉了你的”大头“后面的零碎的其它的外围系统就都是我的了。我要吃时,随时可以吃,我不想吃时,分点羹给你啊,对吧!


    所以国内的一些企业,由其是传统外包,巨头外包或者是一些一直做项目而现在发觉项目越来越难接的公司,你们需要转形了。


    对这些企业我想引用我前公司的的一位领导,他同时也是我的技术人生第一导师的话来说:外面其实有很多项目,但是它们不来找你,而你,找不到项目适合你来做


    结束语


    基本我先总结这些吧,所以,程序员们,你们看看,你们要学的东西还有哪些?


    SSH不是没有用,SSH是基础,是1+1=2,是九九算数表,因为你在做接口时,在开发一些底层的东西时还是需要用到SSH的,而对于一些只有“组件”才能做的事,留给组件去做吧。


    SSH不是没有用,SSH更重要了,因为它已经成了你迈向更高阶的一个踏板,没有了这个踏板,你很难上车,就算上了车你也是骑不稳的。


    如果你还还处在迷茫中,那么就是说你还没有翅膀,但你也想飞翔,那么这些东西够你学一辈子的了,相信拥有一双翅膀绝对是值得你去追求的吧?


    SOA是一个理念,现在的SOA又包括了云计算,社交网络,企业级MOBIE应用的混合应用,SOA+云,SOA+MOBILE, SOA+云等等等是近20年可能仅有的挣钱的机会了。


    因为SOA把原有的企业级开发人员,再次变成了真正的IT开发人员,在SOA理念的指导下去开发系统,IT开发人员更需要去关注于技术和业务的infrastructure即业务组合的架构和技术框架上去,而不是去实现业务;实现业务交给了业务人员,这是一种返璞归真即重新回到了IT人员做技术,业务人员做业务的时代中去了。


    我当然这边也只是发表一下自己的意见。


    我自己总结了一下,由其是还处在迷茫期的程序员,有人说:到底我干了4年,5年我还能干技术吗?还要学点什么,还差点什么,那我总结出来下面这么一张图,从上往下看:




    这张图我把它分为3层。


    从上面第一层来看,我列举出了一些行业界的优秀组件,这些组件都是和业务无关的,但又都是用来组合和集成大型业务系统时所需要用到的。因此我觉得是有必要都去熟悉,学习,运行一下的,如果有志向,应该每一个都会用并且知道分别可以在哪种场景下运用以及它们在运用和集成到你的框架时的优缺点、注意项。


    当中这一层,我觉得是一个准备走技术道路的J2EE开发人员所必须具备的,要不然你无从去了解和设计出一个跨数据库,跨平台,扩展性,安全性的J2EE系统了。


    最底下一层,是为了去满足当中这一层和最上面这一层所要具备的”基本功“,这就和1+1=2一样,这个不会,你也不要去谈四则运算了。


    要学的东西还有很多。


    你如果要来问我:还学点什么,相信此文可以回答你的问题。


    谁说技术道路走不到底?谁说30岁左右就要换PM的角色?


    技术道路也可以走下去啊!

    software engineer, senior software engineer, team leader, architect, senior architect, chief architect, principal architect


    嗯,principal architect,差不多到了这层我应该是vice president的待遇了,哈哈哈哈,估计那时我已经50岁了吧,可我依然走技术,嘿嘿!


    而我今后的篇章在前面有了SSH,性能调优,几个主要的APP SERVER的使用和调优,以及为面试准备的基础技术重温后,也将逐渐引入一个个组件化的应用,并且会在相关的例子中来向大家展现一个灵活的业务架构是怎么去设计、实现和搭建的。















    展开全文
  • 大数据时代,数据已经成为战略资源。掌握前沿科技的大型IT企业在数据的分析和利用上走在了时代的前列。...主要针对内部服务,不对外开发。III.数据分析:此处的数据分析师广义的,包括一切基于数据得出的insights的...

    数据时代,数据已经成为战略资源。掌握前沿科技的大型IT企业在数据的分析和利用上走在了时代的前列。


    0.澄清基本概念

    I.大型IT企业:指对外提供IT相关的软硬件产品及服务的公司,员工至少在万人以上。

    II.数据平台:指大型IT企业用来为自身服务为主,担负数据存储、处理、分析业务和软硬件综合。主要针对内部服务,不对外开发。

    III.数据分析:此处的数据分析师广义的,包括一切基于数据得出的insights的行为,包括统计分析、机器学习建模和预测等。

    1. T企业开展对内数据业务的驱动力

    就目前而言,IT企业针对自身的数据分析业务可以分为广告和非广告两类。对大多数企业而言,除了广告之外的数据业务,并不能直接带来可以量化的收入。

    但是,无论当前数据分析的结果为企业的现金流做了多少贡献。数据为王的思想已然占据了众多前沿企业间的头脑。数据是矿山,insights是金子,有了矿山才能有金子,有了矿山,终究会有金子。

    因此,开发数据业务最主要的驱动力,实际是对数据业务未来前景的积极预估。


    2.数据分析平台通用架构

    常见的数据分析平台,至少包括数据存储、处理和分析三个部分。

    2.1数据存储

    数据存储不必解释,是一定必要的。但是如何备份是一个很重要的问题。

    假设:某公司一年产生上千PB的数据。按照单纯数据的存储费用1美元/GB年计算,存1TB一年就是1000美元,一PB就是100万,1000PB就是10亿。如果就是简单的使用hadoop的默认配置,每份数据都存3份,那么,这个实际产生数据x 3的体量将有多大?有将有多大的cost?

    这是存储层的挑战。为了解决这个问题,一方面从硬件层面力图降低存储介质的价格,比如近年来冷存储的提出,就是针对运维费用。另一方面就是寻找备份算法。例如,yahoo专门研发了一种图片存储算法,逻辑上是11个备份,但是size只有原size的1.x倍。

    2.2数据处理

    数据处理传统上叫ETL、EDW,主要指数据的清洗、迁移和格式化。大数据平台,由于应用范畴不同,自然多种多样,源数据包括结构化数据和非结构化数据。但是如果数据真的是“大数据”(符合4V特征)的话,即使本身收集上来的数据是结构化的,也往往需要二次处理,转换format或schema。

    数据处理层所需技术相对简单,然而挑战在于对于数据的理解。如果不知道这个收集上来的log文件里面要提取出多少字段,每个字段对应数据源中的哪个部分,则数据提取完全不能进行。这就要求进行数据处理的人必须同时具备对业务的了解。

    2.3数据分析

    数据分析是数据中寻找价值的关键步骤。数据分析工作本身还处于初级阶段。除了一些简单的统计计算,大多数数据还是只能交给分析人员,进行没有特别针对性的探索,效果难以得到保证。

    对于这些挑战,开展数据业务早的公司,相应的平台和技术是在针对自身业务的过程中慢慢发展起来,部分公司选择是将平台外包或者自己开发针对自身业务的定制功能。相对于前两者,数据分析师一个业务针对性更强的步骤,因此更难采用通用方法或手段解决,更加依赖企业自身的积累。

    3.数据分析平台开源框架

    3.1开源框架

    目前,就国内而言,谈到数据分析相关的开源框架,总不能忽略下面三个:

    hadoop:batch,mapReduce
    storm:streaming
    spark:batch + streaming

    这些开源框架的共同特点是把重点放在并行计算框架上,关注的是job latency, load balance和fault recovery,对于资源分配、用户管理和权限控制几乎不考虑。它们基于的假设是:所有用户都一样,平权,所有用户都能用所有的机器以最快的可能完成所有工作。

    3.2 开源框架的局限

    而在大型企业内部,不同部门,同一部门的不同job,绝对不是平权的。不同部门之间,也有很多私密的数据,不让别人访问。不同用户的权限也是不一样的。对于计算资源的需求,因为不同job的优先级不同,也要求予以区别。

    在这种需求之下,催生了一些第三方,专门提供hadoop等开源框架的资源、权限管理产品或者服务。hadoop在升级到2以后,也考虑一些数据隔离的问题。

    但其力度,恐怕难以满足大多数大型企业的要求。这也是使用开源框架的无奈。使用开源产品的商业发行版,也是一种办法。不过始终是不如企业原生系统在这方面的支持。

    3.3企业原生框架

    确实也有些企业独立开发了全自主(不基于开源产品)的仅限于内部使用的分布式数据处理平台。在用户管理,数据访问权限,存储、运算资源管理等方面很下功夫。

    例如:要求每个用户在提交job前必须先申请token,有多少token,就有多少计算量。不同数据存储路径之间的权限完全单独管理,使用者也要实现申请权限。

    但是开发这样的系统意味着企业必须具备非常强大的研发能力,并能承担得起巨大的人力等资源的消耗。而且相对于开源系统已经实现的功能,难免有重复造轮子之嫌,即使是大型企业,也很少选取这种方案。

    4.大型IT企业数据业务的挑战

    4.1 通用挑战:意识、技术和人才

    4.1.1意识

    意识主要是指决策层的思想意识——数据对于企业发展是否真的必要?这一点在很多管理者脑子里还是存疑的,他们目前所处状态很多是:听说数据这东西有用,人家都在搞,所以我们也要搞,至于是不是真有用,搞出来看看再说。

    如果只是采用游戏或者试探态度,必然影响发展进程。但这也是没办法的事情,所有新事物都必须经历这一过程。

    4.1.2技术

    技术指目前数据分析的技术,基本是采用新框架逆流支持旧接口的策略。曾经有一篇文章,名叫《NoSQL?NO,SQL》,说的就是这个。包括spark回头支持SQL,也是如此。

    明明我们分析的是非结构化数据,但是因为高阶算法的问题,却连mapReduce都放弃了,索性回到SQL时代。为了让更多人用的舒服,不去开发针对非结构化数据的新方法,而是反过来,向下兼容结构化。个人认为这是一种逆流。这样做则永远无法避免巨大的数据处理工作。

    4.1.3人才

    “数据科学家”这个词大家肯定都知道。可是,这个职位其实很模糊,不同公司,甚至同一公司的不同部门之间对这一职位的定义相差甚远。有些数据科学家是学数学的博士,有些是以前做BI的,有些是PM转行的,水平参差不齐。

    所以,恐怕在相当长的时期里,这会是一个门槛低,要求高的职位。很难短时间内批量涌现出优秀者。

    4.2特有挑战:产品align

    产品align是说每个产品的数据分析结果可以互相对比,也就是要求其定义和实现都一致。对于一个产品众多的大企业而言,要求不同产品、流水线的分析报告具有可比性,这是一个很常见的需求。但是由于现在大多数企业中数据分析不是由一个部门统一管理,各个产品部门各自为战,结果导致在align的过程中互相牵制,进而拉低了所有产品的分析水平。

    这样的挑战有赖于企业总体数据策略的制定和执行。而整体策略的制定和执行又有赖于前面所说的三点通用挑战,环环相扣,显然不能一蹴而就。

    5.大企业数据工作的发展趋势

    短期之内,原本基于批处理模式的数据分析工作,随着业务的发展,对于其实时或者准实时(NRT)的需求越来越多。提供latency极短的增量分析和流式服务是众多企业数据分析工作的当务之急。

    从长远考虑,真正拥有数据的是大企业,未来,大企业在数据的分析利用上,也必将全面胜出小企业。

    不过,处于不同成熟阶段的大公司突破点各不同。有些技术先行,在分析方法和工具上成为领军。另一些则倾向数据管理和治理,在管理层面上,在策略、条例的制定上为整个社会提供先进经验。

    Bingdata优网助帮汇聚多平台采集的海量数据,通过大数据技术的分析及预测能力为企业提供智能化的数据分析、运营优化、投放决策、精准营销、竞品分析等整合营销服务。

    北京优网助帮信息技术有限公司(简称优网助帮)是以大数据为基础,并智能应用于整合营销的大数据公司,隶属于亨通集团。Bingdata是其旗下品牌。优网助帮团队主要来自阿里、腾讯、百度、金山、搜狐及移动、电信、联通、华为、爱立信等著名企业的技术大咖,兼有互联网与通信运营商两种基因,为大数据的算法分析提供强大的技术支撑。

    优网助帮公司优势

    ・拥有近千台服务器,每日数十亿次运算请求

    ・设有超过3万个用户标签

    ・汇聚全国6亿活跃的用户数据

    ・来自BAT一线技术工程师组成的技术算法团队

    优网助帮产品

    ▪DMarket超级数据市场

    DMarket超级数据市场深度挖掘和分析用户数据,实现跨平台的数据打通,帮助客户实现精细化营销,拥有6亿活跃独立用户的完整ID,结合多重维度和核心算法所建立的精准用户画像的数据超级市场。

    DMarket超级数据市场主要的功能

    l 对客户制定精准标签,获取精准客户。

    通过ID MAPING匹配,唤醒沉默用户。

    l 完善用户画像,定向输出数据或报告。

    ▪TalkVIP精准外呼平台

    TalkVIP基于移动互联网大数据,通过智能算法高效获取销售线索。

    Talkvip精准外呼平台的主要功能

    运用AI算法集群运算,有效筛选和锁定目标人群。

    l 可以通过电话和短信触达客户,并进行保密。

    l CRM管理功能有效管理企业数据,分析数据,最大化提高数据价值。

    l 全过程录音跟踪,可以考核电销人员工作量,话术水平。

    ▪ See广告精准投放平台

    See广告精准投放平台通过洞察用户需求,实现个性化、差异化、精准化的营销宣传服务,通过原生广告、信息流、视频广告等多种广告形式,大幅提升广告投放效率。

    See广告精准投放平台的主要功能

    l 通过数据分析进行精准客户刷选

    l 一对一个性化沟通传播体系

    l 整合全媒体网状传播

    ▪ Insight行业分析平台

    Insight拥有丰富数据量的APP行业分析平台,帮助从业者更好的决策产品方向、营销策略和投资决策等。

    Insight行业分析平台的主要功能

    l 海量数据的处理分析,为客户提供行业市场研究。

    l 提取运营指标,提供各项指标分析及科学的行业报告。

    ▪ LinkUser虚拟商品城

    LinkUser虚拟商品城是通过提供虚拟商品丰富合作伙伴的积分平台,提升用户活跃度。

    LinkUser虚拟商品城的主要功能

    l 通过灵活快捷的兑换方式,增加用户产品粘性。

    l 用户可以通过积分兑换虚拟商品,促进用户量提升。

     

     

    展开全文
  • IT企业内部系统运营推广的六种方法

    千次阅读 2016-06-23 09:22:37
    说到企业内部系统的推广,一般会认为无需推广,直接下一个通知大家都得用。说到推广的方法,很多人可能直接就想到一种方法——培训。是的,企业内部系统有其特殊性,因为用户就是自己的员工,他在这里工作就得使用...

    说到企业内部系统的推广,一般会认为无需推广,直接下一个通知大家都得用。说到推广的方法,很多人可能直接就想到一种方法——培训。是的,企业内部系统有其特殊性,因为用户就是自己的员工,他在这里工作就得使用企业的内部系统,无论其体验如何。但企业内部系统做得怎么样,是会影响“员工体验”的,影响他受雇于这家企业的满意度和继续受雇的意愿。

    也就是说,企业内部系统是员工工作环境的一部分,有必要重视企业内部系统的“员工体验”,增加大家工作的愉悦度,提高工作效率。更不用说对于金融企业来说,信息系统作为产品生产线的重要性。

    本文试图总结笔者近年来做企业内部系统运营推广的一些方法,有些是内部工作改进,有些是借鉴业内先进经验的微创新。拿出来与大家交流,很多地方还做得不够好,也请提出批评意见。

    一、提倡“用户参与设计”,通过多种方法让用户参与到系统需求和设计工作当中来。

    1. 考虑做某一系统的升级改造时,通过多种方式征集用户意见。
    2. 找业务部门进行典型用户的深度访谈,包括面对面访谈和电话深访。访谈的要点包括:进行访谈前要制定访谈提纲;要选择被访谈用户,一般一组6人左右;访谈之后要进行总结。
    3. 对于系统改造初步思路通过问卷调查的定量调研方式进行验证。通过验证的思路就作为下一步需求分析的内容。这样不至于都是按照需求方和信息部门的想法来做系统,而是一开始就把握是与用户需求合拍的。
    4. 在系统原型设计初步完成之后,找典型用户进行可用性测试,提前发现可能的使用问题,进行调整。如果调整比较大,要进行下一轮可用性测试。

    按照上述做法,在系统需求和设计阶段加强用户参与,不断验证设计思路,就避免了直到系统实施完成、甚至上线之后参与用户首次亲密接触却“见光死”的情况,保证了系统的价值性、可用性。通过用户参与设计,也让这些用户对参与设计的系统有了感情,在系统上线推广时会得到更多的助力:)

    二、加强业务测试,以测代训。

    对于一些业务项目来说,业务测试非常必要。一般来说,系统测试人员关注于系统功能是否实现,较少关注可用性,对于数据是否准确就更加不敏感。所以业务项目加强业务测试是很有必要的。

    我们进行业务测试的步骤包括:

    1. 制定业务测试方案,包括确定业务测试的形式——集中测试还是分散测试,业务测试的时间、地点,参加业务测试的人员,以及业务测试用例和测试数据准备。
    2. 执行业务测试。如果是集中业务测试,会演示待测试系统,介绍测试流程和要求。然后参加测试人员开始按照业务测试用例进行测试,记录测试意见。
    3. 业务测试意见反馈。业务部门收集业务测试意见并反馈给信息部,然后双方共同讨论确定哪些是bug要改正,哪些是需求变更并确定是本期修改还是下期修改。
    4. 系统bug修正和验证。信息部修正系统bug,然后提交业务部门验证,如果还有问题就重复步骤3和4。
    5. 业务测试验收通过后,系统达到上线要求。

    参加业务测试的过程,相关用户对系统就有了非常真切具体的了解。一旦系统上线也就能够顺利使用,甚至成为部门内使用该系统的引领者。

    三、在系统上线后的培训

    这是传统的系统推广方法,但培训也可以有多种形式,比如视频会议培训、实地培训、在线视频培训等。

    四、运用多种方式管理系统上线风险、实现平滑过渡

    新系统上线存在风险,可能导致系统上线后出现问题甚至事故,影响用户使用。有必要采取多种方式管理系统上线风险,实现平滑过渡。

    (一)业务系统改版项目

    在2013年开始的业务系统改版项目中,我们考虑到改版前后差别较大,虽然都是改进和优化,但用户的使用习惯是根深蒂固的,还是需要逐步推广。因此我们采用了以下方法:

    1. 提前实施菜单调整。该项目中对业务系统的信息架构进行了重构,改变了菜单的层次结构,对目录和菜单名称进行了规划处理,对于这一变动,我们一是发布菜单前后对比信息,二是提前在旧版业务系统中进行数据初始化,让用户有一个缓冲期。
    2. 对于新版系统在试运行阶段与旧版系统并行,用户可以选择试用新版系统。
    3. 我们选择了部分种子用户,永久使用新版系统并提出改进意见,根据种子用户的意见对新版业务系统进行多次迭代改进,解决了新版业务系统中存在的问题。
    4. 在此基础上,我们开展了新版业务系统的宣传,鼓励用户自行选择永久切换到新版系统,保护了用户意愿。

    在这个项目中,我们借鉴了业界灰度发布的方式,并结合企业实际进行了微创新,实现了新版业务系统的平滑过渡。

    (二)内部移动App

    内部移动App是面向员工的移动门户,支持移动办公、移动CRM、移动BI、移动沟通等内容。在内部移动App的推广上我们也花了不少心思:

    在上线试运行期间、正式上线前进行阿尔法测试和贝塔测试。由信息部门员工自己进行阿尔法测试(第一轮测试),在大部分问题解决、运行较为稳定后,在公司内选择部分种子用户进行贝塔测试(第二轮测试),让用户帮我们发现问题,同时也进行正式推广前的预热。

    在贝塔测试之前,我们优化了下载和安装步骤,保证部门外部用户的体验。

    五、组织用户俱乐部,建立多种渠道与用户沟通交流

    目前用户反馈系统问题、咨询系统使用的主要方式是电话和客服平台。但这两种方式都是单线联系,反馈周期也长。我们在内部移动App项目中采用了组织用户微信群的方式,让用户、产品经理、开发人员和测试人员,都加入到这个微信群,用户有问题就随时提出,团队人员也可以及时了解问题并及时对用户进行反馈。

    使用微信群建立用户俱乐部有以下好处:

    1. 在这个方式下所有的信息都是一对多的,一个用户提出问题,其他用户有这个问题也会跟进,很容易就能看出问题的严重性;对一个用户的问题进行反馈,其他用户也能看到。
    2. 用户之间会互相帮助。用户碰到的问题是类似的,很多时候用户比我们更懂系统应该怎么用。热心的用户会帮助我们回答其他用户的问题,他得到的是荣誉感和帮助他人的满足感。
    3. 研发团队及时了解用户意见,真真切切感受到用户,有助于指导产品改进、提高研发效率。这也是小米“参与感”的做法:)

    可以围绕某个产品或产品线建立微信群,这样参加的用户、产品经理、开发人员、测试人员更有针对性,沟通效率更好。

    六、打好广告,加强产品宣传

    我们还通过“打广告”的方式来宣传产品,包括在系统登录页采用轮播图形式进行宣传,在用户进入系统后可以查看系统新模块、新功能的简单图文介绍等。

    产品宣传方案设计包括以下步骤:

    1. 提炼产品卖点,用两三句话说明产品或项目的特点,让用户不用花太多精力就能获得要点;
    2. 进行视觉设计,结合产品特点,选用靓丽色彩,宣传产品/项目。
    3. 在登录页轮播宣传区域和系统项目宣传栏目进行投放,定期更换。

    企业内部系统的运营推广是一个恒久不变的话题,我们将持续改进,不断做到更好!

    展开全文
  • 关于钉钉企业内部小程序的开发 写在前面,一些踩过的坑 网上没有很多适用于钉钉小程序的ui组件库,能找到的可以用的大概是dingui-mini,但是没有说明文档,需要自己看源码 如果使用的是双屏,将开发工具放到副屏上后...
  • 通过这次培训并结合自己近6年的IT 工作经历,明白了以前很多不明白的道理。  先说说自己经历的几家公司吧,我属于那种跳槽不频繁的那种,工作6年,包括现在这家公司,我只呆过3家公司,这3家公司各有特色。 先说...
  • 国内IT项目开发流程

    千次阅读 2019-10-16 08:19:08
    参考 1、IT项目开发流程
  • 快速搭建企业内部信息推送平台

    千次阅读 2019-05-03 12:57:49
    为了解决企业内部的信息推送问题,及时、准确地将报表、订单等各种重要消息推送给员工,很多IT经理人可谓操碎了心。有没有一种可以灵活配置,能够快速与企业现有系统整合,并且费用相对低廉的企业内部信息推送解决...
  • 微信企业号开发 - 企业号配置

    千次阅读 2015-07-21 14:18:14
    微信企业号是微信为企业客户提供的移动服务,旨在提供...企业号作为企业IT 移动化解决方案,相比企业自己开发APP 具有明显的优势,具体为:1) 快速移动化办公。企业在开通企业号后,可以直接利用微信及企业号的基础能力
  • 敏捷开发作为最近的时髦词汇,已经迅速席卷了IT界,以前Agile的使用仅仅适用于网站和手机APP的开发范围,而今传统企业IT也想引进Agile模式,来打造新的企业IT服务模式。Agile的好处我 敏捷开发作为最近的时髦词汇,...
  • 企业IT建设方法论

    千次阅读 多人点赞 2018-10-31 15:09:02
    相信当很多人听到IT或者IT行业一词,第一反应都是高端大气上档次,同样的,IT一词也会常常伴随着几个关键词:高薪、白领、高科技、有前途,很多莘莘学子在选择专业的时候也会向着该行业发展。笔者曾经也是这么认为的...
  • IT企业IT经理如何管理IT人力资源 (这个题目看...因此企业内部IT人力资源的"选"、"育"、"用"、"留"各方面都需要IT经理更多的参与。对任何一家公司来说,一线业务员是公司的关注重点。在IT企业中,IT技术人员就是一
  • 财务核算在企业日常管理中起着不可代替的作用,为了促进企业内部管理水平的提高,需要及时、准确、全面的财务数据分析作为参考与支撑。鉴于制药企业目前的财务报表层面现状。需要一个能够集中体现企业财务核算状况的...
  • 【转】大企业的敏捷开发

    千次阅读 2016-06-11 20:48:05
    如今敏捷开发已经成为初创企业的标配,如果运用得当,它能大幅提升企业的创新效率。然而在人数众多、层级复杂的大企业,敏捷开发能实现么? 转自【2016-06-01 BCG波士顿咨询】谁说只有小企业才能敏捷开发?这5招让...
  • 企业IT部门的职责和定位

    千次阅读 2010-07-06 16:58:00
    企业IT部门有各种各样的名称,这不重要,重要的是职责、定位和实际上起到的作用。我的经验是原来规定的部门职责是什么是一回事,企业对部门的真实期望是一回事,你IT部门是否真正履行好相应的职责又是另外一回事,而...
  • 企业内部信息统一搜索解决方案

    千次阅读 2013-05-29 18:05:33
    前段时间在给一家世界500强企业做咨询,课题是企业级门户的搜索策略。 光看这个课题,大家肯定会联想到谷歌,Bing,百度之类的搜索引擎。对企业搜索有些接触的人,也许会联想到Autonomy(国外知名搜索服务提供商)...
  • 企业IT架构—共享服务体系

    千次阅读 2019-03-29 14:23:06
    最近阅读了《企业IT架构转型之道》,感触较大,和我们公司这几年遇到的问题有很多相似之处,如果能够早几年看到这本书,一定能少走很多弯路,下面说说我对共享服务体系的感受。 先介绍一下这...
  • Java版本微信企业号的开发--01

    千次阅读 2016-04-20 21:58:41
    2016年04月18日企业微信也正式发布了,个人觉得微信企业号的开发也就没有太大意义了,毕竟是腾讯亲生的,很多接口人家都不放出来,但是公司要做我们程序员有什么办法呢,呵呵……。这是我自己第一次写博文,有写的...
  • 企业IT部门的职责和定位(转)

    千次阅读 2010-07-31 15:47:00
        企业IT部门有各种各样的名称,这不重要,重要的是职责、定位和实际上起到的作用。我的经验是原来规定的部门职责是什么是一回事,企业对部门的真实期望是一回事,你IT部门是否真正履行好相应的...
  • 企业IT 能力成熟度评估

    千次阅读 2008-03-06 12:31:00
    通过笔者接触的多家企业和调研发现,行业领先型企业IT建设方面普遍起步较早,通过管理信息化变革有力的推动了企业的发展,如华为在97年实施Oracle大型ERP,其后经过了IT战略规划,集成产品开发(IPD)及大型PDM...
  • J2EE企业开发规范

    千次阅读 热门讨论 2014-04-02 19:38:30
    J2EE是一套全然不同于传统应用开发的...保留现存的IT资产 高效的开发 支持异构环境 可伸缩 结构图       标准规范   1.JDBC(javaDataBase Connectivity): 是一种用于执行SQL语句的Ja
  • IT应用和下一代企业的关系

    万次阅读 2014-04-03 11:38:06
    IT应用和下一代企业的关系一、云IT应用和现在IT的优劣势对比1、安全:从技术安全角度来说,公有云确实比咱们现在IT安全要更安全一些。为什么这么说?因为做云服务目前面临最大的客户迟疑就是安全,所以研发商在...
  • 中国国有IT企业

    千次阅读 2012-09-02 10:33:53
    谁是最受雇员欢迎的中国IT企业? 不要跟我们提惠普、IBM、微软那种国际上数一数二的巨头,它们把根深扎在中国本土,就是要最大可能地吸收营养,为了吸引人才,他们浑身解数都施展开来。但是,毕竟再本土化也是...
  • 企业IT架构的规划思考

    千次阅读 2012-07-12 11:38:45
    更确切地说,当时的应用系统开发主要是出于对部门级或分行级应用的考虑,还谈不上企业级的架构。随着银行业务的发展,对数据的要求发生了变化,从而出现了新的数据架构的考虑,因此,“大集中”开始成为主流。  ...
  • 企业微信自建应用开发初探

    千次阅读 2019-04-02 13:30:00
    同时企业微信作为一个开发平台,企业可以根据需要开发定制自己的企业应用集成到企业微信上。ABC WeChat是我们公司为ABC开发的基于企业微信的一款应用(因保密需要,这里用ABC代替公司名称)。本文以该项目为例对在...
  • 规则引擎-BRMS在企业开发中的应用

    万次阅读 多人点赞 2016-10-17 12:07:54
    复杂企业级项目的开发以及其中随外部条件不断变化的业务规则(business logic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策,并把这些商业决策放在中心数据库或其他统一的地方,让它们能在运行时...
  • 企业IT架构面临的问题及解决之道

    千次阅读 2018-01-29 09:49:37
    中国企业信息化也走过了从无到有,从有到多,从多到散的过程。我们可以将这个过程叫做“企业信息化...必须通过“企业信息化整合”来优化IT架构,提升IT价值,企业信息化已经进入到全面整合的新阶段。 1、企业
  • 本书从阿里巴巴启动中台战略说起,详细阐述共享服务体系如何给企业的业务发展提供了支持。介绍阿里巴巴在建设共享服务体系时如何进行技术框架选择,构建了哪些重要的技术平台等,此外,还介绍了组织架构和体制如何更...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 92,450
精华内容 36,980
关键字:

企业it内部开发