Телеграм канал «DevFM»

Как использовать мессенджеры для повышения ярости в команде

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

• Пользоваться функцией меншена отдельных людей недостаточно. Активно используй everyone и here, чтобы показать, что твой вопрос важен.
• Голосухи. Ну это классика. Но ты можешь пойти дальше: ставь задачи на разработку голосухами, так ты шокируешь даже тимлидов, которые думали, что повидали все в своей жизни.
• Напиши «у нас серьезная проблема» и пропади. Это создаст ощущение драматичности момента, чтобы подчеркнуть что проблема реально серьезная.
• Кидай ссылки на статьи и посты без своих комментариев. Кто не понял к чему это - его проблема. В идеале, чтобы статья была недельной давности.
• Если решил отправить скриншот, то только фоткой экрана монитора дрожащей рукой. Камера телефона гораздо лучше передает цвета да и это тупо удобнее.
• Обращайся «коллеги», потому что ты же коллегам пишешь.
• Капс. Невозможно довести команду, если ты не пользуешься капсом. Каждый дополнительный восклицательный знак к капсу - плюс 1 пункт к ярости команды. СРОЧНО удваивает накопленную ярость.
• Если одно сообщение можно разбить на 10 (например, в сообщении 10 слов) - сделай это.
• Если потенциал групповых чатов исчерпан, переходи на личку. Используй треды в личных сообщениях, чтобы дезориентировать собеседника.
• Пиши «У НАС ЛЕЖИТ САЙТ!!!!!!!!!!!».

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

Ну это просто что-то замечательное. Пятничное развлекательное:)

А вы храните .md в проекте?

Частая тема для обсуждения: вот мы написали план для агента – стоит ли коммитить его в проект? Нужен ли он там после того, как задача сделана?

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

Я обычно не хранил такие документы в репе и до сих пор не храню. Зачем агенту какие-то дизайн-доки из прошлого? В процессе реализации мы могли что-то поменять, и в итоге документ рассказывает одно, а код делает другое (часто видел неактуальное говнище в репах). Чтобы рассинхрона не было, нужно поддерживать документы в актуальном состоянии и городить вокруг этого какую-то машинерию. В общем, волевое решение «теперь храним планы в репе» требует дополнительных приседаний.

Но всё чаще слышу, что некоторые .md-файлики всё-таки имеет смысл прихранивать. Вот, например, эссе Карсона Гросса, создателя мною любимого htmx.

Он предлагает относиться к маркдауну как к исходникам и хранить часть таких файлов в /src/md, рядом с кодом. В них фиксировать, как должна работать система, почему приняты те или иные решения и какие есть ограничения. Вплоть до деталей реализации, моделей данных и API.

По сути, разработчик не пишет разовые промпты на разработку, а готовит и обновляет артефакты в маркдауне. Затем передаёт их агенту, который на их основе пишет код и тесты. Тесты проверяют поведение автоматически, а маркдаун объясняет замысел в форме, удобной и человеку, и агенту.

Аргумент – весь этот контекст остаётся рядом с реализацией. Его можно искать, смотреть в diff и ревьюить в PR. Он не теряется в истории промптов, и за объяснением конкретного модуля не нужно каждый раз идти в вики или переписку.

Но мой вопрос всё ещё остаётся: как надёжно поддерживать синхрон между этими файлами и кодом?

А вы что сохраняете после работы с агентом? И как поддерживаете актуальность?

#ai

Удивительная стойкость и профессионализм

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

А тут случилось невероятное: серьёзно повреждены несколько крупных дата-центров Яндекса.

Я пытаюсь представить масштаб проблемы — и не получается.

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

Теми, кто из раза в раз проводил учения с отключением дата-центров, проверяя надёжность сервисов. Несмотря на недовольство: «Ну всё же и так работает, всё ок».

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

В общем, это невероятно сложная ситуация. Но мы справимся, и всё будет работать. Потому что у инфры есть такой девиз: «Работаем, чтобы работало».

А вы стали пилить больше фичей?

Наверняка да. AI генерирует код с бешеной скоростью. Рост производительности тоже бешеный. Ну, вроде бы.

А всё ли из того, что пилится, реально нужно?

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

Задачи, до которых никогда не доходили руки
Это задачи, которые годами пылились в бэклоге. Опытный проджект раз за разом откладывал их со словами: «Скоро обязательно доберёмся».

И вот кладбище таких задач вероломно вскрыли. Задачи пошли в ход, и этим очень гордятся: «Видали, что мы сделали! Столько лет откладывали, а теперь взяли и сделали!»

Меня, честно говоря, такое пугает. Если задача месяцами или годами откладывалась, то, может, она и не нужна?

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

Теперь на такие скучные вещи просто нет времени. Нужно бежать, разработка стынет :)

И вот тут вопрос: а нужно ли это? Есть ли от этого реальный профит?

Прилепим рядом
Раньше, когда продумывали архитектуру, старались не городить лишнего, встраиваться в существующую систему и переиспользовать готовые решения. Иначе дорого, да и ресурсов столько нет.

А сейчас: так-так-так, система сложная, встроиться в существующее решение непросто, да и агент не очень держит всё это в контексте… Что же делать? А давайте-ка просто рядом бабахнем нашлёпку, и всё будет супер.

Сама нашлёпка выглядит логичной и продуманной. А когда смотришь на систему и архитектуру в целом – ну херня же какая-то!

Хочу фичу, а то…
Может, видели эти горящие глаза? Приходит пользователь с запросом. Ты ему аккуратно говоришь, что это пока не приоритет, что не ложится в общую стратегию продукта. А тебе в ответ: «А давайте я сам пиар вам принесу».

И тут глаз начинает дёргаться, а в голове – пиар на +100500 -3. Пожалуйста, не нааада! Кто это будет поддерживать? Но это мало кого интересует.

Или вообще смотришь, а рядом уже растёт свой костыльный проект, который пытается решить какие-то локальные проблемы.

Поделитесь в чатике, как у вас с этим обстоят дела. А мне пора заканчивать писать, а то там сварился ещё один пиар в соседний сервис. Нужно занести коллегам :)

#devfm

Когда агенту нужен браузер

Словил удивительное поведение в Codex: при работе с браузером получил ошибку, мол, ресурс запрещён. 0_0

Я его и так, и так уговаривал, просил подиагностировать – ни в какую. Говорит, просто запрещено, и всё.

Ну и в целом бывает, что настраиваешь какую-то машинерию и нужен браузер.

На этот случай рекомендую классный скилл agent-browser от Vercel.

#ai