Кто такой Product Owner, чем занимается и как отличается от project-менеджера
В scrum-команде есть несколько основных ролей. Одна из них — Product Owner. Рассказываем, кто это и чем занимается.
Product Owner, или «владелец продукта» знает всё о потребностях и болях пользователя, возможностях команды, видит их точки соприкосновения на благо всего проекта.
Как не путать с менеджером проекта
Менеджер проекта и Product Owner — это не одно и то же. Менеджер проекта — руководитель: он распределяет задачи и нагрузку, проверяет и снова руководит процессом.
А владелец продукта больше про сам продукт. Он видит, каким должен быть результат, и знает, как команда будет его добиваться. Контролируя каждый этап, он корректирует курс и говорит, что делать дальше. У них похожие функции, но есть и отличия.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
| Product Owner | Руководитель проекта |
|---|---|
| ключевая роль в гибких методологиях | должность вне зависимости от методологии |
| не управляет командой, а направляет и работает вместе с ней | по большей части руководит |
| отвечает за продукт | отвечает за продукт |
Функции Product Owner ближе к работе, которую выполняет Product Manager. Чтобы научиться и стать профессионалом в этой области, обратите внимание на практический курс «Управление продуктом» от Skillbox.
Роли продуктового менеджера и владельца продукта часто объединяют в вакансиях.
Роль Product Owner
в scrum-команде
Напомним, что Scrum — методология гибкой разработки программного обеспечения. Она основана на Agile-манифесте.
Scrum-команда — это владелец продукта, scrum-мастер и разработчики. В заказной разработке — еще клиент, пользователи и стейкхолдеры.
Чем занимается
Product Owner
Product Owner выполняет часть функций руководителя проекта, менеджера продукта и маркетолога. Он не управляет, а направляет команду, чтобы вместе прийти к желанному результату. У него есть власть и ответственность.
Product Owner отвечает за продукт на всех этапах его создания:
По Scrum владелец продукта — это роль одного человека из команды. Но компании, которые используют фреймворк, адаптируют его под свои потребности. Поэтому бывает, что один человек выполняет сразу несколько ролей. Например, менеджер проекта в заказной разработке — это и scrum-мастер, и Product Owner. Это противоречит scrum-гиду, но вполне допустимо, если система работает и приносит нужный результат.
Кто будет выполнять роль владельца продукта, зависит от проекта. Это может быть человек из команды, сотрудник заказчика или он сам, если, например, проект — сайт для его компании. Владельцев продукта часто нанимают на проект со стороны и обучают внутри команды.
Что важно для владельца продукта
Обязанности владельца продукта зависят от типа проекта. Вот что для вас важно, если вы — Product Owner.
Вы всегда представляете, как будет выглядеть продукт в итоге, и способны объяснить это другим. Важно сделать так, чтобы все в команде поняли задачи одинаково.
Вы должны убедиться, что продукт будет ценен для пользователя. Не важно, какие методы вы будете применять для этого.
Вам придется слушать предложения команды, оценивать их и заносить в общий список задач и требований. Вы отвечаете за содержание бэклога и за изменения в нем.
Только вы выбираете порядок, в котором команда будет работать. Всегда точно знаете, какие функции появятся у продукта первыми, а что можно дорабатывать потом. Задачи на каждый спринт тоже планируете вы.
Вам важно, что получается после каждой итерации. Вы проверяете качество продукта в конце спринта, и, если что-то идет не так, знаете, как это изменить. Прогресс продукта — это ваш личный прогресс.
Именно вы следите, чтобы общение команды было продуктивным. Вам важно, чтобы все, кто создаёт продукт, могли обмениваться идеями и легко понимали друг друга. От этого зависит общий результат.
Заключение
Мы рассказали, кто такой Product Owner и чем он занимается. Если у вас остались вопросы или вы хотите подробнее разобраться в Scrum и Agile, советуем почитать и посмотреть:
Чтобы быть владельцем продукта, нужно уметь работать по Agile-методологиям. Разбираться в маркетинге, юзабилити, разработке и управлении, а главное — понимать жизненный цикл продукта.
Product Owner vs Product Manager или Product Owner/Product Manager
Кто прав? Единого ответа нет. Сфера ИТ стремительно развивается, компании расширяются, создаются новые проекты, которые требуют новых подходов. Появляются “многостаночники”: девопсы, фулстек-разработчики, технические проджект-менеджеры. Все это зачастую приводит к путанице, когда HR-команда не может четко сформулировать, кто же им собственно нужен, и появляются вакансии, которые включают в себя набор обязанностей “от всех по чуть-чуть”.
Сделав сравнение Project Manager и Product Manager, я получила вопрос:
“А в чем тогда разница между Product Owner (владелец продукта) и Product Manager (менеджер продукта)?”
Давайте разбираться вместе!
Product Manager не привязан к какой-то определенной модели, методологии или фреймворку.
Менеджер продукта отвечает за общее видение продукта и его соответствие требованиям рынка; он контролирует процесс создания, общается с целевой аудиторией и разрабатывает маркетинговую стратегию для запуска, после которого постоянно оценивает актуальность продукта и, при необходимости, совершенствует его.
Владелец продукта отвечает за “достижение максимальной ценности продукта”. Он работает с командой, владеет минимальными техническими знаниями для лучшего понимания задач, решает, что и в какой последовательности будет реализовано из беклога, общается с пользователями на разных этапах для сбора обратной связи.
На этапе зарождения продакт-менеджмента скорость развития рынка и выпуска продуктов была совсем другой. Продакт-менеджер разрабатывал видение продукта и передавал его на реализацию проджект-менеджеру. В 1980-х, когда рынок стал меняться быстрее, продукты к моменту их выхода могли потерять свою актуальность. Появился Scrum со своей ролью владельца продукта, который чувствует, “куда ветер дует” относительно его бизнеса, и вносит необходимые изменения в беклог, постоянно держа руку на пульсе и корректируя приоритеты.
“визионера, который ведет идеи новых продуктов от первоначального концепта до запуска “созревшего” продукта”.
Примеры вакансий и более подробное их описание можно посмотреть FB Product Manager и Sr. Product Manager от Amazon. В Google помимо более 600+ запросов на эту должность, есть своя обучающая программа “Google Associate Product Manager Program”.
А что же с требованиями к этим должностям? Какими эти позиции видят рекрутеры?
Требования к Product Manager:
Умение анализировать рынок и продукцию конкурентов, выявлять болевые точки и проблемы потенциальных пользователей для понимания возможных зон развития.
Понимание, как превращать потребности клиента в готовый продукт.
Опыт в проведении тестов (к примеру, A/B, A/A) и навыки анализа больших объемов информации.
Знание принципов UX/UI дизайна и инструментов для прототипирования.
Опыт в создании плана развития продукта или отдельных функций и отслеживание его выполнения.
Умение работать в постоянно-меняющейся окружающей среде и сбор необходимых аналитических данных для “процветания” продукта в этих условиях.
Понимание процессов разработки продукта, зон ответственности команды и навыки общения с заказчиками и потенциальными пользователями.
Требования к Product Owner
Опыт работы в Scrum и понимание гибких методологий и фреймворков в целом.
Организационные, аналитические и коммуникационные навыки.
Умение находить ключевые проблемы и возможности разрабатываемого продукта.
Способность правильно приоритизировать деятельность (как свою, так и команды) для успешной работы над проектом.
Умение анализировать, КАК думают потенциальные пользователи, ЧЕГО они хотят, КАК себя ведут с целью дальнейшего “превращения” этой информации в функции и услуги.
Способность “предсказывать” тренды в будущем, основываясь на имеющихся данных.
Опыт в оптимизации продукта через А/В тестирование.
Умение разбивать весь объем работы на отдельные задачи для дальнейшей презентации их стейкхолдерам и членам команды.
Опыт написания технической документации.
И если требования более-менее отличаются, то обязанности очень подобны.
Обязанности Product Manager:
Находить и анализировать возможности рынка и потребности ЦА для создания концепта продукта и стратегии его разработки.
Общение с клиентами напрямую.
Создание плана разработки, контроль его выполнения и написание документации.
Сотрудничество со стейкхолдерами, проджект-менеджерами и командой для общего понимания, каким образом создаваемый вами продукт будет соответствовать требованиям клиентов.
Написание high-view требований и детализация их с командой.
Создание пути клиента “от А до Я”, чтобы впечатления пользователей были максимально положительными на всех этапах взаимодействия с продуктом.
Мониторинг метрик, создание и проверка гипотез.
Помощь при выведении продукта на рынок и дальнейшая его поддержка.
Обязанности Product Owner:
Анализировать рынок и потребности клиентов, понимать их ожидания и психологию.
Собирать обратную связь как от стейкхолдеров, так и от конечных пользователей.
Быть “клеем” для команд аналитиков, дизайнеров, разработчиков и поддержки, чтобы происходила эффективная коллаборация между ними.
Определять объем работ для разработчиков и формировать беклог.
Управлять релизами, ставить задачи команде.
Участвовать в демонстрациях и ретроспективах.
Создавать техническую документацию (пользовательские истории, видение, руководство для пользователей и т.д.) и четкие достижимые спецификации, чтобы команда выпускала ключевые функции вовремя и с максимальной ценностью для рынка.
Создавать рекомендации для маркетинговых стратегий с целью привлечения и удержания пользователей.
Формировать дорожную карту продукта.
Контролировать создание продукта от идеи до поставки заказчику.
Гибкое управление Data Science-продуктами
Асхат Уразбаев был программистом, руководил IT-командами, но заинтересовался Agile и основал компанию ScrumTrek, которая помогает компаниям внедрять гибкие подходы.
Однажды в ScrumTrek за помощью обратилась компания с data science-продуктами. Казалось бы, работа понятна и схема отработана: рассказать, что такое Agile, собрать бэклог, запустить спринт — 3 дня работы. 3, не 3, но через 3 месяца точно что-то начнет получаться, а через 3 года вообще все будет отлично.
Оказалось, не так все просто.
Существует примерно два подхода к построению процессов в data science-проектах.
CRISP-DM создан в 90-х годах и вообще не удобен для внедрения. Это просто Work Breakdown Structure (WBS) — список работ, которые примерно нужно сделать. Он слишком общий, поэтому на самом деле не подходит ни одному проекту.
MS TDSP — Microsoft Team Data Science Process — вроде бы коллаборативный подход, построенный вокруг Scrum, но реальные проблемы проектов он, к сожалению, тоже не решает.
Рассмотрим типовые проблемы в data science и поймем, что с ними делать.
Бизнес и DS не понимают друг друга
Разберем проблему непонимания на примере разработки чат-ботов для ритейла. В магазинах торговой сети иногда случаются проблемы, например, продавщица подралась с посетителем, или охранник поругался с продавщицей. В таких ситуациях сразу начинают звонить в юридический отдел. Но юристы отвечают в рабочее время по Москве, а магазины по всей России.
Логичная идея: сделать чат-бот, которому люди будут писать, и умный чат-бот будет отвечать. Команда data science говорит, что надо бы обучить модель, а юристы отвечают, что они уже все подготовили: «Мы написали инструкции в Word, пусть чат-бот их прочитает, выучит и сможет отвечать пользователям». Но data science так не работает, нужны диалоги для обучения модели — заказчик разочарован. А договор уже подписан, деньги на проект выделены и надо что-то делать. Что-то и делают, в итоге результат всех не устраивает.
Почему так получается?
Для заказчиков исполнители выглядят так:
В свою очередь исполнители думают, что у заказчиков:
Как лечить?
Первое, что можно попробовать сделать — перестать передавать проекты data science-команде до горизонта.
Приведу еще один пример. У нас была задача в одной нефтяной компании: грузовики, в том числе бензовозы ездят по России, водители иногда курят в машине, подвозят посторонних людей и другим образом нарушают правила. Это кейсы, с которыми нужно уметь работать. В грузовиках есть камеры, но кто их отсматривает? Представляете, сколько это часов записи. Это прекрасная проблема для искусственного интеллекта, он же может проанализировать записи с камер.
Технически к задаче подошли следующим образом: поставили задачу людям, которые в этом не очень хорошо разбираются. Команда ушла в себя на 9 месяцев, создала proof of concept, который умеет закрывать почти все подобные кейсы. Но для внедрения такое решение оказалось тяжелым, потому что не влезает в кабину грузовика и потребляет слишком много энергии.
Нужна была совместная с представителями бизнеса работа, чтобы найти реализуемое решение. То есть единая команда, у которой:
Постановка бизнес-задачи
К сожалению, задачи по data science часто ставят люди, которые не разбираются в искусственном интеллекте и машинном обучении. Получается как-то так.
Представьте, что человек, который никогда не видел реальных продуктов, никогда не пользовался компьютером и знает о разработке ПО из журналов, писал бы требования для инженера. И это только часть проблемы.
Вторая часть проблемы: «Всем норм». Почему-то data scientist’ы, в отличие от разработчиков ПО, не спорят с такими постановками. Они всегда могут сделать крутую модель.
Заказчик говорит, что читал в журнале про TensorFlow и хочет его внедрить. Он не знает, зачем и почему, но это прикольно. Data scientist с удовольствием берется запускать TensorFlow для чего-нибудь, потому что ему тоже прикольно. В результате все это не внедряется, не запускается, пользы не приносит.
Чтобы не применять data science просто «чтобы было» нужна профессиональная роль — product owner или product manager.
AI Product Owner
Data science должен перестать быть сервисом для людей, которые не понимают, как поставить задачу data science. Должен быть человек, который является мостом между бизнесом и data science, у которого есть понимание возможностей и ограничений data science. Product owner сможет построить ценный продукт на стыке возможностей и потребностей. Но для этого у него должны быть полномочия в принятии решений.
Без product owner могут получиться классные пилоты, для промышленного внедрения которых нужно решить миллион вопросов: кто будет поддерживать и развивать, куда денутся люди, которые раньше следили за камерами, как, возможно, нужно менять регламенты, кто будет отвечать за инциденты и т.д.
Часто, чтобы внедрить data science-решение, нужно поменять структуру самой организации — создать новые отделы, а некоторые старые убрать. Product owner — это тот человек, который должен уметь решать такие задачи и у него должны быть соответствующие полномочия.
Говорят, что иногда data scientist должен прямо сказать, что данные плохие и хорошо обучить на них модель нельзя. Это правильно, но этого недостаточно. За этим должен идти следующий шаг — что-то придумать, сделать, чтобы в следующий раз были подходящие данные. Задача единой команды и product owner или product manager собрать или научиться собирать нужные данные. Это требует определенной работы, и data science-специалист может дать рекомендации, что для этого нужно. Но все равно это пока рекомендации, которые нужно довести до результата.
У product owner должно быть достаточно мотивации и понимания, что он действительно отвечает за результат. Когда у него есть ответственность за результат с точки зрения бизнеса и потребителя, а не за сервис, тогда появляются реальные, полезные результаты.
Product Brief
Чтобы перейти к практике, нужно правильную поставить задачу. Мы для себя придумали Product Brief:
Самым трудоемким в этом Product Brief является формулирование критериев успеха. На старте не всегда понятно, чего же хотят добиться заказчики, и ответ на этот вопрос может занять до нескольких недель. Поэтому после первого брифа мы поняли, что для того, чтобы сформулировать критерии успеха, нужно сразу смотреть данные. Product manager или product owner должен подключить специалистов по data science уже на этом этапе.
Теперь мы тратим максимум две встречи и неделю-полторы на то, чтобы составить Product Brief. Мы формулируем в бэклог задачи в примерно таком виде: «Исследовать данные для того, чтобы понять то-то и то-то», и они уже помещаются на доску задач. Мы не тратим на это слишком много времени, не требуем строгой постановки. Это просто что-то, о чем нужно подумать на старте, а заполнять во время выполнения проекта. Когда мы понимаем, что проект уже чего-то достиг, мы способны сформулировать критерии успеха.
Гипотеза
Далее формулируем гипотезу — некоторое представление о том, чего мы хотим на самом деле добиться:
Нет никакого смысла делать то, что не нужно заказчику, только потому что это интересно data scientist’ам. С другой стороны, нужно разграничивать, какие из ограничений действительно заданы жестко, а какие не следуют из технологических характеристик и являются скорее рекомендациями.
Когда есть набор гипотез, с которыми работает команда, процесс намного прозрачнее для бизнеса. Ему становится понятно, зачем выполняется каждая из задач, к чему команда стремится в итоге.
Бизнес-анализ
Как правило, data science-проекты не очень зрелые, бизнес-анализом по сути никто не занимается. Как задачу поставили, так ее и решают, не учитывая бизнес-контекст. На самом деле в data science-проекты полезно потихонечку добавлять:
Пример: крупный ритейл измеряет показатель NPS — насколько пользователи преданы компании. Data science-команда получила задачу установить, есть ли связь между NPS и доходом компании.
Нет ничего удивительного в том, что дать четкий ответ data science не смогли, потому что данные зашумлены. Эта задача, как корреляция всего со всем, — конечно, данные будут зашумлены. Но что, если попытаться понять, что на самом деле происходит внутри организации? Разобраться, как ведет себя пользователь? Как работает условная физика того, что человек делает, когда заходит в магазин?
Гипотезу «При росте NPS прибыль компании увеличивается» можно разбить на подгипотезы, которые уже можно проверить и получить полезную информацию, например:
Подробнее о работе с гипотезами рекомендую посмотреть в выступлении Адама Елдарова из YouDo на встрече сообщества LeanDS_RU. А мы переходим к следующей типовой проблеме в data science-проектах.
Члены команды не умеют взаимодействовать
Data scientist — общий термин, и, конечно, они бывают разные. Но в среднем data scientist’ы друг с другом не коллаборируют, как ни странно. Первое, что вы ожидаете от специалиста по data science — что он посоветуется с другим специалистом. Но чаще всего это не так: каждый берет свою задачу и тащит ее до какого-то промежуточного результата, а потом забрасывает через забор, например, к программистам. При этом коллаборации по дороге не происходит — ни у data scientist’ов друг с другом, ни между data scientist’ами и программистами. Это нужно иметь в виду и работать с этим.
Пайплайн (value stream)
Работая с data science-проектами, важно понимать отличие пайплайна от software engineering-проектов.
Пайплайн data science длинный, нужно проделать достаточно много работы, которая занимает существенное время:
Scrum в data science-проекте
Внедрение Scrum в проект с таким пайплайном спотыкается о серьезные проблемы.
Пайплайн очень длинный. Из-за этого запланировать и сделать что-то до конца внутри короткого двухнедельного спринта просто не успеть. Это приводит к тому, что каждый раз часть задач переходит на следующий спринт, а затем еще на следующий и т.д.
В отличие от Scrum в software engineering, где есть постоянный инкремент для демонстрации результатов, в data science нет материала сбора обратной связи. В разработке есть демо, можно показать продукт заинтересованным лицам, собрать обратную связи и работать с ней на следующих итерациях. В data science есть просто модель, например, рекомендательная. За спринт удалось повысить её точность с 60% до 65%. Подходит ли это для демо и что можно сделать с обратной связью по такому результату? Ничего.
Требования на спринт меняются. В data science есть итеративность между фазами подготовки данных (Data preparation) и моделирования (Modeling), где все может поменяться.
Например, появилась новая гипотеза, подготовили данные (это может случиться на второй день спринта), проверили гипотезу и всё, что запланировано до конца спринта, уже не имеет никакой ценности. Всё нужно переделывать, потому что концепция поменялась.
Поэтому классический Scrum не работает, от него надо отходить.
Когда не работает Scrum, как и в любой непонятной ситуации, мы дружно внедряем Канбан.
Канбан в data science проекте
На каком принципе его строить? Ближайший аналог из сферы software engineering — это Lean Startup. Lean Startup подразумевает, что есть гипотезы о том, что принесет ценность продукту. Процент гипотез, которые принесут пользу (big discovery) очень небольшой — максимум 10%.
На старте мы, естественно, не знаем, какие именно гипотезы принесут пользу, а просто пробуем, пока что-то не получится. Для этого используется HADI-цикл.
Примерно похожий процесс можно выстраивать в data science-проектах. Нормально, если 80% гипотез умрет. Мы просто постепенно двигаемся.
Для этого нужен Process Framework, в котором есть:
Заметьте, что моделирование и data preparation объединено в одну фазу, потому что иначе это очень неудобно по Канбану двигать: по сути работа с данными и эксперименты происходят в один и тот же момент.
Основные элементы схемы:
Ограничивать working progress особенно важно в части «Data Understanding».
Цели этапа Data Understanding:
Примеры бизнес-метрик, которые анализируются на этапе Data Understanding: размер данных, распределение, средние значения, корреляции, аномалии данных.
Проблема валидации начальных данных вытекает из все той же не построенной коммуникации. Data scientist’ы получая данные, не уточняют, насколько они могут быть некорректны, а сразу начинают с ними что-то делать. Заказчик, в свою очередь, по умолчанию думает, что команда убедится, что с данными все в порядке, или спросит.
Если при работе с данными появляются явные аномалии, то проблема вскрывается быстро. Но на практике лучше явным образом искать, что с данными не так, и уделять ограниченное время, например, 1-3 дня на первичную работу с данными. По сути на этом этапе команда data science занимается верификацией данных, чисткой, заполнением пропусков и т.п. и уточняет у постановщиков, соответствуют ли предельные характеристики реальному положению вещей.
С первыми компаниями мы работали так: ставили дедлайн команде, когда работа должна быть сделана; ребята работали с данными, ближе к концу срока показывали отчет клиенту. И почти всегда что-то шло не так, всегда что-то оказывалось неправильно понятым и клиент не принимал результат.
Поэтому процесс перестроили так, чтобы всегда были промежуточные результаты, которые нужно показывать и валидировать со специалистами в предметной области.
Конечно, это спорный вопрос, но я считаю, что это и есть результат работы data science-команды, по крайней мере до выхода в прод: что мы сегодня поняли, поработав с данными. Это и есть хороший промежуточный результат, на который можно посмотреть.
Если на стендапе выясняется, что ни одного «finding» не было, для нас это значит, что что-то идет не так, и мы обязательно выясняем, что случилось, есть ли какой-то блокер. Это помогает не терять времени на ситуации, когда data scientist уже подозревает, что текущая модель не принесет результатов, но надеется еще что-то из неё выжать.
Findings — сначала мы называли их insights, но пришли к выводу, что это все-таки преувеличение — порождают новые гипотезы, которые так же попадают на доску. Таким образом, в процессе нет итеративности — гипотезы просто двигаются по Канбану слева направо. В data science не надо прыгать туда-сюда, лучше начать прорабатывать новую гипотезу и не беспокоиться, если она провалится. Генерация новых гипотез вместо итерации повышает прозрачность.
Эксперимент в этом примере сформулирован на языке data science, но по крайней мере у него есть связь с какой-то гипотезой, понятно, зачем он нужен.
Приоритезация гипотез:
Также нужно учитывать, что постоянная генерация гипотез и итоги их проверки могут повлиять на постановку. Нормально, если вы сделали гипотезу и выяснили, что постановка неверная. Это естественный discovery-процесс.
Подводя итог проблеме взаимодействия, напомню:
Низкое качество data science-продуктов
Особенность data science-продукта, его отличие от software engineering — модель всегда выдает результат. Она как-то обучена и, если подать валидный вход, что-то да выдаст. Нормально запущенная в прод рекомендательная система в любом случае будет что-то показывать. Но пользователь (конечный клиент) никогда не поймет, из-за чего он видит нерелевантные результаты: это баги или специфика обучения модели. Это основная причина низкого качества data science-продуктов.
А если баг все-таки есть, его очень трудно пофиксить. Допустим, заказчик замечает, что рекомендательная система показывает кеды, которые ему не нравятся, и не показывает интересные ему кроссовки. В разработке это решается так: «Ладно, через 2 дня покажу новый результат».
В data science это может быть еще 2 месяца работы, потому что, например, была ошибка в данных, на которых шло обучение. Её быстро обнаружить, но потом нужно найти новые данные и пройти с ними полный пайплайн проекта. И даже тогда система имеет ограниченную, не 100% точность, то есть заведомо есть вероятность, что результат работы модели будет ошибочным. Исправить этот баг вообще невозможно.
Baseline как MVP
Первое, что поможет повысить качество, — это baseline. Чтобы что-то улучшить, нужно понимать, с чем сравнивать. Первый baseline чаще всего вообще не основывается на ML.
Например, задача: по логотипу выдать название компании. Пока команда data science собирает данные и обучает модель, software-инженер, который не разбирается в ML, запустил самое простое и быстрое решение — забросить логотип в Google и вернуть первую ссылку. Конечно, точность будет не 100%, но это уже хороший ориентир. Который, к тому же, вполне может решить проблему пользователя.
Если быстро сделать самое простое базовое решение, можно обнаружить, что примерно 40% задач можно даже не доделывать. Если MVP решает проблему пользователя, то можно заняться чем-нибудь другим, чем-нибудь более полезным для продукта.
По моим наблюдениям есть два типа data scientist’ов:
Результаты работы data scientist’а как на картинке справа часто невоспроизводимы. У них что-то получается локально в Jupyter Notebook, но перенести это в прод и там воспроизвести результат задача максимально нетривиальная.
Тестирование? Зачем, мы же ученые, а не инженеры
Эта проблема свойственна классической науке. Мне очень нравится пример ученых из Гарварда Carmen Reinhart и Kenneth Rogoff, которые в 2010 году опубликовали работу «Growth in a Time of Debt». В статье утверждается, что в странах с большими внешними долгами, сильно ограничен рост ВВП. В течение нескольких лет некоторые страны действительно пытались поменять свою монетаристскую политику, чтобы уменьшить свои долги.
В 2013 году выяснилось, что авторы статьи допустили ошибку: в Excel не дотянули формулу до последней строки. В этом нет ничего удивительного, потому что во всем мире ученых оценивают по количеству опубликованных работ и индексу цитирования, а не качеству работы.
Data scientist’ы тоже ученые и тоже грешат таким подходом.
Конфигурационное управление
Выправить ситуацию поможет конфигурационное управление, как основа командной работы. Должно появиться управление версиями, грубо говоря data scientist’ы должны начать пользоваться Git. Не все понимают, зачем это нужно, объяснить довольно тяжело, но можно.
На воспроизводимость сработают автоматические проверки того, что построенная модель выдает именно то, что написано в отчете, и это всегда гарантируется. Для этого есть специальные инструменты, например: DVC, MLflow, neptune.ai. Основная их особенность — под версионным контролем находится не только код, но и данные.
Experiment review
Процесс аналогичный code review, так же как и code review бывает трех видов:
Experiment review позволяет повысить качество. Это важно, потому что ущерб от неверных расчетов может повышать стоимость команды в разы.
Подводя итоги, еще раз перечислю отличия data science от software engineering, которые нужно учитывать при построении процессов управления:
При поддержке AvitoTech Онтико уже открыли доступ к видеозаписям всех докладов с TeamLead Conf — вот плейлист. Если хотите быть в курсе новостей вроде этой, то подпишитесь на рассылку или telegram-канал @TeamLeadChannel. А мы пока готовим питерский TeamLead Conf и принимаем заявки на доклады.
