Битва за прошлое. Как политика меняет историю - Part II (Рубрика #History)

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

Часть вторая. Овеществленное прошлое
Эта часть начинается с рассказа про захват Капитолия сторонниками Трампа, причем фокус в рассказе идет на флаге Конфедерации, который стал символом противостояния двух Америк: демократов и республиканцов. По-факту, у этого флага много трактований и разные группы используют его как символ коллективной идентичности и как повод для ритуалов памяти. Дальше автор переходит к рассмотрению того, как в Америке борятся с памятниками героям конфедерации и конкретно генерала Эдварда Ли, а потом это переходит и на памятники отцам-основателям США, так как они тоже были сторонниками "белого превосходства" (по мнению части населения США). Это выглядиит так, что текущие политические силы пытаются переиграть прошлое и перехватить повестку - это выглядит как борьба демкоратов и либералов за историческую идентичность. Но США здесь не уникальны - дальше автор рассказывает как во времена СССР и позже правительства сносили памятники, например, памятники Сталину еще во времена СССР, а также демонтаж памятника Дзержинскому на Лубянке в Москве в 1991. Ну а потом и ленинопад, когда бывшие социалистические страны сносили монументы из прошлого. Интересно, что снести памятник просто, а вот что поставить на его место - это становится большим вопросом, так как люди у власти не всегда имеют консенсус на этот счет:)

Другой вариант - это переименование городов, например, Сталинград в свое время был переименован в Волгоград. Но даже в этом переименовании есть особенность - в дни памятных дат и в дни воинской славы этот город должен дополнительно именоваться "Город-герой Сталинград". Это связывает великое прошлое города и его текущее настоящее. Похожее происходит и с переименованием улиц в городах, когда мы за счет названий фиксируем то прошлое, которое хотим помнить. Больше того, эту фиксацию можно делать через календарь - стандартный способ через памятные даты, а более интересный через изменение календаря, как пробовали сделать с декадами во время Великой Французской Революции или с пятидневкой и пятью группами рабочих в конце 1920х в СССР.

Часть третья. Прошлое как поле конфликтов и повод для примерения
Часто прошлое выступает как поле для конфликтов и автор вспоминает Вторую мировую войну и ее результаты для Европы. Вообще история послевоенной Европы писалась странами победительницами и нацисты там были безусловным злом, а победители - добром. Но после развала СССР восточноевропейские страны решили приравнять нацизм и сталинизм и отстроится от восточного гегемона (СССР). В этой картине мира Россия была не европейским соседом, а способом выстроить собственную идентичность за счет наличия "конституирующего Другого", сравнение с которым и отталкивание от которого помогает определить себя. В итоге, в Восточной Европе страны решили назвать себя Центральной Европой и переписать историю Второй Мировой Войны, с чем не согласна уже Россия. В итоге, у нас Великая Отечестваенная Война была канонизирована и зафиксирована на государственном уровне. Интересно, что во многих европейских странах есть мемориальные законы для поддержания определенной версии истории. И если в Западной Европе эти законы про отрицание холокоста и признание ответственности государств и общества за это преступление, то в Восточной Европе в этих мемориальных законах идет речь про отрицание преступлений "нацизма и коммунизма", что трактовалось как вынос ответственности за пределы стран региона. Это помогало закрыть глаза на ответственность собственных националистических движений. Свои особенности есть и у российского мемориального закона.

Ну и напоследок автор рассказывает про музеи и их экспонаты, на которые сейчас претендуют страны, откуда происходили артефакты. Это поднимает вопрос о том, а кому принадлежит история и зримыые артефакты ушедших эпох.

Окончание книги я рассмотрю в следующем посте.

#Management #Leadership #History #Strategy

Interview with an Agile Coach - Sprint1 (Рубрика #Management)

Забавное шуточное интервью с agile coach:) Смысл примерно тот же, что был в видео "The Agile Paradoxon", правда там это показывается в динамике - с чего начиналось и к чему пришло. В этом же видео мы видим типичного коуча с цитатами вида:

- We don't even define requirements until after production
- Identify problems. And wait for them to go away
- Leave job when debt causes problems, evangelize scrum at next job
- I lost my job because I'm a horrible developer, now I'm an agile coach
- Always change, never finish
- Folks who don't have anything valuable to add deserve meetings
- Everyone spends a bunch of time in meetings to talk about how nothing happened and how work should be done but nobody actually does anything
- The one and only real scrum is mine, we called it scrum . It’s really Waterfall with meetings every two weeks” that one hit differently

В общем, рекомендую посмотреть видео в оригинале - оно снято талантливо и в нем за четыре с половиной минуты обыграно столько шаблонных фраз адептов agile, что диву даешься:)

#Management #Leadership #Processes

Бизнес-линии, сервис-линии и платформы @ T-Bank - Part II - (Рубрика #Management)

Продолжу первый пост про структуру компании рассказом того, как у нас устроено привлечение, с которого я и начинал тогда еще в Тинькофф почти 8 лет назад.
Привлечение - это каноническая сервис-линия, у этой сервис-линии заказчиками являются бизнес-линии. Задача от них упрощенно звучит примерно так
- С учетом наших бизнес-планов нам надо привлечь X% новых клиентов
- У нас есть на это бюджет Y млн рублей
- У нас есть модельки для оценки вклада привлеченных пользователей в PnL продукта (последние годы мы переходим к LTV моделям)
Кроме таких целей по продуктам есть еще общие рекламные активности: телевизор, спонсорские контракты (как с КХЛ). Эти траты не всегда легко аллоцировать на конкретный продукт, но их надо уметь учитывать.
Дальше у нас есть каналы для привлечения, которых до 2022 года было в разы больше, но и сейчас остались инструменты от Yandex, VK и так далее, работу с которыми надо автоматизировать, чтобы маркетологам, таргетологам, performance менеджмерам и остальным ребятам из сервис линии было удобно работать, а их руководителям сыпались актуальные отчеты
- У нас есть внутренние инструменты аля рекламный кабинет, который интегрирован с внешними системами. Он помогает из единого места управлять рекламой, туда встроены контроли и подсказки, а также подтягивается аналитика из внешних рекламных инструментов.
- Дальше эта аналитика объединяется с внутренней информацией из data platform для того, чтобы построить сквозную аналитику с учетом оффлайн событий: встреч с клиентами, выдачи продуктов, утилизаций продуктов и так далее. В итоге, по каждому продукту и каналу можно получить отчет о том, как он себя чувствует и принять решение о запуске/остановке привлечения на определенный продукт или через определенный канал
- Внутри у нас есть сервис аудиторий, который позволяет объединять данные по пользователям (например, какие продукты есть у клиентов) и показанной рекламой. В итоге, мы можем делать таргетированние на look a like пользователей в рекламе или наоборот исключать часть сегментов из таргетинга, чтобы не показывать рекламу продуктов, что есть у клиентов
- Другой важный момент - это модели атрибуции. Суть в том, что для продажи продукта часто нужно несколько точек касаний через разные каналы иначе продажа не состоится. Но в простых инструментах обычно продажа засчитывается тому касанию, что было последним - это может приводить к локальным оптимизациям, когда мы выкидываем другие касания, считая их не эффективными и это приводит к падению показателей. Интереснее построить более сложную модель атрибуции, которая учитывает эти особенности. Например, многие пользователи читают ТЖ (Тинькофф Журнал), но напрямую продукты оттуда оформляет не так много людей, но это не значит, что информация из ТЖ не помогла людям в будущем стать нашими клиентами.

В общем, эта схема работает достаточно хорошо и большую часть указанных выше инструментов делали мои ребята последние 8 лет:) У этой системы несколько сотен пользователей со стороны заказчика, где маркетинговые команды внутри сервис-линии собраны по продуктовому признаку: маркетинг депозитных и расчетных продуктов, инвестиций, платежей и переводов, нефинансовых сервисов и так далее. А со стороны IT это несколько десятков человек, которые постепенно построили эту систему.

