服务设计

基础要点：

1.以迭代和增量的方法，考虑服务设计，以不断适应组织和客户的需求变化。

2.要关注客户体验（Customer Experience，CX）以及用户体验（User Experience，UX），考虑整体环境，准确估算服务的成本、用时、资源和风险，实现跨项目共享与重用，确保可维护性和成本效益。

3.需要考虑与其他现有产品或服务，与相关方，与现有架构，所需技术，必要的衡量指标，现有管理实践之间的关系。

4.产品或服务的变更与退出，也需要用到服务设计，以免产生意外的负面影响。

5.应做好事先设计，并定义好相应的服务级别，而不是事后添加或调整。

解读：

说到底，我们前面所讨论的各种管理实践都是基于前期的服务设计而来。按照时间线来分，我们可以分为两大类设计，即：

1.对近期、乃至中长期的新服务进行规划

如：新增云端业务，启用安全管控措施，转型为DevOps 交付模式等。

2.对现有的服务进行调整、改进、甚至停用

如：更新现有的技术实现方式，替换某项应用或模块，以及减少本地支持人员数量，统一改用内网在线提交与派单系统等。

显然，服务设计的目标就是要满足当前和未来，对于某项业务或用户的需求。

因此，为了体现服务设计的价值，保证交付出用户满意的服务，并减少后期各方可能出现的摩擦，我们应当在设计之初，就厘清如下三个问题：

1.准备提供哪种服务

包括服务的价值，所涉及到的技术，以及对应的支持与管理系统。

2.如何开发出该服务

要考虑到真实合理的业务需求，现有的内/外部资源，以及整体的进度。要在控制开发成本，实现可重用性的基础上，减少交付时和使用中的潜在风险。

3.如何交付出该服务

需要关注如下两个方面：

（1）人员（People)：涉及到企业内/外部各类服务提供的人员，以及他们所需的业务技能。

（2）流程（Process)：包括在服务提供过程中，所涉及到的各种准备与操作步骤，以及业务数据的流转活动。

当然，服务设计的关键内容除了业务服务本身之外，还会涉及到服务后续的管理与运维。

总的说来，设计内容包括：业务功能、容量功效、模型架构、资源预算、技术实现、参数指标、排障文档和支持维护等方面。

实务：

在真实的服务设计上，无论是硬件、软件、运行环境、服务流程还是数据结构的设计，我们重点关注的是服务设计与需求之间的关系。

一般而言，普通用户，特别是业务人员所提出的需求往往出于个人的实际业务需要，过于关注自己的日常工作内容，因此可能会考虑不周，甚至带有一定的局限性。我们在分析需求时，会找到不同的业务执行人员与管理人员，全方位、多层次地进行调研，适当地加以引导和管理。

同时，为了减少产品服务在交付或发布之后面临的被动整改，我们针对服务交付的效果制定了如下三个层次，以便在实际设计时进行对标和参考：

1.基本功能

即：某个产品或系统向用户提供的最少以及最低服务。

例如，应用页面是否能够打开，以及业务申请按钮是否在点击后提供响应等。这类主要是一些“必点”的功能。也就是说，每个用户只要访问或使用到该系统，就会使用到此类基本服务与功能，因此这也是新产品或服务推出的根本所在。

2.特定功能

即：区别于其他或现有产品或系统，提供特定需求的服务。

例如，IT支持服务的在线派单系统，以及业务组件的秒级切换与容灾功能等。也就是说，这类主要是通过“人无我有”的途径，来满足用户特定性或关键性的需求。

3.增值功能

即：让用户更流畅、更满意地使用某项功能。

例如，通过双活数据库保障业务数据的实时可用，以及根据错误代码与关键信息自动生成问题解决方案等。也就是说，此类主要是通过“人有我优”的方式，增加的是用户的粘性与满意度。

前文提到了风险，此处的风险主要来源于：对需求解读的缺乏，架构与定义的不清，实现方式与技术的误用，以及干系人与业务方的参与不足、或过多的干扰。

因此无论由业务方或用户提出新的服务需求，还是由开发或运营团队提出对现有服务的重大变更，甚至是退役请求，我们都应该以成立项目组的形式，积极地做好配套分析，以确保设计出的原型能够正确地反映需求方的真实意图。

在实践中，我们采用过的流程是：分析实现的可行性→确定需求的优先级→定义实体与属性→绘制逻辑关系图→梳理输入/输出流向→创建服务模型等。

此外，为了考核服务设计的绩效，我们还增加了后续的跟踪环节，从交付使用后的成本、效果、用户使用频率，以及变更请求次数等维度进行全面衡量。