适应随机多变的客户需求的系统建设

一.引言

为了使得阅读过程生趣形象，先来分享两个故事。

• 第一个是我亲身经历的事情：2013年一次偶然的机会，在工作中接触到复旦大学的一个朋友，有天他带我去复旦大学软件学院的一个实验室里，这是一个5个人的研发团队，他们正在做CRM系统(客户管理+电话坐席系统)。我之前在软件公司工作过，给客户做过CRM产品，在我印象中项目的整套流程是：

1.客户提出需求
2.产品经理对接，绘制产品原型
3.产品原型交给项目经理
4.项目经理开会讨论需求，分配开发任务，制定开发计划
5.开发完交付给测试人员
6.测试完交付给客户
……
整套系统从0到交付给客户，大概需要2个多月时间，如果后期有类似客户也做一套CRM系统，那么复制之前的那套系统，根据需求来修修改改，大概一个月时间完成。那个复旦大学实验室的团队leader告诉我们：“我们帮客户做一套CRM系统，只需要一杯咖啡的时间，差不多20分钟吧”。我被当时的场景所震惊，可能会记住一辈子吧。

• 另一个故事是在计算机刊文中看到的：在芬兰有一家游戏公司叫supercell，是世界顶级游戏公司巨头，开发过全球热门游戏，比如《部落冲突》《海岛奇兵》《皇室战争》《荒野乱斗》等等，但是公司规模不大，只有一百多人(对比国内的游戏公司，动辄上千人的规模，有点惭愧)，他们自己开发游戏，自己运营，同时也为全球很多公司开发游戏，类似于游戏外包。腾讯在收购supercell之前，启动一个项目一般要组建百八十人的开发团队，并且996工作节奏，大概需求N..天的周期。但是芬兰supercell公司开发一款新游戏，需要大概十个人规模的团队，并且在非常快的时间内交付产品，后来腾讯眼馋了，收购了supercell。当时看到这里同样是震惊，怎么有似曾相识的感觉…

二.客户画像

揣摩别人的心思是大忌，玩得好能得势，玩不好要栽跟头。和珅善于揣摩乾隆的心思，得势一生。反例：李善长喜欢揣摩朱元璋的心思，爱耍小聪明，结果被诛九族…但是现在是民主文明社会，对于我们做产品的人就应该要善于揣摩客户的心思，有时候恨不得想成为客户肚里的蛔虫。

• 客户有两方面需求：一个是业务需求，一个是服务需求。简单描述为：客户在业务上需要使用系统平台，能满足他各方面的功能需求，界面通俗易懂，操作便捷，能够7×24小时随时待命，任何时候都不卡顿，数据只对他喜欢的人可见，不喜欢的人一律不可见，数据永远不会丢失。凡是现实生活中享受不到的服务，他都想享受到，活在梦幻中是每个客户的梦想。
• 客户有两个使用产品的方式，一种是定制化软件，独立部署在客户的服务器上；另一种是云软件，客户打开浏览器或者下载APP或者直接在微信中使用第三方软件。分析下两种方式的利和弊，客户需要的是能满足他业务使用，但是不想自己公司内增加一个软件维护人员，希望委托软件服务商来帮他维护软件，如果是独立部署模式，假如软件出现故障或者需求要改动，他们联系软件服务商尽快解决，软件服务商回复他：更新好了会通知您的。然后客户就会陷入漫长的等待过程，所有涉及到软件方面的业务全部暂停。如果软件服务商给很多客户部署了类似的产品，那么一旦软件中出现一个突发性的故障，软件服务商只能挨个给客户修复，改完这个客户再到下个客户。优先级怎么排呢？当然是大客户优先，小客户慢慢等着吧，那些小客户就悲催了。如果是云软件模式，软件中突然出现一个故障，这个故障会对所有使用该功能的用户可见，即使客户自己不向软件服务商反馈，其他客户也会向软件服务商反馈的，软件服务商会立马修复，并且只需要修改一处，所有客户都会更新，不用挨个客户去修复。好比如：我如果想用办公软件，我宁愿用钉钉，我也不愿意用软件公司给我定制的一套办公软件，即使钉钉每个月让我付钱，我也愿意…
• 至于软件升级考虑，一般软件一个版本的寿命平均不超过两年，如果是独立部署软件，版本升级的工作对每个客户都是重复性的工作，对软件服务商会损失耗能，而云软件只需要做一次工作即可。
• 至于数据隔离和安全考虑，不论是独立部署软件还是云软件，维护工作都是由软件服务商来做的，数据没办法对软件服务商隐蔽，软件服务商还是能获得到客户的数据，只能通过签订保密协议等方式来规避。
• 综上所述，从各个方面分析得出，云软件模式对客户和软件服务商双方都是利大于弊。

