Изменения

Перейти к: навигация, поиск
поправил очень грубые опечатки, добавил ссылок на контент.
= Asger Alstrup Palm. The open source, functional programming platform flow =
[https://www.facebook.com/mtsepkov/posts/2608898432500428 Пост на FB] http://0x1.tv/20191114AA Asger Alstrup Palm. The open source, functional programming platform flow. Представление платформы функционального реактивного программирования с собственным языком, в режиме живой демонстрации кода, развертываемой от hello world к более сложным конструкциям интерфейса, которые представляют собой поток вложенных абзацев, создаешь в визуальном редакторе, а далее отражаемом как верстка экрана. UI при этом создается для всех мобилок, html и desktop, и есть прозрачное взаимодействие с серверной частью - единый язык и платформа для full stack приложений, при этом на серверной части можно интегрироваться с Java, mysql и другими платформами. Реактивное программирование позволяет легко связывать элементы интерфейса, дает графические возможности и так далее. В целом доклад довольно любопытный, но, на мой взгляд, не хватает изюма, киллер-фич нового подхода. Когда [http://0x1.tv/20131024-25 в 2012 Светлана Исакова впервые представляла Kotlin], там был блестящий доклад, в котором сравнивали типичное старое и то, что дает новое, при чем на сложных примерах. Здесь такой динамики не хватало, жаль.
P.S. Доклад был дистанционно - не дали визу из-за технического сбоя в новой системе виз для Питера...
= Евгений Асламов. 22 вопроса архитектора =
[https://www.facebook.com/mtsepkov/posts/2608943662495905 Пост на FB] http://0x1.tv/20191114BB Евгений Асламов (Evgeny Aslamov) из ЛАНИТ. 22 вопроса архитектора - рассказ про чек-лист, который в ЛАНИТ нормирует результат работы архитектора - о чем он должен подумать и примерно в каком порядке. При этом архитектор - человек или коллектив. Вопросы достаточно масштабные, практически задают темы - эксплуатация, масштабирование и так далее. При этом проверка по чек-листу означает (а) указание артефакта и места в нем, где описано, или явное указание на отсутствие артефакта и (б) при отсутствии решения - описать причину отсутствия. Полный чек-лист был показан, а дальше в форме историй рассказ о том, как отдельные пункты появлялись. От первых пунктов: фиксация важных решений по процессу; принимать решения об архитектурных подходовподходах, например, выборе DDD заранее и далее к тоже понятным пунктам: думать заранее про отказоустойчивость; писать логи; думать заранее о том, как в логах разобраться; помнить о viewpoint, а не ограничиваться суперсложной архитектурной диаграммой для всех; поддерживать целостность разных viewpoint за счет метамодели архитектуры; доносить эту целостность до команды. И в заключении - помнить об ограничениях при выборе новых технологий, которые, к сожалению, ограничивают компетенциями разработки и эксплуатации - не полностью отказываясь, а как постепенное апробирование.
К посту был комментарий автора: Евгений Асламов Небольшая ремарка - это не про весь ЛАНИТ:-).
= Дмитрий Павлов из Apache: Что такое настоящий open source (и почему его меньше, чем вы думаете) =
[https://www.facebook.com/mtsepkov/posts/2608973945826210 Пост на FB] http://0x1.tv/20191114AB Дмитрий Павлов из Apache Software Foundation: Что такое настоящий open source (и почему его меньше, чем вы думаете). На доклад забежал в самом конце, после доклада 22 вопроса по архитектуре. Но успел на заключение, в котором подводились итоги. Доклад надо будет посмотреть, выводы же были подтверждены историями и там наверняка интересно. А выводы про проверку open source такие. (1) Проверяйте лицензию - бывает, что в подробностях написано что-то совсем другое, чем open source. (2) Поискать реальное community. Не работают ли все в одной компании? Кто принимает решения, насколько это документировано, как можно повлиять. (3) Кто владелец бренда? Если не коммерческая организация - хорошо.
В ответах на вопросы. Apache платит юристам и инфра-сотрудникам (ресурсы). Все управление - волонтерское. Деньги - спонсорские, спонсоров - много.
= Роман Цирульников. Микросервисные архитектуры с позиции инженерии систем =
[https://www.facebook.com/mtsepkov/posts/2609122569144681 Пост на FB] http://0x1.tv/20191114BD Роман Цирульников, Яндекс.Деньги. Микросервисные архитектуры с позиции инженерии систем. Достаточно неожиданный взгляд на архитектуру stakeholder-driven систему. Началось все с того, что в микросервисной архитектуре сервис не является самодостаточным элементом, сервисов становится очень много и они образуют системы, которым присуще поведение, отсутствующее у отдельных элементов, сложность возрастает и не помещается в одну голову. И надо выделять системы микросервисов, проводя границы, которая относительно произвольна, в соответствии с принципом "Система в глазах смотрящего", она не существует объективно. И Роман предлагает выделять границы, основываясь на стейкхолдерах и их интересах, применяя принцип Дейкстры separation of concent именно исходя из интересов стейкхолдеров. При этом предметом архитектуры перестают быть технологии, наоборот, она начинает строится через арбитраж различных интересов.
К сожалению, в докладе было очень много концептов, и очень мало практических примеров. Концепты и принципы - прекрасны, тем более, что многие из них подтверждались ссылками на известные работы - Закон Конвея, риск второй версии системы погибнуть под тяжистью амбиций при том, что скромная первая успешно стартовала, описанный Бруксом, подход DDD и понимание разработчиками предметной области, эволюционная архитектура с последовательным выделением сервисов из существующих вместо желания все переписать. Но без примеров получилась сборка принципов, которые без приземления на конкретные примеры висят в воздухе и все более-менее известны хорошим разработчиком. Проблема ведь не в том, что ты не знаешь принципы, а в том, как их применить к конкретной ситуации. А ситуаций в докладе не было. И это очень жаль, потому что по рассказу чувствуется, что за докладом стоит реальный опыт, и это же звучало в ответах на вопросы.
= Максим Шаломович. Как архитектура прогибалась =
[https://www.facebook.com/mtsepkov/posts/2609162982473973 Пост на FB] http://0x1.tv/20191114BE Максим Шаломович (Max Shalomovich). Как архитектура прогибалась. Рассказ о том, как выживает архитектурная практика в agile-проектах. Ведь есть мнение, что в agile архитектуры нет, надо код писать, а не картинки рисовать, и в некоторых проектах действительно прорастает спагетти-код без архитектуры, но такие проекты долго не живут. И доклад был как раз о том, как они встроили архитектурную практику в agile.
Компания ЛАНИТ - крупные заказчики и коммерческие организации. Они в последнее время хотят Agile - раз в две недели показ, обратная связь и главное чтобы удовлетворенность заказчика важнее условий контракта! Но при этом фиксированный бюджет и контракт надо выполнить полностью. И это накладывало свои особенности.
Их решение. Типовой ЖЦ проекта таков: предварительное планирование, несколько недель, дальше - итерации: анализ-разработка-тестирование-приемка.
Они в этот цикл добавляют ЯВНО точки принятия архитектурных решений. По факту они есть, но Не не артикулированы, и иногда проявляется хорошо, а иногда - плохо.
# проектирование на предварительной стадии
# проектирование между анализом и разработкой, ответственность может быть на аналитиках или разработчиках, кто сильнее
= Иван Бакаидов. Интерфейс для глаз =
[https://www.facebook.com/mtsepkov/posts/2609486229108315 Пост на FB] http://0x1.tv/20191114AF Иван Бакаидов (Ivan Bakaidov). Интерфейс для глаз. Иван - разработчик в linka.su и основное занятие - делать софт, с помощью которого люди с нарушением речи, поражение опорно-двигательного аппарата, ДЦП , могут формировать тексты для искусственного воспроизведения голосом. У него самого ДЦП, его речь не понимают, а программы дают эту возможность. И доклад за него говорил синтезированный голос, а текст был написан заранее.
Но рассказывал он не про них, а про технологию eye tracker. Он не верил в технологию, устройства были дороги. А тут появился tobii 4c eye tracker - устройство за 12тр вместо 140, и с открытым sdk, а главное - с компенсацией движения головы, потому что оно используется как дополнительная фишка для геймеров. А еще в нем из коробки есть управление глазами в меню открытых программ, он попробовал и привык, оно хорошо работает. И он попробовал использовать это устройство для других задач управления программами. Решения из коробки - ре не работают, он пробовал встроенные в Windows и пару других. Все они требуют большой концентрации взгляда на определенной области, очень чувствительны к случайным переводам глаз. Но при этом есть виртуальные клавиатуры, которые очень хорошо вводят текст глазами, и нечувствительны к временным отвлечениям зрачка. Вывод: устройство рабочее, но приложения писать надо самим, в основе интерфейса как раз квадратики-кнопки, как в клавиатуре. И он написал библиотеку компонентов, на которой пишет конкретные приложения, например, чтобы писать сообщения на стену вКонтакте - было видно. А еще в демо была игра арканоид, управляемая движением глаз (запись экрана).
= Митя Сошников. mPyPl: монадическая Python-библиотека для работы с потоками данных в функциональном стиле =
[https://www.facebook.com/mtsepkov/posts/2609554939101444 Пост на FB] http://0x1.tv/20191114BG Митя Сошников (Dmitri Soshnikov). mPyPl: монадическая Python-библиотека для работы с потоками данных в функциональном стиле. Дмитрия я слушаю много лет, у него всегда интересные доклады. В этот раз он рассказывал про библиотеку, которая позволяет писать на python в функциональном стиле, выстраивая цепочки преобразования данных так, которые эффективно срабатывали за счет механизма ленивых вычислений. Рассказ был на конкретном прикладном примере задач обучения нейронных сетей - пусть есть обучающие изображения, разложенные по дереву директорий, названия которых представляют собой классифицирующие теги. А дальше нам надо на основе этого формировать обучающие и тестовые выборки, которые пачками передавать нейронной сети, последовательно для обучения или смешивая для тестов, по пути нормируя параметры выборки при том, что изображений разных классов может быть сильно разное количество, а также нормируя сами изображения. Код выглядит очень элегантно и понятно. И все это оформлено как библиотека.
Другой пример - задачи смешивания изображений. Тут был показ с использованием публичного Face API, который по фото выделяет опорные точки лица, поворот головы, пол эмоции. А дальше мы можем просто смешивать разные изображения афинными преобразованиями, строить композитные фотки, Дима показывал примеры.
= Сергей Полуэктов. Академия разработки: как мы вырастили корпоративный университет =
[https://www.facebook.com/mtsepkov/posts/2609656575757947 Пост на FB] http://0x1.tv/20191114AJ Сергей Полуэктов (Sergey Poluektov). Академия разработки: как мы вырастили корпоративный университет. Развернутый рассказ о ситуации развития в условиях жесткого дефицита специалистов. В Ульяновске сильное IT и развитие компаний ограничено набором сотрудников, и даже если все выпускники профильных факультетов останутся в Ульяновске, то компаниям все равно не хватит. А отъезд сотрудников существует, хотя внутри Ульяновска работу меняют крайне редко. Поэтому все возможности развития связаны с привлечением студентов, привлечением людей из вне IT, или IT-шников, которые владеют невостребованными технологиями. В результате компании конкурируют друг с другом, привлекая к себе специалистов бесплатными образовательными курсами, митапами, летними школами и всем остальным. И за последние 5 лет все, кто приходят на работу получили образование в конкретной компании. Сергей рассказывал про опыт Mediasoft. Они в 2012 запустили первый курс по php, 6 месяцев, гостевая книга как учебный проект. Пришло 80, дослушали 30, сделали хоть что-то 20, сделали хорошо 5, из них двое работают до сих пор. Опыт оказался удачным, сейчас читают много базовых и продвинутых курсов по разных технологиях, курс по тестированию. Сотрудничают с ВУЗами чтобы окончание курсов зачитывалось за летнюю практику.
Мотивация читать курсы для сотрудников - это не просто работа, это очень важная работа для развития компании и соответственно оценивается. А еще если хочешь внести в компанию технологию - ты должен сам подготовить команду, и это тоже мотивирует. Ищут тех, для кого оплата - не слишком важная, внимательность к деталям.
И обязательно выделить наставника.
Главная фишка доклада - в экономике: 2-3 человека, которые выходят на работу после годовых курсов, через которые проходят сотни человек (цифру называли, не записал) - ОТБИВАЮТ РАСХОДЫ тем, что приносят компании в следующем году. Был слайд с конкретными цифрами расходов и доходов. Базовая кафедра в ВУЗе - намного дороже, есть опыт другой компании, они посчитали не эффективнымнеэффективным. Плюс ВУЗ - это обязаловка для обучающихся , а им интересны добровольцы и свободный отсев.
= Alexey Kuksyonok из DataArt. Межкультурные коммуникации. Инструкция по применению =
[https://www.facebook.com/mtsepkov/posts/2611422022248069 Пост на FB] http://0x1.tv/20191115AA Alexey Kuksyonok из DataArt. Межкультурные коммуникации. Инструкция по применению. Рассказ на собственном опыте взаимодействия с западными коллегами в разных компаниях. Алексей не только постигал на опыте, но и читал книги, и в докладе ссылки были. И в докладе было системное изложение, подкрепленное кейсами, смесь личного опыта и теории. О разделении: западная культура - это Северная Америка, Средняя и Северная Европа, Средиземноморье больше относится больше к восточной, как и СНГ. Китая и Япония надо рассматривать отдельно, там восточные черты и церемонии больше высказано. И надо помнить, что разница - статистическая, а не тотальная, встречаются самые разные люди. Но статистика дает ожидаемое поведение. Продолжение - в комментариях.
Наша культура - внешние факторы контроля, против внутренних факторов на Западе.
= Александр Шкарапута. Определение эмоционального состояния человека с помощью компьютерного анализа параметров звуковой волны =
[https://www.facebook.com/mtsepkov/posts/2611481498908788 Пост на FB] http://0x1.tv/20191115BC Александр Шкарапута (Alexandr Shkaraputa). Определение эмоционального состояния человека с помощью компьютерного анализа параметров звуковой волны. Любопытный доклад. Первоначальная гипотеза - из музыки: Мажор воспринимается радостно, а Минор - печально, у них различаются интервалы: большая терция мажора - 2 тона, минор - 1.5 тона. Дальше берут запись, анализом фурье получают спектр, выделяют три максимума и смотрят их отношения частот. Первоначальные исследования были на разделении радости и печали, потом перешли к шести эмоциям: удивление, отвращение, гнев, страх, радость, печаль. В докладе были численные результаты анализа по 60 записям. Дальше обученная нейронная сетка хорошо различает эмоции, это не зависит от индивидуальных особенностей человека, и характеристик речи (темп, придыхание и другие) и даже языка. Различение эмоций по записям проводилось экспертами психологическими методами. Что интересно, погрешность при опознании наигранных эмоций (из чтения сказок, когда читатель пробовал их воспроизводить) - выше, так что, возможно, метод позволит различать искренние и наигранные эмоции.
= Даниель Саада из МГУ. Классификация фонем при внутреннем проговаривании на основе электроэнцефалограммы =
[https://www.facebook.com/mtsepkov/posts/2611544255569179 Пост на FB] http://0x1.tv/20191115BD Даниель Саада из МГУ. Классификация фонем при внутреннем проговаривании на основе электроэнцефалограммы. Любопытный доклад об исследованиях, направленных на распознавание речи на основе анализа ЭЭГ. Конечное применение - дать возможность общения тем, кто парализован и не может говорить, но мозг работает хорошо, и они могут мысленно проговорить текст. Это еще самое начало исследований, учат различать отдельные фонемы. Задача - не только распознать, но сначала - очистить ЭЭГ от артефактов, связанных с движением, морганием. Сначала был обзор исследований в мире, а потом - результаты команды МГУ, трое сотрудников и трое студентов с ВМК и Психфака ведут исследования у нас для русского языка. И эти результаты сравнимы с международными - фонемы распознаются, уровень не хуже, а фонем даже больше. Но если говорить о практике, то это - самое начало пути.
= Ольга Павлова. Логические основания дизайна интерфейсов =
[https://www.facebook.com/mtsepkov/posts/2611553652234906 Пост на FB] http://0x1.tv/20191115AC Ольга Павлова. Логические основания дизайна интерфейсов. Доклад начался с утверждения, что исходя из многолетнего опыта, никакой логике в организации интерфейсов нет. Хотя у многих есть большая потребность в том, чтобы эта логика была - и потому ее можно выдумать и представить, чтобы наличие логики успокаивало. Отсутствие логики имеет глубокие основания: проектирование интерфейсов - задача создания, применение синтетических методов, а логический вывод - это аналитический метод, он не решает задачи синтеза. Разрыв, который преодолевается на этом пути - перейти от слов к картинкам. И в докладе были практики, которыми они этот разрыв преодолевают, и различные примеры проектов, и большая боль по поводу того, что люди как-то слабо эти практики используют, хотя они довольно просты. Продолжение - в комментариях.
Вроде разрыв от слов к картинкам - не страшный, его же преодолевали 100500 раз. Но почему-то люди себя запугивают. Примеры 1.5 лет, свежие.
* Пример - статтапстартап, торгует чем-то. Взяли технаря и позвали их. Технарь не мог выдать хоть какое-то. Потом - сценарии. И тут был затык, технарь выдавал только описание функционала. Идеи: "у нас не будет корзины, это наша фича" - а как покупать-то будут. Для них стартап кончился хорошо - они забрали в счет оплаты их технику.
* Собираем продукт из ничего. Много букв, аналитическая простыня, углубляющая в разные детали. А сесть и рисовать экраны было невозможно. Зацепиться было не за что. Зацепились волевым усилием: "через неделю - 100 картинок, каких нибудь". Их выложили заказчику, он оказался доволен и ушел делать дальше
* Проектируем главную страницу. Языковая школа, которая хорошо организует немецкого языка, и взялись за английский. Люди делают custdev 8 часов в день, но это им никак не помогало сделать главную страницу и начать разговор. Картинка: люди приходят отвечать на вопросы, давайте на них отвечать - и это отвергается. А дальше пошли не из знания, а из НЕ знания: чем школа от языковых курсов, они ответили на этот вопрос - главная страница стала явной.
= Алексей Кораблев. Создание цифровых двойников роботизированных производств и инновационное офлайн программирование роботов в парадигме Индустрии 4.0 =
[https://www.facebook.com/mtsepkov/posts/2611646248892313 Пост на FB] http://0x1.tv/20191115AD Алексей Кораблев из Концерна R-Про. Создание цифровых двойников роботизированных производств и инновационное офлайн программирование роботов в парадигме Индустрии 4.0. Это был обзорный доклад о том, какие задачи они в принципе решают, совсем без погружения в технические детали, просто сообщение "мы это делаем". Только в ответах на вопросы прозвучало использование платформы Visual component. Но как обзор, для представления о том, какие задачи решаются - интересно. Кейсов очень много.
Начал он с задачи создания цифровых двойников для обычных производств, на которых выполнение операций людей фиксируется с помощью MES-систем, и реальная реализация диаграммы Ганта для операций в цеху сравнивается с тем, что получено на двойнике. Такой проект, в частности делался для Кировского завода. Как он сказал, вряд ли на двойнике проигрывают каждую смену, но вот организацию нового производства они делали. Хотя я лично не слишком понимаю, почему реально не проигрывать каждую смену. Но, может, у операционных менеджеров для этого не хватит компетенций. Кроме новых производств делают анализ простоев и оптимизацию использования высокотехнологичного оборудования, и плотный контроль за использованием того, который является бутылочным горлышком.
= Татьяна Бунто. Как с помощью бота-помощника подружить мессенджер, таск-трекер, базу знаний и раскрасить будни команды =
[https://www.facebook.com/mtsepkov/posts/2611747322215539 Пост на FB] http://0x1.tv/20191115CG Татьяна Бунто (Tatyana Bunto). Как с помощью бота-помощника подружить мессенджер, таск-трекер, базу знаний и раскрасить будни команды.
На одного человека 10+ чатов, 20+ спейсов базы знаний, и еще таск-трекер. Дальше в чате вопросы "а кто моет помочь по задаче CDI-56565? - для этого надо перейти по ссылки и разобраться, что за задача - и понять что проблема не в тебе. Аналогично, вопрос "а актуальна ли инфа по горячему резервированию в статье NNN" - надо пойти в статью, прочитать, и понять. , что не к тебе.
Чат-бот Валера: расшифровывает ссылки на статьи и номера задач названиями (и статусами, другой сопутствующей информацией. А еще - сохраняет в таск-трекере решения по задаче. Потому что типичная ситуация - долгое обсуждение в частике, потом принятое решение - его сделали, и не факт, что перенести в таск-трекер. Валера переносит итоги в таск-трекер - для этого надо ответить именно на его комментарий.
=Татьяна Гаврилова. Почему интеллект-карты так трудно создавать: когнитивные ловушки и ошибки=
[https://www.facebook.com/mtsepkov/posts/2612056752184596 Пост на FB] http://0x1.tv/20191115CH Tatiana Gavrilova. Почему интеллект-карты так трудно создавать: когнитивные ловушки и ошибки. Основная мысль доклада очень проста. В любой карте есть оформление и есть смысловая картина кусочка мира. И когда говорят о mindmap, то фокус делают на оформлении, об этом же книг Тони Бузена, который их придумал. А для реального эффекта использования важно содержание и именно на него надо обращать основное внимание.
Конечно, это вопрос отношения. Если mindmap рассматривать именно как средство оформления собственных смыслов для адекватной передачи, то содержание у тебя есть. А как человеку хорошо организовать содержание своего мозга - отдельный вопрос, не имеющий отношения к передаче этого содержания другим. И, собственно в этом была идея: нарисовать ассоциативные карты, положив в центр основное понятие и связанные с ним, используя цвета, шрифты и картинки. Mindmap и другие графические способы знаний строят мостик между логическим и образно-креативным мышлением, которые связывали с левым и правым полушариям на основе последствий травм мозга. И они эффективны.
А еще в вопросах спрашивали про цели mindmap. И это - важно. Нельзя создавать mindmap просто так, mindmap для разной коммуникации будут разные, и для фиксации знаний - тоже разные. Модельные цели для заданий: представьте, что вы рассказываете о работе своему дяде или ребенку, или, жестче: представьте, что инопланетянину закачали словарь, а связей и здравого смысла нет, надо ему объяснить. А на экзамене рисуют реальные карты для своих целей.
Из комментаривкомментариев. Иван Гаммель Я кажется уже половину коллег подсадил на FreeMind, который когда-то сам увидел в Custis. Сейчас ни одно совещание в IT не обходится без него - пишем протоколы, анализируем инциденты и делаем планы релизов, да вообще кучу всего. На английском кстати проще оказалось работать, чем на русском или немецком.
= Привет! Я Ауригорь и я Бот =
[https://www.facebook.com/mtsepkov/posts/2612120385511566 Пост на FB] http://0x1.tv/20191115CI Привет! Я Ауригорь и я Бот. Внутренний проект Аурига разработки бота, который бы разгружал HR от типовых вопросов сотрудников, и давал единую точку входа спросить о том, на что бот ответить не может. Бот работает в skype, который у них корпоративный мессенджер, небольшой фронт - на Azure, а дальше уходит на внутренний сервер, где формируются и выдаются ответы и есть web-админка для настройки.
Задачи - распознавание человеческого текста, ключевые слова, независимо от порядка. Система диалогов: после вопроса - уточняющий вопрос, и дальше продолжение в контексте. Например, на вопрос про отпуск - уточнить статус человека и характеристик отпуска. А в ответе - можно выдавать артефакты, например, карты навигации по офису, показать проход к туалету с учетом конкретного офиса.
В докладе была организационная часть, которую рассказывал Mikhail Chkalov и техническая, которую рассказывал разработчик(Владимир Малышев), не указанный в программе, а я не успел записать. Организационные проблемы понятны - на внутренний проект сначала просто давали свободного разработчика, который каждые две недели менялись, новый видел написанный код, и рвался переписать. И так полгода было без особого прогресса. Пришлось применить правильный менеджерский подход, подумать о постоянных ресурсах, которые были бы в контексте. Задачу - решили. А техническая часть показывала архитектуру решения, как раз устройство админки для настройки диалогов HR, решения по авторизации.
= Александр Поломодов. Управление знаниями в привлечении Tinkoff =
[https://www.facebook.com/mtsepkov/posts/2612272782162993 Пост на FB] http://0x1.tv/20191115CJ Александр Поломодов из Tinkoff. Управление знаниями в привлечении Tinkoff. В докладе рассказ про организацию знаний по мере роста команды, точки 10-30-70-150. Команда поддерживает публичные web-сайты Тинькова, она не только обновляет материалы и структуру сайта, но и персонализирует выдаваемое содержимое, создает для аналитиков возможности для проведения экспериментов, и работает с покупкой трафика.
Даже когда их было 10, было несколько продуктов и 3 команды по 3 человека. Начинали с Jira + Confluence + Git и Bitbucket. Confluence-пространство - про бизнес, а техническая часть была раскидана. И тогда они привели в порядок - подразделы по продуктам, flow в Jira.
=Scott Gould. Everything you need to know about getting people engaged=
[https://www.facebook.com/mtsepkov/posts/2614197125303892 Пост на FB] http://0x1.tv/20191115AK Scott Gould. Everything you need to know about getting people engaged. Название доклада очень амбициозно: за полчаса рассказать все, что нужно знать о вовлечении - круто. Но основная схема в докладе была дана, развернута до второго уровня и снабжена примерами.
Вовлечение состоит из трех частей: Scatter, Gather и Matter. Scatter - распространение, рассеивание информации, и тут надо использовать множество каналов, а главное - знать schema-hacking, основанные на психологических особенностях восприятия и разных когнитивных ловушках, которые позволяют быстро и эффективно донести ваши сообщения людей - и использовать их при подготовке и распространении сообщений.
Дальше идет Gather - сбор и включение людей которые откликнулись, не хуже, чем удерживала охота на покемонов. Два канала: Sensorial and Social, и надо задействовать оба.
И третья часть - Matter, смыслы ради которых все это делается. Любая игра и любая деятельность должны быть наполнены для людей каким-то смыслом, без них не работает. Можно использовать physical means или psychological means, но даже в случае physical means смыслы не материальнынематериальны, важны не вещи сами по себе, а то значение, которое мы им предаем, и тут были различные пути вовлечения, построенные вокруг вполне материальных мобилок у Apple и Samsung. Вообще в докладе было много примеров, шуток, вовлечения аудитории в performance, проделанные мастерски - запуск стикеров со сцены большого зала, так что долетает до задних рядов - это зрелище.
На этом я завершаю рассказ.
{{wl-publish: 2020-01-07 13:51:55 +0300 | MaksTsepkov }}
5
правок

Навигация