ThoughtWorks洞见

从架构可视化入门到抽象坏味道

2019年2月19日2019年2月19日仝键评论

抽象的坏味道

上文说过，C4说穿了就是几个东西：关系-线、元素-方块和角色（角色不过是图形不同的方块）、关系表述-线上的文字、元素的描述-方块里的文字，虚线框（如前文所说，在C4里面虚线框的表达力被极大的限制了）。

这些东西一点都不新，我们自己随便找个白板，无非也是用这几个东西来表达架构，它的优点在于引进了一些分层，帮助我们理清思路、也有利于可视化给别人看。

换言之，C4不能帮你做好架构设计，但是它能暴露出你设计中的问题，以便于被自己或其他人纠正。

可视化的威力就在这里，但根据我的经验，即便你用上了C4也不见得就能表达清楚，不过好消息是，我们终于可以聊一些高级的表达问题了。

可视化之后，我们能看到自己的表达问题，大概的问题有两个：抽象层次和抽象粒度。这个是表达方面永恒的问题，也就是软件设计永恒的问题，没有万灵丹，但是用上了可视化手段之后还是有机会让生活更美好一点的。

这两个问题可能太抽象了，不容易意识到，那我们可以看图，从图上的具体表现来发现坏味道。一般会有几个迹象表明我们有可视化的坏味道：

一张图上过分密密麻麻的线
一张图上太过多元素（也就是方块）
一张图上太少的元素，比如角色特别少
每个图上文字表达不契合，有的太泛泛，有的太细节
无限制的画更多张图，基本上也就失去了使用图形化表达的意义

那么对应的手段就有：

合成更大的元素

当我们意识到有密密麻麻的线、太多的元素，闻到这个味道的时候，可以考虑是不是该把里面的一些元素合成更大的元素了。Component可以合成Container，Container可以合成System，这样就会分成更多的图，每张图就变得没那么多线和元素了。

紧接着会面临下一个问题：怎么合成一个更大的系统，Container是明确的，所以Component合成Container不是问题，问题是Container怎么合成一个系统，为什么是这些Container合成这个系统，而不是另外几个？或者多加几个、减几个？

这个问题没有标准答案，但是有一些其他的框架可以提供一些思考的维度。

比如可以结合akf扩展立方来思考。

（akf扩展立方）

X轴就比较容易，一方面从容器本身的描述来看设计上是不是支持横向复制的，另一方面则是看部署图。

Z轴相对难一些，只是比较偏技术。比如当技术上有性能瓶颈，则需要注意这一个维度，有时不得不搞出一些特殊的容器出来，有时已经存在这些容器了，他们可能单独属于一个系统（类似于大数据分析的系统），或者一个系统的某一个局部（这就是前面提到的虚线框表达力被限制的地方）。

Y轴给人的感觉是最容易操作的，但实际上却是最难做好的，Y轴的背后是业务，往往我们觉得就按业务切成多张图就好了。这种想法就表现出我们往往意识不到业务的真正难度，于是总在这里出问题。如果你能跨过这个心理障碍，决定去认真做一下，那么也有一些工具可以帮助我们做好。

（领域模型与架构设计）

最经典的工具组合就是求助于DDD，结合康威定律和步速，考虑维护的团队、使用的角色、变化的节奏，这块展开就复杂了，有机会再聊。

这里说一个最简单的做法：按照用户角色分。同一种角色，由于其在公司里的职能、职责都是已经被定好的，天然在系统上就有一种隔离性。比如招聘专员、会计、出纳，他们使用的系统肯定是不一样。

但说简单，其实也不简单。我见过一些图，上面的角色只有两个，内部用户和外部用户。而另一些图，细化到了个人的级别，或者把职级都放上去了。所以无论再简单的原则，最后都会掉进抽象的坑。

画一些共识图来忽略掉一些通用的元素

有时候合成了更大的元素，元素依然很多，线条依然很密。画多张图也不够切分的。这个时候我们可以求助于共识。

人与人交流，如果已经有一些共识存在就可以少废很多话，共识多到一定程度只需要确认一个眼神就完成交流了。所以毫无疑问，做好共识管理，可以大幅简化我们的架构图。

所以在我们做架构可视化的时候，经常会先画一个技术共识图，比如以一个能力建设的数字平台为例，我们就画了一个下面这样的技术共识图：

（技术共识图）

在后面画具体的图时，就可以省略掉一些共识的元素，像nginx和数据库就没有了，可以更关注在业务上，而不是技术上。

通过制定主题，限制文字的抽象层次

其实上面的技术共识图就是类似的做法，只是用于技术方面，如果用于业务方面，我们可以用一些抽象的名词或动词来代替一类业务，比如下图：

（数字平台系统景观图）

上图是一个系统景观图。当前这个主题是希望人们能一眼看清楚这个系统里面的相关角色都在使用什么系统，他们关注什么，职责是什么。至于具体学什么，怎么学的，都不是那么重要。所以我们就用学习一词代表了一系列的业务。

当主题确定的时候，很多纷杂的信息就没有了。一定要克制住自己试图在一张图上表达足够多信息的冲动。

只画重要的图，剩下的交流的时候再画

除了像上面说的，不要试图在一张图上给他足够的信息。同时也不要试图把所有的信息都表达出来。

