22009
Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами. Размещение рекламы: @tanyasanovna Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Новые выпуски тимлидских подкастов
Лучше регулярных силовых тренировок могут быть только тренировки под подкасты. Держите свежую подборку интересных эпизодов:
👉"Три тимлида заходят в бар" про финансовые вопросы команды – сразу два выпуска (1, 2) про зарплаты, их прозрачность, премии, бонусы, контр-офферы и прочее из той же серии.
👉КОДА КОДА про рынок труда для руководителей – почему менеджеру найти работу стало существенно сложнее и как с этим быть.
👉"Едим слона целиком" про организационную психологию и работу с мотивацией команды.
Вы часто обращаете внимание на городские билборды?
Большинство из них мозг фильтрует как фон, но некоторые цепляют взгляд. Вот тут, например, вместо привычного «купи-закажи» какой-то интеллектуальный вызов.
QR-код на билборде ведет на спецпроект OUT OF THE BOX от КРОК. Там команда КРОК собрала нестандартные реальные кейсы из ИТ (и не только) и до 30 марта предлагает IT-рынку их решить. Там не тесты с одним ответом, а задачи «на подумать», которые так сразу не решишь. Но когда привык к определенным рабочим паттернам, такая встряска для мозга очень полезна.
Если еще не видели этот билборд в городе — сайт проекта прямо здесь. Расскажите, какой кейс выбрали и получилось ли решить!
Как эффективно работать с инцидентами
Как показывают последние месяцы, количество серьезных инцидентов начало резко расти. Вы и раньше от них не были застрахованы, а теперь, когда постоянно ложатся базовые сервисы вроде Cloudflare, AWS и GitHub, вы стали еще уязвимее. Поэтому держите статью про то, как прокачивать себя и команду, чтобы справляться с инцидентами эффективнее:
👉Все должны понимать в деталях, из каких шагов состоит деплой.
👉Не нужно быть экспертом во всех компонентах вашей системы, но надо иметь общее представление об ее архитектуре, железе и его конфигурации, сетевом стеке, пути запроса и всей инфраструктуре.
👉Нужен хороший тулинг, который позволяет легко вытащить стектрейсы эксепшнов, посмотреть на метрики железа и приложения.
👉Нужно развивать насмотренность на стектрейсы – понимать, какие части касаются вашего кода, а какие библиотечного, учиться быстро находить их источник.
👉Постройте практику war room – во время инцидента собирать всех релевантных людей из разных функций в одном физическом или виртуальном пространстве, чтобы быстро обмениваться информацией.
👉Введите роль инцидент лида – у этого человека должны быть полномочия перенаправлять других людей на разные части расследования, принимать решения по отключению фичей, поддерживать всех в курсе происходящего.
Простые решения не приносят промо
Большинство процессов, в которых группа людей оценивает чье-то инженерное решение, ведут к излишней сложности. В интервью, решениях о промо, дизайн-ревью в первую очередь выделяются инженеры, которые придумывают сложные и умно выглядящие решения. А инженеры, которые вместо создания новых слоев абстракции решили проблему в несколько строк, и наоборот избежали сложности, остаются незамеченными.
Сложные решения впечатляют людей, а простые гораздо менее интересны. Уровень инженера очень часто оценивается по тому, насколько сложные системы он строил, поэтому мотивации решать вещи простыми способами особо нет.
Что с этим делать инженерам:
👉Нужно стараться сделать свои простые решения видимыми и не менее впечатляющими. Не "реализовал фичу Х", а "оценил три возможных подхода к реализации, и отсек А и Б как неоправданно сложные по таким-то факторам, в итоге реализованное мной решение вызвало 0 инцидентов".
👉Когда на дизайн-ревью вас спрашивают что-то вроде "насколько это решение масштабируемо?", защищайте свою позицию – дайте оценку того, сколько усложнение будет стоить прямо сейчас, и насколько возможно будет доработать решение в будущем, когда это станет действительно нужно.
👉Вовлекайте своего менеджера, он тоже должен быть в курсе принципов, по которым вы принимаете решения, и разделять их.
Вопросы, скрытые за вопросом
Часто важен не конкретный вопрос, который вам задали, а те глубинные вопросы, тревоги и опасения, которые скрыты за ним. Пока вы с ними не разберетесь, собеседник не почувствует, что на его вопрос действительно ответили.
👉Не ввязывайтесь в бесконечное повторение одного и того же. Если ответ не заходит, сделайте шаг назад, подумайте, а чего от вас действительно хотят, и попробуйте другой заход.
👉Подумайте о вашем собеседнике – какие риски его волнуют, что поможет ему почувствовать себя в безопасности, что добавит уверенности в вас.
👉Прощупывайте, задавая уточняющие вопросы. Что-то вроде "Если расскажете, что для вас важнее всего, я смогу дать более релевантный ответ".
👉Когда вы сами задаете вопрос, старайтесь быть более явным, и озвучивать как контекст и все ваши глубинные вопросы.
Современные команды разработки всё чаще сталкиваются с ситуацией, когда сложность продукта растёт быстрее, чем скорость понимания его состояния. Особенно это заметно в распределённых системах, где сбой может долго оставаться незамеченным.
В этом контексте Yandex B2B Tech запустила Monium — платформу для мониторинга и управления состоянием ИТ-систем. Решение уже доступно всем внешним пользователям и создавалось командой Yandex Infrastructure для работы с высоконагруженными сервисами Яндекса.
Monium помогает быстрее выявлять источники проблем, объединяя метрики, логи и трейсы в одном интерфейсе. Для тимлидов и менеджеров это важный инструмент снижения времени реакции команды на инциденты и уменьшения простоев сервисов.
Платформа поддерживает Prometheus и OpenTelemetry, а также гибкую настройку алертинга и сценариев эскалации. Среди первых внешних тестовых пользователей — ОТП Банк.
28 марта Яндекс вновь проведет Dream → Teamlead: практическую конференцию для тимлидов, руководителей и технических лидеров
Собираемся, чтобы вместе с сообществом переосмыслить лидерство: будем говорить про принятие сложных решений и процессы, которые позволяют выстраивать эффективные и здоровые команды.
Программа делится на 2 трека — в первом эксперты будут обсуждать лидерство, как отдельную профессию. Например, Евгений Антонов, из команды Yandex Infrastructure, расскажет про стили лидерства и о том, как действовать при смене рабочего контекста. А Александр Поломодов из Т-Банка объяснит, как ИИ меняет инженерную культуру и что это значит для тимлидов.
Вторая часть программы практическая. Будет мастер-класс о производительности команды, воркшоп по созданию убедительной презентации и другие активности, где можно отработать управленческие навыки.
С полной программой докладов и других активностей можно ознакомиться на сайте. Для тех, кто не в Москве, будет доступна онлайн-трансляция докладов.
Регистрируемся и становимся частью дримтим комьюнити!
Amazon переводит стрелки с AI на людей
У Amazon за последнее время произошло несколько крупных падений, и как минимум в одном из них точно был замешан AI. Разработчик случайно оказался в продовом окружении вместо тестового, Kiro дернул команду не с теми флагами, и один из сервисов после этого лег. AWS во всех пресс-релизах после этого пытается всячески уйти от ассоциаций с AI, и говорит о том, что это человеческая ошибка – а в интернете на это смотрят как на попытку защищать AI.
С моей точки зрения AWS все правильно делает. Проблема не в том, что AI дернул не ту команду, а в том, как выстроены процессы разработки и гардрейлы вокруг него. Как вообще разработчик случайно оказался в проде и смог что-то там поменять? Почему команда с такими сайд-эффектами была вызвана без одобрения? Все это выглядит, как провалы в тулинге, и вообще не важно, детерменистическая или вероятностная система там под капотом.
Делаете RAG-ассистента и нужна база данных?
Попробуйте Managed PostgreSQL от MWS Cloud Platform с поддержкой расширения pgvector
RAG-ассистенты быстро упираются в хранилище данных: документы, метаданные, эмбеддинги и поиск по смыслу нужно где-то надёжно хранить и обслуживать.
В Managed PostgreSQL от MWS Cloud Platform это можно сделать в одном сервисе:
⏺️поддержка pgvector из коробки — хранение эмбеддингов и семантический поиск прямо в PostgreSQL
⏺️структурированные данные, документы и векторы — в одной базе
⏺️автоматические бэкапы и point-in-time recovery
⏺️постоянный primary endpoint — адрес не меняется при switch- / failover
⏺️до 3 read-only эндпоинтов для поиска и аналитики
⏺️гарантированный доступ к CPU, сетевые или NVMe-диски на выбор
Я запускаю закрытый клуб про AI в разработке
Так получилось, что я нахожусь практически в эпицентре того, что происходит с использованием AI в разработке – и благодаря моей основной работе в компании, которая делает девтулинг, и благодаря подкасту, и благодаря друзьям, которые горят этой темой. Но недавно я поймал себя на мысли, что я все равно испытываю жесточайший FOMO – индустрия меняется, а я за ней не успеваю.
Если эта проблема горит у меня, то скорее всего таких людей очень много. А я люблю решать проблемы – поэтому я решил собрать Podlodka AI Engineers Club – закрытое сообщество опытных разработчиков, которые хотят вместе разбираться с тем, как использовать AI с пользой, и делать это системно, а не на ощупь.
👉Как это вообще работает. Каждую неделю – воркшопы и лайвкодинг с людьми, которые активно используют AI, и внедряют его в реальные продукты и компании. Разбор конкретных инженерных практик: как строить своих агентов, как работать по Spec-Driven Development, как собирать комбайн, превращающий таски в Jira в PRы, как масштабировать это и на небольшую команду, и на всю разработку в бигтехе.
Между встречами – сеть закрытых чатов в Telegram, клубные созвоны, совместные эксперименты.
👉Кто уже в программе. Черновое расписание на март-апрель собрано. Среди экспертов – инженеры из компаний разного масштаба: Степан Гончаров (xAI), Роман Елизаров (Яндекс), Андрей Володин (Gracia AI), Андрей Бреслав (CodeSpeak), Денис Неклюдов (Google), Макс Страхов (Meta) и много других крутых ребят.
👉Как попасть. Клуб платный, вход через список ожидания с отбором – нам интересно сделать сообщество именно для опытных разработчиков. Мы набираем участников постепенно – нам важно сохранить атмосферу, в которой можно открыто делиться опытом и проблемами. Стартуем уже с понедельника!
Отдельно подчеркну, что клуб делаем именно для инженеров – людей, которые большую часть своей карьеры писали код, решали технические задачи, принимали архитектурные решения, и жили с их последствиями. Я знаю, что на канал подписано довольно много технических менеджеров, и senior/staff/principal инженеров – вот этот анонс для вас!
Подробности, расписание и заявка – на сайте. А если есть какие-то конкретные вопросы, пишите прямо мне в личку, @etolstoy!
Если вас всё чаще посещает чувство, что вы ничего не делаете на работе... вам лучше присесть ✨
Коллеги из Авито выложили интервью с Егором Денисовым-Бланчем, автором методологии измерения продуктивности разработчиков. Он провёл исследование и выяснил средний процент «инженеров-призраков» в IT-компаниях — 9,5%.
Напомним, что это те, кто числится в компании, но фактически не работает. Как проводилось исследование, как вообще рассчитывается продуктивность инженеров и что нам ждать дальше с приходом AI?
🗂 Смотрим на канале у коллег на одной из площадок: YouTube, Rutube или VK Видео.
Скорость разработки никогда не была проблемой
Все СЕО на интервью в модных подкастах рассказывают про свои команды так, как будто их бэклог уже был полон хороших идей, и единственное, что их ограничивало – это скорость разработки программистами.
Помню веселую байку из Авито, уже почти десятилетней давности. Весь менеджмент беспокоило, что ценных новых фичей появляется мало, доля рынка не растет, а конкуренты поджимают. Ругали, конечно же, неэффективную разработку – поэтому провелся большой реорг, всех пересобрали в автономные продуктовые команды, научили скраму и дейликам, и подкрутили архитектуру под такой сетап. Все стало очень эджайл, прозрачно, и понятно – но ситуация сильно не изменилась. Зато стало видно, что проблема была не в том, с какой скоростью задачи перемалываются, а в том, что продуктовые бэклоги были забиты какой-то фигней.
Вот и сейчас мы видим похожую историю. В подавляющем большинстве случаев внедрение AI не сильно изменит картину:
👉У людей внутри организации мало хороших идей, и много плохих. Вообще то, что идеи запиливать было долго и дорого, наоборот, могло вас спасать от некомпетентности.
👉У большинства ваших сотрудников нет особой мотивации быть суперпродуктивными и выкладываться на благо компании. Как и любые разумные люди, они работают 9-5, и идут домой к семье и своим делам.
👉Для нормальных людей польза от AI не в том, чтобы быть 10х эффективнее, закрывая продуктовый бэклог, а в том, чтобы тратить меньше своей ценной энергии.
👉Те несколько людей, которые действительно хотели свернуть горы, вместо этого сидят и ревьюят AI слоп, который нагенерировали все остальные, и постепенно выгорают.
👉И на фоне всего этого ваш финансовый директор постепенно начинает задавать вопросы про то, как так получилось, что все инженеры теперь стоят на несколько тысяч долларов дороже из-за токенов, которые они прожигают.
AI не уменьшает количество работы, а делает ее более интенсивной
In an eight-month study of how generative AI changed work habits at a U.S.-based technology company with about 200 employees, we found that employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day, often without being asked to do so.
Как сделать программиста счастливее
1️⃣Status – ощущение профессиональной значимости. На него влияют публичное признание вклада, конструктивная обратная связь, вовлечение в принятие важных решений, как технических, так и продуктовых.
2️⃣Certainty – предсказуемость и ясность. С этим помогают понятные цели, хотя бы на краткосрок, наличие смысла за задачами, логичные объяснения причин изменений, доверие к решениям менеджера.
3️⃣Autonomy – контроль над своей работой. Важно иметь возможность самому планировать и свою работу, и то, как она будет делаться, без микроменеджмента, контроля и советов под руку.
4️⃣Relatedness – чувство принадлежности и безопасности. Этот пункт про команду, которой ты доверяешь, с которой разделяешь общие цели, и вместе с которой тебе кайф работать.
5️⃣Fairness – ощущение справедливости. Больше всего его рушит чувство несоответствия между твоими усилиями и вознаграждением. Поэтому работать над этим менеджеру надо, устанавливая понятные правила игры для всех, компенсируя похожим образом похожие результаты, и оставаясь последовательным (см пункт про ясность и предсказуемость).
🤝 «Дружить нельзя обидеть. Как руководителю выстраивать отношения с сотрудниками». Вебинар Яндекс Практикума
90% начинающих управленцев пытаются совместить роли друга и босса. Такие отношения укрепляют коллектив, но в то же время сковывают руководителя. Особенно когда нужно принимать непопулярные решения, критиковать сотрудника и выстраивать единые правила для всех.
Как сохранить доверие и при этом не размыть управленческие границы? Узнайте на вебинаре Практикума 19 февраля.
💬 О чём поговорим:
▪️ Что такое дружба на работе и почему некоторые работодатели против
▪️ Чем опасно смешение ролей
▪️ Как дружба сказывается на остальной команде
▪️ Что о подобных отношениях говорят учёные
👩🏫 Спикер: Галина Лебедова, руководитель B2B-направления Яндекс Практикума, 19 лет в управлении командами
🕚 Начало: 19 февраля в 11:00, онлайн
🎁 Бонус для участников вебинара: самоучитель по ИИ в подарок! Подробнее об акции расскажем на встрече.
→ Зарегистрироваться
Реклама, ООО Яндекс, ИНН 7736207543, erid: 2Vtzqvk9T64
Большинство российских компаний (74%) сейчас оптимизируют бюджеты. В том числе сокращая персонал.
Но не задачи.
Чтобы успевать больше с меньшими ресурсами, нужна «суперсила» для сотрудников. И это — ИИ, который снимает рутину, ускоряет процессы и повышает качество решений.
Внедрите ИИ в своей команде уже сейчас. Обучите сотрудников ИИ-навыкам в Яндекс Практикуме:
⚡️ Воркшопы по внедрению ИИ. Офлайн- или онлайн-интенсивы с экспертами, которые внедряют нейросети в Яндексе.
⚡️ Курсы по ИИ-навыкам. Углублённое онлайн-обучение нейросетям руководителей, маркетологов и других сотрудников. Фокус — на типовые задачи и рабочие кейсы.
→ ИИ-зировать бизнес с Практикумом
🎁 Оставьте заявку на сайте и получите в подарок самоучитель по ИИ для руководителей! Сделайте первый шаг по внедрению технологии.
Про бэкграунд агентов
Очень хороший ликбез по тому, как работают бэкграунд агенты и как их правильно оркестрировать. А главное – как они могут повлиять в будущем на ваш SDLC, и как это изменит роль инженеров.
Как руководителю пережить оценку эффективности сотрудников?
Оценить работу подчинённого — половина задачи. Куда сложнее сесть напротив и честно поговорить о результатах: особенно если человек не согласен, расстроен или задаёт неудобные вопросы.
Важно удержать баланс: быть внимательным к эмоциям, при этом не размывать обратную связь. Иначе разговор закончится не договорённостью, а потерей мотивации или даже сотрудника.
📌 12 марта в 20:00 (мск) лаборатория навыков коммуникации Софт Скиллз Лаб проведет бесплатный вебинар, на котором расскажет, как пережить сезон оценки эффективности и сохранить отношения с подчиненными.
За 1,5 часа разберете:
▫️ Как переводить эмоции в конструктив?
▫️ Что делать, если сотрудник не согласен с вашей оценкой?
▫️ Как давать обратную связь, которая поддерживает, а не демотивирует?
Весь материал разберете на реальных кейсах, вы сможете отправить свою ситуацию в анонимную гугл-форму.
🗣 Спикер — Михаил Ромашов, ведущий тренер Софт Скиллс Лаб, преподаватель по переговорам в ВШЭ и Сколково, автор книги «Эффективный конфликт», владелец продукта в SberCIB.
Встреча пройдет в Zoom, поэтому вы сможете задать Михаилу любые вопросы.
👉🏻 Запустите бота, чтобы получить ссылку на конференцию!
Почему продакты не должны коммитить в прод
Последний год долг чести каждого продакта – похвастаться, что он самостоятельно завайбкодил и выложил целую фичу в прод без участия разработчиков. Почему это антипаттерн:
👉Если фича действительно важна, а ее не делали, то лучше исправить сломанную систему приоритизации
👉Продакт программирует в лучшем случае как джун, а стоит компании как сеньор
👉Если продакты начнут рандомно запускать свои пет-проекты, то технический долг начнет бесконтрольно накапливаться
👉Когда продакты пушат своих знакомых сеньоров поревьюить их код, они довольно бесполезно тратят их время
👉Фичи от продактов чаще всего дают только иллюзию того, что что-то делается, и материал для поста в LinkedIn, а не реальный импакт
В каких случаях продактам надо программировать:
👉Чтобы сделать прототип, который лучше объяснит команде их идею
👉Чтобы лучше понимать устройство системы. ее ограничения
👉Чтобы проводить быстрые эксперименты с пользователями с использованием близких к реальности прототипов
👉Чтобы в редких случаях использовать какие-то свои уникальные доменные знания
Результаты опроса про использование менеджерами AI
Пару недель назад я закидывал в канал опрос, в котором спрашивал вас, в каких категориях задач вы используете AI, и где он приносит вам больше всего пользы. Как и обещал, вот результаты!
👉Самые популярные категории: редактирование текста (ага-ага, а потом жалуемся, что текст стал дешевым), анализ текста, программирование, создание конспектов встреч и помощь в принятии решений.
👉А вот самый максимальный эффект помимо категорий работы с текстом AI дал в саморазвитии – составлении плана собственного роста, симуляции сложных тем и разговоров.
👉"Максимальный эффект" – это, в первую очередь, ускорение работы и повышение ее качества, на третьем месте – уменьшение стресса от задачи.
👉Менеджеры неплохо научились экономить время с помощью AI. Треть экономит больше 8 часов в неделю, еще четверть – от 4 до 8.
А вот и некоторые из конкретных кейсов, забирайте себе идеи:
• проработал 121 с коллегой консерватором, как лучше к нему подойти, что использовать, чтобы посеять в нем зерно и готовность к изменениям, сам меняться не хотел и я не мог подобрать ключикЧитать полностью…
• Сделал бота, которому пересылаю сообщения из телеграма и он создает задачи в Джире. Тот же бот трекает время при необходимости.
• Создание встреч в календаре с голоса
• granola.ai собирает все звонки команды, раскладывает их по папкам, у меня есть чатик с контекстом каждой папки Фан факты: есть отдельные папки по вакансиям при найме, удобно по конкретной вакансии сравнивать кандидатов Отдельный кейс: ИИ-ревью тестовых заданий кандидатов
• Автоматическое ведение деловой переписки на английском. Я наговариваю голосом ответы, получаю готовые сообщения в Teams, письма в оутлук, материал для презентаций
• Делегирую ИИ формулировку задач. Пишу поток сознания с идеями и гипотезами, а ИИ формулирует задачу так, чтобы разработка/проектирование могли максимально быстро и точно понять требования. Ещё один пример - обработка фидбека в свободной форме - он сваливается в таблицу, откуда ИИ разбирает его и систематизирует по категориям. Это позволяет отсортировать самые популярные запросы (больше всего обращений с такой болью) и взять их в работу
• Задача: исчерпывающе описывать технические задачи. С продуктовыми проблем нет, т.к. их описывают аналитики. Технические таски часто были слишком абстрактными. При помощи ChatGPT получилось формировать описание, которые вызывает минимум вопросов у разработчиков. Для этого сделал отдельный проект с указаниями задавать вопросы от лица разработчика до тех пор пока не будет понятно что нужно сделать (на уровне целей и критериев успеха, не пошаговых инструкций)
• Использую агента для саммаризации под конкретных людей
• На основании митингов, AI ассистент предлагает создать конкретные задачи в jira. Я только апрувлю. Почти не приходится редактировать.
• Написание документов и инструкций - все пишу через ии. Разбираю рабочие ситуации и даже конфликты с коллегами и ии подсвечивает где как лучше сделать. Далее уже выбираю что считаю нужным. Строю личные планы развития и практикуюсь прямо с ии
• Подготовка к защите оценки на perfomance review. Чат гпт загрузила матрицы компетенций, результаты полугодия, шаблоны, примеры, попросила сопоставить сильные стороны подчиненных. Это помогло сократить время на анализ данных, но до финального вида сама доводила.
Как AI меняет SDLC
Еще один взгляд на то, как фундаментальные свойства агентской разработки могут в скором будущем поменять весь SDLC:
👉Классический SDLC (Requirements->Design->Code->Test->Review->Deploy) представлял из себя довольно долгий цикл, который в лучшем случае мог занимать несколько часов, а в худшем – недели и месяцы. В работе с агентом этот цикл схлопывается и становится намного быстрее – и в отличие от классического может прогоняться очень много раз.
👉Этап сбора требований размазывается по нескольким прогонам такого цикла – нет смысла заранее сильно вкладываться в спеку, если многие детали можно будет обраружить после первой наивной попытки реализации фичи.
👉Похожая история и с этапом дизайна. Разумнее становится не пытаться проработать всю архитектуру до старта задачи, а дать агенту правильный контекст, вместе с ним исследовать возможные опции, и выбрать подходящую вам по трейд-оффам.
👉TDD становится дефолтной методологией, а не чем-то, о чем чаще всего рассказывают на конференциях.
👉Code review должен отмереть в своем текущем виде – человек должен вовлекаться в цикл только в том случае, когда агент сам не может принять какое-то важное решение. В остальном роль человека – выстроить правильный harness, чтобы цикл мог исполняться без него.
👉Аналогично и с deployment, он должен происходить автоматически, без участия человека – но мониторинг становится еще более важен.
Организации оптимизируют под комфорт
Любая система стремится оставаться в состоянии покоя. С инженерными организациями ситуация такая же. Они оптимизируют работу не под техническую корректность, а под комфорт.
Почему так происходит:
👉Исправление проблем создает видимое неудобство прямо сейчас. А неисправление невидимо, пока не случится инцидент. Организации всегда выбирают невидимое, ведь инцидент всегда можно списать на случайность, если он вообще произойдет.
👉Чаще всего изменения требуют согласия тех, чье поведение должно измениться. Эти люди конечно же голосуют против.
👉Этому очень способствует наличие ответственности за решение последствий проблем без полномочий эти проблемы предотвращать. Условно, если вы чините аварии, это не дает вашему голосу больше веса, чем у остальных участников команды.
👉Часто споры вызывает не само конкретное изменение, а в целом попытка расшатывать устоявшуюся систему.
Текст стал дешевым, и мы к этому не готовы
Управление большими корпорациями всегда строилось на довольно простом принципе – если что-то важно, это надо записать. Написать хороший связный разумный текст было сложно. Это требовало понимания проблемы, усидчивости, и, главное, это требовало от человека подумать. Текст работал как фильтр – если кто-то его написал, то скорее всего мысли, изложенные там, имеет смысл прочитать.
Генеративный AI все изменил. Текст любой длины можно сгенерировать за секунды, и само наличие письменного артефакта вообще не гарантирует, что кто-то туда вложил хоть частицу разумности.
Из-за этого текстов стало больше, а вот ресурса человеческого внимания – нет. Чтобы понять, надо ли в них вчитываться, приходится использовать другой AI, который готовит выжимку мыслей, и получается абсолютно бессмысленный и беспощадный цикл.
Что конкретно с этим делать, пока не очень понятно. Автор поста предлагает развилку с двумя вариантами:
👉Смириться, и жить в цикле, в котором между двумя людьми всегда будут находиться AI агенты, кодирующие и декодирующие поток мыслей.
👉Переизобрести примитив, который обозначает ответственность за мысли и идеи. Требовать краткость, явное авторство, что-то еще, что заставит людей подумать перед тем, как отправлять кому-то свой текст.
Про влияние тренировок на менталочку
Так, я опять про личное. Единственный вид отдыха, который у меня получилось добавить на регулярной основе, и который очень заметно помогает стряхивать с себя весь рабочий стресс – это силовые тренировки. Почти весь прошлый год получалось ходить по семь раз в неделю, после появления ребенка, правда, уменьшил до четырех – но все равно, эффект на менталку чувствуется огромный.
Вот как раз еще одно большое исследование на эту тему вышло – регулярные тренировки оказывают на депрессивные состояния такое же влияние, как терапия, и в целом даже сопоставимы с антидепрессантами. С долгосрочными эффектами правда не очень понятно – поэтому путь один, купить абонемент и не бросать!
Отдых – это не награда за какие-то действия, это часть полноценной и насыщенной жизни.
Почему быстро выпускать новые фичи – это плохо
Продолжаем тему пятничной статьи. Ограничением того, сколько новых фичей вы можете выпускать, могут быть не внутренние возможности компании, а конечный ресурс внимания ваших пользователей. Например, если вы делаете B2B продукт, то вне зависимости от того, с какой скоростью вы будет добавлять новые фичи, большинство клиентов будет адоптить в лучшем случае одну в течение нескольких месяцев.
В итоге, ускоряя команду, вы на самом деле создаете невидимый бэклог фич, которые сделаны, но не используются, растягиваете time-to-value, ну и постепенно роняете качество.
И вместе с этим я напоминаю, что вот уже сегодня начнется бесплатная большая конференция Стратоплана как раз про то, как AI меняет процессы разработки – поэтому, если сердце за происходящее у вас болит, обязательно заглядывайте!
Зовем на максимально практическую онлайн-конференцию Podlodka Techlead Crew «Архитектура данных», 2-6 марта.
Пригодится техлидам, которые хотят меньше теории и больше рабочих решений без ненужного хайпа.
А в надежном комьюнити можно обсудить доклады ❤️
«Идет долгий тренд на оптимизацию ресурсов и подсчет затрат на инфраструктуру.
Востребованы инженеры, которые могут разобраться, как оптимизировать потребление ресурсов хранилища, как быстрее и эффективнее работать с ними»,
— объясняет главный принцип выбора темы директор Techlead Crew Григорий Скобелев.
Расскажите, как вы используете AI
В своем докладе на конференции Стратоплана, про которую я писал утром, я хочу поделиться не только своим опытом, но и тем, как AI используют другие менеджеры. Я собрал небольшой опрос, и очень прошу вас рассказать про свой опыт – в каких категориях задач вы использовали AI, где он локазался действительно полезным, и какие примеры вас впечатлили больше всего.
Конечно же, по нашей традиции среди всех участников я разыграю сертификаты на хорошие книги – на что еще тратить сэкономленное время, как не на чтение!
👉Ссылка на опрос
Конференция от Стратоплана про AI для менеджеров
Как вы видите из постов в канале, влияние AI на нашу индустрию можно аккуратно охарактеризовать как неоднозначное. Да, каждый отдельный разработчик может решать больше задач, чем раньше – и в плане количества, и в плане разнообразия. Но, как гвоорит нам Теория ограничений, повышение эффективности узлов системы не только не ведет к повышению ее общей эффективности, а наоборот, может ее ухудшать. И мы видим прям ровно то же самое: качество продуктов только падает, инфраструктурных инцидентов становится больше, количество технического долга растет, разработчики становятся несчастнее – и при всем при этом не то, чтобы у нас заметно выросло количество успешных компаний.
Стратоплан, которые делают много крутых образовательных программ для менеджеров, и Entropy Talk, которые делают конференции про AI, объединились, чтобы поговорить о том, как AI влияет на уровень команд и бизнеса – разобрать реальные кейсы, показать, как AI меняет управление в разработке, и помочь выработать ментальные модели, которые помогут выжить в этом новом мире.
В программе уже куча классных докладов:
👉Про то, меняют ли AI агенты процессы обучения, найма и увольнения
👉Почему внедрение AI упирается не в технологии, а в людей
👉Как инфраструктура становится блокером, и как победить эту проблему с ограниченными ресурсами
В этот раз впервые за ооооочень долгое время, я тоже решил выступить с докладом! Я решил выбрать максимально прикладную тему личной эффективности руководителя – и расскажу про разные неочевидные примеры того, как AI может улучшить вашу менеджерскую рутину. Например, про анализ антипаттернов своего поведения на базе расшифровок встреч, или про использование OpenClaw для ведения личных карточек своей команды!
Помимо меня будут выступать Head of AI и СТО крупных банков, ex-CTO Booking и EM из Mapbox, Степан Гершуни и Глеб Кудрявцев, Артем – ex-FAANG и автор «эйай ньюз», а также со-основатели Школы Стратоплан Вячеслав Панкратов и Александр Орлов и идейный вдохновитель Entropy Talk.
Участие – бесплатное (но если захотите заплатить за сертификат, то тоже можно).
📆24-26 февраля, онлайн + запись
🔗Регистрация здесь
Что такое Context Graph
Разбираем новый модный термин Context Graph. В чем идея – организации в целом довольно неплохо справляются с тем, чтобы записывать результаты своих решений. Отсюда берутся все те тысячи тикетов в вашей системе и разные документы, лежащие в папках на гугл диске. Но в большинстве случаев, записываются только результаты решений, а не их контекст – как и почему они были приняты. Поэтому, когда спустя какое-то время никто не может объяснить, почему вообще так было сделано.
Проблема-то не новая, даже в канале я постил очень много материалов про то, как вести разнообразные decision records – для архитектуры, процессов, решений по людям. Но в реальной жизни поддерживать и ответственно вести их очень дорого, особенно если речь идет о кроссфункциональных процессах. Какие-то обсуждения ведутся в комментариях к тикету, какие-то – в комментариях к документу с контрактом, какие-то в тредах в Slack – и никто не будет соединять все кусочки этой информации.
Вот тут в игру и вступает контекстный граф. Это автоматическая система трекинга того, как, почему и кем принимаются организационные решения, когда и какие исключения из них были приняты, каким образом были выданы аппрувы. Короче говоря, поиск релевантного контекста во всем огромном массиве организационных переписок и документов.
Пока это скорее идея, которая очень интересна большому количеству стартапов. В реальности я еще не видел, чтобы оно работало хорошо. Инфраструктура для чего-то похожего точно есть у Gleam, которым мы пользуемся на работе, но релевантность там пока оставляет желать лучшего – да и UX удобный точно еще надо будет придумывать.