Найдено 110 team leader

One-to-one встречи

One-to-one встречи или как их по другому называют – совещание теа-а-тет. Это некий инструмент, благодаря которому можно развивать команду, можно улучшать отношения в коллективе, а можно получать фидбэк по Вашей работе, как руководителя и по организации работы в самой компании. Представим, что Вы работаете в компании уже 5-10 лет, у Вас замыленный взгляд, Вы не знаете практик и подходов в других компаниях, поэтому Вы считаете, что Ваше решение единственное верное. Но… Нет. Увы, это не всегда так. И one-to-one встречи в этом помогут Вам. Но начнем с самых основ. Установим правила. Назначьте день проведения встречи. Если у Вас небольшая команда, то такие встречи можно и нужно проводить еженедельно. Если команда побольше – то раз в пару недель. Ни в коем случае не отменяйте эти встречи. Возможно, что у сотрудника припасено много инициатив и предложений, он ждет этой встречи, чтобы поделиться ими с Вами, а Вы берете и отменяете. У сотрудника сразу возникает в голове мысль «я не нужен, со мной не считаются, руководитель не может выделить для меня и 30 минут». Установите жесткий тайминг. Разошлите приглашение в календаре сотруднику и запланируйте тайминг, за который нельзя выходить. Иначе из деловой встречи может получиться болтовня о жизни. Разговаривать о жизни, конечно, тоже хорошо, но не в моменты, когда у сотрудника много работы, а у Вас другие совещания. Когда мы определились с правилами. Переходим к реализации. С чего начать встречу? Вы не поверите, все просто, с банальных вопросов «Что нового?», «Как успехи?» или «Как дела?». Выбирайте любой вопрос, который Вам больше нравится и задавайте его. А вот теперь прислушивайтесь к ответу. Позитивный ответ. Сотрудника все устраивает, никаких проблем не видит, процесс налажен отлично. Но время есть, чем же занять его? А поговорите о людях, поговорите о развитии сотрудника, спросите про улучшения. Не надо распространять только сплетни или слухи. Разрешите задать сотруднику вопросы, которые его мучали или которыми он задавался. Возможно, в коридорах компании ходит неприятный слух, не стесняйтесь, поговорите об этом, развенчайте этот миф или если правда, преподнесите в более мягкой форме. То есть при позитивном ответе сотрудника – Вы должны и закончить встречу позитивно. Негативный ответ. Это может быть какая-то проблема в работе, например, не нравится сотрудник из отдела А. Или может быть сотрудник не успевает в срок. Здесь главное правило – ни в коем случае не вмешивайтесь и не перебивайте. Сотрудник хочет высказаться, выплеснуть эмоции. Позвольте ему это сделать. И вот после того, как все это закончилось, спокойно, а главное без эмоций начните разговор. Ни в коем случае не надо задавать наводящих вопросов, это подливает масла в огонь, сотрудник чувствует поддержку и еще сильнее негативит. Пообещайте, что Вы разберетесь в ситуации. И Вы правда разберетесь, но позже, после того, как соберете достаточно информации. Для чего теа-а-тет совещания? Цели: слушать людей предотвращать конфликты улучшать процессы отвечать на сложные вопросы, которые сотрудники боятся задать при всех. Ни в коем случае не ругайте, а главное не распространяйте информацию, полученную из тет-а-тет совещания. И поверьте, спустя несколько совещаний сотрудники будут сами приносить Вам нужную информацию об успехах, о проблемах, о путях их решений. А Вы должны будете только фильтровать информацию и применять успешные кейсы. Проводит ли Ваш руководитель такие встречи? Или может Вы, как руководитель, проводите и видите в них практическую пользу?

Уровни backend разработчиков

