关于尊重使用AI的指南

将传统的软件基础设施组织融入产品管理，并转向平台工程，已成为当今的热门趋势。作为亲身经历过这两种转型的人，我毫不惊讶地看到许多人在此过程中挣扎。这些转变要求从孤立的、流程驱动的技术思维转向以组合、可用性和客户为中心的思维。这是一场艰难的变革，对于那些整个职业生涯都在构建基础设施的人来说，很容易误解产品和平台的含义。因此，我想分享成功的秘诀：整个工程文化必须改变。

基础设施组织在许多方面表现出色：成本管理、供应商谈判、大规模系统运行。他们拥有精通数据库、网络和内核调试的专家，甚至可能擅长处理来自数十个团队的故障请求、规划大规模故障测试和协调大规模迁移。然而，他们通常不擅长思考用户的需求、考虑用户的偏好，也不把用户视为需要留住的客户。为什么他们会这样？因为用户是被迫使用他们的系统的！正如我在关于内部平台产品的文章中所提到的，这是平台和基础设施团队必须克服的重大挑战。

这种以成本、规模和流程为中心，忽视人和可用性的文化很难根除，而且你不想在这个过程中失去那些宝贵的技能。那么该怎么办？你不能简单地雇佣产品经理就了事。首先，要清楚一点：即使能找到足够多愿意从事这类工作的优秀产品经理（实际上很难），产品经理只有与愿意配合的工程团队合作才能发挥作用。如果工程团队没有为客户交付优秀产品的责任感，产品经理很可能沦为高级的待办事项整理者，而不是真正的产品领导者。

你需要改变支持产品的方式。工单系统黑洞是让客户感到自己更像负担而非关注对象的典型方式。我理解管理大量请求很困难，但密切关注支持方式、响应时间和问题分类对于转型至关重要。工程师应该花时间支持自己的产品。如果他们不经常回答问题，就会错过理解客户痛苦的机会。注意不要将此视为可选任务或只交给初级工程师。高级工程师如果不善于礼貌且有效地与用户互动，就无法构建人性化的产品。如果你担心某人在支持场景中的表现，那么这个人可能正在构建难以使用的产品。随着时间的推移，你可能会发现需要重做很多工作，因为那些代码难以支持且引发大量投诉。

你需要更新面试流程。我建议在所有面试中加入“客户同理心”的筛选。这不一定要深入，可以简单地问他们如何考虑编写代码以便其他开发者理解，或者他们如何回答关于构建的系统的问题。但你要设定基调：期望开发者不仅要考虑如何构建系统，还要考虑使用或协作的人。

你需要更新认可和奖励体系。如果你只提拔解决重大技术问题的人，那么很难留住那些致力于改善可用性、积极倾听客户团队并调整工作优先级以解决最痛苦问题的员工。因此，要仔细审视你在庆祝、奖励和晋升什么，确保包括使产品变得更好的工作，即使它不是最难的技术部分。请记住，这是文化变革，而文化变革如果不涉及认可和奖励方面的价值观变化，注定会失败。

你的项目经理是否过多？在基础设施组织中，过度依赖项目经理可能导致缺乏关于迁移等技术任务的前期规划。如果你的迁移如此痛苦，以至于团队和客户团队都需要项目经理来了解依赖关系和跟踪进度，那么你并没有承担起软件用户体验的责任。是的，迁移是用户体验的一部分！令我惊讶的是，基础设施团队经常提供与现有系统不兼容的新系统，并期望客户自行完成所有迁移工作，而且通常按照发起方规定的时间表。如果转向平台模式，你需要承担比现在更多的迁移工作。平台的价值主张必须包括降低客户的迁移痛苦，这意味着提高自行完成迁移的能力。通过限制项目经理的数量，迫使工程师面对他们不想做的项目管理工作，优秀者会意识到，如果他们创建自动化支持迁移（例如依赖检测、兼容性桥梁库或允许更改内部而不改变客户端库的抽象），就不必做那么多繁琐的项目管理工作。节省自己的时间也节省了客户的时间。因此，限制项目经理是一个很好的推动力。只需确保给团队时间完成这些工作，而不是让他们痛苦或把项目管理工作转嫁给新产品经理。

你的团队将花更多时间与客户沟通，而非纯粹编写代码。工程团队的产品思维转型没有捷径。你不能只添加一个产品经理或每季度召开一次客户咨询委员会会议就了事。团队需要花更多时间与客户在一起，并战略性地规划如何解决整体问题，而不是仅仅处理最新的客户投诉。改变工作方式会有前期成本：他们可能完成更少的工单或其他流程导向的生产力指标，工作速度可能看起来比之前处理无尽工单时慢。但随着时间的推移，产出的工作质量会提高，体现在客户调查、采用率、迁移时间线以及最终的工程生产力上。

保持乐趣！当公司经历这种转型时，基础设施组织与其他业务/产品工程团队之间往往存在严重的对立状态。这种情况对基础设施组织来说从来都不好受。无论他们如何声称用户无可救药或忘恩负义，与用户保持对抗性关系以及与同事陷入“我们对抗他们”的动态中都不是有趣的事。因此，虽然转型会棘手，但如果你允许，它也可以变得有趣。收集用户对产品喜爱之处的反馈，分享收到的赞誉，并花时间庆祝客户满意度指标的改善。确保团队在因他们的工作使应用团队能够做到以前无法做到的事情时参与庆祝。这是一次激动人心的机会，是学习、现代化工作方法和创造更积极文化的契机。以积极的态度领导将使每个人更加享受这个过程。

总而言之，这种文化转变在很多方面与“devops/SRE”变革相似。SRE组织的工程师不会故意构建代码然后扔给运维团队。同样，产品导向组织的工程师不会不考虑用户就构建软件。这些转型对工程团队提出了更高要求，但带来了更高质量的成果。这需要时间和成本，但我保证，这是值得的。

喜欢这篇文章吗？你可能也会喜欢我的书《经理的路径》（The Manager's Path），可在亚马逊和Safari Online购买。