В июне 2019 года открылся наш ML-отдел, и я решил, что неплохо будет попробовать поработать по Скраму. Неплохая идея, ведь правда? 

Команда абсолютно новая, тимлидского опыта у меня было не так много, а начать с чего-то нужно....

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

Решение это далось непросто, все привыкли работать по Скраму, и от команды посыпались вопросы - что делать с эстимейтами, как приходить к общему контексту без скрам-покера, как будем измерять выгоду или потери от перехода на канбан? Изменения - это всегда сложно, недаром теме change management посвятили целый сезон конфы Podlodka Teamlead Crew. Эта статья про то, как мы генерируем предложения и внедряем изменения у нас в отделе.

Ретроспективы

От Скрама мы отказались, но кое-какие его артефакты сохранились до сих пор. Кто-то считает, что ретроспективы - это карго-культ, но мы их всё равно любим и ценим. Итераций у нас нет, но команды стараются проводить ретрики каждые две недели. Заметки с ретро постят в командные каналы, и я всегда их просматриваю. У любых action points с ретро должен быть ответственный, и иногда эти пойнты выходят за пределы команды - например, идеи, связанные с общими встречами, инструментами или практиками. Тогда этим ответственным могу стать я.

Помимо стандартных ретриков мы иногда проводим тематические мероприятия, посвящённые конкретной области или проблеме.

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

Ретро "Челлендж традиций". Берём какую-то область - инструменты, встречи, практики, выписываем все сложившиеся традиции и отвечаем на вопрос “Что бы мы делали, если у нас забрали возможность использовать это?”. К примеру:

• Для трекинга экспериментов вместо ClearML можно использовать W&B, MLFlow, DVC, а можно вообще отказаться от этой практики.

• Для организации инференса моделек вместо самописных решений можно внедрить Triton, Bento ML, Seldon.

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

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

Рацпредложения

Абсолютно согласен с мыслью, что если спонтанно возникает какая-то важная проблема или крутая идея, то ждать ретро - это странно. Каждый член команды может сообщать о траблах или предлагать инновации в каналах mattermost'а - #tooling, #mlops_support, #office_stuff, #ds_process. Ещё один важный канал обратной связи и идей - встречи 1:1 с лидами и руководителем отдела. А когда в отделе появляется новый человек - я отдельно прошу записывать свои впечатления и предложения, чтобы через 2-3 недели обсудить их на специальной встрече. Новый опыт и взгляд со стороны - отличный источник и драйвер изменений.

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

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

Диктатура, демократия и технические комитеты

Отдел вырос, сейчас в нём больше 25 человек, 4 продуктовых команды и одна платформенная. Процесс принятия решений и внедрения изменений, конечно, тоже изменился. Чтобы избежать проблем, недопонимания и затягивания важных решений нужно чётко определиться с процессом принятия тех или иных решений. В этом вам может помочь Delegation Poker.

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

• Tell - полная диктатура, единоличное принятие решений. На первых порах многие решения были приняты мной именно так, и это нормально, ведь нужна была скорость и чёткость. Именно так у нас были изначально были внедрены ClearML, Pytorch, Слак, Скрам. Сейчас так принимаются единичные решения, но оставить за собой такую возможность не повредит, ведь во времена кризиса может понадобиться принять быстрое и, возможно, жёсткое решение.

• Sell & Consult - очень важные инструменты, которыми я до сих пользуюсь для ряда вопросов. Так был осуществлён переход на Канбан, так формируется общее видение по стратегии или новым проектам, которое я потом высказываю на стратсессиях, так после начала войны мы переехали в Маттермост из Слака. Для продажи идеи можно состряпать презентацию или отдать гугл-док на комментирование.

• Agree - так сейчас принимаются все решения по найму и повышениям, а также большинство решений, которые касаются сразу нескольких команд. Для принятия важных общих технических решений - например, переход на новую систему хранения данных и разметки, хорошо работает идея технического комитета. Формируется некий орган, для данного примера он может включать дата-инженеров, внешних экспертов по БД и представителей команд, фиксируется процесс принятия решений и приёма идей “от населения”.

• Advise, Inquire & Delegate - львиная доля решений по проектам принимается командами. Я могу прийти на встречу и предложить своё видение или дать экспертизу по гипотезам, но итоговое решение всё равно остаётся за командой.

Конечно, внутри команд в свою очередь существуют свои правила принятия решений и делегирования. Получается этакая пирамида ответственности =)

Внешние консультации

Иногда бывает так, что для принятия взвешенного решения внутри отдела недостаёт компетенций. Важно это понимать, признавать и не стесняться. Возможно, это сигнал, что пора нанять специалиста нужного профиля, но во многих ситуациях достаточно будет внешней консультации. Наверняка, у вас есть куча друзей и знакомых в IT-сфере, и найдётся тот, кто будет рад помочь. Если же таких нет или неохота эксплуатировать человека - можно найти ментора, который за небольшую мзду ответит на возникшие вопросы. Ключевым фактором тут будет правильная подготовка, ведь человек извне находится вне вашего контекста. Мы в таких случаях создаём документ, накидываем туда вопросы, оцениваем, насколько их формулировка будет понятна “человеку с улицы”

А какие практики используете вы в своих ML-командах?

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML