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

为了使我的问题清楚,请允许我定义标题的术语 -

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

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

这就是问题所在,我的任务是制定准则来缩小生产支持团队和开发人员之间的差距.你有什么想法？当两支球队走到一起时需要提出什么问题？

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

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

我在其他公司见过这个(两个不同的团队),我总是惊讶于这实际上是在现实世界中完成的.

我建议只有一个开发团队 - 有些人负责支持,有些人正在进行新的开发 - 但没有明确的描述.

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

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

我无法理解.

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

编辑:

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

对于出现的问题,双方必须具有可见性.也就是说,生产的反馈必须得到开发团队的支持.

如您所愿,让生产团队参与初始设计,规划和需求收集阶段.

团队必须能够轻松访问彼此

编辑:

我曾经在一家公司工作,这家公司有一个小团队,从开发团队的其余部分借来 - 他们称之为"特警队".他们会为一些大客户建立特定的功能或付费,代码将放在特定的分支上.虽然类似,但他们仍然从所有开发人员的池中走出来.

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

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

编辑:
理想情况下,我同意蒂姆 - 真的不应该是单独的球队,这是一个可怕的做法.我假设你没有权力做出改变的激进,但也许你做:).