绝大多数的图可能只在交流具体业务的时候才画，推荐使用动态图。

总结

即便有了C4这么，好用的可视化工具。我们依然会看到，自己会掉进抽象的坑。所以在使用的时候一定要注意坏味道，经常自查是不是犯了抽象层次和抽象力度的错，才能做好可视化。这件事上，没有谁能幸免，所以要时常自省，与诸君共勉。

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见

在前面的一篇文章《ThoughtWorks的Professional Service (专业服务)模式是否面临颠覆？》，我们分析了ThoughtWorks的专业服务将面临的冲击。企业服务领域正面临着向高度标准化和高度定制化两极分化的趋势。基于云的平台和应用服务，不仅大幅减少了基础设施部署、维护和升级的工作量，还将大幅减少应用软件的升级、移植、转型遗留系统的工作，因此可标准化的服务将更多以SAAS的形式提供。另一方面，以数字化为名，技术驱动的商业变革，让高度定制的技术服务在企业的项目频谱上占据更高份额。这两个趋势所压榨的空间，就是原来属于传统的大型商业软件套件和低端IT服务的空间。ThoughtWorks最近几年的发展在某种程度上印证了后者。

如果我们追求的是高度定制化的市场，并且希望占据战略价值的制高点，就需要在ThoughtWorks的深度和广度上持续扩展。说到战略价值，总会让人想起McKinsey的管理战略咨询和埃森哲的技术战略咨询。不过根据FORRESTER的报告，单纯的战略咨询工作正在减少。在这个不确定的世界里，企业缺乏耐心去启动一个长期、昂贵而结果难料、价值难测的大型项目。相反，通过长期愿景下的一系列短周期项目创造可预见的增量价值，会是更加常见的模式。

这个趋势正好跟ThoughtWorks一直秉持的敏捷理念一致。在软件交付和自身运营中多年的实践，让我们的各项服务都自带敏捷属性，在这个趋势中占据了先发优势。就好像黄博士正在推出的超越预算（Beyond Budgeting）相关服务，其背后思想跟精益非常一致，推动以财务为代表的运营适应VUCA（Volatile，Uncertain，Complex，Ambiguous）的环境。我们的设计师和咨询师们秉持这一理念，创建和演进出各种设计、业务和工程技术的方法。

除此之外，变革管理越来越重要。跨界的竞争对手，快速的技术和业务变化，给团队留下的改变时间很短。伴随着企业需要更多更快的引入、验证和发展新技术、新业务，非正式，随时发生增量组织变革占据了越来越多的比重。这要求咨询公司不仅仅能够转移技能，也能够转移胜任力，不仅仅设计组织和流程，还要注入和增强文化。这种变革是针对客户，也是针对我们自己的团队，考验着我们的学习能力和走出舒适区的勇气。

跟以往相比，战略咨询将越来越多地跟实施融合在一起。相对于协调两家各有所长的公司分别承担这两项工作，客户更愿意看到一个具有跨界能力的公司总体负责战略和实施。具体的工作任务则由这个战略合作伙伴根据优势选择自己或第三方服务团队提供。以前选择这个整合者的天平倾向于管理咨询公司，当前数字化的趋势则将更多的话语权交给了兼具技术和设计能力的组织。

ThoughtWorks已经定义了自己在战略层面的战场 – 技术驱动的商业变革。在当前这个时代背景下，我们会关注业务优化、消费者服务体验、产品创新和商业模式演进这些领域，寻求创造客户价值的机会。在2016年，传统汽车厂商面临着百度、乐视、特斯拉这些跨界者的挑战，同时，在传统汽车市场的格局中，由于车厂跟4S店之间的博弈关系，使得车厂无法有效获取和利用客户的全生命周期数据，因此在业务模式上受到严苛的约束。

过去几年的主动拓展已经使我们初步形成了价值主张、战略、能力、资产和服务五层布局。对外的表现是咨询、交付、DPES和产品/解决方案四个业务模式，并且开始逐渐积累一些轻量级资产。

在这个图里，我们在很多点上都还有着显著的薄弱环节。在上方战略层，我们很多时候缺乏能力快速切入客户上下文，勾勒完整图景。具体就表现在跟客户高层的对话中，无法跟随客户的思路和话题，提供有价值的意见，甚至问不出切到点上的问题。下方资产层的积累一直是ThoughtWorks的短板。

客户对服务的期望是更加敏捷。在高度定制化的同时，要求更快地响应，并支持持续的改变。在这种情况下，如果什么都从零开始，显然会很累。未来可重用资产在服务中将比现在占据更高的比重。组织需要不断算法化并演进其知识和能力，沉淀为资产。资产的形式可能是方法学和知识体系，或是轻量级、可灵活装配的软件组件，又可能是组件化的案例和实践文档。不过资产的建设也需要把握个尺度，我们强调轻量级和快速演进，目的是希望资产不会成为我们创新的包袱。

中间层是我们的各项能力，既是支撑我们价值主张和战略的基础，也是我们资产和服务竞争力的源泉。随着我们不断扩张高价值业务领域，能力的portfolio也在不断扩展。Tech Strategy2.0为我们提示了新能力的方向，但求新的同时，不能忽视我们一直追求的工程卓越，少了这项能力，其它都是无本之木。

最近比较喜欢的文章是哈佛商业周刊里的一篇-《Old Habits Die Hard, But They Do Die》，其中提到，“达成长期稳健发展的公司案例都是能够在包括文化、关系、领导力、战略等稳定性因素和快速动员资源，市场探索实验等动态因素之间取得平衡”。专业服务公司的竞争力是其成员竞争力的综合体现。时代会变迁，我们只要能增强追求卓越、持续改进的文化，对自己的能力保持高的期望，我们就能与时俱进。文化和能力是组织新的基础设施。

MD心声：

我们这样的业务演进对我们的人才结构会带来什么新的要求？对文化会有什么影响？
相对于过去打着一个简单的敏捷标签，能力和服务的丰富反而让我们在市场和社区的识别度下降，如何破？

推荐阅读：

从TechRadar看UI自动化测试的未来

2019年2月13日2019年2月13日齐磊评论

在2017年第17期和2018年19期技术雷达中，分别出现了两个新的工具——cypress,testcafe，之前只接触过webdriver框架的同学可能会有些陌生。而cypress已经在最新一期的技术雷达中进入了评估阶段，并在多个项目得到了应用，总体反馈利大于弊。

先来详细的介绍下cypress以及我所在项目使用中踩过的坑，关于testcafe会在另外一篇文章中介绍,testcafe主要是用来做UI的回归测试，以及多浏览器测试，cypress不足之处则是testcafe的长处。

框架理念

虽然我很鄙视这种行为，但也能够理解，毕竟身后有巨大开发团队在支持，各种开销，总得有收入来维持运转，所以它走了很多中国产品的营销策略，即免费使用，然后通过提供增值服务来赚取利益，也印证了一句话：服务即未来。

框架架构

让我们先来看看它没有公布的设计架构。

这是一张来自cypress 架构师画出的所谓架构图，其实等于什么都没说，但是我们还是能够通过蛛丝马迹，找到一些重要的信息点。electron 与termina，driver ，launcher 等玩过Puppeteer的人肯定知道 chrome headless 既可以在命令中直接执行脚本，又可以通过puppeteer调用chrome launcher在页面运行，显示测试运行过程。

然后我们看下 cypress的运行界面。

貌似就是一个chrome浏览器，没错就是经过二次开发后以electron封装出的工具。没猜错的话，它的底层应该是基于chrome remote-interface这个库，通过在其之上开发出专有的自动化api来控制浏览器。这意味着每个所支持的浏览器都需要一个新的driver。这个driver是什么，用chrome的话其实就是chrome headless。当然还有Firefox，尽管Firefox已经公布了headless模式但是cypress目前还没有支持。

（chrome headless 架构图）

优点

我们了解了架构，再来说说这种架构之上有哪些优点，和webdriver区别又是什么。

最大的优点：快

我们之前使用基于webdriver的各种测试框架，被运行效率折磨的痛不欲生。在用上cypess之后，感受到要起飞的节奏，为什么？之前我们说过cypress其实就是一个二次开发过的chrome，而且你所写的测试是在浏览器进程中运行的，这也意味Cypress测试直接访问真实的DOM元素，而不是像webdriver一样通过json wire protocol、通过proxy server 转换成各种浏览器driver所能识别的命令，这样来来回回会耗费很多时间，所以cypress设计之初就抛弃了 webdriver这种架构。

第二个优点：异步

Cypress is asynchronous and relies on timeouts to know when to stop waiting on an app to get into the expected state. Timeouts can be configured globally, or on a per-command basis.

这是来自官方的文档，所以我们不用再像webdriver那样去封装等待方法，cypress 所有的操作都已经自带了retry功能，直到到达设置的timeout。

第三个优点：只支持js

很多人会诧异，“什么？这也算优点？难道我不会js是我的错？其实cypress面向的主要对象是前端DEV与QA，cypress的底层与所使用工具都来源于前端，面向的测试也是基于前端，例如api，E2E等。

第四个优点：方便调试

前端工具很多都支持hotload，cypress也贴心的加入修改测试代码自动rerun测试的功能，并且支持代码debug，甚至可以在chrome dev tool中方便的调试，更甚每个步骤的操作都会清晰的在图像界面中展示，还有详尽的log信息在console界面打印，还不够的话，还支持录制回放功能，方便你查看整个流程。

其它优点

类似jquery 或者直接使用jquery是获取操作对象。

Cypress.$("ul li").map(function () {
    return Cypress
    .$(this)
    .text()
}

mock普通的http请求

cy.server()           // enable response stubbing
cy.route({
    method: 'GET',      // Route all GET requests
    url: '/users/*',    // that have a URL that matches '/users/*'
    response: []        // and force the response to be: []
})

以及上面提到的mock graphQL请求

beforeEach(() => {
    cy.server();
    cy.mockGraphql({
        schema,
        endpoint: '/gql'
    });
});

还提供了各种CI工具结合的接口，方便与不同CI集成。

不一一介绍，请看文档。

缺点

上面吹了那么多好的地方，也该来黑一波了。

坑一：除了cy对象外的所有操作都是同步的

这就意味着类似以下代码你必须用promise封装，否则将会出现错误永远拿不到正确值，因为Cypress.$其实使用的是jquery对象，方法返回永远都是同步。

getElementsText(selector) {
    return Cypress.$(fxConfig[selector]).map(function () {
                return Cypress.$(this).text()
            })get()))
}

