Меня зовут Иванов Алексей.
Я работаю DS и Scrum Master в Центре экспертизы ML компании TalentTech, разработчика HR-решений.
Обучаем моделей для проектов компании.
Ровно год назад наша команда самоорганизовалась и начала применять Scrum-подход (мы и дальше будем использовать Scrum).
Расскажу о наших внутренних процессах: что происходило, что происходит и, возможно, будет происходить с нами в ближайшее будущее.
Запуск оказался на удивление простым.
Команда встретилась, обсудила общее видение, за неделю создала бэклог и запустила первый спринт. На ретро мы обсудили первые впечатления и результаты и запустили второе.
Мы создали календарь за несколько итераций и сгруппировали встречи в блоки.
Звонки клиентам были зажаты между внутренней демонстрацией и планированием спринта.
Чтобы иметь возможность не только общаться, но и работать, понедельник, вторник и среда вообще остались без встреч (кроме стендапа).
Итак, за пару месяцев мы вошли в ритм.
Процесс стал по-настоящему нашим.
Помню, когда на OKR обсуждались цели процесса, кто-то заметил: «Зачем их ставить? Мы уже работаем по Scrum».
И надо сказать, первые результаты были ошеломляющими.
В одном из проектов, который уже начали считать провальным, за пару месяцев «расстреляли» все гипотезы и выкатили в производство ансамбль нейронов.
Идея «перемешать» задачи внутри команды, что называется, взлетела.
Если раньше, образно говоря, каждый сидел в своем колодце и при всех трудностях оставался по сути одиноким, то теперь пришло понимание, что если ты окажешься в тупике, проект подхватит кто-то другой.
Перевернутая постановка целей и скрытые процессы
Углубляясь в детали, можно увидеть, что наш Scrum не совсем каноничен.Клиентов несколько и как следствие перевернутая постановка целей.
Мы не переходим от целей к задачам, а наоборот. Что необходимо сделать по каждому проекту, обсуждается во время звонков с конкретными заказчиками.
Затем эти соглашения по PBR превращаются в задачи, соответствующие определению готовности, и добавляются в бэклог.
Затем, учитывая возможности команды, формируется объём спринта.
Только после этого возникает цель на ближайшие две недели.
На первый взгляд абсурдно, зачем объединять задачи из разных источников в одно целое.
Про некоторые спринты мы говорим, что возвращаемся к старым проектам («Вьетнамские флешбеки»), в некоторых решили работать над качеством и выполнять задачи в соответствии с DoD («кафе в DoD»).
Обнаруженная цель закрепляется в метафорических названиях спринта (они даны в скобках) и при правильной идентификации вызывает эмоции практически у всех членов команды.
Цель часто отражает текущие внутренние процессы.
Пример одного из них — торможение качественной работы.
В конце мая мы заметили: мы берём в спринт всё больше и больше стори-пойнтов, но завершаем всё меньше.
Сначала мне не хотелось в это верить.
Потом перегрузка стала ощущаться очень сильно.
Мы проанализировали содержание работы и поняли, что задачи были выполнены в минимально формальной степени – «пока прошла рецензия».
Мы приняли волевое решение начать процесс торможения и начали работать над качеством.
Процесс оказался медленным.
Вы не можете внезапно проснуться и взять на себя меньше задач за спринт. Три спринта были замедлены.
Сейчас мы понимаем, что это решение было правильным.
Фокус на качестве был восстановлен, и команда начала увеличивать объемы.
Если в проблемных спринтах мы брали 35-40 стори-пойнтов и делали 20 с четырьмя людьми, то теперь 8 сп на человека чувствуют себя вполне комфортно.
О лидерстве
На старте мы с командой обсуждали руководство командой — важно было, чтобы был один «ответственный» человек, который мог бы руководить командой.При этом, согласно agile-практикам, с помощью которых мы организуем свою работу, эффективная команда должна быть самоорганизующейся.
Мы стартовали без лидеров: они возникли естественным путем.
Модель ситуационного лидерства более гибкая, поэтому она нам подошла.
Каждый несет ответственность за что-то свое.
В зону ответственности входят: техническое видение, учет делового чутья, поддержание качества найма и, как ни странно, юмор.
У нас тоже есть специалист по этому вопросу! :) При этом команда остаётся основной.
Лучше всего это можно увидеть при приеме на работу.
Изначально я был единственным, кто брал интервью у разработчиков, так как у меня есть опыт программиста.
Я опросил нескольких человек, выбрал того, который мне показался подходящим, но через пару месяцев он ушел.
С одной стороны, у него действительно была просадка по одному из хард-скиллов, с другой — новый сотрудник не смог влиться в команду.
После этого было решено провести собеседование с кандидатами всей командой.
Однако так, конечно, будет не всегда.
Недавно нанял разработчика Python и специалиста по DS. Представление о том, какие люди нам нужны, постепенно синхронизируется внутри команды.
Сейчас мы ищем человека, который может и хочет глубже разбираться в математике.
Однако основное свойство универсальности, скорее всего, сохранится.
Что актуально сейчас
В последнее время работа с OKR стала привлекать все больше внимания.Мы отсортировали цели по их важности для клиентов и удалили неважные.
Да и сами цели были реструктурированы.
Модели, которые используются, но активно нами не разрабатываются, выделены в отдельный блок.
В них мы исправляем редкие ошибки и иногда добавляем небольшие функции.
К сожалению, в блоках R&D цели по-прежнему выглядят как задачи, а список результатов — как список дел.
Возможно, в следующем квартале мы попытаемся что-то с этим сделать, а пока запустили синхронизацию со спринтами.
В шаблон презентации для демо-версии был добавлен слайд с информацией о ходе выполнения OKR. Есть надежда, что в будущем OKR начнут выполнять свою основную функцию — синхронизировать нас с компанией.
Процесс генерации идей, кстати, тоже привлекает внимание.
В DS очень много исследовательской работы, и она требует отдельного размышления о том, как упаковать ее в бэклог.
С одной стороны, по канонам Scrum, задачи в бэклоге должны быть понятны всем, а результат — предсказуем.
С другой стороны, исследования предполагают, что мы не знаем, каким должен быть результат. Сейчас основной тип задач — эксперименты по ML. Попробуйте что-то изменить в модели (архитектуру, процедуру очистки данных и т. д.) и снимите метрики.
Есть типа задача найти новые решения с подготовкой небольшого отчета, но пока основные идеи рождаются либо из фонового чтения «Медиума», либо из «полулегальных» экспериментов.
Полулегальные в том смысле, что они выполняются как часть задачи, для которой они не предназначены.
Например, задача была провести факторный анализ и просто предполагала fit-predict, но в процессе выяснилось, что модель работает плохо.
Пришлось изучить вопрос глубже.
Нам удалось выяснить полихорические корреляции за спринт, но подтверждающий факторный анализ оказался слишком сложным и вынесся в отдельную задачу.
Или, например, нужно было переобучить BERT на очередную задачу предсказания предложения, а корпус почти полностью состоял из сообщений в одном предложении.
В результате мне пришлось погрузиться в BERT'ологию и преподавать TSDAE. Та самая магия встречи, когда из пятнадцатиминутного разговора у кофемашины рождается целое направление, немного потускнела, и мне хочется ее как-то поддержать.
Однако это дело будущего.
Пожалуй, это та тема, о которой можно будет написать через год. Теги: #Машинное обучение #Управление разработкой #Управление проектами #машинное обучение #машина+обучение #карьера в ней #agile #scrum #самоорганизация #NSM #HRTech
-
Советы И Подсказки Google Adsense
19 Dec, 24 -
Языки Будущего: Китайский Против Javascript
19 Dec, 24 -
Радио-У №14
19 Dec, 24 -
Пункты Разработки И Продажи Модулей Битрикс
19 Dec, 24
