信息化孤岛探讨及解决思路（四）交付层面孤岛问题的解决

问题

在（三）中，我们讨论了孤岛问题的解决，接下来深入一点进行分析讨论。
一般情况下一个单位会有有几类的终端在用，对不同用户来说，所有的信息系统中，他们关心的是什么？
延伸问题：
如果对用户来说，有几十套应用系统，怎么样才能保障所有的应用系统都能好用，怎么样才能够让这个东西落实到位？

讨论

针对这些问题，小伙伴们循例进行了如下，有些发散但有益的讨论：

一般常见的有PC端、手机端、大屏，基本就是这几类了。对用户来说交付层他首先是好用，好用就包括就是他找的东西又很快找到，不要给他很多个链接，或者翻很多页找东西，反应速度上要反应快一点，用户比较关心这一块。
如果是多个系统由多个团队来做，那么如果要保证一个统一性，要从业务交付层面约定一个标准，或者流程上就统一起来，才能够做这个保证的交互的效果。

在交互层面用户会比较在意的是：界面是不是是否好用？是否美观？他需要知道的是，整个信息系统各个过程的进度，比如说用户在操作的时候，等待的时候也有所反馈。我接触用户都比较在意，希望系统在计算的时候，也要给他一点反馈，让他知道，程序在动。我觉得我们如果做一个信息系统的话，可能要有一种懒人的思维，用最少的代价，用最少的步骤去让用户操作完成想要的功能，然后在这个基础上。再去进行美化，这样的话，我觉得就挺好的。
从项目立项的时候就设立标准，可能要求高了，实际的情况可能是，用户根本没有这方面的知识储备，这方面专业人员就需要帮助制定标准。

我们常用的终端就是主要有这几种：手机端，PC端，瘦客户机等，不同层面的用户关心的点可能也是有不同的，例如可能关心的系统功能、用户体验这几个方面。在管理层面的用户能就会关心信息系统的成本价值、运行质量、安全等等。
关于怎样去保证所有的应用系统都能好用，我觉得这个问题其实也是所有用户都是比较关心的。顶层架构设计我觉得是其中的一个方面，但是如果是从好用这个方面着手的话，我觉得最重要的其实就是要站在用户的角度，去开发设计系统，因为合适就是最好的。
项目标准一般都是与结合专业与业务，一起制定的，要开展这方面的工作，首先要对规范方案有共识，要认可这是项目落地后的开发标准，我觉得这一块要制定标准应该是没那么大问题的，首先认可了整体方案，那么要以什么样的标准去建设开发可以以专业的角度去规划制定了，举一反三再经验推广。

常用终端：PC、TC、手机、平板、大屏；
用户关心的点主要是要好用，也就是使用体验：包括人机交互、界面、响应速度、页面反馈等；
一个单位如果有几十个应用，那他一定是经过了多年的积累形成的了。制定出开发标准让以后的应用开发能够遵循统一的规范，当然是一个方法，虽然不能保证，但比没有好。但对于以前开发的应用，只能逐步更新替换。
要制定标准，首先得获取管理者的充分信任，这需要有展现具备多年的服务经验，并得到认可，这应该是一个前提，这里说的不只是单个应用项目的标准，而是对今后所有应用项目的标准。
至少要有一个规范的框架，不同单位、业务、场景所要求的内容可以不一样，但框架基本相同。也就是规范需要考虑到的点，应该先有准备。

前端关注的可能是交互体验好不好，反应快不快，还有美观度；后端关注的是各种数据分类清楚，展示全面，性价比；前后端都关注的应该还有学习成本低，适用范围场景。
怎样落实，我觉得几十套应用，我们应该先抓重点然后优化，比如先区分出主要用户和次要用户，优先解决主要用户的重点需求，然后往下优化其他满足其他用户。

