编者有言：对于运维工具产品设计，甲乙双方都有各自的视角。那么站在甲方，如何设计运维工具能争取乙方更多的资源支持？这其中都有哪些套路可启发思路？且看彭华盛老师有什么看法。
本文根据彭华盛老师在〖Gdevops全球敏捷运维峰会广州站〗现场演讲内容整理而成。
（点击“阅读原文”可获取彭华盛演讲完整PPT）
作者介绍
彭华盛，现于广发证券负责数字化运营工具建设方向，热衷研究运维/运营领域相关技术，力求构建一个可扩展性的运维/运营体系。
我们的主题是“运维工具的设计思路”，会尝试探讨在甲方的运维开发团队如何获得乙方的资源倾斜，为企业创造更高的价值。
一、话题的背景
这个话题的产生来源于上个月初与朋友的一次关于产品经理的聊天，朋友跟我聊起了他们在产品设计过程中总结并落地的一条产品开发套路，很有启发。
结束聊天后，重新梳理中间一些抽象方法，其实在我日常工作过程中也有应用，但零散不成套路，遂决定尝试做一个小研究：金融企业中甲方运维开发团队的产品设计思路，本篇为这个小研究开个头。
在本篇中，我尝试将目前工作中与产品设计有关的步骤抽了出来，再串起来一个主线作了一个片子（文末有分享的片子链接）。
二、聊聊运维开发团队
自Googlesre50%开发的布道，以及互联网公司、dbaplus社群等技术社区的推动，很多运维团队都建立了运维开发团队，金融企业也认同这种新的思路，在人员招聘，组织团队等方面都有改变。我在上半年做了一个金融行业运维的调研（调研了几家银行，几家券商，几家保险），其中在运维开发团队的运作模式方面，主要如下：
基于开源平台或工具模块，以自主研发为主；
使用外部产品，整合在己有运维工具体系中；
购买外包开发资源，支持运维开发；
基于厂商的产品或平台，进行合作开发（实际上多是以厂商出技术平台与开发资源，甲方出idea）；
在实际的实践过程中，由于一些行业特点，比如系统异构、标准化程度不够、精细化管理程度、监管要求、企业里流程复杂度等，通常金融业里的运维开发团队面临的开发难题更为复杂，开发效率会低于互联网公司不少，所以互联网公司说他们20人可以支持企业所有运维开发工具的需求，但在金融行业里并不一定能实现（另外大部份同业的运维开发团队不超过6个正式员工）。
同时，从投入产出看，在运维这个非企业核心技术线的团队中，20人的运维开发团队所需要的人力成本，相比带来的效益及见效期的期望，往往不如基于成熟产品的合作开发模式。
从调研结果看，第4种“基于厂商的产品或平台，进行合作开发”的模式在同业中的运作效果更好。所以，本篇思路的基础是：金融企业甲方里的“运维开发”不等于“完全的自主研发”，探讨在“合作开发”的运维开发模式下，如何创造更高的价值。
1、甲方乙方说到合作开发，通常会有甲方与乙方，所以需要分析一下双方的优劣势，才能看看如何取长补短，实现双赢。具体的分析则是如何从甲方角度让乙方将资源向我们倾斜，毕竟好的乙方人力资源通常是比较紧张的。
首先看看甲方：
甲方的运维开发团队，成员很多是从运维一线出身，对特定运维场景下的需求理解更深，更贴近真实的用户，对痛点或价值的把握更好；其次，甲方角色很容易得到市场中成熟的商业解决方案，并更容易理解并获取同业中真实解决方案及方案的应用状况。
有优势，劣势也明显，比如甲方实施人力资源少，且有大量的工作量分配在流程的消耗上，甲方的运维开发团队没有生存压力，在成本与效能的管控能力上比较弱等。
看完甲方，再来看看乙方：
乙方的优势在于，一个好的乙方通常见识面更广，他们见过行业及行业外各种客户需要，踩过各种坑，掌握行业更通用的需求与更完备的技术解决方案；同时，乙方有一个完整的研发团队，所以可以支持产品设计、开发、测试等人力与技术的支持；另外，乙方有生存压力，所以他们对成本与效能的管控更好，且实施效率快。
当然，乙方同样存在劣势，他们对特定的需求理解不够或他们需要放弃一些特定的需求，他们与真实用户的距离比较远，如何获得真实且正确的客户需求是一个难点；另外，好的乙方人力资源很紧张。
2、差距分析有了上面甲乙双方优劣势分析，可以明显的看到将甲方和乙方的优势结合是一个很明智的选择方向。不过，从经验看，在这个过程中甲方要解决一个难题：“如何让乙方将资源向我们倾斜”。
如果你是行业TOP5，或在一个大的区域范围内的TOP3，很好，乙方可能会基于战略考虑，给你更多资源；如果你给足够多的钱，项目够大，乙方也会给你更多的资源。也就是说如果你所在企业名气大或给的钱多，乙方的资源倾斜问题不大。
但，如果你的项目预算不算多，企业的名气又不能支持乙方的战略销售方向，我们应该如何获得乙方资源支持呢？
就这一点，我和不少厂商的朋友聊起，得到了这样一个回答：这个甲方可以作为产品孵化场所，甲方的团队对产品或场景的理解更有前瞻性、更深入。
想想看，如果有一个甲方能分析乙方现有的产品能力，有针对性的梳理出优化的方向，或提出一种全新的模式，对于乙方来说是得到了一个更懂用户的产品经理或需求分析人员，将是一个很美好的事。
上面的观点很重要，将是我们甲方在合作开发中的一个切入点。不过在现实中，我们很多运维开发人员或以技术导向进行工具开发与设计，或主要承担项目经理或实施经理，对产品设计及后期运营支持比较少，这个背景不利于乙方对产品功能完善的诉求。
所以在合作开发的模式下，我们甲方要充分发挥我们的优势，要去掌握一些产品设计的思想与方法，以下进一步介绍一些方法。
三、一些方法
由于缺少一个成熟方法论的支撑，这里抽象出来的方法目前看可能比较分散，各位可以有侧重的阅读。
1、先讲项目背景因为后面的方法介绍中需要举到一些例子，所以先把例子涉及的项目背景简要说一下。
我们是以“监、管、控、析”为主线的运维工具体系建设，分别对应监控工具集、流程管控及IT服务工具体、生产操作自动化、运维数据分析。这个工具体系思路是以领域驱动的设计思路，将运维工具体系中不同领域的工具进行分解，重点是领域深度上的扩展性。
虽然在扩展性方面解决了我们的工具建设问题，但在实际的工具使用过程中我们仍然会遇到几个问题：
由于一项工作场景通常需要使用到“监、管、控、析”多个工具，用户需要在多个工具中来回切换，工作方式仍以经验导向，缺少一个经验沉淀或最佳实践的落地；
有重复建设的问题，互联互通程度不够的问题；
大部份工具是面向与生产环境交互的自动化，但是对于日常运维管理及事务性的工作，线下程度高；
为了解决上述问题我们提出了场景可视化项目。项目在工具体系层面上是在“监、管、控、析”之上建立一个信息整合层：
上图的场景可视化层的核心目标是：结合团队背景，以“场景”的思想，以可视化为主要手段，构建管理及事务性工作自动化，整合”监管控析”工具集的工具调用与数据的互联互通，落地运维专家的最佳实践。
为了支撑上述目标重点要进行以下三个手段：
统一可视化；
自助式与关键场景构建；
管理及事务性工作自动化。
项目以“场景”作为核心思路，即“特定的时间+特定的环境+特定的人+特定的事件+特定的连接方式”，场景思想作作为后续所有的场景设计的指导思路，以提高扩展性。以下尝试用一个故事来介绍一下项目：
2、方法关于产品设计的方法套路根据不同的行业，不同的角色会有不同，从甲方角度考虑产品设计相对更简单一些，我们通常重点要北京治疗白癜风哪个医院安全白癜风有好的治疗方法吗