带团队做客户项目有意义吗_独立的项目和维护团队。是否有意义？-CSDN博客

带团队做客户项目有意义吗

Suppose you have to add a new major feature to an app. Which of the 2 scenarios is easier?

假设您必须向应用程序添加新的主要功能。这两种情况中的哪一种比较容易？

add the feature to a relatively small app, still under construction, not yet in production
将功能添加到仍在建设中但尚未投入生产的相对较小的应用程序中
add the feature to an app that has grown over time, whose overall quality is questionable, which is already running in production serving several clients
将功能添加到随着时间推移而增长的应用程序中，该应用程序的整体质量值得怀疑，该应用程序已经在生产中运行，可以为多个客户提供服务

Well, there is no doubt. The second is a much more challenging task.

好吧，毫无疑问。第二是一项更具挑战性的任务。

But then why do we usually find a more senior experienced team in the first and more junior teams buried in the second?

但是，为什么我们通常在第一个团队中找到一支经验更丰富的团队，而在第二个团队中埋葬更多的初级团队呢？

多年前 (Many years ago)

When I entered the team that was developing the new Payment system for a major European Bank, the first position I was given was in the Application Maintenance (AM) team responsible for the legacy parts. The reasons were simple and shared: I was new to the place, new projects were running fast using leading edge technologies for which there was not much experience. AM would have been the right place for me to grow without too much pressure. As soon as I had gathered enough knowledge and experience I would have moved to the Project team, the team developing new features with new technologies, the team of the cool people. After one year or so this actually happened, but I will never forget that supposedly not-so-stressful period of AM.

当我进入为一家大型欧洲银行开发新的支付系统的团队时，我担任的第一职位是负责遗留部分的应用程序维护(AM)团队。原因很简单，也很共同：我是新来的，使用经验很少的前沿技术，新项目正在快速运行。 AM将是我成长的正确场所，而没有太多压力。一旦我积累了足够的知识和经验，我就会转到Project团队，使用新技术开发新功能的团队，很酷的团队。大约一年后，这实际上发生了，但是我永远不会忘记那个所谓的不太紧张的AM。

项目团队和AM团队 (The Project team and the AM team)

All this dates back to the last millennium, but, since then, I have seen the same pattern repeated endless times, often in much more extreme forms. You have a new initiative, you start with the Project team. The Project team develops the architecture, the Project Team develops the features, the Project team accumulates delays with respect to a very optimistic initial plan, the Project team starts working extra hours, the Project team starts cutting corners. Quality is often sacrificed to the altar of the Plan, tests are forgotten and patches are added on top of patches. Developers start adding comments “To be refactored as soon as we have some time”. Technical debt is already there and its destiny is just to grow.

所有这一切都可以追溯到上一个千年，但是从那以后，我看到了无休止的重复相同的模式，常常以更为极端的形式。您有一个新的计划，从项目团队开始。项目团队开发架构，项目团队开发功能，项目团队针对非常乐观的初始计划积累延迟，项目团队开始额外工作，项目团队开始偷工减料。质量经常被牺牲到计划的祭坛上，测试被遗忘，补丁被添加到补丁之上。开发人员开始添加评论“待我们有一段时间后将其重构”。技术债务已经存在，而且它的命运还在增长。

Eventually the thing is brought to production and then, immediately after the go live, the Project team starts the transition towards the AM team. After some overlapping period, the AM team is left sailing alone. The AM team is usually younger, less experienced and considered less strong than the Project team. The tough part is over, the project is live. Now it is AM time, it is easier, it has to cost less, we can afford a new junior team.

最终，这些东西投入生产，然后，在上线之后，项目团队立即开始向AM团队过渡。经过一段时间的重叠后，AM团队将独自航行。 AM团队通常比项目团队年轻，经验不足且实力不足。困难的部分结束了，该项目已经启动。现在是AM时间，它变得更容易，它的成本也更低，我们可以负担一个新的初级团队。

上线一年后 (One year after the go live)

It has been one year of intense work. Bugs have been fixed, little things have been changed, little things have been added. The system has been eventually made ready to sustain real production load and the codebase has grown. At this point the AM Team receives a request to add a new big feature.

