Русский
Русский
English
Статистика
Реклама

Блог

Томограф для нефтегазовых месторождений, или Пересечение трёхмерной расчётной сетки и плоскости на CUDA

28.12.2020 08:09:56 | Автор: admin
В данной статье приведены описание и алгоритм решения задачи построения рисунка внутренностей месторождения, являющегося результатом пересечения расчётной сетки с плоскостью. А также приведены тайминги построения решения, которые получаются на типичном компьютере геолога-модельера или гидродинамика.
image
Визуализация расчётной сетки и куба


Моделирование месторождений уже упоминалось ранее в предыдущих наших обзорах (http://personeltest.ru/aways/habr.com/ru/company/bashnipineft/blog/512052/). При построении 3D-моделей нефтегазовых месторождений в различных областях в гидродинамике, в геологии, в механике часто используются объёмные расчётные сетки. Также сетки нужны, например, при использовании метода конечных объёмов.

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

Часто пользователю, который работает с моделью, нужно визуально оценить распределение физических свойств внутри модели месторождения. Это можно делать разными способами, например, созданием сечений или наложением масок-фильтров на ячейки сетки.
Реализовать в программе визуализацию слоев (i, j, k) сетки довольно просто и быстро.

image
Визуализация слоев сетки i, j (слайсов)

Однако хотелось бы получать рисунок вдоль произвольной плоскости, при этом иметь возможность двигать и крутить эту плоскость в произвольном направлении с хорошим FPS. Таким образом, модельеру нужен этакий быстрый томограф модели месторождения.
Геометрия угловой точки (corner-point grid) способ задания геометрии расчётных сеток из шестигранников, наиболее часто использующийся в гидродинамическом и геологическом моделировании. Такой формат подразумевает:

Наличие пилларов отрезков, каждый из которых задан двумя точками, а каждая точка тремя координатами (x, y, z). Пиллары могут быть вертикальными, наклонными, но никак не горизонтальными. Пиллары образуют множество размером M x N, но не обязательно с постоянным шагом. Множество пилларов задаётся массивом COORD.

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

Кроме этого, задаётся массив нулей и единиц ACTNUM. Нулевое значение в ячейке указывает на то, что она неактивна и её не стоит учитывать в расчётах.

image
Геометрия угловой точки

Входными данными для задачи построения сечения являются:
1) геометрия угловой точки:

  1. размерность сетки;
  2. массив COORD;
  3. массив ZCORN;
  4. массив ACTNUM;

2) коэффициенты общего уравнения секущей плоскости:
$Ax+By+Cz+D=0$

Решение не обязательно должно быть точным, ведь решение будет оцениваться пользователем только визуально. На выходе должны получиться массивы:
  • Упорядоченный массив троек индексов (i, j, k) пересечённых ячеек;
  • Упорядоченный массив координат точек полигонов пересечения ячеек;
  • Упорядоченный массив индексов точек начала нового полигона в массиве координат точек пересечения. В конце массива для удобства должно быть добавлено общее количество точек пересечения.

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

Хорошо бы, чтобы алгоритм построения пересечения был нетребователен к памяти, так как сами сетки довольно объёмны. Например, большая сетка на 1000х1000х1000 ячеек, построенная на типе данных одинарной точности (float) занимает примерно 30 гигабайт памяти.

Нами был разработан довольно экономный к памяти алгоритм построения пересечения геометрии угловой точки и плоскости:
1. Проход по всем ячейкам и определение факта пересечение плоскости с ячейкой:
a. Подстановка каждой вершины в левую часть уравнения плоскости.
b. Если среди полученных чисел есть хотя бы два с противоположными знаками, то пересечение есть.
c. Если среди полученных чисел есть хотя бы три нуля, то пересечение есть.
d. Запись в массив флагов факта пересечения.

image
Геометрия угловой точки, секущая плоскость, пересечённые ячейки

2. Stream Compaction: из массива флагов собираем индексы ячеек, которые пересекаются с плоскостью. Располагаем их в новом массиве компактно.

3. Для каждой пересекаемой ячейки определяем количество точек пересечения проход по всем вершинам и всем рёбрам ячейки. Складываем значения количества точек пересечения соответственно индексам ячеек в общий массив количества точек пересечения.

4. Prefix sum: префиксная сумма по массиву количества точек пересечения в ячейках. Это позволит определить смещение от начала массива координат точек для каждой ячейки.

5. Поиск и запись точек пересечения в массив координат точек пересечения.

6. Для каждой пересечённой ячейки находим барицентр точек пересечения. Составляем вектора по каждой точке пересечения и барицентру. Сортируем точки пересечения по углу относительно первого вектора, тем самым упорядочиваем точки в полигон.

image
Упорядочивание точек пересечения для одной ячейки в полигон

Таким образом получаем результирующие массивы координат полигонов и индексов начальных точек полигонов.

image
Результат пересечения геометрии угловой точки и плоскости

Видно, что каждый шаг алгоритма можно распараллелить.
Была создана реализация алгоритма, распараллеленная на потоки с помощью OpenMP. В такой реализации примерно 87% времени выполнения занимает первый пункт алгоритма проход по всем ячейкам и определение факта пересечения. Время выполнения реализации на OpenMP оказалось слишком большим для комфортной работы с пересечениями в окнах визуализации.
Чтобы ускорить построение пересечения, алгоритм был реализован на CUDA. Сетка должна быть постоянно в видеопамяти, т. к. пересылка её с оперативной памяти занимает слишком много времени, даже если использовать CUDA Streams. В такой реализации примерно 43% времени выполнения занимает первый пункт алгоритма, 20% времени пересылка результатов с видеопамяти в оперативную память. Kernel-функция, используемая в реализации для определения факта пересечения, довольно проста:

Заголовок спойлера
__global__ void checkIntersectCell (const TCOORD* coord,const TZCORN* zcorn,const TACTNUM* actnum,TFLAGS* flags,TIJK I, TIJK J, TIJK K,TPLANE A, TPLANE B, TPLANE C, TPLANE D,const TCOEF* coefX, // предрасчитанные коэффициенты для поиска координат x узловconst TCOEF* coefY // предрасчитанные коэффициенты для поиска координат y узлов){const auto globalIndex = blockDim.x * blockIdx.x + threadIdx.x;if (globalIndex < (I * J * K)){if (actnum[globalIndex]){// globalIndex = K * J * i + K * j + k = K * (J * i + j) + kconst auto k = globalIndex % K;const auto j = (globalIndex / K) % J;const auto i = (globalIndex / K) / J;int_fast8_t signPlus = 0;int_fast8_t signMinus = 0;int_fast8_t signZero = 0;for (size_t p = 0; p < vertexCount; ++p){const auto indexPillar = (J + 1) * (i + p / 4) + (j + (p / 2) % 2);const auto zPillarTop = coord[6 * indexPillar + 2];const auto z = zcorn[(2 * i + p / 4) * 2 * 2 * J * K + (2 * j + (p / 2) % 2) * 2 * K + (2 * k + p % 2)];const auto x = (z - zPillarTop) * coefX[indexPillar] + coord[6 * indexPillar + 0];const auto y = (z - zPillarTop) * coefY[indexPillar] + coord[6 * indexPillar + 1];switch (sign<int_fast8_t>(A * x + B * y + C * z + D)){case -1: ++signMinus; break;case 1: ++signPlus; break;case 0: ++signZero; break;}}flags[globalIndex] = static_cast<TFLAGS>((signMinus > 0 && signPlus > 0) || signZero >= 3);}else{flags[globalIndex] = static_cast<TFLAGS>(0);}}}


Для тестирования был взят случай, который даёт большое количество полигонов пересечения. Сетка в тестах состояла из прямоугольных параллелепипедов, по каждому направлению (x, y и z) сетка располагалась от 0 м до 100 м. Плоскость проходила через центр сетки и имела нормаль (1, 1, 1).

image
Геометрия угловой точки и секущая плоскость для тестирования

Результаты тестирования и замеры времени выполнения представлены ниже. Тестирование проводилось на одном и том же компьютере.

image
Таблица с результатами тестирования и замерами времени выполнения

image
Синяя диаграмма показывает ускорение построения пересечения на OpenMP на 8 потоках относительно OpenMP на 1 потоке. Зелёная диаграмма показывает ускорение построения пересечения на CUDA относительно OpenMP на 8 потоках

Из результатов замеров времени выполнения видно, что, используя реализацию на CUDA, можно добиться практически незамедлительного построения пересечения больших сеток. А учитывая то, что CUDA и OpenGL функционально совместимы, то результат построения можно не пересылать с видеопамяти в оперативную память, что ускорит время решения задачи примерно на 20%.

Также видно, что количество вершин в результате пересечения незначительно отличается. Это происходит в случае, когда плоскость касается угла ячейки. Из-за точности расчётов в результате может засчитаться в пересечение очень маленький треугольник, а может и быть пропущен. Результат различается не только между построением на CPU и GPU, но также и между построением на различных CPU и на различных GPU.
Пересечение геометрии угловой точки и плоскости обычно просматривают в 3D окне.

image
Модель месторождения и секущая плоскость

image
Результат пересечения модели месторождения и плоскости

Заключение: в статье показан пример решения одной из многих задач, возникающих при создании программного обеспечения для процессов моделирования месторождений нефти и газа. Несмотря на огромный парк open-source кодов, решение подобных задач требует мультидисциплинарной подготовки разработчиков, и поэтому представляется интересными развивающими вызовами в области computer science, в которых доля рутинного программирования минимальна, а мозги надо включать на полную. Этим и интересны задачи нашей предметной области, к которым хотелось бы привлечь внимание аудитории и потенциально заинтересованных энтузиастов и разработчиков. В частности, создание построителя пересечения геометрии угловой точки и плоскости являлось задачей на одном из хакатонов, проведённых в 2019 году РН-БашНИПИнефть при участии Уфимского Государственного Авиационного Технического Университета (УГАТУ).

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

P. S. Возможно, поиск пересекаемых ячеек был бы быстрее, если бы применялось K-d дерево. Но реализовать такое решение гораздо сложнее, учитывая, что нужно придумать, как удачно построить само дерево поиска и равномерно распараллелить поиск на потоки. К тому же, если даже теоретически поиск ускорить так, чтобы он вообще не занимал времени (сейчас занимает 87% времени), то производительность на OpenMP реализации вырастет в 7.7 раз, что всё равно медленнее, чем реализация на CUDA.
Подробнее..

Простые средства информирования внутри компании

14.08.2020 16:23:02 | Автор: admin
Всем снова привет!

Вроде бы еще не так давно я рассказывал, как выглядит обмен знаниями в Exness глазами новичка, и вот уже снова есть, что рассказать!

На самом деле, гибкость и скорость это два больших плюса в любом бизнесе. И на работу knowledge managera это влияет в огромной степени.

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

Почему этим хочется поделиться здесь, на Хабре? Очень просто: в ИТ-сфере управление знаниями все еще считается чем-то сложным, требующим больших усилий и обдумывания. Много раз приходилось слышать что-то типа: Ну ведь это же все долго и непонятно. А можно как-то быстро и просто?.

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



У нас в компании никто ничего вовремя не узнаёт...


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

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

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

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

Кому реально надо, тот и так узнает!


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

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

Более того, бывают такие ситуации, когда вы лучше знаете, кого аффектит планируемый апдейт. А если человек даже не подозревает, что вы готовите что-то, что может изменить его business as usual, как он должен предугадать ваши действия?

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

Если у вас нет отдела, который занимается трансфером знаний внутри компании (управление знаниями или внутренние коммуникации), это нужно (в значении must) делать своими силами. Если такой отдел есть (очень рад за вас!), то нужно вовремя передать информацию ему, и коллеги сами лучшим образом ее распространят.

Это все долго и сложно. Лучше фичи быстрее пилить!


Часто сталкиваюсь в ИТ с мнением, что шеринг знаний это все долго и сложно, что это сильно отвлекает от самого важного (продукт сам себя не напишет!). Именно поэтому активности по работе со знаниями часто даже не начинаются. Или после старта на волне энтузиазма, когда инициаторы сталкиваются с необходимостью продавать свою идею всем и каждому, мотивация угасает, и передача знаний прекращается.

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

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

Конечно, без работающего продукта на рынок выйти не получится. Важность разработки никто не умаляет. Но раз в месяц экспортнуть список задач из JIRA, добавить к каждой описание в 3-5 слов, скопировать это в письмо и нажать кнопку Отправить, это ведь не займет много времени, верно? Да вы и так, скорее всего, что-то подобное для руководства составляете и отправляете.

Ну или посчитайте, сколько времени вы тратите на разъяснения каждому спрашивающему по одному и тому же вопросу? Например, как там ваша библиотечка устроена? Я не уверен, что если суммировать время всех ваших ответов, оно будет меньше, чем время на создание той самой новой фичи. Вполне возможно, что рассказываете вы в разы дольше, чем работаете над продуктом.

Куда писать? Чем пользоваться?


Конечно, каналы информирования могут быть разными. Чем пользоваться зависит от культуры конкретно вашей компании. Если у вас приняты чатики в Slack и почта, заведите себе отдельный канал для новостей и ежемесячный дайджест с помощью email-рассылки. Самое главное, что следует помнить и понимать люди разные, и информацию они предпочитают получать по-разному. А еще люди не пользуются сервисами, которые им неудобны. Даже если начальник заставляет.

Поэтому нельзя рассчитывать, что вашу рассылку прочтут 100% нуждающихся в информации коллег, а чатик в Slack не будет на Mute у половины аудитории. А значит, нужно создавать столько каналов информирования, сколько возможно. Как у нас говорят чтобы из каждого утюга звучало. Тогда есть какие-то шансы достучаться до каждого сотрудника, предоставить ему информацию тем способом, которым он готов ее получать.

Как вам удобно следить за новостями? Кому-то нравятся ленты, кто-то слушает радио в машине, кто-то смотрит видео, а кто-то просто в столовой узнает все от коллег.

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

Так а сами-то вы что делаете?


Чем больше вариантов задействовано, тем больше шанс, что вся компания живет с одинаковыми данными. Этим мы руководствуемся, развивая управление знаниями в Exness.

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



Блог базы знаний и Blog Yellow Pages


Все знают, что в каждом спейсе Confluence есть такая сущность, как Блог? А кто из вас им пользуется?

На самом деле, блог хорош. Он позволяет создавать посты, которые располагаются по свежести (самый свежий самый верхний). При этом ссылка на блог остается неизменной. То есть, открывая блог конкретного спейса, посетитель всегда увидит самую свежую новость. Старые при этом никуда не деваются просто уходят вниз.

На блог можно подписаться. Тогда о каждом новом посте вам будет падать уведомление в почту.

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

По итогам опроса сотрудников, мы выяснили, что следить за внутренней соцсетью не всем удобно. Однако про существование Базы Знаний знают все. И мы начали дублировать все новости, которые публикуются в соцсети, в блог. Неудобно следить за постами в разных чатиках и группах? Пожалуйста, подпишитесь на блог и получайте уведомления о новостях в почту.

Кстати, насчет тегирования. Понятно, что сотрудникам не все новости интересны. Кому-то важно знать, что происходит в маркетинге, а кому-то нужны только обновления конкретного продукта. Самостоятельно выделять из ленты блога нужные новости достаточно трудно. Однако очередной стандартный функционал Confluence позволяет вытянуть на любую страничку посты из блога, согласно использованным лейблам (Labels).

Чтобы сделать всем удобно, мы разделили все новости, которые мы транслируем, по темам, присвоили каждой теме свои лейблы и настроили на отдельной страничке структуру разделов. В каждый из разделов подтягиваются из блога новости по соответствующей тематике (на основе лейблов) за последние 60 дней.

Мы назвали этот ресурс Blog Yellow Pages, и теперь любой заинтересованный в конкретной теме сотрудник может зайти и посмотреть последние новости по интересующей сфере бизнеса или продукту.

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

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

Ежемесячный почтовый дайджест




Что может быть проще, чем корпоративная почта? Конечно, я знаю минимум одну большую компанию, в которой почты не существует совсем. Но это исключение. А для большей части компаний почта настолько естественное средство коммуникации, что даже удивительно, почему они не пользуются ею для распространения новостей.

В Exness почта использовалась мало. Вероятно, так сложилось исторически. Но никто не мешал (и не мешает сейчас) нам поработать над ее оживлением.

Умные люди говорят, что даже если ресурс непривычен, но он содержит важный, ценный для сотрудника и привлекательный визуально (= профессионально оформленный) контент, читатели будут им пользоваться, а вы получите положительную обратную связь.

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

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

Мы собрали в одном письме наиболее важные изменения за июль, дополнили их небольшими описаниями (насколько я помню, это называется лиды), добавили прямые ссылки на анонсы и разослали это на всю компанию через маркетинговый сервис почтовых рассылок.

Почему не просто с личного email, например, моего? Не устаю говорить, что PR и маркетинг это очень важные составляющие управления знаниями. Без них невозможно. А значит, надо пользоваться аналитикой, изучать поведение ваших клиентов, считать конверсии, создавать логотипы ваших активностей и т.д.

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

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

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

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

Онлайн-встречи с экспертами




Про культуру внутренних митапов много сейчас говорят в сообществе. Что надо их запускать, надо делиться знаниями, тренировать публичные выступления, устраивать различные FuckUp Nights и прочие полезные офлайн-мероприятия.

Но как это сделать в условиях удаленки? Как добиться того, чтобы выступление эксперта не превратилось в Yet Another Webinar с говорящей головой и не очень хорошо подготовленной презентацией.

Ну и поскольку во время митапов люди обычно обмениваются знаниями (шарят свои, отвечают на вопросы), то думать об этом нужно именно менеджеру по знаниям.

Лично меня очень драйвят внутренние митапы, воркшопы от сотрудников, train the trainer и прочие подобные мероприятия. Во время них из эксперта можно вытащить столько полезной и важной информации, причем, напрямую, без посредников, сколько никогда не получится в почтовой переписке или через документацию. Вот он, человек перед тобой. Ты можешь задать ему любой вопрос прямо здесь, и он тебе ответит прямо сейчас.

Имея в компании потребность в понимании различных наших продуктов, мы решили организовать проект, который назвали Live Updates. Это не совсем вебинар. И даже не столько вебинар, сколько полноценная мини-конференция в Zoom с использованием платформы для онлайн-опросников Slido.

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

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

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

Про вопросы и подготовку презентации следует сказать отдельно. Мы заинтересованы в качестве выступления (спикер, кстати, тоже). Поэтому мы над ним работаем совместно. Примерно за неделю в Slido создается комната для мероприятия, и доступ в комнату транслируется по стандартным каналам (вы помните: соцсеть, чаты, дайджест, блог). Все желающие могут анонимно (или нет) оставить свой вопрос и полайкать чужие. Мы открываем доступ к вопросам спикеру, чтобы он мог понять, что интересует слушателей больше всего, и соответствующим образом развернуть свою презентацию. Или не разворачивать, а просто заранее подготовить ответы на эти вопросы.

За пару дней до мероприятия мы проводим со спикером прогон его выступления, проверяем техническую сторону трансляции, даем обратную связь по контенту, манере выступления (онлайн и офлайн две большие разницы) и удаляем из Slido вопросы, которые будут освещены в презентации.

Во время выступления мы продолжаем собирать вопросы от публики. Почему это делается не голосом или в чате Zoom? Slido решает сразу две проблемы.

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

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

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

Второй плюс Slido удобство. Платформа удобна как для посетителей, так и для организаторов. Она поддерживает любые устройства. Спикер может говорить в камеру и параллельно с телефона управлять опросами. У платформы есть удобная админка и красивый фронт, который можно шарить в эфире.

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

В общем, добавляйте мероприятиям интерактива, и будет получаться не хуже, чем в офлайне!

А дальше что?


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

А в планах еще больше. Наши следующие шаги: сообщества практиков, корпоративный блог (не тот, который с новостями в Confluence, а вполне себе настоящий блог для самых разных историй: от участия в конкурсах и финансовых результатов компании до описания любимого туристического направления), воркшопы, которые профессионалы в своей сфере проводят для всех желающих разобраться в их профессии, ну и продолжение развития культуры внутренних митапов в самых различных проявлениях.

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

Не хотим knowledge managera! Что делать?


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

Итак, кто может заменить вам менеджера по управлению знаниями?

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

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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru