在产品和工程工作之间分配时间

在我工作过的每家公司，我们都将时间分配到产品计划和工程工作之间。百分比总是会发生变化，有时是 70% 的产品，30% 的工程，有时甚至高达 50/50 的分配。其目的是确保工程团队将部分时间用于构建新功能，同时确保我们能够进行“我们自己的”工作，例如解决技术债务、升级系统和记录我们的代码。

问题是，在一开始说起来容易，但要把它变成现实就难了。 我看到这种模式失败的原因有很多，不是因为人们在理论上不明白它的价值，而是因为在实践中，有一些常见的陷阱需要你考虑。我们将从工程领导者的角度探讨其中一些场景，以便我们找到一条良好的前进道路。

问题

以下是一些基于可能出错的情况而做出的反应和计划，所以让我们先谈谈如果设置不当，你会遇到哪些挑战。

• 产品可能会出现冲突，无论是工作本身还是所花费的时间。 这会加剧产品和工程团队之间的关系。如果他们感到措手不及，你可能会发现你的工作范围变得越来越严格。
• 你的工程师可能不明白他们应该做什么。 工作的并行化可能很难做到，因此构建一个良好的流程可以提供清晰度。
• 维护路径应该很清晰： 你是否计划进行大型系统升级？这可能会随着时间的推移影响其他团队，如果你没有明确最终的所有权，它可能会回来困扰你。👻

虽然在你的工程时间里拥有一些自由是件好事，但沟通、计划和明确的期望可以帮助确保你避免上述任何问题。

沟通

一旦你弄清楚了你想解决什么问题，写一份简短的单页文档，与利益相关者分享工作性质、所需时间以及其重要性，这一点至关重要。

如果这是一个大型项目，你也可以将这些部分细化到 GitHub/GitLab/Jira 问题中，并添加一个标签来标识工作类型。这样做很好，因为你可以使用你现有的任何项目管理系统来提高每周的工作量和期望。最好与你的产品合作伙伴保持沟通，了解范围和工作性质，这样他们就不会对其他工作感到惊讶。这在很大程度上取决于团队和组织的文化。

这也有助于为你的工程师提供清晰度。如果他们了解工作的性质以及对他们的期望，他们就更容易解决构成整体的那些小问题。

你可能会发现，从重点的角度来看，让每个工程师将时间分配到产品和工程项目之间没有意义。 他们可能更愿意在他们之间分配工作：三个人在产品工作上工作几周，一个人在工程工作上工作。也有一些时候，每个人都需要参与进来，这样他们才能拥有同等的机构知识（迁移可能是这样的，具体取决于是什么）。你的情况可能会有所不同，这取决于团队规模、产品工作的数量以及项目类型。

沟通在这方面也很有帮助——如果你不确定哪条路是正确的，可以作为一个小组进行一个小小的头脑风暴，讨论如何完成这项工作。只要确保在你这样做的时候，你也让每个人都明白为什么这个项目很重要。

项目类型

在你的工程团队时间里，你可以创建很多类型的项目，而且从我所见，每种项目都有稍微不同的方法，所以让我们分别看一下。

技术债务

让我们先解决技术债务，因为这是最常见的可以释放你团队的工作之一。对于你编写的每个功能，如果工程工作速度变慢，你不仅在产品开发方面损失了时间，而且在工程人员的工资方面也损失了金钱。

少量的技术债务是正常的，尤其是在规模较小的公司，在那里快速行动在经济上更合理，但有一些点，技术债务会对开发和发布造成严重影响，并使代码库不稳定。有时需要立即完成，以确保所有工程师都能高效地工作，有时则需要逐步完成。

在很多情况下，技术债务是你通过自下而上的方法发现你需要做的：最接近系统工作的开发人员比工程经理 (EM) 更了解日常的技术债务。作为 EM，挑战在于注意到更大的模式，例如，当许多人抱怨同一件事时，而不是一个可能意见强烈的开发人员。在你开始这类项目之前，询问一下可以提供帮助——调查一下人们认为他们每周浪费了多少时间，以及采用替代方案的前景。

有时技术债务仅仅是大量的重构问题。我看到，当人们一开始就明确哪些类型的拉取请求 (PR) 是必要的，效果最好。 你是否需要在一百万个地方更新 CSS？或者将旧的类组件转换为钩子？你可能不想要一个包含所有内容的巨大 PR，但将这项工作按组件分解也不明智。作为一个团队，共同协商每个 PR 将包含多少内容以及对审查有什么期望，这样你就不会在工作进行时创建“审查漏洞”。

创新项目

许多公司会进行黑客周/创新周项目，让开发人员可以不受束缚地开发一些与公司产品相关的功能。这是探索的好时机，我看到一些著名的应用程序通过这种方式添加了一些强大的功能。对于团队来说，看到他们自己的想法变成现实，也是非常振奋人心的。

在分配的工程时间里进行这类项目的问题在于，有时会让产品团队感到有些被冷落。为什么呢？好吧，换位思考一下。他们的工作是提出这些功能，与利益相关者仔细计划，制定路线图（通常基于公司指标和研究），并进入工程时间表，通常与项目经理合作。如果你将一半时间花在未经计划的功能上，你可能会使现有项目的计划分叉，违背他们已知的一些研究，或者仅仅减缓获得他们需要的核心功能的进程，而这些功能是成败的关键。

我看到这种做法奏效的方式是，EM 与产品团队提前沟通。 把这看作是一种合作关系：如果产品团队说某个特定功能没有意义，他们可能有一个很好的理由这样认为。如果你能相互倾听，可能就会有一条前进的道路，你们双方都同意。

也要解决他们的担忧。他们是否担心没有足够的时间做产品工作？直接询问你的团队，他们认为以半时间完成可能需要多少周（前提是他们开始深入挖掘后，事情可能会发生变化）。向每个人明确表示，你并不期望以飞快的速度完成工作。

归根结底，沟通是关键。理想情况下，这些都是不会破坏任何事情的小型项目，可以与日常工作并行完成。我的建议是先尝试一些非常小的项目，看看会遇到什么障碍，同时也要让产品团队相信你仍然会完成你的工作，不会“擅自行动”。

最后一步是弄清楚谁负责指标、结果，以及当事情不顺利时谁来负责。产品部门能够决定方向的部分原因是，他们在产品失败时要承担责任。确保你清楚地表明，作为工程负责人，你将对结果负责，包括好的和不好的，以维持良好的关系。

缓慢持续的工作

这可能是所有项目类型中最清晰的一种，并且可能受到最少的阻力。这类工作的例子包括内部文档、工具（如果没有专门的工具团队）或少量维护工作。

这里需要的沟通方式与其他项目略有不同，因为它不一定是一个需要交付的有限制性项目，而是一个迭代过程。以文档为例：我建议在任何功能流程中都安排时间进行内部文档工作。

例如，假设你创建了一个允许团队协作的新功能。公司里并非所有人都知道你为此功能创建了一个微服务，任何团队都可以使用它，并且了解所需参数或如何在未来添加功能。内部文档可以决定该服务是否被使用，以及你的团队是否需要每次有人需要使用它时都与他们配对。更糟糕的是：他们试图自己解决问题，并以一种混乱的方式处理本可以更快、更有效地完成的事情。

与创新项目不同，缓慢持续的工作通常不是人们真正渴望做的事情，因此最好立即制定一个流程和预期。内部文档是团队运作良好的隐藏但非常重要的部分。它有助于入职、让每个人对系统架构达成一致，甚至可以帮助开发人员真正巩固他们所构建的内容并思考解决问题的方式。

迁移

迁移的处理方式与其他类型的项目略有不同，因为它可能会影响所有人。没有一种正确的方法，而且很大程度上取决于迁移的类型——框架到框架、分解单体应用、迁移到不同的构建过程或服务器，这些可能会有不同的方法。由于这些方法中的每一个都可能是一篇文章的内容，让我们来讨论一些适用于迁移组织的总体选项。

• 我的第一个建议是在进行任何类型的迁移之前进行尽可能多的研究。不可能了解所有内容，但你不希望在流程进行到一半时才发现一些关键信息。这些信息对于与利益相关者分享也很有用。
• 公司内部是否存在关于发展方向的争论？限定一段时间来解决问题，并确保最后有一个明确的决策者。许多技术问题没有唯一的“正确”解决方案，因此让一个人负责决策，其他人可以不同意但承诺执行，这会有所帮助。但你也要给人们一些时间说出他们的担忧，即使他们不同意——他们可能会想到一些你没有想到的事情。
• 记录一个迁移计划，包括高层计划，然后分析对每个团队的影响。这也是向产品部门解释这项工作的重要性的好时机：你的代码库是否已经过时，无法很好地与其他库和工具协作？是否出现了一个新的构建过程，可以节省工程师在发布过程中的时间？帮助他们理解这项工作的重要性。
• 明确维护和所有权。如果一个团队迁移了构建过程，而这导致了另一个团队的问题，那么谁来解决问题并解除该团队的阻塞？你应该在事情发生之前就决定好。
• 有些迁移路径允许你随着时间的推移或逐个团队地慢慢进行，或者提前完成大部分工作。但是，通常有一个关键时刻需要所有人齐心协力。与其他可以并行进行的工作不同，你可能需要与产品部门协商，在新的系统到位之前，暂停所有其他功能工作。如果你与他们密切合作，你可能会发现他们在季节性上有客户数量较少的时期，这可以让你喘息的机会来完成这项工作。我建议，如果他们愿意让你将工程团队的时间完全投入一段时间，你也可以回报他们；一旦平台稳定，就可以将团队的时间完全投入产品工作。

庆祝！

这最后一步可能看起来是可选的，但在我看来，这是一件大事。你的团队刚刚完成了一件不可思议的事情：他们将工作并行化，他们与产品部门良好合作，他们为整个工程部门完成了一项工作。重要的是要像庆祝发布一样庆祝这项工作。

团队需要知道你重视这项工作，因为它通常是默默无闻的，但影响力很大。这也有助于建立信任，让他们知道，如果将来出现什么棘手的问题，这确实有助于他们的职业发展。与团队一起庆祝你所取得的成就成本很低，但对团队文化的影响很大。

购买本书

这只是我即将出版的新书中的部分内容示例……