终端:PC端(一般来说是X86架构的PC，、服务器。操作系统有windows、MAC os，Linux、Unix，主流还是Windows，瘦客户机本质上还是X86架构的PC)。移动端(手机、pad、手持PDA、智能电视，按操作系统，主流分为Android、iOS，)
保证系统好用的措施:这个问题我觉得还是比较有开放性的，答案的层面会比较多。设计上，甲方在开始可以统一一定的标准，比如语言、平台、UI、交互逻辑，让开发团队遵循这些标准去开发。对于开发团队来说，还是得从客户的角度多做考虑，在遵循客户的要求下设计，设计的过程多与客户沟通，吸收采纳改进意见，首要解决客户的主要问题，其次再想办法优化改进。

常用的终端主要有：PC、移动端（手机、平板）、瘦终端；
用户关心的点，对普通用户来说，系统操作简单，反应及时，就是易用好用；
对管理人员，系统要安全、稳定、易维护且成本少，应该主要关心这些；
对于存在多系统，各系统要做到好用，那应该在开发前做好一个统一的规范，如设计架构上的规范，各系统统一遵循。这应该涉及到之前讨论的要有一个解决方案，对各系统做统筹规划设计。

终端主要有：PC、移动端、瘦终端
终端用户关心：交互友好，操作方便，兼容性强；任何时间，任何地点，任何设备，想用即用
运维人员关心：傻瓜化安装，运行稳定，扩容方便，运维告警，搬家省事；最好能让他们喝着茶，抽着烟，看着报纸过一天
成本部门关心：便宜省钱
大老板关心：提升工作效率，有成果，汇报工作要有料，大屏够炫
他有几十套应用系统，他怎么样才能去做这个保证，让所有的应用系统都能好用，他怎么样才能够让这个东西落实到位？也许某个开发团队能做到，但是并不是所有的都能做到。这个他会怎么考虑呢？
对于现有系统，既定事实，可以考虑参考一些成熟设计模式，例如：
Sidecar模式进行数据融合和清洗，进行数据融合方面的工作，
统一认证进行用户鉴权，
小程序，或者虚拟化的方式进行统一接入
通过迭代的方式，逐步去形成一个统一的整体规范，并让后续的新应用遵循。
现在比较成功的做法是以参考主流设计为主，现在到了用户那边跟着他们的想法走，一般是做了一个觉得好就要求按那个来（推广）。可以通过分类，选择觉得比较好的一套作为模版，并把关键点列出来作为规范提供，这样可以是一个可行的操作方式，而且每一类应该要有一个。

观点

交付层关心以下问题或者要求：
1、要用什么应用能很快找到，很直观便捷。
2、反应快，在计算、运行过程中，提供进度状态让用户知道
3、操作简单，功能所需的操作步骤少、直观
4、各种数据分类清楚，展示全面
5、界面美观，符合审美
6、使用稳定
相关策略：
1、一个客户的应用可能有很多个，一定是经过了多年的积累形成的了。制定出开发标准让以后的应用开发能够遵循统一的规范，当然是一个方法，虽然不能保证，但比没有好；
2、模版或者规范，参考主流设计为主，按场景分类，每一类都 选择我们觉得比较好的一套作为模版 并把以上关心的问题或要求细化后列出来作为规范提供给各应用开发团队， 并在使用中选择最好的进行优化，再迭代推广，最终定下一套最合适的规范集合。执行中也要进行跟进审核以确定能够落实下来；
3、操作上，先抓重点然后优化，比如先区分出主要用户和次要用户，优先解决主要用户的重点需求，然后往下优化其他满足其他用户；
4、对于已经开发好的应用，只能逐步更新替换，根据实践，除非进行二期或者新一期的开发的可以通过更新替换的方式让应用表现规范，否则很难，这种情况下，可以把频繁使用的、涉及面广的局部功能重新开发（如轻应用），或者在融合应用开发时（数据融合），在根据业务重新组合新的应用时，按规范要求进行，也能达到逐步规范的目的（原应用的使用范围缩小到专业用户，并且专业用户已经适应其使用感受）；
5、减少主动（人工）寻找应用的需要，能通过通知、直接打开应用的方式进行的，不用人工方式；
6、作为服务方，要帮助甲方制定标准，首先得获取甲方的充分信任，这需要展现具备多年的服务经验，并得到他们认可。这应该是一个前提。

在后续章节继续进行深入探讨。

上一章