Куда податься начинающим разработчикам

Часто дискутирую на тему, как AI влияет на начинающих разработчиков и как правильно учиться в новых реалиях.

Прочитал приятную статью от создателя htmx – стоит ли сейчас идти в разработчики? Автор говорит: да, и делится своими мыслями.

Первое, о чем говорит автор – нужно самостоятельно писать код. Полностью разделяю эту мысль. Если не писать код, то и читать его не будешь уметь. А во времена AI умение читать код становится ещё более важным навыком. Более того, когда не умеешь писать код – у тебя нет понимания, как делать правильно. В итоге просто не сможешь контролировать то, что разрабатываешь.

При этом AI может быть очень полезен для начинающих. Раньше можно было надолго закопаться в проблеме, даже не зная с какой стороны зайти. AI как раз может помочь – не генерировать за тебя, а подсказать направление. Автор приводит пример AGENTS.md – инструкцию для агента, после которой тот помогает разбираться, а не просто генерирует готовый код.

А вот какие навыки будут важны.

Коммуникативные навыки. С агентом, с людьми, письменная и устная.

Понимание бизнес-домена. Тут понравилась забавная мысль. Со стороны бизнеса сейчас порой слышим: всё, нам не нужны разработчики. Автор немного хихикает: это нам, разработчикам, теперь не нужны люди от бизнеса :)

А если серьезно, то я думаю спрос на разработчиков будет только расти. Мы уже не первый раз проходим подобное: 4GL-языки, визуальное программирование, nocode-платформы. Каждый раз слышали, что теперь-то разработчики не нужны, и каждый раз оказывалось, что нужны и даже больше, чем раньше.

Архитектурные навыки. Но навыки не тех архитекторов, которые не пишут код и считают себя архитекторами, а тот навык проектирования, который со временем появляется у разработчика.

А завершается статья вопросом, как джунам находить работу. Автор считает, что пробиваться через сайты подбора – скорее лотерея. И советует старое доброе: семья, друзья, друзья друзей. Пока читал эту часть статьи подумалось, что еще хорошо могут работать стажировки. Когда компании целенаправленно ищут начинающих инженеров и дают возможность развиваться на настоящих боевых задачах. У нас, например, в Яндексе сейчас идёт набор на стажировки по большому количеству направлений.

В общем, выдыхаем – разработчики всё так же будут нужны.

#ai

Вот и прошёл AI Dev Day. Классное получилось мероприятие. Делюсь выжимкой моего доклада.

Первая часть была посвящена тому, как мы разрабатываем агента в среде разработки. Когда мы начинали, было много скепсиса к агентам, поэтому главной ставкой были фичи, связанные с бесшовным входом в разработку с агентом. Но настоящим вызовом стал адопшен – нужно было сделать так, чтобы агентом начали реально пользоваться. Писали доку, гайдлайны, проводили воркшопы – в общем было очень потно, но в то же время приятно было видеть, как в результате растёт аудиторная метрика.
Ещё один важный момент, влияющий на адопшен, который подтверждается как нашими внутренними исследованиями, так и исследованиями DORA – важно, чтобы были прозрачные политики безопасности, чтобы люди понимали, что можно отправлять в агентов, а что нет.

Вообще агентов сейчас разрабатывают кажется все кому не лень, и при этом по ощущениям не так часто говорят о качестве. Об этом была вторая часть доклада – как подходить к качеству через офлайн и онлайн-метрики на примере еще одного агента для написания запросов к данным.

Для офлайн-метрик мы используем валидационный датасет – прогоняем на нём агента, чтобы не выкатить изменения, которые ухудшают пользовательский опыт.

Но одних офлайн-метрик недостаточно, потому что реальных сценариев сильно больше, чем мы можем собрать в датасете. И говоря уже об онлайн-метриках, важно их строить от сценариев использования. Первое на что смотрим – CJM, так появляются метрики, основанные на пользовательских сценариев. А чтобы сформировать более точечные метрики, мы регулярно разбираем весь фидбек по работе нашего агента – это дорого, но позволяет понимать, что реально происходит в продукте. По результатам таких разборов тоже появляются метрики – например, мы заметили фейковый тул-колинг, пошли разбираться из-за чего такое происходит, а заодно появилась метрика, насколько эта проблема актуальна для наших пользователей.

И ещё заканчивая о метриках – важно не забывать их валидировать, действительно ли метрика измеряет то, что нужно. Иногда об этом забывают, а потом удивляются :)

А кто любит движуху вокруг LLM – 21 марта будет ещё один любопытный митап в офлайн и онлайн форматах.

#devfm #ai

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

Сейчас пробую Ralphex. Очень любопытная штуковина – под капотом используется Claude Code, но поверх накручена полноценная система управления процессом работы агента.

Начинается всё по классике – нужно любым удобным способом составить план выполнения задачи. Можно использовать встроенную команду plan. Качественный план для агента – это важно, а здесь особенно важно, потому что когда процесс запущен – вклиниться и что-то подправить уже не получится.

Далее просто запускаю ralphex и машина начинает шуршать – выполнять план по шагам, отмечать прогресс, писать тесты. Последний этап – код-ревью. Если у вас в наличии Codex – то он призывается для ревью. Вообще забавно наблюдать, когда один агент чехвостит другого.

На самом деле – там много интересного происходит под капотом – рекомендую поэкспериментировать.

#ai #agents

Голосовой ввод – настоящий геймченджер

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

Неоднократно слышал про Handy – с него и начал. В пару кликов всё настроил: выбрал модель, которая будет работать локально, назначил хоткей на включение режима слушания, и в общем-то всё.

Ну что могу сказать – это чудо чудесное, теперь просто не могу остановиться. Последние пару дней все коммуникации с агентами идут через Handy. Из дополнительных приятностей: раньше иногда было лень писать и думал, ааай агент сам разберётся, а потом агент не разбирался и приходилось расхлёбывать – теперь нет никаких проблем, что-то хочешь уточнить – просто продиктуй.

Есть ещё классная фича – постпроцессинг: после транскрибации текст отправляется в LLM и обрабатывается согласно твоему промпту – например, более лаконично переформулировать то, что только что надиктовал, убрать слова-паразиты. И теперь я пошёл дальше – надиктовываю вообще всё. Нужно оставить коммент в таске – надиктовал, нужно написать сообщение в телегу – надиктовал.

Теперь в офисе постоянно приходится сидеть в переговорках, чтобы не мешать рядом сидящим коллегам.

Люто рекомендую 🙂

#постанадиктован

Из маленьких лайфхаков – я перестал пытаться самостоятельно ориентироваться в незнакомых интерфейсах. Открываешь что-то новое, и вместо того чтобы шариться по менюшкам – просто делаешь скриншот и отправляешь агенту. Тот шуршит пару секунд и подсказывает, куда именно тыкать.

На днях настраивал Cloudflare. Кто пользовался – знает, что их панель делали хищники для чужих. Раньше бы полчаса ковырялся по вкладкам. А тут – скрин, в агента, и через несколько секунд пошаговая инструкция, где найти нужное.

Аналогично с Фигмой – я в ней нечастый гость. Нужно было скопировать себе чужой проект, и я понятия не имел, как это делается. Скриншот → агент → готово.

Тот же паттерн кстати с ридмишками проектов. Открываю README, начинаю вчитываться, пытаюсь понять что за проект, как запустить... а потом бью себя по рукам – зачем? Скидываю агенту, и через минуту у меня полная картина: что за проект, как развернуть, какие есть нюансы. И можно задать уточняющие вопросы, если что-то непонятно.

По сути, появился новый навык – не разбираться самому, а делегировать первичное понимание. И это прям очень круто!

#ai #devfm

Время летит – прошло ещё несколько занятий на курсе CTO от Стратоплана. За это время успели посмотреть разные темы: от информационной безопасности до найма и развития ключевых сотрудников.

Но больше всего меня впечатлил блок про финансовый менеджмент и построение финансовых моделей. Обычно, будучи тимлидом, руководителем отдела, ты редко сталкиваешься с деньгами напрямую – бюджеты где-то далеко, P&L кто-то другой считает, а ты управляешь людьми и проектами. Тикеты двигаются, релизы случаются – супер.

У меня эта тема давненько лежала где-то в личном бэклоге – надо бы разобраться, но понятное дело – всегда находится что-то более приоритетное, плюс когда не погружён в тему – непонятно с чего начинать. В общем, сам вряд ли когда возьмёшься.

А тут звёзды сошлись – рассказали на занятиях. Разобрали базовую терминологию – что такое P&L, как устроен управленческий и бухгалтерский учёт, чем они отличаются, какие ещё учёты бывают. Изучили баланс, отчёт о прибылях и убытках. Потом перешли к финансовым моделям, даже попробовали составить фин модель на практике – и тут мозги реально поплавились. С первого раза очень сложно, мало что понятно, но очень интересно.

Скиллы в агентах – часть 1: база

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

Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий.

Модульность
Скилл – это обычная папка. Внутри обязательный SKILL.md – основная инструкция, которую читает агент: что делает скилл, когда его применять и как именно действовать. Рядом можно положить что угодно: референсы, примеры, вспомогательные скрипты, которые агент вызывает по ходу работы.

my-skill/
├── SKILL.md
├── references/
│ └── examples.md
└── scripts/
└── helper.py

В SKILL.md обязателен фронтматтер с двумя полями – name и description.

Progressive disclosure
В отличие от правил (rules) или agents.md, которые грузятся в начале каждой сессии, тело скилла в контекст не попадает. Изначально там только name и description из фронтматтера – буквально пара строк. Агент сам решает, нужен ли скилл под текущую задачу, и только тогда подтягивает содержимое.

Думаю, именно поэтому скиллы набирают такую популярность.

В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте.

Скиллы этой боли лишены. Можно иметь десятки скиллов – и практически нулевую нагрузку на контекст, пока они реально не понадобятся. А значит, в агента можно паковать большое количество экспертизы: как у вас устроены миграции, как правильно собрать релиз, как команда делает код-ревью.

Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию.

В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами.

#devfm #ai

Все ли так классно со скиллами – часть 2

В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни MCP не нужны, скиллы всё заменят. Давайте разбираться.

Skills vs rules/agents.md
Идея звучит соблазнительно: все командные правила кладём в скиллы, агент сам подтянет нужный.

На эту тему ребята из Vercel недавно выпустили статью. У них была задача дать ai-агентам актуальную документацию по собственному API. Сравнили два подхода – скиллы и agents.md. Получилось любопытно.

Скилл периодически не срабатывал. Что ожидаемо – обещание "агент сам подтянет скилл, когда нужно" оказалось зыбкой почвой. Если же в промпте прямо написать "используй скилл" – срабатывает чаще, но появляется сайд-эффект: агент якорится на документации из скилла и перестаёт смотреть контекст проекта.

С agents.md такой истории не случилось. По сути, убирается точка принятия решения – информация всегда в контексте, и гадать "а надо ли сходить за докой" не приходится. А чтобы контекст не переполнялся, в agents.md кладут не всю доку, а сжатый индекс – указатель, где смотреть по какой функциональности.

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

Skills + CLI vs MCP
Следующий заход, который я слышу всё чаще: давайте выкинем MCP, обернём походы во внешние сервисы в cli-утилиты, а в скилл положим инструкцию, как дергать cli. Идея – блеск. Ну по крайней мере на первый взгляд.

Во многом разделяю позицию автора статьи – делать так не стоит.

MCP – это по сути абстракция над API. LLM не нужно знать, как устроен сервис: достаточно вызвать service.do_x(), а MCP-сервер делает всё остальное. Коннектор между моделью и сервисом, где все шероховатости спрятаны.

А когда ту же задачу пытаются переложить на скиллы, начинаются нюансы:
– К скиллу нужно ещё доставить cli-утилиту. А если в окружении нет консоли – всё, приехали
– Обновление непрозрачное: не до конца понятно, как раскатывать обновления скиллов
– Аутентификация – туман войны, как параноидально управлять токенами изнутри скилла – до конца неясно
– Скиллы обещают экономить контекст, но это не всегда так. Нужен тебе буквально один вызов, а в контекст улетает весь SKILL.md
– Поддержка скиллов у агентов вроде есть, но у каждого свои нюансы. Универсальности, на которую хотелось бы рассчитывать, нет

Итого: скиллы – не замена MCP, а другой инструмент под другие задачи. А что имеет смысл попробовать – skill over MCP. MCP остаётся слоем соединения с сервисом, а Skill добавляется поверх как слой знаний о том, как этим MCP правильно пользоваться.

В следующем посте посмотрим, что сейчас происходит с MCP.

#ai

Что там с MCP

Когда придумали MCP – это было чудо чудесное. Агент общается с любым внешним сервисом через единый протокол, и тебе не нужно писать обвязку под каждую интеграцию. MCP-серверы стали городить как не в себя.

Потом начали вылезать технические нюансы. Описания тулов жрут контекст – подключил несколько серверов, и половина окна занята ещё до первого запроса.

Ещё одна проблема, которую я часто вижу на практике. Владелец сервиса, который пишет свой MCP, просто повторяет в нём свой API. В итоге появляются десятки тулов, между которыми агент путается.

И вот вышло новое видео от Anthropic – про текущее состояние MCP и планы дальше.

MCP – это про коммуникацию с внешними сервисами, и в этой области он реально полезен. А проблема забитого контекста – это не про протокол, а про клиента. Решается с помощью progressive disclosure: нужные тулы подгружаются на лету, по аналогии со скиллами.

Ближайшие планы:
– Stateless transport – чтобы MCP-сервера можно было хостить как обычный stateless REST. Сейчас streamable HTTP плохо масштабируется
– Server discovery – клиент автоматически находит MCP-сервер сайта по well-known URL. Заходит браузер или агент на сайт – и сразу видит, есть ли у него MCP
– Skills over MCP – сервер сможет отдавать не только тулы, но и инструкции с доменными знаниями. То есть сервер сам учит агента, как им пользоваться
– TypeScript и Python SDK – с учётом набитых шишек ребята будут активно переделывать SDK

В общем MCP никуда не исчезают, а продолжают развиваться в своей нише.

#ai

Где брать скиллы (часть 3)

С тем, как устроены скиллы, разобрались, даже в движении. А где их брать?

Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться.

Из тех, чем сам пользуюсь:
frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет.

brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом.

pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться.

playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу.

Делитесь, какими скиллами пользуетесь – интересно собрать подборку.

#devfm #ai

Создаем свои скиллы (часть 4)

Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались.

Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу.

Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный:
1. Достать из таск-трекера то, что вошло в релиз
2. Методом пристального взгляда отфильтровать то, что важно пользователям
3. Сформулировать всё на пользовательском языке, перевести на английский
4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского
...
N. Закоммитить, запушить
N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам

Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты.

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

Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно.

Ещё пара моментов:
– Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл
– Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз
– skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references
– Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить

#devfm #ai

Скилл поверх MCP

Я уже писал про Skills. А недавно попалось отличное видео от ребят из Supabase, где раскрывают интересную мне тему – skills over mcp.

Докладчик говорит так: вот есть у вас MCP – по сути просто набор тулов, чтобы агент ходил в ваш сервис. Но это просто тулы. Агент по-прежнему не знает хороших практик, принятых для сервиса, не знает его нюансов. И вот тут поверх MCP появляется скилл – который эти практики и нюансы агенту и приносит. По замерам ребят, в такой связке агент заметно лучше справляется с задачами.

Дальше – несколько мыслей из видео, которые во многом совпадают с моим опытом.

Описывайте явные сценарии. В видео это прямо подчёркивается: вы хорошо знаете свой продукт, знаете популярные сценарии и то, как их правильно выполнять – вот это и опишите.

Относитесь к скиллу как к документации для себя. Если при описании сценария вы понимаете, что что-то уже есть в доке – дайте агенту явную ссылку: вот здесь про это написано. Не нужно впихивать всё в одно место и дублировать. Тут полностью согласен: поддерживать актуальную доку и так сложно, а в двух местах – нереально. Кстати, ребята предложили подход, который я нигде раньше не встречал – давать агенту доступ к доке по ssh.

Что важно – выносите в SKILL.md. Ссылки ссылками, а следующий тезис такой: если что-то может быть пропущено агентом – оно может быть пропущено. Progressive disclosure у скиллов – это одновременно и фишка, и проблема. По опыту ребят, агент не пойдёт за раз по всем ссылкам из references. Поэтому если для вас что-то категорически важно – не прячьте это вглубь, выносите прямо в SKILL.md. Они так сделали с security-проверками, которые агент обязан выполнить.

И ещё одна мысль, которую я часто повторяю: работа над скиллом – это итеративный процесс. Нельзя один раз сказать агенту "сделай скилл" и считать, что всё готово. В видео автор честно говорит, что последние пару месяцев только и занимался, что докручивал скилл.

Забавно, что в этой всей ai-движухе порой получаешь противоречивые советы. И когда спрашивают: а как лучше? Совет-то я дать могу, но главный совет – экспериментируйте. Как оно сработает в вашем случае – заранее сложно сказать.

#ai

Как подготовить кодовую базу к работе с агентом

Очередная интересная статья от Антропика. На этот раз – о том, как подготовить свою кодовую базу к работе с агентом.

И одно дело, когда у тебя небольшой проектик, а другое – когда у тебя миллионы-миллионы строк кода, причём некоторые из них последний раз трогались в 2007-м.

Как агенту во всём этом ориентироваться? Индустрия много крутилась вокруг индексирования кода – у того же Cursor есть такой функционал. Но ребята идут в другую сторону.

И говорят: успех – в качественной обвязке, она же harness. В неё входят: CLAUDE.md (он же AGENTS.md), hooks, skills, plugins, поддержка LSP и MCP-серверы.

То есть если подготовить проект, агент сможет хорошо в нём ориентироваться. Дальше – чеклист, как это сделать:

1. Подготовьте CLAUDE.md для своего проекта. Если у вас огромный проект или монорепа – имеет смысл сделать отдельный CLAUDE.md для разных директорий, а в корневом оставить только общую картину мира. Обычно агент сам разбирается в структуре, но если вы знаете, что ваш проект – клубок, в корневом CLAUDE.md стоит сделать навигацию: коротенько, где что смотреть. Частая ошибка – класть в CLAUDE.md информацию, которая нужна не всегда, а под конкретный сценарий. По сути это то, что можно вынести в скилл.

2. Настройте hooks. Можно повесить хуки на подгрузку нужного контекста, на запуск линтеров и форматтеров. И в целом сделайте так, чтобы агент умел гонять проверки и тесты только по той части проекта, над которой идёт работа, – это быстрее и не засоряет контекст. Частая ошибка здесь – пытаться сделать промптом то, что можно было сделать обычной автоматикой. Если можно автоматикой – всегда делайте автоматикой.

3. Для повторяющихся, понятных задач сделайте скиллы. А также подключите к агенту LSP-сервер.

4. Поддерживайте .ignore-файл, чтобы в контекст агента не попадала ненужная информация – например, autogenerated или third-party код.

5. Раз в несколько месяцев пересматривайте CLAUDE.md и подобные артефакты. Это живой документ, который нужно периодически чистить: что-то становится неактуальным, модели становятся умнее, и какая-то информация им уже просто не нужна. Я помню времена, когда все автогенерировали эти артефакты – получалась такая фигня, что лучше уж их отсутствие, чем помойка.

6. У всего этого хозяйства должен быть ответственный – тот, кто поддерживает и следит за актуальностью.

Обратите внимание: пункты 5 и 6 – процессные. И, пожалуй, они самые сложные и самые важные (и скучные). По сути это всё про классические процессы в команде, в которые нужно встроить новые практики. Так что если у вас процессы уже настроены и вы знаете, как это делать – вам будет проще :)

#ai

Периодически я рассказываю о классных мероприятиях – и вот одно из них – infra.conf'26 – конференция про создание и эксплуатацию высоконагруженных систем и инфраструктуры.

Мне конечно же интересны темы, связанные с ИИ.

Активное развитие ИИ внесло существенные коррективы: послушаем, с какими новыми вызовами сталкиваются ребята и как с этим справляются.

Мероприятие пройдёт 4 июня. Приходите – будет классно :)

В курсе СТО от Стратоплана есть такая штука – База.

И несмотря на название, для меня именно эти темы оказались самыми интересными. Формат такой: раз в месяц – занятия на все выходные, суббота и воскресенье по 5 часов в день. За это время успеваешь довольно глубоко нырнуть в одну базовую тему.

Особенно откликнулось управление конфликтами. Тема и правда базовая – сталкиваемся с этим постоянно, на любой позиции: отстаиваешь точку зрения, что-то согласовываешь. Где-то выходит хорошо, где-то не очень – со временем нарабатываются свои приёмчики, как делать правильно. И вот самое то, когда теория ложится на уже имеющийся опыт: что раньше делал по наитию, теперь делаешь более осознанно.

По сути всё сводится к нескольким последовательным шагам:
1. Суть проблемы и цель – чётко сформулировать, в чём проблема, что будет, если её не решать, и какого результата хочешь от разговора.
2. Анализ собеседника – понять его поведение, позитивные намерения и скрытые потребности, чтобы говорить на его языке.
3. Формулировка и аргументация – подобрать слова и аргументы, которые показывают важность проблемы с учётом мотивов другой стороны.
4. Пожелание и проверка согласия – выбрать форму подачи (требование / просьба / вопрос / пожелание) и убедиться, что собеседник признаёт проблему и готов её решать.
5. Варианты решения с обоснованием – предложить конкретные выходы и аргументы в их пользу.
6. Закрепление и план Б – зафиксировать договорённости с контрольными точками и заранее продумать действия, если договориться не вышло.

Знаете, ещё иногда бывает – после встречи остаётся осадочек: "эх, вот тут надо было сказать по-другому" или "а вот ещё аргумент можно было привести". Так вот, чтобы схема заработала, к встрече надо готовиться заранее – буквально прописывать каждый пункт – и это прям важно. Тут как с любым навыком: я раньше реально всё фиксировал и расписывал, а теперь хватает просто черновичок накидать.

Отдельно на занятии разбирали медиацию – это когда ты как руководитель управляешь чужим конфликтом. Но это уже совсем другая история :)