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

在我工作的每家公司中，我们在产品计划和工程工作上花费的时间都有分歧。百分比总是改变，有时是70％的产品，30％的工程，有时甚至是50/50分。动力是要确保工程学花费其一部分时间构建新功能，但也确保我们可以做“我们自己的”工作，例如解决技术债务，升级系统并记录我们的代码。

麻烦是，一开始这么说是一回事，而另一件事是使它成为现实。我看到这种模型失败的原因有很多，不是因为人们在理论上不了解它很有价值，而是因为在实践中，您必须考虑一些常见的陷阱。我们将从工程领导者的角度介绍其中的一些情况，以便我们可以解决一条良好的前进道路。

问题

下面的一些指示是根据可能出了问题的反应和计划，因此，如果不是正确设置，请首先谈谈您可能遇到的挑战。

• 产品本身或涉及时间可能会发生冲突。这可能会使产品与工程之间的关系构成关系。如果让他们感到惊讶，您可能会发现工作的界限变得更加限制。
• 您的工程师可能不了解他们的期望。努力的并行化可能很难做到，因此构建良好的过程可以提供清晰度。
• 维护路径应该很清楚：您是否打算进行巨大的系统升级？这可能会随着时间的流逝而影响其他团队，如果您不清楚最终的所有权，它可能会回来困扰您。 ？

在您的工程时间，沟通，计划和清晰的期望中拥有一些自由，这是很好的，可以帮助确保您避免上述任何问题。

沟通

一旦弄清楚要解决什么问题，至关重要的是写一个小单曲，您可以与利益相关者分享有关工作性质，将要花费的时间以及重要的重要性。

如果这是一个大项目，您还可以将这些零件放在GitHub/gitlab/jira问题中，并为其工作类型添加标签。这很棒，因为您可以使用已经使用的任何项目管理系统来提高每周的工作和期望。与您的产品合作伙伴保持范围和作品性质的对话是一件好事，这样他们就不会对其他工作感到惊讶。这将在很大程度上因团队和组织的文化而异。

这也可以为您的工程师提供清晰度。如果他们了解工作的性质及其期望，那么他们更容易解决构成整体的小问题。

您可能会发现，从重点的角度来看，将每位工程师分配时间和工程项目都不太有意义。相反，他们可能更喜欢将自己的工作分开：三个在产品工作中工作了几个星期，一个从事工程工作的人。有时候，每个人都需要参与其中，以便他们拥有平等的机构知识（迁移可以是这样，取决于它是什么）。您的里程可能会根据团队的规模，产品工作量和项目类型而有所不同。

交流也有帮助 - 如果您不确定正确的道路是什么，那么您可以将小精脑风暴作为您想完成这项操作的小组。只需确保您还与每个人都保持一致，为什么该项目很重要。

项目类型

您可以在工程团队的时间中创建许多类型的项目，并且每个项目都与我所看到的略有不同的方法，所以让我们仔细研究其中的每个项目。

技术债务

让我们首先解决技术债务，因为这是可以解锁团队的最常见工作之一。对于您编写的每项功能，如果工程工作放慢了，您不仅会在产品开发方面浪费时间，而且您在工程时间的薪水方面也损失了钱。

一定的技术债务是自然的，尤其是在较小的公司中，快速行动具有更大的财政意义，但是在某些地方，技术债务在开发和发行中变得瘫痪，并使代码库变得不稳定。有时需要立即进行，以确保所有工程师都能有效地工作，有时是逐渐的。

在许多情况下，技术债务是您通过较小的方法学习所需的东西：最接近系统的开发人员将比工程经理（EMS）（EMS）通常会了解哪些日常技术债务。作为EM的挑战是注意到更大的模式，例如许多人抱怨同一件事，而不是一个可能有强烈看法的开发人员。在开始这种类型的项目之前询问可以帮助 - 对他们认为他们在给定的一周浪费的时间与替代方案的前景进行调查。

有时技术债务是大量重构的问题。当人们在需要什么样的拉动请求（PR）上前进时，我已经看到这一点最佳。您需要在一百万个位置更新CSS吗？还是将旧类组件转换为钩子？您可能不希望所有这一切都有一个巨大的公关，但是分解这项工作也没有意义。作为一个团队共同努力，每个公关将拥有多少公关以及对评论的期望，因此您在完成工作时不会创建“评论漏洞”。

创新项目

许多公司都会进行黑客周/创新周项目，在该项目中，开发人员可以在不受限制地处理与公司产品有关的某些功能。这是一个探索的好时机，我看到了以这种方式添加到知名应用程序中的一些强大功能。团队看到自己的想法实现的想法也令人难以置信。

在分裂工程时间进行此类项目的麻烦在于，您有时会使产品团队感到有些轻微。为什么？好吧，从他们的角度想到事物。他们的工作是提出这些功能，与利益相关者仔细计划，整理路线图（通常是根据公司指标和研究），并按照工程时间表，通常与项目经理合作。如果您花了一半的时间在计划外功能上，则可能会为项目提供现有计划，与他们所拥有的一些已知研究相反，或者只是减慢过程，以获得所需的核心成绩或破坏其功能。

