添加产品管理更传统的软件基础设施的组织,有时与转向平台工程,今天风靡一时。人所做的这些事情,我并不感到吃惊,看到如此多的人在努力使其工作。这些变化需要从一个孤立的过程,高科技为主的心态投资组合,可用性,和以客户为中心的心态。这是一个艰难的转变,人很容易就花了他们整个职业生涯建设基础设施误解产品和平台的真正含义是什么。所以我想分享的秘密做这项工作。

你的整个工程文化必须改变。

是的,认真。

基础设施的组织往往是擅长很多东西。他们擅长成本管理、供应商谈判、规模和运行系统。他们有专家知道的黑暗深处的数据库,网络的细微差别,如何调试的内核问题。他们甚至可能擅长进行错误的请求几十或几百个团队,计划大规模故障测试,和协调大规模的迁移。

不幸的是,他们通常不善于思考的人会使用他们的系统,考虑到他们的喜好,和治疗他们正试图保持像顾客。为什么他们?的人使用他们的系统是一个忠实的观众!正如我在我的帖子中提到产品内部平台,这是一个重大挑战,平台和基础设施团队必须克服建立伟大的产品。

这种文化,关注成本、规模、和过程,对人们和可用性,很难根除。你不想失去那些罕见的技能。那么你会怎么做?

你不能只是摩擦产品经理,到此为止吧。

首先,我们要清楚一件事:这可能是诱人的,只是招聘产品经理无法解决这个问题。即使你能找到足够好的产品经理想要这种类型的工作,你不能,产品经理只是搭配时有用的工程团队。如果工程团队不感到所有权提供好的产品给客户,产品经理不太可能弥合这一差距,他们将更有可能变成荣耀比真正的产品积压美容师的领导人。

你需要改变你的方式支持你的产品。

票系统黑洞是一个伟大的方式让你的客户感觉更像是一种负担,而不是关注的焦点。我知道很难管理您的团队的所有传入的请求,但在密切关注如何提供支持,你的响应时间是什么问题,以及如何分流的问题是这种转变的关键。你的工程师应该花时间支持他们的产品。如果他们不经常回答问题,他们已经错失了一个机会去欣赏客户面临的痛苦当试图使用系统。小心做这个可选的,或离开它只有初级工程师。你的高级人不会建立你需要的人性化产品,如果他们不能与用户交互的礼貌和乐于助人,不管他们可能看起来多么辉煌。如果你不能信任的人进行有效在帮助情况下,小心,因为这个人可能不是很容易使用的建筑产品。随着时间的推移,你会发现自己重做大量的工作,因为它是难以支持和推动大量的投诉。

你需要更新你的面试过程。

我建议增加筛查我称之为“客户移情”面试的阵容。这并不深,它可以简单地问他们他们如何思考如何写代码,以便其他开发人员可以理解它,或者他们的方法是对系统建立回答问题。但你想定下了基调,你希望你的开发者不仅思考如何构建系统,而是要使用他们的人或与他们一起工作。

你需要更新你的系统识别和奖励。

如果你只促进解决重大技术问题的人,你会很难留住的人做这项工作顺利出可用性边缘,积极听取客户团队,调整他们的工作重点解决导致最痛苦的东西。仔细看看你庆祝,支付,和促进,并确保你是包括工作,使产品更好无论看起来像什么,即使它不是最困难的技术。记住,这是一个文化变迁和文化变化,不涉及改变什么是价值识别和奖励时注定要失败。

你有太多的项目经理吗?

总有一些需要项目经理,但在基础设施的组织中,严重依赖项目经理会导致缺乏前期技术规划的最常见的一种基础架构团队任务:迁移。如果迁移很痛苦,你的团队和你的客户团队项目经理需要了解的所有依赖项所在并追踪正在发生什么,你不是用户体验软件的所有权。是的,迁移是用户体验的一部分!我惊奇的频率基础设施团队提供新系统不兼容的系统取代,并期望客户做所有的工作迁移到新系统中,通常在一个时间轴由初始团队。

如果你搬到一个平台模型,您需要拥有更多的移民比你直到现在。该平台增值必须包括为客户降低迁移痛苦,这意味着在做完全自己变得更好。现在通过限制数量的项目经理,你强迫工程师面临的项目管理工作,他们不会想做的事。好的会意识到如果他们创建自动化支持迁移,无论是检测依赖、兼容性桥接库,或抽象,允许他们改变内部结构而不改变客户端库,他们不需要做太多的繁琐的项目管理工作。通过节约自己的时间,他们将节省顾客的时间。所以限制项目经理是一个不错的强制函数。只要确保你给团队时间做这项工作,而不只是让他们痛苦或转移项目管理在新产品经理。

您的团队将会花更多的时间与客户交谈,而纯粹的写代码的时间反而少了。

没有办法快捷产品心态转变为你的工程团队。你不能只是添加一个产品经理或者一个客户咨询委员会会议应每季度一次,收工。团队需要花更多的时间与客户,和更多的时间战略规划如何解决整体的问题,而不是进行最新的客户投诉。将会有一个预先成本改变人们的工作方式。他们可以完成更少的票或其他面向流程的措施的效率,和工作的步伐看起来慢比当他们只是通过门票的永无止境的积压。但是随着时间的推移,产生的工作应该更好,以客户调查、收养、迁移时间,最终,工程效率。

保持它的乐趣!

公司通过这种转变的时候,他们通常在一个很深的us-vs-them基础设施之间的组织和他们的其他业务/产品工程团队。这种情况从来没有感觉良好组织的基础设施。无论多少表面上声称,他们的用户是绝望还是忘恩负义的(或更糟),它只是没有驾驶乐趣与您的用户有一个敌对的关系,并且觉得us-vs-them动态与同事的深处。因此,尽管这种转变将是棘手的,如果你让它,它也可以很有趣。从用户那里获得反馈对他们喜欢的产品。分享荣誉,因为他们进来,和花时间去庆祝你的客户满意度指标的改善。确保你的团队是庆祝活动的一部分,当他们的工作使应用程序团队做他们不能做的事。这是一个令人激动的机会,一个学习的机会,你的工作方法,现代化和创建一个更积极的文化,主要与积极的态度将会使所有的差异对每个人来说都是多么有趣。

结束

在许多方面,这种文化的变迁也发生的变化,在“devops”/行为转换。工程师在SRE-focused组织不构建代码,他们不小心扔在墙上一个行动小组。同样,工程师们在关注于产品组织不构建软件没有考虑用户的软件。这些转换问更多的工程团队,但提供高质量的成果。昂贵,需要时间,但我向你保证,这是值得的。

喜欢这篇文章吗?你会喜欢我的书,经理的路径,可以在亚马逊和Safari在线!