如何缩小开发人员和生产支持团队之间的差距？

Question

要明确我的问题，请允许我定义标题的条款 -

生产支持团队是维护当前正在使用的软件应用程序的资源。开发人员是从需求中编写软件应用程序的编码人员。

通常至少在我的工作经历中，这两个团队最多只会见一次或两次，讨论下一个产品发布。假设生产支持团队将在不查看需求或设计文档或永远与客户或利益相关者会面的情况下了解潜在风险。预计在与开发团队的一两次会议中，Prod支持团队将了解并缓解和解决此版本中的潜在风险。

这就是问题所在，我的任务是制定指导方针，缩小生产支持团队与开发人员之间的差距。你有什么想法？当两支球队走到一起时需要提出什么问题？

Answer 1

让人们在两队之间轮流一会儿。这样，当他们回到原来的团队时，他们会更好地理解其他团队面临的问题。

Answer 2

从一开始就拥有两支球队是一个错误。

我在其他公司见过这个（两个不同的团队），我总是惊讶于这实际上是在现实世界中完成的。

我建议只有一个开发团队 - 有些人负责支持，有些人正在进行新的开发 - 但没有明确的界定。

首先，新代码的开发人员没有自然的反馈循环（正面或负面）来实际使其可维护。他们只是把它扔在墙上让维护人员处理。

我也看到它创造了分裂，而不是凝聚力。我没有看到任何关于这种情况的积极/好的东西，而我看到一个产品团队有很多好处。

我无法理解。

我同意其他人 - 要么轮流，要么组成一个团队。

编辑：

因此，对于那些无法轮换团队或组建一个团队的人：

• 双方必须能够了解出现的问题。也就是说，生产的反馈必须得到开发团队的支持。
• 如您所愿，让生产团队参与初始设计，规划和需求收集阶段。
• 团队必须能够轻松访问彼此

编辑：

我曾经在一家公司工作过，这家公司的小团队是从开发团队的其余部分借来的 - 他们称之为“特警队”。他们将为一些大客户构建特定功能或收取费用，代码将放在特定分支上。虽然类似，但他们仍然从所有开发人员的池中走出来。

Answer 3

我会把Elie的建议更进一步，并说总是让人们转动。我不知道任何开发人员只是乐于对其他人编写的代码进行维护工作。

另一方面，只编写新代码的开发人员将不会感受到维护的痛苦，因此无法学习如何编写可维护的代码。

修改
理想情况下，我同意蒂姆 - 真的不应该是单独的球队，这是一个糟糕的做法。我假设你没有权力做出改变的激进，但也许你这样做:)。

Answer 4

一些初步想法：

1. 制作团队是利益相关者，因此他们应该从第1天开始参与。您的系统是否可以支持？它是否将警报事件发布到支持系统/仪表板？是否需要任何手动流程（例如周末反弹）？通过在项目开始时与支持人员交谈，您将创建工作关系的开端。
2. 尽可能通过'生产'您的系统尽快涉及生产支持。即尝试将您的Smoke，QA和UAT构建管理，就好像它们是生产系统一样。烟雾构建并不总是可行，但QA / UAT应该是可能的（甚至是必需的）。
3. 培训和文档。教育生产支持团队并为他们提供良好的文档。
4. 确保您有第二或第三线支持流程 - 即生产支持团队可以在需要时与开发人员取得联系。

Answer 5

真正的整合只能来自同一个项目中的合作。

最好的事情是支持团队参与开发，例如团队由4个元素组成，每周一个人主要是支持，而其他人则在开发。这意味着支持人员可以在再次支持之前休息3周。

这使得人们将这个项目视为他们的“自己”，并避免因为有时支持的愚蠢问题和无脑任务而疯狂。

还要记住，支持团队通常更了解用户以及他们使用系统的方式。因此，他们处于改善它的最佳位置。

生产支持团队应该能够访问要求或设计文档，并参与使其保持最新状态。

Answer 6

对于我自己，我尽可能地与PSG人员一起出去工作，无论是在工作还是在外面。此外，如果他们遇到问题，我会起床，如果可以的话，立即去帮助他们。你越了解他们，他们在生活中遇到的问题和麻烦等等，你就能越好地为他们做好准备。

Answer 7

我已经取得了巨大的成功，让开发人员和支持团队坐在一起，或者至少花一些时间在一起。这样就可以提前播出想法和假设，并且可以更快地解决某些问题。

Answer 8

以Elie，Tim和26中的17人为基础：
每个版本的每个团队进出25％-33％。谁在那里最长的;我不在乎你的职称是什么（高级建筑师北半球或peon）。支持是有效地应用程序，他们知道所有的问题（并将确保它们被修复 - 这一直困扰我3个周期＃$％＃$％＃$％），开发知道最新版本最好，所以他们最适合故障排除（哦，当然，这个问题将出现在XYZ功能中）。