Перечислю некоторых ключевых людей со стороны бизнеса и IT:
- Когда-то эту махину мы начинали строить с Кириллом Бобровым, который тогда был VP of Acquisition
- Потом на смену ему пришел Саша Лебединский, который является директором по развитию бизнеса и VP of Growth
- За онлайн-маркетинг у Саши отвечает Игорь Посталенко, который и был основным заказчиком этих систем
- На стороне IT за маркетинг и рекламу отвечает Кирилл Крайнев, технический директор этого управления
- Рекламные кабиинеты делал Саша Гайдуков, руководитель отдела, которого еще я лет 6 назад брал на работу
Ну и внутри есть еще сотни ребят, без которых мы бы не сделали все это. Спасибо ребятам за работу.

#Management #Leadership #Software #Processes

Шахматные звезды 4.0

Вчера получилось побывать на закрытии турнира "Шахматные звезды 4.0" и награждении победителей. Связано это было с тем, что генеральным партнером турнира является Т-Банк:) Параллельно взрослому турниру с крутыми участниками, проходили и детские турниры (до 9, до 11, до 13 и до 17 лет). Участникам детских турниров удалось поиграть в одном зале с участниками основного турнира. А основной турнир имел крутой состав: Карякин, Артемьев, Томашеский, Табатабаи, Садхвани, Хоу Ифань, Горячкина, Гунина, Лагно. В итоге, лучшей среди девушек стала Хоу Ифань, а среди мужчин - Владислав Артемьев. У турнира был крутой комментатор - Сергей Шипов, гроссмейстер и автор популярного youtube канала Crestbook Chess, который я периодически посматриваю во время крупных шахматных турниров.

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

P.S.
Для меня это флешбеки из прошлого - я достаточно много турниров играл в детстве, когда еще с первого класса и до седьмого-восьмого ходил в ДЮСШ на занятия по шахматам:) Правда, я оказался слабоват в шахматах, поэтому переключился на математику и физику и дальше подналег на их изучение, чтобы поступить в итоге на Физтех.

P.P.S.
Сейчас дома со своими детишками пробую играть в шахматы, когда есть время. Иногда получается, но я вижу как им сложновато держать фокус, особенно когда рядом (в телефоне) есть игры попроще, а на телевизоре есть развлечения позрелищнее (мультики). Но мне кажется, что учить шахматам детей стоит - это поможет научиться фокусироваться, оценивать позицию, планировать свои действия и так далее

#Chess #SelfDevelopment

Уже второй раз поучаствовал в благотворительном аукционе Meet For Charity, где благотворитель мог на аукционе приобрести возможность пообщаться со мной. Как и в прошлый раз все пожертвованные даньги отправились в фонд "Нить добра", который был создан в целях осуществления благотворительной деятельности, направленной на реабилитацию детей и подростков с онкологическими и другими тяжёлыми заболеваниями. В принципе, у организаторов в канале есть и другие интересные лоты, так что если есть желание пообзащаться с кем-то интересным тет-а-тет, а также помочь одному из фондов, то you are welcome.

P.S.
На этой неделе как раз встречался с благотворителем, который пожертвовал деньги в фонд, и мы достаточно интересно пообщались по широкому кругу вопросов.

#Charity #Software #Management #Leadership

«Т-Банк» — больше, чем просто финансовые услуги: на платформе выстроена полноценная экосистема сервисов. Как она устроена с точки зрения технологий, расскажет Александр Поломодов — технический директор «Т-Банк». 

Темы для обсуждения:
• почему сейчас бизнес и IT должны быть на одной волне;
• как выглядят эффективные процессы разработки и почему они зависят от размера и жизненного цикла компании и продукта;
• как выстроить архитектурные процессы в компании;
• как нанимать сильных инженеров (разработчиков, QA-инженеров и т.д.);
• как появление искусственного интеллекта изменило расклад на рынке разработки.