有没有方法解决？有有有！

使用cypress-promise这个库如上述代码在返回最外层使用 promisify(）方法，在使用ES7 promise语法 async await 就可以转换成为异步操作。

async getElementsText(selector) {
    return await promisify(Cypress.$(fxConfig[selector]).map(function () {
            return Cypress.$(this).text()
            }).get()))
}

坑二：并发测试

当我们的测试用例越来越多时，我们第一个想到是并发测试，但是这是cypress 收费服务。当你按照以下图做了配置时，高高兴兴的在云端运行时，发现根本没有用，因为你没交钱！

有没有方法解决？有有有！

利用concurrently这个库或者GNU命令起多个进程去执行不同测试文件，从而绕过cypress的限制。
测试设计层面，利用cucumber的tag 将测试分类，再利用CI 设计不同pipeline 来并发运行不同tag的测试，进而绕开收费限制。

坑三：当元素不存在或者没有找到时，测试会失败

这个坑貌似听起来很正确，但我们想一下这个场景：如果我们希望当某个元素不存在时，需要执行某个操作。但是因为以上默认的实现，没有找到元素，所以会直接报错。

或者某个元素刚开始没有出现，必须将页面滚动到底部，直到全部数据加载完后才出现，也会遇到问题。

有没有方法解决？有有有！

利用jquery 查找元素的length是否大于0，然后利用if或while循环进行判断

if (Cypress.$(".show-more-button").length > 0) {
    cy.get('.show-more-button a').click();
}
else{
    do something
}/

肯定有人问：为什么不直接cypress去查这个元素的length对不起 cypress没有这个方法。

坑四：不支持多浏览器测试

对，cypress首席执行官也说了，多浏览器测试也许在未来已经不需要了，因为微软已经放弃IE啦，好了世界都是chrome和webkit的了。

再来谈谈它的云服务

先看看界面吧。

类似继承了一个CI，但是刚才提到收费项目，并发测试，以及 bar chart分析。

再来看看到底怎么收费？

收费也不算高，这在国外也就一顿大餐，但是提供的服务还是有限，期望以后能够提供一些自动化测试结果分析以及预测的功能，或者结合ML,AI实现一部分的自动化混淆测试。

坑还很多，需要慢慢填，记得当初在上一次提及cypress工具后，很多人都说“坑很多慎入”，其实我觉得和webdriver最开始一样，坑也很多，只有不断有人去填坑，这个工具才会有更好的未来，与其慎入，不如来尝试下他的优点，何乐而不为。

未来预见

对于QA而言，JS势必会成为一门必须要掌握的语言。由于我们大部分项目都是以前端为主，前端方面的知识储备能够帮助QA快速的融入团队技术架构，快速构建适用于项目的自动化架构。自动化测试平台化离我们越来越近，Webdriver离我们越来越远，像cypress这种打着免费旗子的工具只会越来越多，那么谁提供的服务更好，性价比最高，就将在这场争夺中存活下来。就像很多公司在做类似于AWS的产品，但市场中占绝对统治地位仍是AWS，还是那句话——服务即未来。

我们并不需要一个大而全的工具，我们需要的是一个能够帮助整个团队提升工作效率与体验的工具，那么目前来说cypress在E2E的测试上是成功的。所以从现阶段看像webdriver这种效率低下且体验差的工具在软件开发历史长河中终将泯灭，但还是要感谢它在自动化领域做出的巨大贡献。

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见

智能商业时代的挑战

2019年2月13日2019年2月13日吴俊宏 1 条评论

随着物联网、大数据、人工智能、云计算、区块链等技术的发展，商业将进入智能化时代。

智能商业将给企业带来许多业务升级和转型机会，但是并不是每个企业都能从中获益。如果对智能商业时代的商业环境和竞争态势没有准确的判断，企业内部没有足够的竞争力支撑，反而是企业没落的开始。

1 智能商业时代的竞争态势

1.1 生态系统的竞争

图1 生态系统的竞争

过去企业在战略上强调竞争优势，通过不断强化核心竞争力，扩大规模效应，以提供低成本产品、差异化的服务；但是在智能商业时代，企业还需要发展自身的生态优势，利用生态网络的放大效应和协同效应，提供一体化的产品和服务。

Gartner调研数据显示，中国有61%的企业已经参与别人的生态系统或自建生态系统。比如阿里和腾讯之间的竞争，不是淘宝和微信这两个产品的竞争，而是围绕电商交易与围绕社交形成的两个生态系统之间，在零售、娱乐、出行、旅游、金融、物流、社交、电商、云计算等多领域、全方位的生态竞争。未来不再是产品之间、企业之间或者产业链之间的竞争，而是企业连接形成的生态系统之间的竞争。

1.2 数据的竞争

过去，数据的用途和价值比较单纯，只是作为企业或组织生产经营过程中的“副产物”。随着数据不断积累，运营环境的复杂化，企业开始发掘数据的新用途。利用数据，企业能在未来获得更大的经济收益。企业需要对数据进行资产化管理，通过数据建模分析，挖掘内部和外部数据所蕴含的信息，进行精准营销、产品优化、服务改善等。数据从“副产物”，转变为经营和决策过程的“新矿藏”。实现数据驱动的智能决策，不仅可以给客户提供智能化的产品和服务，还可以提高企业商业决策的效率和质量，制定更加行之有效的战略。

据IDC的研究报告预计，从2013到2020年，全球数字信息将以每两年翻一番的速度，从2013年的4.4ZB增长到44ZB，总规模增长10倍。MIT数字商业中心联合麦肯锡商业技术部、沃顿商学院对北美330家上市公司高管进行大数据与业绩的研究表明，“运用大数据做决策的那些行业前三名企业，比其竞争对手在产能上高5%，利润上高6%”。比如Google不仅存储了网页数据，还存储用户搜索时间、内容和方式。基于这些海量的页面数据和用户行为数据，Google可以优化广告排序，制定广告的投放策略，实现广告的精准投放，将搜索流量转化为盈利模式。根据Google的母公司Alphabet发布的2018财年第三季度财报，第三季总收入337.4亿美元，其中广告业务占总收入的85.8%，达到289.5亿美元，总比增长20%。收集和使用数据的能力，将是未来企业核心的竞争力之一。

1.3 用户体验的竞争

图2 用户体验的竞争

过去企业只关注效率，重视流程。因为只有价值链的各项流程都高效运作，才能保证低成本，形成价格壁垒。但是流程的高效，只能帮助企业实现“节流”，无法实现“开源”。企业的利润最终还是来自于客户。Oracle应用软件协会曾公布一份针对电子商务的调查数据：57%的用户在体验非常差的时候会完全放弃整个处理过程，26%的用户将会转到竞争对手的网站。产品和服务的用户体验是未来企业竞争力的重要一环。比如iPhone之所以在一经面世，就引起消费者的热烈追捧，其重要的原因是它将手机的用户体验做到了极致。简洁的产品设计，简单的用户界面，听音乐、上网、拍照、打电话、玩游戏，只需要屏幕轻点一两下即可，给用户带来了一种全新的体验。用户体验，将是影响企业保持客户和获取客户的重要因素之一。

2 企业内部的制约瓶颈

陈旧复杂的IT系统降低了响应力

在过去十几年，很多企业都实施了ERP等大型软件，将管理、生产、库存、采购、物流和财务进行了集成，从而提高运行效率，节约企业成本，增加企业竞争力。但是ERP关注的是企业内部，很少关注企业外部供应商和合作伙伴的协作，形成相对封闭的企业IT体系。随着企业生态合作的扩大，原有陈旧、复杂的IT系统难以快速应对生态的变化，导致企业应对变化的响应力降低。

烟囱式建设模式导致信息孤岛的形成

企业早期按项目制或“烟囱式”来建设IT系统。这些IT系统所采用的技术、数据规范、运行环境都有可能不同，就像在企业内部树立一座座相互孤立的“烟囱”，导致业务和数据的隔离、资源不能共享，运维成本和复杂度高，形成信息孤岛。

客户体验过时导致客户流失和获新困难

客户体验是指“客户与企业和品牌之间的所有互动，不仅仅是指某个时点的互动，而是指作为该企业客户的整个周期的互动”。良好的客户体验可以吸引和留住客户，鼓励客户加深与企业的关系，购买更多产品和服务，最终增强客户的忠诚度。企业的产品操作复杂，服务低效，正不断地降低客户的忠诚度，导致客户的流失。

3 智能商业时代的企业战略

为了应对智能商业时代的生态、数据和用户体验竞争，提高企业的整体竞争力，智能生态战略的整体目标是：

充分运用技术、用户、合作伙伴等生态要素，以适应市场和用户的变化，形成生态优势；
集中管理和利用企业外部和内部的数据，实现企业智能化；
提高企业响应力和优化产品和服务的客户体验，保持和获取更多客户。

如果未来企业是一艘宇宙飞船，那么信息资产就是飞船的动力系统——发动机，运营管理则是飞船的主体——船身，用户体验和业务规划则是飞船的左右机翼。

图3 智能生态企业

3.1 飞船的发动机——信息资产

信息资产是指企业所拥有的信息系统、业务知识、数据和基础设施能力等，是给宇宙飞船提供动力的发动机，而业务服务化和数据资产化是提高发动机动力的有效举措。

图4 智能生态企业-信息资产

业务服务化

从业务角度而言，服务是指一个独立对外提供可重复业务能力的逻辑单元。独立，是指一个服务不受外界影响完成服务自身的逻辑处理，具有高度自治性。可重复，是指同样的输入，服务总是会得到相同的结果，即服务本身是无状态的。而业务服务化就是将企业内部拆分为若干个相互关联的业务服务。

