Кто я и чем занимаюсь.

Работаю во ВкусВилле, руковожу портфелем AI-проектов.

Вместе с командой запускаем платформу Гала для всех сотрудников ВкусВилла, масштабируем продукты и сервисы. Берем на себя все задачи, где AI или IA может оказать положительный эффект на бизнес и его экономику.

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

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

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

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

Как я пытался читать книги быстрее — и что из этого вышло

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

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

Результат оказался средним.

Что работает плохо:
Книги про мышление, майндсет, установки. Основные тезисы вроде остаются, но теряется глубина. Ощущение, что книгу "пересказали", но не прожили.

Что работает отлично:
Книги, где есть структура: фреймворки, подходы, методологии. Их как будто специально писали для такого формата. Воду срезает, инструменты остаются. Можно тут же остановиться на любой главе и подумать, как применить в своих задачах — весь контекст по моей работе у чата уже есть.

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

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

Если интересно, вот шаблон, который использую:

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

Процесс обработки книги:
Шаг 1: Детализированное разложение структуры
• Книга → Главы → Разделы → Подразделы → Конкретные темы.
• Подробно зафиксируй иерархию материала и взаимосвязи внутри структуры.

Шаг 2: Глубокое извлечение смыслов
• Для каждого элемента структуры выпиши центральную мысль, аргументы и примеры автора.
• Обеспечь полное сохранение контекста и деталей из первоисточника.

Шаг 3: Подробное выделение и описание инструментов
• Извлеки каждый практический инструмент, описанный автором, и структурируй его в виде пошаговой инструкции.
• Проиллюстрируй каждый шаг примерами строго из книги.

Шаг 4: Перевод инструментов в навыки с контролем
• Опиши, как именно инструмент становится навыком: последовательность действий, частые ошибки, лайфхаки от автора.
• Добавь критерии, по которым можно проверить успешность освоения навыка.

Шаг 5: Итоговая сверка и итоговый справочник главы
• Проверь с помощью чек-листа, чтобы ни один смысл, идея, инструмент не был утерян или искажён.
• Сформируй финальный итоговый справочник по главе:
• Центральные тезисы и смыслы.
• Инструменты с инструкциями.
• Примеры использования из книги.
• Критерии оценки освоения навыков.

Около года назад мы с партнёром получили грант на развитие пет-проекта. Тогда решили пойти в акселерацию и фаст-трек от «Сколково». Несколько месяцев тратили на исследования рынка, упаковку продукта и определение TRL.

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

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

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

Год назад такой инструмент сэкономил бы нам кучу времени.

Если хотите попробовать, держите мой промпт для проверки бизнес-идей.

Закидывать сюда не стану, слишком длинный пост получится :)

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

Мне такой подход в целом не очень нравится, не понимаю, какую ценность такие курсы дают. Что есть на курсе:
1. Около нулевое внимание ментора
2. Группа людей уровня вас или около того, с которой можно чатиться
3. Текст курса и практические задания в вебе

Стоят такие курсы обычно 100-200к рублей.

Что предпочитаю делать я:
1. Залезть в интернет, да даже на сам сайт с курсами и скачать там программу курса, посмотреть роудмапы
2. Сделать проект в ChatGPT (или подставь ЛЛМ, которая больше нравится), дать максимально много информации о своем опыте, о своих навыках.
3. Скормить в этот же чат требования из 10-15 вакансий компаний, в которые вы хотите попасть
4. Попросить чатик сделать вам тест, который вы сможете пройти прямо в нем, чтобы он вас поскорил
5. После скоринга попросите составить роудмап и понедельный план обучения

Что делать, если встали?
1. В курсах есть чатики со студентами и кураторами. Вы можете найти открытые компьюнити или найти в линке действующих экспертов, обычно они отвечают на вопросы, если не спрашивать что-то нудное или совсем очевидное.
2. Если совсем уперлись и ну ничего не понимаете, бывает такое со статистикой, математикой или каким-то ЯП, тогда просто зайдите на какой-то сайт, где есть услуги преподавателей и репетиторов, создайте заявку, выберете преподавателя из университета или из компании, в которую хотите попасть, он может вас ещё и зарефералит. Час у таких ребят стоит 2500-4000 рублей, на выходе, даже в самом худшем случае, за цену курса вы получите 30 часов индивидуальных консультаций, что кажется сильно более ценным, чем чатик с ментором, с которым даже созвониться нельзя.

Интересные выводы, к которым пришли после разговора с командой стратегии Спортмастера

• Рекомендательные модели не дают вау прироста. Подбор товаров даёт ощутимый, но всё равно умеренный эффект.

• LLM-чат с базой знаний дал наибольший экономический эффект, особенно, когда чат-бота выводят напрямую к пользователю. Тогда расходы на поддержку пользователей падают кратно, в первую очередь ФОТ. У нас в ВВ внутри одна из ключевых ценностей — живое общение с оператором, поэтому напрямую клиентам такой чат не даём. Но сами операторы используют его и экономят время — это сокращает расходы на обучение, снижает нагрузку на ФОТ и одновременно растит NPS. Сплошные плюсы.

• Оптимизация «снизу» почти не рождается. Пока не включают рычаг (например, урезание бюджета), люди не ищут, как оптимизировать процессы. Кто-то делает и сам, но таких мало и без системного подхода.

• Генеративный контент для карточек — все ждут, решений нет. Спрос высокий, рынок — пустой. Особенно актуально для fashion-ритейла. Окно возможностей для продуктов.

• AI работает лучше там, где уже есть порядок. Систематизация процессов даёт больший эффект, чем сама AI-надстройка. Больший эффект получается от упорядочивания знаний, чем от добавления той же ЛЛМки.

Два интересных ввода из обзора Pulse of the Profession 2024 от PMI, которыми хочу поделиться:

1. Энейблеры или катализаторы роста (не нашел перевода лучше) напрямую влияют на затраты и производительность. PMI называет катализаторами любые системные программы, которые помогают людям расти: менторинг, обучение новым навыкам, сообщества практик, ресурсы для ментального здоровья и т. д. Компании, предлагающие три и более таких программ, показывают производительность на 11% выше, а scope creep случается на 9% реже.

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

2. PMO, который не только контролирует процессы, но и культивирует обучение (менторинг, обмен знаниями, обучение новым практикам), в 2 раза чаще превышает прошлогодний рост выручки и в 3 раза чаще демонстрирует скачок клиентского NPS. Такие PMO становятся внутренним акселератором, связывая эти самые катализаторы с метриками портфеля и бизнес-результатами. На мой взгляд, крайне важно умение не просто абстрактно чему-то обучать, а подсвечивать команде дорожку обучения, которая помогает и интересная не только сотруднику, но и компании.

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

Как Claude с MCP-сервером может ускорить вашу работу и сделать её более приятной.

Наверняка ловили себя на мысли: «Было бы круто, если бы GPT сам зашёл в переписку, сделал саммари, разбил всё по шаблону, расписал задачи и вытащил нужную цитату — пока я допиваю кофе».
Я пробовал экспортировать чаты, копировать сообщения руками, даже клеил связку n8n + бот. Оно работало, но ощущалось так себе, все разбросано по разным окнам или неудобно. Для себя нашел решение в Telegram MCP Server.

Немного матчасти:

MCP (Model Context Protocol) — это договорённость, по которой ваш LLM-клиент (Claude Desktop, Cursor…) и внешний «сервер» общаются через JSON-RPC 2.0.
У модели наконец появляются реальные руки: она может читать чаты, тащить медиа, пушить задачи — а вы видите лишь готовый результат прямо в диалоге.

Как настроить:
1. Заходим в репозиторий, следуем инструкции :). Если консоль пугает, скормите инструкцию в какую-нибудь o3, разберетесь с ней за пол часа.
2. Идем на сайт телеграмм, получаем API ID / HASH, приложение создается минуты за 2, прямо на сайте.
3. Ставим Claude Desktop, скачать можно тут,прописываем маленький JSON-конфиг (пример в README).

Как я использую:
Приведу пример конкретно с телегой. Заходим в Claude, пишем ему команду, например, "Найди у меня Чат для поста в телеграмм и достань оттуда Usage Examples для Telegram MCP Server". Самое кайфовое, что можно писать просто обычным языком, без всяких /comand, как в телеграмм-ботах.

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

Как-то так, пользуйтесь :)

Как давать фидбэк команде

Первое, что стоит сделать, — забыть про бутерброды и прочие странные техники, которым до сих пор кто‑то учит. Там в основе идеи замаскировать проблему чем угодно, чтобы запутать того, кому вы фидбэк даете, кажется, что не то, что нам нужно. Начнём с понимания: зачем вообще нужен фидбэк?

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

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

