s2t маппинг что это
Чернобровов Алексей Аналитик
Big Data Mapping: что такое маппирование больших данных
В этой статье рассмотрено, что такое маппирование больших данных, как это связано с Data Science, когда и как часто выполняется этот процесс, а также, какие программные инструменты позволяют автоматизировать Big Data mapping.
Что такое маппирование данных и где это используется
Представим, что в одной из корпоративных систем сведения о семейном положении сотрудника хранятся так, что «1» в поле «дети» означает их наличие. В другой системе эти же данные записаны с помощью значения «True», а в третьей – словом «да». Таким образом, разные системы для обозначения одних и тех же данных используют разные отображения. Чтобы привести информацию к единообразию, следует сопоставить обозначения одной системы обозначениям в других источниках, т.е. выполнить процедуру мэппинга данных (от английского map – сопоставление). В широком смысле маппирование – это определение соответствия данных между разными семантиками или представлениями одного объекта в разных источниках. На практике этот термин чаще всего используется для перевода или перекодировки значений [1].
Дисциплина управления данными, Data Management, трактует маппинг как процесс создания отображений элементов данных между двумя различными моделями, который выполняется в начале следующих интеграционных задач [2]:
Таким образом, маппирование данных представляет собой процесс генерации инструкций по объединению информации из нескольких наборов данных в единую схему, например, конфигурацию таблицы. Поскольку схемы данных в разных источниках обычно отличаются друг от друга, информацию из них следует сопоставить, выявив пересечение, дублирование и противоречия [3].
С прикладной точки зрения можно следующие приложения маппинга данных [4]:
В Big Data мэппинг выполняется при загрузке информации в озеро данных (Data Lake) и корпоративное хранилище (DWH, Data Warehouse). Чем Data Lake отличается от DWH, рассмотрено здесь. В этом случае маппинг реализуется в рамках ETL-процесса (Extract, Transform, Load) на этапе преобразования. При этом настраивается соответствие исходных данных с целевой моделью (рис. 1). В случае реляционных СУБД для идентификации одной сущности в разных представлениях нужно с ключами таблиц и настройкой отношений (1:1, *:1, 1:* или *:*) [5].
Рис.1. Маппирование данных при консолидации таблиц
В Data Science маппирование данных входит в этап их подготовки к ML-моделированию, когда выполняется формирование датасета в виде матрицы значений для обработки соответствующими алгоритмами. В частности, когда Data Scientist обогащает исходный датасет данными из сторонних источников, он занимается маппингом данных. Проводить процедуру дата мэппинга можно вручную или автоматически с помощью соответствующих подходов и инструментов, которые рассмотрены далее.
Особенности процесса дата мэппинга
На практике трудоемкость мэппинга зависит от следующих факторов [3]:
Облегчить процесс маппирования можно за счет метаданных – сведениях о признаках и свойствах объектов, которые позволяют автоматически искать и управлять ими в больших информационных потоках. В частности, если каждое приложение будет выполнять публикацию метаданных, что позволит создать их стандартизированный реестр, то маппинг будет полностью автоматизированным [2]. Однако в большинстве случаев процесс мапирования данных не полностью автоматизирован и состоит из следующих этапов [4]:
При работе с большими объемами данных выделяют 3 основных подхода к маппированию [2]:
Также стоит упомянуть полуавтоматическое маппирование в виде конвертирования схем данных, когда специализированная программа сравнивает источники данных и целевую схему для консолидации. Затем разработчик проверяет схему маппирования и вносит исправления, где это необходимо. Далее программа конвертирования схем данных автоматически генерирует код на C++, C # или Java для загрузки данных в систему приемник (рис. 3) [3].
Рис. 3. Конвертирование схем данных в процессе мэппинга
Далее рассмотрим, какие инструментальные средства реализуют вышеперечисленные подходы.
Инструменты маппирования больших данных
Как и большинство прикладных решений, все средства для маппинга данных можно разделить на 3 категории [6]:
Большинство перечисленных продуктов поддерживают все 3 подхода к маппированию: ручной (GUI и кодирование), data-driven и семантический. Однако, семантический мэппинг требует наличия реестров метаданных, что имеется далеко не в каждом предприятии. А публичные реестры метаданных, такие как национальные, отраслевые или городские репозитории [7] не всегда напрямую коррелируют, например, с задачами построения локального DWH. Но, наряду с открытыми государственными данными и другими публичными датасетами, их можно использовать в исследовательских DS-задачах.
При выборе конкретного инструмента для маппинга больших данных стоит учитывать следующие факторы:
Резюме
Итак, маппирование данных – это важная часть процесса работы с данными, в том числе и для Data Scientist’а. Эта процедура выполняется в рамках подготовки к ML-моделированию, в частности, при обогащении датасетов. В случае одноразового формирования датасета из нескольких разных источников сопоставление данных можно выполнить вручную или с помощью самописного Python-скрипта. Однако, такой подход не применим в промышленной интеграции нескольких информационных систем или построении корпоративных хранилищ и озер данных. Поэтому знание инструментов дата мэппинга пригодится как Data Scientist’у, так и Data Engineer’у. Наконец, сопоставление данных с целью избавления от дублирующихся и противоречивых значений входит в задачи обеспечения качества данных (Data Quality) [4]. В свою очередь, Data Quality относится к области ответственности стратега по данным и инженера по качеству данных. Таким образом, понимание процесса маппирования необходимо каждому Data-специалисту.
Impact Mapping на практике
Когда читал книгу Impact Mapping первый раз, у меня было желание бросить её на середине. Всё, что там написано, слишком очевидно. Я нашел в себе силы и дочитал, благо книга коротная и с большими картинками. Как в последствии выяснилось, вся соль была в том, что все эти очевидные и простые практики из книги я не применял в своей работе.
Иногда заказчики писали свои цели в официальных документах к проекту. Иногда мне казалось, что я и так понимаю цели заказчика — они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.
История появления Impact Mapping
Раньше на старте проекта у нас были технические задания, схемы работы системы и, в хорошем варианте, прототипы интерфейса. В этих документах не хватало понимания динамики развития проекта и приоритетов в работе.
Мы начали писать User Story и делать Story Mapping. Эти практики добавили понимание того, как проект будет развиваться, какие сейчас приоритеты, дали нам возможность продуктивнее общаться с заказчиком. Чего не хватало? Продукты существуют не в вакууме, нужно видеть более глобальные задачи, которые лежат где-то выше историй использования системы. Не хватало простой игровой практики по постановке целей проекта, из которых потом будут появляться Story Mapping и список User Story.
Mijo Balic и Ingrid Ottersten в 2007 году написали статью Effect Managing IT (подробнее Agile product management using Effect Maps). Через 4 года в 2011 году Gojko Adzic выпустил книгу Specification by Example, где в главе «Deriving scope from goals» упоминает о технике под названием Effect mapping. Эта техника призвана помогать командам фокусироваться на бизнес-целях, выявлять заинтересованные стороны и их потребности.
Gojko Adzic со временем добавляет в Effect mapping несколько усовершенствований, таких как: приоритизация целей и воздействий, возможность уходить от технических деталей на уровне What, цикличность в предположениях и экспериментах и т.п. Лично мне кажется, что это важные изменения, они добавляют полезности в реальной жизни. После этого техника стала называться по-новому — Impact Mapping.
Сколько стоит килограмм кода?
Представьте себе ситуацию. К вам приходит заказчик. У него уже есть набор фич на покупку, он знает чего хочет. Он берёт корзину для покупок, как в магазине. Складывает в неё список технологий, десяток прототипов интерфейса, интеграцию с соц. сетями и т.п. Подходит к кассе и просит всё взвесить, реализовать и выставить ему счёт.
Получается, что заказчик пришел к вам с готовыми решениями каких-то своих проблем. В такой ситуации в работе будут только руки разработчика, но не голова. Разработчик не сможет критически взглянуть на все решения, которые мы будем делать.
Будет ли такой проект успешным? Если у клиента живой бизнес и проект делается не «в стол», то успех можно оценить только эффектом, который был оказан на бизнес. Не количеством поставленных фич, не соблюдением сроков, не соблюдением бюджета, а только изменениями в бизнесе.
Скажем честно, сложно гарантировать, что проект станет успешным. Зато в наших силах увеличить шансы на успех за счёт того, что каждый в команде будет понимать и разделять цели бизнеса. Тогда любое решение — от именования переменной в коде до выбора архитектуры — будет приниматься, исходя из реальных потребностей бизнеса.
Остается вопрос, как вытащить из заказчика реальные цели бизнеса, которых мы хотим достичь? Как сделать так, чтобы команда услышала их, приняла и начала с ними работать?
Составляем Impact Mapping
Impact Mapping — это mind map по целям проекта с картой влияний, которые должны подтолкнуть бизнес заказчика к достижению целей.
Why?
Центральный элемент нашей карты, который отвечает на ключевой вопрос: Зачем мы это делаем? Это цель, которую бизнес пытается достичь.
Who?
На первом уровне мы отвечаем на вопросы: Кто может поможет достичь желаемого результата? Кто может помешать? Кто пользователи нашего продукта? Сюда войдут все заинтересованные стороны, которые могут повлиять на цели бизнеса.
How?
На втором уровне мы должны описать воздействия, которые должны оказать заинтересованные стороны, чтобы бизнес достиг целей. Мы ищем ответ на вопросы: Как они помогут бизнесу достичь целей? Как они могут помешать успеху проекта?
What?
После ответа на основные вопросы можно обсудить конкретные задачи. Третий уровень отвечает на вопросы: Что мы можем сделать как организация или команда разработки, чтобы создать необходимые воздействия? Здесь будет описан конечный результат нашей работы.
Организация процесса
Пример из практики
Разберём пример, очень приближенный реальному проекту, для которого в начале мы сделали Impact Mapping. Остановимся на ключевых моментах при составлении Impact Mapping и на ошибках, которые могу погубить всю идею.
Корневым элементом нашей карты будет список бизнес-целей. Например, это может быть увеличение удовлетворенности пользователей в 2 раза. Важно, что удовлетворенность пользователей — это индекс, т.е. конкретная цифра, которую можно взять из CRM, а не мнение/ощущение заказчика. Мы же хотим после поставки фич измерить достижение цели и понять, в том направлении мы идём или нет. Если бы удовлетворенность пользователей была не цифрой, то как бы мы узнали, что достигли цели? Ещё важно, что мы написали именно в 2 раза, а не просто увеличение. Хорошие цели должны быть SMART:
На HappyDev 2014 я проводил мастер-класс по составлению Impact Mapping и Story Mapping. Играть роль заказчика согласился руководитель проекта по обработке заявок на строительство. Все, кто пришел на тренинг, были очень активными и сразу втянулись в процесс. Со временем мы осознали, что довольно сложно просто слушать заказчика и понять его проблему. Коллеги наперебой предлагали свои решения. В какой-то момент приходилось прерывать работу группы, напоминать, что мы должны больше слушать. Несколько раз из-за напряженной атмосферы и давления участников, заказчик принимал наши решения, откзываясь от своих. Я думаю, что все участники почувствовали важный баланс между тем, когда надо слушать заказчика, а когда надо предлагать решения.
На этом этапе мы должны выявить всех, кто поможет оказать влияние на цель, кто поспособствует её достижению или помешает. В нашем примере это будут Отдел маркетинга и Модератор форума. По мнению заказчика именно они могут изменить удовлетворенность пользователей:
Здесь мы можем указывать конкретных людей, названия отделов, сегменты рынка и т.д. Выбирайте любой уровень абстракции, лишь бы он был адекватен вашему проекту.
Теперь нам надо определить те воздействия, которые будут сделаны для достижения цели. Например, модератор форума может попробовать давать ответы на вопросы в течение 1 минуты. Как вы думаете, повысит это удовлетворенность пользователей? У нас есть предположение, что повысит, поэтому записываем этот «impact». Тоже самое делаем для остальных ролей:
Мы дошли до самого несущественного в Impact Mapping. В последнем узле нашей карты находится та самая корзина с покупками, с которой обычно начинается работа над проектом. Разница в том, что теперь мы понимаем ценность каждой фичи, почему эта фича здесь и к чему приведет её реализация:
Результаты создания Impact Mapping
Вот и готов наш Impact Mapping. Осталось приоритизировать каждую колонку. Не все цели одинаково важны, тоже самое можно сказать про остальные узлы карты. Есть разные способы приоритизировать. Т.к. мы идем по пути простоты и визуализации, то я могу рекомендовать ставить звездочки. Каждому участнику даете по 5 звезд и он может ставить их куда хочет. Таким образом, можно выявить самые приоритетные узлы.
Фильтр входящих задач
Даже когда все согласились с целями проекта и способами их достижения, заказчик может добавить в проект фичу, которая ему очень нравится — pet feature. Мы можем отфильтровать её через цели, показать что эта фича никаким образом не приведет нас к достижению целей.
Аналогично мы будем фильтровать идеи по архитектуре и дизайну системы, которые исходят от команды разработки. Ведёт ли переделка архитектуры к более быстром и дешевому достижению цели? Если нет, то зачем нам это делать?
Модернизация Kanban-доски
Какая колонка идет последней на вашей Kanban-доске? Могу поспорить, что это Release, Deploy, Done или что-то в этом духе. Последней колонкой на доске должна стать — проверка достижения цели. Недостаточно просто залить фичу на сервер, нам нужно проверить достигли мы цели, как предполагали или нет.
Impact Mapping является одной из активностей, которые сделают и заказчиков и разработчиков более счастливыми и эффективными. Ставьте правильные цели правильно!
Impact Mapping — как dev-команде перестать делать то, что требуют, и начать делать то, что нужно?
Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия
На странице доклада можно найти презентацию и видео, а здесь текст…
Сразу сделаю ремарку, что компания у нас продуктовая и в моем рассказе, возможно, будет много нашей специфики. Но стоит пояснить, что сам подход достаточно универсален, чтобы быть примененным и в заказной разработке, и в каких либо специфичных сценариях.
Итак, почему я считаю что не всегда команда разработки в нашем случае делает то, что нужно и причем здесь Импакт Маппинг.
В двенадцати часовых поясах от него живет команда разработки, которая реализует необходимые фичи и в основном ни сном, ни духом почему изменения требуются именно такие. Бэклог для них это просто список покупок, за которыми отправили в магазин. Что именно будут готовить они, как правило, не знают.
Итак, какие общеизвестные проблемы растут из-за этого пробела в коммуникациях.
Проблемы
1. Так как решение о том, какие изменения нужны в продукте для достижения поставленной бизнес цели, принимается единолично менеджером продукта, не всегда эти решения эффективны и обоснованы.
2. Команда, которая не понимает куда стремится продукт, не мотивирована на то чтобы делать его лучше. Они просто закрывают фичи, не более.
3. Пояснять команде как именно должна быть реализована фича и почему именно в таком порядке, не зная исходной цели крайне сложно.
4. Развиваем профессиональное заболевание любого менеджера по продукту. Они просто обожают ближе к дате релиза расширять требования различными бесплатными на их взгляд мелочами. Все эти «небольшие правки» с большим трудом вырезаются из бэклога просто потому что мы не знаем действительно ли они не важны.
Мы уже пытались ранее решить эти проблемы различными способами.
1. У нас был документ с маркетинговыми требованиями — MRD. Постепенно отмер. Возможно, как дань переходу на agile, где принято больше говорить, нежели писать.
2. Были «темы»=themes, которые должны были описывать релиз и задавать общий тренд всех изменений одним абзацем. Тоже не пошло.
Импакт мапинг стал для нас очередной попыткой внести ясность в то, куда продукт движется и как мы, как команда разработки, этому способствуем.
Импакт маппинг
Импакт маппинг – это подход к стратегическому планированию, позволяющий построить логическую цепочку от бизнес-целей в голове у продакт-менеджера до изменений в продукте, необходимых для достижения поставленных целей.
Название подхода (импакт — воздействие) обуславливается тем, что мы пытаемся понять: кто и какое именно воздействие на нашу цель может оказать, и только потом принимаем решение, что нужно изменить в продукте для этого.
На выходе мы получаем карту mind map, которую в процессе обсуждения рисуют совместно бизнес и представители дев-команды. Никаких многостраничных документов, только одна хорошо структурированная схема.
Для подготовки карты требуется ответить на четыре простых вопроса.
Шаг 1. Why — зачем
Сначала требуется ответить на вопрос why – зачем
1. Зачем мы выпускаем данную версию продукта,
2. Почему мы считаем, что в продукте требуется что-то поменять
На данном шаге мы определяем цель. Цель естественно должна быть смартовой (SMART):
1. Конкретной,
2. Измеряемой,
3. Ориентированной на действие,
4. Достижимой в разумный промежуток времени.
Ответ на вопрос “Why” есть (должен быть) у нашего менеджера продукта, но навряд ли его цель соответствует критериям. Над этой целью придется еще поработать.
Хорошая цель представляет собой проблему, которую нужно решить, а не готовое решение.
Шаг 2. Who – Кто
Следом отвечаем на вопрос Who? — кто? Основная задача – определить круг заинтересованных (или не очень) лиц.
1. Кто нам может помочь с достижением цели?
2. Кто может помешать?
На этом шаге важно рассмотреть всех задействованных лиц, а не только юзеров. Все кто может повлиять на результат, должны попасть на нашу карту. Продукты не работают в вакууме, и использование продукта влияет не только на конечных пользователей.
В нашем случае это оказались и другие команды, с которыми интегрируемся, и маркетинг, и даже топ менеджеры компании.
Шаг 3. How – Как?
1. Отвечаем на вопрос по каждому задействованному лицу — как мы должны изменить (воздействовать на) поведение этого действующего лица, чтобы он посодействовал нам в достижении цели?
2. Определяем воздействие на юзеров и других действующих лиц
Это, пожалуй, единственный «вопрос» из всего подхода impact mapping’а, требующий пояснения на примере.
У нас был проект, перед которым была поставлена цель — «увеличить количество пользователей желающих продолжить разбираться с продуктом после триального периода»:
Был сформулирован impact — «shorten time to value», т.е. сократить промежуток времени, который требуется пользователю, чтобы понять какие возможности ему предоставляет продукт, какие его проблемы решаем (начиная с момента, когда пользователь открывает авторан).
Идеально сформулированное воздействие — простое и напрямую влияющее на цель.
По факту было сделано огромное количество изменений в документации, сетапе, GUI и так далее.
Шаг 4. What – Что?
Последний вопрос для построения карты — что. Именно на этом этапе появляются фичи.
Нужно понимать, что не всегда для оказания нужного нам воздействия требуется вносить изменения в продукт и что-то девелопить. Порой достаточно изменить документацию, например. Или другой пример — для привлечения пользователей не всегда нужны фичи, альтернативным решением может стать маркетинговая активность и проведение рекламных компаний.
Этапы построения карты
1. Определяем цель, не забывая о требованиях SMART,
2. Выбираем метрику, по которой будем смотреть насколько мы приблизились к цели,
3. Определяем промежуточные этапы для достижения цели (milestones),
4. Рисуем костяк карты, отвечая на четыре ключевые вопроса – why+who+how+what,
5. Ищем возможные альтернативы, причем желательно сфокусироваться не на фичах, а на ролях (who?) и на том, как на них воздействовать,
6. Определяем приоритетные направления на карте,
7. По мере продвижения не забываем удостоверяться, что мы действительно продвигаемся к цели максимально эффективным образом.
Пример карты
Пример честно позаимствован из книги, о которой будет упомянуто ближе к концу доклада.
1. Онлайн игра, преследующая цель расшириться до 1млн игроков (промежуточный этап вырасти в 2раза от 400 до 800к игроков),
2. Выделены несколько ролей, явно видно с достижением цели нам могут помочь не только игроки, но и рекламщики, например,
3. На каждой из веток выделено по несколько воздействий,
4. Фичи в явном виде соответствуют цели. Помните наши проблемы? Здесь мы явно видим что делаем, почему и более того видим несколько альтернативных вариантов движения к цели.
5. Звездочками на ветках карты отмечены приоритетные направления,
6. Ветви карты легко ложатся на пользовательские истории истории (As a… I want to… So that …).
Внедрение Impact Mapping в Dell
Я выступал в роли инициатора, поэтому в первую очередь все внедрение было поделено на этапы.
Время для этапа 1 определилось по звездам, но как выяснилось, конец текущего релиза, время, когда требуется начать выяснять задачи на следующую версию это и есть лучший момент для начала перехода на новые рельсы.
Начал я с того, что продал идею импакт маппинга менеджеру продукта и объяснил ему почему нам нужно жить по новому. Мы обсудили — с какими проблемами мы, как дев команда, обычно сталкиваемся, почему мы ощущаем недостаток понимания — куда движется продукт и почему это плохо.
Для нашего ПМа данный диалог оказался сюрпризом. Впрочем, отрицать очевидное он не стал.
Итак, я представил идею импакт маппинга и настоятельно разжевал, что результат достигается совместными усилиями и что мы не предлагаем ему опять начать единолично писать многостраничные MRD.
После этого я начал потихоньку тянуть из ПМа цель на грядущий релиз, по которому у нас уже был список фичей на обсуждение
1. самым сложным здесь было заставить менеджера поставить конкретную цель, которая была бы измерима и достигалась в ограниченный промежуток времени,
2. из собрания длиной в час, мы только сорок минут бодались вокруг цели, пока не выбрали что-то похожее на правду,
3. лишний раз убедился, что наличие мысли в голове у менеджера продукта не обязательно означает, что он может ее внятно сформулировать.
По окончанию первой встречи мы поделились впечатлениями и договорились
1. еще раз подумать о целях (в том числе и в более долгосрочной перспективе)
2. через неделю собраться снова уже для того чтобы попробовать нарисовать карту
За ту неделю пока менеджер продукта наш естественно НЕ думал о целях, я подготовился к следующему собранию. У меня была драфтовая цель, было понимание, что навряд ли наш менеджер согласится под ноль переработать все то, что у нас уже было ранее занесено в бэклог. Поэтому пришлось произвести некоторый реверс-инжиниринг бэклога и подготовить первый вариант карты на грядущий релиз самому:
1. роли были выявлены достаточно быстро
2. необходимые воздействия тоже
3. но далеко не все фичи удалось связать с поставленной целью. Забегая вперед скажу, что в результате большая часть «нелогичных фичей» была вырезана,
Получившийся черновик был представлен продакт менеджеру.
1. Мы обсудили то, что не вписывалось в цель и зарезали эти фичи/истории,
2. Обсудили чем еще можно сделать в рамках тех ролей, которые уже были выявлены,
3. Появилось несколько новых ролей, для которых не нужно было делать ничего на стороне продукта, кроме как предоставить необходимые материалы (маркетинг, пресейлзы),
На удивление наш продакт менеджер принял крайне активное участие в доработке карты, которая дорисовывалась у него на глазах. Именно благодаря ему на карте появилось большое количество ответвлений, не относящихся к изменениям в продукте.
К заключительной стадии внедрения импакт маппинга на наших продуктах мы начнем через релиз, когда планирование состава фичей на версию будет изначально обрисовываться с помощью импакт маппинга.
Пока что мы просто прощупали насколько успешными окажутся первые попытки.
Отзывы внутри компании
1. Продукт менеджер высказался, что его уже много раз пичкали различными около-скрамовскими методологиями, но именно этот подход его не напрягает и очень ему нравится (естественно ведь карта в зоне ответственности аналитиков и рисуется ими же).
2. Команда проявила хороший интерес к тому, что получилось. Особо им понравилось, что к их мнению прислушиваются, и что они могут предложить обоснованную с точки зрения бизнес-цели фичу.
3. Команда получила компас, с помощью которого проще проводить планирование спринтов и минимизировать споры вокруг очередности историй и деталей их реализации.
4. Наши менеджеры оказались счастливы от того, что теперь для понимания результатов релиз планинга не требуется проводить общую планерку, а достаточно посмотреть на карту. Обсуждение при этом достаточно легко переносится в офлайн.
5. Всем понравилось, что на карту проросла не только деятельность команды, но и в том числе активность которая ранее была теневой (работа маркетинга, проталкивание продукта на уровне бизнеса).
6. Аналитик использует карту на каждом созвоне по текущему состоянию дел (current state call), который проходит каждую неделю и проходится по ключевым веткам карты. Теперь в фокусе получается удерживать большее количество вопросов.
Для того чтобы получить больше информации о данном подходе, крайне рекомендуется одноименная книжка Гойко Аджича.