Стажировка системного и бизнес-аналитика

Участие в стажировке - это колоссальный опыт, который позволяет полностью погрузиться в будущую профессию. Моя стажерская история началась с момента, когда я получила письмо о зачислении на поток, эмоции переполняли. И вот первый день, собрание, мы сами сформировали группы, нам поставили задачу и началось самое интересное...усердная работа аналитиков. Нас, аналитиков, на проекте было двое, от этого было немного проще, мы общались, советовались, помогали друг другу и делились знаниями. Было очень интересно изучать новые технологии и инструменты, самостоятельно разбираться в структуре, придумывать логику работы приложения, взаимодействовать с командой. Было сложно, но невероятно интересно. За время стажировки было много вопросов. Основные из них: что же на самом деле хочет заказчик и как сделать продукт максимально простым и удобным; как поставить задачи разработчикам так, чтобы все всё поняли? В результате ответы на вопросы были найдены. Минусом стажировки, наверное, можно назвать ее продолжительность (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'ов.

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

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

Стажировка прошла очень комфортно.

Из плюсов: Вначале казавшийся неожиданным формат ""кинули в речку - плыви"", оказался очень действенным. Пусть и на своих ошибках, но самостоятельно принимались решения и приходило понимание почему именно так , а не иначе. Очень важно, что ""надо делать именно так"" пришло само, а не насаждалось свыше, что могло восприниматься негативно и с мыслью: "" А я бы сделал по другому""

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

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