论坛首页 综合技术论坛

我理解的互联网应用和企业应用开发

浏览 10275 次
精华帖 (1) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2011-07-12   最后修改:2011-07-12
前段时间,我写过一篇该主题的博客,但写完了,我觉得还是没有谈到本质,这篇文章算是续篇。

互联网应用(网站或app),和企业应用的本质区别,应该从用户谈起。
互联网是陌生用户,网站对于他们来说是自助系统(类似于ATM取款机),不需要、也不可能对他们强制培训,比如用户注册。所以它们要做得绝对的弱智化,尽量降低学习成本。

企业应用是公司员工,带有强制性,而且上岗前、或系统上线前,一般都有培训,比如工行柜台员工那个Windows客户端的功能,比如存款,都是通过输入“2397”调出的。相对于互联网应用,用户体验并不是优先考虑的。但有一点会很重视,那就是便捷性,如快捷键,因为这些应用一般都是运营系统,员工每天都是重复做那些事情,效率很关键。

特别提示,像淘宝网,前台网站是互联网应用,供买家使用产品、订单模块属于企业应用。
对于一家B2C电子商务公司,往往既有前台的互联网应用,也有后台的业务系统。因为前后台的高度耦合性,如前台订单提交和状态,必须和后台的订单处理流程对应,导致项目很难外包给第三方软件公司,互联网公司一般都有自己的IT开发团队。将软件分包,需要很高的项目管理水平:开发过程解耦+模块解耦。目前,互联网开发外包刚刚起步。

用户行为驱动 vs 业务流程驱动
互联网是用户行为(意图)驱动,带有随机性,而且不同的用户有不同的浏览习惯。比如我google东西时,一般会先打开上10个页面,然后才一个个看。再比如豆瓣网的书籍详细页:书籍评分、查看类似的书、查看书评、添加书评等,并没有严格的逻辑或流程。同一个书籍界面,书商(作者)、读者、点评者,对该页面的关注点都不一样,就如同企业应用里面的不同用户角色,登录到系统看到的界面不一样。
而且,用户查到该书后,他的浏览顺序、下一步操作都有随机性。很可能因为网站速度慢,他点击了关闭。

这样的系统如何设计?核心原则:研究用户进入该页面的场景,在该场景下用户的需求,以及在此需求下产生的行为。比如购书网站,用户从比价网进来,第一关注点是折扣和促销;如果用户是购买过程中不经意看到一本陌生书,那么他会关注该书的目录和评价;如果用户已经在购物车添加了一本书,那么他会看一下“其他用户还购买了…”。

其实,企业应用也是这样,Use Case里就特别强调了Business Scenarios(业务场景)。
因为企业应用一般是协作式系统,协作式系统涉及到协作流程,也就是工作流,比如订单处理流程、病人应诊流程。当然了,也有很多模块是没有流程的,如交电费(电力CRM)。但它们基本上都可以抽象为表格+表单+流程。

互联网用户的行为习惯是自己练就的,而企业应用的用户习惯,更多是培训出来的。互联网用户行为极不稳定,比如20岁的年轻人浏览网页非常浮躁,到30多岁就沉稳多了;在网页臭长臭长的年代,鼠标滚轮就被派上了用场。而企业应用,界面操作一般是流程驱动,而流程可能上10年都是那样,用户操作相对比较稳定、线性。

界面原型 vs 领域模型
无论是互联网应用还是企业应用,稍微复杂点,一般都会出架构图,如部署图(可能4+1架构视图有点教条),如根据负载,一台服务器只做批处理(数据同步和发送邮件),一台服务器只做搜索查询。

比较复杂的业务系统,我们倾向于在需求分析阶段,开发用例图、领域模型图、序列图。当然,我也见过,很简单的业务系统也画一堆图,然后被开发人员扔到垃圾堆里,其实,一个excel功能需求表就可以解决。

对于互联网应用,界面即需求,往往不需要给业务需求建模:领域模型图和序列图等基本上没法用。性能和可伸缩性等非功能需求,可以以功能列表归纳。

软件过程
因为需求过程的成果物不同,传统的那套软件开发方法:从需求规格说明书到详细设计,即使是RUP等迭代过程,也很难照搬。

互联网进化快,用户需求非常不稳定,它们往往都是在运营过程中改进;系统上线后,偏向于维护而不是迭代开发。估计若干年都不会出现针对互联网领域的业务组件库,但在企业应用领域却很普遍,比如SAP的NetWeaver里针对行业的组件库。

互联网应用,一般均采用敏捷过程。但这种敏捷过程,我们往往搬过来都很教条,如燃尽图和每日站立会议。其实它们解决的就是进度和沟通的,本质上也就是风险控制。这些方法学层面的东西,在《职业经理人》课程里面,都是常识:时间管理、沟通管理、团队管理等等。
敏捷是一种理念,不是一种方法学,虽然最终要落实到方法学。什么叫川菜,什么叫东北菜?一看就知道,但我们需要用辣椒和酱油来衡量吗?

IT人员构成
做企业应用项目,一般有三种角色:技术、需求、管理。
技术:架构师、高级工程师、工程师、设计师
需求:需求分析师
管理:项目经理PM、技术经理TL
上面我忽视掉了配置管理和测试等角色。

对于互联网项目,角色和上面差不多。
技术:也是架构师、高级工程师、工程师,但设计师普遍比做企业应用的强一个层次。因为他需要处理界面风格、易用性、浏览器兼容性、SEO等。
需求:产品经理+公司业务人员,可能还会配上用户体验专员(交互设计师)。
对于企业应用,偏向于分析性归纳思维(向内),它只要求你抽象出的软件,能够match当前的业务;而互联网应用,更多是偏向创造性思维(向外),比如SNS网站的like、poke按钮,极大活跃了用户互动。
管理:项目经理PM,可能由产品经理PD担当,看项目规模了。可能还有技术经理TL,负责技术人员的绩效管理。

两种不同的人员构成,主要体现在需求人员上。互联网需求,是挖掘出来的;企业应用需求,是梳理出来的。企业应用你可以做业务调研,但互联网应用,你调研谁?像中国移动财大气粗,可以花十分钟做一次电话调查,但这往往是选择题,选择就意味着封闭。像苹果iOS中的窗口,并没有关闭、最大化、滚动条,这些创造性功能,是不可能通过用户访谈得到的。

技术架构
做企业应用的那一套,如Hibernate,我是不建议用在互联网上的。Hibernate解决领域模型的持久化很有效,而互联网应用,偏向于页面而不是领域模型。
另外,互联网应用偏向于读,而不是写操作,这和企业应用是反过来的,Hibernate主要是解决持久化(写)。
Hibernate的性能、级联查询,基本上在互联网上很难有作为。
如果用Java,我倾向于Spring MVC+Spring JDBC,前台做URLRewrite。企业应用那种三层架构、五层架构,在互联网开发上,一定要谨慎。

谈到开发语言,可以选择Java,这和.Net基本上没啥差别,看你的团队精通哪种了。因为它们在团队协作性方面都很强(静态编译型),有强大的开发工具来规范团队行为,对项目可维护性也很有益。
当然了,如果团队不大,php应该是首选,因为它操作数据库非常简单、高效、灵活。php优势特别是在部署上面,因为互联网应用部署非常频繁,Java一部署就重启app,原来session全部丢失,这绝不是一个小问题。
对于Ruby这类小众语言,太过灵活,团队一大,很容易失控。我没有在项目中实战过,只是曾经研究、学习,不敢妄自发言。

好了,就写到这里。
这篇文章,我还没有谈到产品经理在内容建设方面的职责。像电子商务网站,在内容这块投入的人力成本,如产品图片和文字等,仅次于开发。产品经理在内容建设上,是一个纲领性角色。

这篇文章,只属于启发性,还谈不上总结。估计几年后,会出现比较成熟的互联网开发方法学。


   发表时间:2011-07-12  
支持。。。。。。
0 请登录后投票
   发表时间:2011-07-12  
文章太长了,用一张表格来做对比,列出关键要素即可。
0 请登录后投票
   发表时间:2011-07-12  
zwchen 写道
前段时间,我写过一篇该主题的博客,但写完了,我觉得还是没有谈到本质,这篇文章算是续篇。

互联网应用(网站或app),和企业应用的本质区别,应该从用户谈起。
互联网是陌生用户,网站对于他们来说是自助系统(类似于ATM取款机),不需要、也不可能对他们强制培训,比如用户注册。所以它们要做得绝对的弱智化,尽量降低学习成本。

企业应用是公司员工,带有强制性,而且上岗前、或系统上线前,一般都有培训,比如工行柜台员工那个Windows客户端的功能,比如存款,都是通过输入“2397”调出的。相对于互联网应用,用户体验并不是优先考虑的。但有一点会很重视,那就是便捷性,如快捷键,因为这些应用一般都是运营系统,员工每天都是重复做那些事情,效率很关键。

