锁定老帖子 主题:我理解的互联网应用和企业应用开发
精华帖 (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这类小众语言,太过灵活,团队一大,很容易失控。我没有在项目中实战过,只是曾经研究、学习,不敢妄自发言。 好了,就写到这里。 这篇文章,我还没有谈到产品经理在内容建设方面的职责。像电子商务网站,在内容这块投入的人力成本,如产品图片和文字等,仅次于开发。产品经理在内容建设上,是一个纲领性角色。 这篇文章,只属于启发性,还谈不上总结。估计几年后,会出现比较成熟的互联网开发方法学。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2011-07-12
支持。。。。。。
|
|
返回顶楼 | |
发表时间:2011-07-12
文章太长了,用一张表格来做对比,列出关键要素即可。
|
|
返回顶楼 | |
发表时间: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这类小众语言,太过灵活,团队一大,很容易失控。我没有在项目中实战过,只是曾经研究、学习,不敢妄自发言。 好了,就写到这里。 这篇文章,我还没有谈到产品经理在内容建设方面的职责。像电子商务网站,在内容这块投入的人力成本,如产品图片和文字等,仅次于开发。产品经理在内容建设上,是一个纲领性角色。 这篇文章,只属于启发性,还谈不上总结。估计几年后,会出现比较成熟的互联网开发方法学。 |
|
返回顶楼 | |
发表时间:2011-07-15
说的不错,有些地方很受用
|
|
返回顶楼 | |
发表时间:2011-07-15
部分赞同
|
|
返回顶楼 | |
发表时间:2011-07-15
最后修改:2011-07-15
说实话,我不大喜欢看楼主的文章风格。
教条,古板。可能有人喜欢这种严谨风格。 这些手段在互联网和企业应用都会有一些交叉,因人而异。 互联网公司,也是企业,也会有企业应用。但是做这些事的很有可能是同一批团队,即使不是同一个团队,也会是同一个技术老大 |
|
返回顶楼 | |
发表时间:2011-07-15
在互联网公司开发企业应用,跟lz所谈的就不一样了,最近准备写篇这样的文字
|
|
返回顶楼 | |
发表时间:2011-07-15
sslaowan 写道 在互联网公司开发企业应用,跟lz所谈的就不一样了,最近准备写篇这样的文字
写完后别忘了在这儿通告一下哦。 我也有自己的经历和视角盲点,希望看到其它人的看法。 |
|
返回顶楼 | |
发表时间:2011-07-15
nighthawk 写道 说实话,我不大喜欢看楼主的文章风格。
教条,古板。可能有人喜欢这种严谨风格。 这些手段在互联网和企业应用都会有一些交叉,因人而异。 互联网公司,也是企业,也会有企业应用。但是做这些事的很有可能是同一批团队,即使不是同一个团队,也会是同一个技术老大 我确实确实有些教条、古板,文风即人风。但你也知道,改变自己的性格或风格是不现实的,也没必要。 互联网应用开发方法学,是一个新领域,在IT界目前还停留在感觉和经验阶段,但企业应用开发方法学就成熟多了,我在这儿发表一点我的肤浅看法,也是想为了更深入的思考。 我有自知之明,目前写的文章基本上都没啥深度。 |
|
返回顶楼 | |