Преобразование компетенций бизнес-аналитика в ИТ с развитием ИИ-технологии
"ИИ — это не просто «еще один инструмент» для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.
В статье рассматриваются:
- Преобразование компетенций и ежедневной работы БА:
- Автоматизация рутины (где ИИ — «гипер-инструмент»).
- Появление новых компетенций (супер-сил).Сокращение численности команд.
- Примеры и тренды в российских IT-компаниях.
- Сложности перехода к новой логике."
Читать статью
"ИИ — это не просто «еще один инструмент» для бизнес-аналитика (БА), как когда-то им были MS Visio или Jira. Это фундаментальный сдвиг, который меняет саму суть работы, ценность специалиста и структуру команд.
В статье рассматриваются:
- Преобразование компетенций и ежедневной работы БА:
- Автоматизация рутины (где ИИ — «гипер-инструмент»).
- Появление новых компетенций (супер-сил).Сокращение численности команд.
- Примеры и тренды в российских IT-компаниях.
- Сложности перехода к новой логике."
Читать статью
Для чего нужно моделировать процессы
Любой бизнес- или системный процесс, который подлежит анализу, можно зафиксировать разными методами. Например:
💭 проговорить устно,
📝 оформить в текстовом виде или структурировать в таблицах.
Однако наиболее универсальным и наглядным способом, который одинаково хорошо воспринимается заказчиками, разработчиками и архитекторами, считается представление процессов через модели
.
Модель процесса — это совокупность диаграмм и сопроводительных материалов, описывающих последовательность работ или действий, а также внешние и внутренние факторы, влияющие на выполнение этих шагов.
Ключевой результат процессного моделирования — это чёткая визуализация порядка операций и условий, обеспечивающих достижение целевого результата.
Используя моделирование процессов, аналитик получает:
1️⃣ наглядный формат фиксации текущего состояния (AS IS) функционирования системы или бизнеса;
2️⃣ ясное представление целевого состояния (TO BE) процесса после внедрения планируемых изменений;
3️⃣ диаграммы, отображающие участников, входные и выходные данные, последовательные шаги и возможные альтернативные сценарии развития.
В IT-проектах моделирование процессов — одна из ключевых компетенций аналитика. Это инструмент, который позволяет эффективно взаимодействовать с представителями разных ролей: от бизнес-заказчиков до системных архитекторов. Чёткое и лаконичное донесение структуры процессов в виде моделей ускоряет согласование требований и проектирование решения.
Любой бизнес- или системный процесс, который подлежит анализу, можно зафиксировать разными методами. Например:
💭 проговорить устно,
📝 оформить в текстовом виде или структурировать в таблицах.
Однако наиболее универсальным и наглядным способом, который одинаково хорошо воспринимается заказчиками, разработчиками и архитекторами, считается представление процессов через модели
.
Модель процесса — это совокупность диаграмм и сопроводительных материалов, описывающих последовательность работ или действий, а также внешние и внутренние факторы, влияющие на выполнение этих шагов.
Ключевой результат процессного моделирования — это чёткая визуализация порядка операций и условий, обеспечивающих достижение целевого результата.
Используя моделирование процессов, аналитик получает:
1️⃣ наглядный формат фиксации текущего состояния (AS IS) функционирования системы или бизнеса;
2️⃣ ясное представление целевого состояния (TO BE) процесса после внедрения планируемых изменений;
3️⃣ диаграммы, отображающие участников, входные и выходные данные, последовательные шаги и возможные альтернативные сценарии развития.
В IT-проектах моделирование процессов — одна из ключевых компетенций аналитика. Это инструмент, который позволяет эффективно взаимодействовать с представителями разных ролей: от бизнес-заказчиков до системных архитекторов. Чёткое и лаконичное донесение структуры процессов в виде моделей ускоряет согласование требований и проектирование решения.
Вижу — значит, понимаю: зачем нужны прототипы
Прототип — это способ увидеть проблему до того, как она съест ваш бюджет, сроки и репутацию.
➡️ Когда делать прототип?
🔚 У вас есть непонятные требования
🔚 Клиент говорит «Узнаю, когда увижу»
🔚 Риски — высокие, цена ошибки — ещё выше
🔚 Интерфейс критичен для продукта
🔚 Нужно быстро получить фидбек
➡️ Какие бывают прототипы?
🔚 Одноразовый — быстрое прояснение требований, наброски экранов
🔚 Эволюционный — постепенная сборка функционала, приближающаяся к финальному продукту
🔚 Экспериментальный — проверка архитектуры, производительности, технической реализуемости
➡️ Прототип это не Продукт
Важно: прототип — это НЕ MVP, не финал, не половина разработки. Это инструмент. И да, его можно сделать в PowerPoint, Figma или даже на бумаге. Главное — не застревать в отрисовке, а быстро получать обратную связь.
➡️ Этапы:
🔚 Сценарии использования
🔚 Карты экранов / диалогов
🔚 Вайрфрейм
🔚 Фидбек от пользователей
🔚 Дизайн интерфейса
Чем больше итераций — тем меньше сюрпризов.
➡️ Риски при работе с прототипами
🔚 Заигрались и ушли в перфекционизм
🔚 Клиенты начинают думать, что это уже рабочая система
🔚 Архитектура не выдержит масштабирования
🔚 Команда тратит больше времени на отрисовку, чем на анализ
Прототип — это способ увидеть проблему до того, как она съест ваш бюджет, сроки и репутацию.
Важно: прототип — это НЕ MVP, не финал, не половина разработки. Это инструмент. И да, его можно сделать в PowerPoint, Figma или даже на бумаге. Главное — не застревать в отрисовке, а быстро получать обратную связь.
Чем больше итераций — тем меньше сюрпризов.
Please open Telegram to view this post
VIEW IN TELEGRAM
📑 Документация как инструмент управления проектом
В статье аналитик Банка ДОМ. РФ, Василий Белькович, делится опытом построения системы документации для сложной корпоративной IDM-системы.
Описывает цели создания такой системы и представляет подход к разделению документации на три части, объясняя, как каждая из них помогает решать поставленные задачи.
Читать статью
В статье аналитик Банка ДОМ. РФ, Василий Белькович, делится опытом построения системы документации для сложной корпоративной IDM-системы.
Описывает цели создания такой системы и представляет подход к разделению документации на три части, объясняя, как каждая из них помогает решать поставленные задачи.
Читать статью
Документирование — это мощнейший инструмент системного мышления.
Мы часто думаем: «Документацию никто не читает, значит, ее можно не писать»
Это самое частое оправдание. Но в нем кроется ошибка: ценность не только в готовом документе, но и в процессе его создания.
Когда вы пишете, вы заставляете свой мозг перейти от хаотичных мыслей к строгой структуре. Это как рассказать кому-то сложную тему — именно в момент объяснения вы сами начинаете понимать ее глубже.
3 причины писать «для себя»
😻 Выявление «дыр» и противоречий
Пока требование крутится у вас в голове, оно кажется идеальным. Но стоит начать излагать его на бумаге, как сразу всплывают вопросы:
🦊 «А что будет, если пользователь нажмет отмену?»
🦊 «Как система отреагирует на пустое значение?»
🦊 «Мы же не забыли про валюту в этом расчете?»
🧡 Вывод: Документирование — это стресс-тест для ваших требований.
😻 Структурирование информации
Наша память нелинейна. В ходе интервью мы получаем информацию кусками: из диалога с экспертом, из письма, из старой документации.
Процесс написания — это сбор паззла. Вы группируете разрозненные данные в логические блоки: функциональные требования, бизнес-правила, сценарии.
🧡 Вывод: Голова освобождается от хранения информации, и вы можете сконцентрироваться на анализе.
😻 Создание «якоря» для памяти и коммуникации
Через месяц или даже неделю вы не вспомните, почему было принято то или иное решение. Записав ход мыслей и аргументы, вы создаете надежный источник правды, к которому всегда можно вернуться.
🧡 Вывод: Документация — это внешняя память аналитика, которая не подводит.
Как применять на практике?
Не обязательно сразу писать полноценный BRD. Начинайте с малого:
🦊 Конспектируйте встречи. Не просто записывайте решения, а тезисно формулируйте проблему и аргументы.
🦊 Рисуйте схемы. Набросайте от руки блок-схему процесса, который пытаетесь понять. Это сразу выявит логические разрывы.
🦊 Ведите личные заметки. Используйте любой удобный формат: Markdown-файл, Miro-доска, OneNote. Пишите так, как понятно вам
Мы часто думаем: «Документацию никто не читает, значит, ее можно не писать»
Это самое частое оправдание. Но в нем кроется ошибка: ценность не только в готовом документе, но и в процессе его создания.
Когда вы пишете, вы заставляете свой мозг перейти от хаотичных мыслей к строгой структуре. Это как рассказать кому-то сложную тему — именно в момент объяснения вы сами начинаете понимать ее глубже.
3 причины писать «для себя»
Пока требование крутится у вас в голове, оно кажется идеальным. Но стоит начать излагать его на бумаге, как сразу всплывают вопросы:
Наша память нелинейна. В ходе интервью мы получаем информацию кусками: из диалога с экспертом, из письма, из старой документации.
Процесс написания — это сбор паззла. Вы группируете разрозненные данные в логические блоки: функциональные требования, бизнес-правила, сценарии.
Через месяц или даже неделю вы не вспомните, почему было принято то или иное решение. Записав ход мыслей и аргументы, вы создаете надежный источник правды, к которому всегда можно вернуться.
Как применять на практике?
Не обязательно сразу писать полноценный BRD. Начинайте с малого:
Please open Telegram to view this post
VIEW IN TELEGRAM
Как правильно формулировать нефункциональные требования
"За свою карьеру я написала не одну сотню требований и поняла такую вещь — самые важные и самые незаметные, это блок нефункциональных требований."
Перейти к статье
"За свою карьеру я написала не одну сотню требований и поняла такую вещь — самые важные и самые незаметные, это блок нефункциональных требований."
Перейти к статье
👍2❤1
👍2
❤1👍1
Примеры бизнес-применения модели C4
Хорошая статья про модель С4, которая набирает популярность с каждым днем
Перейти
Хорошая статья про модель С4, которая набирает популярность с каждым днем
Перейти
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Автор, Семен, solution-архитектор в Газпромбанке, поднимает в статье вопрос разорванного ландшафта компании — ситуацию, когда бизнес и IT существуют в параллельных вселенных, и делится опытом, как это можно "починить".
📎 Читать статью
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
«Мы думали, это займет три дня»: как сократить разрыв между бизнесом и IT
Привет! Меня зовут Семен, я solution-архитектор в Газпромбанке. За девять лет в разработке я насмотрелся на одну проблему, которая встречается практически везде. Хочу обсудить разорванный ландшафт...
Как аналитику разобраться в legacy-системе без документации
Статья основана на практическом опыте, в нашей школе мы не просто даем теорию, а любим делиться тем, что действительно работает на проектах.
Перейти к статье
Статья основана на практическом опыте, в нашей школе мы не просто даем теорию, а любим делиться тем, что действительно работает на проектах.
Перейти к статье
Хабр
Как аналитику разобраться в legacy-системе без документации
Приветствую всех! С вами старший системный аналитик, эксперт онлайн-школы по системному анализу Ольги Пономарёвой System Analyst. Статья основана на практическом опыте, в нашей школе мы не просто даем...
Один Swagger вместо сотни страниц Confluence: как в Рунити навели порядок в API-документации
Сложность: ★☆☆ | Время чтения: 9 мин | Автор: Маргарита Сорочинская, технический писатель отдела архитектуры в Рунити
Автор рассказывает об опыте описания API целиком в Swagger, без дублирования в Confluence, а также делится пошаговой инструкцией документирования и загрузки на Git.
📎 Читать статью
Сложность: ★☆☆ | Время чтения: 9 мин | Автор: Маргарита Сорочинская, технический писатель отдела архитектуры в Рунити
Автор рассказывает об опыте описания API целиком в Swagger, без дублирования в Confluence, а также делится пошаговой инструкцией документирования и загрузки на Git.
📎 Читать статью
Как нанимают fullstack-аналитиков: инсайты от работодателя
Автор статьи подробно описывает:
- этапы отбора кандидатов;
- на что обращает внимание при просмотре резюме и на собеседовании;
- и делится готовым планом интервью на позицию Fullstack-аналитика.
Также в статье есть примеры «фильтров», по которым некоторые работодатели могут отсеивать резюме. Но не стоит воспринимать это как универсальное правило — это лишь одна точка зрения на большом и разнообразном рынке труда.
Статья может помочь тем, кто готовится к собеседованиям — будет полезно заглянуть в голову рекрутера.
📎 Читать статью на VC
Автор статьи подробно описывает:
- этапы отбора кандидатов;
- на что обращает внимание при просмотре резюме и на собеседовании;
- и делится готовым планом интервью на позицию Fullstack-аналитика.
Также в статье есть примеры «фильтров», по которым некоторые работодатели могут отсеивать резюме. Но не стоит воспринимать это как универсальное правило — это лишь одна точка зрения на большом и разнообразном рынке труда.
Статья может помочь тем, кто готовится к собеседованиям — будет полезно заглянуть в голову рекрутера.
Please open Telegram to view this post
VIEW IN TELEGRAM
vc.ru
КАК НАХОДИТЬ СИЛЬНЫХ АНАЛИТИКОВ: ЧЕСТНЫЙ РАЗБОР СОБСТВЕННОГО ПОДХОДА
Эта публикация посвящена одному из самых сложных процессов в компании – подбору сотрудников. А если быть точным, то ещё более сложному – поиску аналитика в команду.
❤2👍2