我理解的互联网应用和企业应用开发
前段时间，我写过一篇
该主题的博客，但写完了，我觉得还是没有谈到本质，这篇文章算是续篇。
互联网应用(网站或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这类小众语言，太过灵活，团队一大，很容易失控。我没有在项目中实战过，只是曾经研究、学习，不敢妄自发言。
好了，就写到这里。
这篇文章，我还没有谈到产品经理在内容建设方面的职责。像电子商务网站，在内容这块投入的人力成本，如产品图片和文字等，仅次于开发。产品经理在内容建设上，是一个纲领性角色。
这篇文章，只属于启发性，还谈不上总结。估计几年后，会出现比较成熟的互联网开发方法学。
互联网应用(网站或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这类小众语言，太过灵活，团队一大，很容易失控。我没有在项目中实战过，只是曾经研究、学习，不敢妄自发言。
好了，就写到这里。
这篇文章，我还没有谈到产品经理在内容建设方面的职责。像电子商务网站，在内容这块投入的人力成本，如产品图片和文字等，仅次于开发。产品经理在内容建设上，是一个纲领性角色。
这篇文章，只属于启发性，还谈不上总结。估计几年后，会出现比较成熟的互联网开发方法学。