Недавно помогал коллеге готовиться к ретро, он помочь попросил. Кейс такой: у них провалился проект, и буквально всё пошло не так:
1. Сорвали сроки.
2. Огромный перерасход бюджета.
3. Почти по каждой задаче фактические затраты разработчиков превысили оценки.
4. Конверсия упала, пользовательский путь запутался.
5. Куча ошибок прямо на релизе, из‑за чего службу поддержки неделю держали на переработках.

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

У ребят своя специфика, но то, что мы используем в продуктовых командах, не сильно отличается — адаптируйте под свою компанию, команду и особенности, и можно применять.

Первое, что нужно сделать — обозначить общую проблему, желательно одной фразой, например: «+83 % человеко‑часов, сорван релиз, ошибки на основных пользовательских путях в проде».

После того как проблему обозначили, собираем все данные, которые доступны. Понимаю, что не у всех производство обложено метриками и дашбордами. Чтобы собрать инфу, пересматривать запись каждого дейли наверное не нужно, но попытайтесь собрать максимум. При проблеме, сформулированной выше, сразу приходит в голову:
• план/факт часов из трекера;
• список дефектов;
• история коммитов и релизов;
• все изменения требований и сметы;
• ключевая коммуникация и этапы принятия решений.

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

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

Составляем сводку на доске в Миро. Таблицы кому‑то удобны, но доска нагляднее. Выписываем:
• проблему;
• гипотезы причин от команды;
• метрики и цифры, которые удалось собрать;
• при желании — цепочки событий и принятых решений.

Сама ретроспектива. Проводить стоит онлайн. Ребята думали, что часа хватит, но выяснилось, что нужно 2-3, иначе объемный проект не обсудить.
• Открываем встречу. Объясняем, что ищем причины и пути улучшения, чтобы в следующий раз не допустить факапов; фокус на фактах, а не на обвинениях.
• Разбираем причины. Методик куча, но можно разложить на четыре стрима. Для проблемы «копили изменения четыре месяца» получается:

– Процессы: нет плана релизов, ритма поставок;
– Люди: на проекте не было техлида, который полностью отвечал за проект;
– Технологии: нулевое покрытие тестами;
– Требования: после согласования основных контрактов вносились изменения в ТЗ и макеты.

Записываем всё, что нашли. Банально, но не критикуйте в моменты сбора причин. Сначала вытягиваем всё, что можем, потом отсекаем лишнее.
• Генерируем решения вместе с командой. Опять же, любой фреймворк приоритезации, хоть точками голосуйте, главное - это отсеять лишнее и выделить основные решения, которые затем распределим по людям.
• Выделенные решения можно оформить по SMART, назначить ответственных и поставить дедлайны, ну, сами знаете :)

Обычно не делают, но кажется полезным. Занесите результаты ретро во внутреннюю базу знаний. Если её нет, самое время завести: без фиксации выводы теряются, ошибки повторяются, команда топчется на месте.

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

*Кликбейтный заголовок про бесполезность книг

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

После того, как уперлись в этот порог, лучше переходить на отраслевые медиа, журналы, конкретных авторов. Статьи, посты или описание опыта, которые публикуют не ради трафика, дают кратно больше ценности.

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

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

Станьте знаменитыми и богатыми или присылайте свои доклады.

Попал в программный комитет секции «Рост продуктивности команд» на конференции AGDays 2025, конференция проходит уже пятый год подряд, совместно с Tagline. В секции проджекты, продакты, тимлиды и CTO обсуждают, как прокачивать техническую команду без токсичности и микроменеджмента. Ближайшие несколько месяцев, вместе с командой комитета, буду отслушивать ваши доклады.

Если у вас есть опыт публичных выступлений, вы опытный менеджер или руководитель, работаете в известной на рынке компании, у вас есть тема, в которую вы глубоко погружены или интересный кейс, про который хотите рассказать – напишите мне, обсудим ваше выступление :)

Когда конференция и что вас ждет.

31 октября (пятница) — старт и препати:

• Digital Tour by Doubletapp — на прошлых турах мы заглянули в «Контур», «Жизньмарт», «Восход», «Галамарт» и другие компании. Кто откроет двери для участников AGDays в этом году? Doubletapp объявит совсем скоро!
• Halloween-вечеринка 🎃 — препати 31 октября. В программе: эффектные образы и декорации, конкурсы и много знакомств.

1 ноября (рабочая суббота) — деловая часть в Домне:

• Секция «Рост бизнеса» — якорный поток с докладами и бизнес-разборами компаний, с которых началась конференция. Тема этого года — IT-компании в новой реальности: выход из кризиса и поиск добавочной ценности.
• Секция «Рост продуктивности команд» — рассказал про неё выше.
• Секция «Рост eCommerce» — новый поток, который появился из отраслевой экспертизы и нетворка Alto. Вместе с ecom-директорами поговорим о взаимодействии IT и маркетинга, удержании клиентов и всем, что влияет на масштабирование онлайн-торговли
• Afterparty прямо на площадке, а потом на выбор: кальян, танцпол, караоке или всё сразу

2 ноября (воскресенье) — и длинные ноябрьские выходные в Екатеринбурге:

• Экскурсия по городу
• Завершается конференция в банном комплексе с максимальным жаром, профессиональным парильщиком. Я никогда шарм бань не понимал, но видимо всем нравится :)
• Ну а дальше — три дня выходных с ресторанами, барами и маршрутами, вместе с крутым IT-комьюнити.

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

Мне сказали, чтобы я ничего серьезного в пятницу не постил, поэтому вот, не самый серьезный пост. Недавно пытался объяснить, как работают JTBD и маркетинговые воронки на кальянах, публикую примерное содержание разговора. @altoivan Наверное тут нужное экспертно-кальянное ревью :)

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

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

Когда ваш друг стал интересоваться темой, вам нужно найти подходящие для него джобы, чтобы засетапить ситуацию, в которой все ещё не очень полезная кальянная может ему пригодиться. Вы начинаете ресерчить, и оказывается, что у него дома часто отключают свет, и у него есть потребность в тихом месте с хорошим вайфаем и удобным столом, где он может поработать, пока свет не вернут обратно. Кальянная как раз располагалась в пяти минутах от дома, днем в ней мало людей, там играет очень тихая музыка, столы удобные. Джобу нашли, кальянную, которую можно нанять для её выполнения тоже. Теперь нам нужно дождаться ситуации и подтолкнуть к сделке :)

В один из дней свет выключается, вы видите гневное сообщение в чате: "Свет опять отключили, попробую найти тихое место, частично на связи". Моментально пишете своему товарищу, предлагаете тихое местечко, показываете интерьер. Тут вы уже берете на себя функции отдела продаж, отвечаете на его вопросы, уточняете потребности, рассказываете о преимуществах похода в кальянную вдвоем: "Там и кальян сущие копейки начинает стоить, и куришь ты не так много, вред минимальный, давай, вперед!".

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

Как управлять командой без техлида

Исследования bigtech-компаний постоянно подтверждают, что команды с техническими лидерами показывают значительно лучшие результаты:
- Существенно меньше багов в продакшене
- Быстрее принимают технические решения
- Реже сталкиваются с архитектурными проблемами

Но что делать, если техлида в команде нет, а найти его прямо сейчас невозможно?

Типичный сценарий
PM без технического бэкграунда получает команду из 5+ разработчиков. Что происходит дальше:
- Разработчики часами спорят о простых задачах
- Обсуждают масштабирование для проекта с 10 пользователями
- Придумывают корнер-кейсы, которые никогда не случатся
- Задачи обсуждаются, но не делаются

Главная ошибка, которую совершает большинство PM
Попытка изобразить из себя техлида. Лезть в технические обсуждения, пытаться принимать архитектурные решения :)

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

Что бы посоветовал я:
1. Станьте диспетчером, а не изображайте эксперта. Ваша задача — организовать процесс принятия решений, а не принимать их самостоятельно. Назначайте ответственных за конкретные технические решения, фиксируйте договоренности, следите за выполнением.

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

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

4. Декомпозируйте. Любая задача должна укладываться в 1-2 дня. Маленькие задачи сложнее переусложнить и проще контролировать. Аналитик может ставить функциональные куски в виде пользовательских историй, а до задач в 1-2 дня декомпозировать может уже сам разработчик.

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

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

Фокусируйтесь на том, что умеете лучше всего: планировании, коммуникации и контроле исполнения, снимайте с ребят непрофильные задачи, управляйте процессом и модерируйте споры, это поможет вам поднять производительность команды.

Давно ничего не писал, потому что был завал на релизах и в личку сыпалась куча вопросов, исправляюсь)

В LinkedIn после публикации кейса про БЗ с ЛЛМкой спрашивали, какие метрики мы используем для того, чтобы убедиться, что внедряемое ИИ-решение соответствует ожидаемым результатам, решил написать об этом и поделиться метриками, которые использовали на старте и сейчас.

Я уже рассказывал, что у моей команды основные силы сейчас сосредоточены на платформе, которая закрыла бы все внутренние задачи сотрудников ВВ, в том числе управление знаниями. Я вообще убеждён, что все, кто работает внутри компаний и как-то связан с knowledge management’ом, будут прикручивать к своим базам RAG-системы, чтобы получить возможность общаться с ними в виде чата. Мы такой проект уже реализовали — сейчас в него постепенно перетекает основная группа пользователей. Чуть позже напишу статью про экономический эффект от внедрения такого инструмента, но спойлер: на масштабе экономит он много.

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

В итоге пришли к тому, что всех этих тестирующих потом нужно повторно проверять, потому что сами работающие сотрудники не всегда знают, правильный ли ответ им выдаёт модель. Поменяли флоу и убрали все метрики, кроме оценки «хорошо»/«плохо»: в интерфейсе решили просто выводить лайк и дизлайк под каждым ответом, потом проверять самыми опытными ребятами общую выдачу и собирать эталонные ответы. Сейчас у нас удовлетворённость больше 90%, отрабатываем жалобы на совсем редкие кейсы.

Ну и как всегда это бывает, после того как к нам пришло 20+ команд и загрузили свои знания, обрабатывать все вопросы одинаково хорошо через 1 модель не получилось, некоторые команды из-за размеров и особенностей чуть ли не в отдельный продукт сейчас выделяем, об эволюции в области управления знаний у нас тоже расскажу позже, с этим сильно помог Ваня Замесин, когда у нас воркшоп в ВВ проводил :)

Нанимаю в команду

Сейчас 2 открытые позиции, ML-инженер и Техлид.

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

У нас классная кросс-функциональная команда, с бизнес и системными аналитиками, backend, frontend и ML разработчиками, своим дизайном.

Очень важно иметь опыт реализованных коммерческих проектов с использованием RAG-систем.

Подробности смотрите тут:
1. https://perm.hh.ru/vacancy/127597188?hhtmFrom=employer_vacancies
2. https://perm.hh.ru/vacancy/127595268?hhtmFrom=employer_vacancies

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

Читайте, что получилось: https://t.me/news_vkusvill/1156