Опасная игра. Стоит ли полагаться на команду из джуниоров

https://hackernoon.com/the-risky-game-of-relying-on-a-junior-developers-team-98a38427af9b
  • Перевод

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



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

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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


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

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

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

Хрупкий код


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



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


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

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

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


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

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

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

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

Подробнее: https://alconost.com
Alconost 89,07
Локализуем на 68 языков, делаем видеоролики для IT
Поделиться публикацией
Комментарии 14
  • +3
    У него есть основные обязанности и в нагрузку — педагогические.

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


    Железное правило: когда часть сокомандников занята молодняком, другие должны перераспределить между собой их нагрузку.

    Нагрузка наставника как разработчика должна сразу планироваться минимальной по объему с постепенным увеличением (но никогда не доходит до 100%), иначе менеджмент де-факто будет впихивать невпихуемое с предсказуемым результатом.


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

    Менеджер не может управлять качеством кода в принципе. Это в любом случае задача разработки.


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

    Это очень, очень, очень плохой наставник. И еще худший менеджер над ним. Бесполезно требовать от молодняка высокой продуктивности на раннем этапе. В начальный период суммарная продуктивность команды будет низкой из-за высокого объема "менторских" коммуникаций, это надо учитывать при планировании.

    • 0
      А ещё наставник рискует «отстать от жизни», пока учит молодняк и работает с перегрузкой, но при этом, очевидно, получает меньше больших и интересных задач, да и на самообразование времени не остается, может и деградировать несколько.
      • +2
        Вы тут не правы. Во-первых уча новичков, наставник сам освежает свои знания и узнаёт новое. Иногда новички могут подкинуть очень интересные решения и более современные подходы, которм он научился где-то в интернете. Ключевой проблемой, описанной в вашем комментарии являются не новички, а работа с перегрузкой. Т.е. достаточно чуть уменьшить объём заданий для наставника и выделить фиксированное количество часов на наставничество и ревью кода и все описанные вами проблемы решаются.
        • 0

          Лучше не фиксированное время, а прямой приоритет помощи в развитии ученикам над собственными задачами.

        • 0
          После такого менторства — натуральный путь в техлиды.
          • 0

            С точностью до наоборот: через наставника проходят все задачи его подопечных и среди них обязательно должны быть сложные и интересные.

            • 0
              Сложные задачи у новичков? Не верится что-то. Разве что для самих новичков. Интересные еще могут попадаться.
              • 0

                Без сложных задач не будет ни роста, ни настоящей проверки результатов обучения.
                Помните исходное значение слова "шедевр"?

          • +1
            Забыли самое главное.
            Разработчики учатся и хотят ЗП больше, но им не дают, их же воспитали и они уходят спустя год.
            Очень популярна такая текучка где набирают джунов и учат, вкладывают уйму сил и потом забывают адекватно поднять ЗП
            • 0
              Есть разные компании и разные модели. Доводилось сталкиваться даже с такой, что набирали студентов из вузов и обещали заплатить после испытательного срока. Ну и разумеется никто этот срок не проходил. Контора несколько лет так работала.
            • +2
              Пара советов тем, кто думает брать джуниоров в проект:
              Совет 1. Берите. Все мы были когда-то джуниорами, а стали профи. Есть большая вероятность того, что вам попадётся именно такой, и через год его не отличишь от профи. Просто подойдите ответственнее к вопросу выбора и выберите того, кто действительно хочет учиться (а это основной критерий для джуна)

              Совет 2. Цените наставников. Введите премии за наставничество. Даже дополнительные 100 баксов сеньёру не помешают. Также выделите по 1 часу в день на наставничество. Т.е. планируйте спринт наставнику не на 40/80 часов, а на 35/70.

              Совет 3. Присмотритесь к джуниорам в возрасте. Видел много случаев, когда в компанию приходят начинающие разработчики из тех, кому за 30. Почему-то компании их часто отметают. Присмотритесь к ним. Возможно его опыт и желание учиться будет намного более полезен, чем у вчерашних студетнов.

              Совет 4. Как только джуниор вырос — не забудьте поднять ему зарплату. Иначе он уйдёт от вас, и вам прийдётся начинать всё сначала. Очень частая ошибка. У меня была такая-же история на первом месте работы.
              • 0
                Для этого есть студенты и выпускники профильных специальностей, они хоть на виду. Брать со стороны, да ещё в возрасте — кто на это пойдёт?
                • 0
                  Смотря какой профиль у конторы. Если не только development, а ещё какой-никакой research, то очень даже возьмёт.

                  Люди в возрасте 40+ приходят из науки, обладая начальными (для промышленности) навыками программирования. Опыта у них с головой, а кодить учатся быстро.
              • 0
                Зарплата опытного разработчика может вдвое

                после перестал читать

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое