инженерная практика конференции 2021

ДОБЫЧА’ 2021: Повышение эффективности эксплуатации механизированного фонда скважин, ППД.

27-29 апреля 2021 года ООО «Инженерная практика» проводит IV Ежегодную производственно-техническую конференцию «ДОБЫЧА 2021: Повышение эффективности эксплуатации механизированного фонда скважин, ППД». Ежегодное совещание носит рабочий характер и направлено на обсуждение применения лучших практик в области актуальных вопросах механизированной добычи нефти. К участию приглашаются Эксперты вертикально-интегрированных компаний, научных центров, поставщиков технологических решений, производителей оборудования и нефтепромысловой химии.
Форма участия: очная/заочная (по запросу).
Тематика: реализация корпоративных стратегий в области эксплуатации механизированного фонда скважин, включая повышение показателей надежности и энергоэффективности работы добычного оборудования и экономической эффективности добычи; развитие постоянного мониторинга параметров работы ВСО и ФЕС пласта и реализация «интеллектуальных» алгоритмов и методов управления добычей нефти; развитие и применение специализированных программных комплексов; совершенствование организационных, физических и химических методов эксплуатации скважин и систем сбора нефти в условиях воздействия осложняющих факторов; лучшие практики применения и развития технологий одновременно-раздельной эксплуатации; повышение эффективности эксплуатации систем ППД и другие, напрямую связанные с обеспечением эффективности механизированной добычи темы.
Планируется посещения производственных объектов Региона.

Источник

Инженерная практика конференции 2021

Место проведения: online

2 марта стартует новый сезон «Инженерной практики». Приглашаем на обучающие онлайн-семинары, где вы познакомитесь с основными возможностями КОМПАС-3D и специализированными САПР-приложениями, которые помогают упростить решение отраслевых задач. Подключайтесь и задавайте любые вопросы команде КОМПАС-3D в прямом эфире!

РАСПИСАНИЕ

Место проведения: online

Онлайн-семинар» организован АО «КАДФЕМ Си-Ай-Эс», элитным партнером компании Ansys.

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

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

Участие в семинаре бесплатное.

Место проведения: online

Цифровая трансформация рынка ритейла активно набирает обороты, а торговые сети все чаще переходят на BIM. На вебинаре своим опытом поделятся специалисты одного из ведущих российских ритейлеров, АО «Перекресток», и расскажут, как внедрение передовых технологий позволяет решать строительные задачи и проектировать 80 магазинов в год.

На нашем вебинаре специалисты АО «Перекресток» расскажут, с применением каких BIM-инструментов удалось организовать взаимосвязь информационной модели с внутренним тарификатором АО «Перекресток» для получения более точных объемов и смет.

Компания поделится идеей создания эталонной BIM-модели магазина и планами развития BIM-технологии в торговой сети.

Вебинар будет актуален для BIM-специалистов, ГИПов, руководителей, проектировщиков и сметчиков.

Дата и время: 11 ноября в 11:00 (МСК)

Кристина Смирнова, продакт-менеджер направления «Сметные решения» CSD
Дмитрий Резюк, руководитель инженерно-технического отдела АО «Перекресток»
Екатерина Ланг, руководитель отдела нормирования и контроля АО «Перекресток»

Участие бесплатное! Необходима предварительная регистрация.

Место проведения: online

Главное событие в мире автоматизированного моделирования от компании Dassault Systemes

11 ноября в 10:00 открывается виртуальная конференция для России и стран СНГ, посвященная новому релизу программного комплекса SOLIDWORKS 2022.

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

Эксперты компании расскажут, каких успехов добились наши клиенты из России и стран СНГ, использующие SOLIDWORKS, а также рассмотрят истории успешного внедрения программного комплекса.

Присоединяйтесь также на технические сессии, которые состоятся 15 и 18 ноября.

Зарегистрируйтесь для подключения к трансляции.

Место проведения: online

XXII Российская конференция MSC Software (HxGN Live Design & Engineering Russia 2021) – одна из ежегодных конференций Hexagon, посвященных вопросам цифровизации.

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

Место проведения: online

Форум «РосТИМ. Российские технологии информационного моделирования в строительстве» — самый представительный смотр отраслевых цифровых решений от отечественных разработчиков.

РосТИМ-2021 организуют компании АСКОН и Renga Software с участием фирмы «1С», Кредо-Диалог, Rubius, ЛИРА софт, НТЦ «АПМ», НПП «АВС-Н», Эрикос-ЦСП, ITLand при поддержке Университета Минстроя и Университета Иннополис.

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

К участию в РосТИМ-2021 приглашаются специалисты и руководители проектных организаций, архитектурных бюро и мастерских, девелоперских и строительных компаний, органов экспертизы, проектных отделов промышленных предприятий, а также госслужащие управлений и отделов капитального строительства и муниципалитетов, преподаватели архитектурно-строительных вузов и колледжей.

Участие бесплатное после регистрации на сайте форума https://ros-tim.ru/.

Место проведения: online

«Строим вместе» (Building Together, ранее BIM Day) — ежегодное профессиональное мероприятие, призванное объединить в одном пространстве архитекторов, инженеров и специалистов смежных профессий.

Мероприятие будет полезным как существующим пользователям Archicad, BIMcloud и BIMx, так и специалистам, пока не знакомым с портфолио решений Graphisoft для архитектурного BIM-проектирования.

С пользовательскими докладами выступят представители ТПО PRIDE, Wowhaus, АЛКУТА, АК БАРС Инжиниринг, Сити-Арх, UM Architects и CNTR Architects.

К участию приглашаются все заинтересованные специалисты из России, Украины, Белоруссии, Казахстана, Грузии и стран СНГ.

Участие бесплатное, необходима предварительная регистрация.

Место проведения: Москва

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

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

Источник

Доклады

Техдолг и legacy (4)

Ныряем в легаси: набор приемов и принципов рефакторинга старья

Зачастую поддержка или рефакторинг легаси-кода может обернуться настоящим адом для разработчика, особенно если перед вами большая кодовая база.

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

Доклад принят в программу конференции

Перезагрузка легаси-проекта: прийти и победить!

Я работаю в заказной разработке и моя «спецификация» — помогать легаси-проектам, которые оказались в «сложном положении»: предыдущая команда «не справляется» и нужно «починить» ситуацию. Часто это означает частичную или полную замену команды разработки, а иногда и менеджмента проекта. Здесь есть много специфики: может не быть истории изменений, документированного деплоя, процессы «хромают» или и вовсе не «настроены». В конце концов, почему этот проект приходится «спасать»?

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

Доклад принят в программу конференции

Как работать с техдолгом и техническими задачами в продуктовой команде

Техдолг и технозадачи — разные вещи. Одни замедляют разработку, а вторые помогают её ускорять.
* Как можно посчитать количество техдолга и как его оценивать?
* Как за ним можно следить и вовремя править?
* Как сравнивать технозадачи и понимать, какие из них делать прямо сейчас?
* Как можно управлять приоритетами и не замедлять продуктовую разработку?

Доклад принят в программу конференции

Выявление технического долга и оценка его процентов

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

Заполнить bugtracker задачами технического долга недостаточно: чтобы продать бизнесу технический долг, нужно понимать “процент выплат” по каждой из задач. Встает вопрос «что важнее»: вычистить лог, чтобы саппорт быстрее с ним разбирался, добавить метрики в Prometheus, чтобы DCO видело падение производительности, доделать честную многопоточность для хороших циферок масштабируемости и производительности или отрефакторить старую подсистему.

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

Доклад принят в программу конференции

Опасности безопасности (1)

Попросите продуктовую безопасность вам помочь

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

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

Доклад принят в программу конференции

Клуб по интересам: как и зачем создавать сообщество (3)

Внутренние истории — три innersource-проекта в крупном банке

Часто, когда мы говорим о крупных компаниях, у нас возникают ассоциации вроде «кровавый enterprise», бесконечные NDA и тщательное регулирование всех процессов разработки.

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

Доклад принят в программу конференции

InnerSource: инструкция по применению

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

Со временем зрелые команды по наитию решают эти проблемы инженерными практиками и подходами, даже не подозревая, что пришли к InnerSource. Хорошая новость в том, что сообщество энтузиастов из мировых компаний InnerSource Commons делится лайфхаками и правильными рецептами приготовления InnerSource. Принципы open source, уже давно доказавшие свою состоятельность в разработке сложных программ, отлично перекладываются на корпоративные реалии.

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

Доклад принят в программу конференции

Внутреннее комьюнити: митапчики с пиццулей или машина по настройке процессов?

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

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

В общем, это краткий курс по инвестированию в людей, который точно даст вам пару применимых на практике инструментов.

Доклад принят в программу конференции

65536 путей развития техлида (4)

Куда развиваться техлидам

Все хотят расти, и техлиды — не исключение. Но иногда возникает ощущение, что вы достигли потолка — и совсем непонятно, куда же расти дальше. Это обманчивое ощущение я и попытаюсь развеять. 🙂

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

Доклад принят в программу конференции

Фасилитация: боремся с бесполезными встречами

Пора признать: 5/10/30 умных человек на встрече ≠ полезная встреча.

Затянутые груминги, бесполезные синки, токсичные и невовлеченные участники, неразрешимые споры и унылая атмосфера — всё это и другие признаки поганых встреч частенько встречаются в IT-компаниях.

Хватит это терпеть! Приходите на мастер-класс по фасилитации.

Мы не будем рисовать человечков на флипчарте, но освоим 5 базовых техник, которые смогут спасти ваши встречи.

Фасилитировать — это нестыдно!

Доклад принят в программу конференции

Как найти в своей работе то, о чём не стыдно рассказать

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

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

Однако многим классным специалистам мешает внутренний барьер. Все рабочие задачи делятся на два типа:
1) абсолютно тривиальные,
2) те, которые вы ещё не решили.

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

Обсудим список вопросов, которые имеет смысл себе задать. Выработаем углы зрения, под которыми стоит на свою работу посмотреть. Надеюсь, в конце у каждого будет хотя бы одна идея доклада.

Доклад принят в программу конференции

Из техлида в менеджеры продукта. Миф или реальность?

После 10 лет подъема по технической карьерной лестнице я сменила профиль и стала менеджером продукта.

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

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

Доклад принят в программу конференции

Нетривиальное качество (2)

Инъекция качества: как мы перестали искать дефекты

Технологический Центр Дойче Банка

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

Расскажу в своем докладе:
* Почему инспекция не улучшает качество?
* Что мы изменили в процессе разработки для предотвращения дефектов?
* Причём здесь документация?

Доклад принят в программу конференции

Мутационное тестирование: внедрение на большое количество сервисов усилиями одной команды

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

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

В своем докладе я расскажу:
* Немного о мутационном тестировании, что это, вообще, такое?
* Как внедряли мутационное тестирование на 1000+ микросервисов усилиями одной небольшой команды.
* Как донести результаты мутационного тестирования до разработчиков и какой инструментарий мы для этого создали?
* И, конечно же, о трудностях, с которыми столкнулись в процессе.

Доклад принят в программу конференции

Пропаганда инженерных практик (5)

«Новое» API к «старой» системе: архитектурные ошибки, которые мы допустили

Каждый раз, когда мы готовим новую версию API или просто новый интеграционный протокол, мы попадаем в среду с типичными входными условиями:
• API нужно через неделю;
• контрагент готов с нами сотрудничать;
• «тут же чуть-чуть поправить то, что у нас есть!».

А мы, как разработка, стремимся к:
• сделать «стильно, модно, молодежно» (соответствие современным практикам);
• убрать «раздражающее» несоответствие между текущими внутренними сущностями и API;
• отгадать требования «из будущего» и заложить точки гибкости для упрощения поддержки.

За последние 1,5 года мы выпустили 2 крупных продукта, завязанных на интеграцию информационных систем нескольких компаний между собой (6 API для внешней интеграции только на нашей стороне: 4 протокола для платежей и фискализации и 2 протокола для идентификации физических лиц).

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

Доклад принят в программу конференции

Гарри Поттер и методы прагматичного программирования

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

В этом докладе мы немного под другим углом посмотрим на привычные вещи. Проведем ретроспективу с учетом изменений, произошедших в современном мире.

Темы:
* Революция в мире редакторов кода (LSP).
* О чем молчит скрам.
* Надежные процессы без тестировщиков и стейджинга.
* Как мы не поняли SOLID.
* Что сказал Кент Бек, но его никто не услышал.
* Почему пирамида тестирования осталась в прошлом.
* Зачем не нужны микросервисы.

Доклад принят в программу конференции

Как мы ушли от локальной разработки в облака и что выиграли

В 2016 году команда Хекслета переехала на разработку через Docker, который имеет проблемы с производительностью в macOS. Для решения этой проблемы, среди прочего, решили попробовать разработку на удаленных машинах. Оказалось, что у такого подхода есть масса неочевидных плюсов.

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

Темы:
* Проблемы разработки на Маке: память, докер, среда.
* Провайдеры (aws, google, do), коннекты, задержки.
* Ненапряжная работа в Vim, VScode.
* Правильные терминалы и интеграция с Tmux.
* Совместная работа и внешние домены.
* HTTPS, веб-хуки, интеграции с внешними системами.
* Terraform, Ansible и друзья.
* Батарейка!

Доклад принят в программу конференции

От кода до прода. Последствия выбора стратегии ветвления и опыт пошагового внедрения trunk based development

1. Сделаю краткий обзор популярных стратегий ветвления (git flow, github flow, gitlab flow, trunk based development), покажу сходства и различия между ними.
2. Разберу вышеупомянутые стратегии на кирпичики — задачи, в решении которых они задействованы: распределение, интеграция, поставка и поддержка. Покажу плюсы и минусы существующих решений, чтобы можно было на их основе собрать наилучшую стратегию для своей команды.
3. Покажу, как оптимальные решения влияют на скорость и качество разработки. Покажу зависимости между рекомендуемыми практиками. Что нужно внедрить сначала, а что можно отложить на потом.
4. Расскажу о нашем опыте внедрения TBD, что прошло успешно и принесло плоды, а что у нас не получилось и какие интересные выводы мы сделали.

Доклад принят в программу конференции

Делать велосипед или использовать готовое? Чек-лист прагматика

Писать самим или разбираться с чужим кодом? Если этот вопрос для вас актуален, приходите послушать мой доклад и тогда вы:
* узнаете, почему собственное решение уже решенной кем-то задачи может быть хорошо, а может быть плохо. С примерами;
* разберетесь с 8-ю блоками вопросов, каждый из которых характеризует один из аспектов проблемы (пере)изобретения велосипеда;
* познакомитесь с методикой объективной оценки возможности создания рабочего решения взамен существующего;
* сможете тут же попробовать методику на сайте.

Доклад принят в программу конференции

Техлид и его команда (4)

Чего не знает Джон Сноу: растим из инженера Короля Севера

Какое чувство сильнее гордости за то, как вырос инженер в твоей команде? Только горечь расставания с мидлом, которого ты год тащил до senior level, а тот вдруг раз и свалил. Да и не каждого дотянешь, тем более по удаленке, а уж себе замену подыскать.

У хорошего лида всегда цейтнот, поэтому приходит понимание, что инвестировать в команду нужно, но с умом.

В своем докладе я расскажу, что такое ELTV (employee’s lifetime value) и как его улучшить, а также покажу свой собственный silver bullet для развития и удержания инженеров — визуальный Personal Development Roadmap.

Доклад принят в программу конференции

Матрица компетенций: как техлиду развивать и оценивать знания разработчиков

В 2016 году компания Dunice начала стремительно развиваться, и количество сотрудников постоянно увеличивалось. Мы, как и многие техлиды, столкнулись с проблемой оценки и развития уровня знаний новых и текущих сотрудников.

Основные вопросы, которыми мы задавались:
* Как понять, кто сможет работать с той или иной технологией?
* У кого достаточно знаний и умений для выполнения задач на том или ином проекте?
* Как упростить процесс оценки знаний у людей и снизить операционные расходы?
* Как понимать скорость роста сотрудника?
* Где и как хранить эти данные, чтобы не пришлось вычислять их на лету?

Хотелось создать нечто стабильно работающее, чтобы не пришлось заменять на другое через пару лет. Через два года тестирования готовых систем мы поняли: это провал. Использование системы тестирования привело к тому, что люди просто решали тесты без конверсии в практические знания и умения. В этот момент было решено создавать собственный инструмент. Так появилась Матрица компетенций Dunice.

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

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

Источник

• ← инженерная практика журнал официальный сайт
• инженерно геодезическая практика отчет →