Как это влияет на коллектив, менторство, качество кода, а также вопрос денег

Очевидно, что любая компания предпочитает брать в команду опытных разработчиков. Отдача от них лучше. Они предлагают более надежные и творческие решения, которые удобно масштабировать. Заправский senior-разработчик понимает проблемы и, вероятно, умеет не попадать впросак и минимизировать количество багов. Кроме того, код у таких разработчиков работает быстрее, чем у начинающих, и они умеют трудиться самостоятельно.

С другой стороны, деньги правят миром, а джуниоры стоят значительно дешевле. Зарплата опытного разработчика может вдвое превышать зарплату начинающего. Кроме того, начинающих разработчиков много, и иногда так и хочется нанять одного из них.

Мы в Alconost перевели статью о том, насколько рискованно полагаться на команду молодых разработчиков и как такая ситуация влияет на опытных разработчиков, менторов и качество продукта.

Проблеееемы, как минимум некоторые

Молодому разработчику нужен наставник. Не каждый обстрелянный разработчик справится с такой задачей без руководства и четкого понимания. Многие менеджеры совершают одну и ту же ошибку: набирают в одну команду много молодых разработчиков. Они думают, что если отдать новичков в подчинение сильному наставнику — все проблемы решены. Но наставник — это не волшебник. Быть наставником — тяжкий труд.  

Не всякий разработчик годится в менторы. Как правило, среднестатистический разработчик не должен брать на себя такую миссию, не потренировавшись в менторстве. Способности у всех джуниор-разработчиков разные, и наставник не может учить их всех одновременно, тем более, если джуниоры подключались к команде в разное время. Создание команды, чрезмерно завязанной на множестве начинающих разработчиков, может привести к деструктивным последствиям, а менеджеры порой пропускают момент истины и не успевают справиться с ситуацией.

На проект требуются дополнительные разработчики ?—? что делать? Перетасуем

Обычно на зарождающемся проекте заняты считанные разработчики. Проходит время, и —  бууум! —  проект перешел к стабильному развитию. В него вкладывается все больше времени и денег, на вас наседают заказчики, чувствуется прессинг. Тогда рекрутеры-технари принимаются круглосуточно искать новых разработчиков. Нельзя же собрать команду из одних новичков —  поэтому приходится прибегать к перетасовке. Команды перекомпоновываются.

Итак, теперь работы много, требуется руководить множеством разработчиков. Иной менеджер решает: «Брошу их в дело, пусть выплывают». Такая ошибка может оказаться фатальной, и вы вскоре об этом узнаете. Что тогда? Снова кого-нибудь нанимаем и снова перетасуем. Людям не нравятся изменения, тем более — частые. Такие меры могут по-настоящему тряхнуть членов команды. Коллеги должны срабатываться, чувствовать друг друга и знать сильные стороны соратников.

Выгорание наставника

Любой менеджер, берущий человека в команду, принимает решение. Если новобранец опытный, наставник ему зачастую не требуется. Даже при наличии ментора опытный разработчик обычно независим и умеет учиться сам. Когда разработчик неопытен, наставнику придется туже. У него есть основные обязанности и в нагрузку — педагогические. Каждый час ему могут поступать новые вопросы. Ментор должен не только помогать разработчику решать возникающие проблемы, но и учить, как учиться. В противном случае наставник не успеет выполнять свои основные обязанности.

Когда у наставника несколько подопечных, они могут засыпать его просьбами о помощи и совершенно не оставить времени на основную работу. Хороший ментор должен быть терпелив и уметь слушать. Длительное наставничество порой бывает изнурительным, и иногда чувствуется выгорание.

Бремя опытных разработчиков

Не все опытные разработчики — менторы, и это не упрощает ситуацию. Естественно, наставник получает меньшую нагрузку, нежели остальные. Поэтому типичный менеджер осознает, что, если не нагружать опытного разработчика менторством, то он будет трудиться продуктивнее.  

Железное правило: когда часть сокомандников занята молодняком, другие должны перераспределить между собой их нагрузку. Они получают больше ключевых задач и тем самым позволяют наставникам — учить, а новичкам — учиться. Они отвечают за прогресс в разработке продукта. Со временем такая роль может стать очень обременительной. Менеджер, руководящий процессом, должен не лишать таких разработчиков контакта с другими членами команды.

Как это сказывается на качестве кода

Менеджер не может держать планку по качеству кода, если на одного опытного разработчика приходится четверо начинающих. Он не в силах, а если вы — в силах, то дорогого стоите. Компания жива, пока подпитывается деньгами, и когда деньги иссякают — с ней все кончено. Все — начинающие, обстрелянные, опытные разработчики и даже уборщики — ходят на работу, потому что хотят кормить семью.

Итак, насколько меняется качество кода? Сильно. Шкала в данном случае варьируется, все зависит от того, насколько джуниоров заставляют быть продуктивными, и от периода обучения. Как правило, наставник скажет: «Будет рефакторинг — поправим».

Обычно это чепуха. По тем самым причинам никакого рефакторинга обычно не наступает, и качество кода в данном приложении становится «стандартом» для всего проекта. Где удобнее всего добыть образец кода? В нашем же приложении. Все стандарты оформления кода там соблюдены. Префиксы тоже как надо, так почему бы нет? Ctrl+C & Ctrl+V, прощайте, стандарты программирования, се ля ви.

Хрупкий код

Качество кода пострадало. А что насчет хрупкости? Когда новичок пишет блок кода, он еще не знает, где этот код может сломаться. Код называется хрупким, если в нем легко возникают баги. Пример: функция не проверяет значения аргументов, их тип или диапазон валидации. Это простой пример. Но порой баг выловить сложнее, например, если в коде JS инструкция проверяет на undefined, но не на null, либо если условие if получилось сложным, и программист не учел в нем порядок предшествования операций. Редактор, просматривающий код, должен быть в курсе таких изъянов и настороженно их выискивать. Тестирование кода позволяет радикально снизить риски.

Наш месседж — ДОЗИРУЙТЕ, причем аккуратно.

Новички, опытные разработчики, наставники, менеджеры, баги, клиенты и деньги. Каждый из них важен и играет свою роль. Как бы там ни было, все когда-то начинают с самых первых шагов. Ни один senior-разработчик не родился сразу с достаточными знаниями и опытом.

Нельзя кусать руку, которая тебя кормит. Нужно понимать, что перетряска и перетасовка команды  — это вмешательство, которое может дорого обойтись. Здесь важно знать меру и строго ее соблюдать. Если без перетасовки не обойтись — добейтесь, чтобы она происходила не чаще, чем с интервалом от девяти месяцев до года. Убедитесь, что наставники не выгорают, а остальные разработчики не трудятся на износ.

Набор молодых разработчиков — это тактика со множеством преимуществ. Если как следует наладить наставничество и подобрать подходящий учебный план, такая работа может оказаться очень плодотворной. Начинающего разработчика легче сформировать по своему вкусу, чем опытного. Новички знают, что не пользуются бешеным спросом. Поэтому у них выше стремление и мотивация тратить собственное время на прокачку навыков и выстраивание карьеры.   


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com