产品工程师的平台工程师指南（2019年）

久处了，我告诉朋友，我在工作中感到沮丧。我一直在为一个非常重要的产品功能增加支持，我们的平台团队正在难以置信。它觉得每一行代码需要一个月的谈判获得批准。让我们在这里诚实 - 我没有告诉我，我在抱怨。 “他们认为我们是白痴吗？”我问道。

她和我一样微笑着，直到我做的，直到我已经完成，她说：“你是白痴”。然后，她继续向她作为平台工程经理的经验，产品工程师和平台团队生活在一个平行的宇宙中。寻找共同点是一项挑战。我相信她用“愚蠢的狒狒”（这给这篇文章）的一点来说。

我的下巴下降了。我不认为自己是本质上的愚蠢（请避免在评论部分中分享证据，但我是愚蠢的吗？事情肯定不会顺利。我错过了什么？

我花了一些时间听她，然后要求我们小组的更多高级成员的一些指导，并对事情做得很好，而不是最摩擦的地方，这就是这篇文章来自的地方。

但在我潜入透视之前，我获得了使用顽固的大象，又名平台工程师，让我们澄清我们正在讨论的内容。

我对“平台工程师”的定义是一个工程师，其角色是为其他开发人员提供通常在内部使用的框架，而“产品工程师”是一个工程师，其角色是开发用户面临的特征。

作为一个经验的规则，如果你正在做你作为用户故事的任务的敏捷事物，而且故事中的用户是一个实际的用户 - 你可能是一个产品工程师。如果故事是关于贵公司的开发人员，那是一个您是平台工程师的好兆头。

我还看到了一些关于全架工程师的误解，有些人将他们困惑与产品工程师困惑。我所看到的定义似乎跨越了广泛的范围：从“可以做任何事情”到“​​垃圾可以访问键盘的天才”。

我对FullStack的定义很简单：可以完成一个编程任务的开发人员，其中包括后端和前端工作。资历或专业知识无关紧要。 FullStack可以是TIC-TAC-TOE REACT应用程序，带有Firebase后端，用于保存分数，或者在无服务区块链中存储数据的应用程序跟踪运行状况统计数据（或使用额外的流行语，使其声音复杂为实现）。

我承认大多数Fullstack工程师是产品工程师，因为他们为用户开发了特色，但它们不是代名词。根据组织结构：

最后，即使他们是前端工程师，我认为你不能认真地表明反应核心团队正在做产品工作。

所以，现在我们明确了这些条款 - 让我们谈谈产品工程师和平台工程师的区别，充分发挥作用。

产品工程师专注于用户面临的功能和客户需求，将平台代码视为一组工具和服务，这应该允许快速有效地写入产品功能。

平台工程师专注于创建一个基础设施，可以长时间使用许多不同的消费者使用，产品代码的小怪癖和特殊情况会干扰平台提供灵活和强大的服务的能力。

此外，产品工程师通常在同一地区的一组功能上工作，也许经常切换团队。因此，他们的观点主要限于他们现在正在努力的东西（或他们过去的一些事情）和他们使用的平台服务。他们没有太多的知识和对其他产品团队正在做的知识或认识，他们的工作可能会如何影响它们，而是深入了解不同的平台如何表现以及他们的不同范式和约定如何影响产品代码。

平台工程师可能具有与产品工程师相同的盲点，作为其他平台团队正在做的事情，而是通过它们在堆栈中的角色，他们可以了解某些更改可能会影响其他团队进行平台或产品工作的情况。正如我的朋友把它所示：“你可能需要这个参数中的2个，但这是另一个团队 - 他们需要它是一个3.我们不能支持两者，你必须弄清楚你自己”。

如果您是2019年任何类型的工程师，您可能正在使用敏捷。如果你正在这样做“书”，你应该在短时间内工作。如果您的任务不适合Sprint - 您将其分解为小块以确保它在该冲刺内完成。

只有，这是一个谎言：任务并不总是整个功能。我们在生产中获得了一些事实并不意味着该功能已完成。释放不完整的功能是常见的，这些功能不会准备好几个月，因此我们在特征标志后面门，直到我们实际准备就绪。

尽管如此，产品项目通常是短暂的，最多可在几个月内发布。计划，代码，测试，释放 - 或者您将错过市场！平台项目很长，他们的规划是彻底和缓慢的，有些项目需要多年才能完成。

现在，我喜欢清洁的代码和下一个人一样多（虽然我相信设计模式过度使用应该被认为是7个致命的罪恶之一），但作为产品工程师 - 如果我被陷入纠结的混乱，我必须犁通过它，快速完成。我无法阻止一切并清理。尽我所愿，我有一个截止日期。

此外，产品要求不断变化，有些功能被广泛杀死或修改，这意味着规划太远，过于工程代码是绝对浪费时间，是YAGNI的经典案例。

这使得产品工程师看起来很糟糕，仿佛我们正在与口香糖和图钉一起攻击东西，只要它有效。

平台项目花费这么长时间的副作用必须处理遗留代码。当产品功能模具时，大部分代码都可以安全删除。没有人这样做是因为它在裂缝之间滑落或因为它们太害怕（出于某种理解的原因），但总的来说 - 与死亡功能有关的大多数代码只是坐在某处死亡，而不是打扰任何需要写新的人特征。

平台代码不会表现这种方式。它在僵尸状态悬挂在僵尸状态，为产品工程师提供各种麻烦。就平台而言，它不推荐弃用，不应该得到支持。但是，如果仍有仍在开发的功能仍在使用遗留代码 - 他们需要支持，有时会修改。每次偶尔都有一个需要大的基础变化的功能，然后它是代码世界战z到处。

没有人喜欢用遗留代码搞乱，但产品工程师有哪些选择？请记住，我们很快就会截止日期。我们不能等到两三年，直到被推卖的僵尸代码已经死亡并埋葬了。往往，切换功能代码使用的任何平台都支持的努力都太大，并且不适合产品时机。

如果您在一个小型启动中工作，每个人都坐在同一个房间，工程功能之间没有实际分离 - 您可以跳到下一节。但是，如果您在更成熟的公司中工作，通常通常的不同团队甚至整个工程组织用于产品VS平台工作。这导致心理/情绪距离，以及各种功能之间的物理距离。

希望，您为您工作的公司不鼓励“美国与他们”的态度，但如果没有积极承认和解决，那么这种类型的东西就会有机发展。

如果您位于全球各地的不同城市或不同的城市，这使得这一切更加差：当您没有频繁的专业或休闲联系时，它更容易将对方视为“愚蠢的狒狒”或“顽固的大象“。

透视：产品和平台工程师对重要意义有不同的想法，导致他们在某些地区认为努力作为滋扰或作为最高优先级，具体取决于他们的观点。它们还有与系统的不同观点，作为整个交叉团队的担忧，API等。导致意外地方的摩擦和并发症。

速度与质量：产品工程师正在进行更短的时间表和不断变化的要求。强调速度和长期工程的速度较少使它们出现不关心代码质量。

Zombie Code：产品工程师有时需要修改遗留平台代码，从其休息的地方唤醒亡灵代码，为平台工程师造成麻烦和额外的工作。

距离：“美国与他们”的态度和缺乏稳健的工作关系使得越来越难以看到“愚蠢的狒狒”和“顽固的大象”标签和彼此尊重。

交流！对不起陈词滥调，但真的，这几乎是唯一的解决方案。

规划后，清楚地了解产品时间表和约束。不要隐含，明确说明您有意识地拨动权衡以及它们是什么。

有一个长期计划，与其他团队分享，并使用它来遵循这一长期愿景的短期决策。从协作角度来看，这更有效率，使其他团队能够了解大图片并获得一次协议，而不是每次问题出现时都必须与上下文切换。从开发角度来看，当前方的道路很清楚时，它也是更高效的，因为当前方的道路很清楚时，小决定更容易制作。

平台不等待你给他们更多的事情，他们自己很忙。如果您需要他们的帮助，请给他们礼貌，让他们知道你的计划是什么以及你需要什么样的支持。

尊重，不仅承担良好的意图，还要竞争力。毕竟，我们都为同一家公司工作，希望相同的目标。即使我们的直接利益可能会发生冲突，我们也应该努力看看它们。

记住，我们的观点是有限的，我们肯定不知道一切。事实上，要求提供其他团队的建议 - 事实上 - 这是确切的对面，这是让我们的工作完成最高质量下的最高质量的重要组成部分。

如果产品和平台工程师在欢乐时光期间谈话或站在会议室周围的会议室待在会议室以前的会议外，每次偶尔每次都会结束，或者一般 - 有一个坚实的关系和更广泛的个人视角你正在使用的人，你可能会认为他们毕竟不是那么糟糕。我不相信建设团队工作的强迫场外活动，必须每天完成。找到合适的机会并使其发生。

不要太害怕（或懒惰......）直接沟通。从你的电脑后面走出来，进入一个房间。讲话。会议可能会令人讨厌，并分散你的“实际工作”，但有时它们是沟通和绝对必要的最有效的方式，以便在顺利完成事情。

如果您不在同一站点工作，并且没有每一个小功能的旅行预算（毕竟是有意义的），请拿起您选择的视频会议应用程序，并不是互相交谈。

Slack对建立关系也不差，因为它感觉更加个性化而随便的电子邮件。

使用很多表情符号。 我没有数据来备份，但我相信它有所帮助。 远离JIRA或其他任务管理系统。 这些对于跟踪项目状况非常重要，但可用于建立信任和沟通。 在直接通信后更新JIRA并验证您的所有页面。 这些指导校长将（1）使产品工程师看起来不像“愚蠢的狒狒”，更像是我们所处的高技能专业人士，（2）帮助我们编写更好，更清洁，更可维护的代码。 每个人都赢了！ 感谢您阅读这一点，我希望您发现我的见解很有用。 请记住，这是由产品工程师的角度写的 - 我确信可以在这里添加的平台工程师有许多有用的见解。 对于任何您的任何人来说，我都会非常高兴从平台工程师的角度来看类似的帖子，或者只是留下下面的评论。