¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
GetAnalyst - Старт карьеры в IT • Системный аналитик • Бизнес-аналитик
Ir al canal en Telegram
Канал для начинающих карьеру системных аналитиков. Влюбиться в системый анализ и начать свой путь в IT можно здесь! 🚀 Для опытных аналитиков - Навыки • БД • Интеграции • API: t.me/getanalysts Обучение: https://getanalyst.ru/education
Mostrar más5 067
Suscriptores
+524 horas
+197 días
+5730 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
junio '26
junio '26
+32
en 0 canales
mayo '26
+92
en 0 canales
Get PRO
abril '26
+92
en 0 canales
Get PRO
marzo '26
+119
en 3 canales
Get PRO
febrero '26
+152
en 1 canales
Get PRO
enero '26
+120
en 1 canales
Get PRO
diciembre '25
+107
en 2 canales
Get PRO
noviembre '25
+111
en 1 canales
Get PRO
octubre '25
+113
en 3 canales
Get PRO
septiembre '25
+153
en 1 canales
Get PRO
agosto '25
+140
en 2 canales
Get PRO
julio '25
+140
en 1 canales
Get PRO
junio '25
+124
en 1 canales
Get PRO
mayo '25
+132
en 1 canales
Get PRO
abril '25
+144
en 1 canales
Get PRO
marzo '25
+144
en 1 canales
Get PRO
febrero '25
+163
en 2 canales
Get PRO
enero '25
+164
en 2 canales
Get PRO
diciembre '24
+141
en 2 canales
Get PRO
noviembre '24
+197
en 2 canales
Get PRO
octubre '24
+258
en 1 canales
Get PRO
septiembre '24
+1 482
en 1 canales
Get PRO
agosto '24
+129
en 1 canales
Get PRO
julio '24
+192
en 2 canales
Get PRO
junio '24
+132
en 2 canales
Get PRO
mayo '24
+176
en 2 canales
Get PRO
abril '24
+195
en 1 canales
Get PRO
marzo '24
+165
en 1 canales
Get PRO
febrero '24
+103
en 1 canales
Get PRO
enero '24
+135
en 1 canales
Get PRO
diciembre '23
+96
en 1 canales
Get PRO
noviembre '23
+115
en 1 canales
Get PRO
octubre '23
+147
en 1 canales
Get PRO
septiembre '23
+60
en 0 canales
Get PRO
agosto '23
+100
en 0 canales
Get PRO
julio '23
+90
en 0 canales
Get PRO
junio '23
+61
en 0 canales
Get PRO
mayo '23
+41
en 0 canales
Get PRO
abril '23
+43
en 0 canales
Get PRO
marzo '23
+37
en 0 canales
Get PRO
febrero '23
+380
en 0 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 10 junio | +4 | |||
| 09 junio | +5 | |||
| 08 junio | +4 | |||
| 07 junio | +5 | |||
| 06 junio | +3 | |||
| 05 junio | +3 | |||
| 04 junio | +1 | |||
| 03 junio | +3 | |||
| 02 junio | +3 | |||
| 01 junio | +1 |
Publicaciones del Canal
🎯 Чек-лист навыков Системного Аналитика 2026: полная и актуальная версия 🎯
Cобрали полный список навыков, которые чаще всего ждут от системного аналитика в 2026 — от требований и БД до интеграций, API и архитектуры.
Самое полезное 👇
Собрали всё это в одну статью и добавили:
▫️ маркировку по уровням (junior / middle / senior)
▫️ формулу, как оценить свой грейд
🔗 Ссылка на статью
Чтобы было удобно собрать личный план развития, мы сделали PDF-чек-лист.
Можно скачать, распечатать и отмечать прогресс — или просто сделать скрины и отмечать прямо на них.
📄 [PDF прикреплён к посту]
👉 Рекомендации:
1. Пройдите по чек-листу и отметьте свои навыки.
2. Выберите по 2-3 навыка на каждый месяц к освоению.
3. Через год перепроверьте себя: что нового появилось.
✅ А если вы уже строили план по нему, то самое время свериться и подвести промежуточные итоги.
Сохраняйте в избранное и оценивайте свой грейд — это та штука, к которой реально полезно возвращаться весь год 🚀
| 2 | 📖 Подборка книг по Архитектуре и Микросервисам 📖
Когда я только начала знакомиться с архитектурой, то одной из первых и любимых книг сразу стала:
📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс
Благодаря ей я, как системный аналитик, еще раз пересмотрела подходы к проектированию и описанию требований, структурировала знания, и начала осознанно использовать рекомендации из нее.
Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности.
В дополнение к ней:
📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!)
📚 Создание микросервисов, Сэм Ньюмен
📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон
📚 Высконагруженные приложения, Мартин Клеппман
📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин
📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа
📚 DDD - предметно ориентированное проектирование, Влад Хононов
Ставьте реакцию, если сохранили подборку! 😊❤️🔥
#hwGetAnalyst | 378 |
| 3 |  Встречаем новую рабочую неделю👌😁
Желаем успешно разобраться со всеми задачами) | 357 |
| 4 | 🧡 [6–9 июня] Хореография и оркестрация микросервисов: открытый практикум для аналитиков 🧡
В простых задачах всё понятно:
Frontend → Backend → БД.
Но в распределённой архитектуре один процесс может затрагивать сразу несколько сервисов, брокер сообщений и внешние системы.
И аналитику нужно решить:
▫️ кто запускает процесс
▫️ какой сервис отвечает за каждый шаг
▫️ где использовать прямой API-вызов
▫️ где передавать события через Kafka или RabbitMQ
▫️ когда нужна оркестрация, а когда — хореография
▫️ как всё это показать на архитектурной схеме
👉 Этому и посвящён новый практикум по хореографии и оркестрации микросервисов.
На занятии вы разберёте:
✔️ как устроены процессы в микросервисной архитектуре;
✔️ как проектировать оркестрацию и хореографию;
✔️ какую роль играют RabbitMQ и Kafka;
✔️ как отображать взаимодействия сервисов на схемах.
Подойдёт системным аналитикам, которые уже работают с интеграциями и проектированием систем и хотят глубже разобраться в микросервисной архитектуре, событийном взаимодействии и построении сложных процессов.
🧡 Хореография и оркестрация микросервисов: практика проектирования процессов
📅 Доступ 6 - 9 июня
🕘 Время на обучение: ~4 часа
🎯 Формат: урок в записи, можно пройти в удобное время
🔗 Зарегистрироваться
Это полноформатный вводный урок к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 9 июня.
Если к активному осеннему найму хотите увереннее работать с архитектурой, проектировать сложные процессы и претендовать на более сильные позиции — присоединяйтесь 🙌
Вопросы? Пишите @getanalyst или на info@getanalyst.ru. | 413 |
| 5 |  +7Как разобраться в микросервисной архитектуре: реальный опыт студентки GetAnalyst 👩🎓
Ирина пришла на программу «Проектирование архитектуры» с конкретным запросом: разобраться в микросервисах и интеграциях. За плечами — 8 лет в IT и глубокая экспертиза в 1С.
Впереди — поиск новой работы, Kafka и архитектура, которую нужно было освоить быстро.
Вот что из этого вышло #студентыGetAnalyst | 365 |
| 6 |  У вас бывало ощущение неловкости, когда приходишь в новый коллектив или в новую тусовку, а там используют совершенно неизвестные вам слова? Мозг усердно пытается догадаться о чём речь, но без гугла сложно.
Если вы ещё новичок в системном анализе и только погружаетесь в слэнг, команда GetAnalyst собрала самые популярные термины из сферы IT, чтобы вам было легче понимать коллег и снизить градус неловкости при общении.
Сохраняйте пост и пользуйтесь при необходимости.
Аттачить — прикреплять файл
Апрув — подтверждение
Апнуться – улучшить навык, получить повышение
Баг — дефект, отклонение
Бэкап — резервное копирование
Бэклог — список задач, требований или идей, которые предстоит выполнить
Валидный — подходит по критериям
Дебажить — проводить анализ ошибок
Зарелизить — выпускать обновление
Костыль — временное решение проблемы, которое не считается идеальным
Митинг — собрание
Логи — файл-отчёт о действиях пользователя/программы
Онбординг — процесс адаптации нового сотрудника
Отревьюить — проверить
Пушить — заставлять, принуждать
Синк — короткая встреча для синхронизации команды
Таска — задача
Тэдэшка — техническая документация
Фиксить — исправить логику, откорректировать процесс, починить
Фича — новая функциональность или возможность системы
Эскалировать — поднять вопрос на более высокий уровень для решения проблемы
Если упустили какие-то слова, то пишите в комментариях — вместе дополним наш словарь 🙂 | 489 |
| 7 | ⭐️ ФТ vs НФТ: повторить перед собеседованием на СА ⭐️
👉 Функциональные требования (ФТ) — это про то, ЧТО делает система.
Для сервиса доставки еды это могут быть:
+ Пользователь может зарегистрировать личный кабинет в системе для отслеживания истории заказов, получения доступа к функциям электронного кошелька и программы лояльности.
+ Пользователь может искать блюда с учетом фильтров по названию, цене и наличию ингредиентов, а также сортировать результаты поиска.
+ Пользователь может добавить блюдо в корзину.
+ Пользователь может добавить удалить блюдо из корзины.
+ Пользователь может оформить заказ, когда наполнил корзину.
+ Пользователь может оплатить заказ банковской картой или с использованием электронного кошелька.
ФТ — фундамент любой системы.
👉 Нефункциональные требования (НФТ) — это про то, КАК система работает.
❗️ Любое НФТ должно быть проверяемым: либо в фукнциональных/авто-тестах, либо нагрузкой. Непроверяемые формулировки — просто "вода". Это не нужно.
Есть несколько основных видов НФТ, которые вы должны помнить всегда. Рассказываем про них с примерами:
1) Производительность - скорость работы системы.
👎 Система работает быстро.
✅ Время обработки запросов к системе не должно превышать 900 мс при 150 RPS и 300 одновременных пользователей.
2) Доступность и отказоустойчивость - время работы без сбоев.
👎 Обеспечить для системы высокую доступность.
✅ Публичный API должен быть доступен 99.9% в месяц.
✅ Регламентные окна ≤2 ч/мес.
✅ Допустимое время восстановления сервиса после сбоя (RTO) ≤ 15 мин.
✅ Допустимая потеря данных во времени при восстановлении (RPO) ≤ 1 мин для заказов и платежей.
3) Масштабируемость - способность расти в зависимости от нагрузки.
👎 Система должна легко и быстро масштабироваться при увеличении нагрузки от пользователей.
✅ В часы пик 12:00–15:00 и 18:00–21:00 по Мск входящий трафик возрастает в 3 раза относительно базовой нагрузки. Сервисы каталога товаров, заказов и платежей, должны автоматически масштабироваться, увеличивая количество активных инстансов (работающих экземпляров) в 4 раза без простоя.
4) Безопасность
👎 Обеспечить защиту данных.
✅ Система должна поддерживать аутентификацию по OAuth2/OIDC с обязательным PKCE для мобильных клиентов.
А ещё:
5) Целостность
6) Надежность
7) Удобство использования
😍 Эффективность
9) Переносимость
и другие виды НФТ.
Подробнее познакомиться с теорией и примерами по НФТ можно в подкасте:
🔗 Нефункциональные требования: пример для медицинской системы
Пример, когда не учтенные НФТ положили систему:
🔗 Миграция БД, индексы и импортозамещение ПО: как положить прод и поднять обратно
❗️ НФТ считаются одними из самых сложных для понимания аналитиков. Поэтому собрали для вас как примеры, так и реальные примеры их влияния на системы.
Обязательно повторите этот материал перед собеседованием на Junior/Middle позиции. Всегда будьте готовы объяснить разницу и привести примеры 🤝 | 488 |
| 8 | 🧐 ИЗ ЧЕГО СОСТОИТ ТЗ? 🧐
Чаще всего ТЗ содержит следующие информационные блоки:
1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.
2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.
3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.
4️⃣ Основные требования
Список основных функций, возможности, ограничения и взаимодействие с другими системами, а также требования к производительности, безопасности, масштабируемости и другим особенностям продукта.
5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.
6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.
7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.
8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.
9️⃣ Стадии и этапы разработки, а также сроки их выполнения.
🔟 Возможные риски
Где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут же указаны планы по их снижению или управлению.
Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.
🧐 ПРО СТАНДАРТЫ ТЗ 🧐
Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:
❣️Международные (ISO, IEEE)
❣️Российские (ГОСТ 19, ГОСТ 34)
❣️Стандарты из областей знаний (BABOK, Вигерс, RUP и другие)
Все они специализируются на разных предметных областях, поэтому брать можно как готовый стандарт, так и его адаптированную версию. | 566 |
| 9 | 🎯 Чек-лист навыков Бизнес-Аналитика 2026: полная и актуальная версия 🎯
Привлекли в помощь супер-опытного бизнес-аналитика, и мы подготовили для вас актуальную карту компетенций для бизнес-аналитиков, чтобы вы могли честно оценить свой уровень и выстроить план развития.
8 ключевых блоков:
▪️ Soft Skills
▪️ Сбор требований
▪️ Анализ требований
▪️ Фиксация требований
▪️ Прототипирование и моделирование
▪️ Работа с данными
▪️ Управление командой
▪️ Hard Skills
Ничего лишнего, что обычно любят подкидывать нейросети.
Только реальные и актуальные требования к БА.
👉 Как использовать чек-лист
1. Распечатайте / Скачайте PDF
2. Напротив каждого навыка отмечайте «умею / пробовал / нет»
3. Выбирайте 2–3 точки роста на каждый месяц 2026 (могут повторяться: например, два месяца фокусируетесь на одних и тех же навыках)
4. Сверьтесь в конце года и насладитесь прогрессом.
И помните, чем выше грейд у бизнес-аналитика, тем шире зона пересечения с компетенциями системного аналитика. Это нормально и закономерно 🤝
Сохраняйте и пользуйтесь 🔖
Оставайтесь с нами, чтобы забирать самые актуальные и практические знания для аналитиков 🚀 | 629 |
| 10 | 🧐 ИЗ ЧЕГО СОСТОИТ ТЗ? 🧐
Чаще всего ТЗ содержит следующие информационные блоки:
1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.
2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.
3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.
4️⃣ Основные требования
Список основных функций, возможности, ограничения и взаимодействие с другими системами, а также требования к производительности, безопасности, масштабируемости и другим особенностям продукта.
5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.
6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.
7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.
8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.
9️⃣ Стадии и этапы разработки, а также сроки их выполнения.
🔟 Возможные риски
Где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут же указаны планы по их снижению или управлению.
Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.
🧐 ПРО СТАНДАРТЫ ТЗ 🧐
Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:
❣️Международные (ISO, IEEE)
❣️Российские (ГОСТ 19, ГОСТ 34)
❣️Стандарты из областей знаний (BABOK, Вигерс, RUP и другие)
Все они специализируются на разных предметных областях, поэтому брать можно как готовый стандарт, так и его адаптированную версию. | 1 |
| 11 |  Друзья, с первым днём лета ☀️
И с началом новой рабочей недели) | 533 |
| 12 |  И такое бывает 🙈 #GAhahaha | 632 |
| 13 | ![💎 Хореография и оркестрация микросервисов: практика [6–9 июня] 💎 Микросервисная архитектура — это не только про то, чтобы р](data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZlo+AjIqgtObDoKrarYqMyP/L2u71////m8H////6/+b9//j/2wBDASstLTw1PHZBQXb4pYyl+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj/wAARCAAXACgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwBNzPABs5xgmpjFEFACYx3pFjyMADHucUGFj08scf3zWj0MIzbAbRwP5VHJGP4Tz9Kf5L4wCn/fZpRCw67D/wADNK5bnIpNCSSTRV/yyvYH6NmitE7gk3uNBxUdxG8rAo5UAHODiiik1dHNF2YxIJNuDI3pw3/1qkgjdHcs5dSBgFskUUVNjVTZZDEJwoP1ooooNFsf/9k=){kind=small} 💎 Хореография и оркестрация микросервисов: практика [6–9 июня] 💎
Микросервисная архитектура — это не только про то, чтобы разделить систему на отдельные сервисы.
Главное начинается дальше: нужно спроектировать, как эти сервисы будут взаимодействовать в реальных бизнес-процессах.
Аналитику важно понимать, кто за что отвечает, как передаются данные, где нужны события, а где лучше использовать прямые вызовы или оркестрацию.
На новом практическом занятии разберём, как проектировать такие процессы и показывать их на архитектурных схемах.
💎 Хореография и оркестрация микросервисов: практика проектирования процессов
📅 Доступ 6 - 9 июня (сб-вт)
🕘 Время на обучение: ~4 часа
🎯 Формат: урок в записи, можно смотреть в удобное время
🔗 Зарегистрироваться
👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры (RabbitMQ, Kafka)
5. Хореография процессов: практика
👉 Практикум полезен, если вы:
✔️ уже работаете с API и интеграциями, но хотите глубже понимать микросервисную архитектуру
✔️ готовитесь к интервью на Middle+/Senior системного аналитика;
✔️ часто слышите на проектах “Kafka”, “RabbitMQ”, “события”,“микросервисы”, но хотите разложить это в понятную систему
✔️ стремитесь работать с более сложными архитектурными задачами, а не только с экранами, CRUD и простыми API.
Есть планы разбираться в интеграциях микросервисов?
Регистрируйтесь и смотрите практикум в удобное время с 6 по 9 июня 👍 | 634 |
| 14 | Что делать, если требования изменились❓
Главное правило: не паникуйте!
1️⃣ Обсудите варианты реализации изменений
В некоторых случаях изменения можно выпускать доработкой к ранее согласованному решению. А иногда всё таки придётся остановить разработку и откатить работу на этап аналитики, где требования будут переписаны.
В любом из случаев принятое решение должно быть оценено и согласовано с заказчиком.
2️⃣ Если есть возможность, работайте по гибкой методологии
Когда всё ПО проектируется постепенно в виде постоянных небольших доработок, изменениями проще управлять.
Во-первых, всегда есть возможность договориться о переносе новых требований в последующие итерации.
Во-вторых, в гибкой методологии изменения требований происходят менее болезненно. Это связано с тем, что всё ПО проектируется “по кусочкам” — то есть по функциональностям. Соответственно, изменять такие кусочки проще, нежели переписывать всё ПО.
3️⃣ Обращайтесь к авторитетам
Если требования меняются из-за того, что заказчиков несколько и они не могут договориться между собой (что тоже бывает, итс лайф 🤷♀️🤷), находите стейкхолдера, который имеет большее влияние на ту часть бизнеса, в которой планируется внедрять решение.
В этом случае вы как бы эскалируете проблему на специалиста, который сможет повлиять на достижение компромисса между заказчиками.
4️⃣ Фиксируйте результаты изменения требований
Помимо фиксации изменений в документации, обязательно выносите факт изменения внутри решения до проектной команды.
Также вносите комментарии в задачи и указывайте согласующих стейкхолдеров, чтобы заинтересованные лица всегда имели доступ до актуальной информации о статусе и наполнении задач для проектирования решения.
Старайтесь не воспринимать подобные ситуации как личную неудачу, а смотрите на них, как на опыт.
😊 Благодаря опыту мы растём, как специалисты, и можем управлять ситуацией в случае её повторения.
😊 А ещё на собеседованиях часто спрашивают про “ваши факапы на работе”.
С гордостью сможете рассказать, как справились с ситуацией, когда требования к ПО изменились, и как это повлияло на вашу предусмотрительность в дальнейшем. | 640 |
| 15 |  ⚡ Требования изменились ⚡
Даже если требования были хорошо собраны и согласованы, в какой-то момент они могут стать неактуальными. И это нормальная часть работы аналитика.
Причины обычно делятся на две группы:
🔹 Внутренние
Например:
• заказчик изменил решение;
• требования были поняты неоднозначно;
• разработка реализовала задачу иначе.
🔹 Внешние
Например:
• изменилось законодательство;
• поменялись бизнес-процессы;
• проект или интеграция потеряли актуальность.
Чтобы снизить риск потери актуальности требований, аналитику важно⤵️
1️⃣ Фиксировать итоги встреч письменно
После обсуждений лучше отправлять краткое резюме с договорённостями, решениями и открытыми вопросами на согласование. Это помогает избежать ситуаций, когда участники встречи по-разному запомнили договорённости.
2️⃣ Поддерживать документацию актуальной
Любые изменения важно сразу отражать в ТЗ, спецификациях и других артефактах. Команда должна работать с актуальной версией требований.
3️⃣ Не дублировать требования в разных местах
Чем больше копий требований существует, тем сложнее поддерживать их в актуальном состоянии. Лучше хранить единый источник документации и ссылаться на него из задач.
4️⃣ Обсуждать требования с командой
Недостаточно просто передать документацию. Грумминги и совместные обсуждения помогают заранее выявить вопросы, противоречия и снизить количество ошибок ещё до начала разработки.
Изменение требований — стандартная практика в проектах.
Главное — выстроить процесс так, чтобы быстро адаптироваться к изменениям и сохранять контроль над требованиями 👍
#hardGetAnalyst | 629 |
| 16 |  📚 «12 недель в году» — книга о том, как перестать жить в режиме «успею потом» и начать действительно двигаться к целям.
Авторы предлагают систему, в которой год условно превращается в 12 недель. За счёт более короткого горизонта планирования появляется больше фокуса, задачи меньше откладываются и становится проще переходить к действиям.
Книга особенно откликнется тем, кто любит «включаться» только перед дедлайном 😅
➡️ Главная мысль книги — большинство людей не ленивы, а просто отвлекаются, растягивают сроки и откладывают важное на потом. Но когда времени остаётся мало, внезапно находится энергия и получается закрыть огромное количество задач.
Авторы объясняют, как выстроить такой рабочий ритм и сделать его частью системы.
В книге много практики: планирование, работа с приоритетами, система оценки прогресса и подходы, которые помогают меньше уходить в прокрастинацию 👌
#hwGetAnalyst | 684 |
| 17 |  С началом новой рабочей недели 🙌 | 655 |
| 18 |  +5Когда компания выбирает «Дизайн REST API» для своей команды: опыт корпоративного обучения ✅
Часто на курсы в GetAnalyst приходят не отдельные специалисты, а сразу несколько человек от компании.
Так на программу «Дизайн REST API» попала Анастасия: её и коллег из разных департаментов направили на корпоративное обучение, чтобы усилить навыки работы с API.
Особенно ценно, что Анастасия уже работала с REST API до курса.
Поэтому в отзыве — не просто впечатления новичка, а взгляд специалиста, который смог сравнить обучение со своей реальной практикой и увидеть, что можно улучшить в своей работе.
#студентыGetAnalyst ➡️ | 827 |
| 19 | Мы собираем требования и проектируем системы с внутренними подсказками:
✔️ Пользователям необходимо решить такую-то проблему, для этого система...
✔️ Я, как пользователь, хочу, чтобы....
✔️ Чтобы пользователь получил результат, ему необходимо выполнить следующие шаги...
Идем по прямым сценариям 📈
А работаете ли вы с обратной стороной проектирования? Помните про реальный мир? Как не должна себя вести в случае, если на нее нападут миллионы разъяренных пользователей в погоне за маркетинговой акцией? Или если сервера откажут? Много внимания уделяете этим вопросам?
И любимый вопрос: "Что тут может пойти не так?" 🙃 | 750 |
| 20 | Техники сбора требований ✍️
От того, насколько точно получится выявить потребности бизнеса, пользователей и команды, зависит дальнейшая реализация продукта, фичи или целого проекта.
Требования помогают:
• определить границы проекта;
• понять цели и ожидания стейкхолдеров;
• зафиксировать, что именно нужно реализовать;
• договориться с заказчиком и командой.
Собрали основные техники, которые помогают аналитику собирать требования ⤵️
1️⃣ Интервью
Одна из самых популярных техник. Аналитик заранее готовит вопросы и общается с заказчиком, пользователями или другими участниками процесса. Интервью может быть как индивидуальным, так и групповым.
Например, если нужно доработать личный кабинет сотрудника тех поддержки, аналитик уточняет:
— какие действия он выполняет чаще всего;
— где возникают сложности;
— какие данные важно видеть в первую очередь.
Интервью помогает понять контекст: почему появилась задача и какую проблему нужно решить.
2️⃣ Анкетирование
Подходит, когда нужно собрать информацию от большой группы людей. Например, если системой пользуются десятки сотрудников из разных отделов или миллионы пользователей.
В анкете могут быть:
• закрытые вопросы с вариантами ответа;
• открытые вопросы, где человек отвечает самостоятельно.
Например:
«Какие действия в системе занимают у вас больше всего времени?»
«Оцените удобство интерфейса от 1 до 5»
3️⃣ Наблюдение
Аналитик наблюдает, как пользователь работает в реальной среде:
• какие шаги выполняет;
• где задерживается;
• что делает вручную;
• какие дополнительные таблицы или инструменты использует.
Техника особенно полезна, когда пользователю сложно подробно описать процесс или часть действий выполняется автоматически и уже не замечается.
Например, сотрудник говорит, что «просто оформляет заявку», а на практике копирует данные из трёх систем, сверяет их в Excel и только потом вносит в программу.
4️⃣ Анализ документации
Аналитик изучает существующие материалы:
регламенты компании, инструкции, ТЗ, описания процессов, API-документацию внедренных систем, схемы.
Так он быстрее погружается в предметную область, может понять ограничения и увидеть, как процесс устроен сейчас.
Например, перед интервью с сотрудниками заказчика изучить текущие регламенты работы сотрудников, чтобы вопросы были точнее.
5️⃣ Mind Map - как инструмент для сбора требований
Карта мыслей (Mind Map) помогает разложить информацию по блокам и увидеть связи между частями системы или процесса. Её удобно использовать на старте проекта, когда информации много и она ещё не структурирована.
Например, при проектировании интернет-магазина можно выделить основные ветки:
каталог, корзина, оплата, доставка, личный кабинет, уведомления.
Затем детализировать каждую.
6️⃣ Мозговой штурм
Подходит для генерации идей и поиска вариантов решений.
В обсуждении могут участвовать аналитики, заказчики, разработчики, дизайнеры и пользователи.
На первом этапе важно собрать как можно больше идей, а уже потом оценивать их по пользе и реализуемости.
Например, если команда ищет способ снизить количество ошибок при оформлении заявки, на штурме могут предложить:
• автозаполнение полей;
• подсказки в интерфейсе;
• проверки данных;
• изменение процесса согласования.
7️⃣ Анализ конкурентов
Помогает понять, как похожие задачи решены в других продуктах.
Аналитик изучает:
• функциональность;
• пользовательские сценарии;
• интерфейсные решения;
• ограничения и особенности продукта.
Например, при проектировании формы онлайн-записи можно посмотреть, как этот процесс реализован у других сервисов: какие поля используются, как устроено подтверждение записи и какие уведомления получает пользователь.
В реальной работе аналитик редко использует только одну технику. Чаще всего хороший результат даёт именно комбинация подходов. Сначала изучаются документы, затем проводятся интервью, после этого строится mind map, а детали уточняются через наблюдение или анкетирование.
Чем больше техник аналитик умеет применять на практике, тем точнее он выявляет реальные потребности бизнеса и пользователей ✅ | 654 |
