Alex_Wilson
New member
За последние восемь лет я успел поработать и в роли аналитика, и в роли тимлида, и в роли того самого человека, который в конце квартала объясняет руководству, почему красивый пилот снова остался пилотом. Поэтому цифра в заголовке для меня не абстрактная статистика из отчёта, а личная боль. Я видел десятки инициатив с громкими названиями, презентациями на общих собраниях и моделями с аккуратными метриками в блокнотах — и лишь малая часть из них дожила до реальных пользователей. Ниже я хочу честно разобрать, где именно мы теряем эти проекты, и что помогает вытащить их в прод.
Первая и самая частая причина — отсутствие внятного бизнес-вопроса на старте. Проект запускают потому, что «у нас есть данные» или «конкуренты уже используют машинное обучение», а не потому, что есть конкретная боль с измеримой ценой. В одном моём проекте мы полгода строили рекомендательную систему, а на защите выяснилось, что бизнес вообще не собирался менять интерфейс каталога: команда просто хотела красивое исследование. Хорошее правило, которое я вывел для себя: если вы не можете одной фразой сказать, какую метрику компании вы сдвинете и на сколько, проект ещё не готов стартовать.
Вторая причина — недооценка данных и инфраструктуры. Все любят обсуждать архитектуру модели и почти никто не любит вычищать дубли, разбираться с часовыми поясами и выяснять, почему в проде поле с датой приходит строкой в трёх разных форматах. В моей практике на подготовку данных уходило от шестидесяти до восьмидесяти процентов всего времени, и это норма, а не провал. Команды же, которые планируют две недели на сбор данных и месяц на «самое интересное», почти гарантированно срывают сроки и теряют доверие заказчика.
Третья причина — разрыв между ноутбуком и продакшеном. Исследовательская модель, обученная на выгрузке из локального файла, и сервис, который должен отвечать за двести миллисекунд под нагрузкой и переобучаться без остановки, — это два совершенно разных инженерных изделия. Я не раз наблюдал, как отличный блокнот с точностью выше девяноста процентов превращался в тыкву, потому что никто не продумал мониторинг, версионирование данных и обработку аномальных входных значений. Простой чек-лист из вопросов о том, что будет при пустом ответе базы, при смене схемы и при пиковой нагрузке, спасал меня больше, чем любые модные фреймворки.
Четвёртая причина — организационная, и она самая коварная. У дата-проекта часто нет владельца с реальными полномочиями: дата-сайентист сидит в одной команде, инженеры в другой, а бизнес-заказчик приходит только на демо раз в месяц. Как только пилот заканчивается и наступает скучная фаза внедрения, у всех находятся более приоритетные задачи, и проект тихо засыпает. Я убеждён, что на старте нужен один человек, который отвечает за результат целиком, и он должен иметь право тормозить проект, если ценность не подтверждается.
Что реально помогает? Первое: начинайте с решения, а не с технологии. Соберите простейший бейзлайн, иногда это правило на основе бизнес-логики, выкатите его в прод как можно раньше и сравните с текущим поведением системы. Второе: договоритесь о критериях успеха и о критериях остановки заранее. Если через месяц пилота метрика не сдвинулась, это тоже результат, и честно закрыть проект дешевле, чем тащить его три года из вежливости. Третье: вкладывайтесь в данные и мониторинг как в полноценный продукт, а не как в побочные расходы. Четвёртое: держите бизнес-заказчика внутри процесса, показывайте ему промежуточные результаты каждую неделю, а не раз в квартал.
Отдельно скажу про культуру измерений. Мы привыкли отчитываться количеством экспериментов и обученных моделей, хотя правильнее считать деньги и часы, которые проект вернул компании. Я стал вести простой журнал: что планировали, что получили, какое решение приняли по итогам. Через год такого журнала спорить с руководством о приоритетах стало невероятно легко, потому что на руках были не эмоции, а история реальных результатов, включая неудачные. Кстати, именно неудачные кейсы научили меня больше, чем самые удачные.
В итоге мой главный вывод прост: восемьдесят процентов проектов теряются не из-за слабых алгоритмов, а из-за слабой постановки задачи, отсутствия владельца и нежелания доводить работу до скучной инженерной части. Хорошая новость в том, что всё это лечится процессами и честностью, а не покупкой нового кластера. А теперь вопрос к вам, коллеги: какой приём помог именно вашей команде довести дата-проект до продакшена и что вы теперь делаете иначе на самом старте?
Первая и самая частая причина — отсутствие внятного бизнес-вопроса на старте. Проект запускают потому, что «у нас есть данные» или «конкуренты уже используют машинное обучение», а не потому, что есть конкретная боль с измеримой ценой. В одном моём проекте мы полгода строили рекомендательную систему, а на защите выяснилось, что бизнес вообще не собирался менять интерфейс каталога: команда просто хотела красивое исследование. Хорошее правило, которое я вывел для себя: если вы не можете одной фразой сказать, какую метрику компании вы сдвинете и на сколько, проект ещё не готов стартовать.
Вторая причина — недооценка данных и инфраструктуры. Все любят обсуждать архитектуру модели и почти никто не любит вычищать дубли, разбираться с часовыми поясами и выяснять, почему в проде поле с датой приходит строкой в трёх разных форматах. В моей практике на подготовку данных уходило от шестидесяти до восьмидесяти процентов всего времени, и это норма, а не провал. Команды же, которые планируют две недели на сбор данных и месяц на «самое интересное», почти гарантированно срывают сроки и теряют доверие заказчика.
Третья причина — разрыв между ноутбуком и продакшеном. Исследовательская модель, обученная на выгрузке из локального файла, и сервис, который должен отвечать за двести миллисекунд под нагрузкой и переобучаться без остановки, — это два совершенно разных инженерных изделия. Я не раз наблюдал, как отличный блокнот с точностью выше девяноста процентов превращался в тыкву, потому что никто не продумал мониторинг, версионирование данных и обработку аномальных входных значений. Простой чек-лист из вопросов о том, что будет при пустом ответе базы, при смене схемы и при пиковой нагрузке, спасал меня больше, чем любые модные фреймворки.
Четвёртая причина — организационная, и она самая коварная. У дата-проекта часто нет владельца с реальными полномочиями: дата-сайентист сидит в одной команде, инженеры в другой, а бизнес-заказчик приходит только на демо раз в месяц. Как только пилот заканчивается и наступает скучная фаза внедрения, у всех находятся более приоритетные задачи, и проект тихо засыпает. Я убеждён, что на старте нужен один человек, который отвечает за результат целиком, и он должен иметь право тормозить проект, если ценность не подтверждается.
Что реально помогает? Первое: начинайте с решения, а не с технологии. Соберите простейший бейзлайн, иногда это правило на основе бизнес-логики, выкатите его в прод как можно раньше и сравните с текущим поведением системы. Второе: договоритесь о критериях успеха и о критериях остановки заранее. Если через месяц пилота метрика не сдвинулась, это тоже результат, и честно закрыть проект дешевле, чем тащить его три года из вежливости. Третье: вкладывайтесь в данные и мониторинг как в полноценный продукт, а не как в побочные расходы. Четвёртое: держите бизнес-заказчика внутри процесса, показывайте ему промежуточные результаты каждую неделю, а не раз в квартал.
Отдельно скажу про культуру измерений. Мы привыкли отчитываться количеством экспериментов и обученных моделей, хотя правильнее считать деньги и часы, которые проект вернул компании. Я стал вести простой журнал: что планировали, что получили, какое решение приняли по итогам. Через год такого журнала спорить с руководством о приоритетах стало невероятно легко, потому что на руках были не эмоции, а история реальных результатов, включая неудачные. Кстати, именно неудачные кейсы научили меня больше, чем самые удачные.
В итоге мой главный вывод прост: восемьдесят процентов проектов теряются не из-за слабых алгоритмов, а из-за слабой постановки задачи, отсутствия владельца и нежелания доводить работу до скучной инженерной части. Хорошая новость в том, что всё это лечится процессами и честностью, а не покупкой нового кластера. А теперь вопрос к вам, коллеги: какой приём помог именно вашей команде довести дата-проект до продакшена и что вы теперь делаете иначе на самом старте?