Стажировка по аналитике

1.

2.

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

3.

План практики
Этап 1 — Бизнес-анализ
• Жизненный цикл разработки ПО
• Методологии разработки
• Управление требованиями
Этап 2 — Системный анализ
• Базы данных
• Архитектура
• Интеграции

4.

План практики
Этап 3 — Выход на рынок
• Сбор резюме
• Тренировка интервью
• Оформление кейсов
Этап 4 — Поиск работы
• Помощь с откликами
• Поддержка при собеседованиях
• Сопровождение до выхода на работу
Этап 5 — Сопровождение
• Консультация при выполнении задач
• Разбор внутренних ситуаций
• Консультация по взаимодействию с командой

5.

Структура работы и правила

6.

Зачем нужен
аналитик?
Короткий ответ: Чтобы сэкономить деньги заказчика и нервы
разработчиков.
Переводчик: Бизнес не говорит на языке кода, программисты не
говорят на языке прибыли. Аналитик переводит «хочу кнопку» в
описание API endpoint и обратно.
Экономия: Исправить ошибку на бумаге в 10 раз дешевле, чем
переписывать готовый код. Аналитик находит ошибки до начала
разработки.
Ясность: Разработчик пишет код по четкому ТЗ, а не гадает, что
имел в виду заказчик. Это убирает хаос и бесконечные переделки.

7.

Чем занимается
аналитик?
• Изучает бизнес-процессы, выявляет проблемы и возможности для
улучшений.
• Создает технические задания, диаграммы и модели (например,
схемы процессов, прототипы интерфейсов).
• Координирует работу команды разработчиков, тестировщиков и
других участников проекта, чтобы итоговый продукт
соответствовал ожиданиям заказчика.
• Участвует в тестировании и внедрении решений, помогает
устранить недочеты.

8.

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

9.

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

10.

С кем взаимодействует
аналитик?
• Тестировщик: тестирует функционал по требованиям аналитика,
уточняет сценарии. Аналитик подсказывает ключевые кейсы.
• Разработчик: консультирует по техническим ограничениям.
Аналитик передаёт и разъясняет требования. Возможны созвоны
для уточнений
• Менеджер проекта: аналитик помогает менеджеру проекта
планировать работу, согласовывать приоритеты и сроки с
заинтересованными сторонами.

11.

С кем взаимодействует
аналитик?
• Дизайнер: аналитик сверяет макеты с требованиями, выявляет
визуальные несоответствия.
• Другие аналитики: обмениваются консультациями, проверяют
задачи друг друга, помогают с формулировками.
• Лид аналитиков: распределяет задачи, помогает в сложных случаях
и с поиском специалистов.

12.

Типичные задачи
Сбор и уточнение требований.
Описание бизнес-процессов и логики системы.
Подготовка спецификаций, сценариев и критериев приёмки.
Согласование решений со стейкхолдерами.
Разъяснение требований команде разработки и тестирования.
Проверка корректности реализации и поддержка тестировщиков.
Ведение документации и обновление схем.

13.

Зона ответственности
аналитика (Бизнес-анализ)
Где начинается: С момента появления идеи у заказчика
В процессе: Передаёт бизнес-функциональную спецификацию
системному аналитику, уточняет требования для системного
аналитика, разработчика, тестировщика и дизайнера в процессе
работы.
Где заканчивается: После финальной приёмки готового продукта
перед внедрением или публичным релизом.
Задачи:
• Сбор и формализация бизнес-требований от заказчика и
стейкхолдеров.
• Выявление целей, требований, ограничений.
• Подготовка бизнес-функциональной документации.
• Согласование требований с заказчиком, уточнение требований для
технической команды.
• Участие в финальной приёмке перед релизом: соответствует ли
результат ожиданиям бизнеса.

14.

Зона ответственности аналитика
(Системный анализ)
1.Получение бизнес- и функциональных требований
• Получает требования от бизнес-аналитика или напрямую от
заказчика.
• Уточняет детали по бизнес- и функциональным требованиям.
• Разбивает бизнес- и функциональные требования на более
технические, понятные для команды разработки.
2.Системная проработка
• Преобразует бизнес- и функциональные требования в системные
требования и спецификации.
• Определяет архитектуру компонентов, сценарии взаимодействия,
API, потоки данных и правила обработки.
• Создает техническую документацию: диаграммы, схемы, форматы
данных и т. д.

15.

Зона ответственности аналитика
(Системный анализ)
3.Коммуникация с командой разработки и дизайна
• Передаёт системные требования разработчикам и дизайнерам.
• Отвечает на вопросы, уточняет детали в процессе реализации.
• Следит за соответствием разработки требованиям.
4.Поддержка тестирования
• Отвечает на вопросы тестировщиков.
• Совместно с Бизнес-аналитиком помогает формировать тест-кейсы
на основе требований.
• Проверяет результат реализации на соответствие требованиям (в
т.ч. приёмка).

16.

Зона ответственности
аналитика
5. Внедрение
• При необходимости участвует в релизах и внедрении.
• Консультирует команду внедрения.
• Анализирует возможные отклонения и проблемы.
6. Эксплуатация и сопровождение
• Анализирует баги, собирает дополнительную информацию от
пользователей.
• Определяет, является ли поведение системы багом или фичей.
• Формирует требования на доработки.

17.

Зона ответственности
аналитика
7.Вывод из эксплуатации
• Анализирует влияние отключения системы.
• Участвует в планировании переноса(миграции) данных и
переходных процессов.
• Обеспечивает корректное завершение использования системы.
• Анализирует риски при поддержке устаревшей системы.
• Участвует в принятии решений: переписать, модернизировать или
оставить как есть

18. Жизненный цикл разработки ПО – Software Development Life Cycle (SDLC)

19.

1. Идея - формулировка проблемы или возможности, ради которой создаётся
система.
2. Сбор и анализ требований - выявление, уточнение и документирование
потребностей бизнеса и пользователей.
3. Проектирование системы - Определение архитектуры, компонентов,
интерфейсов и принципов работы системы.
4. Реализация - непосредственная разработка программного кода и
конфигураций.
5. Тестирование - проверка системы на соответствие требованиям и выявление
дефектов.
6. Деплой - развёртывание системы в целевой среде и подготовка к
эксплуатации.
7. Поддержка и обслуживание - эксплуатация системы, исправление ошибок,
улучшения и сопровождение пользователей.
8. Вывод из эксплуатации - плановое прекращение использования системы и
её безопасное отключение.

20. Методологии разработки

21. Waterfall

Что это?
Waterfall – это методология, при которой процесс разработки
идет строго поэтапно.
Каждый этап завершается перед началом следующего.
Вернуться на предыдущий этап невозможно.
Основные этапы:
1.Анализ требований – Понимание того, что нужно создать.
2.Проектирование – Планирование структуры системы.
3.Разработка – Написание кода.
4.Тестирование – Проверка работы.
5.Внедрение – Запуск продукта.
6.Поддержка – Исправление ошибок после запуска.

22. Для каких проектов подходит Waterfall?

23. Waterfall

Плюсы:
• Полное понимание требований до начала разработки.
• Легкость в управлении и отслеживании этапов.
Минусы:
• Сложно вносить изменения после старта.
• Долгое ожидание готового результата.
Пример:
Разработка банковского ПО: Когда требования заранее
четко определены, и их изменение в процессе разработки
нежелательно.
Строительство инфраструктурных объектов: Например,
создание системы управления аэропортом или железнодорожным
терминалом, где каждый этап должен быть завершен до перехода к
следующему.

24. Скрам (Scrum)

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

25. Артефакты Скрам (Scrum)

Бэклог продукта (product backlog) — это приоритезированный
список задач, требований и функций, которые необходимы для
улучшения продукта. В него входят как уже запланированные шаги,
так и пожелания заинтересованных лиц по улучшению продукта.
Бэклог Спринта (sprint backlog) — это приоритезированный список
задач, требований и функций, выполнение которых гарантирует
выполнение цели спринта и поставку инкремента.
Инкремент – самостоятельная версия продукта, поставленная в
результате выполнения цели спринта.

26. Ритуалы Скрам (Scrum)

Планирование спринта
Происходит в начале каждого спринта и включает:
• Выбор задач: Берутся задачи из бэклога продукта, которые
команда может реально выполнить.
• Оценка сложности: Каждая задача оценивается по времени или
сложности выполнения.
• Определение цели: Команда ставит достижимую цель,
например, разработка новой страницы сайта или внедрение
определенной функции.
Daily (дейли) / Ежедневный митинг – это встреча которая обычно
проводится не более
15 минут. Каждый член команды разработки отвечает на 3 вопроса:
Что я закончил вчера?
Над чем я буду работать сегодня?
Я заблокирован чем-нибудь?

27. Ритуалы Скрам (Scrum)

Ретроспектива
Проводится после завершения спринта, чтобы команда могла
улучшить свои процессы. Обсуждаются:
• Что прошло хорошо: Успехи и достижения.
• Что можно улучшить: Проблемы и трудности.
• План действий: Какие изменения внедрить в
следующий спринт. Ретроспектива помогает
команде становиться лучше и эффективнее.
Плюсы:
• Быстрая реакция на изменения.
• Постоянная обратная связь от заказчика.
Минусы:
• Требует высокой самоорганизации команды.
• Могут возникать проблемы, если цели спринта
нечеткие.

28. Скрам (Scrum)

Ревью спринта
Что это?
Встреча в конце спринта, где команда демонстрирует готовый
инкремент продукта заинтересованным сторонам и обсуждает,
что было сделано, а что нет.
Кто участвует?
Scrum-команда, заказчики, стейкхолдеры.
Что делает аналитик?
• Проверяет, соответствует ли результат требованиям.
• Участвует в демонстрации (может объяснять сложные или
ключевые изменения).
• Фиксирует обратную связь от заказчиков и стейкхолдеров.
• Обсуждает доработки или новые задачи, которые могут попасть
в следующий спринт.

29. Для каких проектов подходит AGILE SCRUM?

30. Что такое MVP?

MVP (Minimum Viable Product) — это минимально
жизнеспособный продукт.
То есть самая простая рабочая версия, которая позволяет:
• протестировать идею,
• собрать обратную связь от пользователей,
• избежать затрат на ненужную функциональность.
MVP в Waterfall
• Подходит как ограниченный проект: есть чёткие сроки,
бюджет и фиксированный
объём.
• Позволяет быстро собрать базовый продукт, не распыляясь
на "хотелки".
• По сути тестирование продукта, взлетит или не взлетит
(окупится, будет ли востребован на рынке) - нужно понять,
именно так и мы и поймем.

31. Что такое MVP?

MVP в Scrum
• MVP — это стартовая точка.
• В первые спринты команда создаёт базовую версию, которая
затем улучшается
итеративно.
• MVP даёт заказчику возможность участвовать в развитии
продукта: он видит, как работает основа, и может менять
приоритеты.

32. Скрам (Scrum)

Пример:
Разработка мобильного приложения: Например, создание
приложения для доставки еды, где регулярно добавляются новые
функции, а обратная связь пользователей помогает быстро вносить
изменения.
Стартап: Быстрое прототипирование и тестирование идей, таких
как кредитные сервисы или инвестиционные платформы.
Ключевая причина использования:
Проект с изменяющимися требованиями и необходимостью частой
демонстрации результата.

33. Канбан (Kanban) – Визуальный контроль процесса

Что это?
Канбан – это методология, где процесс разработки визуализируется на доске (физической
или электронной). Все задачи проходят через определенные этапы: например, «В работе»,
«На проверке», «Завершено».
Основные элементы Канбан:
• Доска Канбан:
• Колонки – Этапы выполнения задач.
• Карточки – Задачи, перемещаемые между колонками.
• Ограничения на количество задач – Чтобы не перегружать команду.
• Постоянное улучшение – Регулярное выявление проблем.

34. Канбан (Kanban)

35. Для каких проектов подходит Канбан (Kanban)?

36. Канбан (Kanban)

Плюсы:
• Простота визуального контроля задач.
• Гибкость в приоритизации и изменениях.
Минусы:
• Могут возникать задержки, если команда плохо управляет задачами.
• Нет жесткого временного расписания, как в Скрам.
Пример:
Техническая поддержка и обслуживание: Например, управление потоком задач по
устранению багов или добавлению мелких улучшений в существующий продукт.
Производство ПО для корпоративных систем: Например, разработка и поддержка CRM
или ERP-систем, где постоянный поток задач идет на доработку функционала или
устранение ошибок.

37. Сравнение методологий

Критерий
Ватерфол
(Waterfall)
Скрам (Scrum)
Канбан (Kanban)
Гибкость
изменений
Низкая
Высокая
Высокая
Структура работы
Поэтапная
Циклическая
(спринты)
Постоянный поток
Видимый
результат
Только в конце
В конце каждого
спринта
Постоянно
Подходит для
Стабильных
проектов и
неизменяемые
требования
Быстро
меняющихся задач
Процессов с
непрерывным
потоком (тех.
поддержка)

38. Сравнение методологий

Роль
Scrum
Kanban
Waterfall
Product Owner
Отвечает за
приоритизацию
задач в спринтах,
формирует бэклог
-
-
Scrum Master
Следит за
процессом, убирает
препятствия,
помогает
команде(некий
психолог)
-
-
-
Могут
использоваться,
чтобы управлять
общей нагрузкой
Отвечает за полное
управление
проектом и
соблюдение сроков
Менеджер проекта

39. Сравнение методологий

Роль
Scrum
Kanban
Waterfall
Команда
разработки
Самоорганизующаяся
команда. Берут задачи
из бэклога
Работает
над
задачами из
доски
Kanban
Работает над задачами,
следуя заранее
утвержденному плану
Тестировщик
Встроен в команду,
тестирование
происходит
параллельно с
разработкой
Бизнес-заказчик
Взаимодействует с
владельцем продукта
(вне рамок scrum
процесса)
Тестирование
по мере
выполнения
задач
Может
взаимодействов
а ть для
корректировки
приоритетов
Тестирование
проводится после
завершения разработки
каждого этапа
Обеспечивает
требования на этапе
планирования и
участвует при сдаче
проекта