传统软件企业向互联网企业的转型

2005年我提出将公司CRM产品向SaaS化发展的战略时，很多人都认为那是一个巨大的冒险，而如今已经没有人再质疑传统软件向SaaS化发展的趋势。很多决心向互联网产品转型的企业，都会遇到这样一个问题，传统的项目化的业务模式利润越来越薄，而投向互联网的产品又屡屡碰壁，不是产品迟迟无法成型，就是资金烧不起。怎样才能顺利的完成这样的转化，本文将在这方面进行探索。

三大误区

近些年互联网在商业上的巨大成功，特别是这几年移动互联网的迅猛发展，许多新的产品和新的企业骤然崛起，在墙外的人们总不自觉的看着成功企业靓丽的光环，并误以为那就是其本质。我常见到的误区有三个：互联网必须烧钱、要先明确盈利模式、沉迷于新技术和新概念。这一章节，我们对这些想法一一抽丝剥茧。

误区一：烧钱就是互联网

近十年互联网企业的烧钱模式是深入人心，可烧钱的背后是什么呢？我们先看一看烧钱成功的案例。

首先是京东，众人皆知京东持续亏损，直到2017年才真正实现盈利，但这是不是烧钱模式呢？我们来看看下图。

从2012年到2017年，京东整个公司的总资产和固定资产都急剧攀升十倍以上，而其平台的GMV（商品交易总额）更是从2012年的733亿扩大到2017年的将近1.3万亿，增长将近20倍。于此同时，淘宝和天猫的GMV总额，从2012年过万亿到2017年的3.77万亿，增长不足4倍。

京东是在亏损，但亏损的背后我们要看到几点：

一、京东是有毛利的，对于他们所销售的单品来看，基本都是高于进价销售的，所以会有毛利，但是均摊掉公司运营成本、物流建设成本、营销成本等，最后就变成了亏损的状态。

二、京东的亏损是有意控制在一定范围，相比京东的资产、估值，亏损只是非常小的一部分，京东一直将亏损控制在合理可接受的范围内，并未对企业的经营造成什么不良的影响。

三、京东每年营收都急剧扩大（年均超过50%）。 假设京东今年360亿营收，亏20亿，延期还款一个月，那么京东到年底手里的钱反而多出了10亿！（30亿应付账款，减20亿亏损）。假设明年京东营收540亿，又亏20亿，但年底手里只会减少5亿（45亿应付账款，减20亿亏损，再付掉去年留下的30亿应付账款）。所以只要京东的营收越来越多，而亏损不是大幅增加的话，京东手里的现金流足够用很多年！

京东这种靠现金结算流的烧钱模式，是互联网才有的吗？根本不是，相比稍微年长一些的人都会记得当年国美和苏宁疯狂开店的时代。是的，美苏就是靠现金结算流进行资本动作来赚钱的。举个例子：假如我每天给你1万，注意是每天都给，要求你3个月之后还我1万，注意也是每天都还，你一年的现金流就是365万。你挣钱了吗？天天有进有出，他们赚的就是起初的90万和365万的现金流还有银行的利息，道理很简单。美苏，假设一年100亿营收，延迟三个月还款，手里就是25亿现金流！延迟六个月还款，手里就是50亿！假设疯狂开店扩大现金流，一年200亿营收了，延迟三个月还款，手里就是50亿，延迟六个月，就是100亿！

所以我们可以得出一个结论，京东的烧钱模式并不是互联网才出现的，国美的开店潮，房地产的快速发展都是这种模式，在快速成长的行业里，只要现金流充足，一定幅度的亏损并不意味着是在烧钱，而京东通过压低产品价格，投入自营物流配送和提供优质的售后服务，虽然增加了成本，降低了利润，但在用户快速成长的生命周期里，他获得了最快速的增长。

接着我们来回顾滴滴和快的烧钱大战。

微信5.0改版后，2013年9月份滴滴接入微信与手Q，打车服务用户群体与移动支付用户天然重合，腾讯开始借滴滴推送微信支付。2014年1月份，随着腾讯1亿美金融资到位，滴滴补贴大战陷入疯狂状态，随后在阿里支持下快的跟进，这场补贴/支付大战一直打到5月份才告一段落，双方烧掉近20亿元，堪称惨烈。

前些日子，马化腾在长江商学院的一次内部分享会上坦言，这场补贴烧钱大战教育了用户，推动了移动支付在中国的普及，这是让他意想不到的一个收获。说是意想不到，恐怕不见得，这场大战虽然迅速拉高了滴滴和快的日订单数飙升到数十万，但其真实目的却不在于此，君不见烧钱大战三年后的现如今，各种专车打车APP又开始增多，滴滴的日订单量也缓慢回落到15万，可是你见到滴滴还有挑起新的补贴大战吗？当时腾讯和滴滴发起，阿里和快的跟进之迅速，足以说明这场大战根本目的不在于打车市场，而在于争夺更庞大的移动支付市场。

我们可以看到成功的产品，他们的一个共同点在于利用互联网以及移动互联网的特性，为用户带了更方便快捷的体验，京东为用户提供了更方便却更有品质的购物体验，滴滴快的为用户解决了打的难的问题，移动支付更是改变了整个中国的支付习惯。而支付只是在他们产品已经得到用户认可，商业模型已经得到基本验证后，为了快速扩大用户数，抢占市场，获取垄断地位的一种手段，而不是天真的以为烧钱就可以换来用户的认可。

我们也来看一个烧钱失败的案例。

不知是否还有人记得2000年的时候，各一线城市街头出现的大大小小的亿唐广告牌，“今天你是否亿唐”的那句仿效雅虎的广告词，让亿唐整个网站一时风光无限。亿唐从两家著名美国风险投资DFJ、SevinRosen手中拿到两期共5000万美元左右的融资，在全国范围快速“烧钱”：除了在北京、广州、深圳三地建立分公司外，亿唐还广招人手，并在各地进行规模浩大的宣传造势活动。2000年年底，互联网的寒冬突如其来，亿唐钱烧光了大半，仍然无法盈利。此后的转型也一直没有取得成功，2008年的亿唐公司只剩下空壳，昔日的“梦幻团队”在公司烧光钱后也纷纷选择出走。2009年5月，etang.com域名由于无续费被公开竞拍，最终的竞投人以3.5万美元的价格投得。

说完这些，大家或许还记得这个公司名，可是这个公司到底做什么的，还有人记得吗？那时的亿唐网内容贪大求全，毫无特色：几乎门户有的东西，亿唐当时都有。作为一个综合性网站，亿唐拥有亿唐主题、新闻报道、蝶女性网、亿唐校园、亿唐卡、职业直通车、财经纵横、亿唐房屋八个纵深频道。但没有一样真正拿得出手，互联网“一白遮百丑”的规则被视而不见。在那段疯狂烧钱的岁月里，唐海松及其领导的亿唐从网站到手表全都做，甚至投资250万元参与拍摄了20集电视连续剧《真情告白》的续集。更有传闻称亿唐在两个月里，就“烧”掉了1亿元人民币。

大部分烧钱失败的产品背后的团队都多少有这样一个特点：缺乏对自身的清晰定位，人浮于事，没有沉下心做出帮用户解决实际问题的产品，而只是幻想用钱就可以砸出一个互联网的企业。而实际上一个成熟的互联网产品在需要极速扩大用户群的时候或许需要使用烧钱的方式作为手段，但切不可反过来以为烧钱就有可能砸出一个产品。

误区二：必须先明确盈利模式

如果在你产品的初期，整个业务模型还没有成型，也未得到第一批铁杆用户的认可，就开始精细的打量这个产品的盈利模式，这就有些像建立空中楼阁了。产品为客户解决什么问题，可以带来怎样的便利，客户为何会喜欢并长期使用这个产品，这才是一开始需要琢磨和思考的最基本的事情。

事实上作为一个企业的战略级的产品，其本身是可以不盈利的，因为它可以帮助你的其他产品获得利润。比如微信。靠微信上的位置，先后入股了京东、点评、美团点评、滴滴、摩拜等小巨头。靠微信上的位置，给游戏导流，进而获得利润。靠微信和手Q，强推了应用宝，进而使应用宝的装机量变得特别大，然后收开发者的钱。靠微信上的腾讯新闻插件强推了腾讯新闻和天天快报，进而卖腾讯新闻和天天快报的广告位。靠微信公众号上的视频强推了腾讯视频，进而做大腾讯视频，买视频贴片广告，这是通过战略产品的引流在其他产品上变现的路径。

对于一个在传统软件领域已经有一定规模的企业，向互联网方向转型时首先不应该想某一个产品，而应是规划服务的方向和未来面对的用户群体。方向和用户群体不能太宽泛，一定要知道自己的最终目标是什么，基于这个目标，哪些是可以为其他产品引流的战略级产品，哪些是有利润爆发点的产品，哪些是赔本赚吆喝的产品。对于不同层次的产品要区别对待。战略级产品即使盈利点不明朗也应当全力做大做强，有利润爆发点的产品应当集中资源开发迅速铺向市场，赔本赚吆喝的产品应当用最少的投入维持基本运作。互联网产品，尤其是移动互联网产品，其生命力的关键是用户的粘性，一个能帮用户解决问题，并且提供长期高频使用场景的产品应当就是公司的战略级产品，在原有的优势之上找到这样的产品是一个传统软件企业转型期需要时刻牢记并积极探索的重中之重。

误区三：沉迷于新技术和新概念

近些年好多新的技术名词和新的概念随着互联网的发展应运而生，身边一个个做项目开发的公司也开始在自己的产品里面套用起这些新的名词，比如几年前还挺新潮的OLAP（联机分析处理，俗称报表）没人提了，都在说大数据了；几年前还挺牛掰的数据挖掘也没人说了，都在说深度学习了；甚至刚流行起来的分布式概念也好像要被区块链取代了。似乎没有产品没有革命性的突破，不用一点新潮流的技术，就不是互联网的产品似的。企业为了营销，为了迎合客户，不得已使用这些名词也就罢了，如果企业内部搞产品的研究技术的人们，也被这些概念牵着鼻子走，那就真是把自己给忽悠瘸了。

新技术的使用首先要取决于产品的实际需求，比如一个明显的关系型结构的数据环境，仅仅因为预估数据量会达到了千万或亿级，就迫不及待的宣布要在一开始就用MongoDB等NoSQL的数据库，而忽视了这些数据库因为没有ACID可能导致的问题，在这些数据库中的数据一致性是需要额外的代码去小心翼翼的维护的，实际上我就在多个项目中看到缺乏实际经验盲目使用NoSQL数据库带来了数据不一致的严重问题。如果当你知道淘宝的核心数据库依然在用MySQL，并可以支持TB级的日访问，会有何感想呢？

OLAP就可以实现的产品功能，却一定要用Hadoop的Map/Reduce；用简单的分析模型就可以得出的数据挖掘方案，却一定要用深度学习去展开训练；更适合传统关系型数据库的场景，却盲目相信NoSQL数据库的高效；企业没有经历过插件化和模块化的沉淀，项目内代码的可复用性还很低的时候，却相信微服务的魔力。这些天真浪漫的以为新技术可以解决所有问题的想法，常常使一个本来有希望的产品在孕育初期就人为的叠加了重重困难。

互联网产品初期通常并不会太过复杂，使用合适的技术快速上线、快速试错、小版本快迭代，是互联网产品不同于传统型软件开发的重要特点。但这不是代表我们排斥新技术，而是要在合适的时间使用合适的技术，这也需要技术决策者们对技术的了解有一定的宽广度。比如产品以简单的Document式的数据为主，没有副本，没有数据不一致的可能，那为何不一开始就使用更合适的NoSQL数据库，而抱着关系型数据库不放呢？

互联网的产品有时会遇到爆发性的增长，在产品的发展过程中如果还抱着初期的架构不放，不与时俱进，那也是不行，在埋头叠加新功能的时候，作为产品的开发者，必须也做好在架构中引入新技术的规划。合适的时间做合适的事情，说起来容易，真正做到却是很难的。

产品转型三步走

讨论到产品转型的问题，为了更流畅的描述问题，这一章节将主要以传统的CRM服务提供商的角度进行探讨。典型的传统的CRM服务提供商，通常都是有一个基础的产品，然后根据每一个客户的需求不同进行二次开发。有些产品模块化做的好一些，积累的模块多一些，二次开发周期就短一些；有些模块化做的不足的，客户需求特例比较多的，二次开发周期就长一些。产品转型要顺利实现三步走，必须在思维上就有所转变。

首先是业务规划。传统项目的思维是：开会，讨论，定义清楚方向，然后再讨论，方向实现的细节，然后再讨论。有时碰到问题，发现走不通了，甚至会推翻重来。互联网的思维是：挑一个方向，先做起来，如果错了，改方向，继续走。快速上线、快速试错、快速决策、共同负责。

其次是需求梳理。传统项目的思维是：自己无法提出有效需求，只能按用户表面需求走，不看数据（因为没上线根本没有），遇到问题拍脑袋。互联网的思维是：开始阶段拍脑袋，运营一段看实际数据，从用户、运营、产品、商务各个方面收集需求，由产品经理牵头处理。

然后是产品设计。传统项目的思维是：先按一个个功能点计算人天工作量，根据工期定人员或者反过来根据人员定工期，遇到工期太短的情况，砍功能。互联网的思维是：需求全部列出来，按紧急重要程度排序，按顺序开发。

最后是运营心态。传统项目的思维是：定项目范围、定需求，开发完了了事。互联网的思维是：让消费者进入到产品的整个生命周期中来。消费者不再是那个只面对销售终端的对象。而是应该让消费者融入到售前，包括需求调研、产品研发、产品改进中来。同时企业应与消费者建立直接的联系，利用新媒体手段与消费者产生情感连接，形成品牌印象。

第一步：已有产品向互联网和移动互联网转化

已有产品加上多用户管理就照抄到互联网之上，是最容易设想的方式，但实际上这样并不符合互联网产品的思维。首先照抄上去的产品规模较大，无法做到快速上线、快速试错，铁杆用户将无法参与到产品的生命周期中来；其次产品功能分散，重点不明确，难上手。已有产品向互联网的转化应当突出重点，针对一个场景将少部分的重点功能先移植上去。

在前几年各大品牌纷纷在天猫、京东这样的电商平台开旗舰店的契机，传统CRM就可以有针对性的将一些功能打包成为一个针对电商平台的SaaS系统。电商的促销活动与传统商场的促销有过之而不及，那么原来的促销模块就可以加强后移植到线上；销售运营分析部分（主要是OLAP）依然很重要，需要移植到线上；电商渠道不再需要大区库房和零售店铺库房，那么库房管理部分就可以简化；原有的会员卡服务在电商渠道不再重要，就可以省略掉。在需要移植的功能中，又可以根据重要程度分优先级，以最快速度的上线第一个版本为前提，迅速让铁杆用户试用，快速试错快速迭代新版本。

第二步：明确未来整体方向和服务对象

将已有产品移植到线上，是一个传统企业体会互联网产品的过程，这个过程中，需要同步的思考企业未来的整体方向。

传统的CRM服务提供商，一直以来都缺乏对C端用户的直接联系，同时原有客户现如今也纷纷在电商平台转移，未来还会进一步有互联网化的需求，对于这些客户来说如何打通线上线下也是未来生存的关键问题，由此继续专注于B端客户群，帮助他们解决互联网运营的一系列问题，提供线上线下的经营提供全天候的支持，这无疑是很适合的一个方向。

这个方向是不是真的适合企业，并不是凭空想象就可以知道的，只有在实践中去发现问题去寻找解决方案。有可能因为产品的规划缺失和开发能力的不足，丧失了占领市场的先机；有可能因为市场营销的互联网转变不够，无法承载支撑整个方向的产品，而只能将精力集中在小部分的细分领域。本文专注于讨论产品设计和研发在企业转型中的问题，但实际上一个传统的企业要真正转向互联网的企业，从来不是一两个部门的事情，而是从上至下，上下一心的结果。

第三步：形成自己的互联网及移动互联网的产品组合

将自身产品以一个切入点进入互联网，并明确未来方向之后，就应当谋划整套产品体系了。一个企业的产品体系可以是腾讯这样的一两个战略级产品作为引流入口，其他产品附加之上实现利润。也可以是今日头条这样的，数个产品（今日头条、西瓜视频、抖音短视频、火山小视频、悟空问答、内涵段子）都与内容分发相关，数个战略产品并存，均以广告收益为主的体系。

CRM服务提供商们可以为传统的品牌商们提供怎样的产品体系呢？

首先是帮助有一定规模客户代运营，包括电商店铺管理、品牌营销、网络推广（精准广告）、客服以及仓储。对于传统的品牌商或许已有客服和仓储，但他们对互联网化的推广方式和营销手段了解并不深；对于电商兴起之后的新兴的品牌商通常客服和仓储都是缺失的。

其次是现在的新零售的概念。新零售不仅仅是线上线下与物流结合的一体化销售，而是像互联网产品一样，让消费者深入到品牌产品的方方面面，用数据打通消费者认知、兴趣、购买、忠诚及分享反馈的全链路，并在品牌策略、品牌传播和品牌运营全方位精细支撑。今后VR技术在零售店铺的引入，RFID和各种体感传感器的使用，客户购买诉求的精准分析和广告更为精确的投放，产品的各种个性化定制，这些都将彻底改变零售业态，要实现这些，各品牌商们更加需要强大的IT服务的支撑。这些产品都是传统CRM企业转型去思考和选择的方向。

互联网时代，传统软件企业，特别是项目为主的企业，利润率越来越低，但互联网带来了生存危机的同时，又提供了更广阔的可能。因为互联网的格局下，其他行业对信息化产品的需求不是降低了，而是更高了。中国IT服务的整个市场规模这些年都以20%的幅度增长，以“智研咨询集团”的预计，2021年中国整个IT服务的市场规模将超过万亿。

技术转型三步走

这二十年软件架构的体系的演进过程大致可以归纳为四个阶段，从早到晚分别是：单体架构、模块化架构（垂直架构）、SOA架构和微服务架构。架构的演变只有一个目的，就是化整为零，将一个大的系统拆分成可以组装的小系统，从而将软件系统的耦合性尽可能的降低，并让小系统可以变得可重复使用。

结合我原来的工作经历，我们来看看架构的变化可以带来哪些好处。

任何一种软件系统都遍布着查询的功能，尤其是CRM这样的企业信息管理系统，销售查询、库房查询、客户查询、采购查询等等。一个单体架构的系统，常常也会使用一些表格控件，来辅助开发众多的查询，如基于JQuery的表格控件datatables.js，使用这样的表格控件就是模块化了吗？不，还不算。因为开发者依然要深层次的将这些控件嵌入到代码中，耦合度依然不低。

以使用datatables.js为例，我们在前端WEB页面要嵌入这样的代码：

还要在服务后端嵌入类似这样的代码（PHP代码）：

完成这些代码，我们可以看到以下的界面：

如果我们需要加上分页和过滤的功能，还需要分别在前端和后端加上更多的代码。不仅如此，每开发一个查询功能，我们都要重复以上的工作。

那么一个模块化的查询控件需要做什么呢？只需要配置一句SQL：

如果没有配置映射字典，那么配置文件要稍微增加一句，变为：

完成这样简单的配置，就可以得到如下的界面：

可以看到，不仅可以按字段进行过滤，还包含了分页。这就是模块化架构相比单体架构的一个重要优势：开发效率更高。但不可否认，完成这样的查询模块也是有代价的，它需要为模块的开发投入工作量，但只要是可以重复使用的场景，模块化都是非常值得的，因为随着在今后的使用功能越来越多，边际成本将越来越低。

除了开发效率更高，模块化另一个重要作用是功能扩展成本低。例如，在上面的查询基础上，产品经理提出要加入实时统计的功能，如果还是传统的模式，必然导致需要重构该功能点，而模块化之后，不需要任何改变，就可以得到：

当然我们也不是魔法师，虽然不需要对业务功能点改动任何代码，但还是需要对该模块增加统计分析的功能的。在我们的实践中，模块的重构远远低于每一个功能点的重构，而使用该模块的功能点越多，这个成本优势会越来越明显。

