The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Вот что говорит Википедия об этом: “Высокая текучесть может быть вредна для продуктивности компании, если опытные сотрудники часто уходят, и количество новичков среди работников высокое.” Я согласен. Однако, я считаю, что низкая текучесть также может быть очень вредной.
Я нашел эту хорошую статью, где Джон Салливан объясняет, почему низкая текучесть может быть тревожным симптомом. Она действительно хороша, но довольно общая. Она не относится специально к командам разработчиков программного обеспечения. Мой опыт в основном связан с программистами и их текучестью. Я узнал, что низкая текучесть отрицательно влияет на поддержку кода и поощряет “героическую разработку” и “сильную собственность на код” (обе эти практики являются плохими).
“Текучесть” - это в основном замена сотрудника новым сотрудником по любой причине, включая увольнение, пенсию, уход по собственному желанию или любую другую. Проще говоря, чем больше людей в вашей команде уходят каждый год, тем выше ваша текучесть. Если в вашей команде 20 программистов, и каждый год пять из них уходят, ваша текучесть составляет 25 процентов.
Я не могу точно сказать, какое число вам следует стремиться достичь, но я категорически считаю, что если вы считаете программистов ценными долгосрочными активами и пытаетесь удержать их любой ценой, то вы делаете это неправильно.
Мой посыл заключается в том, что здоровая команда разработчиков программного обеспечения должна регулярно заменять программистов. Я бы сказал, что иметь одного человека в команде дольше года - это просить неприятностей.
Под заменой я не обязательно подразумеваю увольнение. Вовсе нет. Я имею в виду перемещение их вдали от кодовой базы. Очевидно, если у вас есть только одна кодовая база, замена будет означать увольнение.
Когда программисты долго остаются вместе, работая над одной кодовой базой, они неизбежно становятся экспертами в своей области. Прежде всего, это приводит к сильной собственности на код. Естественным образом каждый из них становится специалистом в своей части кода, в основном потому, что работать с чем-то, с чем вы знакомы, проще, чем переходить с модуля на модуль. Сильная собственность на код, как нетрудно догадаться, является плохой практикой. Коллективная собственность на код является гораздо лучшей альтернативой, как объясняет Мартин Фаулер.
Затем, наличие сильных экспертов в команде неизбежно приводит к героической разработке, где тушение пожаров очень ценится. Эксперт не хочет потерять свою позицию и всегда пытается показать, насколько он или она ценен для команды. Лучший способ сделать это - решить проблему, которую никто другой не может решить. Вот как обеспечивается “гарантия рабочего места”. И вот как начинает разрушаться команда. Эта запись в блоге Фредрика Рубенсона правильно подтверждает эту проблему.
Таким образом, чтобы достичь более высокой поддерживаемости и надежности исходного кода, мы должны перемещать программистов, не позволяя им становиться экспертами в одной области.
Я понимаю, что эта идея звучит противоречиво, но подумайте об этом. Сохраняя людей вместе, работающих над одной проблемой в течение длительного времени, мы копим много знаний в их головах, а не в нашем исходном коде. Эти люди становятся активом. Они становятся умнее, они очень хорошо знают решение и быстро решают все проблемы. Но кодовая база разрушается.
Когда наступает время заменить кого-то (по любой причине), ущерб будет значительным. Мы можем потерять значительные знания, и оставшаяся кодовая база будет неподдерживаемой. В большинстве случаев нам придется переписывать ее. Вот почему в большинстве команд разработчиков программного обеспечения руководство боится программистов. Они боятся потерять ключевых разработчиков программного обеспечения, потому что последствия могут быть фатальными.
В конце концов, программисты контролируют руководство, а не наоборот.
Это не школа!—В этом раннем сообщении объясняется, как эту проблему можно решить без увольнений или перемещений программистов, но немногие команды, особенно находящиеся в одном месте, могут себе позволить это. Если ваша команда не может, просто старайтесь поддерживать достаточно высокую текучесть, чтобы предотвратить появление героев (также известных как эксперты в своей области).
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:35
