HeadHunter
1 719

Kanban для ML: когда Waterfall и SCRUM не работают

Kanban придумали в компании Toyota для организации производства и снабжения, но и в сфере ИТ этот подход отлично прижился. Выглядит он здесь иначе, хотя и реализует тот же самый принцип — то, что нужно, в срок. Александр Сидоров, руководитель направления анализа данных в HeadHunter, рассказал о своём опыте применения и дополнения Kanban для управления ИТ-проектами в компании, а также о том, как удалось повысить эффективность и сократить срок внедрения изменений, улучшающих качество продуктов.

В закладки

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

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

Иногда нужно дорабатывать, оптимизировать и проводить повторные A/B-тесты несколько раз (мы ограничиваемся тремя, чтобы уменьшить вероятность, что A/B-тест покажет статистически значимые изменения случайно). Чтобы придумать и поставить правильный приоритет для гипотезы, которая улучшит качество, очень часто нужно знать результаты проверки предыдущих гипотез.

Разработка по традиционной каскадной или каскадно-возвратной модели (waterfall) к ML плохо применима, потому что заранее не известно, какие гипотезы покажут улучшение качества и какие следующие гипотезы появятся в процессе. Это создаёт много изменений в требованиях, архитектуре и плане, которые при waterfall требуют очень больших усилий.

SCRUM работает не лучше, потому что попытка втиснуть всю математику и детали алгоритмов в голову одного product owner’а, а проверку гипотез и мелкие доработки разбить на спринты фиксированной длины напоминает натягивание совы на глобус.

Поэтому для управления разработкой умного поиска мы используем Kanban в сочетании с элементами adaptive software development. Это позволяет нам быстрее и с меньшими затратами находить, проверять и запускать на пользователей гипотезы, которые приводят к повышению качества продуктов.

Почему не работает SCRUM?

SCRUM позволяет делать то, что нужно сейчас product owner’у. При этом процесс разработки остаётся эффективным благодаря периодам стабильности бэклога спринта, ежедневному мониторингу проблем и прогресса. Кроме того, каждый знает, что в конце спринта нужно продемонстрировать результат, проанализировать процесс и спланировать следующий спринт. Это отлично работает, пока:

· всё, что нужно сделать, помещается в голове product owner’а;

· задачи помещаются в спринт, их можно продемонстрировать в конце, и после демо они редко требуют доработки.

В SCRUM встроена гибкость при реализации. Но он не мешает многим product owner’ам работать в режиме «я один знаю, что делать». Такой подход позволяет удовлетворительно делать обычные продукты. Но если в продукте применяются сложные алгоритмы, включая машинное обучение, product owner теряет очень много хороших гипотез, которые становятся видны команде, а также мотивацию команды к тому, чтобы думать и проявлять инициативу. Кроме того, при попытке держать в голове одновременно хотя бы пару десятков гипотез ML со всеми деталями, зависимостями и обстоятельствами, product owner устаёт, хуже думает, скептически воспринимает всё новое. Так что его гипотезы приводят к улучшению качества ещё реже.

Но даже если лидер слушает команду и определяет истории на спринт вместе с ней, возникают сложности с размещением проверки гипотез в коротких, фиксированных итерациях спринтов, бэклоги которых нельзя изменять. Долгие A/B-тесты могут не помещаться, мелкие правки и доработки по их результатам – ждать следующего спринта. Приходится планировать, какие гипотезы проверять в новом спринте, не дождавшись результатов проверки предыдущих гипотез, просто потому что пришло время планировать спринт, и не волнует. Хуже того, когда результаты A/B-теста становятся доступными, бэклог спринта уже нельзя изменить, даже если теперь видно, что там есть лишние задачи и нет нужных – только полностью отменить спринт. В результате команда проверяет не то, что нужно, находит меньше улучшений, и каждое улучшение доходит до пользователей на несколько недель позже, чем могло бы, а то и больше.

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

Adaptive software development

Проблемы с тем, что гипотезы не помещаются в одну голову, мы решаем с помощью элементов из agile-методологии Adaptive software development (ASD).

При любой разработке мы бережно относимся к Emergence – идеям, знаниям, пониманию, которые появляются у людей в команде в ходе работы. Как о том, что нужно делать, так и о том, чего делать не нужно. Мы их обязательно записываем и, если есть хоть какая-то вероятность, что это увеличит качество продукта, снизит требуемые вычислительные ресурсы, ускорит и упростит дальнейшую доработку – рассматриваем как гипотезы. Больше половины наших гипотез изначально придумали наши data scientist’ы, разработчики, тестировщики.

При проработке сравнительно небольших и простых гипотез, таких как применение новых признаков по поведению пользователей или метапризнаков, мы используем цикл speculation-collaboration-learn. Прорабатываем гипотезу вместе с командой, вместе, силами нескольких человек, делаем, затем обсуждаем результат и думаем, как нам изменить планы и приоритеты.

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

· 1-2 дня всей командой придумываем и прорабатываем, как делать, понимая, что всё изменится;

· 1-2 недели пробуем писать код каждой части, подбирать модели;

· 4-6 недель – доделываем до целой системы, работающей на стенде разработчика, с заглушками вместо сложных частей; например, рекомендации резюме на вакансии с линейным фильтром и ранжирующей моделью XGBoost, но без DSSM-эмбеддингов для расчёта LSH в unsupervised предварительном фильтре, потому что на этом этапе не очень важно, что без этого компонента при попытке подобрать подходящие среди 1,1 млн. резюме менеджеров по продажам в Москве возникнет таймаут;

· 4-6 недель – дорабатываем сложные части так, чтобы можно было запустить в первый A/B-тест на часть пользователей;

· 4-6 недель – оптимизируем, стабилизируем, объединяем с production, чтобы можно было выкатить на 100% пользователей.

ASD может дополнять SCRUM или Kanban, но сама по себе не решает проблем, которые создаёт SCRUM при проверке гипотез, связанных с ML.

Почему Kanban?

Потому что позволяет оптимизировать Lead Time – время от возникновения гипотезы до того, как мы её выкатим на всех пользователей – или решим выбросить.

Это помогает нам:

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

· Проверять гипотезы от начала до конца, стараясь сделать быстрее, а не уложить в спринт и продемонстрировать. Не отвлекаясь, как в SCRUM, на длительные ритуалы, которые нужно проводить потому, что настало время, а не потому, что возникла необходимость.

· Менять приоритеты и планы сразу, как только становится известным результат проверки предыдущей гипотезы, не дожидаясь конца спринта.

· Когда нужно сделать небольшую доработку, чтобы запустить следующий A/B-тест или чтобы выкатить гипотезу, улучшающую качество продукта, на всех пользователей – не ждать следующего спринта.

Вряд ли получится описать Kanban в одной статье.

Но хочу особенно ценности и практики, которые нам особенно помогают:

· организация людей вокруг гипотез и отдельных задач, поощрение проявлений лидерства и любознательности;

· визуализация и ежедневный контроль состояния задач: мы используем Kanban-доски Jira, на которых настроили статусы «идея», «проработка», «разработка», «A/B-тесты», «обратная связь», и для каждого по два состояния, «в работе» и «уже готово, а дальше ещё не пошло»;

· отношение к начатым задачам, которые чего-то ждут, как к рискам и убыткам, потому что всё изменяется, они стремительно теряют актуальность, провисят недельку – придётся переделывать;

· жёсткое лимитирование количества незавершённых задач в каждом состоянии;

· вытягивающая парадигма, когда мы не ждём, а приходим за задачами, смотрим, в чём помочь;

· кросс-функциональность, которая позволяет каждому подключиться и помочь решить проблему, вместо обычного «это не моя зона ответственности, к пуговицам претензии есть?»;

· встречи по анализу и улучшению процесса, на которых мы решаем, как нам убрать препятствия, которые нам мешают.

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

А что в итоге?

На старте мы стараемся сосредоточится на наиболее коротких и простых гипотезах, в результаты которых мы оцениваем как самые значительные, «низко висящих фруктах», затем их развиваем. Это позволяет быстро набирать знания и делать следующими более сложные, но ещё более результативные гипотезы, а не просто следовать хайпу, статьям или копировать код с Kaggle. Улучшение качества и ценности продуктов нравится пользователям и клиентам, нам, сотрудникам отдела продаж, руководству и инвесторам.

Kanban, ASD, отношение ко всему как к гипотезам, культура метрик и A/B-тестов нам в этом очень помогают. Возможно, благодаря этому, а также из-за того, что мы ещё проверили не все «низко висящие фрукты», почти треть наших гипотез приводят к улучшению продуктов (хотя обычно в ML даже когда приносит результат одна из десяти, это считается неплохо). В результате, за последние 2 года ML стал обеспечивать от четверти до трети приглашений кандидатов на собеседования. SCRUM для проектов с ML мы попробовали весной 2017, но он нам мешал и мы быстро от него отказались, а последние ТЗ и диаграммы Ганта для waterfall’а последний раз делали в 2013 и никогда больше не хотим к ним возвращаться.

{ "author_name": "HeadHunter", "author_type": "editor", "tags": [], "comments": 0, "likes": 11, "favorites": 7, "is_advertisement": false, "subsite_label": "headhunter", "id": 69248, "is_wide": true, "is_ugc": false, "date": "Mon, 27 May 2019 11:48:35 +0300" }
{ "id": 69248, "author_id": 275353, "diff_limit": 1000, "urls": {"diff":"\/comments\/69248\/get","add":"\/comments\/69248\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/69248"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 275353, "last_count_and_date": null }

Комментариев нет 0 комм.

Популярные

По порядку

0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Хакеры смогли обойти двухфакторную
авторизацию с помощью уговоров
Подписаться на push-уведомления
{ "page_type": "default" }