Я выбрала карьеру в IT после 9 класса и начала движение в этом направлении. Мое поступление в университет было не по выбору родителей, а по собственному осознанному желанию.

Уже на тот момент я понимала, что "корочка" о высшем мне не пригодится. Но боялась это признать.

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

✔️ написание ТЗ
✔️ UML
✔️ проектирование БД, SQL
✔️ принципы ООП
✔️ программирование Java, JavaScript, C#, Delphi (Pascal)
✔️ разработка сайтов
✔️ деловое общение

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

Спустя два красных диплома и годы работы до меня дошла мысль: а можно было идти по простому пути, зачем я выбрала сложно? 😬

В 17 лет, когда я поступала в университет, друзья из IT мне говорили:

▫️ Можно научиться программировать, поработать где-то бесплатно и пойти после этого на работу с высокой ЗП
▫️ У меня есть диплом. Как видишь, я его забираю из университета спустя два года, потому что до этого было лень за ним ехать
▫️ Зачем тебе сложный ВУЗ? Ты же уже работаешь. Тебе надо что попроще, только нужных знаний, а в универ заезжать экзамены сдать

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

"Опытный наставник быстрее приводит к результату" - эта фраза нужна была мне в 17 лет. И опытный наставник.

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

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

Друзья, у кого-нибудь хоть раз реально просили диплом при устройстве на работу?
Да - 👍 и делитесь в комментариях где
Нет - 🔥

В этом подкасте рассказала про высшее образование и свой диплом. История искусств - one love 😅👇

Про высшее образование для начинающих в IT: надо или нет?

📕 Диплом — полезная штука. Уменьшает количество вопросов на собеседовании. Оправдывает, когда устраиваешься на работу без опыта в 19-24 года

📚 Знания — есть полезные предметы. Не во всех ВУЗах, не ото всех преподавателей дождешься структурированной информации без воды и крутой практики, но все же свои 20% полезных предметов я нашла

📝 Я выпускалась с дипломом по выбранной мною теме, а не моим научным руководителем. Это было круто. Я на инициативе сама работала над ним и меня не надо было пинать

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

Что было полезно, а что не очень? Ответ в подкасте 👩‍💻
P.S. История искусств 100%

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

1️⃣ Когда нужны аналитики, а ты не можешь найти их. Хочу клонировать себя
2️⃣ Опытом важно делиться - не хочу быть жадной, большое желание отдавать
3️⃣ У меня не было наставника в системном анализе, когда я начинала. У меня есть возможность дать это другим

P.S. Смотрите хэштег #getanalyst_знакомство
Я хочу собирать лучших системных и бизнес-аналитиков в GetAnalyst ♥️

🔥 Стартуем продуктивный 2023 🔥

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

💥 Проекты с нуля, стартапы
💥 Подключение в развивающиеся проекты (развитие работающего ПО)
💥 Участие в продуктовой разработке (пример: amazon, tinkoff, yandex...)
💥 Внедрение CRM, ERP
💥 Интеграции
💥 Пре-сэилы - анализ предметной области, выявление проблем и подготовка презентаций

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

Даю 100% гарантии - чем больше предметных областей удалось разобрать, тем лучше!

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

Опыт работы на проектах и какие задачи на них выполнялись - это то, на что в первую очередь смотрять в вашем резюме 📑

Доверие людям - одна из важных составляющих моей жизни

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

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

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

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

Был у меня случай, когда я переучила тестировщика с гуманитарным образованием в системного аналитика. И когда помогала junior-разработчикам разобраться с правильными подходами к дизайну REST API - один из навыков опытных аналитиков и программистов.

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

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

За 2022 с GetAnalyst больше 30 бизнес-аналитиков перешли в системный анализ. Со мной в аналитику переходили и специалисты тех. поддержки, и тех. писатели. И меня очень воодушевляют отзывы про то, что я дарю веру в себя, люди успешно меняют работу, увеличивают доход и идут к новым вершинам!

Спасибо вам за доверие ♥️ Растем дальше! 🚀

Я держу обещания. Напоминаю про одно из них 🙃

Бесплатный вебинар
📹 Основы ООП - пишем код в прямом эфире
🗓 11 января 2023, 19:00 (Мск)

Регистрацию завтра откроем! 😉

Включайте уведомления и добавляйте канал в закрепленные, чтобы не пропустить 📌

Как разговаривать с разработчиками на одном языке? Можно поставить себя на место разработчика и написать немного кода, чтобы понять о чем они там на своем "птичьем" поют 🙂

Бесплатный вебинар уже завтра!
🚀 Основы ООП для аналитиков - пишем код в прямом эфире
🗓 11 января (ср), 19:00 (Мск)
🔗Регистрация здесь

В программе:
✔️ напишем вместе небольшую программу
✔️ чтобы понять классы и объекты
✔️ разобраться с наследованием, полиморфизмом и инкапсуляцией
✔️ и применять знания ООП при разработке требований.

Подключаться с компьютера - будем программировать!
До встречи в прямом эфире! 😉

Доброе утро!

Вы вчера задавали очень крутые вопросы на вебинаре! Разобрали даже больше, чем я планировала 💥

Нам удалось освоить все базовые принципы ООП и понять, как они влияют на работу аналитика. А еще и код написали!

На следующей неделе проведем вебинар, на котором будем работать над созданием или обновлением ваших резюме в прямом эфире 📑

🚀 5 лайфхаков для создания цепляющего резюме
🗓 18 января, 19:00 (Мск)

Готовимся активно участвовать! 😉

Хочу поделиться с вами своей историей: как системный анализ и работа в IT повлияли на мою жизнь 🌴

Я всегда мечтала путешествовать. Когда мне было 19, мне казалось, что отпуск 1-2 раза в год за границей - предел мечтаний! И я откладывала ЗП на это редкое удовольствие. Каждый раз ревела, когда уезжала из долгожданной поездки.

Как-то я увидела фотографии подруги, которая побывала в США. Еще до этого мне про Route 66 рассказывали. И мысли были "Ну лет в 30 я точно накоплю и отправлюсь туда в отпуск!". Я была младшим системным аналитиком и очно учлась в ВУЗе.

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

Так появилась цель получить заветное путешествие в США.

Уже через 6 месяцев после появления этой идеи о США я впервые оказалась во Флориде и Калифорнии!

А потом через 2 месяца после возвращения была на выходных в Вене. А еще через 2 выходные в Сочи. Потом выходные в Испании. Да и ЗП росла, что выходные где-то за границей уже были стабильно раз в 4-8 недель. И отпуск в США раз в пол года без отрыва от производства - еще до пандемии я начинала работать удаленно.

Позже я придумала новую цель и накопила на учебу в США. После завершения магистратуры в РФ сразу отправилась туда с удаленной работой старшим системным аналитиком в Москве. Опять же, до пандемии, когда это еще не стало обычным делом))

А сегодняшний день я просто не могла представить. Мне меньше 30, я живу в Калифорнии и у меня бизнес, который работает по всему миру, и команды в разных часовых поясах. Много бывших коллег и друзей из IT сейчас живет не в России.

Я благодарю судьбу за то, что однажды выбрала профессию системного аналитика, которая позволила мне стать ценным и востребованным специалистом для найма в IT-компаниях, и растить свой бизнес за счет опыта общения с крутыми предпринимателями и руководителями! А еще исполнить детскую мечту - путешествовать! 🙌

P.S. Моя мотивационная картинка на 2023 - буду учиться одновременно с вами и двигаться к новым целям 🚀

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

И вот с какими ошиками я сталкивалась, когда только начинала работать аналитиком.

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

Длинные письма по результатам переговоров или их отсуствие
Если мы с заказчиком внесли уточнения в требования в процессе разработки, когда уже ТЗ и договор были подписаны, то правки нужно было фиксировать не только в задачах Jira. Нужно было еще и отправлять письма.
Слишком длинные письма - не читают, и потом на приемке их приходится искать и зачитывать их вслух. Отсутствие письма по уточнениям на приемке как-то обернулось "мы этого не обсуждали, почему не как по ТЗ?".

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


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

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

Что стоит проверять?

✔️ Описали ли вы ограничения по доступности функциональности? Какие роли имеют к ней доступ?

✔️ Вы описали сущность в системе. Например "Заказ". Что с ней можно сделать? Прогнали CRUD-модель (create, read, update, delete), чтобы описать все бизнес- и функциональные требования?

✔️ Вы описываете Use Case (пользовательский сценарий).
- Вы проверили возможные альтернативные сценарии, которые могут быть на каждом из шагов?
- Для клиента - вы указали методы API, которые должны вызываться?
- Для сервера - вы указали откуда брать данные из БД?

✔️ При постановке задачи на дизайнера вы сообщили ему о том, что необходимо отрисовать состояния, когда на экране возникли ошибки или нужно поменять статус (состояние)?

✔️ При проектировании интеграций вы открыли Postman, чтобы убедиться в том, что внешняя система работает корректно в тесте и на продакшн, как вы ожидаете по документации?

✔️ Форма ввода данных. Где делать проверки введенных данных? На сервере перед сохранением в БД точно. А нужно ли дублировать какие-то проверки на клиенте? Как обрабатывать ошибки валидации? Подсвечивать поля красным?

✔️ Вы проектируете БД. В одном заказе может быть много товаров. Один товар может быть во многих заказах. Связь сущностей товар-заказ "многие-ко-многим". Вы поняли почему так? А знаете как избавиться от этой связи? 😉

Это, и даже больше, возможно разобрать и запомнить только на практике! Делайте скриншот, чтобы не потерять этот мини-чеклист 📷

Заглядывайте завтра на бесплатный вебинар, в котором за 2.5 часа я расскажу 2 месяца университетской программы про ООП и покажу, как программировать на C# 😉

Бесплатный вебинар уже завтра!
🚀 Основы ООП для аналитиков - пишем код в прямом эфире
🗓 14 января (сб), 13:00 (Мск)
🔗Регистрация здесь