业务服务化对于提高竞争力有重要作用。企业实施业务服务化后，得到一系列标准化和可复用的服务。这些服务与上层的业务流和具体环境无关，所以可以很快速灵活地运用到新的业务流程和商业环境，减少定制化开发的投入，加快了产品和服务的交付速度，从而提高整个组织的响应力和敏捷度。像Google、Netflix、Amazon、PayPal等大型互联网企业很早就开始将其内部系统拆分为多个服务，以应对市场和客户需求的变化和不断增长的访问量。国际领先银行也开始纷纷参照这些互联网企业，其中，荷兰国际集团（ING）就是成功的案例。ING是一家植根于荷兰的全球化金融机构，拥有员工113,000人，在全球50个国家为6千多万客户提供银行、保险及资产管理服务。在2014年，ING完成了系统的服务化和迁移，降低其内部应用和基础架构的耦合度，得到更加独立和灵活的业务服务。产品和服务的交付速度比以往都快，推出市场的速度提高了50%。新功能从概念的产生到最终的交付，也只需要短短的5周。

业务服务不仅可以用于企业内部，还可以开放到给第三方企业使用，这样可以加强与其他企业的协同，提高企业的生态参与度，有助于融入生态圈或者围绕企业打造自己的生态圈。例如星展银行（DBS）、花旗银行（Citibank）、西班牙对外银行（BBVA）等领先银行纷纷开展生态银行和开放银行的布局，打造API平台对外开放服务，通过金融科技，提前占领与客户交互的场景，打造生态圈。

数据资产化

资产是指由企业过去的交易或事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。企业所有的业务数据、业务文档、合同、设计图纸都属于数据资产。数据资产化，就是将企业记录的数据转化为可以产生预期经济效益的资产，其核心特性就是可变现。

图5 数据资产化

内部变现：

数据通过作用于现有产品，对产品运营过程产生的数据进行收集、分析，用于产品自身的运营决策、用户体验提升，从而提高产品的收益，给企业产生更大的经济效益。据研究估算，大数据技术可帮助银行将交叉销售业务量提升10%-30%，信贷成本下降10%-15%，后台运营成本降低 20%-25%。

外部变现：

外部变现的方式，一般是很难评估数据实际的价值。在合法合规的情况下，让数据以各种方式交易，可以给企业带来直接的经济效益，例如租售原始数据，提供数据整合、分析、报表等数据服务。例如西班牙对外银行（BBVA）在2014年2月份成立了一家名为BBVA DATA & ANALYTICS（D&A）的大数据公司，希望通过数据科学和技术，为银行创造价值。截止于2017年，D&A进行了40个数据项目，其中27个已经开始有财务回报；开发了商业化旗舰版数据产品Commerce360，并推向西班牙、墨西哥和哥伦比亚市场；获得多个学术界奖项，得到媒体和大众的认同。正是因为D&A取得巨大的成功，BBVA将其视为数字化转型的关键资产。

3.2 飞船的主体——运营管理

运营管理，主要包括将无形资产转化为客户和财务成果等有形价值的流程，是宇宙飞船的主体部分，连接和协调发动机与机翼，使飞船作为一个整体前进。流程自动化、决策智能化、体验一体化和创新协同化是优化和增强飞船主体能力的有效举措。其中，流程自动化和决策智能化是智能生态企业的核心运营管理能力。

图6 智能生态企业-运营管理

流程自动化

目前，流程自动化最常见的类型是机器人流程自动化（Robotic Process Automation，RPA）。根据“机器人流程自动化和人工智能协会（IRPAAI）”的定义：“机器人流程自动化 (RPA) 是一种技术应用模式，使计算机软件或者‘机器人’能够捕获并解释现有应用，从而能够处理事务、操作数据、触发响应以及与其他数字系统进行通信”。RPA常用的场景有IT、财务、采购等内部流程自动化。企业经过业务服务化和数据资产化后，就可以将RPA运用到业务服务和数据资产之上，实现业务的自动化和高响应，提高效率、大幅度降低运营成本。据研究预估，有42%的财务活动通过采用成熟的技术可实现全自动化，还有19%可实现近全自动化。澳新银行运用RPA，成本平均降低达到40%，巴克莱银行的财务部门使用RPA实现坏账准备金流程的自动化，每年节省将近1亿美元。

RPA当前普遍使用场景是基于结构化数据和基于逻辑规则的场景，随着技术的成熟，进一步是更复杂的非结构化数据流程的自动化及智能化的端到端流程自动化。

决策智能化

决策智能化，指在大数据和自动化的基础，构建大数据分析、机器学习的能力，使得企业对于数据的使用不再是简单的汇总，而是能产出洞察的深入分析，然后基于洞察作出组织、流程和人员能力方面的评估和改善，真正实现“感知—洞察—评估—响应”闭环的顺利运作与循环提升。这样，企业对自身经营发展就可以实现多维度分析和智能决策，从业务驱动转变为数据驱动。

以蚂蚁金服为例，蚂蚁金服通过商业场景的数据化积累丰富和准确的贷款者信息，然后运用算法模型对每一名贷款者进行信用打分，最后根据信用打分来决策是否贷款。这样的贷款审批方式，使得蚂蚁金服不需要信贷经理，几秒钟内就可以完成一笔自动审批，而且业务违约率约为1%，远远低于世界银行2016年估计的世界平均水平4%。澳大利亚的一家银行，也通过模型来实现营业网点运营的智能决策。他们通过建立网点定位模型，分析出市场和地点对不同类型服务的需求，然后基于分析得出的洞察，决定开设、调整或关闭网点，最终将网点的数量减少25%~30%，预计净成本节省达1亿美元，而且还能提高整体的业务量，并利用模型继续网点的持续优化。