三.常规软件建设原理

一般性软件建设的流程是(复制上面的)：

1.客户提出需求 -> 2.产品经理对接+绘制产品原型 -> 3.产品原型交给项目经理 -> 4.项目经理开会讨论需求+分配开发任务+制定开发计划 -> 5.开发完交付给测试人员 -> 6.测试完交付给客户 -> ...

如果是类似的软件，把之前开发的软件复制一份，在此基础上来动手术，改造成符合客户需求的软件，但是还是存在问题：如果新的软件较老的软件，流程上有大的变动，那么新软件开发是个大型外科手术，可能要修改核心功能和架构，要知道改造规模过大还不如重建的好，工程量就会增加了。
用通俗接地气的文字，简单介绍传统软件建设过程：

1.终端

最终呈现给客户的是一个个操作界面（浏览器页面，APP页面等），每个页面里有各种数据字段，字段包含列表字段，详情字段，表单录入字段（必填字段或非必填字段）；页面中包含按钮，提供用户操作；页面中包含弹框，我们可以称之为子页面；页面中有对话框，用来和用户进行信息交流。总结为：最终给到客户的是页面和子页面，字段，按钮，对话框和交互。

2.页面和子页面

在软件中，通俗来说：一个页面对应一个软件模块。不过也包括，多个相关联的页面对应的是同一个模块，比如订单列表页面，订单编辑和订单详情页面对应的是同一个模块：订单模块。在项目工程中这些页面对应是具体的程序文件，程序文件控制着页面的显示。所以当客户提出需求，需要开发某个页面的时候，开发工程师要做的工作是：1.编码出相对应的程序文件；2.根据模块设计对应的数据表，比如订单模块对应订单表，但是此时数据表是空白的，没有字段，因为要经过下一步才能在表中增加字段（普及一下：数据库是一个存储数据的机器，数据库包含很多数据表，比如订单表，车辆表，每张表里有很多字段）。你可以想象成当前只是定义好了tab名称的空白Excel表格

3.字段

需求模块对应页面，那么信息数据对应的是字段。字段包含独立字段，关联字段。独立字段如姓名，身份证等，一个字段表示一个具体的数据信息；关联字段如银行名和银行编码，银行名和银行编码是一一对应关系，再例如：安徽省和合肥市，芜湖市属于关联字段，它们之间存在某种关系。另一类关联字段如：产品类型和产品规格，比如裤子和尺寸+腰围，货车和载重+吨位，它们之间本身并没有直接的关联，而是在具体的业务场景里，人们主观上把它们牵连到一起，最终形成了一种惯性思维，他们具有行业特有属性，以至于提到货车，自然会想到载重+吨位，但是载重+吨位也适用于其他的领域；开发工程师得到客户给出的字段之后，他们的工作是：1.把这些字段定义为程序文件里的属性，变量；2.在相应的数据表里增加字段。当前可以想象成定义好格式的Excel文件，只是没有数据而已…

4.按钮