Время движется вперед и то, каких знаний раньше хватало на долгие годы, сейчас не хватит и на месяц. Поэтому, я хочу попробовать сделать разбивку на уровни разработчиков, кто к какому относится и почему я делаю такие выводы. Итак, во всем мире принято 3 грейда. О них мы и поговорим. Junior. Кто такой джун разработчик? Умение писать маленькие приложения, например, запись данных в файл. Базовые знания SQL синтаксиса Работа с данными по сети, отправка GET/POST В принципе то и все, ничего сложного, но в наше время уже должен быть какой-то практический опыт на домашних проектах. Поэтому, прочитайте книгу и сделайте пару домашних проектов, например, Telegram Bot, которого создавать очень и очень легко. Middle. Кто относится же к мидлу? Опыт практической разработки нескольких лет(в среднем 2 года) Умение решать практически любые задачи с ТЗ Оптимизация кода, рефакторинг, ревью Знания SQL более глубокие Слышал и использовал noSQL Брокеры сообщения не просто слова Знает принципы работы Docker, для чего может пригодится К стандартной работе по сети добавляются несколько интересные протоколы, такие как gRPC, GraphQL, хотя бы слышал про них и сможет быстро погрузиться Senior. Это высшая ступень эволюции у разработчиков. Еще есть TechLead, Архитектор. Но это очень близко, поэтому и требования более серьезные. За плечами длинный путь практической разработки(в среднем 5 лет) Умение решать задачи без ТЗ. То есть додумывать, говорить и обсуждать, предлагать как лучше, иногда даже поправлять аналитика, так как систему он знает почти наизусть. Сможет рассказать правила написания кода, указать слабые места кода Кроме базовых SQL запросов сможет создавать вьюхи, хранимые процедуры, вешать индексы noSQL становится родным словом Брокеры сообщений, такие как RabbitMQ и Kafka понятны, знает отличия Менторство, наставничество Идеи по созданию архитектуры(первый шаг к архитекторству) Подводя итог, можно сказать, что Джун имеет самые базовые знания по написанию приложения Мидл начинает изучать смежные технологии и использует их Сеньор технологии уже предлагает, ТЗ ему почти не нужно, знания технологий глубокие, может предлагать архитектурную схему Надеюсь, что данная система грейдов Вам поможет посмотреть на своих специалистов другими глазами, а если вы разработчик - поймете куда расти и как двигаться.

На что чаще всего жалуются гости в кафе?

Если почитать отзывы и просто послушать гостей, становится понятно, что у многих претензии примерно одни и те же. Вот 5 самых частых причин недовольства, которые важно не пропускать мимо! Долгое ожидание заказа Гостям важно не только вкусно поесть, но и не тратить на это лишнее время. Даже 10 лишних минут могут повлиять на общее впечатление. Несоответствие блюда ожиданиям Иногда описание в меню или фото создают одно представление, а на столе оказывается что-то другое — и это расстраивает. Невежливый персонал Даже вкусная еда не спасёт, если официант грубый или холодный. Гостеприимство — половина успеха. Неопрятное помещение Людям важно чувствовать себя комфортно. Детали вроде чистых столов, аккуратных стульев и свежего воздуха — всё это влияет на ощущение уюта. Сложности с парковкой Это особенно актуально в небольших городах и на оживлённых улицах. Если гость не может удобно припарковаться, есть шанс, что он просто проедет мимо. И тут важно понять, что жалобы — это не просто негатив, это сигналы, это обратная связь, за которую надо быть благодарными. Потому что она помогает увидеть свои слабые места, исправить ошибки и стать лучше. Если вы хотите, чтобы гость вернулся, не игнорируйте то, что он говорит. Улучшайте процессы, проверяйте работу команды и идите дальше. Потому что индустрия питания — это всегда про развитие. А если вам нужна помощь по открытию кафе, обращайтесь в наше консалтинговое агентство «Не франшиза». Поможем на всех этапах — от создания концепции до первых гостей!

Словарь продуктового редактора

