Павел Шерер

Залетаем https://telemost.yandex.ru/j/5576120574 Темы: UX, системный дизайн, ai-аненты и всякое такое

Снова собираемся на канале. В следующий четверг (6.08) в 19:00 МСК. Будет как обычно: ламповое тепло, умные лица, капельку высокомерия и похабных шуточек. Тему мне лень выдумывать, выбирайте сами. Ну и ставьте в календари + шарьте

Ну что, доживаем последние деньки в телеге, как считаете? Пока ещё всё работает, хочу вам сообщить о хорошей новости: я снова объявляю набор на менторство. Больше года прошло со времени последнего набора, у меня стали освобождаться слоты — посему велкам. Почему менторство, что это, какие условия и что что я могу дать — тут и ниже. Делитесь, наверняка кому-то окажется полезно. UPD: пишите @mashavanassi, она организует первую встречу

JTBD → Job Story → Иерархия целей → Opportunity Landscape → Personas → Механика → User Story → Проверка результата Новая статья в цикле про персон и JTBD. Теперь о том, почему даже приличная User Story может аккуратно описывать совершенно не ту задачу. Команды часто путают потребность с механикой: пользователю якобы нужен дашборд, уведомление, автоскейлер или очередная форма. Хотя на самом деле ему нужно, чтобы продукты не заканчивались, проект не падал, а важная информация не терялась. На сквозном примере разбираемся, как перейти от ситуации «я выпал из проекта и потерял контекст» к конкретной и проверяемой User Story — не влюбившись в решение раньше времени. Шарьте

Мой хороший друг ищет девлида, вот вакансия: # Руководитель разработки/техлид Ищем руководителя разработки/техлида в проект в сфере API программ лояльности. Продукт на стадии работающего MVP (клиенты и план развития минимум на пару лет - в наличии). Заниматься нужно техническим управлением разработкой: развитием архитектуры, инфраструктуры и в целом работой команды. Оплата - от 300.000 рублей в месяц. ## Чем предстоит заниматься Проектировать и развивать архитектуру backend, API, интеграций, фронтов (админок), инфраструктурного контура и модели данных. В том числе включиться в развитие архитектуры БД и её производительности. Основная задача - управлять командой разработчиков: декомпозировать задачи, помогать с техническими решениями, проводить ревью, временами стоять над душой. И быть основной точкой технической экспертизы по продукту. Нужно (хотя не факт, что придётся) писать код: роль предполагает техническое лидерство плюс hands-on при необходимости. Объем работы и задач большой, надо любить кодить и любить красивый код. Так же нужно управлять devops-контуром продукта: Kubernetes, CI/CD, наблюдаемость, IAM, окружения. Требуется соответствующий опыт и компетенции. ## Что требуется Уровень - senior/lead. Опыт коммерческого проектирования веб-ПО, backend-архитектуры, API (OpenAPI и т.п.); практический опыт с Node.js и React (сейчас стек на них). Опыт с другими языками и фреймворками будет большим плюсом. Уверенный опыт с SQL и Postgres, особенно в части производительности. Опыт работы с Redis, Kafka или RabbitMQ, микросервисами и кешами. Большим плюсом будет опыт с Supabase. Практический опыт и devops-практика на уровне понимания flux, CI/CD и k8s и умения их готовить. Уверенное владение письменным английским: чтение документации, разбор технических материалов, письменная техническая коммуникация. Устный английский в плюсе и приоритете. ## Формат работы Полный рабочий день, ГПХ. Полностью удалённая работа, география - вся Россия. График гибкий, основная коммуникация и рабочие процессы ведутся преимущественно в часовом поясе Москвы. Работаем в формате стартапа: без избыточной бюрократии, длинных согласований и лишнего формализма. При этом от руководителя разработки ожидается ответственное отношение к принимаемым решениям, качеству и срокам. ## Как проходит отбор Техническое интервью и тестовое задание. На интервью обсуждаем опыт, архитектурные решения, управление разработкой, backend, базы данных, инфраструктуру и работу с различными системами. Писать @xFFFFFE Шарьте

Общий анализ Внимательно проанализируй содержимое репозитория на предмет: - Наличия потенциальных уязвимостей и слабых мест в безопасности. - Качества общей архитектуры и программных решений. - Согласованности функций, компонентов, модулей, методов API и прочего. - Наличия избыточной и дублирующей функциональности и логики, методов API и прочего. - Идемпотентность операций (API, БД, кэш и прочее). - Оптимизации и быстродействия. - Cоответствие файлов окружения `.env.*`. - Полноты и качества документирования проекта, соответствия документации текущей версии кода. - Соответствия файлов ARCHITECTURE.md, README.md и AGENTS.md коду и архитектуре. - Консистентности документации проекта, наличия дубликатов в файлах документации. Старайся ничего не упустить. Создавай подробный план исправления. Проработка UX Внимательно изучи все страницы и объекты сайта с точки зрения UX и UI: - Главная страница - ... - 404 страница - Остальные страницы и разделы Тебе нужно проверить: - консистентность схожих элементов и блоков; - сетки, отступы, границы и тп; - качество цветовой схемы; - доступность: контраст, наличие элементов и атрибутов для скрин-ридеров; - удобство использования; - наличие, качество и плавность анимаций; - качество и оправданность выбранных дизайн-решений; - прочие аспекты UX и UI. После оценки составь план (в том числе, исходя из реальных интерфейсов в браузере), исправления всех недостатков, которые найдёшь. Задай все необходимые вопросы перед тем, как составлять финальный план.

ARCHITECTURE.md # Задача Создай (или обнови, если уже существует) файл `docs/ARCHITECTURE.md`. # Вводные `ARCHITECTURE.md` — это живой архитектурный документ, описывающий текущее фактическое состояние системы. Это не vision-документ и не roadmap. Он фиксирует реальную архитектуру, отражённую в коде и инфраструктуре. # Требования к содержанию `ARCHITECTURE.md` Документ обязан содержать следующие разделы: 1. System Overview – назначение системы – ключевая бизнес-цель – границы системы (что входит и что явно не входит) – основные внешние акторы и интеграции 2. Architectural Context – тип архитектуры (монолит, модульный монолит, микросервисы и т.д.) – среда исполнения (runtime, инфраструктура, deployment-модель) – основные технологические стеки 3. Subsystems and Responsibilities Для каждой подсистемы: – название – ответственность – публичные интерфейсы – зависимости – что она не должна делать 4. Interactions – логическая схема взаимодействия подсистем – направление зависимостей – синхронные / асинхронные взаимодействия – точки интеграции с внешними системами Описание должно быть логическим и архитектурным, без BPMN и без избыточной детализации бизнес-процессов. 5. Data Architecture – основные доменные сущности – границы владения данными – источники истины – политика кэширования (если есть) 6. Key Technical Decisions – принятые архитектурные решения – их причины – зафиксированные компромиссы – допущения 7. Constraints – технические ограничения – инфраструктурные ограничения – нормативные или внешние ограничения 8. Extension Points – предусмотренные точки расширения – места, где допустимо добавлять новые модули – зоны, требующие осторожности 9. Architectural Invariants Перечень принципов, которые запрещено нарушать. Это должны быть чёткие, проверяемые правила. # Правила описания – Документ описывает текущее состояние кода, а не желаемое будущее. – Если что-то не реализовано — не описывать это как существующее. – Не использовать расплывчатые формулировки («гибкая», «масштабируемая» без пояснения). – Не дублировать README. – Не описывать бизнес-функциональность вне архитектурного контекста. – Не фантазировать о механиках, которых нет в коде. # Консистентность Перед созданием/обновлением документа: – проанализируй текущую структуру репозитория – определи реальные модули и зависимости – зафиксируй их как есть Документ должен быть согласован с кодовой базой. # Обновление AGENTS.md Обнови файл `AGENTS.md`, добавив: 1. Правило, что `docs/ARCHITECTURE.md` является единственным источником истины по архитектуре системы. 2. Обязанность агента: – при любом изменении, затрагивающем архитектуру (структура модулей, зависимости, интеграции, инфраструктура, доменные границы), обновлять `ARCHITECTURE.md` в том же коммите. 3. Запрет на архитектурные изменения без обновления документа. 4. Если архитектурное изменение невозможно корректно отразить в `ARCHITECTURE.md`, агент обязан: – явно указать это в комментарии к изменению – объяснить причину – предложить способ корректного отражения # Запрет дублирования – Архитектурные описания запрещено дублировать в других документах. – Все архитектурные разделы в других файлах должны ссылаться на `docs/ARCHITECTURE.md`. # Дополнительно Если файл уже существует: – не переписывать его полностью без причины – сохранить структуру, если она логична – обновлять только несоответствующие или устаревшие разделы # Результат После выполнения: – `docs/ARCHITECTURE.md` отражает реальную архитектуру – `AGENTS.md` закрепляет дисциплину поддержки архитектурной документации

Ну и вот вам ещё парочка пропмтов, которые я использую с Codex регулярно. Каждый из них, разумеется, нужно допиливать под конкретную задачу и особенности проекта. В одно сообщение не влезло, ловите несколько: AGENTS.md # Задача Создай (или обнови) в корне репозитория файл AGENTS.md, который станет исчерпывающей шпаргалкой для дальнейшей автоматизации. Документ должен рождаться из самого кода: прежде чем писать, проанализируй структуру проекта, конфигурационные файлы и историю коммитов. ## Как работать Сначала собери контекст. Просмотри: * файлы, явно задающие правила (например package.json, composer.json, pyproject.toml, Makefile, docker‑compose.yml, .github/workflows); * настройки тестов и линтеров; * историю git, чтобы понять фактические соглашения именования и частоту используемых команд. Затем построй черновик, где каждый раздел отвечает на вопрос «как мне сэкономить время при следующем вызове». Проверь, что в финальной версии нет лишних подробностей (избыточных для автоматизации) и отсутствуют недостающие шаги, без которых агент начнёт задавать уточняющие вопросы. ## Что обязательно описать ### Навигация по коду Укажи точки входа (bin‑скрипты, запуск приложения, тестовый раннер) и пути, которые можно смело игнорировать (скомпилированные артефакты, временные каталоги). ### Повторяемые команды Приведи стандартные команды для запуска тестов, линтеров, миграций, сборки образов и развёртывания. Добавь примечания, когда нужны переменные окружения или специфические флаги. ### Соглашения о стиле Опиши реальные, а не декларируемые правила: табы или пробелы, максимальная длина строки, формат сообщений коммита. Если настроены автоформатеры (pre‑commit, black, prettier) — укажи их конфигурацию и команды. ### Ограничения и переменные среды Зафиксируй минимальные версии интерпретаторов, набор обязательных переменных окружения и значения по умолчанию, безопасные для локального запуска. ### Зависимости и менеджеры пакетов Перечисли используемые менеджеры (npm, pipenv, poetry, go modules) и типовые сценарии: установка, обновление, аудит. ### Система CI/CD Расскажи, какой pipeline собирает проект, какие проверки считаются обязательными, где находятся конфигурации workflow и как локально воспроизвести сборку. ### Расхождения и подводные камни Отметь известные проблемы (например, нестабильные версии зависимостей, необходимость ручного патча) и предложи безопасные обходы. ### Полезные ссылки Дай точечные ссылки на внешние руководства, если они экономят время (например, политика версионирования или дизайн‑система). ### Информацию о локализации (переводе) строк Если применимо, укажи механики локализации и место хранения переводов. ### Обязательно добавь о необходимости обновления AGENTS.md в случае, если в репозитории произошли какие-то изменения в перечисленных пунктах. ## Финальное действие Сформируй AGENTS.md, сохрани в корне репозитория, зафиксируй коммит с сообщением «docs: bootstrap AGENTS.md». В комментарии к коммиту коротко опиши, какие данные были автоматически обнаружены, а какие добавлены эвристически.

Решил я поставить эксперимент: запилить редизайн своего сайта полностью на Open AI Codex. Без дизайна, референсов и единой строчки самостоятельно написанного кода. Ну а где редизайн, там и с нуля написанная тема, современная и с кучей плюшек, которые я раньше закрывал сторонними плагинами. Задачка не особо простая, как мне тогда казалось. Сказать, что я охренел будет слишком мягко. Всего за 4 вечера шаблон был полностью готов, покрыт тестами и успешно развёрнут на локальном сервере (на прод залью чуть позже, пока вот вам скрины). Из интересного: я специально писал промпты на естественном языке, только иногда добавляя что-то специфическое, типа веб-сокетов в админке или детали по 2FA. Я не просил его о простых вещах, типа «подвинь вот этот блок» или «поменяй шрифт», только общие команды. Например вот такие: Внимательно изучи все страницы и объекты сайта с точки зрения UX и UI: - Главная страница - Страница блога - Запись блога - Страницы со списком питомцев - Отдельная страница питомца - 404 страница - Остальные страницы и разделы Тебе нужно проверить: - консистентность схожих элементов и блоков; - сетки, отступы, границы и тп; - качество цветовой схемы; - доступность: контраст, наличие элементов и атрибутов для скрин-ридеров; - удобство использования; - наличие, качество и плавность анимаций; - качество и оправданность выбранных дизайн-решений; - прочие аспекты UX и UI. После оценки составь план (в том числе, исходя из реальных интерфейсов в браузере), исправления всех недостатков, которые найдёшь. Задай все необходимые вопросы перед тем, как составлять финальный план. или такие: Нужно доработать механики таксономии «серия»: 1. На внешней части в секции .sherer-post-series.series показывать неопубликованные статьи серии с пометкой «coming soon». Они должны быть некликабельными, серыми. 2. Для каждой статьи в серии должно быть можно указать порядковый номер — именно по нему будут сортироваться записи в блоке .sherer-post-series.series. Если номер не установлен, то сортировки происходит по дате публикации. 3. Проставь автоматически всем записям во всех сериях порядковый, исходя из даты публикации (можно прямо в БД). или даже такие: Нужно добавить маленький плавающий баннер внизу страницы «Сайт использует куки» с кнопкой «Мне плевать». По клику на кнопку баннер скрывается и больше в этом экземпляре браузера не показывается (через cookies или local storage). Баннер должен быть совсем небольшой, чтобы не мешал чтению даже если пользователь его не скроет Да, без понимания, как оно вообще должно работать и без внятного образа результата — у вас, скорее всего, получится хуйня. Да, дизайн не сказать, что особо выразительный. Но тема получилась реально удобной и от её вида не текут кровавые слёзы. Кроме того, она делает сам сайт намного безопаснее — и без сторонних решений, расширяющих площадь атаки. А главное — это: - Быстро. Я бы сам такое писал месяц точно, если со всеми фичами. Но вероятнее, просто отдал бы на сторону. - Практически бесплатно. Я с лихвой уложился в «бесплатный» лимит кодекса, а раньше просто отдал бы 3-4 сотни дизайнеру с разрабом. - Удивительно, но это реально безопасно. Ни я, ни локальная модель, ни клод, ни тот же кодекс не смогли в итоговой версии найти ни одной уязвимости. В интересное время живём

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

Голоса разделились поровну. А посему правом, данным мне мной же, выношу решение в сторону онлайн-встречи. В ближайший четверг, 02.07, в 20:00 МСК. Ссылку на Телемост скину ближе к дате. Обсуждать будем, как обычно, продукты, дизайн и управление: на этот…

Голоса разделились поровну. А посему правом, данным мне мной же, выношу решение в сторону онлайн-встречи. В ближайший четверг, 02.07, в 20:00 МСК. Ссылку на Телемост скину ближе к дате. Обсуждать будем, как обычно, продукты, дизайн и управление: на этот раз с упором на исследования и прогнозирование в наступающий век AI. Будет полезно дизайнерам с аналитиками, исследователям и продактам. Шарьте всем причастным

Мой коллега и одновременно вундеркинд Гари недавно выложил довольно занимательную статью. Главная мысль в том, что фокус — это не «соберись блять». Это результат работы нейробиологии и архитектура среды: сон, питание, отсутствие лишних стимулов, нормальное рабочее место, понятные блоки работы и ритуалы входа/выхода. Настройка системы. Статья большая, но я в вас верю.

Ищу UX/UI-дизайнера в команду 👀 У нас в студии становится больше проектов, поэтому ищу дизайнера интерфейсов на постоянное сотрудничество. Что делаем: — B2B-системы, личные кабинеты, CRM, ERP; — сложные интерфейсы с большим количеством данных и сценариев; — работаем через аналитику, а не просто рисуем красивые экраны. Что важно: — уверенно работать в Figma; — уметь думать про UX, а не только про UI; — не бояться таблиц, фильтров, форм и сложной логики; — соблюдать сроки и держать связь по проекту. Будет плюсом: — опыт работы с корпоративными системами; — понимание продуктового подхода; — опыт подготовки макетов для разработки. Формат работы: — удалённо; — проектная занятость с возможностью постоянной загрузки; — оплата обсуждается по опыту и уровню. Если интересно — присылайте: 📌 пару слов о себе; 📌 ссылку на портфолио в figma; 📌 желаемую ставку или уровень дохода. Писать мне в личку: 👉 @evgeniyashamray Буду благодарна за репост ❤️