页面和字段是用户获取信息的基本单元，用户与软件之间交互需要通过按钮来传达。按钮包含：打开，关闭，编辑，查看，跳转，事件操作(确认付款，审核通过，审核驳回等等)。数据信息通过页面来展示给用户，但是页面是静态的，用户需要动态的与数据信息交互，通过按钮可以实现创建数据，浏览数据，修改数据。开发工程师为每一个按钮所对应的事件编码相应的程序文件，程序文件里包含很多功能函数，一个按钮对应一个特定的功能函数，比如保存按钮对应一个功能函数，查看按钮对应一个功能函数…如果按钮事件要修改数据，那么功能函数里所要做的工作是：1.从数据库或者文件里获取源数据；2.对数据加工处理得到新数据；3.新数据写回源数据的位置；如果按钮事件是需要与外部通讯，比如把数据发送到省平台，那么功能函数里所要做的工作是：1.从数据库或者文件里获取源数据；2.按照省平台的要求，把数据组装成对方要求的格式；3.把格式化后的数据通过网络发送到省平台的主机；4.省平台回应接收成功，该事务完结。

5.弹框

弹框是页面的补充，也可以理解为一个子页面，弹框里可以包含页面+字段+按钮，在软件里，把弹框也当做页面来处理，开发工程师所做的工作和上面的内容一样。

6.跳转

以上介绍了一个完整页面所包含的内容，也介绍了开发工程师开发一个页面所做的工作。一个软件或者系统，通常由很多个页面组成，页面之间的关联来自于现实业务间的关联，业务的关联性通过跳转来呈现。开发人员视作一个页面为一个开发单元，这也是软件工程所提倡的，比如一个软件工程由多人参与，把一个页面作为一个开发任务，然后任务分配到每个人身上，这也是团队协作开发的基础模式。那么开发完单独页面之后，页面之间的关联性在程序文件中通过“传参”的方式来达到契合。举个栗子：电商平台里，从购物车页面进入到付款页面，购物车页面对应一个程序文件，付款页面对应一个程序文件，付款页面的程序文件怎么才能辨别出是某某用户选择了某些商品呢？其实就是：购物车程序文件通过“数据传参”的方式传达到付款程序文件，“数据传参”携带有具体的用户和具体的商品，这样在付款页面就可以对具体用户和具体商品来处理，比如为孟康这个用户创建付款单数据，修改商品的库存等等……

7.数据仓库

软件的数据包含：业务数据，文件数据，行为管理数据。

• 业务数据指每个业务场景对应的数据，这些数据通过不同的数据表来隔离（数据库由多个数据表组成），比如运单相关数据组成一个数据表叫运单表，车辆相关数据组成一个数据表叫车辆表，数据表具有固定的格式，数据是按照矩阵方式来组成的，类似于上面的Excel表格，每一行代表一条数据，其中的某一列表示这条数据的属性（属性可以理解为字段），比如用户创建了一条运单数据，这条数据占据一行，运单里有装货地字段，装货地就是这条数据的一个属性。而数据可以包含很多属性字段，开发工程师根据用户的需求来设计数据表，用户提出的业务需求中需要哪些字段，开发工程师就建哪些字段（加字段可以理解为在Excel中加一列）。用户创建数据就是在数据表中插入一行数据，每一行数据对应唯一的ID，查看数据就是从数据表中通过ID查询一条数据，修改数据就是在数据表里通过ID修改整行数据或者只修改部分属性字段。
• 文件数据指软件中非文本类数据，包含图片，合同文件，表格文件等。这些数据不存储在数据库中，它们存储在磁盘中，由用户上传而产生，这种数据很容易理解，一个文件占据一块磁盘空间，不多解释了。
• 行为管理数据指非用户需求数据，包含用户行为数据，系统检测数据，权限划分数据等。用户行为数据是用户在软件中的操作行为日志数据，用于追踪用户的行为轨迹，日后在业务操作中产生纠纷，可以作为凭证。系统检测数据是指系统检测用户提交的数据，或者外部发送过来的数据，也包含系统自身检测所产生的数据。权限划分数据指不用人员授权操作的数据，不同的人员只能授权软件的部分页面或者操作。

8.鸟瞰

通过上面的描述，基本了解了一个软件工程的原理。软件工程起源于客户的需求，是一个工程的发起点。客户的需求传导到产品设计人员，产品设计人员绘制出产品草图，然后给到开发人员，开发人员按照业务来划分模块，然后每个页面对应着不同的程序文件，为页面中每个按钮和事件编写功能函数，不同模块对应着不同的数据表，页面中的字段对应数据表的某个属性，业务流程通过页面跳转来衔接，对应不同程序文件之间使用“传参”来达成契合。好了，软件工程就按照这样的模式有条不紊的进行下去，直到开发结束->测试结束->交付客户。