Ссылка на лот: https://clck.ru/3BBnNN

#MeetForCharityЛоты

Leetcode - прогресс за полгода (Рубрика #SelfDevelopment)

Вот уже полгода я на leetcode, специально под этот полуюбилей я сделал так, чтобы у меня было 404 решенных задачи:) Полмесяца все шло хорошо, но потом случился выезд в Калиниград и ритуал был нарушен и только к концу месяца я оклемался. К сожалению, я так и не начал курс "System Design for Interviews and Beyond", но почти закончил курс "Data Structures and Algorithms", а дополнительно начал "Top Interview Questions (Easy Collection)" и "Google Interview". В общем, с таким набором разных курсов как-то интереснее играть с задачками, которые теперь я решаю примерно полчасика-часик в день:)

P.S.
Предыдущие посты на эту тему доступны здесь: 1, 2, 3, 4, 5 и 6

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Моделирование потоков событий в эволюционирующем окружении - Николай Голов - SmartData 2023 (Рубрика #Architecture)

Интересный доклад Николая Голова на тему моделирования кликстрима. Коля - крутой эксперт, который сначал работал с data vault на базе teradata, anchor modeling на базе vertica (в Avito) и anchor modeling+ на базе snowflake (в Manychat). Интересно, что объем кликстрима часто сильно превышает объем других данных, поэтому важно правильно научиться работать с ним:) Сам кликстрим характеризуется тем, что у нас
- Сотни (тысячи) типов событий
- Схема каждого типа события меняется
- Аналитики хотят одну таблицу .. быструю и простую

Его можно сохранять в виде частично структурированных данных (аля json) в нормальную базу (условный postgres) и это работает до определенных масштабов. Условно если нам нужно анализировать до миллиона событий, то можно работать напрямую с этими json, но если данных для анализа больше, то начинают играть роль проблемы с json
- Производительность: колоночные базы данных не ускоряют работы с json в sql
- Схема: какие атрибуты использовать в наших json
- Безопасность: как хранить данные в json безопасно (условно перс данные)
В итоге, хранить clickstream можно в виде json в data lake, но недолго - иначе получим data swamp. Но что же с этим делать?

Дальше Коля говорит про anchor modeling, фанатом которого он и является. Anchor modeling - это развитие data vault и 6 нормальная форма. У нас есть таблица сущности achor, таблица для атрибута attribute, а также таблица для связи - tie. Это очень сложный подход, но в Авито удалось разложить в свое время кликстрим разложить в сотни нормализованных страниц. Но теперь Коля не рекомендует так делать из-за проблем
- Сотни гигантских страниц
- Для загрузки нам требуется joins 10ˆ9 строк
- Для анализа нам требуется joins 10ˆ9 строк
- Типа джойним одно и то же два раза.

А дальше Коля предлагает свой подход, к которому он пришел уже после Авито. Предложение в том, чтобы остановиться где-то посередине между 6NF и jsons.
Коля начинает с того, что вспоминает про то, как работает star schema:
- У нас есть таблица фактов в сотни таблиц
- Большая часть таблицы разреженная
- Для анализа нужны joins на таблицы dimensions
- Каждое событие с парой атрибутов добавляет столбцы для все таблицы
В общем, этот подход не работает для кликстрима - мы это не запихнем в условный ClickHouse и словарики слишком большие для joins.

Но вместо star schema можно использовать activity schema. Идея в том, чтобы сделать аналитику на одной таблице, где мы все события пытаемся представить как список активностей, происходящих с определенной сущностью. В итоге, табличка видит примерно так
- stream_id
- user_id
- event_id
- action_datetime

