Основные боли бизнеса это автобусный фактор, переизобретение решений задач, текучка и стагнация знаний сотрудников. На KnowledgeConf в прошлом году разработчики, тестировщики и руководители рассказали, как им удалось решить эти проблемы. Меньше месяца осталось до KnowledgeConf 2020 Online — самое время вспомнить доклады прошлого года и подготовиться к новой онлайн-конференции. В новом формате она стала доступнее: контента больше, а цены ниже.



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

Гарри Клейн — американский психолог, исследователь интуитивных решений в экстремальных ситуациях. В своей книге «Источники силы» Клейн описал один случай: пожарная команда приехала вызов, в жилом доме горела кухня. Команда вошла в помещение и начала тушить огонь, но он не затухал. В какой-то момент командир почувствовал тревогу и приказал срочно уходить. Когда все вышли из дома, пол на кухне провалился. Оказалось, что пожар начался в подвале, а потом перекинулся наверх, поэтому погасить его на кухне не удавалось.



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

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

Toyota — мировой лидер автомобилестроения, один из самых дорогих автомобильных брендов и синоним слова «качество». Toyota известна своей сложной производственной системой, благодаря которой она стала мировым лидером. На её описание потребовалось 10 лет и 20 версий, в итоге появился документ «Философия Toyota 2001». Часть принципов из этой книги — кайдзен и канбан — используются в IT. Но эти принципы лишь часть системы постоянного обучения и непрерывного совершенствования, которая плотно интегрирована во все процессы корпорации.



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

История Toyota — отличный пример управления знаниями. Но что будет, если знаниями не управлять, а систему не выстраивать? Велосипеды, сломанные конвейеры, автобусы, «сжигание» денег на онбординге и legacy — все это случается с компаниями, когда они не задумываются об управлении знаниями.

Industrial IoT — это мониторинг, диспетчеризация и автоматизация инженерных систем промышленных объектов, зданий, бизнес-объектов. Датчики разных параметров, счетчики и контроллеры собирают данные с этих объектов, например, температуру и влажность воздуха в серверной, показания счетчиков воды в многоквартирных домах, уровень углекислого газа в помещениях. Контроллеры обрабатывают эту информацию и отправляют все в «облако».

Компания Wiren Board производит контроллеры с Linux для industrial IoT. Устройства собирают данные с нефтедобывающих скважин и банковских отделений, следят за микроклиматом в серверных и супермаркетах. Контроллеры интегрируются с системами верхнего уровня партнеров компании. Системы аутентифицируют устройства — понимают, что разговаривают со своим датчиком, а не с чужим, а потом авторизуют. На этом этапе возникает проблема — контроллеров тысячи, клиентов сотни, а единой системы интеграции нет. Простые традиционные способы, например, пары логин/пароль, уязвимы к атакам и неудобны в развёртывании.



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

26 ноября в Инфопространстве пройдет ScalaConf 2019 — профессиональная конференция для Scala-разработчиков. Возможно, первая в России. Накануне события мы попросили Вадима Челышова (dos65), руководителя ПК ScalaConf 2019, рассказать о докладах и концепции конференции.



Вот, что мы узнали: на конференции нас ждет проповедник функционального программирования, четыре англоязычных доклада, новый инструмент, который решит проблемы дата-инженеров, доклад о том, почему Scala Plugin несовместим со Scala-компилятором, «Профессор Haskell» и много функционального программирования. Также мы поговорили о границах развития Scala-разработчика, почему среди них нет джунов, о «холиваре» между Scala и Haskell, и об информационном «пузыре» коммьюнити. Подробности под катом.