四.思考和挑战

上一章节完整描述了传统软件建设的方案，从客户需求出发，然后按部就班的开发，再到交付客户，是一个完整的闭环。环环相扣，每个环节都不能脱钩，形成一种强耦合效应。

• 提出问题：那么试想如果客户的需求有变动怎么办？源头有变动，那么从源头到尾部所有环节跟着变动，这也是当前软件行业超过95%以上的项目所存在的问题（我也看过Windows操作系统的代码，他们的都是定制化的代码风格）。我们设想：如果客户的需求模糊，或者未来随时变动，那么我们怎么用最小的成本和最高的效率来应对呢？比如：1.某个页面调整了，页面里的字段删除一部分，新增一部分；2.按钮也改动了一部分，导致逻辑有变动；3.业务模式和流程变了，本来一笔创建完订单后直接进入售后环节，但是现在改成了需要在创建订单之后增加审核的流程。如果发生诸如此类的需求变动，那么页面跟着修改，功能函数跟着修改，数据表结构跟着改动，页面的跳转方式也跟着改动…
• 发起挑战：如果是按照传统软件工程模式，我想复旦大学实验室就无法实现一杯咖啡的时间为客户做出一套CRM系统。那么他们是怎么做到的？这个问题我思考了很多年，因为我所工作过的所有公司，开发软件的模式都是传统软件工程模式，而且类似于复旦大学这种模式的开发资料肯定是不会外泄的，网上也搜不到，只能自己研究。于是这些年的工作经验加上自己的思考，总结出一套“局部试错法”：我把每个环节想象成动态的，而非固定的，比如页面中的字段随时会变动，那么程序文件中就不能使用“硬编码”。硬编码描述：比如页面中第一列显示客户名称，第二列显示客户手机号，那么程序文件中是按照固定格式来显示页面的，伪代码如下：

  show web page:    # 显示页面
  table first line:"客户名称"    # 第一行显示客户名称
  table second line:"客户手机号"    # 第二行显示客户手机号
  ...

  这种就属于“硬编码”，页面需要显示什么，程序文件中就按照固定的格式来编码，如果页面修改了，那么程序文件紧跟着也需要修改。“硬编码”显然无法适应未来的随机变动，所以使用另一种模式：“动态编码”。页面中的字段是动态存储的，而程序文件编码时从动态存储中获取。比如我们建一张数据表用来存储页面中需要显示的字段，然后程序文件从数据表中获取到页面需要的字段，然后编码出一个动态显示页面的程序文件，伪代码如下

  show web page:
  loop query page fields: {    # 循环从数据表中获取
    table <n> line:"fields.n.field"    # 显示从第1~N行的字段
  }

  “硬编码”模式下，客户需求变动之后，开发工程师需要修改程序文件，功能函数和数据表。而“动态编码”模式下，所有的字段都是存储在数据表中，程序文件是从数据表中查出所有字段，程序文件根据不同的字段类型来做不同的处理，一旦客户需求变了，只需要修改数据就可以，这个工作量是非常小的，并且不需要开发工程师的介入，一个系统运营人员在后台修改一下即可。前者的工作量以工作日为单位，并且需要开发人员来修改软件项目，后者的工作量是以分钟为单位，并且不需要开发人员的介入。
  前面提到“局部试错法”，但是说到现在好像跟这个也没关系，只提到“动态编码”，其实还有其他的，具体请看下一章节。

五.SaaS平台建设方案

从软件项目的稳定性和可靠性来说，传统定制化开发模式的软件肯定是最好的，因为每一个页面，字段，按钮和跳转都是一一对应着程序文件和数据表，但是社会发展迅猛，行业在不断地变革，产品的更新迭代非常频繁，所以它无法适应快速变化的客户需求，无法用最小成本来改造软件项目等等。

SaaS平台又称“多租户云平台”，只要浏览器或者下载了软件，在有网络的地方随时随地就可以访问。市面上有不少这样的产品，比如办公软件钉钉也属于SaaS平台，但是钉钉这款产品不适用多变的客户需求，他做出来的产品是什么样子，客户只能按照他的产品来使用，所以它属于单一产品模式的SaaS平台。财务软件金蝶，一直想走SaaS模式，但是他走的依然是独立部署模式，它的产品有多种形态，但其实是多个产品类似的软件项目，不能算SaaS平台。任何公司，任何软件项目想转型成“动态产品形态的SaaS平台”都不是一件简单的事，如果是重建项目还好，不用考虑老项目架构和老用户使用的问题，不过从0开始建设不是一件容易的事；如果是有了一些年限的软件项目想转型的话，难度就更大了。

难归难，但也并不是不可能，我的战略是“局部试错法”，战术包括“动态编码”，“功能清单”，“选择性跳转”。简单描述：我们按照传统软件模式来建设雏形版本，雏形版本可以根据自己公司业务需求而开发出的软件。然后结合同行业的业务模式，分析出软件里每个模块中需求会随机变动的部分，比如页面的字段会变动，页面中会有不同的按钮，业务流程和页面跳转会变动，或者只有某个公司特有的需求功能等等。根据这些随机变动的业务需求，把我们把整个软件架构设计成“功能组件化”模式，每个组件在有限范围内可随机修改（因为SaaS具有行业属性，不能把制造业的SaaS平台突然转型为电销类SaaS平台），并且整个软件是由各个组件组装而成，而非整机模式。如果我们贸然把软件项目里的每个会变动的地方都改造成“随机动态”模式，每一个改造都构成一个不确定风险点，整个软件里所有改造同时进行的话，不确定性风险会叠加形成巨大风险，最终会对整个软件造成毁灭性的打击。“局部试错法”是先局部改造，等某个局部改造得到充分考验之后，再进入下一个局部的改造。

通过模拟业务场景来阐述我的方案和思想：

1.首先架构改造，把整体架构模式改造成每个单独组件服务架构模式。比如原先的架构是：先建一个叫“安捷智运”的项目，然后在项目里创建“运单模块”，“车辆模块”，“财务模块”，各个模块使用“传参”方式来衔接；但是新的架构模式是：创建“运单”微项目，创建“车辆”微项目，创建“财务”微项目等等。把以前的各个模块换成为了“微项目”，这样有什么好处呢？在同一个项目里的各个模块之间关联性很强，要求开发人员之间的配合度和契合度很强，但是换成微项目之后，每个微项目之间是相互独立的，很方便扩展：比如货运行业里，各个货运公司在运单方面的需求差异很大，那么开发人员就集中火力投入到“运单”微项目里，而其他的微项目根本不需要动。如果是传统的模块化的架构，只要改一个模块，其他相关联的模块都需要改动，而且不方便扩展。所以新的架构下的软件，是由很多个微项目组成。

2.根据自己公司的业务需求开发SaaS平台的雏形版本。俗话说：只有自己玩过，才知道坑有多深。这时候开发出来的版本是SaaS V1.0。

3.挖掘同行业的需求。有的公司用极少数的员工创造出巨大的产值，但是有的公司人员规模庞大却产值很小。这种现象在互联网公司里太多了，货运行业应该也存在这种情况，所以尽可能多的挖掘同行业的需求有助于提升产品的广度和深度。这个环节非常重要，起到重要作用的人就是产品人员。产品人员能够秒懂客户的心思，并且能在客户提出的基础上给出具有建设性意义的思路，帮助客户改善不良需求，引导客户往更合理的方向发展，得到客户的认可之后，能把肚里所有的货传达给开发人员。传统意义上的产品人员仅仅是把客户的需求收集来，绘制出开发人员能看懂的产品图，然后交付给开发人员。但是这远远达不到参与SaaS平台建设的产品人员，产品人员不仅要能收集需求，还能发现客户公司业务模式里的问题，主动跟客户沟通交流，引导客户向更先进的业务模式去发展，使每个方案都具有创新性。建设SaaS平台的初衷并不仅仅是给客户提供服务，同时也是帮助客户往更好的方向去发展。

