Почему разработчики новых продуктов неохотно берут в свои команды начинающих, когда отсутствие опыта может стать преимуществом, а также как молодому и не очень опытному специалисту повысить свои шансы попасть в проект, рассказывает Александр Кочетов, технический руководитель Membrana Kids — сервиса безопасного цифрового пространства для детей, который был разработан в Центре инноваций МТС Future Crew.
В представлении обывателей разработчики инновационных продуктов — это прорывная и быстро развивающаяся команда из талантливых и энергичных молодых специалистов. В суровой реальности такие команды состоят в основном из опытных ИТ-специалистов, а начинающих там не очень любят. Почему?
Почему к новичкам относятся предвзято
Команды, делающие инновационный продукт, почти всегда невелики, и в ведении каждого сотрудника находится своя маленькая разработка, за которую он несёт ответственность, причём полную.
Возьмём для примера создание нашего продукта Membrana Kids. Это цифровой сервис для родителей, который позволяет управлять телефонным трафиком ребёнка, — фильтровать входящие звонки, контролировать доступ к интернет-ресурсам и многое другое.
Membrana Kids — сложный проект, и запуск каждой его фичи — многоэтапный процесс. Принимать ключевые решения приходится сразу, с первого этапа — с разработки идеи и её исследования. Здесь самое главное — попасть в целевую аудиторию и создать понятный и полезный для неё функционал, иначе проект выйдет нежизнеспособным. В попытках проработать ту или иную фичу мы можем проводить множество исследований и неоднократно менять концепцию.
Следующий этап — бизнес-анализ. Мы собираем данные по фиче, необходимые для дальнейшей работы: описания юзкейсов и базовых интеграций, которые будут внедрены в продукт. Затем выстраиваем пользовательский путь и прописываем задачи для дизайнеров. Ошибки на этом этапе могут привести к тому, что продукт окажется неудобным или вовсе невостребованным и его не захотят покупать.
На этапе бизнес-анализа прорабатываются конкретные кейсы использования функционала — как прямые, так и альтернативные пути. Далее в ходе системного анализа выстраивают архитектуру продукта и определяют его техническое решение — вплоть до структуры базы данных и примерных пользовательских запросов.
Ошибки могут возникать на любом из этих этапов. Собственно, так много подготовительных стадий у проекта для того, чтобы выявить как можно больше проблем до начала проектирования и разработки. Ведь чем ближе задача к конкретному написанию кода, тем сложнее будет исправить проблемы функционала.
Когда системный анализ завершён, мы собираем всю команду на согласование. Оно необходимо, чтобы все ознакомились с фичей до начала разработки. На этом этапе есть шанс заметить дополнительные проблемы с бизнес-логикой и сэкономить время. Технические изъяны или недостатки проектирования можно исправить на месте, но если возникают проблемы с бизнес-логикой, то почти наверняка задача вернётся на этап бизнес-анализа. А самой большой ошибкой здесь станет попытка поправить бизнес-логику самим разработчикам, без вмешательства бизнес-аналитиков или продуктовых менеджеров.
Если вы запускаете новый продукт, а команда разработчиков небольшая и от человека требуется автономность и самостоятельность, брать в неё молодого неопытного специалиста — большой риск для бизнеса, и чем меньше у человека опыта, тем этот риск выше.
В итоге мы отправляем фичу в разработку, затем интегрируем бэкенд с мобильными платформами, фронтендом и запускаем серию тестирований на стендах. И вот наступает решающий этап — экспертиза качества на уровне МТС. Только получив положительное заключение по её результатам, мы сможем выпускать продукт.
На каждом этапе принимаются жизненно важные решения. Поэтому если в команде открылась новая должность или направление, где у команды мало экспертизы, лучше найти специалиста, который уже понимает, чем живёт и дышит разработка. И даже в этом случае нужно дважды оценить, сможет ли человек осилить такую большую ответственность. Да и работать с опытными людьми гораздо проще, потому что им не надо рассказывать ни про стандарты, ни про процессы.
Когда минус становится плюсом
Значит ли это, что новичкам путь в разработку инновационных продуктов закрыт? Нет. Свежая кровь приветствуется, но только если:
- компания расширяет свой состав на уже существующих направлениях;
- в команде есть люди, которые готовы стать наставниками для молодых специалистов и помочь им плавно войти в рабочий процесс;
- открывается отдельное R&Dнаправление.
R&D (research and development) — это задачи на исследование. Они появляются, когда требуется создать решение, подобного которому на рынке ещё нет и никто не знает, как за него взяться. Как правило, такие задачи не очень срочные, там очень большая свобода действий и простор для творчества.
Естественно, чем больше людей в команде, тем больше мы можем позволить себе брать молодых специалистов, — для них уже будут наставники, которые позволят им плавно «вкатиться» в работу. Ещё у нас в Центре инноваций Future Crew есть гильдии, объединяющие специалистов одного направления из разных команд, например тестировщиков или аналитиков. У гильдий есть руководители, с которыми ребята могут посоветоваться.
Отсутствие опыта тоже может стать преимуществом: начинающие осваивают специальность с огнём и особым рвением, у них нет зашоренности, они чаще, чем опытные сотрудники, предлагают креативные решения.
Как-то раз нам очень помог свежий взгляд молодых ребят — мы нашли дополнительные точки для создания фичей. Как всё было: мы проводили хакатон, на котором проверяли гипотезы. В нём участвовала команда совсем молодых ребят, студентов первых-вторых курсов. Их решение в итоге выиграло. Мы общались с руководителем команды, который это решение вёл, — таким же студентом, как и остальные. У них было очень мало опыта в сфере даже не телекома, а в принципе в профессии. Но они выдали довольно креативное и, главное, рабочее решение.
Переходим к конкретике: как вчерашнему выпускнику прорваться в разработку нового продукта.
Как новичку «зайти» в инновационные «айти»: четыре способа повысить шансы
1. Использовать любые возможности получить реальный и подходящий опыт.
Решающий фактор, на который обращают внимание работодатели, — не возраст и не образование, а навыки, опыт работы в рамках интересующего их направления. Поэтому, кстати, всегда стоит интересоваться не только своей профессиональной сферой, но и смотреть по сторонам, на смежные. Так, дизайнер может изучить бизнес-анализ, а системный аналитик — покопаться в коде.
Например, сразу после окончания универа я искал работу системного аналитика, но всем нужны были специалисты с опытом именно по этому профилю. Потенциальные работодатели смотрели больше не на мои знания, а на то, были ли у меня реальные проекты как у аналитика — а у меня были только опыт работы в техподдержке и несколько личных проектов как у разработчика. Устроиться именно системным аналитиком мне удалось только года через два.
Кстати, молодость — это не всегда отсутствие опыта. Двадцатилетний специалист может оказаться намного сильнее коллег на пять лет старше: может случиться, что коллеги за эти пять лет вообще не развивались — никогда не выходили за рамки своих задач. А молодой, наоборот, интересовался всем чем можно и всё пробовал.
Ещё сейчас молодые люди очень рано пробуют создавать свои стартапы. Бывает, что у них нет официального опыта, зато есть практический — они знают, как запускать продукт, уже работали над реальными проектами.
У молодых нестандартные подходы к решению задач: человек с опытом знает, что какие-то вещи сделать просто нельзя, не получится — но иногда упускает детали, которые могли бы помочь решить задачу. А неопытный, но активный, этого ещё не знает, зато такие детали видит и благодаря этому может найти нетривиальное решение.
2. Участвовать в хакатонах.
Это отличный инструмент поиска новых кадров для работодателя, а для молодых — возможность найти работу: на таких мероприятиях можно и на других посмотреть, и себя показать. Пока участники работают над заданием, мы присматриваемся к ним и заодно тестируем фичи своих продуктов. Хакатоны часто раскрывают потенциал у ребят без опыта, но с классными идеями и умением их реализовать.
3. Не игнорировать стажировки.
Обычно у нас стажируются студенты, но как-то раз на позицию стажёра — инженера DevOps пришёл... десятиклассник. Иногда он даже свои фото из школы присылал. И он не просто пришёл, а хорошо справился с задачами.
Бесплатные стажировки — это тоже хорошо. Это набор опыта, ничего плохого тут нет. Но тут очень важно пресекать свои порывы слишком сильно удариться в работу: высок риск выгореть. Нужно соблюдать баланс работы и отдыха.
Высокие зарплаты в ИТ действительно есть, но рассчитывать на них новичку не стоит. Некоторые соискатели не понимают, что в начале пути приобретение опыта надо ставить выше дохода. Они слышали только о больших деньгах в «айти», а о высокой нагрузке — нет.
Что делать, если вас уже взяли в команду
Перестать бояться нового. Когда человек приходит на новую должность или меняет сферу деятельности, ему кажется, что он мало знает, что ему не хватает опыта.
В разработке инновационных продуктов очень высокий темп работы с большим потоком задач. Но и опыт нарабатывается быстро. А значит, превратиться, допустим, из мидла в сеньора можно в несколько быстрее, чем в «обычной» разработке. Это неудивительно: работая над разнообразными задачами в разных сферах, можно существенно ускорить профессиональный рост. Поэтому для новичков очень круто будет устроиться в какую-то аутсорс-компанию, где есть разнообразные проекты и где можно быстро поднять насмотренность. По крайней мере, у нас в команде есть и 25-летние сеньоры.
Опыт и знания приходят со временем. Самое главное — не бояться и пробовать. Когда ты переходишь на новую роль, приходишь в новую для тебя сферу, быстро осознаёшь, сколько всего ещё предстоит освоить. Но всё придёт. И если тебя взяли в проект, значит, ты попал туда не зря.
А вы пытались когда-нибудь попасть в разработку нового продукта, не имея (или почти не имея) опыта? Получилось или вас развернули ещё на входе?