术业有道：交付服务探索之交付指引建设

在应用系统交付服务的系列文章，第一篇（《新系统交付服务模式在光大银行的探索与实践》）介绍了传统运维模式中开发与运维对系统建设关注点的差异、专业领域沟通语言不对等等问题，生产运行关注的非功能性问题没能及早发现并解决，开发诉求的快速上线和运维追求的平稳运行屡次交锋。交付服务模式针对传统运维模式的痛点，从系统建设之初介入，参与架构、设计、非功能测试、上线至移交运维的全生命周期，为整个开发及上线运维保驾护航。第二篇（《IT服务-以服务迎接未来》）介绍了交付服务模式建立的背景与探索实践的初步成效，以及交付服务在效率提升、项目推进、知识共享、能力建设方面做出的努力。本文将描述我们在交付服务实践中如何进行工作可量化，结果可度量的交付服务标准化探索。

如同程序开发解决一个bug的过程，通常又会冒出新的bug一样，交付服务模式在实践过程中也暴露出一些问题。

一项新业务发展，通常由业务扩张到人员扩张，再到业务扩张，螺旋式上升。业务急速扩张，若存在小纰漏，就会像业务扩张速度一样很快放大。人员急速扩张，水平的参差不齐，影响面可能更广。在此过程中，把握好“人”和“事”尤为重要。

交付服务模式的推进也是如此。银行业快速转型期，大量新业务需求涌入，同期建设的系统数达十余个。而交付服务的初衷是为业务发展、项目建设提供强有力支撑，这对技术能力、架构水平、业务理解、组织协调、沟通能力俱有要求。

在工作中，部分事务的归属并不清晰，加上个人对交付服务的认知差异，交付服务范围呈现差异化。此为“广度”问题。

即使对相同的事务，系统管理经验有别，架构规划能力高下，做事风格迥异，细节关注程度不同，花费了时间和精力完成，但最终的结果有时不尽人意。此为“深度”问题。

有项目点将交付服务经理，一方面是对个人能力的肯定，一方面也暴露了交付服务的水平还有差距。此为“标准化”问题。

系统众多，事项繁杂，交付服务经理的记忆的局限性，不免有时会有遗漏。此为“工具支撑”问题。

交付服务无成例可循，如何解决人和事的问题，我们以事为核心定规则、定方法。交付小组成员较少，在对于上述问题的应对上，我们拟以头脑风暴法为基础结合SMART、5W2H工作方法论来探讨问题的解决。

（一）、头脑风暴法要点是探讨方式，概言之为充分、非评价性的、无偏见的交流讨论，要点如下：

1、自由畅谈

参加者不应该受任何条条框框限制，从不同角度、不同层次、不同方位大胆地展开想象。

2、延迟评判

必须坚持倾听原则，一切评价和判断都要延迟到会议结束以后才能进行。

3、禁止批评

绝对禁止批评，头脑风暴的目的是发散思维，拓展问题，批评对创造性思维无疑会产生抑制作用。

4、追求数量

获得尽可能多的设想，至于设想的质量问题，可留到会后的设想处理阶段去解决。在某种意义上，设想的质量和数量密切相关，产生的设想越多，其中的创造性设想就可能越多。

（二）、SMART工作方法论，SMART原则最早是由管理学大师Peter Drucker提出，并首先出现于他的著作《管理实践》（The Practice of Management）书中，这个方法既适用于个人工作绩效管理，也可以用于个人成长目标建立。这个原则主要包括有如下几点：

1、目标必须是具体的（Specific）

2、目标必须是可以衡量的(Measurable)

3、目标必须是可以达到的(Attainable)

4、目标必须和其它目标有相关性（Relevant）

5、目标必须具有明确的截止期限（Time-based）

（三）、5W2H分析法，5W2H分析法又叫七问分析法，是二战中美国陆军兵器修理部首创。简单、方便，易于理解、使用，富有启发意义，广泛用于企业管理和技术活动，对于决策和执行性的活动措施也非常有帮助，也有助于弥补考虑问题的疏漏。

（1）WHAT——是什么？目的是什么？做什么工作？

（2）WHY——为什么要做？可不可以不做？有没有替代方案？

（3）WHO——谁？由谁来做？

（4）WHEN——何时？什么时间做？什么时机最适宜？

（5）WHERE——何处？在哪里做？

（6）HOW ——怎么做？如何提高效率？如何实施？方法是什么？

（7）HOWMUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？

具体到交付服务的几个问题的解决，我们拟定明确服务事项与流程，建立交付服务指引来规范指导交付服务工作。指引的建立过程分三步走：

（一）、探讨工作范围

全组头脑风暴，复盘系统建设历程，取每个人工作范围的最大并集，讨论以统一认识，形成交付服务公认的工作范围。对于一些处于组织间真空地带的事务，或者工作界面不清晰的事务，我们以服务为基础纳入考虑，避免在推进中出现管辖真空地带引起“事有所不决”。

（二）、交付服务事项划分

利用SMART工作方法对服务事项进行划分，划分过程遵循如下原则：

1.每个事项均为具体任务。如“与项目经理初步沟通”并未指明沟通内容，需明确为“与项目经理确认系统开发进度及上线时间”。

2.每个事项可衡量。如“熟练掌握某系统”就无法作为能力评价指标，因其无法衡量。可衡量的方法我们认为是“脱稿讲解架构及逻辑部署”。

3.每个事项可达到。如“资源分配实施计划”，必须是依托于各资源的满足程度难易、先后依赖关系和各团队变更窗口来紧密安排部署，直接给出一个理想日期要求大家配合则无异于镜中花水中月。

4.每个事项明确是否有前继依赖。分析服务事项间的逻辑关系，确认前继依赖，作为事项开始的必要条件。

5.每个事项有最晚开始时间和最晚完成时间。最晚开始时间，保证在已知一定耗时的任务，交付服务经理有足够的时间能够把事项顺利完成。最晚结束时间，保证其后继事项能够如期展开。

（三）、交付服务事项工作方法确认

参考5W2H分析法，为每个事项明确如下内容：

1.事项内容（what）

2.事项是否为关键节点（why）

3.执行人和相关配合人员（who）

4.工作方法（when,how）

5.文档模板链接/ITSM流程（where）

6.完成标志(how much)

在全组成员共同努力下，交付服务指引应运而生，平滑地连接了人与事。按照系统建设周期，交付事项划分了交付介入、架构评审、资源申请、设计评审、非功能测试、投产准备、投产上线、验收交付8个阶段，梳理交付服务工作细项共七十多项。这七十多项按照事项类型分别属于记录留存、材料准备、组织会议、参与会议、沟通协调、过程跟踪、基础平台、流程发起。即使第一次做交付服务经理，根据交付服务指引中事项内容、执行人、配合人、工作方法、模板链接也能明确每件事的工作方法。

对于一些处于组织间真空地带的事务，我们起到了桥梁作用，助力每件事能顺畅进行下去。对于一些流程上无法体现并流转的事务，我们采用文件共享平台进行衔接和记录。

“授人以鱼不如授人以渔。”在实践中，交付服务指引在如下方面起到了积极作用：交付服务过程指导，交付服务标准化提升，人员能力培养，交付服务工作量化,交付服务结果度量。在业务、开发、质量、运维与交付服务组的密切配合下，顺利支持数十个新系统建设上线。

本文转自交付服务经理组 匠心独运维妙维效