这是一年的紧张工作。错误已得到修复，小事情已更改，小事情已添加。该系统最终已准备就绪，可以承受实际的生产负荷，并且代码库已经扩展。此时，AM团队收到了添加新的重要功能的请求。

And we are back to the initial question. Is it easier to add the new feature now or was it easier to add a new feature when we were in Project mode?

我们回到了最初的问题。现在添加新功能更容易吗？还是在“项目”模式下添加新功能更容易？

The answer is clear: the task for the AM team is much more difficult. It is true that the AM team is sitting on the experience developed over time, but at the same time the AM team needs to touch heavily a not-very-stable code base, needs to avoid introducing regressions without having a decent test safety net, needs to devise a way to deploy a new major version without creating disruption.

答案很明确：AM团队的任务要困难得多。的确，AM团队会随着时间的推移而积累经验，但是与此同时，AM团队需要大量接触不稳定的代码库，需要避免在没有适当的测试安全网的情况下引入回归，需要设计一种在不造成中断的情况下部署新的主要版本的方法。

Let’s say it. The AM team often faces a much tougher job than the Project team. So why, if the task of the AM team is tougher, most if not all of the senior people were in the Project team and now are somewhere else, probably doing something else cool?

说吧。 AM团队通常比项目团队面临更艰巨的工作。那么，为什么，如果AM团队的任务更加艰巨，那么大多数(如果不是全部)高级人员都在Project团队中，而现在又在其他地方，可能还会做其他很酷的事情？

可能的答案：项目团队需要奠定正确的基础 (A possible answer: the Project team needs to lay the right foundations)

One reason to have the most experienced people starting a Project is that, at the beginning, we need to lay the foundations for what has to come. We need to define the architecture and make some fundamental decisions about the design of the solution, so the right experience is required.

聘请最有经验的人来启动项目的原因之一是，一开始，我们需要为将来的事情打下基础。我们需要定义架构，并对解决方案的设计做出一些基本决定，因此需要正确的经验。

At the same time though, at the beginning of a Project, we have usually only a limited knowledge of the problem we are called to solve. At the start of any significant Project there are many known unknowns and also many unknown unknowns. For this reason, the Architecture of the system has always to be considered evolutionary, and we need to be aware that many crucial decisions can not be made at the beginning but have to be made when the unknowns start to reveal themselves.

但是，与此同时，在项目开始时，通常我们对所要解决的问题的了解有限。在任何重要项目的开始，都会有许多已知的未知数，也有许多未知的未知数。因此，必须始终将系统的体系结构视为可演化的，并且我们需要意识到，许多关键的决定不能在一开始就做出，而必须在未知因素开始显现时做出。

Considering architectural decisions as things to be decided once for all at the beginning of a Project is often an illusion. Critical architectural questions may pop up at any time in the life of the SW system. Critical architectural decisions made at the start of the Project may have to be overhauled later, maybe because of new requirements, maybe because of new technologies coming over, e.g. the Cloud, maybe because they were simply the wrong ones for the problem to solve.

将架构决策视为在项目开始时一劳永逸的事情通常是一种幻想。在软件系统生命周期中的任何时候都可能出现关键的体系结构问题。在项目开始时做出的关键体系结构决策可能必须稍后进行大修，这可能是因为有新的要求，可能是因为出现了新技术，例如Cloud，也许是因为它们只是解决问题的错误方法。

So yes, it is true, the Project team has to make architectural decisions, but also the AM team has to make architectural decisions, and it has to make them in a much more complex environment.

因此，是的，确实如此，项目团队必须做出架构决策，但是AM团队也必须做出架构决策，并且必须在更加复杂的环境中做出决策。

你根本做不到 (You simply can not do the reverse)

While the classical model of a strong Project team followed by a more junior AM team is not the most efficient in the medium term, the opposite is not an answer as well. We can not imagine to have a junior team starting a project and then transition it to a more senior team for maintenance, this is clearly not an option.

在中期，虽然强大的项目团队的经典模式随后是一支更初级的AM团队并不是最有效的方法，但相反的方法也不是答案。我们无法想象有一个初级团队来启动一个项目，然后将其过渡到一个更高级别的团队进行维护，这显然不是一种选择。

潜意识的情况 (A case for subconsciousness)

Maybe one profound reason why more senior people start new Projects with new cool technologies is that they like to start new things with new cool techs and then over time, when the work seem to become more repetitive, they simply want to move to some other challenges.

也许更多的高级人员使用新的炫酷技术来启动新项目的一个深刻原因是，他们喜欢用新的炫酷技术来开始新事物，然后随着时间的流逝，当工作似乎变得越来越重复时，他们只是想应对其他挑战。

This is good for their tech curiosity and this is good for their resume. But this is probably not good for the long term health of the SW system they are building.

这有利于他们的技术好奇心，也有利于他们的履历表。但这可能对他们正在构建的软件系统的长期健康不利。

从项目团队到产品团队 (From Project team to Product team)

In 2006 Werner Vogels CTO at Amazon coined the famous “you build it, you run it” motto to convey the idea that a team responsible for a Product needs to cater for it from its inception down to its run phase, where run covers both the Ops aspects as well as the evolution aspects. To put it simply, the same team is responsible for all phases required for a Product to be successful: design, build, run, evolve. This is the model adopted by the digital giants that have emerged in the last decade, from Amazon to Facebook to AirB&B. Their undisputed success is the prove that the model is the right one in the digital era.

2006年，亚马逊的Werner Vogels首席技术官创造了著名的“您构建，运行”的座右铭，传达了这样一个想法，即负责产品的团队需要从产品开始到运行阶段都对其进行服务，其中运行涵盖了运营方面以及演进方面。简而言之，同一团队负责产品成功所需的所有阶段：设计，构建，运行，发展。这是近十年来出现的数字巨头所采用的模型，从亚马逊到Facebook再到AirB＆B。他们无可争议的成功证明了该模型是数字时代的正确选择。

Nowadays a growing number of people start predicating the need to move from a Project oriented way of organising work to a more Product oriented model. This is a complex transformation which involves many aspects of an organisation, but for the theme we are debating here it definitely means to abandon the idea of separate Project and AM teams and create more stable Product teams. Product teams need to have the right mix of experienced people and more junior people who need to grow. Working together with seniors, juniors gradually become cool themselves. Controlled rotation is then possible without tampering the quality of the team.

如今，越来越多的人开始认为有必要从以项目为导向的组织工作方式转变为以产品为导向的模型。这是一个复杂的转变，涉及组织的许多方面，但是对于我们在这里进行辩论的主题，这绝对意味着要放弃将项目和AM团队分开的想法，而要创建更稳定的产品团队。产品团队需要由经验丰富的人员和需要成长的初级人员的正确组合。大三学生与年长者一起逐渐变得很酷。这样就可以在不影响团队质量的情况下控制轮换。

结论 (Conclusion)

In the era we are living, the Digital era, we have to be suspicious when we hear something like “and when the Project ends we will transition to AM”.

在我们生活的时代，数字时代，当我们听到类似“当项目结束时，我们将过渡到AM”之类的消息时，我们必须变得可疑。

This is not to say that there is no space for AM any more. There are still old legacy systems, usually serving the back office, which are egregiously doing their work, which are very stable, which just need some Maintenance.

这并不是说AM不再有空间了。仍然有一些旧的旧系统，通常为后台服务，它们的工作非常糟糕，非常稳定，只需要一些维护即可。

But when it comes to develop new differentiating digital capabilities we need to move away from the Project/AM model and embrace a Product oriented model, where teams are designed to be responsible for building not only the first version of the Product but also to run it, to learn from running it, to evolve it over time to make sure it remains relevant for the final users.

但是，在开发新的差异化数字功能时，我们需要远离Project / AM模型，而要采用面向产品的模型，该模型的设计团队不仅要负责构建产品的第一个版本，还要负责运行它。，从中进行学习，并随着时间的推移进行改进，以确保它与最终用户仍然相关。