特别提示,像淘宝网,前台网站是互联网应用,供买家使用产品、订单模块属于企业应用。
对于一家B2C电子商务公司,往往既有前台的互联网应用,也有后台的业务系统。因为前后台的高度耦合性,如前台订单提交和状态,必须和后台的订单处理流程对应,导致项目很难外包给第三方软件公司,互联网公司一般都有自己的IT开发团队。将软件分包,需要很高的项目管理水平:开发过程解耦+模块解耦。目前,互联网开发外包刚刚起步。

用户行为驱动 vs 业务流程驱动
互联网是用户行为(意图)驱动,带有随机性,而且不同的用户有不同的浏览习惯。比如我google东西时,一般会先打开上10个页面,然后才一个个看。再比如豆瓣网的书籍详细页:书籍评分、查看类似的书、查看书评、添加书评等,并没有严格的逻辑或流程。同一个书籍界面,书商(作者)、读者、点评者,对该页面的关注点都不一样,就如同企业应用里面的不同用户角色,登录到系统看到的界面不一样。
而且,用户查到该书后,他的浏览顺序、下一步操作都有随机性。很可能因为网站速度慢,他点击了关闭。

这样的系统如何设计?核心原则:研究用户进入该页面的场景,在该场景下用户的需求,以及在此需求下产生的行为。比如购书网站,用户从比价网进来,第一关注点是折扣和促销;如果用户是购买过程中不经意看到一本陌生书,那么他会关注该书的目录和评价;如果用户已经在购物车添加了一本书,那么他会看一下“其他用户还购买了…”。

其实,企业应用也是这样,Use Case里就特别强调了Business Scenarios(业务场景)。
因为企业应用一般是协作式系统,协作式系统涉及到协作流程,也就是工作流,比如订单处理流程、病人应诊流程。当然了,也有很多模块是没有流程的,如交电费(电力CRM)。但它们基本上都可以抽象为表格+表单+流程。

互联网用户的行为习惯是自己练就的,而企业应用的用户习惯,更多是培训出来的。互联网用户行为极不稳定,比如20岁的年轻人浏览网页非常浮躁,到30多岁就沉稳多了;在网页臭长臭长的年代,鼠标滚轮就被派上了用场。而企业应用,界面操作一般是流程驱动,而流程可能上10年都是那样,用户操作相对比较稳定、线性。

界面原型 vs 领域模型
无论是互联网应用还是企业应用,稍微复杂点,一般都会出架构图,如部署图(可能4+1架构视图有点教条),如根据负载,一台服务器只做批处理(数据同步和发送邮件),一台服务器只做搜索查询。

比较复杂的业务系统,我们倾向于在需求分析阶段,开发用例图、领域模型图、序列图。当然,我也见过,很简单的业务系统也画一堆图,然后被开发人员扔到垃圾堆里,其实,一个excel功能需求表就可以解决。

对于互联网应用,界面即需求,往往不需要给业务需求建模:领域模型图和序列图等基本上没法用。性能和可伸缩性等非功能需求,可以以功能列表归纳。

软件过程
因为需求过程的成果物不同,传统的那套软件开发方法:从需求规格说明书到详细设计,即使是RUP等迭代过程,也很难照搬。

互联网进化快,用户需求非常不稳定,它们往往都是在运营过程中改进;系统上线后,偏向于维护而不是迭代开发。估计若干年都不会出现针对互联网领域的业务组件库,但在企业应用领域却很普遍,比如SAP的NetWeaver里针对行业的组件库。

互联网应用,一般均采用敏捷过程。但这种敏捷过程,我们往往搬过来都很教条,如燃尽图和每日站立会议。其实它们解决的就是进度和沟通的,本质上也就是风险控制。这些方法学层面的东西,在《职业经理人》课程里面,都是常识:时间管理、沟通管理、团队管理等等。
敏捷是一种理念,不是一种方法学,虽然最终要落实到方法学。什么叫川菜,什么叫东北菜?一看就知道,但我们需要用辣椒和酱油来衡量吗?

IT人员构成
做企业应用项目,一般有三种角色:技术、需求、管理。
技术:架构师、高级工程师、工程师、设计师
需求:需求分析师
管理:项目经理PM、技术经理TL
上面我忽视掉了配置管理和测试等角色。

对于互联网项目,角色和上面差不多。
技术:也是架构师、高级工程师、工程师,但设计师普遍比做企业应用的强一个层次。因为他需要处理界面风格、易用性、浏览器兼容性、SEO等。
需求:产品经理+公司业务人员,可能还会配上用户体验专员(交互设计师)。
对于企业应用,偏向于分析性归纳思维(向内),它只要求你抽象出的软件,能够match当前的业务;而互联网应用,更多是偏向创造性思维(向外),比如SNS网站的like、poke按钮,极大活跃了用户互动。
管理:项目经理PM,可能由产品经理PD担当,看项目规模了。可能还有技术经理TL,负责技术人员的绩效管理。

两种不同的人员构成,主要体现在需求人员上。互联网需求,是挖掘出来的;企业应用需求,是梳理出来的。企业应用你可以做业务调研,但互联网应用,你调研谁?像中国移动财大气粗,可以花十分钟做一次电话调查,但这往往是选择题,选择就意味着封闭。像苹果iOS中的窗口,并没有关闭、最大化、滚动条,这些创造性功能,是不可能通过用户访谈得到的。

技术架构
做企业应用的那一套,如Hibernate,我是不建议用在互联网上的。Hibernate解决领域模型的持久化很有效,而互联网应用,偏向于页面而不是领域模型。
另外,互联网应用偏向于读,而不是写操作,这和企业应用是反过来的,Hibernate主要是解决持久化(写)。
Hibernate的性能、级联查询,基本上在互联网上很难有作为。
如果用Java,我倾向于Spring MVC+Spring JDBC,前台做URLRewrite。企业应用那种三层架构、五层架构,在互联网开发上,一定要谨慎。

谈到开发语言,可以选择Java,这和.Net基本上没啥差别,看你的团队精通哪种了。因为它们在团队协作性方面都很强(静态编译型),有强大的开发工具来规范团队行为,对项目可维护性也很有益。
当然了,如果团队不大,php应该是首选,因为它操作数据库非常简单、高效、灵活。php优势特别是在部署上面,因为互联网应用部署非常频繁,Java一部署就重启app,原来session全部丢失,这绝不是一个小问题。
对于Ruby这类小众语言,太过灵活,团队一大,很容易失控。我没有在项目中实战过,只是曾经研究、学习,不敢妄自发言。

好了,就写到这里。
这篇文章,我还没有谈到产品经理在内容建设方面的职责。像电子商务网站,在内容这块投入的人力成本,如产品图片和文字等,仅次于开发。产品经理在内容建设上,是一个纲领性角色。

这篇文章,只属于启发性,还谈不上总结。估计几年后,会出现比较成熟的互联网开发方法学。



0 请登录后投票
   发表时间:2011-07-15  
说的不错,有些地方很受用
0 请登录后投票
   发表时间:2011-07-15  
部分赞同

0 请登录后投票
   发表时间:2011-07-15   最后修改:2011-07-15
说实话,我不大喜欢看楼主的文章风格。
教条,古板。可能有人喜欢这种严谨风格。

这些手段在互联网和企业应用都会有一些交叉,因人而异。

互联网公司,也是企业,也会有企业应用。但是做这些事的很有可能是同一批团队,即使不是同一个团队,也会是同一个技术老大
0 请登录后投票
   发表时间:2011-07-15  
在互联网公司开发企业应用,跟lz所谈的就不一样了,最近准备写篇这样的文字
0 请登录后投票
   发表时间:2011-07-15  
sslaowan 写道
在互联网公司开发企业应用,跟lz所谈的就不一样了,最近准备写篇这样的文字

写完后别忘了在这儿通告一下哦。
我也有自己的经历和视角盲点,希望看到其它人的看法。
0 请登录后投票
   发表时间:2011-07-15  
nighthawk 写道
说实话,我不大喜欢看楼主的文章风格。
教条,古板。可能有人喜欢这种严谨风格。

这些手段在互联网和企业应用都会有一些交叉,因人而异。

互联网公司,也是企业,也会有企业应用。但是做这些事的很有可能是同一批团队,即使不是同一个团队,也会是同一个技术老大

我确实确实有些教条、古板,文风即人风。但你也知道,改变自己的性格或风格是不现实的,也没必要。

互联网应用开发方法学,是一个新领域,在IT界目前还停留在感觉和经验阶段,但企业应用开发方法学就成熟多了,我在这儿发表一点我的肤浅看法,也是想为了更深入的思考。

我有自知之明,目前写的文章基本上都没啥深度。



0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics