5 причин, почему только разработчики-аутстафферы не помогут успеть к дедлайну

И как нужно подготовиться, чтобы усиление команды аутстафф-разработчиками не вызвало торможение команды в целом.

Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.

Усиление команды аутстафф-специалистами — практика, к которой часто прибегают, когда горят дедлайны. Но эффект от нее часто компенсируется проблемой вида «9 женщин не родят ребенка за 1 месяц».

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

При поиске разработчика в штат на постоянку на принятие решения обычно есть много времени. В таких ситуациях стоит задача найти «того самого» разработчика, который поможет команде получить прирост производительности и развиться в долгосрочной перспективе.

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

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

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

Чтобы новые разработчики могли доставлять свои изменения до продакшена без риска все сломать, этот процесс должен быть максимально автоматизирован и запускаться по кнопке в веб-интерфейсе.

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

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

При увеличении команды разработки под релиз тестирование фичей на одном тестовом сервере становится более затруднительным. Распределять фичи между сотрудниками так, чтобы они не пересекались, становится сложнее.

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

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

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

Процесс погружения разработчика в контекст проекта обычно занимает время. И это время зависит от того, насколько хорошо организован процесс онбординга.

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

Еще стоит поработать над тем, чтобы развертывание проекта на компьютере нового сотрудника занимало меньше времени. Если у вас настроены фича-серверы из предыдущего пункта и их развертывание происходит автоматически, то развертывание сервиса на компьютере нового разработчика займет не больше часа.

Подробно о том, как не потерять производительность при росте команды, я уже рассказывал.

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

Чтобы фича-серверы работали, достаточно настроить их один раз, но этот процесс может занять от 4 до 6 человеко-месяцев, если у ваших инженеров нет соответствующего опыта.