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

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

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

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

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

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

Проблемы с тем, что гипотезы не помещаются в одну голову, мы решаем с помощью элементов из 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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