😰 Уволить или обучать? 😰

Жёсткий, но очень честный вопрос для любого руководителя. Отвечаю.

Проблема не всегда в том, что человек «чего-то не знает».
Есть вещи, которые обучением почти не лечатся.


✅ Ошибся, признал и пришёл с вариантом исправления. Или обсудить, как такое не допустить в будущем?
Обучать.
Потому что ошибка — это не катастрофа.
Катастрофа — это когда человек защищает ошибку до последнего, перекладывает ответственность на разработчиков, тестировщиков, заказчика, ретроградный Меркурий и «непонятный контекст».


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


✅ Мало знает, но хочет расти?
Обучать.
Навыки наращиваются: API, интеграции, БД, микросервисы.
Главное, чтобы человек не делал вид, что уже всё знает.


🚩 Ноет, что всё плохо?
Уволить.
Если человек видит риски и аргументирует — это ценно.
Если человек просто разрушает энергию команды и заражает всех ощущением «ничего не получится» — это проблема.
👉 Системный аналитик должен видеть проблемы.
Но зрелый аналитик приносит не только проблему, а ещё и варианты решения.


🚩 Сдал задачу в разработку = снял ответственность.
Уволить.
Потому что аналитик — это не человек, который «написал документ и ушёл». Он связывает бизнес, разработку, тестирование, поддержку.
Если он не помогает команде переводить с бизнесового на разработческий — он не выполняет ключевую часть своей роли.


🚩 Даёт результаты, но токсичен в общении?
Уволить.
Можно быть сильным специалистом, но если после каждого созвона команда выгорает, разработчики боятся задавать вопросы, а тестировщики получают ответы в стиле «ну это же очевидно» — это разрушает рабочую среду.
Высокий уровень экспертизы не даёт права быть токсичным.


🚩 Оспаривает каждое решение?
Уволить.
Если аналитик спорит аргументированно, защищает качество системы и помогает найти слабые места — это плюс.
Если спорит ради спора, чтобы показать свою ценность, саботирует договорённости и не может принять командное решение — это уже не критическое мышление, а управленческая проблема.


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



Я более 7 лет руковожу проектами на 1млн+ пользователей.
Я более 3 лет веду свой бизнес с командой на 20+ человек.
Я не хочу быть вовлеченной в задачи своих сотрудников, сидеть как «курица наседка» и следить за каждым.


👉 Уволить или заменить?
Мой вывод такой:

Обучать стоит тех, у кого не хватает навыков, но есть ответственность, честность, интерес и желание расти.

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

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

❌🤖 Перестаньте использовать ИИ как простой чат-бот: настройте проекты под свои задачи 🤖🚀

Многие работают с нейросетями так:
«Сделай мне диаграмму»
«Напиши Use Case»
«Спроектируй REST API»

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


Но в ИИ есть продвинутая функция — проекты.

📌 Проект — это рабочее пространство под конкретную аналитическую задачу.

Поддерживается в:
ChatGPT
Qwen
Claude
Perplexity
и других инструментах.


✅ Зачем это?
Чтобы один раз настроить правила работы ИИ, загрузить примеры хороших результатов — и больше не собирать контекст с нуля в каждом новом чате.

Проект превращает ИИ из “разового помощника” в настроенный рабочий инструмент под вашу задачу:
▫️ C4-диаграммы
▫️ UML
▫️ Use Cases
▫️ проектирование REST API
▫️ бизнес-требования
▫️ интеграционные сценарии



👉 Например, можно создать проект:
"C4-диаграммы через Structurizr"

И один раз добавить туда:
▫️ системный промпт
▫️ правила генерации диаграмм
▫️ примеры идеального кода
▫️ ваши требования к оформлению схем

После этого вы не объясняете всё заново в каждом новом чате.
Вы просто пишете:
«Сделай C4 Container для медицинской системы»
И получаете результат уже в нужном формате, в который вносите минимум правок.



👉 Пример простого системного промпта под C4, который можно добавить в проект:

Работай как системный аналитик и архитектор ПО с опытом более 10 лет в enterprise проектах.

Твоя задача — проектировать C4-диаграммы в формате Structurizr DSL.

Всегда:
- используй уровни C4: Context, Container, Component, если это уместно;
- явно показывай пользователей, внешние системы, backend-приложения, frontend-приложения, БД, брокеры и API Gateway;
- подписывай протоколы взаимодействия: REST API, GraphQL, WebSocket, Kafka, gRPC и т.д.;
- добавляй краткие описания для систем, контейнеров и связей;
- не придумывай лишние сервисы без необходимости;
- возвращай только готовый Structurizr DSL-код и короткое пояснение к схеме.

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

Дальше добавляете в проект 2–3 примера вашего идеального Structurizr-кода в виде файлов и всё.

Настроенные проекты под разные задачи экономят аналитику не менее 10 часов в неделю.

Не только потому что ИИ «делает работу за вас».
А потому что вы перестаёте каждый раз объяснять ему одно и то же.



👉 Начать можно с одного проекта.
Не нужно сразу настраивать десятки рабочих пространств под все задачи.

Сделайте один проект под то, что чаще всего повторяется в вашей работе: диаграммы, Use Cases, REST API или требования.

И вы быстро почувствуете разницу между “просто спросить у ИИ” и “работать с настроенным инструментом”.


Ещё больше про ИИ для СА в @getanalysts 🤝

#AI_for_analysts #АрхитектураGA

Обучение в Johns Hopkins University было ошибкой 🤡

Я пошла туда с мыслью: «Ну всё, сейчас разберусь, как работает AI, и хотя бы на год закрою вопросы с новым обучением».

А в итоге AI уже тихо переставляет мебель в моих карьерных планах 😄


В апреле я закончила программу Applied Generative AI в Johns Hopkins University.

И не успела нормально выдохнуть после одного семестра, как взяла на следующий Agentic AI.

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


Сейчас я активно использую Claude Code, настраиваю AI-агентов, собираю приложения и экспериментирую на своих задачах.

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

Инструментов много. Возможностей ещё больше.
👉 А в голове местами красивый, но всё-таки хаос.

Хочу его структурировать.
Мне важно понять, как лучше проектировать AI-агентов, как встраивать их в архитектуру больших систем, где они реально полезны и что из этого можно применять в работе аналитика.


А остаться именно в Johns Hopkins решила потому, что мне очень близко, как там дают AI: глубоко, наглядно и через практику.
Собственно, именно так я сама стараюсь строить обучение в GetAnalyst.


Всё самое полезное, как обычно, принесу аналитикам в GetAnalyst ❤️‍🔥

Так что пока отдыхаю, насколько получится.
А с июля снова учёба 🤓


И да, это уже не просто интерес к AI, а новые карьерные планы.