Data driven «управляемый данными»подход к управлению, основанный на данных

BDD — Behaviour Driven Development

Из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. В чем же отличие? Концепции обоих подходов похожи, сначала идут тесты и только потом начинается разработка, но предназначение у них совершенно разное. TDD — это больше о программировании и тестировании на уровне технической реализации продукта, когда тесты создают сами разработчики. BDD предполагает описание тестировщиком или аналитиком пользовательских сценариев на естественном языке — если можно так выразиться, на языке бизнеса.

Если записывать названия тестов в виде предложений и при записи имен методов использовать лексику бизнес-домена, созданная документация становится понятна заказчикам, аналитикам и тестировщикам.

Тексты сценариев записываются в определенной форме.

Может получиться что-то подобное:

Или другой пример на русском:

BDD подход совместно с инженерными практиками позволил нам отказаться от legacy-документации, содержащей неактуальную информацию, и получать новую документацию налету, хранить ее вместе с проектом, что приблизило аналитиков и тестировщиков к коду.

BDD — скорее, процесс, целью которого является удешевление реализации новых фич. Еще на старте разработки мы получаем важные артефакты. Например, понятную для поддержки документацию. Эта документация дает возможность всем заинтересованным лицам сформировать свое представление о продукте и сценариях пользовательского поведения, которые должны быть реализованы в ходе итераций разработки. С BDD-подходом мы также снижаем порог входа в проект новых участников.

В чем преимущество BDD?

  • Тесты читаемые для не программистов.
  • Их легко изменять. Они часто пишутся почти на чистом английском.
  • Их может писать product owner или другие заинтересованные лица.
  • Результаты выполнения тестов более «человечные».
  • Тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается.

Минусы:

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

Выходом из этой ситуации может оказаться выбор подходящего BDD фреймворка и правильно выстроенных процессов разработки.

Подробнее о BDD можно прочитать тут.

Многие уже давно поняли, что тестирование — это своего рода панацея от всех болезней, но так ли это на самом деле? Безусловно, основательно протестированный код работает стабильнее и предсказуемее, но тесты не избавляют нас от проблем и ошибок на этапе проектирования и постановки задач. Следующие подходы к разработке могут помочь вам с этим.

Недостатки data-driven подхода

Самый главный недостаток – данные не будут принимать решения за вас.

Первое решение, которое нужно принять, – нужен ли вашему бизнесу data-driven менеджмент.

Учитывайте нюансы:

  • Просто собирать данные недостаточно. Нужна инфраструктура сбора данных, их структуризация, систематизация и своевременная передача нужным людям в нужное время.
  • Эта инфраструктура требовательна к человеческому ресурсу. Сотрудников нужной квалификации искать сложно, и стоить они будут дорого.

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

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

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

  • Полученные данные, даже очень полные и очень точные, описывают прошлое. На основании таких данных строят предиктивные модели, но нельзя забывать, что в любой момент может прилететь «черный лебедь».
  • Для оценки нового функционала или инновационного продукта, которого раньше не существовало, data-driven подход неприменим.
  • Результаты внедрения data-driven подхода будут видны не сразу. К этому нужно быть готовым и не ждать чудес.
  • Пути назад нет. Если компания принимает решения, основываясь на данных, все остальные факторы (прошлый опыт, экспертное мнение, прочитанный в интернете кейс и т.д.) играют роль только на этапе формирования гипотез.

Как стать Data Driven-компанией

Data Driven-организация корректно собирает, проверяет и обрабатывает данные и использует их на пользу бизнеса. Такие компании имеют отлаженный механизм работы с данными, в котором все сотрудники четко понимают задачи: data-аналитик собирает данные, отдел маркетинга умеет ставить четкое ТЗ на сбор конкретной информации, а руководство соотносит это с бизнес-целью.

Мария Михеева, продуктовый аналитик AliExpress, считает, что организация Data Driven-подхода затрагивает такие аспекты работы компании, как миссия, идеология и обучение сотрудников. Но в основе подхода все-таки лежат качественные данные — достоверные и очищенные от лишней информации, ненужной компании. На этих данных как раз выстраивается data-менеджмент. Кроме них, есть другие важные аспекты:

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

Кроме этого, важно, чтобы принцип работы с данными был понятен не только аналитикам, но и другим специалистам, это упрощает процесс коммуникации внутри компании

Мастер-система. Работа с данными в Data Driven-компании — это система, в которую входят хранилища с разными типами данных, инструменты для визуализации или BI-платформа (Business Intelligence) с отчетами в реальном времени (дашбордами).

Система принятия решений. Можно считать, что в организации успешно внедрен Data Driven-подход, когда для решения задачи сотрудники начинают опираться исключительно на данные или предлагают провести исследование, если таких данных пока нет.

Data leadership. Компании необходим человек, который будет заниматься внедрением подхода, координировать работу и отвечать на вопросы руководства и сотрудников.

Data Driven-культура. Под культурой подразумевается принятие новых правил всеми сотрудниками компании, когда в каждом отделе сформировано понимание, как и зачем работать с данными, а большинство сотрудников умеет работать с данными и правильно их интерпретировать.

В основе подхода лежат качественные данные. Источник

Главный критерий успеха в Data Driven-подходе — понимание сотрудниками компании того, зачем нужны данные. Поэтому работу над этой управленческой стратегией стоит начинать с внутреннего PR, презентации и обучения.

FDD — Features Driven Development

FDD — Эта методология (кратко именуемая FDD) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.

Как и остальные адаптивные методологии, она делает основной упор на коротких итерациях, каждая из которых служит для проработки определенной части функциональности системы. Согласно FDD, одна итерация длится две недели. FDD насчитывает пять процессов. Первые три из них относятся к началу проекта:

  • разработка общей модели;
  • составление списка требуемых свойств системы;
  • планирование работы над каждым свойством;
  • проектирование каждого свойства;
  • конструирование каждого свойства.

Последние два шага необходимо делать во время каждой итерации. При этом каждый процесс разбивается на задачи и имеет критерии верификации.

Давайте поподробнее остановимся на каждом пункте.

Разработка общей модели.

Разработка начинается c анализа широты имеющегося круга задач и контекста системы. Далее для каждой моделируемой области делается более детальный разбор. Предварительные описания составляются небольшими группами и выносятся на дальнейшее обсуждение и экспертную оценку. После одна из предлагаемых моделей или их совокупность становится моделью для конкретной области. Модели каждой области задач объединяются в общую итоговую модель, которая может изменяться в течение работы.

Составление списка функций

Информация, собранная при построении общей модели, используется для составления списка функций. Функции объединяются в так называемые «области» (англ. domain), а они же в свою очередь делятся на подобласти (англ. subject areas) по функциональному признаку.

Каждая подобласть соответствует определенному бизнес-процессу, а его шаги становятся списком функций (свойств). Функции представлены в виде «действие — результат — объект», например, «проверка пароля пользователя». Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо декомпозировать на более мелкими итерации. Список свойств в FDD – то же самое, что и product backlog в SCRUM.

План по свойствам (функциям)

Далее идет этап распределения функций среди ведущих программистов или по командам.

Проектирование функций

Для каждого свойства создается проектировочный пакет. Ведущий программист выделяет небольшую группу свойств для разработки в течение двух недель. После оставляются подробные диаграммы последовательности для каждого свойства, уточняя общую модель. Далее пишутся «заглушки» классов и методов. В этот момент мы должны сфокусироваться на дизайне программного продукта.

Реализация функции

Пишем код, убираем заглушки, тестируем.

После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.

Итого, в результате мы получаем:

  • документация по свойствам системы;
  • тщательное проектирование;
  • проще оценивать небольшие задачи;
  • тесты ориентированы на бизнес-задачи;
  • проработанный процесс создания продукта;
  • короткие итеративные циклы разработки позволяют быстрее наращивать функциональность и уменьшить количество ошибок.

Минусы:

  • FDD больше подходит для больших проектов. Небольшие команды разработки не смогут прочувствовать все преимущества данного подхода;
  • значительные затраты на внедрение и обучение.

Важно: проверьте достоверность данных, с которыми работаете

Ошибки в данных бывают очень часто. Задвоенные транзакции в Google Analytics, расходы могут передаваться не полностью, не размечены как транзакции покупки в 1 клик (а только через корзину), некорректно настроенные A/B-тесты — всё это делает регулярную работу с данными бесполезной и может даже привести к убыткам.

Если вы понимаете важность развития аналитической культуры в компании, но не знаете, с чего начать, начните с формирования у сотрудников привычки работать с данными.

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

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

P.S. Как спроектировать правильный дашборд и выбрать инструмент визуализации — читайте в нашей инструкции.

Наталья Веселова, аналитик ZV.Digital.

Источник фото на тизере: Ricardo Gomez Angel on Unsplash

Рекомендуем:

  • Как маркетинг-аналитика помогает бизнесу принимать взвешенные решения и расти>
  • Визуализация данных в Google Data Studio своими силами и без дополнительных затрат
  • Data-driven подход в маркетинге фармы: «новая нефть» или плацебо?
  • Как визуализировать данные с помощью Yandex DataLens: обзор инструмента и пример использования
  • Data-маркетолог: зачем осваивать новую профессию
  • Внедрить data-driven и остаться в живых. Подводные камни веб-аналитики

Почему необходимо становиться Data-driven компанией?

Чтобы понять, почему необходимо становится Data-driven компанией, необходимо дать ответ на вопрос: «Что значит быть Data-driven компанией?» Руководство большинства компаний считает, что если их компания создает и использует в своей работе различные отчеты, то она является Data-driven компанией. Однако если взглянуть на работу с данными более комплексно, то в современном цифровом мире недостаточно обладать хорошо структурированными отчетами, содержащими полезную информацию. Зачастую подобные отчеты способны предоставить информацию о том, что на предыдущей неделе произошло снижение продаж, но при этом они не могут дать ответ на самые главные вопросы: «Почему это произошло, и какие меры необходимо предпринять?» Помимо этого, данный отчет, возможно, не достигнет своего адресата из-за недостаточно выстроенных бизнес-процессов и отсутствия конвейеров по сбору и обработке данных. Аналогичная ситуация наблюдается в большинстве компаний в отношении разрабатываемых KPI (Key Performance Indicators), представленных на дашбордах, основывающихся только на статистических данных.

Основное отличие Data-driven компании от любой другой — это умение использовать существующие данные для реализации предиктивной аналитики — аналитики, которая использует текущие данные для получения преимуществ в будущем. Data-driven компания способна реализовать аналитику, нацеленную на будущее, и регулярно давать ответы на такие вопросы, как: «Какие причины привели к данному событию?», «Какие меры необходимо предпринять для решения возникшей проблемы?», «Какой прогноз мы можем построить на основе имеющихся данных?» Таким образом, только дата-ориентированные организации способны монетизировать данные — извлекать и повышать прибыль бизнеса за счет применения практик по анализу данных. За счет этого данные становятся не просто отчетами и визуализациями, а реальным инструментом по построению системы поддержки принятия решений и увеличения прибыли компании.

Резюме

В нашем поганом мире гарантии отсутствуют.

Профессионалы оперируют вероятностями.

Генерал Дж. С. Паттон

Так стоит ли ввязываться в сложное и затратное внедрение data-driven?

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

Сбор данных – только первый этап. Далее следует их интерпретация, затем – принятие решений и корректировка стратегии бизнеса.

Важно, чтобы решения, основанные на данных, не привели к датацентричности, о которой предупреждает история дизайнера Google. Он покинул команду из-за чрезмерного «датацентризма»

Вот как он прокомментировал свой уход:

С чего начинать внедрение?

Собрать команду.

  • Начать собирать данные из максимального количества источников (продукт, рекламные кабинеты, CRM/ERP система и т.д.).
  • Спроектировать архитектуру структуры данных, необходимых для принятия решений на всех этапах.
  • Наладить процесс передачи нужных данных нужным людям в нужное время.
  • Визуализировать данные.
  • Использовать!

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

Важно понимать суть каждого подхода, возможности и применимость к конкретной ситуации. Когда вы работаете над чем-то, у вас есть видение того, к чему вы хотите прийти

Данные нужны, чтобы корректировать направление движения.

Например, с помощью HADI-циклов:

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

Обработка (Processing)

Если речь заходит о том, что объектная модель изменяется на основе своих свойств без внесения новых данных, то мы обращаемся к слою Интерактора напрямую. Слой Интерактора является ключевым в нашем приложении, именно в нем описывается вся бизнес-логика в виде отдельных Вариантов использования (Use Cases) и именно на нем идет изменение Сущностей.

Рассмотрим такой сценарий использования. В нашей гостинице посетитель уже зарегистрирован, но мы отмечаем каждый его приход или уход.

Давайте немного остановимся. Почему не сделать реализацию одним методом с параметром ? Интеракторы и в корне отличаются. Если к нам пришел постоялец, то мы должны проверить закончилась ли уборка, не поступало ли для него новых сообщений и т.п. При его уходе мы, наоборот, должны инициировать уборку в случае необходимости. Про сообщения, в свою очередь, мы даже не вспоминаем, поскольку если бы он был в гостинице, мы бы ему сразу позвонили. Именно всю эту логику бизнеса мы и прописываем на слое Интерактора.

Но что нам делать, если у нас есть данные извне? Тут подключается действие Сбора данных.

Сбор данных (Collecting)

При первичной регистрации постояльца в гостинице он заполняет форму регистрации. Эта форма проверяется. Если данные верны, то происходит бизнес-процесс Регистрация. Процесс возвращает данные — созданную бизнес-модель «Постояльца». Эту модель мы представляем постояльцу в читаемой форме:

Схематично это выглядит так:

Правила игры (Rules)

  • Вариативная система с точки зрения процессов делится на Действия.
  • Последовательность Действий определяется Режимом.
  • Режимы инкрементальны.
  • Более «сложный» Режим дополняет более «простой», на строго одно действие.
  • Каждое действие происходит в рамках одного Слоя.
  • Каждый слой представлен Классом.
  • Внутри слоя могут быть Классы-Слои и Классы-Ответственности.
  • Общение происходит только между Слоем и Внутрислойным Классом.
  • Модели-Представления являются исключениями.
  • Обработка ошибок должна происходить на уровне Класса-Cлоя.

У данного подхода высокий порог вхождения. Его применение требует от проектировщика большого опыта для четкого осознания решаемых задач. Сложность также представляет разнообразие выбора необходимого инструмента. Но, не смотря на сложность структуры, реализация на уровне кода невероятно проста и выразительна. Хотя и содержит в себе ряд условностей и доверенностей. В дальнейшем мы разберем каждый шаблон проектирования в отдельности, опишем как его создать, тестировать и обозначим область применения. А чтобы не запутаться в их многообразии, предлагается полная карта:

Data-driven and data-informed design: What is the difference?

Data-driven and data-informed design represent two approaches to working with data. The data-driven design approach uses data as its foundation, and every decision is evaluated using that data. In data-informed design, data is used as a reference when a design decision is made.

Depending on the nature of your project, both models can be beneficial. For example, a data-driven approach may be appropriate when you want to do performance optimization—quantitative metrics such as time-to-load will help you to understand when you will face performance bottlenecks. Data-informed design, on the other hand, is great when you want to know what problems a user faces when they interact with your product, introduce changes in your design that will solve problems, and measure the impact of your changes.

Data-Driven против Data-Informed

Иногда люди думают, что разница между Data-driven (основанный на данных) и Data-informed (действующий с учетом данных) подобна potayto potahto. Некоторые организации называют себя приверженцами Data-driven, другие называют себя Data-informed. Для многих это означает одно и то же.

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

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

Принятие решений, управляемых данными: клики растут. Посещения (основной показатель для этого издателя) растут. Доход (с тех пор, как они запускают объявления CPM) растет. Здорово! Все наши ключевые показатели растут. Давайте отправим заголовки с кликабельными названиями.

Принятие решений по принципу информированности данными: все наши ключевые показатели растут. Это хорошо. Каковы счетчики? Показатель отказов вырос. Это не похоже на хороший опыт, если пользователи уходят. Что относительно долгосрочных показателей счетчика? Разве мы считаем, что кликабельные названия хороши для наших пользователей? Будет ли это негативно отразиться на нашем издательском бренде? Кстати, почему кликабельные заголовки работают? Контент, который вызывает любопытство пользователей, преуспевает. Вместо того, чтобы писать кликабельные заголовки, мы можем интегрировать это понимание в нашу стратегию контента. Напишите о тех темах, о которых люди интересуются, но могут не знать достаточно.

При принятии решений, основанных на данных, данные находятся в центре принятия решений. Это первичное (а иногда и единственное) понимание. Вы полагаетесь только на данные, чтобы выбрать лучший путь вперед. При принятии решений, основанных на информированности, данные являются ключевым фактором среди многих других переменных. Вы используете данные для более глубокого понимания того, какую ценность вы предоставляете своим пользователям.

Итак, можно спросить, что случилось с культурой, управляемой данными. Данные — неопровержимый источник истины. Вера в то, что данные неопровержимы, на самом деле является мифом. Есть несколько слепых пятен в данных, которые, если их не решить, могут привести к субоптимальным решениям. Посмотрите на риски, связанные с культурой, основанной на данных.

Why Should We Care About Data-Driven Design?

Failing to consider data (or using data in an ineffective way) can have serious implications for the success of a project. If you rely solely on instinct or best practices to make decisions without performing any data-driven investigation, you risk wasting money on changes to design choices that are ineffective (or even harmful).

Using data effectively can lead directly to improved business outcomes. Research by MIT’s Center for Digital Business found that “companies in the top third of their industry in the use of data-driven decision making were, on average, 5 percent more productive and 6 percent more profitable than their competitors.”

There are many examples of cases where data-driven UX techniques have delivered a tangible improvement on ROI. For example, in 2014, airline Virgin America used A/B testing to redesign a new, responsive website. This led to:

  • A 14% increase in conversion rates
  • 20% fewer support calls
  • Customers booking nearly twice as fast, across devices

Another interesting example comes from e-commerce website Music & Arts, which used usability testing and heuristic evaluation to inform a website redesign. Upon the conclusion of the project, their online sales increased about 30% year over year.

Data-driven менеджмент

Менеджмент, основанный на данных, выполняет несколько важных функций:

  1. Максимизация эффективности вложений в бизнес. Микросегментация, управление количеством касаний, привлечение новой аудитории с учетом изменения пользовательского опыта и многое другое повышают эффективность вложений начиная от логистики и заканчивая кадровой политикой.
  2. Сокращение маркетинговых издержек. Рекламные кампании поддаются анализу вплоть до оценки эффективности конкретного рекламного объявления с учетом LTV привлеченных пользователей.
  3. Максимальная клиентоориентированность. Детальный анализ целевой аудитории, персональная коммуникация с клиентом, мониторинг отзывов, оценки удовлетворенности клиентов, проведение опросов, –– все это извлекается из данных.
  4. Оперативная реакция на изменения рынка. Отслеживание данных в режиме реального времени уже никого не удивляет, а грамотно настроенный мониторинг позволяет принимать решения молниеносно.
  5. Максимизация прибыли за счет всего вышеперечисленного.

В качестве примера рассмотрим крупнейшую в мире оптово-розничную сеть Walmart. 12 000 торговых точек, 2 миллиона сотрудников – без больших данных этого гиганта ждала бы участь динозавров. Однако у Walmart все хорошо. Компания отслеживает ситуацию во всех торговых точках, использует 200 внутренних и внешних источников информации и обрабатывает 2,5 петабайт данных в течение часа. Walmart оперативно корректирует цены на товары в соответствии с изменениями в поведении покупателей.