Какие варианты действий
1. Сказать Пете, что он туповат и игнорирует базовые инструменты. Максимум, чего мы добьемся, — оборонительной реакции. В худшем случае Петя решит, что туповат его руководитель, и просто уйдёт.
2. Можно ставить задачи Пете. Но тут проблема: у вас же ещё Никита, Кирилл, Максим и Вова, которые, кстати, справляются с тем, чтобы свои задачи по своим проектам не терять. Замыкать систему на себе и создавать боттлнек тоже кажется неразумным, да и с ответственностью за задачу тут явно что‑то не то.
3. Можно дать фидбэк сразу после факапа. Без ярлыков объяснить, к чему приводят потерянные задачи, показать, что «думать и помнить» одновременно тяжело, и предложить решение — вести календарь. Затем помочь разобраться с инструментом, если понадобится.

Кажется, что в третьем варианте шансов на успех больше. Как же его реализовать? Здесь помогает концепция радикальной прямоты, описанная Ким Скотт в одноименной книге. Ключевой инструмент — принцип HHIPP.

Что такое HHIPP
1. Helpful (полезно). Фидбэк должен помочь, а не унизить.
2. Humble (без высокомерия). Иногда легко скатиться в позицию учителя и показывать, какой вы опытный и умный. Тут важно, что вы не демонстрируете своё превосходство, а искренне хотите помочь именно Пете.
3. Immediate (сразу). Обратная связь даётся как можно ближе к моменту совершения ошибки. Не нужно откладывать обратные связи в папочку и ждать one-to-one, который вы раз в месяц проводите, пользы будет мало.
4. In‑Person (лично). Лично, говорят, что лучше очно, но можно приватном видеозвонке.
5. Not Personal (основываемся на фактах). Разбираем конкретное действие и его последствия, не присваиваем характеристики Пете, даже, если сильно хочется.

Что делаем, если видим, что у Пети появляется проблема?
1. Двухминутный разговор. После встречи с клиентом приглашаете Петю на короткий колл: «Есть минутка обсудить задачу?» Дальше — факт, последствие, вопрос, договор.
2. Действие и последствия. «Задача потерялась, из‑за этого клиент сдвигает релиз. Думать и помнить одновременно сложно: либо теряешь фокус на текущей работе, либо забываешь то, что вне поля зрения».
3. Договоренности и ресурсы. Петя сам исправляет ошибку: до завтра переносит все задачи в календарь. Вы при необходимости даёте инструмент, гайд или оплачиваете курс по тайм‑менеджменту :)

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

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

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

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

1. Ключевая переменная не «сколько часов в неделе», а «какое отношение у этих часов: высокой, средней и низкой когнитивной нагрузки — и как они расставлены по ритмам дня и недели».
Задача относится к высоконагруженной, когда одновременно:

1. Нет готовой отработанной схемы (новизна).
2. Нужно удерживать и увязывать более четырёх взаимозависимых факторов.
3. Время вхождения до устойчивого потока превышает несколько минут.
4. После прерывания приходится “пересобирать” логику.
5. Качество и скорость сильно различаются у новичка и эксперта

2. Я замечал, что обычно мы календари строим от встреч, сначала назначаем созвоны или дейлики на неделю вперед, а потом в промежутках пытаемся вместить задачи на подумать. Тут важно немного изменить паттерн поведения и строить свое расписание вокруг сложных задач.
3. Правило “делай сложное утром” — это эвристика, которая работает для N-ной части населения. Базовый принцип на самом деле звучит так: “делай сложное в свои индивидуальные пики устойчивого внимания при низкой внутренней и внешней помехе”. Нужно определить столы, в которых вы наиболее эффективны, это можно сделать замером примерно за неделю. Именно в них нужно воткнуть самые сложные задачи и остальную неделю планировать от них.
4. Самые легкие задачи, которые можно делать на автопилоте, размещайте на период, когда нормально подумать уже не получается. Определить легкую задачу тоже довольно просто, если вы можете одновременно слушать музыку или, например, говорить с кем-то, то задача однозначно простая.

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

Возможно, вы обнаружите, что рассчитали что-то не совсем верно. Например, пик оказался короче, чем предполагалось или, скажем, вы поставили две творческие задачи в один день, но чувствуете, что вторая “не пошла”. Регулярно анализируйте: удалось ли выполнить запланированное в отведенные слоты? Правильно ли рассчитана сложность дел под ваши возможности? Что было лишним, а чего не хватило? Используйте эти наблюдения, чтобы подправить календарь.

Недавно помогал коллеге готовиться к ретро, он помочь попросил. Кейс такой: у них провалился проект, и буквально всё пошло не так:
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