标签：style blog class width 2014 http
站在客户视角，一个系统，包括业务配置（是否启用某某功能，设置该功能的参数），包括业务数据（对业务运营过程产生的数据的分析和统计，用来反应系统的实际价值），包括硬件设备的外观和物理接口（开关、指示灯、输入输出端口，各子设备端口之间的连接线）。
站在开发者视角，一个系统，包括各个业务，每个业务涉及的硬件设备，每个业务涉及内的各个软件，每个业务涉及的软件模块，每个硬件、软件、模块各自有自己的接口（参数配置、业务交互、日志）。
我们公司绝大部分人已经习惯了站在开发者视角设计面向客户的人机交互界面（软硬件）。结果就是，对客户而言，界面软件难用，不敢用；对开发人员而言，界面模块与其他模块耦合度大，增加了实现的复杂度，增加维护的复杂度，增加了应对需求变更的复杂度。
从公司设计人机交互界面（软硬件）的现象中，可以推断公司在广义设计上的思维方式存在问题，缺乏对“面向抽象接口设计，上层决定下层，下层提供可行性论证”这一最基本的设计原则的理解。结果就是，设计制造不出优秀的大型复杂的易维护的需要大量人机交互的产品。
站在客户视角，精简软件
现有的应用软件主要是面向开发人员，软件里面充斥着大量的开发人员视角的分类和语言，这直接导致最上层的应用软件难用，非常难用；另一方面，上层软件一旦与低层设计的耦合性高，复用性就很低，导致大量上层软件不必要的复杂度和频繁的改动。
我们要做的事是，面向客户开发软件，分开现有软件中客户不可能、不需要理解的部分，保持上层应用软件的纯净和稳定。
如下图，能做网管的客户，可以设定他是一个有通信专业知识基础的人，并且了解所在行业的业务规则和流程，但下图的设置他是绝对不会懂也不该懂的。好比自己用的手机，你需要了解里面有多少芯片，每个芯片的参数设置是什么吗？更不需要是通信专业毕业的才能会用手机吧。
下图中的设置应该如何处理？对于专属个别开发人员的配置，上层应用软件最多只需要提供这些配置的保存和传输的抽象接口，上层软件不需要展示给客户，所以不需要解析内容，解析任务就交给那些个别的开发人员吧，这样开发人员的内部参数变化不会影响到上层软件，理论上现在用SIP协议实现，明天用PIS协议实现，上层应用都可以不改。
站在客户视角，整合软件
现有的应用软件主要是面向开发人员，依据实现系统的设计，分开了各个应用的服务器和客户端，大多很孤立，每个应用都有自己的用户管理，关联设备的配置管理，最麻烦的是各自有各自的号码本，客户需要同时记住多个账号密码，手动同步多个号码本，适应各个软件中不同风格操作。站在客户的视角，他们关心的功能是否能简洁的实现，至少可以只有一套账号管理，至少可以不需要手动同步号码本，至少可以对同一个设备只配置一次（例如XXX模块的IP），至少可以统一管理各个应用。
面向整个系统，设置业务规则，而不是基于当前设计，面向模块设置规则
假设系统中包括一个业务，该业务有一个参数，在当前的设计下，这个参数可能要被多个模块使用，我们现在的做法是相关的各个模块都要配置一下，如果哪天设计变了，但参数本身没变，客户需要修改多个模块。
典型的例子是，设备IP，拨号方案，号码本，多个软件或模块需要在界面上配置这些业务参数。另一方面，一个完整的业务规则，涉及的参数被分散在各个软件或模块（开发者视角）的界面中。
整合客户端
典型的例子是，站在开发人员视角，开发录音应用，分录音服务器和录音客户端是多么合情合理，但站在客户视角，需要的只是在每条话单旁可以直接回放相应的录音。录音客户端不需要单独做一个软件，录音服务器只需要向网管的话单模块提供一个查询接口。
PC客户端事例
PC服务器端事例
站在客户视角，精简软件，整合软件,布布扣,bubuko.com
标签：style blog class width 2014 http
原文地址：http://www.cnblogs.com/wangk/p/686895f9dcfc89854857a0330e14d505.html