互联网的今天模块化不是终点，微服务架构开始盛行，它又带来什么变化？

传统软件企业，无论是新产品上线还是定制新的功能，都会经历需求分析、设计、开发和测试这么几个阶段，周期都会比较长。但互联网的产品有所不同，前文已经阐述，互联网的产品版本迭代周期都很短，遵循着快速上线、快速试错的原则。周期越来越短，但对系统稳定性要求却越来越高，模块化架构的思路开始出现瓶颈。

我们依然以查询统计控件为例，随着数据越来越多，部分日志型数据将转用elasticsearch（ES）数据库，这时我们需要在控件中支持ES的查询。假如此时因为开发人员在连接的控制上出现BUG，某种情况触发了内存泄漏，可想而知，这时候会导致整个查询模块的崩溃，如果垂直切分不够完善，严重的情况下甚至可能导致整个系统的崩溃。微服务架构下会有帮助吗？

我们来看看微服务架构下查询统计控件的架构的新变化。

左边的模块化架构，虽然已经在控件内部做了功能切分，但是新增ES执行组件（橙色）后，查询控件需要重新打包代码后部署上线，由于控件是作为一个整体部署在一个应用容器中，新增组件的严重BUG将有可能导致整个控件的崩溃。

右边的微服务架构，原有的查询服务、SQL服务与新增的ES服务（橙色）是三个独立的小系统，分别部署在不同的应用容器中，此时若ES服务内部出现BUG，只会导致ES服务的崩溃，这一分离的架构将新的服务引发的问题与原有服务隔绝开，而不会影响原有应用的正常运行。不仅如此，相比较整个查询控件的重新测试和部署，测试和部署一个微服务的速度要快得多，这正符合互联网产品的需要。

但微服务架构不是软件行业的银弹，带来了好处的同时，也会带来一些问题：

一、测试难度增加，必须用自动化测试来替代传统的手工测试。因为微服务对外的接口只是Service API，而不是用户可以看到的界面，如果没有编写自动化测试脚本的能力，微服务的测试无从开展。

二、运维难度增加。从原来只需要管理一个系统，变为管理多个微服务的子系统，多个微服务之间也需要用配置文件将他们连接起来，这种网状的结构，随着微服务的数量增加，其运维工作的复杂度将几何级数的增长。传统的开发人员打包程序，交给运维工程师去手动部署上线的运维方式已经无法适应微服务架构，正因为如此，“谁开发谁运行（You build it, you run it）”的DevOps理念开始流行。

三、监控难度增加。每个微服务就是一个子系统，都运行在一个应用容器之上，每个容器都有自身的服务状态、接口调用情况、异常告警等诸多信息，监控的复杂度成倍增长。正因为这一特点，互联网的SaaS产品可以用微服务架构，但部署在客户服务器或私有云上的传统软件产品就很难采取微服务架构，因为这对集中监控有很高的要求。但后续篇章我们会谈到，Docker这一事物或许将改变这一问题，并带来新的可能性。

微服务架构是现在最适合互联网产品的一种技术架构，但不代表传统软件企业就可以直接拿过来使用。在技术方面，如果你的自动化测试、自动化运维和监控没有达到要求，微服务架构只会给你增加工作量；在管理方面，如果你还是传统的开发流程和组织架构，做不到向DevOps的方向靠拢，无法适应小版本快迭代的要求，微服务架构同样会给你带来很多的混乱。

第一步：模块化架构

模块化的架构，不仅仅适用于互联网产品，对于一些还处于单体架构阶段的传统软件企业，应首先向模块化架构转型。在实践过程中有几点心得：

一、敢想敢做。在事务性的工作压力面前，由于对模块化额外工作量的担忧，企业的技术管理者们常常会在第一步就停滞不前，设想的多，但迟迟不动手。实际上只要在实际工作中有共性的，可重复性的功能集合，都可以考虑模块化的思路将他们整合为一个模块。

二、从小到大。模块化设计的时候，人们常常会想的太多，希望一次解决所有想到的问题，使得一开始的复杂度就很高。过高的期望，过于复杂的设想，会导致模块化的工作量太大，这导致要么畏惧工作量而中止工作，要么周期过长而最终出来的产品事与愿违。在我们的实践中，好的模块第一版的开发工作都会控制在两周的时间，这样尽快上线一个版本，然后交给其他团队去使用，在使用的过程中收集意见，不断迭代新的功能，往往比一开始就设计很周全的效果好的多。

三、眼界宽广。开源组织的发展已经很多年了，各种开源工具和产品层出不穷，多关注开源社区的发展，多看看别人的项目，不仅可以扩展自己的思路，还常常可以找到合适的项目加以改造和重新组合后，成为适合自己企业的模块。

四、包容失败。模块化之路有成功，也可能有失败，如果遇到失败的情况，应当检讨事情哪些做的不好，也可以检讨人选哪里选的不对，但不能遇到失败就放弃模块化的道路。

五、临时组建。有些企业在一开始就会组建专业化的组织（如架构组、控件组等）去专心开发模块，但这样做会很容易使他们与业务工作分离，成员逐渐脱离生产的实际需要，出现闭门造车的问题。事实上应该是在实际的开发工作中发掘出模块化的功能需求，这时应当有少数的几个人临时组建一个开发组，快速开发出来，然后推广使用。如果一个模块功能越来越复杂，平时维护和升级的工作量都很大，那么可以针对这一个模块成立固定的开发组，专门负责它的开发工作。从生产实践中寻找模块化的需求，会比成立只负责模块开发的专业组的效率更高，开发出来的产品也更能符合业务的需要。

第二步：敏捷型组织

技术的转型不仅仅是架构的问题，还是组织形式的问题和开发流程的问题。敏捷开发模式不仅仅适用于微服务架构的技术体系，也可以为传统产品的开发提供帮助。组织的敏捷化主要体现四方面：

一、小版本快迭代，不要试图一次开发一个大版本，一个版本的开发周期应当尽可能的缩短。

二、测试驱动开发（TDD），TDD不是说产品不需要思考和设计就直接开始构建测试代码，而是将需求分解为任务列表，再从列表中挑选一批任务，转换为一组测试用例，然后不断循环去实现。

三、持续集成持续交付，不要试图在版本的末期才提交整套代码，而应当至少每天实现一次构建和集成，充分利用测试用例的覆盖，在代码提交的当时就立刻发现问题解决问题。

四、开发与运营的紧密结合，打破传统项目型企业中开发、QA、运维、运营之间各部门的鸿沟，建立以业务为主线的整套协作流程。

第三步：微服务架构

当你的技术人员适应了模块化的思维方式，当你的组织与开发流程进行了敏捷化的改造了，更重要的是当你的产品逐渐往互联网发展了，你一定会自然而然的产生向微服务架构的体系转型的冲动。这时可以着手在五个方面进行准备：

一、业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。

二、服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。

三、自动化测试用例高度覆盖：微服务架构一个明显的变化就是随着服务的增多，测试的复杂度显著增加。如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。

四、自动运维 ：微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。

五、监控：包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务架构。

没有什么事情是一撮而就的，微服务的架构也不是一步就能全面实施的，在工作中有规划的推进，逐步的准备，微服务架构的建设也就顺理成章完成了。

三点注意

第一点：要注意从传统项目孵化互联网产品的思想

很多时候企业会得到一些看起来与市面上互联网产品类似的项目，于是乎决策者们就开始设想完成这个项目后顺带孵化出一款互联网的产品，我就曾经在工作中遇到这样的事情，这样的思维逻辑下会产生以下三个无法调和的矛盾。

首先项目与互联网产品的迭代方式不同，项目通常以交付工期作为迭代周期，而互联网产品要求快发布快验证。如果项目里面也采取互联网产品的快发布快验证，项目的最终客户会有耐心去帮你审核半成品吗？

其次项目与互联网产品的目标不同，我之前就遇到过的希望通过运营商的用户感知体验的项目孵化出APM产品，而运营商侧重的是终端用户的测试结果，而APM的目标群体是各ICP，而ICP更侧重的是结合终端用户的测试结果查看服务器端的运行问题。这不同的客户群体不同的产品目的，两个产品的需求和体验截然不同，甚至应当是完全不同的产品。

最后是项目与互联网产品的管理模式不同，不同的管理模式就意味着不同的考核办法，考核办法又间接影响开发人员的思想。当你想做好项目时，它离互联网产品的体验就越来越远；当你想更符合互联网产品的体验时，项目的范围和工期将不可控。鱼与熊掌不可兼得也。

或许这时候有人会问，那我开发完项目之后，有了一定的技术经验再去开发互联网产品不是就可以了吗？首先我们在上面就指出项目与互联网产品可以说是两个南辕北辙的事物，重新再开发互联网的产品并不一定能规避什么技术风险，反而因为原来项目的惯性思维可能会固化你的思路。这样又不省钱又固化思维的事情，做起来又有什么意义呢？

第二点：要注意大而全的闭门造车的思想

一个产品如果初期版本设计太过庞大，就很容易陷入闭门造车的怪圈，因为你无法最快速的获得运营数据，也无法与客户有效的进行交流，获取真实的体验和需求。只能采取闷头瞎想，下意识或者自动忽略对于产品基本需求的科学性调研，只是单方面地认为某个群体有某种需求。

产品上线后，也要避免不自觉地虚拟出用户的需求或者片面扩大用户的需求。不要去主观想，不要去替用户考虑，要做的只是访谈，有引导的焦点会议，有导向性的用户研讨会，设计思路清晰的调查问卷，同时要在产品中采集实际的运营数据，学习结合实际数据去分析用户的需求。

第三点：要注意生搬硬套沿用传统项目的KPI考核模式

传统项目的考核总是避不开利润计算、工作效率、责任归属等指标的划分，而这种呆板的考核模式并不符合互联网产品的思维。互联网产品强调快速上线、快速试错，出了问题快速决策，集体负责，根本没有时间给你划分责任的归属问题，自然也无法很有效的用KPI去计算工作效率，互联网产品的特性则更加难以计算一个开发周期的利润指标。

未来的可能

随着微服务架构与基于容器的虚拟化（Docker为代表）的发展，未来十年的软件行业会产生非常大的变化，应用将由各种微服务组合而成，软件开发领域将划分为两类人群，一类是微服务的开发者，另一类是微服务的组装者。软件应用的开发将越来越像现代工业产品的开发模式：零部件的开发与产品的组装。微服务的开发者专注于单一微服务功能的实现；微服务的组装者关注如何将已有的微服务组装起来成为客户需要的完整产品，组装者需要只是为不同微服务的连接开发一些适配程序，而不再关注单一功能的细节如何实现。

在这样的远景的前提下，未来的软件领域还可能出现一些新的事物：

一、微服务商城。类似于App Store，提供各种微服务的购买、下载与安装，商城不仅提供单一的微服务，还提供各种打包好的套件。

二、微服务外包。不同于现在的软件外包形式，未来IT服务提供商们不再考虑一个项目完全由自己开发，而是专注于设计业务模型，将市面上已有的微服务的组装成自己的产品提供给客户。对于一些特例的需要单独开发的微服务则采取外包的方式交给第三方的微服务开发者。

三、新的云形态。一方面未来企业对涉及商业机密的数据要求越来越高，同时基于容器的运维管理工具越来越丰富，而容器很容易移植的特点，私有云将逐渐在企业市场占据主导地位。另一方面随着物联网的发展，每个家庭都遍布各种智能设备，个人隐私信息的保护也将逐渐严格起来，管理自身设备的家庭云和个人云也将开始出现。

四、服务标准化。对于查询、统计、报表、权限、工作流等通用服务，业界内部将逐渐形成标准化的服务接口；对于库房、订单、采购等行业内通用服务，在该行业内部也可能逐渐形成统一的标准。

微服务的商城如何运作，微服务如何定价并保护知识产权，开源社区将有哪些新发展，服务标准如何形成，组织形式和开发流程又会有哪些新的改变，未来软件从业人员的有哪些新的要求，以上问题的思考我将在今后的系列文章《未来十年的互联网》一一阐述。