Общаться с продуктовой командой на одном языке 👌 Когда я говорю «продукт», я обычно имею в виду какие-то диджитал-артефакты: сервисы, приложения, платформы — вот это вот всё. Редактору здесь приходится очень много общаться с маркетологом, продуктовым менеджером, разработчиками, дизайнерам. А они разговаривают на своём языке. Чтобы ты уверенно чувствовал себя в команде, вот тебе небольшой словарик. Здесь то, что я сама чаще всего встречаю в работе. 🤯 Спринт — интервал времени, за который планируется выполнить определённый объём задач. Обычно — неделя или две. 🤯 Таска — задача. 🤯 Борда — Доска для планирования задач. Я работала в Джире, ПланФиксе и Трелло. 🤯 Оунер — владелец, лицо, которое отвечает реализацию конечного видения некой сущности. Это может быть владелец продукта (Product Owner) или процесса (Process Owner). 🤯 Прод — продашкн — промышленный или боевой сервер — то, чем пользуются реальные люди. 🤯 Релиз — процесс выпуска чего-либо в промышленную среду. 🤯 СТА — Call to Action — призыв к действию в интерфейсе или маркетинговых материалах: купи, подпишись, закажи. 🤯 RTB – Reason To Believe – факт-причина доверять продукту. Это может быть статистика, результаты исследований 🤯 Баг — ошибка в программе. 🤯 Лаг — задержка в работе сервиса — когда он тупит. В последнне время у меня такое часто с Фигмой. 🤯 Юзер — пользователь. 🤯 Консёрн — озабоченность, опасения, сомнения. «Есть консёрн по поводу этой формулировки». 🤯 Синк — синхронизация. Обычно в моей работе так называют созвон, где нужно что-то обсудить и прийти к какому-то единому мнению. Или, например, синхронизироваться по статусам задач. 🤯 Фиксить — исправлять. 🤯 Дейофф — отгул. 🤯 Груминг — дословно: причёсывание. Так обычно говорят, когда в середине спринта команда синкается, сделанные задачки закрываются, проставляются актуальные статусы и дедлайны. 🤯 Ретро — ретроспектива. Это встреча, которая проходит по итогам какого-то периода — спринта, месяца, квартала. Там обсуждают, что получилось хорошо, какие были трудности, что сделать, чтобы эти трудности больше не возникали или сильно не влияли на процессы. Напиши в комментах, с какими терминами чаще всего встречаешься в работе.

Мама, теперь я тимлид

Всем привет! Меня зовут Дмитрий Адмакин и я TeamLead одной из команд в компании АО «БАРС Груп». И сегодня хочу поговорить с Вами о знакомой для многих ситуациях, когда вы стали тимлидами. Вчера Вы были первоклассным разработчиком, паттерны, принципы ООП, backend, frontend – все вам было по плечу. Но вдруг приходит руководитель и говорит «Вася, ты себя хорошо показал, ты делаешь нереальные вещи, теперь ты тимлид». У Вас круглые глаза, Вы не понимаете, радоваться или плакать, куда бежать, что читать, как жить дальше. И вот эту ситуацию мы и разберем. Спокойствие. Не переживайте, Ваш руководитель понимает, что Вы новоиспеченный ТимЛид. Прочитайте пару книг по управлению командной. Обязательно Дж. Ханк Рейнвотер «Как пасти котов», А. Купер «Психбольница в руках пациентов», М. Лопп «Как управлять интеллектуалами. Я, нерды и гики». Посетите профессиональную конференцию, например TeamLeadConf. Забывайте о разработке. Если Ваша команда более 7 человек, время на программирование не будет от слова совсем. Ваша обязанность теперь поддерживать команду, мотивировать, вдохновлять, не дать им разбежаться и решать конфликты. Начинайте знакомство с командой. Проведите теа-а-тет разговор с каждым, поговорите по душам, узнайте, чем человек доволен, чем не доволен, куда хочет расти, как развиваться. Подготовьте инструменты. Google Calendar, Яндекс календарь или любой другой удобный для Вас календарь. Обязательно подключайте в календарь команды, рассылайте приглашения, пусть команда знает и Ваш график, и Вы планируйте время команды. Заведите записную книжку (лучше электронную с синхронизацией), записывайте все, что вы должны сделать, указывайте даты. То есть – календарь + записная книжка – это тот минимум, который у Вас должен появиться. Мыслите немного иначе. Теперь Вы больше менеджер, Вы должны не только говорить сроки, но и понимать, что заказчик не всегда захочет ждать месяцами, поэтому иногда нужно вносить коррективы, обсуждать их. Не бойтесь. Теперь Вы должны говорить сроки, отвечать за команду. Не бойтесь делать ошибок, но помните правило, если оценку Вы получили от разработчика, то добавьте минимум 20% времени, разработчики слишком оптимистичны. Налаживайте контакты. Вы должны дружить со всеми отделами, взаимодействовать, знать их руководителей. В принципе, это то, что на первый момент будет требоваться от Вас. Главное. Не растеряйте команду, растите их и поймите, что Вы теперь не гуру разработчик, Вы руководитель команды! В некоторых областях Ваши знания будут меньше, чем знание определенных членов команды и это норма, невозможно знать все, но Вы тот, кто сможет все это агрегировать и получать результат или ответ на свой вопрос.