体验一体化

一体化，是指使分散而又相互联系的单元或运作方式组合成为一个协调的整体。体验一体化，强调的是企业的产品和服务应保持简约性和一致性，避免孤岛式产品链模式，使用户可以极大便利地体验到跨系统和产品的功能，真正地以用户为中心。例如荷兰的ING银行，推进泛欧一体化银行平台，大幅改善客户体验，2017 年与 2013 年相比收入增长 14%；澳大利亚联邦银行2017年的发展战略目标为“打造简单而优质的银行”，通过三大数字化战略举措，提升服务效率和客户体验。两年间，数字客户增长25%，其中移动端增速达44%，突破1700万人，数字化销售渗透率更达到了28%，而两年前该比率仅为10%。

创新协同化

协同创新指企业内部或企业之间围绕人才、资本、信息、技术的分享机制，进行多方位交流，多样化协作，使创新资源和要素能突破主体间的壁垒，充分释放而实现深度合作。智能生态企业的协同创新，能将自身与合作伙伴的优势结合起来，形成协同效应，使得整体的经营表现和竞争力都优于原有各个企业单独经营之和。协同生态创新可以是产业上下游的深度协同创新，也可以是跨产业的广度协同创新，甚至是深度和广度兼顾的全面协同创新。深度协同创新能加强企业在产业链的影响力和竞争力，而广度协同创新则增加企业的多元性，避免行业同质化竞争。余额宝就是广度协同创新的例子。余额宝是电子商务巨头阿里巴巴集团和天弘基金合作推出的以支付宝为平台，由天弘基金公司进行销售的一款互联网货币市场基金。一经推出就引发全民抢购，上线短短半年时间，就吸收了5000亿人民币的巨额资金，成为中国单一规模最大的金融产品，而天弘基金也凭借着余额宝一举成为中国最大的基金。

3.3 飞船的机翼——客户体验和业务规划

客户体验，主要描述了针对目标客户群的价值主张。业务规划，主要描述了企业的有形价值。用户体验和业务规划作为宇宙飞船的左右机翼，能给飞船提供足够的升力。

图7 智能生态企业-客户体验和业务规划

差异化

这里的差异化有两层含义，一是企业之间的差异化，主要指企业在顾客广泛重视的某些方面，力求与竞争对手有区别；另外一层是客户之间的差异化，即个性化。差异化使企业的产品和服务有别于同类竞品，每个客户都有不同的体验，提高企业产品和服务的竞争力，获取更多客户，扩大财务收入。

一体化

一体化，指企业充分利用自己在产品、技术、市场上的优势，通过与外部合作伙伴协同合作，使企业不断向深度和广度发展。企业与外部合作伙伴协同合作，充分利用外部资源的同时，也提高自身资产的利用率，给客户提供一体化、全方位的产品和服务，改善现有客户盈利性。

智能化

智能化，指企业具备智能属性，能主动地去了解客户，通过学习和分析不断提高用户体验、运营效率和决策质量，从而降低企业成本，改善现有客户盈利性。

高响应

高响应，指企业面对多变的市场、业务和客户需求，能快速做出响应。这意味着企业能快速感知变化，积极调动内外部资源，不断创新和满意客户需求，保持和获得更多客户，以扩大财务收入、改善现有客户盈利性。例如荷兰ING银行在面对日益严峻的形势下，决定进行敏捷组织的转型，将IT、研发、产品管理和营销等固有的部门壁垒打散，重新组建为“敏捷小分队”并通过敏捷管理模式进行项目的开发，大大地提高了产品交付速度，以应对市场和客户需求的变化。

智能商业时代正向我们走来，新商业范式正在萌芽，企业根基正悄然改变，你的企业准备好了吗？

更多精彩商业洞见，请关注微信公众号：ThoughtWorks商业洞见

项目管理的三个关键

2019年2月12日2019年2月12日陈庆敏评论

项目管理是一门抽象的学问，实践证明，能把项目带向成功的并非固定招式，也不是放之四海而皆准的标准，在项目管理这条道路上，走过的弯路、踩过的坑都有可能成为非常宝贵的经验和教训。总结了三个项目管理的关键，分享给所有项目管理者或者想成为项目管理者的伙伴。

01 管理风险，基于事实而不是感觉

风险，一直是令项目管理者头疼的问题，客户关系处理不好是风险，交付范围扩大是风险，需求变更是风险，团队合作是风险，有的时候诸多风险会一起到来，令项目管理如履薄冰，稍有不慎就会导致项目失败。

在真实风险之外，也有许多项目折戟于“想象中的风险”。换言之，很多风险并非无法解决，而是我们认为自己无法解决。

我的上一个项目，客户负责算法，交付团队负责应用程序，就在离交付只有不到三周的时候，团队提出客户的算法有bug，会导致一些我们解决能力范围之外的问题，于是报出了高风险预警，并产生了悲观情绪，认为项目必然会失败。

后来，我们做了问题整理和原因分析，结果却大大出乎我们的预料，竟然发现大部分的问题是来自应用程序，应用程序解析外界输入太脆弱，而且没有良好的容错机制，应用程序读取算法时设置了错误的参数。

