Вау. Вау. Вау! Это было круто и мы хотим это повторить!

Коллеги, вчера прошел практический вебинар
🧩 Интеграции: пошаговый план работы на проекте
и он был похож на что-то необыкновенное!

Я очень хочу поблагодарить коллег, кто был онлайн и работал со мной в пряом эфире, задавал вопросы через микрофон. Давайте все поставим ❤️ Катерине и Тиму в благодарность за активность!


О важном 👇

1. Я проводила этот вебинар с целью напомнить о старте потока по проектированию Интеграциий систем, но уже в понедельник мы поняли, что этот вебинар не нужен. Поток закрыт.
Почему я провела его ни смотря на перегрузку, с учетом конференции в понедельник и большого объема задач по текущим проектам?
Я обещала. Я сделала. И я счастлива, что еще один практический кейс у вас в копилке ❤️

2. Что будет в этот раз с повтором, и еще раз про то, почему я не публикую записи.
Коллеги, когда я создала GetAnalyst, я публиковала записи. Кому это было нужно? Никому. Откладывали на потом и никто не смотрел. Потом. Потом. Никогда. И зачем?
Я понимаю, что есть удобство по времени и среда 19Мск не всегда всем удобна. Но....
Благодаря текущему подходу с повторами вы онлайн и вы работаете в эфире. Вы задаете вопросы и я отвечаю сразу.
Про повтор: ждем сообщения от команды GetAnalyst здесь, на почте и на странице регистрации.


Я люблю GetAnalyst. Я хочу развивать наше сообщество. Но давайте хотя бы на минутку задумаемся.... Как много времени я дарю вам?

Я вижу коллег, кто со мной уже очень давно и ценит каждый мой эфир. И я вижу негодование "почему нет записей" и "инфоцыганство". Пусть это будет чем угодно, но я искренне горжусь людьми, кто благодаря GetAnalyst вырос и реализовал свои цели.

Практический опыт и рост в карьере? Вы в правильном месте, чтобы собирать опыт. Просто посмотреть и подготовиться к собеседованиям? Есть курсы по подготовке к собеседованиям. Я про реальные знания. Я хочу работать с крутыми аналитиками, а не с людьми, кто выучил алгоритм собеседований.

Всем крутого дня! Вернусь скоро с маппингом по сценарию с платежами 😊

Всем привет! 👋

Начало рабочей недели хотим сделать продуктивным, но не слишком сложным (ведь понедельники и так не сахар!😅). Сегодня подробнее разберём тему разработки ПО, а именно — сам процесс разработки IT-продукта #hardGetAnalyst

Создание и сопровождение любого IT-продукта – это многократно повторяющийся процесс внутри компании. Этот процесс называют жизненным циклом разработки ПО.

Жизненный цикл разработки ПО — это ряд взаимосвязанных этапов, через которые проходит продукт: от момента зарождения потребности до завершения работы продукта.

Создание любого ПО можно разделить на шесть этапов:

1️⃣ Сбор и анализ требований.
2️⃣ Документирование требований.
3️⃣ Проектирование архитектуры.
4️⃣ Разработка системы.
5️⃣ Тестирование созданной системы.
6️⃣ Внедрение и перевод в поддержку и развитие.

Далее подробнее о каждом из них.

Этап 1️⃣: Сбор и анализ требований

Для начала команда должна сформулировать, что она создаёт и зачем. Для этого необходимо собрать требования у заказчика.

Заказчик — это человек или группа людей, выступающие от лица пользователей ПО. Часто это руководитель отдела или владелец бизнеса.

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

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


Этап 2️⃣: Документирование требований

После сбора информации аналитик перекладывает своё видение на «бумагу». Формируется документ, в нём прописывают:
🔹 требования к функционалу, который планируется разработать;
🔹 процессы в их нынешнем состоянии (AS IS)
🔹 и то, к какому виду они должны прийти после разработки (TO BE).

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


Этап 3️⃣: Проектирование архитектуры

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

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


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

🥷: Кстати говоря, про этапы разработки ПО часто спрашивают на собеседованиях 😉

💥 Продолжаем с этапами разработки ПО! 💥

На первых трёх этапах разработки ПО:
1️⃣ Сбор и анализ требований
2️⃣ Документирование требований
3️⃣ Проектирование архитектуры
аналитик задействован на все 200%.

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

Этап 4️⃣: Разработка системы

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

Вы уже знаете, что разработчики делятся на фронт- и бэк-разработчиков: первые отвечают за разработку пользовательских интерфейсов, вторые — за работу системы «под капотом», то есть части ПО, невидимой пользователю.


Этап 5️⃣: Тестирование созданной системы

Тестирование системы — это комплексная проверка её алгоритмов на:
🔹корректную работу в разных операционных системах (Mac, Windows, другие), браузерах (например Яндекс Браузер, Mozilla Firefox, Safari, Chrome) и на разных устройствах (смартфоны, планшеты, компьютеры);
🔹 соответствие полученного результата ожиданиям в прописанных требованиях;
🔹 наличие «слепых зон» в логике работы функциональности, которые не были обозначены на этапе аналитики.

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


Этап 6️⃣: Внедрение и перевод в поддержку и развитие

Внедрение системы — это обучение пользователей, выдача учётных записей и поддержка пользователей в начале работы с системой.
Чтобы продукт «ушёл в народ», нужно подружить пользователя с ПО:
🔹 продемонстрировать ПО в действии,
🔹 написать инструкцию и ответить на возникшие вопросы.

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

Так как IT-продукт — это система, которая живёт и развивается, жизненный цикл может воспроизводиться несколько раз.

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

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

👀 А ВОТ И КВИЗ! #quizGetAnalyst

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

Итак, ваша задача:
1. Внимательно прочитайте предложенные высказывания на тему цикла разработки ПО.
2. Отметьте все верные высказывания, а все неверные не отмечайте. Получается, верных высказываний может быть несколько.

А потом вместе проверим и обсудим ответы в комментариях. Удачи! 🥷

Друзья, внеплановый мем 😅
#GAhahaha

👋 Итак, друзья, результаты КВИЗ-а!

1. 🔴 Бизнес- и системные аналитики на первых трёх этапах действительно являются прямыми исполнителями. На этапе разработки, тестирования и внедрения аналитики тоже привлекаются, но в качестве экспертов и согласующих. Итог: аналитик привлекается на всех этапах цикла разработки ПО.

2. 🔴 Количество этапов в разработке ПО не зависит от методологии разработки ПО. В каскадной (или, по-другому, водопадной) модели и в гибких методологиях цикл разработки состоит из тех же чередующихся этапов.

3. 🟢 🔴 Вы не попались на шалость! Если говорить про этапы жизненного цикла ПО, то проектирование архитектуры — это отдельный шаг в этом цикле, поэтому утверждение можно считать неверным.
Но если все три этапа объединить одним процессом — процессом сбора требований, то по результатам этого процесса аналитик предоставляет артефакт в виде требований к ПО и его архитектуре. Поэтому высказывание также можно считать утвердительным. Короче говоря, важна верная аргументация.

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

4. 🟢 Этапы разработки ПО — это цикличный процесс. Каждое новое обновление внутри проектирумой системы запускает этот процесс с начала.

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

Ну как вы, справились? По результатам КВИЗа мы решили, что вы просто умницы! 😎

🔥 МОТИВАЦИЯ НА ЭТИ ВЫХОДНЫЕ 🔥

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

Давайте поговорим на моем примере. Моё обучение никогда не прекращается. Я обучаюсь новому не просто 1-2 раза в год, это для меня стало частью жизни. И здесь речь идет не о том, чтобы просто копить знания, но о том, чтобы их применять, чтобы расти как профессионал.

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


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

🛠 Профессиональное развитие:
В каждой профессии важно сочетание Hard skills 🏋‍♀️ и Soft skills 👥. Для системного аналитика, например, важны навыки проектирования БД. Этот "твёрдый" навык помогает понимать требования к данным, структурировать их и задавать правильные вопросы заказчикам.

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


Каждый новый навык или опыт, который вы приобретаете, делает вас сильнее и более конкурентоспособным. Не бойтесь новых вызовов и идите вперёд к новым вершинам! 🌟

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

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

Приятные ощущения от этих мыслей, да? Я хочу помочь вам сделать шаг в ваше реальное будущее.

Онлайн-практикум:
📚 От проектирования БД до SQL-запросов
📅 26 сентября, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Что вас ожидает:
🔍 Анализ требований и выявление ключевых сущностей.
📐 Проектирование БД с нуля на концептуальном, логическом и физическом уровнях.
💻 Реализация созданной модели базы данных в SQLite.
⌨️ Выполнение на ней SQL-запросов.
🤖 Лайфхаки от Кати: применение ChatGPT для проектирования БД и SQL-запросов.

Что я жду от вас:
✅ Готовность работать со мной в прямом эфире и не бояться задавать вопросы.
✅ Подготовка в течение недели по теории и инструментам.
✅ Не отвлекаться в процессе и заранее подготовиться к тому, что у вас реальное обучение.


Готовы получать опыт? Регистрируемся и отмечаем любой реакцией здесь, что вы в деле!
Жду в следующий вторник онлайн ❤️️