Стажировка системных и бизнес-аналитиков в IT-академии Lad
О стажировке
На стажировке для системных и бизнес-аналитиков мы разрабатываем в командах полезные проекты для компаний и пользователей — от создания прототипа в дизайне и подготовки бэка до тестирования и релиза полноценного приложения.
Вместе с вами над проектом будут работать стажеры направлений: frontend-и backend-разработка, веб-дизайн, инженеры по тестированию, техническое писательство, project management.
Мы настроим вашу работу по методике Scrum — такой подход приблизит процессы к реальным условиям работы продуктовых IT-команд. Это значит, что в стажировку войдут дейлики, демо, работа в команде и самообучение — всё, как в командах разработки современных IT-компаний.
Стажировка будет проходить онлайн в вечернее время после 18:00 (по мск), можно подключаться из любой точки мира.
Кому подойдёт
Начинающие аналитики
Вы начинающий аналитик
с базовыми знаниями,
которому нужен опыт в резюме и кейс в портфолио.
Нужна стажировка
Есть небольшой опыт в бизнес и системном анализе, и нужен реальный опыт работы аналитиком в команде.
Удаленная
работа
Хотите работать аналитиком, иметь более гибкий график работы и перемещаться по миру.
Студенты
Учитесь в университете или колледже, хотите стать аналитиком, а также зачесть стажировку в качестве учебной практики.
Требования
к стажёру
Почему стоит выбрать нашу стажировку?
<one>
<two>
<three>
Что вас ждет
Документ по окончании
После защиты итогового проекта вы получите сертификат.
Менторы
Стажировку проводят специалисты IT-компаний. Они объяснят теорию простым языком. Помогут освоить необходимые навыки и технологии, которые сами используют в работе ежедневно. Дадут совет, как развиваться в новой профессии новичку и успешно пройти собеседование.
Наши менторы помогают при работе над проектом, который вы разрабатываете на стажировке.
Анастасия Голунова
Системный аналитик ООО "ПАРК"
Алексей Усков
Директор IT-академии Lad.
20 лет опыта работы в IT.
Преподаёт 19 лет.
Что в итоге
Опыт
Доведете проект от идеи до релиза
Команда
Поймете, как строится работа в проектной команде
Портфолио
Положите в портфолио коммерческий проект
Рекомендации
Получите рекомендации для трудоустройства
Что разработано на стажировке
Стажировка (2023 - 2024 г.)
YöReactions
Веб-приложение для создания презентаций с обратной связью в режиме реального времени.
Стажировка (осень 2022 - весна 2023)
Family Tree
Сервис позволяет создать генеалогическое древо семьи.
Стажировка (осень 2023 - весна 2024)
РУТС
Проект от создателей "Беги, герой!".
РУТС - это забег с культурной начинкой, акцент которых сделан на объединение интересов людей к новым местам, культурным ценностями, а также активному образу жизни .
Отзывы
Участие в стажировке - это колоссальный опыт, который позволяет полностью погрузиться в будущую профессию. Моя стажерская история началась с момента, когда я получила письмо о зачислении на поток, эмоции переполняли. И вот первый день, собрание, мы сами сформировали группы, нам поставили задачу и началось самое интересное...усердная работа аналитиков. Нас, аналитиков, на проекте было двое, от этого было немного проще, мы общались, советовались, помогали друг другу и делились знаниями. Было очень интересно изучать новые технологии и инструменты, самостоятельно разбираться в структуре, придумывать логику работы приложения, взаимодействовать с командой. Было сложно, но невероятно интересно. За время стажировки было много вопросов. Основные из них: что же на самом деле хочет заказчик и как сделать продукт максимально простым и удобным; как поставить задачи разработчикам так, чтобы все всё поняли? В результате ответы на вопросы были найдены. Минусом стажировки, наверное, можно назвать ее продолжительность (6 месяце). Из-за того, что в самом начале , мы достаточно долго решали организационные вопросы, разработка немного затянулась... но плюс - готовый MVP. Хочется выразить благодарность компании LAD за организацию стажировки и за возможность по-настоящему погрузиться в рабочий процесс.
Светлана Красильникова
Стажировка превзошла все мои ожидания.
1) Мы разработали MVP продукт и уже этот факт - причина гордости =)
2) Мне очень понравилось работать в большой команде (около 20 человек). Благодаря такому опыту появилось понимание, кто за какую часть ответственен (дизайнеры, тестировщики, фронты, бэки, мобильные разработчики, тех. писатели, PM и аналитики)
3) В команде царила отличная атмосфера взаимопомощи, и со всеми членами команды было интересно общаться. Мы все были замотивированы сделать отличный продукт ;)
4) Во время работы над реальным, а не учебным проектом, появилось понимание многих нюансов, которые нужно продумывать и прописывать в требованиях. После курсов на системного аналитика от ТГУ я знала основы требований, но о многих нюансах не догадывалась.
5) Еще во время стажировки я устроилась на работу системным аналитиком. Было нелегко совмещать новую работу и стажировку, но я дошла до конца и очень рада, что увидела итоговую версию продукта ("YoReaction")
6) Хотелось бы подметить, что в начале стажировки наша команда долгое время топталась на месте, слабо представляя весь процесс разработки. Но когда осознали процесс, работа пошла гораздо быстрее и все члены команды все время были чем-то загружены)
7) При разработке каждый из нас совершал ошибки, которые тормозили процесс. И это тоже непередаваемый опыт из разряда "как делать нельзя"
Голунова Анастасия
Есть в ретроспективе подход писать ""плюс"" и ""дельта-плюс"" вместо ""минус"" (что хотелось бы изменить), поэтому так и сделаю.
=====ДЕЛЬТА=====
===О начале Тяжелое начало, хотя понимаю, что это было не просто для всех и требовало сил и времени. Мне не хватило на первых неделях информации про Swagger, Figma, и сам перечень доработок, и чтобы менеджмент понимал процессы. Среди опытных людей ""возьми перечень задач"" у продакта и ""спроси формат нужной документации"" у команды звучит справедливо, но когда все с нуля, это не работает. Я расстроилась, что ничего не запускается.
===О доске и задачах Ожидала, что люди будут готовы в начале работать с доской и формировать задачи. Я бы сделала для менеджмента отдельный семинар что такое доска, в частности в Youtrack, что такое карточки и общий механизм нарезания задач, что должно быть в карточках, как берутся карточки в разработку, какие-то графические материалы: планирование спринта тогда-то, старт тогда-то, что должно быть готово к спринту, какие есть колонки, что такое технически dev и prod, зачем они нужны.
===Как нагрузить 4 разработчика Особенности стажировки такого свободного формата по вечерам для аналитика: т. к. обязательства присутствовать и что-то делать ни у кого по сути нет, кроме собственного желания, могут наблюдаться дни, в которые не можешь что-то выяснить или дождаться вовремя тестирования. На стажировку у многих есть несколько часов по вечерам, не у всех они есть каждый день, не все готовы сильно тратить выходные. Из-за этого есть риск не успеть приготовить свою работу, а аналитик привязан к итерациям, потому что 4-х разработчиков нужно чем-то загрузить на 2 недели.
===Почему аналитику нужно на старте проекта больше времени Могу привести расчёты :)
На прошлой работе мы считали статистику: работа аналитика чаще составляет 30--50% от работы разработчика, бывает, аналитик работает больше разработчика над задачей (200%), чем лучше проработка, тем меньше времени уходит на реализацию. Иногда анализ может показать, что доработка совсем не нужна. Предположим: один разработчик тратит 2 ч в будни и 4 часа в выходные, то 4 разработчика - 144 ч в итерацию. 40% от 144 ч = 57,6~58 часов нужно аналитику.
Сюда еще не входят трудозатраты на описание на первом этапе всяких вещей вроде vision проекта, выяснения с менеджментом пользователей, ролей, составления перечня Epics, User Story и деление их на названия Use cases (сами юз кейсы уже расписываются каждую итерацию). Это еще часов 15-20. Итого получается где-то 58+15= миним. 73 часа. Если 73 ч / 4 часа в день без выходных, получится 19 дней. Это не считая времени, которое нужно потратить на митинги, семинары, изучение информации для работы, то есть, каждый день без выходных тратить по 4 часа не получится. Поэтому выходит 3-4 недели на запуск этого проекта аналитиком без лишней суеты в формате стажировки.
===Форматы взаимодействия Настя советовала направлять вопросы письменно продакту, менеджменту, но это не было эффективно в нашем случае. Проще было объяснить, что я хочу спросить, в формате звонков и показами Фигмы, требований, приложения - что было на тот момент готово.
===Сроки тестировщиков На митингах мы слушали только разработчиков, каких-то сроков для тестировщиков у нас не было, поэтому задачи могли висеть дольше. Из-за отсутствия быстрого тестирования в некоторых моментах могут быть ""накладки"": нужно, чтобы тестировщик нашел баги, их поправить, а потом новые требования добавить к существующей функциональности. Исправлять что-то до того, как нашел тестировщик, не хотелось. Из-за этого какие-то доработки пришлось делать позже, чем могли бы, и требования не обновлять, а дописывать в конце. Я бы тоже ввела какой-то контроль менторами или менеджментом.
===Знакомится с требованиями разработчикам до итерации Я бы привлекала разработчиков больше к выработке варианта реализации до старта итерации. Это известная проблема, и Максим прав, что этому помог бы ввод оценки доработок в сторипойнтах, но менеджмент в итоге на это не пошёл (подозреваю, не понятна была особо идея сторипойнтов), а я за эту тему не взялась, изучала свои темы. Если бы делали с нуля, то без консультаций с разработчиком можно напроектировать то, что не будет работать.
===Что такое Agile и что нужно было от него ждать команде На старте многие не понимали, что такое итерация, и что значит итеративная разработка. Я бы на первых встречах рассказала, что такое Agile. Лида готовила небольшое объяснение, но людям обилие терминов было не понятно по сути: что такое ""итеративный подход"". Я бы объяснила просто: требования будут готовиться частями, разрабатываться частями, тестироваться. А потом те же требования могут быть изменены, доработаны и сделаны новые, т. е., все работают каждую итерацию. Возможно, тут нужна какая-то картинка, иллюстрирующая процесс. Иначе люди ждали готовых требований по всему приложению к первой итерации. Надеяться на эмпатию в этом вопросе бесполезно: в начале стажировки люди находятся в стрессе, каждый хочет показать себя, поэтому как аналитик будет описывать за 1-2 недели всё приложение с абсолютно готовой логикой от и до просто никто на тот момент не думает.
=====ПЛЮСЫ===== Что оказалось полезным: работа в команде, работа в полном цикле - выяснение что нужно, разработка требований, сбор мнений, постановка задач разработчикам, разработка, тестирование, ответы на вопросы тестировщиков. Практика - это то, что в учебных пособиях не наберешь. В книгах написано одно, а на практике удобнее оказывают немного другие форматы - это тоже важно было освоить.
Поучаствовала во встречах для менеджеров, посмотрела материалы для тестировщиков, была новая информация. Отдельно хочется сказать спасибо Павлу за неравнодушие к процессу.
Считаю, что попалась хорошая команда, все старались разобраться, что происходит, даже если не работали с чем-то раньше. Разработчики разработали всё, что мы планировали, никто никуда не пропадал, и переделывали то, что мы просили. Тестировщики ответственно находили баги, и было видно, что проверяют много кейсов. Было много вопросов в документе, что приятно, значит, его вычитывали хорошо. :) Менеджмент нашел интересные форматы проведения ретро в Miro по совету Максима, было интересно. Я рада, что проект удалось реализовать.
Итого:
- Провела встречу 1-1, получила представление об этом. - Поизучала Metabase, с бесплатной версией не развернуться, но примерно представляю, как работает. - Поизучала нотацию BPMN, т. к. остальные диаграммы я знала, а этой не пользовалась. - Поучила людей тому, что умею, например, много вопросов было про Swagger, как работает приложение в браузере и пр. Заодно обновила свои знания, была мотивация изучить что-то новое в подходах разработки, понять, какие мысли люди понимают, а какие нужно переформулировать. - С менеджментом собирались на отдельные встречи по планированию итераций, поэтому работать со временем стало хорошо. - Обновила практику ""нарезания"" задач разработчикам из требований. Т.к. требования и задача - разные и требуется опыт и того, и того. - Посмотрела, какие форматы требований ""работают"", а что нужно уточнять и писать не так, как в книгах. Настя говорила, что формат подбирается под команду -- в принципе, так оно и получилось. - Нахождение в команде людей, которые успешно учатся, в принципе мотивирует учиться дальше.
===Что ещё бы хотелось===
С удовольствием поизучала бы темы: к современному аналитику не редко требования знаний не только бизнес-анализа, но и как распилить монолит на микросервисы, брокеры очередей (Redis, RabbitMQ, Kafka), методологии интеграции приложений, проектирование и работа с NoSQL. Может показаться, что это какой-то solution architect - так оно и есть, есть мнения, что аналитик в IT к этой роли стремится, и требуется много hard'ов.
Спасибо, что пригласили на стажировку! Считаю, что это очень полезная возможность для начинающих и переходящих из различных направлений специалистов. Желаю вам успешных дальнейших запусков стажировок!
У нас были встречи для аналитиков. В начале мы разбирали типы требований, приемы документирования, ментор Настя делала презентации и проводила встречи. На второй встрече речь шла про различные диаграммы и способы их построения. В течение стажировки Насте сбрасывала требования и консультировалась по формату и содержанию. Настя всегда отвечала и проверяла, иногда давала рекомендации, как лучше сделать. Так как разработка требований пришлась на первую половину в основном стажировки, то мы и общались больше первую половину. Настя - отличный человек, общаться одно удовольствие.
Асилия Тихонычева
Стажировка прошла очень комфортно.
Из плюсов: Вначале казавшийся неожиданным формат ""кинули в речку - плыви"", оказался очень действенным. Пусть и на своих ошибках, но самостоятельно принимались решения и приходило понимание почему именно так , а не иначе. Очень важно, что ""надо делать именно так"" пришло само, а не насаждалось свыше, что могло восприниматься негативно и с мыслью: "" А я бы сделал по другому""
Из минусов: Был немного смазанный вход из-за постепенного введения всех членов команды, т.е. у кого-то было больше информации и подразумевалось, что как будто ее знают все
Анастасия очень приятный ментор, отвечала на любые вопросы, советовала что можно улучшить Провела несколько встреч, где рассказывала о способах написания требований. Не настаивала ни на одном, но подробно описывала варианты.
Дарья Столярова