Залетаем через 5 минут. Комменты будут под этим сообщением

Неплохой перевод статьи о важных аспектах общения с ChatGPT 5.2, есть несколько довольно занимательных примеров промптов.

Самое забавное, что ко многим из этих рекомендаций я пришёл сам. И даже рассказывал об этом своим менти (и на нашей последней встрече здесь).

Прикладное использование иишек всё пресказуемее

Как заставить ИИ работать с проектной (и не только) документацией.

В современных LLM есть одно фундаментальное ограничение — длина контекста. Да, она с каждым годом растёт, но для серьёзных проектов всё равно не хватает. Попробуйте скормить AI всю вашу документацию: текст, схемы, таблицы, изображения, файлы. Даже Google с её нынешним лямом токенов начнёт нести чушь.

Потому что есть ещё системные промпты и история сообщений. Есть файлы, диаграммы и картинки, которые жрут немеряно токенов. Всё это довольно быстро забивает контекст и модель начинает упрощать, тупить и галлюцинировать. Так что же делать?

Ответ есть уже довольно давно. Ещё в 2020м исследователи одной запрещённой соцсети опубликовали статью про RAG (Retrieval-Augmented Generation). Это такой подход, при котором ИИ не полагается на одну только память, а сперва ищет информацию во внешнем хранилище — и только потом формирует ответ на основе найденного.

Давайте на примере библиотеки и библиотекаря.

Библиотека — это ваша документация, база знаний: документы, журналы, инструкции, PDF и эксельки, статьи, заметки, БД. Всё это заранее разложено, проиндексировано и помечено так, чтобы можно было быстро найти нужные фрагменты (а не перечитывать каждую спецификацию целиком). В RAG это всё документы, разбитые на фрагменты и преобразованные в векторы.

Библиотекарь — это RAG-логика поверх LLM. Когда ты задаёшь вопрос, библиотекарь не бросается отвечать сразу. Он сперва выявляет суть твоего вопроса, идёт в библиотеку, ищет релевантные книги и даже страницы в них. Он достаёт конкретные абзацы, а не перебирает всю книгу целиком. И только после этого он возвращается и отвечает. Библиотекарь не обязан знать ответ заранее. Он должен уметь искать и пересказывать.

Почему это принципиально важно?

Потому что обычная LLM без RAG — это очень услужливый библиотекарь без доступа к библиотеке. Он умный, начитанный, но его знания могут быть устаревшими, в них может не хватать деталей. А когда знаний нет, он начинает очень убедительно их выдумывать.

Как выглядит запрос в RAG-логике:

Ты спрашиваешь у своего ИИ: «Какие риски могут сработать при изменении формы регистрации юрлиц в нашем продукте?»

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

Если в библиотеке нет нужной книги, твой библиотекарь скажет об этом.

Почему RAG — не просто «поиск + ChatGPT».

Ключевое отличие в том, что модель видит контекст целиком. Это не «я нашёл 5 ссылок, вот они». Это «я нашёл подходящие фрагменты и отвечаю, опираясь на них». Поэтому ответ обычно точный, связный, без галлюцинаций и со ссылками на источники.

RAG идеально ложится на:
- документацию,
- корпоративные базы знаний,
- нормативку,
- исследования,
- да и вообще всё, что не лезет в контекст.

RAG — это не просто поумневшая модель. Это хорошо обученный библиотекарь с доступом ровно к тем полкам, которые вы ему разрешили.

Навигация по постам в канале:

2023-12-31 Проверка зрения дизайнеров
2024-01-21 Баги будут
2025-04-29 Последствия неочевидных ошибок
2025-05-03 CJM и иллюзия контроля
2025-05-05 Техдолг и тротил под фундамент проекта
2025-05-15 Культ метрик и чем он чреват
2025-05-25 Менторство
2025-06-09 UX vs CX: кто кого включает
2025-07-18 PO, PM, PjM: кто такие и при чём тут мыло, ракеты и застройщики
2025-08-23 Риски невидимых зависимостей
2025-09-01 ИИ, тире и ёлочки
2025-09-14 Внедрение методологий без саботажа
2025-09-19 Саботаж при внедрении методологий
2025-10-03 Метрики, которые убивают ваш продукт
2025-10-07 PoDPR: приоритизация для взрослых
2025-10-19 Обновление цикла про Информационную Архитектуру
2025-11-18 Гипотезы без риска и измеримости
2025-11-22 Рынок найма мутировал
2025-12-03 Кто не пишет с AI, пусть бросит в меня камень
2025-12-08 Семь лет Дизайну Данных
2026-01-03 RAG в документации на примере библиотекаря
2026-01-25 Почему не нужно боятся увольнения
2026-05-14 Personas и JTBD: два этажа одного здания

Очень честный и хороший выпуск про то, как и зачем писать хорошие тексты (и, конечно, про ограничения использования иишек)

Пишу небольшую статью про объединение Персон и JTBD. Про то, как из потребностей пользователей рождаются механики продукта.

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

Не переключайтесь

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

Но поиск новой работы всегда сопряжён с уходом со старой. А ведь уход — это тоже отдельная тема. Грамотное увольнение может содержать вас от трёх месяцев до полугода (а то и больше).

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

Давайте немного расскажу про то, почему вам не стоит бояться увольнения:

1. Вас никогда не уволят по статье. Просто поверьте. Если ваш начальник угрожает этим, смело шлите его. ТК РФ в этом отношении накладывает на работодателя такой пиздец, что ему намного проще пойти на соглашение сторон, чем идти через процессуальный ад.

2. Вас не могут сократить. Вообще. Потому что если это и случится, а потом работодатель будет искать вам замену, вы не только восстановитесь в должности, но и получите зарплату за все месяцы, пока не работали. А компания получит штраф. Тут есть, конечно, нюансы, но вы при любом раскладе не окажетесь в минусе, пока ищете работу.

3. Если вы знаете свои права и готовы их отстаивать, ваше увольнение обойдётся компании минимум в шесть ваших окладов. И это ещё без учёта операционки (типа найма и обучения замены, работы эйчаров и прочих накладных расходов). Поверьте, руководство это понимает.

Хотел ещё написать про то, как правильно выбирать работодателя и читать трудовые договоры. Или как увольнять так, чтобы все остались довольны. Но и так получается лонгрид. Вот вам вместо этого охеренный подкаст на тему увольнений.

Шарьте. И не переключайтесь

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

Не знаю, есть ли у меня тут ребята из HH, но если есть, покажите это своим продактам.

17-18 апреля буду выступать на конференции Merge в Иннополисе.

Тема сейчас максимально актуальная: «Приоритизация здорового человека: как учесть риски и обратимость». Расскажу, почему классические фреймворки иногда искажают картину и как PoDPR помогает выбирать инициативы, которые можно быстро и безопасно проверить.

Конфа обещает быть жаркой: 7 тематических направлений от разработки до маркетинга, 170+ спикеров, 10 одновременных потоков и нетворкинг.

По промокоду SHERER можно взять билет со скидкой 20%

Подробнее о конфе на сайте: tatarstan2026.mergeconf.ru

Подписчики из Казани и около: пишите, пересечёмся

Друзья, у меня открылась офигительная позиция для сильного дизайнера в мой проект. Ниже — вакансия от нашего дизайн-лида:

Уровень: Middle+

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

Задача: изучать потребности пользователей, проектировать клиентскую логику и интерфейсы. Принцип: сильный UX, простой UI. В первую очередь веб, в меньшей степени мобильные платформы.

Коротко: нужно быть больше ux-инженером, чем ui-дизайнером. Вы умеете быстро погружаться в сложный контекст, разбирать его на винтики, и планомерно превращать в решения. Желательно иметь минимальную техническую грамотность – например, вы понимаете принцип работы браузера, можете объяснить, как работает кнопка “войти через VK ID”.

Скиллсет:
- Фреймворки CJM и JTBD.
- Функциональная, информационная и навигационная модели интерфейса – вы знаете что это, можете собрать, и объяснить что с этим делать дальше.
- Собирать и описывать функциональные сценарии и user flow с учётом слоя системной логики.
- Проектировать интерфейсы (от простых до сложных, и можете объяснить почему интерфейс должен быть именно таким).
- Можете собрать библиотеку компонентов в фигме и собрать с ее помощью простой функциональный UI.
- Исследовать и проектировать с помощью AI.

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

Очень много прилетело заявок (уже больше полусотни), и ещё летят. Спасибо тем, кто откликнулся. Всех рассмотрим, но у меня пока нет отдельного HR для этих целей, всем занимается дизайн-лид. Нам понадобится несколько дней, чтобы всех изучить и с кем-то, возможно, созвониться.

Если к кому-то не вернулись с обратной связью, прошу понять и простить напомнить к середине следующей недели

Пришло время полезных статей. В этот раз я решил запустить мини-цикл про симбиоз персон и JTDB. Вокруг этих ребятишек всегда много шума: то один другого отменяет, то наоборот. Я их у себя давно подружил, и теперь делюсь этой дружбой с миром.

Это первая из двух статей, вторая будет про развитие Job Story из User Story, не переключайтесь

Если вам нужно скормить эту статью нейронке, вот вам удобная ссылка для неё: https://sherer.pro/llm/post/personas-i-jtbd-raznye-etazhi-odnogo-zdaniya.md

А вот тут в целом весь сайт (если вы захотите, как одна моя знакомая, сделать нейропашу): https://sherer.pro/llms.txt

А я тем временем продолжаю искать на самый лучший свой проект (по версии фаундера) ребят настолько крутых, что от их появления почтенно стихают тётеньки в бухгалтерии.

Теперь очередь DevOps (цитата умеет раскрываться по клику, если что):

Senior DevOps для проектирования и поддержки инфраструктуры большого онлайн-проекта.

Уровень: Senior
Формат: полный рабочий день
Локация: удалённо, Россия
IT-аккредитация: пока нет

Мы ищем Senior DevOps Engineer в команду. Создаем цифровой продукт с нуля: B2C и B2B-система с элементами маркетплейса и несколькими функциональными контурами.

Что предстоит делать

1. Участвовать в проектировании платформы продукта с нуля. В частности:
- выработать GitOps-подходы,
- спроектировать политики безопасности, модель хранения секретов, схемы предоставления доступов,
- выработать подход к резервным копиям и DR,
- настроить мониторинг, сбор и просмотр логов, алертинг и трассировку,
- спроектировать ролевую модель и настроить IAM-контур.

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

3. Кроме этого, нужно настраивать CI/CD-пайплайны, контейнеризацию приложений, сопровождать их запуск и жизненный цикл.

4. В рамках данных задач нужно полностью управлять кластерами проекта (managed k8s): разворачивать, настраивать и сопровождать инфраструктуру платформы.

Что важно

- Опыт работы DevOps Engineer / SRE / Infrastructure Engineer на senior-уровне.
- Уверенный опыт работы с Kubernetes.
- Опыт настройки CI/CD: GitLab CI, GitHub Actions, Jenkins, TeamCity или аналогичные системы.
- Опыт работы с IAM: RBAC, ABAC, пользователи, роли, группы и прочие связанные штуки.
- Опыт администрирования Linux и сетей.
- Опыт настройки мониторинга, логирования и алертинга.
- Опыт работы с базами данных и брокерами на инфраструктурном уровне: PostgreSQL, Redis, Kafka, RabbitMQ и прочие.
- В целом, готовность работать в продукте с нуля, где часть решений предстоит выбрать, описать и внедрить, а затем сопровождать и развивать.

Писать @xFFFFFE