Forwarded from Не AБы какие тесты
Привет, товарищи-статистики!
Влад опять сделал это: нашел новую свежую статью, которую я коротко окрестил бы как "точки над CUPED". Пока Владислав пилит свой пост на тему как статьи, так и CUPED (ожидайте!), я отмечу самое примечательное на мой взгляд:
1) Начнем с того, что китайцы, выделили два вида симуляций: DBF - Design-Based Framework и MDF - Model-based framework.
Во время теста мы, как правило, случайно сплитуем пользователей в группы A и B, то есть у нас есть механизм назначения - рандомная сплитовалка, это раз.
Второе, модель генерации данных / модель, порождающая данная: во время симуляции мы можем задать популяцию на основе нормального распределения с Mu=24, sigma=2, то есть наша популяция (данные) будут порождены (сгенерированы) моделью N(24, 2)
Далее мы брали выборки из этой популяции (тогда она сама бы была порождающей данные)
Но... а что если сразу задавать модель генерации данных на уровне выборки? Те же N(24, 2), только всего, условно, пара-тройка измерений?...
Вот об этом и речь, что есть два подхода к симуляции, которые могут давать разные результаты при проверке работоспособности критериев:
1.1. DBF - Design-Based Framework, это подход к причинному выводу и статистическому анализу,
в котором единственным источником случайности считается механизм назначения (сплитовалка),
а не модель генерации данных
1.2. MBF - Model-based framework (модельно-ориентированный подход) - это подход к статистическому выводу, в котором данные рассматриваются как реализации случайных величин (в рамках выборок),
порождённых некоторой вероятностной моделью, а случайность исходит от процесса генерации данных, а не от сплитовалки.
При этом вся математика с ее E(X)=... построена именно на Model-based: поэтому если вы хотите обобщения корректности выводов вашей придумки для всех-всех, то надо обязательно доказывать корректность модели на MDF подходе, иначе вы просто доказали, что это работает в рамках вашей оценки ген. совокупности (DBF), то есть только для вашего случая (!)
В чем разница в рамках результатов симуляции-то?
MDF cимуляция каждый раз генерирует _новые_ данные. Если в модели заложен тяжелый хвост, выбросы будут приходить всегда вне ограничений по удаленности, но такое ограничение как раз будет при DBF (=просто популяция, мы делаем ее большой, но не бесконечной, а значит и не весь хвост соберёем). Используя MBF там, где надо DBF (а мы всегда в этом формате работаем), можно получить слишком много шума (=большая дисперсия), то есть.
Коротко: сначала проверка через Model-Based framework, а потом на Design-Based Framework на своих исторических данных; в случае же чистых симуляций, если у вас n очень большое, то особой разницы уже не будет.
2) Китайцы вывели поправку для theta (это такой коэффициент, который оптимальным образом позволяет ковариате минимизировать дисперсию), когда мы считаем ее отдельно для контроля и теста.
Всего есть три сценария расчета theta, которые вызывали (кажется, до этого момента) споры в индустрии:
1. theta сразу по всем данным теста и контроля, - используют Booking, Walmart, Statsig (Стасик, Стасик, Стасик, - сможешь ли ты меня остановить!? )
2. theta "усреднённая" (pooled) по тесту, контролю, - Netflix, Airbnb
3. отдельно по данным групп, - запрещенная в РФ Meta, Microsoft; эта theta как раз спорная, так как при не шибко больших выборках и MDF может быть смещенность дельты (не совпадать с истинным, например, нулем при отсутствии эффекта).
Но:
- cкриншот показывает, что 3-ая при DBF менее конвервативна и самая мощная из всех
- самое важное: китайские братушки вывели поправку для дисперсии разниц CUPED, чтобы не бояться bias'a! И при этом вывели они просто через базу в статистике! Ту самую, которую скипнуть бы и обмазаться сразу кьюдеп-х*юпед. Оказывается, нельзя! База всему голова.
Проникнуться гениальностью вывода
Влад опять сделал это: нашел новую свежую статью, которую я коротко окрестил бы как "точки над CUPED". Пока Владислав пилит свой пост на тему как статьи, так и CUPED (ожидайте!), я отмечу самое примечательное на мой взгляд:
1) Начнем с того, что китайцы, выделили два вида симуляций: DBF - Design-Based Framework и MDF - Model-based framework.
Во время теста мы, как правило, случайно сплитуем пользователей в группы A и B, то есть у нас есть механизм назначения - рандомная сплитовалка, это раз.
Второе, модель генерации данных / модель, порождающая данная: во время симуляции мы можем задать популяцию на основе нормального распределения с Mu=24, sigma=2, то есть наша популяция (данные) будут порождены (сгенерированы) моделью N(24, 2)
population = np.random.default_rng().normal(mu_H0, sigma, population_size)
sample_based_on_population = np.random.choice(population, size = sample_size)
Далее мы брали выборки из этой популяции (тогда она сама бы была порождающей данные)
Но... а что если сразу задавать модель генерации данных на уровне выборки? Те же N(24, 2), только всего, условно, пара-тройка измерений?...
sample_based_on_model = np.random.default_rng().normal(mu_H0, sigma, sample_size)
Вот об этом и речь, что есть два подхода к симуляции, которые могут давать разные результаты при проверке работоспособности критериев:
1.1. DBF - Design-Based Framework, это подход к причинному выводу и статистическому анализу,
в котором единственным источником случайности считается механизм назначения (сплитовалка),
а не модель генерации данных
1.2. MBF - Model-based framework (модельно-ориентированный подход) - это подход к статистическому выводу, в котором данные рассматриваются как реализации случайных величин (в рамках выборок),
порождённых некоторой вероятностной моделью, а случайность исходит от процесса генерации данных, а не от сплитовалки.
При этом вся математика с ее E(X)=... построена именно на Model-based: поэтому если вы хотите обобщения корректности выводов вашей придумки для всех-всех, то надо обязательно доказывать корректность модели на MDF подходе, иначе вы просто доказали, что это работает в рамках вашей оценки ген. совокупности (DBF), то есть только для вашего случая (!)
В чем разница в рамках результатов симуляции-то?
MDF cимуляция каждый раз генерирует _новые_ данные. Если в модели заложен тяжелый хвост, выбросы будут приходить всегда вне ограничений по удаленности, но такое ограничение как раз будет при DBF (=просто популяция, мы делаем ее большой, но не бесконечной, а значит и не весь хвост соберёем). Используя MBF там, где надо DBF (а мы всегда в этом формате работаем), можно получить слишком много шума (=большая дисперсия), то есть.
Коротко: сначала проверка через Model-Based framework, а потом на Design-Based Framework на своих исторических данных; в случае же чистых симуляций, если у вас n очень большое, то особой разницы уже не будет.
2) Китайцы вывели поправку для theta (это такой коэффициент, который оптимальным образом позволяет ковариате минимизировать дисперсию), когда мы считаем ее отдельно для контроля и теста.
Всего есть три сценария расчета theta, которые вызывали (кажется, до этого момента) споры в индустрии:
1. theta сразу по всем данным теста и контроля, - используют Booking, Walmart, Statsig (
2. theta "усреднённая" (pooled) по тесту, контролю, - Netflix, Airbnb
3. отдельно по данным групп, - запрещенная в РФ Meta, Microsoft; эта theta как раз спорная, так как при не шибко больших выборках и MDF может быть смещенность дельты (не совпадать с истинным, например, нулем при отсутствии эффекта).
Но:
- cкриншот показывает, что 3-ая при DBF менее конвервативна и самая мощная из всех
- самое важное: китайские братушки вывели поправку для дисперсии разниц CUPED, чтобы не бояться bias'a! И при этом вывели они просто через базу в статистике! Ту самую, которую скипнуть бы и обмазаться сразу кьюдеп-х*юпед. Оказывается, нельзя! База всему голова.
Проникнуться гениальностью вывода
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
#МЛ_мюсли собесы
Пока я пытаюсь разобраться со всем смрадом, которое навалилось на меня в январе, нет много времени, чтобы писать технические посты, поэтому буду собирать небольшие сводки и мысли.
1. Насколько же к собесам стало готовиться проще💳
Вспоминая свою подготовку пару лет назад, самой большой проблемой был поиск информации. Сейчас пайплайн из хендбука Яндекса(огромный им поклон, реализовать все мл подходы с мат базой - это очень сильно), плейслист ШАДА по LLM, плюс видео Карпатого и вы уже отвечать на вопросы и рассуждать. Вам останется добрать кейсы на хакатонах и, если повезет, на коммерческих проектах и дальше вы сможете получить хоть что-то внутри бигтеха. Кажется, собесы будут все больше отходить от вопросов по метрикам и архитектурам к MLSD.
2. Удивило, что нет большого количества вопросов к собеседованиям😠
Но из хорошего нашел методичку из общих вопросов, про NLP, а также нашел сборник кейсов про MLSD. Этих материалов вам точно хватит, чтобы узнать ваши пробелы примерно до уровня техлида.
3. Методички про собесы и поиск компании😱
Около полугода назад прочитал методичку про поиск работы в ML от Бориса опять, очень понравилось, всем советую. На неделе также нашел методичку на английском, хоть она и старая, но очень понравилось строение и в целом виденье автора.
PS: если у вас есть любимые материалы подготовки к собесам, обязательно кидайте в комментарии💃
Надеюсь, из всех дел я смогу вылезти побыстрее, а пока ставьте реакции, ведь они сильно меня мотивируют не забрасывать канал💗
Пока я пытаюсь разобраться со всем смрадом, которое навалилось на меня в январе, нет много времени, чтобы писать технические посты, поэтому буду собирать небольшие сводки и мысли.
1. Насколько же к собесам стало готовиться проще
Вспоминая свою подготовку пару лет назад, самой большой проблемой был поиск информации. Сейчас пайплайн из хендбука Яндекса(огромный им поклон, реализовать все мл подходы с мат базой - это очень сильно), плейслист ШАДА по LLM, плюс видео Карпатого и вы уже отвечать на вопросы и рассуждать. Вам останется добрать кейсы на хакатонах и, если повезет, на коммерческих проектах и дальше вы сможете получить хоть что-то внутри бигтеха. Кажется, собесы будут все больше отходить от вопросов по метрикам и архитектурам к MLSD.
2. Удивило, что нет большого количества вопросов к собеседованиям
Но из хорошего нашел методичку из общих вопросов, про NLP, а также нашел сборник кейсов про MLSD. Этих материалов вам точно хватит, чтобы узнать ваши пробелы примерно до уровня техлида.
3. Методички про собесы и поиск компании
Около полугода назад прочитал методичку про поиск работы в ML от Бориса опять, очень понравилось, всем советую. На неделе также нашел методичку на английском, хоть она и старая, но очень понравилось строение и в целом виденье автора.
PS: если у вас есть любимые материалы подготовки к собесам, обязательно кидайте в комментарии
Надеюсь, из всех дел я смогу вылезти побыстрее, а пока ставьте реакции, ведь они сильно меня мотивируют не забрасывать канал
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevFM
RAG на практике
RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.
Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.
Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.
Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.
Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.
Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.
Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.
Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.
Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.
Ещё одна проблема: модели дообучены быть полезными. Если в контексте нет прямого ответа, модель склонна притянуть что-то похожее за уши вместо честного – не знаю.
Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.
Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.
Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.
Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.
Статью очень рекомендую.
#ai
RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.
Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.
Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.
Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.
Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.
Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.
Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.
Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.
Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.
Ещё одна проблема: модели дообучены быть полезными. Если в контексте нет прямого ответа, модель склонна притянуть что-то похожее за уши вместо честного – не знаю.
Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.
Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.
Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.
Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.
Статью очень рекомендую.
#ai
Хабр
Как я победил в RAG Challenge: от нуля до SoTA за один конкурс
Автор - DarkBones Предисловие В этом посте я расскажу про подход, благодаря которому я занял первое место в обеих призовых номинациях и в общем SotA рейтинге. В чём суть RAG Challenge? Нужно создать...
Forwarded from DevFM
Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда есть нюансы, но ты уже примерно понимаешь, как действовать.
Помимо практики, мне нравится читать книги, которые под эту практику подводят теорию. Знания становятся более структурированными.
Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.
Природа изменений
Адизес начинает с того, что изменения неизбежны, а любое изменение порождает проблемы. И эти проблемы необходимо решать – пока никаких открытий:)
PAEI: разные люди – разное восприятие
Чтобы решать проблемы и проводить изменения, нужно сначала спланировать, а потом воплотить решение. И для этого нужны разные роли – Адизес называет их PAEI. Не буду раскрывать модель подробно, это лучше читать в оригинале, но суть в том, что разные типы людей буквально живут в разных системах координат.
Они по-разному расставляют приоритеты: одному важно сделать результат здесь и сейчас, другому – выстроить порядок и процессы, третьему – увидеть новые возможности, четвёртому – чтобы команда была согласна и двигалась вместе.
Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".
Когда начинаешь понимать эти особенности, многие рабочие недоразумения начинают выглядеть иначе, всё становится более предсказуемым.
Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.
Но конфликт бывает конструктивным и деструктивным. Разница – во взаимном уважении и доверии. Если они есть, разногласия ведут к лучшим решениям. Если нет – то ничего хорошего не получится.
CAPI: почему недостаточно быть правым
Допустим, команда прошла через конструктивный конфликт и нашла хорошее решение. Достаточно ли этого, чтобы изменение произошло?
Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.
Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.
В книге раскрываются и другие интересные темы, но именно это показалось особенно интересным.
#books
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда есть нюансы, но ты уже примерно понимаешь, как действовать.
Помимо практики, мне нравится читать книги, которые под эту практику подводят теорию. Знания становятся более структурированными.
Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.
Природа изменений
Адизес начинает с того, что изменения неизбежны, а любое изменение порождает проблемы. И эти проблемы необходимо решать – пока никаких открытий:)
PAEI: разные люди – разное восприятие
Чтобы решать проблемы и проводить изменения, нужно сначала спланировать, а потом воплотить решение. И для этого нужны разные роли – Адизес называет их PAEI. Не буду раскрывать модель подробно, это лучше читать в оригинале, но суть в том, что разные типы людей буквально живут в разных системах координат.
Они по-разному расставляют приоритеты: одному важно сделать результат здесь и сейчас, другому – выстроить порядок и процессы, третьему – увидеть новые возможности, четвёртому – чтобы команда была согласна и двигалась вместе.
Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".
Когда начинаешь понимать эти особенности, многие рабочие недоразумения начинают выглядеть иначе, всё становится более предсказуемым.
Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.
Но конфликт бывает конструктивным и деструктивным. Разница – во взаимном уважении и доверии. Если они есть, разногласия ведут к лучшим решениям. Если нет – то ничего хорошего не получится.
CAPI: почему недостаточно быть правым
Допустим, команда прошла через конструктивный конфликт и нашла хорошее решение. Достаточно ли этого, чтобы изменение произошло?
Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.
Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.
В книге раскрываются и другие интересные темы, но именно это показалось особенно интересным.
#books
Forwarded from DevFM
Продолжая разговор о книге Адизеса хочется еще поделиться парочкой цитат, которые выписал, пока читал книгу.
Простая мысль, но в жизни часто бывает иначе: люди блокируют решения, не имея полномочий их принимать. И нужно четко понимать с кем ты работаешь и кто тебе нужен, чтобы протащить свое решение.
Очень часто это вижу и проговариваю с теми, кто приходит посоветоваться. Будь ты хоть миллион раз прав – если был агрессивен, раздражен или токсичен, тебя уже не будут слушать. Будут цепляться за форму, а не за содержание. Поэтому очень важно следить за тем, как ты доносишь свою точку зрения.
Проблема новоиспеченных тимлидов, которых поставили, нагрузили обязанностями, а вот про полномочия и власть – забыли. Кого нанимать? Не твое. Решение о премии? Не твое. Приоритеты менять? Согласуй сначала. Еще что-то хочешь внедрить – тоже согласуй. И вот у тебя куча обязанностей, а полномочий и власти – нет.
#books
Если в ответ на ваше предложение босс говорит "нет", спросите, имеет ли он право говорить "да". Если ему не позволено говорить "да", то выясните, кто обладает этим правом. Только этот человек и должен иметь право говорить "нет"
Простая мысль, но в жизни часто бывает иначе: люди блокируют решения, не имея полномочий их принимать. И нужно четко понимать с кем ты работаешь и кто тебе нужен, чтобы протащить свое решение.
Всякий раз, не соглашаясь с собеседником, уделяйте больше внимания тому, как вы выражаете несогласие, а не тому, что составляет его суть
Очень часто это вижу и проговариваю с теми, кто приходит посоветоваться. Будь ты хоть миллион раз прав – если был агрессивен, раздражен или токсичен, тебя уже не будут слушать. Будут цепляться за форму, а не за содержание. Поэтому очень важно следить за тем, как ты доносишь свою точку зрения.
Менеджеры результативны тогда, когда имеют достаточно полномочий, власти и влияния для выполнения своих обязанностей
Проблема новоиспеченных тимлидов, которых поставили, нагрузили обязанностями, а вот про полномочия и власть – забыли. Кого нанимать? Не твое. Решение о премии? Не твое. Приоритеты менять? Согласуй сначала. Еще что-то хочешь внедрить – тоже согласуй. И вот у тебя куча обязанностей, а полномочий и власти – нет.
#books
Telegram
DevFM
Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда…
Книга "Управление изменениями без потрясений и конфликтов" Адизеса
Хорошая база позволяет принимать решения в сложных ситуациях. Когда у тебя есть структура в голове, ты не смотришь на новую проблему как на что-то уникальное – всегда…
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Винни-Пух и его друзья решают менеджерские проблемы
Мой товарищ, коллега и сообщник по сообществу руководителей Management Hub Саша Коныгин написал на Хабре две статьи, которые мне очень понравились по нескольким причинам:
1. Он использует инструменты теории ограничений, чтобы и копнуть вглубь проблемы, и не пытаться разом всё на свете сделать одномоментно.
2. Забавно подано в стиле полилога между известными мультяшными персонажами.
3. Всё структурно и поэтапно. Для самых маленьких, так сказать. 🙂
Не уверен насчет того, как эта серия статей воспримется теми, кто не знаком с теорией ограничений, но мне, шапочно знакомому, было отрадно видеть, как теория превращается в практику и приносит пользу.
Обе статьи based on true story. 🙂
https://habr.com/ru/articles/971680/
https://habr.com/ru/articles/988796/
Мой товарищ, коллега и сообщник по сообществу руководителей Management Hub Саша Коныгин написал на Хабре две статьи, которые мне очень понравились по нескольким причинам:
1. Он использует инструменты теории ограничений, чтобы и копнуть вглубь проблемы, и не пытаться разом всё на свете сделать одномоментно.
2. Забавно подано в стиле полилога между известными мультяшными персонажами.
3. Всё структурно и поэтапно. Для самых маленьких, так сказать. 🙂
Не уверен насчет того, как эта серия статей воспримется теми, кто не знаком с теорией ограничений, но мне, шапочно знакомому, было отрадно видеть, как теория превращается в практику и приносит пользу.
Обе статьи based on true story. 🙂
https://habr.com/ru/articles/971680/
https://habr.com/ru/articles/988796/
Хабр
История, в которой Винни-Пух и его друзья учатся решать проблемы по одной
Когда проблем так много, что не знаешь, с чего начать Каждое ретро превращается в длинный список проблем: команда обсуждает всё подряд, составляет планы — но через месяц список остаётся тем же....
Forwarded from Борис опять
Верить в "its just scale" больше не модно, однако я все больше убеждаюсь во мнении, что решает ML/AI твою задачу или нет в первую очередь определяется способностями модели. Промтпы, скаффолды, раги и прочие костыли вносят эффект в пределах чуть больше погрешности. Даже если они помогают, то со следующим релизом модели побольше и поумнее эффект пропадает.
Несколько наблюдений на тему. Я сейчас играюсь с GUI агентами, даже сделал свой скаффолд а-ля MobileAgentV3. Общаясь текстом ты не сразу увидишь разницу скажем между Gemini 2.5 Flash, Gemini 3 Flash и Gemini 3 Pro. Но когда ты сажаешь эту штуку управлять телефоном через тулколы разница видна моментально несмотря на то, что модели обучались на схожих данных. Flash 2.5 не может тапнуть куда нужно, принимает иконку Google Translate за Google Play, галлюцинирует целые экраны. Flash 3 уже сносно работает, Pro 3 делает прям вау.
Причём ты можешь дать маленькой модели самый лучший скаффолд, заточить тулы под задачу, очень хитро и умно оптимизировать контекст и всё равно будет плохо. Ты можешь дать большой модели всё максимально кривое и она разберётся.
Другие наблюдения которые объясняются этой гипотезой. Почему Claude Code сработал так, как не сработал до этого Cursor? Потому что вышли Sonnet 4.5/Opus 4.5 у Claude Code и вкупе с максимально простым скаффолдом (фор луп + тулколлы + периодический compact) вдруг заработало. Почему у людей зааработал OpenClaw сделанный максимально проклято, хотя предыдущие попытки сделать такого ассистента не смогли? Вышел Sonnet 4.5 и заработало.
Вывод я для себя сформулировал так. Делая что-то на LLM надо начинать с самой умной и дорогой модели, а затем смотреть насколько ты можешь снизить косты не потеряв в качестве катастрофически. А не начинать эксперименты с мелких моделек и расти по необходимости. Ты понаделаешь для мелких моделей тонну костылей, но все равно не заработает, и все это будет впустую так как большим моделям костыли не нужны и даже мешают.
Очень хочется любить мелкие модели, но не получается
Несколько наблюдений на тему. Я сейчас играюсь с GUI агентами, даже сделал свой скаффолд а-ля MobileAgentV3. Общаясь текстом ты не сразу увидишь разницу скажем между Gemini 2.5 Flash, Gemini 3 Flash и Gemini 3 Pro. Но когда ты сажаешь эту штуку управлять телефоном через тулколы разница видна моментально несмотря на то, что модели обучались на схожих данных. Flash 2.5 не может тапнуть куда нужно, принимает иконку Google Translate за Google Play, галлюцинирует целые экраны. Flash 3 уже сносно работает, Pro 3 делает прям вау.
Причём ты можешь дать маленькой модели самый лучший скаффолд, заточить тулы под задачу, очень хитро и умно оптимизировать контекст и всё равно будет плохо. Ты можешь дать большой модели всё максимально кривое и она разберётся.
Другие наблюдения которые объясняются этой гипотезой. Почему Claude Code сработал так, как не сработал до этого Cursor? Потому что вышли Sonnet 4.5/Opus 4.5 у Claude Code и вкупе с максимально простым скаффолдом (фор луп + тулколлы + периодический compact) вдруг заработало. Почему у людей зааработал OpenClaw сделанный максимально проклято, хотя предыдущие попытки сделать такого ассистента не смогли? Вышел Sonnet 4.5 и заработало.
Вывод я для себя сформулировал так. Делая что-то на LLM надо начинать с самой умной и дорогой модели, а затем смотреть насколько ты можешь снизить косты не потеряв в качестве катастрофически. А не начинать эксперименты с мелких моделек и расти по необходимости. Ты понаделаешь для мелких моделей тонну костылей, но все равно не заработает, и все это будет впустую так как большим моделям костыли не нужны и даже мешают.
Очень хочется любить мелкие модели, но не получается
Forwarded from max.sh
Как строить evaluation системы для AI агентов?
Очередной крутой блог пост от Антропиков. Читать тут.
Прорывных мыслей, бенчмарков или сокрального знания тут не найти, но зато очень хорошая структура (такое пригождается на систем дизайн интервью, если что), отличный технический словарь (task, transcript, evaluation harness, agent harness, и.т.д) и призыв к действию для тех, кто активно шаманит над агентами в рабочих задачах.
И действительно. Если в прошлом году все поголовно были увлечены внедрением агентов процессы, то сейчас все переходят к стадии "а как с этими агентами со-существовать" и валидировать, что со временем они так же продолжают драйвить продуктивность (чтобы это не значило). Короче говоря, не хочется вслепую обновлять модель на новую и потом ловить себя на чувстве "так а чето стало только хуже".
Поэтому Eval-ы и нужны. Eval (от evaluation) – это по большому счету тест AI агента. Даете ему среду, задачу, запускаете, и оцениваете результат. На бумаге легко. На деле же каждая из переменных: среда, задача и оценка результата – безумно сложная задача. Особенно на масштабе организаций с сотнями репозиториев. Тут нужна методичность и структура. Поэтому так легко свалиться в "да пофиг, вроде стало лучше". По работе много общаюсь с энтерпрайзами и это головная боль чуть ли не каждого. Собственно поэтому мы и стали командой делать eval платформу, в которой можно эвалить разного рода контекст (например, вы сделали claude skill, а насколько он хорош? оценить можно тут) или целые репозитории и смотреть насколько хорошо агенты справляются с задачами. Но про это в другой раз.
Мне из блога откликнулись такие мысли.
* Смотреть на Eval-ы, как на модель швейцарского сыра. Картинка к посту в пояснение. Суть в том, что одним подходом все не поймать. Поэтому нужно много слоев. Где-то часть ошибок отловят автопроверки, где-то llm-as-judge, а где-то нужно смотреть не просто в input-output поведение, а анализировать логи агента и смотреть что он там накуролесил в процессе.
* Чем больше в системе детерминированных проверок, тем лучше (для вас). Проще дебажить, проще менять. Вслепую делегировать работу на откуп агенту-валидатору (читай llm-as-judge), себе дороже. По мнению такого валидатора все всегда будет ХО-РО-ШО. Как минимум рубрики нужно калибровать и смотреть глазами прежде чем внедрять такое и основывать на этом выводы.
* Чем раньше начнете задумываться о концепции eval-ов, тем проще будет с агентами дальше. Потому что так будет четкие аргументы, почему агент не может решать задачи именно в вашей кодовой базе и во что инвестировать, чтобы стало лучше. Несколько знакомых так уже получили промоушены в биг техах, чисто за счет какой-никакой observability-платформы для агентов. Лайфхаком не является, но намек вы поняли.
Очередной крутой блог пост от Антропиков. Читать тут.
Прорывных мыслей, бенчмарков или сокрального знания тут не найти, но зато очень хорошая структура (такое пригождается на систем дизайн интервью, если что), отличный технический словарь (task, transcript, evaluation harness, agent harness, и.т.д) и призыв к действию для тех, кто активно шаманит над агентами в рабочих задачах.
И действительно. Если в прошлом году все поголовно были увлечены внедрением агентов процессы, то сейчас все переходят к стадии "а как с этими агентами со-существовать" и валидировать, что со временем они так же продолжают драйвить продуктивность (чтобы это не значило). Короче говоря, не хочется вслепую обновлять модель на новую и потом ловить себя на чувстве "так а чето стало только хуже".
Поэтому Eval-ы и нужны. Eval (от evaluation) – это по большому счету тест AI агента. Даете ему среду, задачу, запускаете, и оцениваете результат. На бумаге легко. На деле же каждая из переменных: среда, задача и оценка результата – безумно сложная задача. Особенно на масштабе организаций с сотнями репозиториев. Тут нужна методичность и структура. Поэтому так легко свалиться в "да пофиг, вроде стало лучше". По работе много общаюсь с энтерпрайзами и это головная боль чуть ли не каждого. Собственно поэтому мы и стали командой делать eval платформу, в которой можно эвалить разного рода контекст (например, вы сделали claude skill, а насколько он хорош? оценить можно тут) или целые репозитории и смотреть насколько хорошо агенты справляются с задачами. Но про это в другой раз.
Мне из блога откликнулись такие мысли.
* Смотреть на Eval-ы, как на модель швейцарского сыра. Картинка к посту в пояснение. Суть в том, что одним подходом все не поймать. Поэтому нужно много слоев. Где-то часть ошибок отловят автопроверки, где-то llm-as-judge, а где-то нужно смотреть не просто в input-output поведение, а анализировать логи агента и смотреть что он там накуролесил в процессе.
* Чем больше в системе детерминированных проверок, тем лучше (для вас). Проще дебажить, проще менять. Вслепую делегировать работу на откуп агенту-валидатору (читай llm-as-judge), себе дороже. По мнению такого валидатора все всегда будет ХО-РО-ШО. Как минимум рубрики нужно калибровать и смотреть глазами прежде чем внедрять такое и основывать на этом выводы.
* Чем раньше начнете задумываться о концепции eval-ов, тем проще будет с агентами дальше. Потому что так будет четкие аргументы, почему агент не может решать задачи именно в вашей кодовой базе и во что инвестировать, чтобы стало лучше. Несколько знакомых так уже получили промоушены в биг техах, чисто за счет какой-никакой observability-платформы для агентов. Лайфхаком не является, но намек вы поняли.
Forwarded from Статистика и R в науке и аналитике
Дизайн A/B теста: пошаговая инструкция
Продолжаю рубрику вопросов с собеседований, сегодня предлагаю разогнать классический кейс на дизайн A/B теста.
К тебе приходит продакт с легендарной идеей покрасить кнопку “купить” в зеленый.
В таких вопросах A/B тест это не всегда единственный и лучший вариант, но в данном случае A/B наиболее просто задизайнить и объяснить.
Примерная структура ответа:
1. Уточнить контекст:
Какую проблему решаем (низкая конверсия, плохая заметность кнопки), какой ожидаемый эффект, как дорого это для разработки (в данном примере скорее всего недорого).
2. Выбрать метрики: ключевые, вспомогательные, заградительные
В данном случае скорее всего ключевой метрикой будет конверсия в успешную покупку, в качестве вспомогательных можно взять конверсию в клик по кнопке.
3. Сформулировать гипотезы: бизнесовые и статистические
Бизнес-гипотеза:
Зелёная кнопка повысит заметность, увеличит желание нажать на нее и увеличит конверсию в покупку.
Статистические гипотезы
H₀: конверсия в тестовой группе не отличается от контрольной;
H₁: конверсия в тестовой группе отличается от контрольной.
По умолчанию проводим именно двусторонний тест, так как наше воздействие может быть в обе стороны. Вообще односторонний тест на практике обычно не применяется и требует явного обоснования.
4. Дизайн эксперимента, расчет размера выборки
Вот здесь обычно начинаются сложности, рекомендую почитать пост Макса и планирую написать про это отдельно.
В рамках этого поста разберем буквально в двух словах:
Для расчета размера выборки нужно зафиксировать три параметра:
🟡 α - верхняя граница вероятности ошибки первого рода.
🟡 Мощность - вероятность обнаружить реальный эффект
🟡 MDE (Minimum Detectable Effect) - это минимальный размер эффекта, который эксперимент должен уметь обнаружить с заданной альфой и мощностью + имеет бизнес-смысл.
Дальше логика такая:
- от базовой конверсии выбираем MDE,
- фиксируем α и power,
- фиксируем сплитование: 50/50 даёт максимальную мощность, любой другой сплит нужно уметь объяснить.
- считаем размер выборки,
- делим на дневной трафик → получаем длительность теста,
- при необходимости учитываем недельную сезонность.
Важно понимать: чем меньше MDE, тем больше выборка и длиннее тест. Подробнее можно почитать здесь
5. Зафиксировать критерии принятия решения
Ещё на этапе дизайна договариваемся с продактом:
- Какой результат теста признаем успешным
- В каких сегментах будем смотреть
- Что будем делать с серым тестом (статистически незначимым)
- Какие критерии экстренной остановки теста
В некоторых случаях продакты могут раскатывать и серый тест, но нужно осознавать, какие могут быть последствия у этого.
6. Бонус: A/A тесты
На собеседовании упоминание A/A — скорее плюс:
- A/A полезен для проверки сплитовалки и метрик
- если система уже валидирована, перед каждым A/B его обычно не проводят
7. Подведение итогов теста
После завершения эксперимента:
- проверяем SRM (Sample Ratio Mismatch)
- сравниваем конверсии (обычно используется z-тест пропорций)
- смотрим доверительные интервалы
- анализируем заградительные и вспомогательные метрики (но решение принимаем по ключевой)
- отдаем продакту решение, а не просто p-value
Главное на собеседовании – уметь структурировать ответ, понимать ограничения A/B тестов и не запутаться в вопросах о статистике, если они будут!
Всем удачных собеседований и адекватных собеседующих 💪
#собес_PA #analytics #AB_tests
Продолжаю рубрику вопросов с собеседований, сегодня предлагаю разогнать классический кейс на дизайн A/B теста.
К тебе приходит продакт с легендарной идеей покрасить кнопку “купить” в зеленый.
В таких вопросах A/B тест это не всегда единственный и лучший вариант, но в данном случае A/B наиболее просто задизайнить и объяснить.
Примерная структура ответа:
1. Уточнить контекст:
Какую проблему решаем (низкая конверсия, плохая заметность кнопки), какой ожидаемый эффект, как дорого это для разработки (в данном примере скорее всего недорого).
2. Выбрать метрики: ключевые, вспомогательные, заградительные
В данном случае скорее всего ключевой метрикой будет конверсия в успешную покупку, в качестве вспомогательных можно взять конверсию в клик по кнопке.
3. Сформулировать гипотезы: бизнесовые и статистические
Бизнес-гипотеза:
Зелёная кнопка повысит заметность, увеличит желание нажать на нее и увеличит конверсию в покупку.
Статистические гипотезы
H₀: конверсия в тестовой группе не отличается от контрольной;
H₁: конверсия в тестовой группе отличается от контрольной.
По умолчанию проводим именно двусторонний тест, так как наше воздействие может быть в обе стороны. Вообще односторонний тест на практике обычно не применяется и требует явного обоснования.
4. Дизайн эксперимента, расчет размера выборки
Вот здесь обычно начинаются сложности, рекомендую почитать пост Макса и планирую написать про это отдельно.
В рамках этого поста разберем буквально в двух словах:
Для расчета размера выборки нужно зафиксировать три параметра:
Дальше логика такая:
- от базовой конверсии выбираем MDE,
- фиксируем α и power,
- фиксируем сплитование: 50/50 даёт максимальную мощность, любой другой сплит нужно уметь объяснить.
- считаем размер выборки,
- делим на дневной трафик → получаем длительность теста,
- при необходимости учитываем недельную сезонность.
Важно понимать: чем меньше MDE, тем больше выборка и длиннее тест. Подробнее можно почитать здесь
5. Зафиксировать критерии принятия решения
Ещё на этапе дизайна договариваемся с продактом:
- Какой результат теста признаем успешным
- В каких сегментах будем смотреть
- Что будем делать с серым тестом (статистически незначимым)
- Какие критерии экстренной остановки теста
В некоторых случаях продакты могут раскатывать и серый тест, но нужно осознавать, какие могут быть последствия у этого.
6. Бонус: A/A тесты
На собеседовании упоминание A/A — скорее плюс:
- A/A полезен для проверки сплитовалки и метрик
- если система уже валидирована, перед каждым A/B его обычно не проводят
7. Подведение итогов теста
После завершения эксперимента:
- проверяем SRM (Sample Ratio Mismatch)
- сравниваем конверсии (обычно используется z-тест пропорций)
- смотрим доверительные интервалы
- анализируем заградительные и вспомогательные метрики (но решение принимаем по ключевой)
- отдаем продакту решение, а не просто p-value
Главное на собеседовании – уметь структурировать ответ, понимать ограничения A/B тестов и не запутаться в вопросах о статистике, если они будут!
Всем удачных собеседований и адекватных собеседующих 💪
#собес_PA #analytics #AB_tests
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Датавиз в BI • Алиса Ручкина
Подборка мини-хаков в FineBI
Собрала подборку маленьких нюансов в FineBI, которые могут быть полезны для начинающих:
🤩 Создать легенду для нескольких мер
🤩 Создать ось для мер
🤩 Расположить названия мер на оси Y горизонтально (аналогично, если нужен наклон «минус 90 градусов»)
🤩 Убрать скролл в дашборде при использовании tab-компонента
🤩 Убрать наклон подписей на горизонтальной оси
🤩 Добавить сортировку по столбцу с типом «Число»
🤩 Добавить сортировку по дате с типом «Текст»
🤩 Добавить сортировку по мере, которая не отображена на графике
🤩 Добавить интерактивную сортировку по мере
Большую мега-подборку по FineBI смотри здесь🔗
#подборка #база
Собрала подборку маленьких нюансов в FineBI, которые могут быть полезны для начинающих:
Большую мега-подборку по FineBI смотри здесь🔗
#подборка #база
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Quant Valerian
Практики управления на уровне культуры команды
Итак, прошло несколько месяцев с тех пор, как я попробовал новые методы в работе с командой. Пришло время подвести промежуточные итоги и поделиться с вами результатами и самими практиками.
Какие цели я перед собой ставил?
- члены команды должны уметь работать самостоятельно и принимать решения автономно
- члены команды должны быть проактивны и стремиться решить проблему, а не сделать задачу
- члены команды должны научиться самостоятельно принимать решения
- члены команды должны *хотеть* помочь друг другу
Что конкретно я сделал?
Ввёл ритуалы!
Последовательно. На первых двух неделях:
- Каждый день проговариваем правило: «молчание = остановка». Если застрял — спроси, дойди, допинай, эскалируй. Двигайся!
- Если есть позитивные примеры такого поведения — подсвечиваем сразу и публично хвалим.
- Каждый день, на дейлике, каждый человек во время рассказа о статусе по своей задаче должен объяснить, зачем мы делаем эту задачу.
- Если он не может объяснить, то пытается объяснить кто-то другой, например, я. Если мы не можем объяснить, то это повод разобраться, а надо ли эту задачу делать.
Немного попугайская история, потому что каждый день это часто, но длится такое всего две недели, так что можно и потерпеть.
Это позволило ребятам почувствовать, что они вообще делают. Как сказал наш проджект, начать строить храм, а не просто носить кирпичи. Отсылка к известной притче.
Кроме того, ребята привыкают слушать друг друга, потому что теперь гораздо понятнее, чем занят сосед.
На третьей неделе обновили ритуал:
- Теперь нужно было объяснить не только зачем мы делаем задачу, но и связывать свою задачу с целями команды.
Здесь уже появляется связка между членами команды. Теперь они начинают слушать внимательно, ведь сосед делает вещи, которые напрямую влияют на твои дела. Тут началась кооперация, дискуссии, появилось желание ребят помочь друг другу.
На четвертой неделе еще одно обновление:
- Теперь нужно объяснить, почему мы делаем именно эту задачу и почему именно сейчас.
- Одну задачу в неделю команда может выбрать и запланировать сама, без менеджеров и лидов.
Этот ритуал переводит фокус внимания сотрудников с операционки на достижение поставленных целей, учит понимать приоритезацию. Помогает постоянно держать в голове стратегические цели.
На этом этапе ребята уже несколько раз ловили меня на том, что запланировал какую-то фигню к работе. И мы меняли приоритеты или скоуп. Ведь у них больше контекста, они реально лучше понимают риски и эффекты от разных проблем и фич.
Здесь уже была активная кооперация, и команда попёрла к целям как паровоз!
Кроме того, по пятницам мы ввели ещё один ритуал. С одной стороны командообразующий, с другой позволявший мне, как руководителю, измерять температуру в команде:
- Я просил каждого высказать свое мнение, как мы поработали на этой неделе. Лучше или хуже, чем на прошлой? Что было хорошего, а что плохого? Кому хочется сказать спасибо?
Это добавило теплоты и ламповости, создало среду, где ребята могут быть уязвимы друг перед другом. Это основа построения доверия.
Мы сделали и ещё несколько изменений, например, довольно существенно изменили процессы в сторону канбана, посрезали излишнюю бюрократию, жестко лимитировали WIP по эпикам. Но по моему общению с ребятами на 1-1, именно ритуалы произвели наибольший эффект и очень понравились команде.
Попробуете у себя? Или у вас уже есть подобные штуки?
Итак, прошло несколько месяцев с тех пор, как я попробовал новые методы в работе с командой. Пришло время подвести промежуточные итоги и поделиться с вами результатами и самими практиками.
Какие цели я перед собой ставил?
- члены команды должны уметь работать самостоятельно и принимать решения автономно
- члены команды должны быть проактивны и стремиться решить проблему, а не сделать задачу
- члены команды должны научиться самостоятельно принимать решения
- члены команды должны *хотеть* помочь друг другу
Что конкретно я сделал?
Ввёл ритуалы!
Последовательно. На первых двух неделях:
- Каждый день проговариваем правило: «молчание = остановка». Если застрял — спроси, дойди, допинай, эскалируй. Двигайся!
- Если есть позитивные примеры такого поведения — подсвечиваем сразу и публично хвалим.
- Каждый день, на дейлике, каждый человек во время рассказа о статусе по своей задаче должен объяснить, зачем мы делаем эту задачу.
- Если он не может объяснить, то пытается объяснить кто-то другой, например, я. Если мы не можем объяснить, то это повод разобраться, а надо ли эту задачу делать.
Немного попугайская история, потому что каждый день это часто, но длится такое всего две недели, так что можно и потерпеть.
Это позволило ребятам почувствовать, что они вообще делают. Как сказал наш проджект, начать строить храм, а не просто носить кирпичи. Отсылка к известной притче.
Кроме того, ребята привыкают слушать друг друга, потому что теперь гораздо понятнее, чем занят сосед.
На третьей неделе обновили ритуал:
- Теперь нужно было объяснить не только зачем мы делаем задачу, но и связывать свою задачу с целями команды.
Здесь уже появляется связка между членами команды. Теперь они начинают слушать внимательно, ведь сосед делает вещи, которые напрямую влияют на твои дела. Тут началась кооперация, дискуссии, появилось желание ребят помочь друг другу.
На четвертой неделе еще одно обновление:
- Теперь нужно объяснить, почему мы делаем именно эту задачу и почему именно сейчас.
- Одну задачу в неделю команда может выбрать и запланировать сама, без менеджеров и лидов.
Этот ритуал переводит фокус внимания сотрудников с операционки на достижение поставленных целей, учит понимать приоритезацию. Помогает постоянно держать в голове стратегические цели.
На этом этапе ребята уже несколько раз ловили меня на том, что запланировал какую-то фигню к работе. И мы меняли приоритеты или скоуп. Ведь у них больше контекста, они реально лучше понимают риски и эффекты от разных проблем и фич.
Здесь уже была активная кооперация, и команда попёрла к целям как паровоз!
Кроме того, по пятницам мы ввели ещё один ритуал. С одной стороны командообразующий, с другой позволявший мне, как руководителю, измерять температуру в команде:
- Я просил каждого высказать свое мнение, как мы поработали на этой неделе. Лучше или хуже, чем на прошлой? Что было хорошего, а что плохого? Кому хочется сказать спасибо?
Это добавило теплоты и ламповости, создало среду, где ребята могут быть уязвимы друг перед другом. Это основа построения доверия.
Мы сделали и ещё несколько изменений, например, довольно существенно изменили процессы в сторону канбана, посрезали излишнюю бюрократию, жестко лимитировали WIP по эпикам. Но по моему общению с ребятами на 1-1, именно ритуалы произвели наибольший эффект и очень понравились команде.
Попробуете у себя? Или у вас уже есть подобные штуки?