也就是说，团队掉进了自己为自己挖的坑。

我们还把所有基于感觉的问题做了梳理跟踪和记录，项目结束之后大家一起做了回顾，对所有人来讲，那是一次深刻的教育。

项目交付过程中，团队可能会面临各种各样的复杂度，有时候需要突击学习，有时候需要加班赶工期，这些挑战都有可能变成团队的压力，重压之下团队很有可能变得悲观，当一个人的悲观变成一群人的悲观，团队就失去了对风险的客观判断，这时候最需要的就是事实。

所以，项目管理的第一个关键：面对风险，我们需要多做一些分析，管理风险，一定是基于事实。

02 管理客户，多一些沟通少一些猜测

很多项目管理者认为客户管理是项目管理中最有挑战的部分，而客户管理中最复杂的莫过于决策者的管理。

决策者通常来自客户的高层，有时候还是出资的那个人，他们有想法，有话语权，但其特殊的身份决定了他们一般都很忙，不是我们在项目中直接对接的那个人。

如果管理不好决策者，就经常有如下情景发生：

项目开发到一半了，决策者出现，推翻了大部分做好的功能；
Showcase的时候决策者提出反馈，条条都是需求变更；
关键业务功能找他拍板的时候，约不到时间，找不到人。
……

这样的事情发生的多了，开发团队通常会这样猜测，重要的人物都很忙，我们的项目不是他的优先级，我们尽管非常需要他，但无能为力。

但当你问开发团队，决策者是否知道他很重要，是否知道他可能会是项目交付的风险和最大瓶颈，大多数时候，开发团队一脸茫然，因为很少会有人和决策者确认过这个猜测。

这是项目管理的第二个关键，有时候，我们对客户的认识基于我们的猜测，而不是事实。

我经历过一个决策者隐身的项目，也预料到他的缺席会是项目交付最大的风险，于是借助一次关键的showcase，我们暴露了所有的缺陷，也因此引起了决策者的关注，我们趁机和他做了沟通，原来他之所以和项目保持着若即若离的距离，是因为他一直以为项目一切顺利。

意识到参与的重要性之后，他和团队安排了一周两次的catch up，自那之后我们才真正将决策者引入开发的过程。

所以，在客户管理上，对客户产生正确的认识，让客户成为团队的一部分，多一些沟通，大部分的时候都会有收获。

03 管理目标，不断验证并强化目标的一致性

所有的项目都是有目标的。

这个目标的设定首先来自于客户，客户想通过一个系统或者数字化手段解决什么问题，带来什么价值，对这些价值都有什么描述，成功和失败的定义是什么，除了数字化手段还有什么其它辅助方案？

绝大多数项目经理，都会有意识去收集并澄清这些信息。

团队的目标是根据客户的目标制定的，团队如何帮助客户达到目标，实现期望的价值，团队内部如何合作，团队和客户如何沟通，如何界定开发范围，根据什么进行优先级决定，这些也通常会被项目管理者纳入工作的范围。

理想情况下一旦客户的目标明确，团队的目标也会变得非常清楚。

但现实往往是，每过一段时间就会有人质疑团队是否有目标，或者抛出一个对目标的错误认知，甚至认为团队不可能达到目标。

项目经理可能会疑惑，目标不是很明确吗？团队不是一起讨论过目标吗？而且所有人都达成了共识？项目经理甚至记得这种事情发生了什么地点什么时间，他自己或者有上下文的同事说过什么话，在白板上写过什么内容。

但是，这些都无济于事。

人的认知是个很奇怪的事情，信息被植入人的大脑，但随着时间的推移，它会被迭代很多次，于是不同的人就有了不同的认识。

此时，如果项目经理还是基于以前的假设，认为所有人都已经充分了解上下文并拥有一致的认识，那就大错特错了。如果不反复强化目标，并确认所有人拥有一致的认识，就会出现这样的一些情况：

团队花时间开发了无用的功能，造成浪费，但是要开发重要功能的时候却没有时间了；
系统出现了问题，有人认为应该修复，有人认为不需要，对优先级的认识不一致导致了很多无效的讨论；
客户也会对开发团队产生怀疑，认为团队自始至终是没有理解业务；

最终，在客户的资源耗尽之时，团队没有办法交付一个可以实现价值的可用的版本。

这也是项目管理的一个关键问题。

要解决这个问题，项目管理者需要不断验证假设，弄清楚团队是否都理解目标并且是否对目标达成一致，尤其去找中间加入项目的成员确认他们对目标的认识。

即使团队暂时性的对目标明确且达成了一致，项目管理者也需要不断的强化目标，这样才能尽可能的帮助团队统一方向，提高效率。

导致项目失败的原因有很多，遇到如上原因的话，有可能会使一个看起来成功概率很大的项目走向失败。

在《有效管理的5大兵法》中有这样一句话：解决问题，就是把可能让我们失败的因素清除了，让我们达成预期目标。

作为项目管理者，把项目带向成功，就是不断识别可能会导致项目失败的关键因素并解决问题的过程。

更多精彩洞见，请关注微信公众号：ThoughtWorks洞见