4.得到同行业的需求之后，产品和开发一起分析客户的需求和自己公司需求的差异。上面介绍过传统软件模式，需求方面的差异具体到软件工程里其实就是：页面差异，字段差异，按钮差异，跳转差异等。从这些差异中提炼出哪些方面是随机动态的，并且根据轻重缓急来标注优先级。

5.先从最简单的开始：字段差异。我们自己公司简称“安捷”，我们设想存在这样一个客户，这个客户的业务需求覆盖了同行业绝大部分公司的需求，这个客户叫：安杰运输有限公司（后面简称安杰），第一阶段，假如安杰公司的业务模式和安捷一样，但是页面中字段和安捷有差异，安捷存在的一些字段安杰不存在，安杰存在的一些字段安捷不存在。想象一种极端的情况：所有页面的字段都有差异。这时候我们来改造我们的SaaS平台，改造的结果是：既能满足安捷的业务需求，也能满足安杰的业务需求。我使用的战术是：动态编码。程序文件不使用硬编码模式，所有字段都是随机动态存取。安捷的字段和安杰的字段都是在后台配置的，安捷有一套字段表，安杰也有一套字段表。经过改造之后，终于实现了相同页面但是字段存在差异。

6.接着改造页面的其他部分：按钮，弹框和逻辑。安杰说页面中很多操作无法满足他们公司的需求，要在安捷的基础上增加和修改一些按钮或者弹框，比如运单页面不仅要录单功能，需要增加导入运单的按钮来实现导入功能；在车辆管理页面，不想用人工录入功能，使用“一键”AI自动识别行驶证的功能等。这时候我使用的战术是：功能清单。我们为每一个功能开发出一个对应的功能函数，然后提供功能清单让客户来选择。这就要求系统里有个功能函数库，随着接触的客户越来越多，需求越来越多，功能函数库越来越庞大，功能清单里的选项也越来越丰富。这个环节的工作量非常大，因为要为每个页面提供功能清单，但是业务需求有轻重缓急，我们根据业务需求把页面按照优先级分为各种级别，对业务影响越大的越优先来处理。这项工作是伴随着SaaS平台的整个生命周期，我们会不断地扩充我们的功能函数库。

7.接下来改造业务的流程：跳转。跳转可以说成业务跳转，也可以是页面跳转。安杰对我们反馈：他们的业务流转需要调整，原来安捷的业务流程是：1.录入司机和车辆信息 -> 2.创建订单 -> 3.订单配车 -> 4.生成运单 -> 5.财务对账 -> 6.省略部分环节… -> 7.上报到省平台；但是安杰需要改动两处业务流程：1.直接从表格导入订单，导入完之后增加审核的功能；2.有部分已完成的线下运单，可以直接导入上传到省平台。安杰提出的流程需求，是目前安捷里没有出现过的业务需求，所以需要改造页面跳转，使得软件系统满足安杰和安捷两种业务流程，但是我们的目标是：改造之后要同时满足安杰和安捷，并且为后面其他客户提出的流程改造留出可扩展性空间。这里我使用的战术是：选择性跳转。我们把所有业务环节的点设置为“跳转点”，然后把所有“跳转点”连成一条业务线，从左向右的方向，这是一条“超级业务线”，包含每家公司的“跳转点”，是所有公司“跳转点”的并集，然后给每个客户提供“选择性跳转”，根据客户自己的业务流程从“超级业务线”中选择部分“跳转点”来组成自己的业务线，但是必须遵守：选择“跳转点”只能按照“超级业务线”从左往右，不能沿着相反方向，这是不合逻辑的。

8.未完待续：总有我们想不到的问题，总有我们没有遇到过的需求场景。不断地遇到问题和丰富多变的需求造就了一款得到市场认可的产品。所以我们要放宽心态，敢于迎接各种问题和需求，在后面的研发过程中会不断创造出新的战术，未来可期…

六.感慨

一个SaaS平台的建设是一个不断累积的过程，累积大量的需求，累积各种功能函数库，累积各种解决问题的战术。需要工匠精神才能开发出一套市场认可的产品。它没有终点，客户在变，市场在变，SaaS平台也一直在变…

本作品采用《CC 协议》，转载必须注明作者和本文链接