Кейс. Как я настроил воронку в amoCRM и вернул 350 клиентов из брошенных корзин

Алексей, у нас уже есть amo, и мы даже настроили интеграцию с сайтом, но почему-то программа не работает. Некому ей заниматься, а вопросы копятся. Посмотри, пожалуйста. 👁️‍🗨️ И я посмотрел. И увидел, практически «голую» систему, в которую сыпятся заявки и вопросы, но в ответ – тишина и тайна. 🔥 Кейс компании, занимающейся оптовой и розничной торговлей. Более 15 000 SKU Колоссальное количество клиентов. Я бы спокойно назвал эту компанию – лидером отрасли. В связи с подписанным NDA не могу сказать больше. 🔥 Первое на что я обратил внимание – если есть заказы (и много), значит есть и те, кто до заказа не добрался по разным причинам. В CMS было видно, что в оптовой системе зависло более 500 брошенных корзин. 📍 Я сделал базовую воронку в amo и настроил интеграцию так, чтобы выгрузилось все, что зависло. И вот, в «неразобранном» у меня появилось 500 сделок. С совершенно разным сроком давности. От 2-3 дней, до 12-14 месяцев. 🔥 Следующим шагом мне нужно было понять причину зависания. Я глубже изучил товар и ассортимент, пообщался с менеджерами и продавцами и даже провел несколько недель в магазине, как продавец, чтобы лучше понять бизнес. Увеличило это срок решения вопроса? Конечно. Но зато и результат был не просто: «у вас проблема, вот вам инструкция по решению и до свидания». В итоге, я неплохо знал ассортимент и правила работы. Кроме того, мне выделили прямую линию с менеджерами по продажам, чтобы я мог оперативно консультироваться, если чего-то не знал. 🚀 Мое решение было: самостоятельно прозвонить это невероятное количество корзин. Дальше объясню зачем самостоятельно и что это дало. 🕜 Весь прозвон занял один месяц. Ежедневно, методично разгребал заявку за заявкой, чтобы понять клиентов. Когда работа была завершена, у меня на руках было исследование и больше 5 основных причин оставленных корзин. Все результаты исследования не могу рассказывать в связи с NDA, но кое-что очевидно. Часть клиентов не нашли нужную информацию на сайте. Еще часть пыталась написать в чат и задать вопрос по условиям сотрудничества и не получили ответ. Часть не разобрались с системой скидок. Кто-то просто не понял, как работать с личным кабинетом. 🔥 И это было идеальной почвой для того, чтобы автоматизировать бизнес-процесс «брошенные корзины» в воронке. Основное, что я сделал – настроил срок нахождения корзины в неоформленном виде до передачи в CRM. Срок сделки в опте достаточно большой. И почти все, кто висел там меньше 1 месяца отвечали – мы еще собираем корзину. Так, что нервировать таких клиентов не надо. Для коммуникации с клиентом нужно было, чтобы система умела отправлять сообщения клиентам. 📍Для этого мы интегрировали виджет Wazzup. Он позволял общаться через WhatsApp и Telegram. Также, подключили интеграцию с почтой. 🔥 Далее настроил триггер, на появление сделки в неразобранном. Как только создавалась сделка – CRM отправляла в один из доступных мессенджеров сообщение: Добрый день (имя)! Мы заметили, что вы все еще собираете корзину на сайте (название сайта). Ассортимент стремительно меняется, и мы переживаем, что часть позиций могут разобрать быстрее, чем вы завершите наполнение. Подскажите, можем ли мы вам помочь? Да, такое сообщение, варианты ответа и все сценарии диалога (а их было больше 40) были написаны мной благодаря тому, что я услышал 500 мнений и причин. 🔥Поэтому, мой SalesBot был просто гигантом мысли, предугадывающим 80% ответов. Он начал отвечать на все вопросы, которые были у тех самых 500 брошенных корзин. 🚀 Самое крутое было настраивать бота на контекст сообщения пользователя. То есть, при наличии определенных слов и синонимов бот сам готовил ответ. В общем, получилась не бездушная машина, а вменяемый помощник. ☝️Кроме того, после общения с ботом, если вопрос не решался сам (хотя таких практически не было) – улетало оповещение менеджеру по продажам, что нужно взять в работу клиента и срочно позвонить. Бот был успешно запущен в эксплуатацию. Средняя оценка пользователей составляла 9.7 из 10. А из тех корзин, которые висели изначально отвалилось всего 150. Ведь со всеми проговорили вопросы голосом, да еще и чат-бот помог им завершить наполнение. 📍Так получилось, что я не только создал и автоматизировал воронку, но и сформировал бизнес-процесс, которого раньше в компании не было, но который позволил остановить потерю выручки. 🔥 Работа была завершена, а заказчик доволен, что CRM «ожила» и начала общаться с клиентами и менеджерами, заставляя одних покупать, а других работать. Хотите также? Я занимаюсь настройкой и внедрением amoCRM. Пишите в личные сообщения. Вместе прорвёмся. 🚀 Помогаю сильным руководителям превращать хаос бизнес-процессов в работающие системы без выжигания персонала. #кейс #crm #настройка #бизнес

Маркетинг vs. продажи: кто виноват в пустом pipeline?

Маркетинг говорит\: «Лиды есть — продажники не работают». Продажи парируют\: «Лиды — мусор». Разбираем\, где на самом деле пробел и как его закрыть. 3 главные причины пустого pipeline 1. «Холодные» лиды vs. «горячие» клиенты - Маркетинг ловит всех подряд\, чтобы отчитаться по количеству. - Продажи получают контакты людей\, которые просто «посмотрели объект». Решение\: — Внедрите скоринг лидов (например\: 1 балл — скачал презентацию\, 5 баллов — запросил private-показ). — Настройте разные воронки для «холодных» и «горячих» лидов. 2. Разрыв между обещаниями и реальностью - Реклама говорит\: «Эксклюзивные условия». - Продажи предлагают\: «Стандартный договор». Что делать\: — Проведите тайный shopper-тест — как менеджеры отрабатывают лидов. — Синхронизируйте скрипты маркетинга и продаж. 3. Нет nurturing (прогрева) - 80\% клиентов покупают после 5-7 контактов\, но им перестают писать после 2-х. Исправляем\: — Автоматизируйте цепочки писем (не только «цена»\, но и полезный контент). — Добавьте личные касания (например\, звонок после 3-го письма). Как понять\, кто прав\? 1. Анализируйте\: - Конверсию из лида в показ (если <10\% — проблема в маркетинге). - Конверсию из показа в сделку (если <20\% — проблема в продажах). 2. Проверьте\: - Куда уходят клиенты\? (Если «обдумывают» → не хватает доводов). 3. Сравните\: - Какие лиды не дошли до продаж (может\, их «отсеивают» рано\?). 3 способа наладить процесс 1. Еженедельные разборы - Маркетинг + продажи разбирают 3-5 потерянных лидов. - Ищут\, где был пробел\: недогрели\? Недоработали\? 2. Общие KPI - Не «100 лидов в месяц»\, а 5 сделок. - Премии — только за результат\, а не активность. 3. Сквозная аналитика - Отслеживайте весь путь\: от клика до сделки. - Используйте CRM (например\, HubSpot или Битрикс24). Вывод Пустой pipeline — это системная ошибка\, а не вина одного отдела.

Изучение C#. Урок 10

