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

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

Первое о чем, я хочу рассказать - это о том, как мы выстроили процесс найма новых сотрудников.

Найм новых сотрудников

Перед тем как говорить о нашем процессе найма, упомяну ограничения с которыми мы сталкивались:

1. Вилка зарплат была на уровне Junior-Junior+;

2. Очный формат работы;

3. Самая главная проблема: специалисты высокого уровня не откликались на нашу вакансию (как показал дальнейший опыт, очный формат сильно отталкивает специалистов высокого уровня).

Процесс найма мы разделили на четыре три части: просмотр резюме, звонок HR, тестовое задание и очное собеседование.

Просмотр резюме

На данном этапе мы проверяли основные моменты, которые нас интересуют:

1. Местонахождение - из-за того, что у нас предполагался очный формат работы;

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

Звонок HR

Цели звонка были:

1. Задать заранее подготовленные базовые вопросы. Это позволяло отсеять кандидатов, которые не знают основные вещи, которые для нас важны в работе.

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

3. Уточнить, устраивают ли его наши ограничения: работа в офисе и т. п.

После собеседования мы отправляли тестовое или звали на очное собеседование

Тестовое задание

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

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

2. К сожалению, идеальное тестовое задание не может гарантировать, что человек действительно будет сильным сотрудником.

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

Очное собеседование

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

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

В какой-то момент мы перешли к формату решения задач. Это позволило нам лучше понять, как мыслит кандидат и готов ли он тщательно разобраться в вопросе или сразу же говорит «не знаю».

Вывод из нашего процесса найма

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

Организация процессов в команде

Scrum как возможность быстро учиться

Про Scrum написано много статей и ходит много разных мнений на тему того, нужен он или нет. В случае начинающей команды он позволяет достигать хороших результатов за счет:

1. Постоянной синхронизации с заказчиком, что позволяет быстро проверять гипотезы

2. Постоянного самообучения на основе ретроспективы;

3. Улучшения командного духа и сплоченности.

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

Постоянная работа с бэклогом

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

Могу выделить основные моменты, которые важно указывать:

1. Описание задачи. Важно, чтобы описание понимала вся команда. Лучше всего добавить User Story, чтобы разработчик мог лучше погрузиться в проблематику задачи;

2. Критерии готовности (DoD).

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

Приоритеты задач

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

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

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

Очный формат работы

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

В нашем случае компания поставила ограничение: только очный формат.

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

Работая в очном формате я вынес для себя несколько важных вещей:

1. Важно, чтобы команда работала рядом. Когда я только пришёл в компанию, команда была «распределенной» по всему офису, и это затрудняло общение между коллегами. Но вскоре нам удалось убедить руководство в том, что нужно собрать команду в одном месте. Это решение улучшило показатели скорости работы в два раза — просто за счёт сокращения времени на коммуникацию и повышения её качества.

2. Отдельно хочу подчеркнуть, что дизайнерам и аналитикам важно находиться рядом с командой разработки, а лучше всего – рядом с лидером команды. Такой подход позволяет им быть в контексте работы команды и быть в курсе всех принимаемых решений.

Важно проводить ретроспективу

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

Здесь самое главное понять чего вы хотите. Например:

• Если вы хотите сплотить команду, то классно включать на экране видео с камином, выключать свет и по кругу обсуждать то, как прошел спринт, чтобы команда делилась как хорошими, так и плохими моментами;

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

Важно, чтобы ретро было сделано вокруг команды, чтобы она училась сама решать свои проблемы и улучшала процессы.

Распад команды

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

Мне до сих пор грустно, что мы не смогли ее сохранить, но этому мешало несколько факторов:

1. Усталость от проекта. Многие устали разрабатывать один проект много лет и не видеть полноценного выхлопа от своей работы;

2. Внедрение резких изменений во все процессы со стороны руководства. Со стороны я понимаю эту ошибку так: важно прорабатывать все изменения вместе с командой, чтобы она понимала зачем они нужны, как повлияют на их процессы и что принесут ей в будущем;

3. Отсутствие развития новых навыков, рутинность процессов, так как в проект не внедрялись новые технологии и практики.

4. Непроработанный подход к повышению заработной платы и роста внутри компании. Для прозрачности можно использовать практику Performance Review.

Вывод

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

Стоит ли собирать команду из начинающих разработчиков? Это решение остаётся за вами. Я понял для себя, что такая команда отлично подходит для разработки MVP продуктов. Это экономичный вариант, который позволяет вырастить внутри компании хороших специалистов. В будущем они смогут продолжить работу над этим проектом или перейти к более сложным задачам.

Преимущества:

• Дешево: начинающие специалисты стоят значительно дешевле опытных;

• Простота адаптации: новички быстрее погружаются в специфику компании;

• Легче сплотить, так как вся команда растет вместе.

Недостатки:

• Отсутствие идеальной архитектуры: у начинающих специалистов не так много опыта в разработке и из-за этого им сложно с первого раза выстроить качественную архитектуру. Данный минус можно устранить за счет выделения опытного наставника, к которому можно обратиться за советом;

• Необходимость помощи в организации процессов: кроме помощи в техническом направлении, нужно не забывать помогать и в менеджерском направлении, чтобы команда лучше понимала куда она идет и зачем.

P.S. Удивительно как можно сплотить команду

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

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