И у этого решения есть плюсы
- Быстрая и дешевая загрузка
- Колоночность. Компрессия. ClickHouse
- Удобная базовая аналитика: DAU/WAU/MAU, Funnels, Conversions
Дальше Коля показывает как можно этот анализ делать прямо на примерах SQL запросах. А потом что же делать, если у событий есть дополнительные данные?
- Если атрибуты событий случаются часто, то их можно сунуть в основную схему
- Но если атрибуты случаются редко, то их можно унести в небольшие нормализированные таблицы с деталями (микс с data vault) - это таблицы-саттелиты
Интересно, что это с первого взгляда похоже на star schema, но отличается кардинально:
- В star schema ссылки на dimensions идут из таблицы фактов
- В этой схеме у нас ссылки из таблиц-саттелитов на activity таблицу, которая ничего не знает про дополнительные атрибуты
Это решает проблему с разряженными таблицами + позволяет реализовать фичи безопасности, так как sensitive атрибуты можно хранить в таблицах-саттелитах

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

#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture

Головоломка БондиЛогика (Рубрика #Kids)

Пока папа решает easy задачки на leetcode младший сын собирает головоломки из машинок на уровне новичок:) Там сначала заполняешь парковку, а потом пытаешься вывести скорую помощь из лабиринта:)

#ForKids #SelfDevelopment

Code of leadership #16 - The Five Dysfunctions of a Team (Рубрика #Management)

Шестнадцатый выпуск подкаста про лидерство посвящен книге "5 пороков команды", которую написал Патрик Ленсиони в жанре бизнес-романа еще в 2002 году. Эта книга направлена на лидеров, которые хотят сделать свою команду эффективнее. Но этому мешают ряд факторов, которых автор насчитал целых пять штук, которые выстраиваются в пирамиду (подробнее в прошлом посте про эту книгу)

Я обсуждаю эту книгу с Андреем Соколовым, экспертом в области эффективных коммуникаций для бизнес-сообщества с 20-летним стажем. У Андрея есть курс по сторителлингу, часть из которого я раньше успел пройти. Для зрителей и слушателей нашего стрима есть скидка в 20% для записи в июльскую или августовскую группу 2024 года. Достаточно использовать кодовое слово "Книжный куб".

#Management #Leadership #PublicSpeaking #Storytelling #Culture

Обеспечение качественных ETL на Vertica - Александр Крашенинников - SmartData 2023 - Part 1 (Рубрика #Architecture)

Интересный доклад от Саши Крашенниникова из Т-Банк про то, как сделать обеспечить бизнес качественными данными причем не только на Vertica:) В докладе замиксованы как процессные, так и технологические моменты, а сам доклад основан на опыте Саши, который он получил еще вне Т-Банка, но сейчас использует на благо нашей компании:) Ну и бонусом к техническим компетенциям Саши идет отличный стиль подачи материала - с юмором и крайне доступно, рекомендую к просмотру в оригинале. Но кому лень смотреть суть примерно такая.

Собственно, все начинается с того, что компания успешна, есть запрос на аналитику по данным. Для решения задачи решают гонять все поверх могучей MPP (massive parallel processing) базы данных. В качестве MPP базы выбирают Vertica, которая является классикой MPP баз (multi-node, column store), ACID совместимая, без SPOF (single point of failure), быстрая и щедрая на системную информацию (что можно использовать для улучшения процессов). Пока все звучит хорошо, но надо добавить, что она проприетарная и сильно платная:) Процессы выглядят так, что инженеры данных привозят "сырье", пользователи сами пишут ETL и выводят его в прод. Все работает ... до какого-то момента.

Но дальше начались проблемы
- "База тормозит" - запуск тяжелых запросов, которые аффектят остальные запросы. Решение через квотирование является стандартным, но квотирование не решает проблем чтения с диска, передачи по сети, перекос нагрузки, "нецелевое" использование базы
- Поверх стандартного квотирования добавляется query watchdog для мониторинга и оптимизации запросов. Часть запросов отстреливаются этим сервисом и отправляется оповещение автору запроса
- Отдельно Саша раскрывает как может выглядеть "нецелевое" использование базы - например, это может быть OLTP-style нагрузкой или однопоточной интеграцией данных. Для выявления запросов в стиле OLTP можно накрутить поиск дублирующихся запросов. А однопоточная интеграция приводит к перегреву узла, через который проходит запрос (например, узла-координатора в Greenplum). Это можно детектировать по системной информации

Дальше Саша рассказывает про то, как они выстраивали процесс обучения пользователей использованию MPP. Ключевыми моментами обучения были
- Структурированная подача информации в курсе
- Тесты для самопроверки
- Аттестация по окончанию курса

В сам курс ребята включили
- Вводную часть про MPP
- Ключевые отличия от single-node баз данных
- Для чего используется в организации
- Как подключиться
- Базовый query language
- Хранение: шардирование, data-locality, сортировка
- Оптимизации: типы joins, group by
- Оптимизации: неточный distinct, argmax

Дальше Саша показывает примеры задачек в рамках курса + рассказывает как сделать прохождение курса обязательным для инженеров, у которых есть роли с доступом к MPP базе. Классно еще сделать возможность запускать локально базу для экспериментов, а также собирать фидбек по самому курсу.

Но остаются запросы
- А что является нормальным?
- Справедливо ли распределение ресурсов?
- Может уже пора заливать проблему железом?

Для определения границ нормальности надо собирать телеметрию по запросам и кластеризовать их, а дальше анализировать аномалии. Эксперты анализируют OLAP куб и выявляют проблемы, коммуницируют с владельцами кода для исправления. Если проблема не решена, блокируют учетную запись и форсируют авторов кода на исправление.

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

Конкретные примеры работы с дефектами в посте-продолжении.

#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture

Обеспечение качественных ETL на Vertica - Александр Крашенинников - SmartData 2023 - Part 2 (Рубрика #Architecture)

В первый пост по этому докладу не поместились все практические советы Саши, поэтому продолжим

Для построения аналитики стоит построить OLAP куб с компонентами
- Измерения: время, учетная запись, ресурсная группа, узел кластера
- Показатели: sum/skew/avg/q50/q75/q90/q99 по метрикам запросов
- Время: CPU, общее время
- RAM
- Объемы данных: чтение/запись по диску, чтение/запись по сети
- Число запросов
- COST

Ну а дальше работа с дефектами - когда проблемы имеют схожие паттерны, которые можно разделить на
- Статические - данные лежат спокойно, но больно станет, когда придется с ними работать (таблицы, колонки)
- Динамические - это уже сейчас работает не оптимально (запросы и последовательности запросов)

Статические дефекты данных
- Хранение и обработка текстовой информации в VARCHAR - если мы просим VARCHAR(2048), а пишем туда 2 символа, то мы имеем доп накладные расходы, а при использовании UDF (user defined functions) мы действительно будем занимать все 2kb даже если напишем 2 символа
- numeric с управлением точности числа - больше точность, больше места на диске, а при несовпадении типов у нас тратится CPU и RAM на их приведение. Обычно хватает numeric(18, 4) в 90% случаев (что занимает места как int64)
- Сортировка - важно сортировать по меньшему полю + слишком много полей для сортировки может быть ошибкой
- Распределение данных (шардинг) - шардинг по меньшему полю + правильное использование несегментированных таблиц. Использование сегментации по float может быть ошибкой (из-за плавающей точности и распределения близких значений по разным нодам)
- Партиционирование - по правильному полю + большое партицируем на не слишком много партиций, если маленькое, то не партицинируем
- Перекос данных - перекошенные данные тормозят все запросы, надо с перекосами бороться. Саша показывает как это делать с NULL полями
- И еще куча проблем

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

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

Проблемы с производительностью
- Объем временных данных на одном узле может вызвать проблемы с производительностью.
- Неявные коммиты и множественные sql инструкции могут вызвать ошибки и false positive.
- Важно обучать пользователей правилам игры и границам дозволенного.

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

#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture