基础设施团队:好的,坏的,或者根本没有

2020-05-20 23:07:39

我习惯在拥有产品团队和基础团队的公司工作。产品团队会考虑最终用户会做些什么,比如分享猫咪照片、订披萨或做他们最终要做的任何事情。

那么,下面的人,就是像我一样在他们下面辛勤工作的人,让所有的管道都能正常工作。如果我工作做得好,产品人员永远不会知道我的存在。他们只是继续使用我的东西,这对他们很管用,而且不会妨碍他们。他们可以专注于做他们最擅长的事情,这就是让最终用户满意。他们不必担心服务级别、YAML文件或我们在这些黑暗的基础设施巷子里强加给彼此的任何其他令人厌恶的东西。

但是.。并不是所有的公司都以同样的方式处理这件事。让我们来看看一些可能性,在那里有一个产品团队试图在他们的公司完成一些事情。他们有不同的体验,这取决于他们的公司如何处理某些决策。看看会发生什么。

A公司有一支为内部客户提供服务的团队。也许他们有办法让人们在公司的作业运行解决方案中运行作业。可能是物理硬件、虚拟机或某些容器协调情况。A&39;公司的团队做到了,而且做得很好。产品团队有东西要跑,把它和基础设施团队的服务联系起来,然后就出发了。人们是相对幸福的。

产品团队可以考虑他们的产品,而不是基础设施。他们之所以出类拔萃,是因为他们把宝贵的周期花在了他们擅长的东西上--他们的产品--而且他们不必太担心堆栈的较低层。有一个完整的团队在做这件事,而且做得很好。

B公司也有一支为内部客户提供服务的团队。它还声称在公司的作业运行解决方案上运行作业。确切的实现对这里的故事来说并不重要。你需要知道的是,他们在这方面绝对很糟糕。产品团队知道这一点,并希望他们不必处理这件事。

他们在这件事上别无选择。任何将团队视为伤害并绕过它的企图都会遭到迅速的报复。一旦有人发现一个团队甚至有点像是在那个领域工作,他们就会蜂拥而至,试图扼杀这个项目。任何威胁他们垄断这个领域的东西都必须被控制,如果他们不能控制它,他们就必须摧毁它。

随机生产产品的人现在必须知道其他人强制执行的武断的废话,比如库贝莱茨(kubelets&34;)和詹金斯(Jenkins&34;)。他们在糟糕的系统上烧毁自己的周期和理智,而不是改善公司最终用户的体验。

出于某种原因,C公司甚至没有一个团队来提供运行作业的服务。也许他们还没有想过用这种方式组织事情。也许他们“有”这样一支球队,它真的很糟糕,所以他们解散了它。管他呢。关键是,产品团队要靠自己。

实际情况是,每个产品团队最终都是在白费力气。有些人找到了很好的解决方案。一些人找到了糟糕的解决方案。总的来说,它类似于问题空间的随机游走。

如果有一点运气,再加上多一点的疏忽,团队最终可能会分享笔记,在那些被证明对他们有效的事情上汇聚在一起,并会避开那些不起作用的事情。也许他们会互相教会如何把事情做好。

这并不是特别有效率,因为你的产品团队不得不争论基础设施的废话,而不是处理他们实际要做的事情--建造和发展他们的产品--但它确实奏效了。

A公司行动迅速,产品团队把他们的基础设施负担卸给了一个有线索的团队。这些团队做他们最擅长的事情。他们的产品人员时刻盯着奖品,他们在业务上表现出色,不会陷入愚蠢的基础设施中。

B公司是一群可悲的失败者。它有基础设施团队,不能向同舟共济的同事提供有用的服务,管理层支持试图通过回避问题来解决问题的攻击性团队。产品团队痛恨他们的生活,因为他们被基础设施团队扣为人质。

C公司是一群衣衫褴褛的人,他们尝试不同的东西,希望它能奏效。没有人会因为他们尝试这些东西而攻击他们,因为它不是任何人拥有的。它不是某人管理领域的一部分。

我的猜测是,第三个连队的团队创造的随机游走的情况实际上比第二个连队中积极敌对的情况要好得多。“。

你可能会玩得很开心,因为有人在那里试着确保你玩得开心。

你肯定会过得很不愉快,你是控制不了的。你要么在他们面前下跪,要么就会挨打。

你可能玩得很开心,也可能不玩,但至少这取决于你。你掌握了自己的命运。你可以尝试新事物,也许还会有所改进。你没有坚持你的决定。

记住,这不是好与坏的对比。它是好的、坏的、没有的。实际上,有“两个”选择可以让你取得进步。