假设您必须向应用程序添加新的主要功能。那么将此功能添加到仍在建设中？还是但尚未投入生产的相对较小的应用程序中？还是将其添加到总体质量值得怀疑的，随着时间推移而增长的大型项目应用程序中是否更容易？毫无疑问，第二项更具挑战性的任务。但是为什么我们通常会找到最有经验的开发人员，即软件工程师，即很酷的人，而大多数人则参与其中，而其他人则常常被埋葬在第二项中？
多年前
很多年前，当我进入负责大型公司的核心系统之一的开发团队时，我担任的第一职位是负责遗留部件的应用程序维护（AM）团队。原因很简单，也很共同：我是新来的，使用经验很少的前沿技术，新项目正在快速运行。AM将是我成长的正确场所，而没有太多压力。
一旦我积累了足够的知识和经验，我就会转到项目团队，使用新技术开发新功能的团队，好人团队。大约一年后，这种情况实际上发生了，但是我永远不会忘记AM那个据说不太那么紧张的时期。
项目团队和AM团队
所有这些都是很多年前的，但是从那以后，我看到了无数次重复的相同模式，常常以更为极端的形式出现。您有一个新的计划，从项目团队开始。项目团队开发体系结构，项目团队开发功能，项目团队针对非常乐观的初始计划积累延迟，项目团队开始额外工作，项目团队开始偷工减料。
质量常常被牺牲在计划的祭坛上，测试被遗忘，补丁被添加到补丁之上。开发人员开始添加评论“待我们有一段时间后将其重构”。技术债务已经存在，其命运还在增长。
最终，该产品投入生产，然后，在上线之后，项目团队立即开始向AM团队过渡。经过一段时间的重叠后，AM团队将独自航行。AM团队通常比项目团队年轻，经验不足且实力不足。困难的部分结束了，该项目已经启动。现在是AM时间，它变得更容易，它的成本也更低，我们可以负担一个新的初级团队。
上线一年后
这是一年的紧张工作。错误已得到修复，小事情已更改，小事情已添加。该系统最终已准备就绪，可以承受实际的生产负荷，并且代码库已经扩展。此时，AM团队收到了添加新的重要功能的请求。
我们回到了最初的问题。现在添加新功能是否更容易，还是在“项目”模式下添加新功能更容易？
答案很明确：AM团队的任务要困难得多。的确，AM团队会随着时间的推移而积累经验，但是与此同时，AM团队需要大量接触不太稳定的代码库，需要避免在没有适当的测试安全网的情况下引入回归，需要设计一种在不造成中断的情况下部署新的主要版本的方法。
AM团队通常比项目团队面临更艰巨的工作。为什么，如果AM团队的任务更加艰巨，那么所有很酷的人都在项目团队中，而现在又在其他地方，可能还有其他很棒的事情吗？
可能的答案：项目团队需要奠定正确的基础
聘请最有经验的人来启动项目的原因之一是，一开始，我们需要为将来的事情打下基础。我们需要定义架构，并对解决方案的设计做出一些基本决定，因此需要正确的经验。
但是，与此同时，在项目开始时，通常我们对所要解决的问题的了解有限。在任何重要的项目开始时，都有许多已知的未知数，也有许多未知的未知数。因此，必须始终将系统的体系结构视为可演化的，并且我们需要意识到，许多关键的决定不能在一开始就做出，而必须在未知因素开始暴露时做出。
在项目开始时就将架构决策视为一劳永逸的决策通常是一种幻想。在软件系统生命周期中的任何时候都可能出现关键的体系结构问题。在项目开始时做出的关键体系结构决策可能必须稍后进行大修，这可能是因为有新的需求，可能是因为出现了新技术，例如Cloud，也许是因为它们只是解决问题的错误方法。
所以是的，的确如此，项目团队必须做出架构决策，但AM团队也必须做出架构决策，并且必须在更加复杂的环境中做出决策。
您根本无法做到相反
在中期，虽然强大的项目团队的经典模式随后是一支更初级的AM团队并不是最有效的方法，但相反的方法也无法解决问题。我们无法想象有一个初级团队来启动一个项目，然后将其过渡到一个更高级别的团队进行维护，这显然不是一种选择。
潜意识的情况
也许更多的高级人员使用新的炫酷技术来启动新项目的一个深刻原因是，他们喜欢用新的炫酷技术来开始新事物，然后随着时间的流逝，当工作似乎变得越来越重复时，他们只是想应对其他挑战。
这有利于他们的技术好奇心，也有利于他们的履历表。但这可能对他们正在构建的软件系统的长期健康不利。
从项目团队到产品团队
2006年，亚马逊的Werner Vogels首席技术官创造了著名的“您制造，运行”的座右铭，传达了这样一个想法，即负责产品的团队需要从产品开始到运行阶段都对其进行服务。运营方面以及演进方面。简而言之，同一团队负责产品成功所需的所有阶段：设计，构建，运行，发展。
如今，越来越多的人开始认为需要从以项目为导向的组织工作方式转变为以产品为导向的模型。这是一个复杂的转变，涉及组织的许多方面，但是对于我们在这里进行辩论的主题，这无疑意味着放弃将项目和AM团队分开的想法，而创建更稳定的产品团队。
产品团队需要由经验丰富的人，很酷的人以及需要成长的初级人才的合适组合。大三学生与帅哥一起工作，逐渐变得很酷。这样就可以在不影响团队质量的情况下控制轮换。
在我们生活的时代，数字时代，当我们听到诸如“当项目结束时我们将过渡到AM”之类的消息时，我们必须变得可疑。
这并不是说AM不再有空间。仍然有一些旧的旧系统，通常为后勤部门服务，它们的工作非常糟糕，非常稳定，只需要一些维护即可。
但是，在开发新的差异化数字功能时，我们需要远离AM模型，而要采用面向产品的模型，该模型的设计团队不仅要负责构建产品的第一个版本，还要负责运行它。 从中进行学习，并随着时间的推移进行改进，以确保它与最终用户仍然相关。更多关于项目管理的信息，请继续关注。
