在之前的博客中,我谈到了为什么将“系统思维”方法引入应用交付如此重要,使其更像一个为高效价值交付而优化的工厂。 要达到这个目的意味着要评估您所依赖的工具以及您选择和采购这些工具的过程。 效率要求尽可能优先考虑可重复使用的模式,以及选择跨团队和环境一致的工具和流程。 从理论上来说,这对大多数人来说都是有意义的,尤其是当所讨论的工具与基础设施或安全相关时——对应用功能的影响极小。 然而,在构建此类模式的过程中,经常会遇到一个未被充分重视的障碍: 供应商和采购流程。
目前,DevOps 工程师使用云原生工具、开源解决方案或其他类型的廉价(或免费)资源并不罕见,这些资源不需要大量投资或与采购团队的互动。 但是,如果您需要倡导更丰富的 IT 投资来提高所需的效率并确保您的应用程序具有更好的安全性和性能,该怎么办?
以下是 DevOps 专业人员在应对采购流程的未知领域时需要牢记的一些事项。
如果您正在阅读此博客,则您可能更愿意关注所需的技术能力,可以整天讨论 API,并且痴迷于优化。 但你猜怎么着——负责签署大额支票的同事可能根本就不在乎这些。 这就是为什么您可以做的最大的事情就是支持购买新工具或资源,用他们的术语来表达它将带来的商业价值。
通常,这首先要确定当前缺少什么或不足什么。 仅仅因为现在有新工具可用而要求购买,远不如强调其重大缺陷或责任、概述该缺陷造成问题的方式(减慢生产速度、暴露漏洞等),然后提出一个可以解决所有问题的新工具更有说服力。
需要关注的三个关键要素是成本、价值和风险。 从商业角度谈论这些问题很重要——特定的解决方案如何解决以下确定的问题:
在所有这些中,尽可能量化每一个是非常重要的。 没有人想要纯粹定性的意见。 硬数据很重要。
对于采购部门(以及更广泛的财务团队)的同事来说,一切都有成本和价值。 这包括(面对已知问题)不采取任何行动的成本,以及将工人从处理这些问题中解放出来的价值。 请注意,虽然 NetOps 可能发现消除日常任务的价值在于它使工作不那么繁琐,但财务团队却认为释放这些工程师的精力以专注于战略性的创收计划很有价值。
F5 技术解决方案经理 Will Marken 建议您“将自己定位为问题解决者;当您专注于创造价值时,将所提出的解决方案与企业愿景联系起来 - 这表明您可以按照管理层的条件与他们互动并满足他们的需求。 ”
您的团队可能全力通过订阅模式购买解决方案,然后发现您的组织围绕大型资本支出,并且缺乏以订阅方式为 IT 投资提供资金的流程。 在这种情况下,您还需要做一些额外的工作。 您可能会发现切换到资本支出预算请求(例如,随着时间的推移而摊销的单笔大额采购)更容易。 另一方面,即使是那些迟迟不愿接受订阅模式的公司也在想办法支持它们。 您可能只需要留出一些额外的时间,让您的财务同事解决他们自己的组织流程挑战。
虽然听起来很陈词滥调,但这确实是关于旅程而不是目的地的例子之一。 证明大额购买的合理性通常需要多次尝试。 事实上,您的请求很可能会与其他已经经过两到三个预算周期的请求进行竞争,在此过程中不断完善重点并获得支持。 当你听到“不”时不要放弃。 相反,要为它做好计划,当它来临时接受它,然后从那里开始进行调整。
处理采购就像您在敏捷工作流程中处理任何其他任务一样。 发现问题;逐一解决;然后迭代、迭代、再迭代。
对于较大的预算要求,将项目划分为更易于理解的部分通常会有所帮助。 这有两个好处:a)当焦点更集中时,更容易创建合理的 POC(概念证明)并识别现实世界的价值;b)负责人更容易批准较小的请求。
有各种各样的理由可以证明向组织中的其他人寻求帮助是一个好主意。 首先,您的直接或跨团队同事可能更熟悉整个采购流程,尤其是 F5 解决方案的价值,因此可以帮助您制定请求(并避免已知的危险)。 您还可以通过展示您提出的解决方案如何对多个部门产生积极影响来降低感知风险。 最后,发现另一个团体已经尝试过与您的类似的请求(在这种情况下您可以向他们学习)或甚至可能已经开始实施类似的解决方案(在这种情况下您可以与他们合作)的情况并不少见(特别是在非常大的组织中)。
在制定预算申请时,您可以依赖许多相同的策略来创建您所在领域的更典型的文档,例如白皮书和数据表。 首先要找到合适的模板,以便您知道您的请求看起来和读起来都像经理熟悉的其他请求。 它还包括在整个过程中将其交给多位同事以获得输入和反馈。 F5 产品开发经理 Jon Gross 补充道:“与数据表和白皮书一样,成功通常取决于描述或开头段落。 ” 他建议您“寻找现有的参考架构和用例,以便通过真实世界的数据点来支持您的实施路线图。 ”