Как нарисовать свою карьерную карту, когда всё надоело?

Знакомо чувство, когда работа не радует, но и непонятно, куда двигаться?

Канал «Уставшие» создал пошаговый алгоритм, который превращает этот тупик в понятную карту с вариантами.

Я адаптировала этот метод в готовый промт, который проведет вас по всем шагам. Вам нужно только честно отвечать.

В чем суть метода? Краткий конспект:

1. Диагностика настоящего.

Зачем вы на самом деле держитесь за текущую работу?

Примеры для вдохновения:
- На текущем месте понятные задачи и процессы
- Здесь меня ценят и уважают
- Стабильность и предсказуемость

2. Опора на силу.

Фиксируем 3 главных достижения за карьеру и формулируем, «за что вас купят всегда». Это ваш фундамент.

Пример для вдохновения:
Стала функциональным архитектором уникальных систем для тепло- и водоканалов

3. Профильная экспертиза

В чем ты профи? За что тебя будут покупать работодатели всегда?

Пример для вдохновения:
'Я классный team-lead системных/бизнес-аналитиков и функциональный архитектор, создающий уникальные решения для автоматизации основных процессов в тепло- и водоснабжении'

4,5 Усиливаем свои преимущества

6.Поиск векторов. Самый важный и сложный этап.

Вы не меняете всё и сразу. Вы смотрите:
* Куда можно перейти, не меняя специализацию (другие отрасли).
* Куда можно перейти, не меняя отрасль (другие специализации).
* Что будет, если остаться в своей комбинации «отрасль + спец.» (рост).
* И только при наличии финансовой подушки — вариант «меняю всё».

7-8. Люди — это новая валюта.
Карьеру в 2026+ строят через людей.
Алгоритм учит, как провести аудит своих контактов
и превратить знакомых в лоббистов - тех, кто знает вашу репутацию и захочет помочь.

9,10. Считаем деньги и риски.
К каждому варианту перехода прикрепляем реалистичную вилку з/п и список рисков (падение дохода, потеря статуса, долгий поиск).
Для анализа рыночной стоимости можно использовать промт и связи с лобистами.

11. Финальная карта.
Все варианты сводятся в таблицу и раскрашиваются в
- зеленый (цель),
- желтый (запасной аэродром)
- красный (не наш путь).
Получается понятный план действий на 1-2 года.

Как это работает?

Метод запрещает мечтать абстрактно. Он заставляет опираться на факты (ваши навыки), связи (ваших людей)
и цифры (вашу будущую зарплату и риски).

P.S. Метод сложный, требует честности перед собой и времени.
Но он дает то, чего не хватает — ясность.
Рекомендую делать его не за один вечер, а растянуть на неделю, обдумывая каждый шаг.
Крутой AI-аналитик

Недавно мне прислали ссылку диалог с ИИ, в котором пользователь очень не доволен ответом.
Это классический антипример правильного диалога с ИИ.
На скрине ответ от дипсик на конкретный вопрос по той же теме.

Как НЕ нужно разговаривать с ИИ (если вам важны факты)
❌ Не задавайте вопрос без указания типа истины.
«Кто победил?» — это не вопрос для ИИ.
Уточните: официальный результат по регламенту, данные первичного источника, статистика на дату.
❌ Не подавайте источники разного уровня как равнозначные.
YouTube, телекомментарии и агрегаторы ≠ официальные протоколы. ИИ не сам выбирает, чему верить — вы должны задать иерархию.
❌ Не используйте многозначные термины без определения.
Слово «финал» в спорте может означать матч по регламенту, последнюю игру турнира или просто кульминацию. Зафиксируйте значение.
❌ Не позволяйте ИИ переходить от проверки к объяснению.
Если вы не остановите модель фразой: «Только факт, без интерпретаций», она начнёт строить правдоподобную историю — даже если она ложная.
❌ Не эскалируйте эмоционально.
Фразы вроде «ты врёшь» переводят ИИ в режим сглаживания конфликта, а не уточнения данных.
—
ИИ — не собеседник. Это инструмент точности.
Чем строже промт — тем чище факт.

Промт для получения правильного ответа:

Дай официальный результат турнира “Canada Cup 1981” по регламенту организатора, с указанием:
– списка участников
– формата турнира
– официального финального матча
Источники: только первичные (IIHF / Hockey Canada / протоколы).
Без интерпретаций, мифов и телекомментариев.

+ не забывайте включать режим поиска

А у вас бывает, что вы недовольны ответом от ИИ?
Крутой AI-аналитик

Кто смог выполнить задание на тренажере?

Я смогла пройти только с подсказкой.

Прислать промт?
👍 промт нужен
🤪 промт не нужен

Проектные риски из моей практики

Денис Бесков выделил 11 проектных рисков:
1️⃣ Построение системы, которая решает «не ту задачу»
2️⃣ Неприемлемая экономическая эффективность проекта (ROI < 0)
3️⃣ Непринятие системы пользователями
4️⃣ Неправильный выбор класса системы или вендора
5️⃣ Эскалация сроков и бюджета (scope creep)
6️⃣ Архитектурная несостоятельность решения
7️⃣ Конфликты со стейкхолдерами и управленческие кризисы
8️⃣ Регуляторные, юридические, комплаенс-риски
9️⃣ Низкое качество данных и решений на их основе
🔟 Рост стоимости изменений после внедрения
1️⃣1️⃣ Локальные дефекты реализации и бесконечные доработки

Поделюсь своим проектным опытом
❌ 3. Непринятие системы пользователями
📍2 заказчика, которым нужны шашечки, а не ехать

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

📍 Автоматизация Водоканалов
Мастера саботировали работу у канавы на планшете:
• холодно
• руки грязные
• камера не работает (затирали наждачной)
• «это невозможно»
Причина — система усиливала контроль за их работой. Им нужно было фиксировать на планшете каждую выполненную операцию с указанием времени начала и окончания, а также прикладывать фото с места проведения работ
Решение:
жёсткий контроль главным инженером + принятие работы только по результату аудита действий в системе.
Итог: система эксплуатируется по филиалам Водоканалов России.

❌ 6. Архитектурная несостоятельность

Автоматизация контроля приборов учета зависела от структуры точек учета из биллинга, который внедрялся параллельно.
Финансирование биллинга приостановлено → структуры нет → вручную заносить никто не стал → пром-запуск сорван.
Вывод: без данных система бесполезна, успешно пройденные тестовые сценарии мало значат.

❌ 7. Конфликты со стейкхолдерами
Смена топ-руководства =
- остановка развития продукта
- повторный аудит решений
- необходимость каждый раз заново доказывать ценность

Частые смены руководства иногда вынуждают замораживать развитие продукта.

❌ 10–11. Рост стоимости изменений и локальные дефекты

Взяли на развитие систему другого подрядчика.
Задача: разработать 3 новых модуля к уже существующей системе.
В процессе вскрылась несостоятельность архитектуры БД:
➖между сотрудником и подразделением не было внешнего ключа
➖можно было удалить подразделение → пользователь из удалённого подразделения не проходил аутентификацию
Пришлось за наш счёт править ядро, хотя разработка новых модулей оценивалась без затрат на такой сюрприз.
Мораль: исходная архитектура чужой системы часто дороже новых функций.


Большинство проектных рисков — не технические.
Они про людей, данные, управление и мотивацию.
Код почти всегда можно переписать.
Непринятие пользователями, хаос управления и дефекты данных — дороже всего.
Крутой AI-аналитик

Итоги 4-го потока марафона «ТЗ за 7 шагов»: ключевые инсайты и эволюция методологии

Четвертый поток марафона по созданию технического задания с помощью ИИ завершается 10.02. Этот поток стал по-настоящему исследовательским: фокус сместился с вопроса «как делать?» на глубокое обсуждение «почему именно так?». Благодаря диалогу с практикующими аналитиками мы смогли выявить точки роста в методологии и зафиксировать конкретные улучшения для следующих потоков.

Ключевые темы обсуждения и запланированные изменения:

1. Графическая нотация: от единого стандарта — к инструментальной гибкости

Что обсуждали: 
Инструмент Graphviz, предложенный для построения контекстных диаграмм, оказался неидеален для всех. Участники отмечали недостаток визуальной наглядности в процессе правки и сложность быстрой итерации.
Что меняем в промтах: 
В следующих потоках мы добавляем альтернативные варианты на выбор: PlantUML (для любителей текстового описания) и Yed Graph Editor (для тех, кому важен интерактивный drag-and-drop).

Цель — повысить скорость и комфорт моделирования.

2. Четкое разделение логики: Use Cases, Интеграции, Utility-функции
Что обсуждали: 
Возникла важная дискуссия о природе функций. Стало очевидно, что не все требования стоит упаковывать в сценарии использования (Use Cases). Необходима предварительная классификация по цели:
- Действие, направленное на достижение цели конкретной роли пользователя (UC).
- Обеспечение обмена данными с внешними системами (Интеграция).
- Поддержка внутренних процессов или общие сервисные функции (Support/Utility).

Что меняем в промтах: 
вводим структурированное разделение:
-Пользов ательские Use Cases — строго для целей акторов.
- Интеграционные сценарии — выносим в отдельный промт внутри блока интеграции.
- Support/Utility функции — исключаем из Use Cases и описываем в соответствующем разделе. Это устранит путаницу и повысит логическую целостность документа.

3. Разделение ответственности: Функциональные и Нефункциональные требования

Что обсуждали: 
Обсудили дублирование измеримых параметров между ФТ и НФТ.

Что меняем в промтах: 
Четко разводим ответственность:
- В ФТ убираем количественные метрики. Акцент — на саму функцию, ее тип (UC/Utility/Support) и привязку к целям из Opportunity Canvas.
- В НФТ концентрируем все измеримые атрибуты качества.

4. Формирование Функциональной Архитектуры (ФА)

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

Что меняем в промтах: 
добавляем отдельный, целенаправленный промт на шаге работы с требованиями. Его задача — сгенерировать вариант функциональной архитектуры, который напрямую вытекает из целей и метрик Opportunity Canvas, обеспечивая прослеживаемость от бизнес-задачи до структуры компонентов.

5. «Теория в один клик»
Что обсуждали: в процессе работы часто требовалось быстро освежить в памяти теоретические основы (например, правила построения контекстной диаграммы или классификацию НФТ.

Что дополняем: в тексты заданий напрямую интегрируем ссылки на соответствующие статьи из библиотеки Systems Education:
- НФТ и атрибуты качества
- Контекстная диаграмма

Что уже доработано «на лету»:
- Обновлены промты для проектирования модели данных с учетом рекомендаций по трем нормальным формам для реляционный БД
- Настроены проекты в Qwen для автоматизации обратной связи по всем 7 шагам марафона.
- Разработан и апробирован на учебном кейсе участника пилотный промт для описания Функциональной Архитектуры.

Итог:
Четвертый поток наглядно показал, что лучшие методологические улучшения рождаются из практики и открытой дискуссии с профессиональным коммьюнити. Спасибо всем, кто задавал вопросы — именно так создается живой и эффективный инструментарий аналитика.

Следующий поток стартует в феврале — надеюсь успеть внести изменения в промты.
Если ваша цель — создавать четкие, структурированные и технологически выверенные ТЗ с помощью ИИ, присоединяйтесь!

5ый поток марафона c 18.02

Всем привет, сегодня обследование в налоговой инспекции - будем обсуждать возможности применения ИИ в их работе

Коллеги, всем привет!

В рамках подготовки к 5-ому потоку марафона ТЗ с помощью ИИ за 7 шагов я дополнила материал полезным инструментом.

Разработала инстуркцию и промпты, которые позволяют строить контекстные диаграммы в редакторе Yed Graph Editor.

Чем этот подход лучше связки с Graphviz?

1. Ключевое отличие — в возможности гибкого пост-редактирования без написания кода.
2. Диаграмма генерируется на основе XML от ИИ.
3. Визуальную часть (расположение элементов, стили, связи, выравнивание подписи) можно легко скорректировать стандартным UI редактора Yed. Также есть кнопка, которая позволяется красиво расположить элементы в 1 клик.
4. Готовый результат снова выгружается в XML для хранения или дальнейшего использования и можно использовать в качестве обучения для ИИ.

Спасибо Вике - участнице 4ого потока.
Крутой AI-аналитик

Всем привет, опять готовлюсь к семинару на тему применения ИИ: теперь для БА и СА. Формат 2 лекции + практика по написанию промтов.

Нравится делать презентации - не могу остановиться и перейти к следующей.
Крутой AI-аналитик

К сожалению, не получится. Данный семинар готовлю под заказ клиента.

👻 Задача на логику: «Отель с призраком»
Прокачиваем навык работы с противоречивыми требованиями

📖 Вводная
Вы — системный аналитик в компании, разрабатывающей систему управления отелем. К вам приходит владелец с необычной проблемой:

Заказчик:
«У нас в отеле есть номер 404. По легенде там живёт призрак. 80% постояльцев просят поселить их именно туда — ради острых ощущений и фото для соцсетей. Но 20% гостей, узнав, что им достался этот номер, требуют срочного переселения и грозят судом за моральный ущерб.

Бронирования через агрегаторы (Суточно.ру, Ostrovok) тоже идут, и там люди не знают, какой номер получат до заезда. Я хочу, чтобы ваша система решила эту проблему».

🎯 Бизнес-требование (дословно):
«Сделайте так, чтобы те, кто хочет призрака — получали номер 404, а те, кто боится — никогда в него не попадали. Но при этом мы не должны терять бронирования через агрегаторы и не можем нарушать их правила».

🔍 Задание:
Вам нужно предложить логику работы системы, которая удовлетворит это требование.

Проработайте:
1. Как будет работать алгоритм распределения номеров? (шаги, условия)
2. Какие данные нужно собирать о гостях?
3. Как быть с бронированиями через агрегаторы, где вы не можете спросить у гостя про призрака до оплаты?

⚠️ Важно учесть:
— В отеле 100 номеров, только один «проблемный» (404)
— Система должна работать автоматически
— Нельзя просто убрать номер 404 из продажи — владелец теряет деньги
— Агрегаторы не дают собирать кастомные поля при бронировании

💡 Чек-лист для самопроверки:
— Ваш алгоритм минимизирует риск заселения «боящегося» в 404?
— Номер 404 при этом не простаивает?
— Решение работает в условиях неполных данных (агрегаторы)?
— Не требует доработок со стороны агрегаторов?

Если пост наберет 30 реакций (лайки и комментарии), пришлю разбор решения от ИИ.
Крутой AI-аналитик