S2t маппинг что это
Recent Posts
Categories
About Source to Target (S2T) Document or Mapping Document
S2T document is the bible of any ETL Projects. This will be designed by the Data Modeler’s using the FSD’s (Functional Specification Documents).
Data Modeler’s are interested in
Most of the S2T’s are written in Excel spread sheet. Where you will find many columns, each column is important for the ETL Load to be designed.
Major components of an S2T,
using the Version Numbers.
SourceDatabase– Source Database name or names will be mentioned in this space
Source Column– All the Source columns from respective Source Database are mentioned in this space (these columns will undergo the transformations if required.
Extraction Criteria– As I already mentioned, we are not going to pull all the data from the source before transformation however we need to pull the data that we required for the transformation and this will be mentioned in this space. All the Joins and Unions will be done here so as a Tester we need to understand and analysis this area with more care.
Example – Now I wanted to load Customers details and their balance from Savings account. Customers Details will be fetched from Cust_Detl table and the Balance from ACCT_BALANCE table, so you need to perform join in between. This extracting filters only Customers Savings account. So I consider this is my Data extraction criteria.
Filter Criteria– After we extracted the data from the source we need to filter the data if required for few or more target tables and this will be covered in this space.
Target Database – Target Database name or names will be mentioned in this space
Target Column – All the Target columns from respective Target Database are mentioned in this space (these columns will undergo the transformations if required.
Key or Value Columns–Next to the Target Column names you could see Key / Value. Key column means the column that makes the record unique and Value means, what makes the record time variant.
Comments and Version Changes – This space will explain us what was in the S2T before and what changed now. Comments will tell us more about the transformation.
What we need to look in the S2T?
As soon as you get the S2T, please query your Staging Source tables and check the data that you have got will satisfy your transformation rule. S2T’s will be written with the SIT phase data, and the rules mentioned might change as soon as we get the UAT Phase data. So to achieve the good quality of testing we always interested in UAT data.
Most of us will confuse the below transformation logic
Example: If the source columns are NOT NULL BLANK SPACE 0 and DO NOT LOAD the record. In this case, we might look for the record in the target when it has Unknown values.
Thanks for reading – Comments are Expected 🙂
Мэппинг в бюджетировании. Что это, и зачем он нужен?
Если в процессе подготовки данных для бюджетирования задействовано более одного человека, то встает вопрос о том, как сделать так, чтобы при обработке первичных данных соблюдалась последовательность и единообразие, чтобы один набор параметров всегда был сопоставлен одной статье бюджета, а не так, как по какой-то причине захотелось сегодня пользователю. Здесь на помощь приходит мэппинг
Мэппинг – это сопоставление, определение связей и соответствия между различными объектами системы. Говоря по-русски, это картирование, когда вы составляете «карту системы», описываете маршрут процесса получения данных. Разберем сегодня, как этот инструмент пригодится в бюджетировании.
Система бюджетирования представляет собой один из контуров учета, представление и компоновка данных в котором может отличаться от их представления в оперативном и регламентированном контурах. В то же время система бюджетирования строится на том же наборе исходных данных, что и регламентированный и оперативный учет.
Информационная потребность руководства в управленческой информации может быть существенно шире, чем, например, данные, предоставляемые в рамках бухгалтерской и налоговой отчетности. Структура бюджетов, состав и группировка статей бюджетирования может отличаться от, например, отчета о финансовых результатах или оборотно-сальдовой ведомости в регламентированном учете. Статьи бюджетов – это отдельный от статей расходов, доходов, денежных средств и иных справочник.
Состав статей бюджетов может быть огромным, в то время как бухгалтерии, например, для учета доходов и расходов достаточно тех статей, что представлены в отчете о финансовых результатах, или тех статей движения денежных средств, что представлены в отчете о движении денежных средств.
Для сохранения целостности данных, контроля, получения информации в требуемом виде используется механизм сопоставления или мэппинга данных оперативного учета данным бюджетирования.
Суть мэппинга:
Для каждой статьи бюджета нужно указать, на основе каких данных оперативного учета при каких условиях формируется значение по ней, при каких условиях происходит отражение фактических данных в бюджете, либо в каком случае срабатывает заложенный в бюджете лимит.
Соотношение между справочниками может быть различным. Одна статья бюджета может складываться из нескольких статей расходов, например. Или данные одной статьи расхода в бюджете могут быть разложены на несколько статей бюджетов.
Возможны ситуации, когда всё будет один к одному: одна статья бюджета равна одной статье первичного учета, например, расхода. Это нормально. Многие так работают. Просто очень часто это неэффективно.
Важно:
Мэппинг должен обеспечивать целостность данных, т.е. учет всех возможных вариантов комбинаций, сумма которых в бюджетировании будет равна сумме данных в оперативном и регламентированном учете с поправкой на заранее известные не учитываемые в каком-то из видов учета данные.
Если ваше множество данных по какой-то статьей включает А, Б и ещё что-то, то условия должны включить их все:
— например, вы для одной статьи выбираете «А», для второй статьи выбираете «Не А»;
— либо вы можете выбрать для одной статьи «А», для второй «Б», для третьей «Не А и Не Б».
Т.е. должна быть учтена вся совокупность данных.
Если вы выберете только А и Б, то получите дыру в части данных из области «ещё что-то…».
Пока попробуйте понять написанное, а в следующей статье разберем пример, чтобы было понятнее, что это за зверь такой.
Чернобровов Алексей Аналитик
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 является одной из активностей, которые сделают и заказчиков и разработчиков более счастливыми и эффективными. Ставьте правильные цели правильно!
S2t маппинг что это
Impact mapping — графический метод обозначения границ проекта и быстрой связки глобальных бизнес-целей с конкретными методами реализации. Представляет собой ментальную карту (mind map).
Инструмент применяют на стадии стратегического планирования для координации работы всех отделов/сотрудников компании. Практика показывает, что применение такого, на первый взгляд, банального метода помогает повысить эффективность работы и на выходе получить качественный продукт.
Иногда простые решения приводят к великим результатам. Поэтому Impact mapping сегодня очень популярен. При составлении ментальной карты определяют степень влияния той или иной функции на успешность продукта. Для этого задают вопросы «зачем?», «кто?», «как?» и «почему?» и отвечают на них.
Если сравнивать Impact mapping с другими методами планирования, можно выделить несколько ключевых преимуществ:
1. Сокращение расходов и издержек. Без четкого планирования команды тратят на работу много времени и денег и не получают ощутимого результата. Цель остается недостигнутой.
Распространенный пример — команда выполняет какие-то действия, не ведущие к увеличению прибыли или достижению других бизнес-целей. Никакой пользы (информации) не возникает, если не считать понимания того, что такое бесполезная деятельность для компании.
Нет ничего хуже для бизнеса, чем выполнение ни к чему не приводящей работы. Impact mapping используют для выполнение полезных действий и достижения бизнес-целей.
2. Прозрачность работы. Impact mapping помогает отслеживать затраты и процесс достижения целей. С помощью инструмента продакты и предприниматели смотрят, приближаются ли они к поставленным целям. Если проект не дает ощутимого результата, его прекращают, пока не закончились доступные ресурсы.
3. Быстрое применение. На составление Impact mapping даже при отсутствии опыта уходит до нескольких часов.
Для составления качественной карты собираются командой, обсуждают основные вопросы и визуально фиксируют полученные результаты. О лучших инструментах для создания Impact mapping расскажем далее в статье.
Цель (Зачем?)
Центральная часть карты — цель — должна отвечать на вопрос, зачем мы это делаем. Подразумевается бизнес-цель проекта, описывать сам продукт и его функции не нужно. Посмотрев на центральный сегмент карты, человек должен за несколько секунд понять, в чем заключается бизнес-ценность запланированного продукта (проекта/задачи и т.п.).
Казалось бы, постановка цели — очевидная вещь. Но практика показывает, что ее обычно формулируют недостаточно подробно и не доносят основные идеи до разработчиков. Поэтому последние не могут соотносить свою деятельность с итоговым результатом и эффективность работы снижается.
Посмотрите на службы спасения: в дороге на вызов они получают четкое описание ситуации, после чего руководство назначает конечную цель — то, что они должны сделать в итоге. Как вы думаете, ставя перед ними абстрактные цели, какова вероятность успешного выполнения операции?
Устанавливайте цели, соответствующие критериям SMART: они конкретны, измеримы, ориентированы на совершение конкретных действий, достижимы и ограничены во времени.
Действующие лица (Кто?)
Второй уровень дает ответы сразу на несколько вопросов:
Ответы на эти вопросы — список действующих лиц, которые способны повлиять на достижение поставленной цели.
Если говорить проще, определяем целевую аудиторию и стейкхолдеров и пытаемся спрогнозировать, кто поможет, а кто помешает. Эти люди — действующие лицы проекта. Учитывайте их мнение и вкусы в работе и предугадывайте поведение. Постарайтесь определить всех действующих лиц и избегайте общих терминов.
Вот несколько примеров:
Влияния (Как?)
На этом этапе соотнесите действующих лиц с поставленной бизнес-целью. Получите ответы на следующие вопросы:
Для каждого действующего лица опишите, чем будущее поведение должно отличаться от текущего. В нашем случае, когда стоит цель по увеличению прибыли на 20%, есть смысл описать влияние для маркетолога: делать более эффективные и креативные рекламные кампании.
Распространенная ошибка продактов на этом этапе — перечисление всех возможных требований действующих лиц. Так делать не нужно, концентрируйтесь на том, что действительно поможет приблизиться к цели.
Список влияний — это не список функциональных возможностей будущего продукта. Не описывайте «программистские» идеи, фокусируйтесь на конечной бизнес-цели.
Вот несколько примеров влияний:
Поставляемый функционал (Что?)
Последний этап составления Impact mapping — поставляемый функционал. Другими словами, что необходимо сделать для достижения указанных на предыдущей стадии влияний. С помощью этого функционал соотносится с запланированной бизнес-целью.
Но почему бы просто не составить список функционала, который поможет увеличить продажи на 20% в 4 квартале? Потому что простой список не позволит объективно приоритезировать перечисленные функции. На карте все функции имеют четкие границы и создается понимание, что нужно реализовать в первую очередь.
Наравне с этим легко понять, от какого функционала следует отказаться, не тратить на его реализацию время и ресурсы.
Несколько примеров поставляемого функционала:
Создать Impact mapping можно вручную на доске стандартного размера. Ее помещают в переговорной, чтобы у каждого сотрудника был доступ. Но эффективнее использовать специальный софт, упрощающий составление карты:
1. UXPressia. Платный продукт. Помогает в составлении карты с четким обозначением бизнес-цели, действующих лиц и оказываемых ими влияний. Интерфейс на английском языке. Доступна бесплатная версия для ознакомления: в рамках нее возможно составление Impact mapping с одним действующим лицом.
Платная версия позволяет делать любое количество карт с множеством действующих лиц. Результат можно экспортировать в PNG или PDF для отправки по электронной почте или в мессенджерах.
2. SpecLog. Платный продукт. В отличие от первого сервиса, для работы этой платформы необходима установка дополнительного программного обеспечения на ПК. Это позволяет связывать Impact mapping с беклогом продукта и story maps.
Для новых пользователей доступен 30-дневный бесплатный период для ознакомления с инструментом. После окончания триал-версии клиент ежемесячно платит в соответствии с выбранным тарифным планом.
3. MindMup. Условно-бесплатный продукт. Популярный инструмент для создания диаграмм связей и схем. За счет интуитивно понятного интерфейса — хороший вариант для создания первой карты. Готовую Impact mapping можно экспортировать в формате PDF. Также доступно добавление картинок, файлов, шрифтов, стилей и многого другого.
Бесплатная версия продукта позволяет создавать карты размером до 100 Кб и хранить в облаке до 6 месяцев. При этом созданные документы хранятся в публичном доступе. Соответственно платная версия эти ограничения снимает и позволяет устанавливать запрет на просмотр документа всеми желающими.
Примеры Impact mapping для этой статьи создавались в последнем сервисе.
Среди других полезных инструментов можно выделить:
Попробуйте все описанные инструменты в работе, чтобы определить для себя наиболее удобный. Советуем пользоваться платными версиями, если планируете часто использовать Impact mapping в работе. Тогда сможете получить максимальную пользу от использования инструмента.