Меня зовут Иванов Алексей. Я DS и скрам-мастер в центре ML-экспертизы разработчика HRtech-решений TalentTech. Мы занимаемся обучением моделей для проектов компании.
Ровно год назад наша команда самоорганизовалась и начала применять подход scrum (будем дальше — скрам.) Я расскажу о наших внутренних процессах: что произошло, что происходит и, возможно, будет происходить с нами в ближайшем будущем.
Запуск получился на удивление простым. Встретились командой, обсудили общее видение, за неделю сформировали backlog и запустили первый спринт. На ретро обсудили первые впечатления и результаты, запустили второй. Сформировали за несколько итераций календарь — сгруппировали встречи в блоки. Созвоны с заказчиками втиснули между внутренним demo и планированием спринта. Чтобы была возможность не только разговаривать, но и работать, понедельник, вторник и среду оставили вообще без встреч (кроме standup). Таким образом, мы вошли в ритм за пару месяцев. Процесс стал по-настоящему нашим. Помню, когда на OKR обсуждали процессные цели, кто-то заметил: «А зачем их ставить? Мы и так уже работаем по скраму».
И надо сказать, первые результаты оказались ошеломляющими. В одном из проектов, о котором уже начали думать как о провальном, за пару месяцев «отстреляли» все гипотезы и выкатили в прод ансамбль нейронок. Идея «перемешивать» задачи внутри команды, что называется, выстрелила. Если раньше, образно говоря, каждый сидел в своем колодце и со всеми сложностями оставался, по сути, в одиночестве, теперь пришло понимание, что если ты окажешься в тупике, проект подхватит кто-то другой.
Перевернутое целеполагание и скрытые процессы
Углубляясь в детали, можно заметить, что скрам у нас не совсем канонический. Есть несколько заказчиков и, как следствие, перевернутое целеполагание. Мы идем не от цели к задачам, а наоборот. Что нужно сделать по каждому из проектов, обсуждается на созвонах с конкретными заказчиками. Потом эти договоренности на PBR превращаются в задачи, отвечающие Definition of Ready, и добавляются в backlog. Потом с учетом капасити команды формируется scope спринта. Цель на ближайшие две недели возникает только после этого. На первый взгляд, абсурд, с чего бы задачам из разных источников компоноваться в единое целое. Про какой-то спринт мы говорим, что возвращаемся к старым проектам («вьетнамские флешбеки»), в какой-то мы решили поработать на качество и делать задачи в соответствии с DoD’ом («кафе у DoD’а»). Обнаруженная цель закрепляется в метафорических названиях спринта (это они даны в скобках) и, если она выявлена правильно, вызывает эмоции почти у всех членов команды.
Цель часто отражает актуальные внутренние процессы. Пример одного из них — торможение с работой на качество. В конце мая заметили: стори поинтов в спринт берем все больше, а выполняем все меньше. Поначалу в это не хотелось верить. Потом перегруз начал ощущаться очень сильно. Мы проанализировали содержание работы и поняли, что задачи выполняются в минимальном формальном объеме — «лишь бы ревью прошло». Мы приняли волевое решение запустить процесс торможения и начали работать над качеством. Процесс оказался небыстрым. Нельзя вдруг проснуться и взять в спринт меньше задач. Тормозили три спринта.
Сейчас мы понимаем, что это решение было верным. Внимание к качеству восстановилось, и команда начала наращивать объемы. Если в проблемные спринты брали 35-40 стори поинтов и делали 20 вчетвером, то сейчас 8 sp на человека ощущается вполне комфортным.
Про лидерство
На старте мы с командой обсуждали team-лидерство — было важно, чтобы был один «ответственный», который бы мог направлять команду. При этом, согласно agile-практикам, по которым мы выстраиваем работу, эффективная команда должна быть самоорганизующейся. Мы запустились без лидеров: они возникли естественным образом. Модель ситуационного лидерства более гибкая, и поэтому она нам подошла. Каждый отвечает за что-то свое. Среди сфер ответственности: технический вижн, памятование о бизнес-смысле, поддержание качества найма и, как ни странно, юмор. У нас есть специалист и по этому вопросу! :)
При этом главной остается команда. Лучше всего это можно увидеть на примере найма. Первоначально разработчиков собеседовал я один, так как обладаю бэкграундом программиста. Прособеседовал несколько человек, выбрал по моему мнению подходящего, но через пару месяцев он ушел. С одной стороны у него и правда была «просадка» по одному из hard-скилов, с другой — у нового сотрудника не получилось влиться в команду. После было принято решение собеседовать кандидатов всей командой. Впрочем, так, конечно, будет не всегда. Недавно наняли Python-разработчика и DS-специалиста. Видение того, какие люди нам нужны, потихоньку внутри команды синхронизируется. Сейчас ищем человека, который может и хочет плотнее разбираться с математикой. Впрочем, базовое свойство универсальности скорее всего сохранится.
Что актуально сейчас
В последнее время все больше внимания начинает привлекать работа с OKR. Мы отсортировали цели по их важности для заказчиков и удалили второстепенные. Да и сами цели были реструктуризированы. Модели, которые используются, но нами активно не развиваются, выделили в отдельный блок. В них мы чиним редкие баги и иногда прикручиваем мелкие фичи. К сожалению, в R&D-блоках цели по-прежнему выглядят как задачи, а список результатов — как список дел. Возможно, в следующем квартале попытаемся с этим что-то сделать, а пока — запустили синхронизацию со спринтами. В шаблон презентации к демо добавили слайд про апдейт прогресса по OKR. Есть надежда, что в будущем OKR начнуть выполнять свою первоочередную функцию — синхронизировать нас с компанией.
Процесс генерации идей, кстати, тоже привлекает внимание. В DS много исследовательской работы, и требует отдельного осмысления, как ее упаковывать в backlog. С одной стороны, по канонам скрама, задачи в backlog должны быть всем понятны, а результат предсказуем. С другой — research предполагает, что мы не знаем, что должно быть на выходе. Сейчас основной тип задач — это ML-эксперименты. Попробовать что-то поменять в модельке (архитектуру, процедуру очистки данных и т.п.) и снять метрики. Есть тип задач на поиск новых решений с составлением краткого отчета, но пока основные идеи рождаются либо из фонового чтения «Медиума», либо из «полулегальных» экспериментов. Полулегальных в том смысле, что делаются в рамках задачи, в которой они не подразумеваются. К примеру, задача была выполнить факторный анализ и предполагала просто fit-predict, но в процессе оказалось, что моделька отработала плохо. Пришлось изучать вопрос глубже. С polychoric correlations удалось разобраться за спринт, а confirmatory factor analysis оказался слишком сложным, и он ушел в отдельную задачку. Или, например, было необходимо дообучить BERT на задаче next sentence prediction, а корпус почти целиком состоял из сообщений в одно предложение. В итоге пришлось погрузиться в BERT’ологию и обучить TSDAE.
Та самая магия встречи, когда из пятнадцатиминутного разговора у кофемашины рождается целое направление, слегка поугасла, и хочется ее как-то поддержать. Впрочем, это уже дело будущего. Возможно, это тема, про которую можно будет написать через год.