Условия, сравнение На улице идет дождь, значит нужно взять зонт. Часто ли такие мысли посещают Вас, когда Вы смотрите в окно и видите ливень? То есть Вы сейчас представили некоторое условие, а на условиях в языках программирования очень многое построено. Посудите сами. Если переменная a равна 10, то мы умножаем ее на 5, если переменная a равна 20, то мы плюсуем к ней 30. Все это называется условными выражениями и с их помощью можно делать ветвление программы. Начнем с конструкции if/else. static void Main(string[] args) { var weatherOnStreet = "Дождь"; if (weatherOnStreet == "Дождь") { Console.WriteLine("Возьмите зонт"); } else { Console.WriteLine("На улице хорошая погода"); } } Мы объявляем переменную, в которую кладем текст "Дождь". Дальше идет слово if(если). То есть мы проверяем, что находится в переменной и если там "Дождь" то выводим текст "Возьмите зонт". В противном случае (else) "На улице хорошая погода". Хочу, чтобы Вы обратили внимание на ==. Именно с помощью двух равно происходит сравнение чего-то с чем-то, в нашем случае переменной с текстом. Так же, мы можем сделать следующее. Если на улице дождь, то берем зонт, если на улице солнце, то возьмем очки, иначе ничего не берем. Попробуем это написать. static void Main(string[] args) { var weatherOnStreet = "Дождь"; if (weatherOnStreet == "Дождь") { Console.WriteLine("Возьмите зонт"); } else if (weatherOnStreet == "Солнце") { Console.WriteLine("Возьмите очки"); } else { Console.WriteLine("На улице хорошая погода"); } } После блока if, можем добавить else if. А что, если у нас град, грозы, ветер, да и еще множество погодных условий и нужна разная логика. Для этого будем использовать конструкцию switch. static void Main(string[] args) { var weatherOnStreet = "Дождь"; switch (weatherOnStreet) { case "Дождь": Console.WriteLine("Дождь"); break; case "Ветер": Console.WriteLine("Ветер"); break; case "Солнце": Console.WriteLine("Солнце"); break; default: Console.WriteLine("Не понятная погода"); break; } } Объявили переменную, помещаем ее в круглые скобки после switch и дальше с помощью ключевого слова case перечисляем возможные варианты и после : делаем логику, которая должна быть при таких условиях. Видите слово break? Это означает, что после выполнения кода внутри блока case - мы должны выйти и не делать следующие блоки от других кейсов. В дальнейшем мы часто будем использовать условные конструкции и поэтому практика будет подкреплять полученные навыки. А пока, вспомните наш калькулятор. Чуть улучшим его и сделаем возможность складывать, умножать, делить и вычитать числа. Так же пока не будем рассматривать возможные ошибки, а будем считать, что пользователь вводить два числа, а затем любой из 4 символов. static void Main(string[] args) { var a = int.Parse(Console.ReadLine()); var b = int.Parse(Console.ReadLine()); var c = Console.ReadLine(); switch (c) { case "+": Console.WriteLine(a + b); break; case "-": Console.WriteLine(a - b); break; case "/": Console.WriteLine(a / b); break; case "": Console.WriteLine(a b); break; } } Пишем 5, затем 10, потом символ и получается 50.

ИДЕАЛЬНАЯ КЛАССИКА - ЭТО TISSOT PR 100

💯Швейцарские часы, сапфировое стекло, кварцевый механизм и черный стальной ремень - вечный тренд. ⭐️ Звезды, которые носят часы Tissot: Анджелина Джоли, Майкл Оуэн, Тони Паркер, Лю Ифэй, Вират Кохли часы #инвестиции #роскошь #подарок #богатство #аксессуар #мода #эксклюзив #звезда #люкс #премиум #часылюкс #часынаручные #ролексы #стиль

Принципы управления данными: метаданные, планирование, кросс-функционал

Продолжаем разговор о принципах управления данными. Для управления данными необходимы метаданные. Для управления любым активом нужны данные об этом активе (число сотрудников, номера счетов и т. д. и т. п.). Данные, используемые для управления другими данными, принято называть метаданными. Поскольку данные — вещь неосязаемая, для понимания того, что они собою представляют и как их использовать, требуются определения и знания, которые и формулируется в метаданных. Порождаются метаданные в недрах самых различных процессов, связанных с созданием, обработкой и использованием данных, включая проектирование архитектуры, моделирование, обслуживание, распоряжение и управление качеством данных, разработку систем, текущие информационно-технологические и бизнес-операции, аналитические исследования. Управление данными должно вестись исключительно планомерно. Даже в небольших организациях встречаются крайне сложные по структуре ландшафты технологических и бизнес-процессов. Данные проистекают из множества физически разнесенных источников и перераспределяются по различным участкам с целью последующего использования. Для координации работы и согласования конечных результатов управление данными должно вестись тщательно спланированным образом — как с точки зрения архитектуры, так и сточки зрения процессов и процедур. Управление данными — кросс-функциональный процесс, требующий широкого спектра знаний и навыков. Единственной команде не по силам управлять всеми данными организации. Управление данными требует, помимо чисто технических навыков, глубокого и всестороннего понимания происходящего, а также воли и способности к сотрудничеству между функциональными подразделениями. Первый пост о принципах управления данными 👉 здесь Оставшиеся принципы будут рассмотрены в следующем посте. управлениеданными #datamanagement #datagovernance #dama