我看到的表现很好的方式是，当EM与产品前进时。考虑一下这是一种合作伙伴：如果产品说特定功能没有意义，那么他们可能会有充分的理由这样做。如果你们俩都可以互相听到，那么你们俩都同意的可能是前进的道路。

解决他们的恐惧也是一件好事。他们是否担心产品工作没有足够的时间？直接询问您的团队在他们认为可能需要花费几个星期的时间（期望他们挖进去时会发生变化）。向所有人清楚地表明，您不会期望以突破性的速度完成。

最终，沟通是关键。理想情况下，这些小型项目不会与常规工作平行地做任何事情。我的建议是先尝试一些很小的东西，以查看可能的颠簸，还可以通过产品建立信任，即您仍然可以完成工作，而不是“流氓”。

最后一部分是找出谁负责指标，结果以及何时进展顺利。产品决定方向的部分原因是因为它们在失败时会挂钩。确保您清楚地表明，作为工程领导者，您对成果负责，无论 保持良好关系的不良关系。

缓慢，正在进行的工作

这可能是任何类型的项目中最清晰的切割，可能会从任何人那里获得最少的回压。此类工作的示例是内部文档，工具（如果您没有专用的工具团队）或一小部分维护。

这里需要的沟通与其他项目有所不同，因为它不一定是您发货的一个受约束的项目，而是一个迭代过程。以文档为例：我建议在任何功能过程中筹集内部文档的时间。

例如，假设您创建了一个允许团队协作的新功能。并非公司中的每个人都可能知道您为任何团队都能使用的该功能创建了一个微服务，以及预期的参数，或者如何在道路上添加功能。内部文档可以是所使用的服务以及您的团队每次需要使用它时与某人配对之间的区别。或更糟糕的是：他们试图四处乱逛并自行弄清楚，从而造成了可以更快，更有效地处理的东西的混乱。

与创新项目不同，缓慢而持续的工作通常不是人们真正渴望做的事情，因此设定一个过程和期望直接效果最好。内部文档是一个有时隐藏但非常重要的一部分，这是一个功能齐全的团队。它有助于入职，让每个人都在同一页面上了解系统体系结构，甚至可以帮助开发人员真正巩固他们的构建和思考，并通过如何解决。

迁移

迁移的处理方式与其他类型的项目有所不同，因为它可能会影响所有人。没有一种正确的方法可以做到这一点，也将在很大程度上取决于它是哪种类型的迁移 - 框架到框架，分解整体以及迁移到其他构建过程或服务器的框架可能具有不同的方法。由于这些事实可能是其本身的文章，因此让我们仔细研究适用于组织的一些高级选择。

• 我的第一个建议是对您正在做的任何类型的迁移进行尽可能多的研究。没有办法了解一切，但是您不想让一部分过程中找到一些关键的过程。这也是与利益相关者共享的有用信息。
• 关于您的公司应该朝哪个方向前进的内部辩论吗？时箱是解决问题的时间单位，并确保您最终有一个明确的决策者。许多技术问题没有一个“真正的”解决方案，因此让一个所有者做出决定，而其他所有人都不同意和提交可以提供帮助。但是，您还想给人们一点时刻，让人们听到他们的声音，即使他们是不同意的，他们也可能会想到您不是您的事情。
• 记录一个迁移计划，无论是高水平，然后通过对每个团队的影响进行工作。这也是解释产品的好时机，为什么这项工作很重要：您的代码库是否会变得旧，并且不能再与其他库和工具一起玩得很好？是否出现了一个新的构建过程，可以在发布过程中节省工程师的时间？帮助他们了解为什么工作至关重要。
• 清楚维护和所有权。如果一个团队迁移了一个构建过程，然后引起另一个问题，那么谁在解决该团队的问题？您应该在发生之前做出决定。
• 某些迁移路径可以随着时间的流逝或团队的团队来缓慢地做事，或者在前做很多工作。但是，通常有一段时间至关重要，需要所有的手甲板。与其他可以并行的其他工作不同，您可能必须使用产品来处理一些其他功能工作，而所有其他功能工作都会停滞不前，而您可以在适当的地方进行新的系统。如果您与他们紧密合作，您可能会发现，在季节中，您自然会有更多的客户休息，并且可以为您提供完成此操作所需的呼吸空间。我建议，如果他们愿意让您花时间100％，那么您就会回报。一旦平台稳定，就可以将团队的100％时间用于产品工作。

庆祝！

最后一步似乎是可选的，但我认为这很重要。您的团队只是做出了不可思议的事情：他们并行努力，是产品的好伙伴，他们为整个工程组织做了一些事情。庆祝作品就像您的发射一样至关重要。

团队需要知道您重视这项工作，因为这通常是令人不愉快的，但是很有影响力。它还可以建立信任，知道如果将来会出现毛茸茸的事情，它确实也有助于他们的职业道路。与您的团队一起庆祝您所取得的成就的成本很少，并且具有很大的文化影响。

买书

这只是我最新一本书的内容的样本……

加入列表！

以上是在产品和工程工作之间分配时间的详细内容。更多信息请关注PHP中文网其他相关文章！