2020-01-07: SECR-2019 - много содержательных докладов

Короткая ссылка: SECR-2019

Ссылки сюда (2) →

О других конференциях

Пользуясь новогодними праздниками, собрал свои посты-репортажи с SECR-2019 в отчет. Я участвую в SECR с 2010 года, это была десятая для меня и пятнадцатая по счету конференция. И не я один стабильно участвую в конференции, так что SECR для меня - не только качественные доклады, но и погружение в атмосферу общения, встреча со многими знакомыми.

Оригинал на FB с Максимом Семенкиным, Игорем Одинцовым, Анной Абрамовой и Анной Мелеховой

Оригинал на FB "Три Максима - это сила" - Александр Калинин с Максимами Болотовым, Цепковым и Семенкиным

Но, надо отметить, что доклады тоже были очень интересными и разнообразными. Широкая тематическое поле - отличительная особенность SECR, она дает возможность посмотреть на то, что происходит в IT в целом, на новые направления развития. Она - не единственная такая конференция, в 2019 я был и на Highload, и на РИТ, но на SECR спектр разнообразия тем - больше. Доклады - достаточно глубокие, а не обзорные, однако ПК специально работает с докладчиками, чтобы доклад был интересен для широкого круга участников, а не только узким специалистам. Впрочем, судите сами. Помимо моего отчета хочу рекомендовать отчет Евгения Асламова и отчет Екатерины Степалиной. Наверняка можно найти и другие.

Видео с конференции уже появилось http://0x1.tv/Category:SECR-2019, можно смотреть, доклады того стоят. Есть печальный разбор Стаса Фомина о том, что видео никому не нужно и его не смотрят. Можно это обсуждать, но Стас - он же ориентируется на реальные показатели просмотров и комментариев к видео, а не на слова о том, что "все нужно".

Asger Alstrup Palm. The open source, functional programming platform flow

Пост на FB http://0x1.tv/20191114AA Asger Alstrup Palm. The open source, functional programming platform flow. Представление платформы функционального реактивного программирования с собственным языком, в режиме живой демонстрации кода, развертываемой от hello world к более сложным конструкциям интерфейса, которые представляют собой поток вложенных абзацев, создаваемый в визуальном редакторе, а далее отражаемом как верстка экрана. UI при этом создается для всех мобилок, html и desktop, и есть прозрачное взаимодействие с серверной частью - единый язык и платформа для full stack приложений, при этом на серверной части можно интегрироваться с Java, mysql и другими платформами. Реактивное программирование позволяет легко связывать элементы интерфейса, дает графические возможности и так далее. В целом доклад довольно любопытный, но, на мой взгляд, не хватает изюма, киллер-фич нового подхода. Когда в 2012 Светлана Исакова впервые представляла Kotlin, там был блестящий доклад, в котором сравнивали типичное старое и то, что дает новое, причем на сложных примерах. Здесь такой динамики не хватало, жаль.

P.S. Доклад был дистанционно - не дали визу из-за технического сбоя в новой системе виз для Питера...

Евгений Асламов. 22 вопроса архитектора

Пост на FB http://0x1.tv/20191114BB Евгений Асламов (Evgeny Aslamov) из ЛАНИТ. 22 вопроса архитектора - рассказ про чек-лист, который в ЛАНИТ нормирует результат работы архитектора - о чем он должен подумать и примерно в каком порядке. При этом архитектор - человек или коллектив. Вопросы достаточно масштабные, практически задают темы - эксплуатация, масштабирование и так далее. При этом проверка по чек-листу означает (а) указание артефакта и места в нем, где описано, или явное указание на отсутствие артефакта и (б) при отсутствии решения - описать причину отсутствия. Полный чек-лист был показан, а дальше в форме историй рассказ о том, как отдельные пункты появлялись. От первых пунктов: фиксация важных решений по процессу; принимать решения об архитектурных подходах, например, выборе DDD, заранее, и далее - к тоже понятным пунктам: думать заранее про отказоустойчивость; писать логи; думать заранее о том, как в логах разобраться; помнить о viewpoint, а не ограничиваться суперсложной архитектурной диаграммой для всех; поддерживать целостность разных viewpoint за счет метамодели архитектуры; доносить эту целостность до команды. И в заключении - помнить об ограничениях при выборе новых технологий, которые, к сожалению, ограничивают компетенциями разработки и эксплуатации - не полностью отказываясь, а как постепенное апробирование.

К посту был комментарий автора: Евгений Асламов Небольшая ремарка - это не про весь ЛАНИТ:-).

Дмитрий Павлов из Apache: Что такое настоящий open source (и почему его меньше, чем вы думаете)

Пост на FB http://0x1.tv/20191114AB Дмитрий Павлов из Apache Software Foundation: Что такое настоящий open source (и почему его меньше, чем вы думаете). На доклад забежал в самом конце, после доклада "22 вопроса по архитектуре". Но успел на заключение, в котором подводились итоги. Доклад надо будет посмотреть, выводы же были подтверждены историями, и там наверняка интересно. А выводы про проверку open source такие. (1) Проверяйте лицензию - бывает, что в подробностях написано что-то совсем другое, чем open source. (2) Поискать реальное community. Не работают ли все в одной компании? Кто принимает решения, насколько это документировано, как можно повлиять. (3) Кто владелец бренда? Если некоммерческая организация - хорошо.

В ответах на вопросы. Apache платит юристам и инфра-сотрудникам (ресурсы). Все управление - волонтерское. Деньги - спонсорские, спонсоров - много.

Вход для всех apache-проектов - apache-инкубатор (mail list), пишем предложение в установленной форме, и дальше голосование, потом 9 месяцев в инкубаторе (или больше).

Роман Цирульников. Микросервисные архитектуры с позиции инженерии систем

Пост на FB http://0x1.tv/20191114BD Роман Цирульников, Яндекс.Деньги. Микросервисные архитектуры с позиции инженерии систем. Достаточно неожиданный взгляд на архитектуру stakeholder-driven систему. Началось все с того, что в микросервисной архитектуре сервис не является самодостаточным элементом, сервисов становится очень много, и они образуют системы, которым присуще поведение, отсутствующее у отдельных элементов, сложность возрастает и не помещается в одну голову. И надо выделять системы микросервисов, проводя границы, которая относительно произвольна, в соответствии с принципом "Система в глазах смотрящего", она не существует объективно. И Роман предлагает выделять границы, основываясь на стейкхолдерах и их интересах, применяя принцип Дейкстры separation of concerns именно исходя из интересов стейкхолдеров. При этом предметом архитектуры перестают быть технологии, наоборот, она начинает строиться через арбитраж различных интересов.

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

Максим Шаломович. Как архитектура прогибалась

Пост на FB http://0x1.tv/20191114BE Максим Шаломович (Max Shalomovich). Как архитектура прогибалась. Рассказ о том, как выживает архитектурная практика в agile-проектах. Ведь есть мнение, что в agile архитектуры нет, надо код писать, а не картинки рисовать, и в некоторых проектах действительно прорастает спагетти-код без архитектуры, но такие проекты долго не живут. И доклад был как раз о том, как они встроили архитектурную практику в agile.

Компания ЛАНИТ - крупные заказчики и коммерческие организации. Они в последнее время хотят Agile - раз в две недели показ, обратная связь и главное, что удовлетворенность заказчика важнее условий контракта! Но при этом фиксированный бюджет и контракт надо выполнить полностью. И это накладывало свои особенности.

Проблемы таких желаний.

• Нет возможности сделать MVP. Заказчик agile хочет, но верит в предыдущее, где в ТЗ надо было запихнуть все - и запихивает
• Представление Заказчика: раз гибкость - значит можно делать что угодно и переделывать потом. За fixprice

Решение этих проблем, прорастающее в компаниях:

• сокращаем ненужные стадии ЖЦ проекта - вот здесь архитектура и исчезает, еще и тестирование часто исчезает
• обкладываемся ограничениями ТЗ, все что нет - выкидываем
• любые изменения через ТЗ - через запросы на изменение (оценка, принятие решения о стоимости) - зачем париться

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

Их решение. Типовой ЖЦ проекта таков: предварительное планирование, несколько недель, дальше - итерации: анализ-разработка-тестирование-приемка. Они в этот цикл добавляют ЯВНО точки принятия архитектурных решений. По факту они есть, но не артикулированы, и иногда проявляется хорошо, а иногда - плохо.

1. проектирование на предварительной стадии
2. проектирование между анализом и разработкой, ответственность может быть на аналитиках или разработчиках, кто сильнее
3. архитектурный надзор после тестирования.

На предварительной стадии

• определяют технологический стек;
• выделяют переиспользуемые системные компоненты при взгляде на систему сверху;
• определить функции, которые точно потребуются, например, отчетность;
• делают верхнеуровневое описание архитектуры - квадратики и стредочки, UML и Archimate не катит;
• определяем ключевые показатели качества для дизайна (можно развивать) и runtime (производительность, масштабируемость и отказоустойчивость).

Проектирование между анализом и разработкой

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

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

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

Да, проверку соответствия модели в архитектурном надзоре им очень хочется автоматизировать, но пока не получается, смотрят глазами.

Еще в ответах на вопросах - если уже есть проект без архитектуры, можно ли туда внедрить гибкую архитектуру? Ответ - было несколько позитивных опытов, когда архитектор приходит и начинает помогать команде разработчиков.

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

Иван Бакаидов. Интерфейс для глаз

Пост на FB http://0x1.tv/20191114AF Иван Бакаидов (Ivan Bakaidov). Интерфейс для глаз. Иван - разработчик в linka.su и основное занятие - делать софт, с помощью которого люди с нарушением речи, поражение опорно-двигательного аппарата, ДЦП, могут формировать тексты для искусственного воспроизведения голосом. У него самого ДЦП, его речь не понимают, а программы дают эту возможность. И доклад за него говорил синтезированный голос, а текст был написан заранее.

Но рассказывал он не про них, а про технологию eye tracker. Он не верил в технологию, устройства были дороги. А тут появился tobii 4c eye tracker - устройство за 12тр вместо 140, и с открытым sdk, а главное - с компенсацией движения головы, потому что оно используется как дополнительная фишка для геймеров. А еще в нем из коробки есть управление глазами в меню открытых программ, он попробовал и привык, оно хорошо работает. И он попробовал использовать это устройство для других задач управления программами. Решения из коробки - не работают, он пробовал встроенные в Windows и пару других. Все они требуют большой концентрации взгляда на определенной области, очень чувствительны к случайным переводам глаз. Но при этом есть виртуальные клавиатуры, которые очень хорошо вводят текст глазами, и нечувствительны к временным отвлечениям зрачка. Вывод: устройство рабочее, но приложения писать надо самим, в основе интерфейса как раз квадратики-кнопки, как в клавиатуре. И он написал библиотеку компонентов, на которой пишет конкретные приложения, например, чтобы писать сообщения на стену вКонтакте - было видно. А еще в демо была игра арканоид, управляемая движением глаз (запись экрана).

Митя Сошников. mPyPl: монадическая Python-библиотека для работы с потоками данных в функциональном стиле

Пост на FB http://0x1.tv/20191114BG Митя Сошников (Dmitri Soshnikov). mPyPl: монадическая Python-библиотека для работы с потоками данных в функциональном стиле. Дмитрия я слушаю много лет, у него всегда интересные доклады. В этот раз он рассказывал про библиотеку, которая позволяет писать на python в функциональном стиле, выстраивая цепочки преобразования данных так, которые эффективно срабатывали за счет механизма ленивых вычислений. Рассказ был на конкретном прикладном примере задач обучения нейронных сетей - пусть есть обучающие изображения, разложенные по дереву директорий, названия которых представляют собой классифицирующие теги. А дальше нам надо на основе этого формировать обучающие и тестовые выборки, которые пачками передавать нейронной сети, последовательно для обучения или смешивая для тестов, по пути нормируя параметры выборки при том, что изображений разных классов может быть сильно разное количество, а также нормируя сами изображения. Код выглядит очень элегантно и понятно. И все это оформлено как библиотека.

Другой пример - задачи смешивания изображений. Тут был показ с использованием публичного Face API, который по фото выделяет опорные точки лица, поворот головы, пол эмоции. А дальше мы можем просто смешивать разные изображения афинными преобразованиями, строить композитные фотки, Дима показывал примеры.

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

Библиотека доступна, ссылки были.

Сергей Полуэктов. Академия разработки: как мы вырастили корпоративный университет

Пост на FB http://0x1.tv/20191114AJ Сергей Полуэктов (Sergey Poluektov). Академия разработки: как мы вырастили корпоративный университет. Развернутый рассказ о ситуации развития в условиях жесткого дефицита специалистов. В Ульяновске сильное IT и развитие компаний ограничено набором сотрудников, и даже если все выпускники профильных факультетов останутся в Ульяновске, то компаниям все равно не хватит. А отъезд сотрудников существует, хотя внутри Ульяновска работу меняют крайне редко. Поэтому все возможности развития связаны с привлечением студентов, привлечением людей из вне IT, или IT-шников, которые владеют невостребованными технологиями. В результате компании конкурируют друг с другом, привлекая к себе специалистов бесплатными образовательными курсами, митапами, летними школами и всем остальным. И за последние 5 лет все, кто приходят на работу получили образование в конкретной компании. Сергей рассказывал про опыт Mediasoft. Они в 2012 запустили первый курс по php, 6 месяцев, гостевая книга как учебный проект. Пришло 80, дослушали 30, сделали хоть что-то 20, сделали хорошо 5, из них двое работают до сих пор. Опыт оказался удачным, сейчас читают много базовых и продвинутых курсов по разных технологиях, курс по тестированию. Сотрудничают с ВУЗами чтобы окончание курсов зачитывалось за летнюю практику.

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

Что дать стажеру на первых порах

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

И обязательно выделить наставника.

Главная фишка доклада - в экономике: 2-3 человека, которые выходят на работу после годовых курсов, через которые проходят сотни человек (цифру называли, не записал) - ОТБИВАЮТ РАСХОДЫ тем, что приносят компании в следующем году. Был слайд с конкретными цифрами расходов и доходов. Базовая кафедра в ВУЗе - намного дороже, есть опыт другой компании, они посчитали неэффективным. Плюс ВУЗ - это обязаловка для обучающихся, а им интересны добровольцы и свободный отсев.

Alexey Kuksyonok из DataArt. Межкультурные коммуникации. Инструкция по применению

Пост на FB http://0x1.tv/20191115AA Alexey Kuksyonok из DataArt. Межкультурные коммуникации. Инструкция по применению. Рассказ на собственном опыте взаимодействия с западными коллегами в разных компаниях. Алексей не только постигал на опыте, но и читал книги, и в докладе ссылки были. И в докладе было системное изложение, подкрепленное кейсами, смесь личного опыта и теории. О разделении: западная культура - это Северная Америка, Средняя и Северная Европа, Средиземноморье больше относится больше к восточной, как и СНГ. Китая и Япония надо рассматривать отдельно, там восточные черты и церемонии больше высказано. И надо помнить, что разница - статистическая, а не тотальная, встречаются самые разные люди. Но статистика дает ожидаемое поведение. Продолжение - в комментариях.

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

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

Германия, Швейцария - федерация и конфедерация, независимые федеральные земли с отдельными органами управления. Не только государственные - ТСЖ там тоже работает довольно эффективно. У нас ТСЖ так не работают.

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

Что делать? Вырабатывать внутренний статус контроля. Например, напоминалка в аутлуке, чтобы каждые 2-3 дня сообщать о статусе, и статус должен быть правдивый. И вам скажут спасибо.

Второе. У нас личностная доминанта, а у них - деловая доминанта. Мы стараемся делать работу хорошо для тех, с кем хороший личный контакт. Поэтому дни рождения и тимбилдинги. 10 мотивирующих факторов, атмосфера в коллективе - 2-3 место, а на первом - деньги.

• Предпочтителен визуальный контакт, личный разговор.
• Сделаю хорошо, если ты мне нравишься.

Иностранные коллеги. У них атмосфера в коллективе на 9-10 месте.

• Контакт без знакомства, на базе функций и ролей
• Мы им нравимся ПОСЛЕ success story, а не ДО.

Что делать? Деловой стиль. Повестка, деловой контекст во всех встречах, придерживаться темы.

Откуда все взялось? Одно время нас объединяли христианские корни. А в 11 веке - раскол христианства, и пошли своими путями.

• Запад: равноправие всех перед богом, индивид - двигатель прогресса, личность - центр бытия
• Восток: император - главный перед богом, преданность традициям, доминирование общего над индивидуальным

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

Еще важно. В коммуникации широкий контекст против узкого.

• В широком контексте 30% в явных словах, а 70% - мимика, жесты и прочее. "Мы постараемся", не говорим "нет", но делаем "нет"
• В узком контексте чувства не считываются. "Мы постараемся сделать к 1 мая" - значит будет сделано, а сложно - всем сложно

Что делать:

• Явно выдавать статус результата
• Оперировать фактами, а не чувствами. Не "ваш архитектор - не умеет работать", а "ваш архитектор несколько раз задерживал работу, и если мы хотим успеть во-время, он должен во-время выдать результат"

И есть еще несколько аспектов, о которых он в докладе не рассказал: полихрония против монохронии, аспекты жизни: соединение против разделения. И были ссылки на книги, Эдвард Халл Beyond Culture и еще пара, надо смотреть презентацию.

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

Александр Шкарапута. Определение эмоционального состояния человека с помощью компьютерного анализа параметров звуковой волны

Пост на FB http://0x1.tv/20191115BC Александр Шкарапута (Alexandr Shkaraputa). Определение эмоционального состояния человека с помощью компьютерного анализа параметров звуковой волны. Любопытный доклад. Первоначальная гипотеза - из музыки: Мажор воспринимается радостно, а Минор - печально, у них различаются интервалы: большая терция мажора - 2 тона, минор - 1.5 тона. Дальше берут запись, анализом фурье получают спектр, выделяют три максимума и смотрят их отношения частот. Первоначальные исследования были на разделении радости и печали, потом перешли к шести эмоциям: удивление, отвращение, гнев, страх, радость, печаль. В докладе были численные результаты анализа по 60 записям. Дальше обученная нейронная сетка хорошо различает эмоции, это не зависит от индивидуальных особенностей человека, и характеристик речи (темп, придыхание и другие) и даже языка. Различение эмоций по записям проводилось экспертами психологическими методами. Что интересно, погрешность при опознании наигранных эмоций (из чтения сказок, когда читатель пробовал их воспроизводить) - выше, так что, возможно, метод позволит различать искренние и наигранные эмоции.

Даниель Саада из МГУ. Классификация фонем при внутреннем проговаривании на основе электроэнцефалограммы

Пост на FB http://0x1.tv/20191115BD Даниель Саада из МГУ. Классификация фонем при внутреннем проговаривании на основе электроэнцефалограммы. Любопытный доклад об исследованиях, направленных на распознавание речи на основе анализа ЭЭГ. Конечное применение - дать возможность общения тем, кто парализован и не может говорить, но мозг работает хорошо, и они могут мысленно проговорить текст. Это еще самое начало исследований, учат различать отдельные фонемы. Задача - не только распознать, но сначала - очистить ЭЭГ от артефактов, связанных с движением, морганием. Сначала был обзор исследований в мире, а потом - результаты команды МГУ, трое сотрудников и трое студентов с ВМК и Психфака ведут исследования у нас для русского языка. И эти результаты сравнимы с международными - фонемы распознаются, уровень не хуже, а фонем даже больше. Но если говорить о практике, то это - самое начало пути.

Ольга Павлова. Логические основания дизайна интерфейсов

Пост на FB http://0x1.tv/20191115AC Ольга Павлова. Логические основания дизайна интерфейсов. Доклад начался с утверждения, что исходя из многолетнего опыта, никакой логики в организации интерфейсов нет. Хотя у многих есть большая потребность в том, чтобы эта логика была - и потому ее можно выдумать и представить, чтобы наличие логики успокаивало. Отсутствие логики имеет глубокие основания: проектирование интерфейсов - задача создания, применение синтетических методов, а логический вывод - это аналитический метод, он не решает задачи синтеза. Разрыв, который преодолевается на этом пути - перейти от слов к картинкам. И в докладе были практики, которыми они этот разрыв преодолевают, и различные примеры проектов, и большая боль по поводу того, что люди как-то слабо эти практики используют, хотя они довольно просты.

Вроде, разрыв от слов к картинкам - не страшный, его же преодолевали 100500 раз. Но почему-то люди себя запугивают. Примеры 1.5 лет, свежие.

• Пример - стартап, торгует чем-то. Взяли технаря и позвали их. Технарь не мог выдать хоть какое-то. Потом - сценарии. И тут был затык, технарь выдавал только описание функционала. Идеи: "у нас не будет корзины, это наша фича" - а как покупать-то будут. Для них стартап кончился хорошо - они забрали в счет оплаты их технику.
• Собираем продукт из ничего. Много букв, аналитическая простыня, углубляющая в разные детали. А сесть и рисовать экраны было невозможно. Зацепиться было не за что. Зацепились волевым усилием: "через неделю - 100 картинок, каких-нибудь". Их выложили заказчику, он оказался доволен и ушел делать дальше.
• Проектируем главную страницу. Языковая школа, которая хорошо организует изучение немецкого языка, взялась за английский. Люди делают custdev 8 часов в день, но это им никак не помогало сделать главную страницу и начать разговор. Картинка: люди приходят отвечать на вопросы, давайте на них отвечать - и это отвергается. А дальше пошли не из знания, а из НЕ знания: чем школа отличается от языковых курсов, они ответили на этот вопрос - главная страница стала явной.

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

Список ТЗ, которые Ольга получала. Уже из названий файлов видно, что люди писали не для того, чтобы это читали. Они просто высказывались по теме, можно сказать, сэкономили на визите к психотерапевту.

Практики работы для перехода к картинкам.

• Самое простое - линейный wizard-сценарий, диалог системы с человеком. Очень просто. Почему-то таких сценариев - ноль. Я лично думаю, что кто может - не приходят к ним.
• Puzzle-сценарий. Когда шаги логичны, а внутри хаотично. Очень быстро скатываются в фичи, не прописывают сценарий.
• Модель информационных ожиданий. Пример - письмо от системы. Какими вопросами задается человек, получая письмо? Хочу убедиться, что все хорошо - что надо проверить. Нашел проблемы - что мне делать?
• Карта фокусов. Примеры - веб и mobile. Структура интерфейсов - не дерево. И не один экран. Как изложить структуру - нет прямого подхода. Когда пользователь смотрит на систему - он смотрит на точку. И именно эти точки - фокусы. Они могут быть размазаны по экранам. Пример - недооформленный заказ.
• Логика сюжеты.
• Инсайт как джокер. Если исследовать поведение людей целиком - будет общая картина, она описывает ВСЕ. Мило аналитикам, но результаты - скучны, и дизайнеры НЕ могут их учесть, ей не разу не удалось заставить, хотя информация - о пользователях. Метод - вытаскивать из массы материала интересные кусочки, смотреть, что дизайнера драйвит, а что - нет.

Ключевое соглашение: сначала ищем способ доказательства (правоты конструкции, что это не поток мысли), а потом решаем задачу.

• Нравится/не нравится ЛПР - нормально
• Потестировали в лаборатории - без гарантий
• Выкатываем и проверяем на живых людях - очень приятно для дизайнеров и неприятно заказчикам

Но! доказательство - оно как тестирование, инструмент, а не основа работы.

Ричард Талер. Нобелевская премия по экономике за 2017 - следующий шаг за Канеманом. Статистически люди не рациональны. Но зато люди прагматичны. И интерес людей - и есть тот самый драйвер, который надо учитывать. За это - отдельное спасибо Ольге.

Дизайн интерфейса - не последовательный вывод правильного, а выбор. Нельзя вывести правильную татуировку, надо просто выбрать.

Знание о пользователях не помогает. Есть компании, которые заводят UX-лабораторию. А все равно пользователи страдают. Потому что дальше люди делают фильтр "а, это не важно" и т.п.

Если вы хотите, чтобы результат был непротиворечив, то отнеситесь к интерфейсу, как к массиву, а не отдельным точкам. Смотрим на весь массив и выделяем главное - как при анализе olap-куба.

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

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

Алексей Кораблев. Создание цифровых двойников роботизированных производств и инновационное офлайн программирование роботов в парадигме Индустрии 4.0

Пост на FB http://0x1.tv/20191115AD Алексей Кораблев из Концерна R-Про. Создание цифровых двойников роботизированных производств и инновационное офлайн программирование роботов в парадигме Индустрии 4.0. Это был обзорный доклад о том, какие задачи они в принципе решают, совсем без погружения в технические детали, просто сообщение "мы это делаем". Только в ответах на вопросы прозвучало использование платформы Visual component. Но как обзор, для представления о том, какие задачи решаются - интересно. Кейсов очень много.

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

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

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

В целом - интересно. Промышленных роботов в России не делают, а цифровые двойники - создают. И через неделю 20-21.11 они проводят в Питере Форум индустриальной роботизации.

Из комментариев. Dimitryi Stoyakin Да это действительно интересно, цифровые двойники молотят ( по умолчанию -без брака) а коим образом функционал ОТК в связке реализован?

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

Татьяна Бунто. Как с помощью бота-помощника подружить мессенджер, таск-трекер, базу знаний и раскрасить будни команды

Пост на FB http://0x1.tv/20191115CG Татьяна Бунто (Tatyana Bunto). Как с помощью бота-помощника подружить мессенджер, таск-трекер, базу знаний и раскрасить будни команды.

На одного человека 10+ чатов, 20+ спейсов базы знаний, и еще таск-трекер. Дальше в чате вопросы "а кто моет помочь по задаче CDI-56565? - для этого надо перейти по ссылки и разобраться, что за задача - и понять что проблема не в тебе. Аналогично, вопрос "а актуальна ли инфа по горячему резервированию в статье NNN" - надо пойти в статью, прочитать, и понять, что не к тебе.

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

А еще можно тегнуть Валеру и при наборе будут подсказки по статьям или таскам, online-подсказки наполнения ссылок.

А еще обращение "Валера, кинь монетку" - и Валера выбирает исполнителя, если предпочтений нет. И вносит нотку юмора, если к нему явно обратиться. Набор ответов пополняется по перлам разработчиков в таск-трекере, они раньше просто разлетались, а потом пополняют словарь.

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

Jira, Confluence и Telegram. У всего этого есть API, все на регулярках и поиске. Написан на Go, никакого ИИ. Безопасность - раньше Валера активировался по кодовой фразе, возвращал ссылку и можно было добавить. И они учили разговаривать с незнакомцами. Есть группа, в которой все сотрудники - Валера разговаривает только с ними.

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

Начальная разработка была как хобби PM, заняла 8 часов - а дальше развитие по идеям самих коллег. Самим делать стандартные задачи, напоминать, если долго не отвечают и так далее.

А еще в конце была идея - в одной из компании бот просто определял кто с кем сегодня обедает.

Обсуждение поста на FB показало большой интерес к боту, и в комментариях автор, Mike Berezin обещал "в ближайшее время попробую сделать общественную версию, раз такой интерес".

Пост Татьяны Бунто Сегодня на #secr рассказала про Валерия — нашего бота в #HFLabs, которого сотворил и обучает новым штукам продакт Mike Berezin. Пока я ехала в Сапсане на конференцию, Валерий научился цитировать прекрасные ворклоги моих коллег. Посмотреть и скачать презентацию — https://goo-gl.su/vPAHlT0 Спасибо SECR - конференция "Разработка ПО" за многогранность докладов и интересные темы. Приятное послевкусие в виде инсайтов, новых знакомых и информации для обдумывания. А еще очень приятно встречать людей, с которыми всегда есть, о чем поговорить и что обсудить!

Максим Цепков (Maxim Tsepkov), огромное спасибо за ваши заметки! Это титанический труд в онлайн-режиме публиковать мысли из докладов и нести их в массы!

Татьяна Гаврилова. Почему интеллект-карты так трудно создавать: когнитивные ловушки и ошибки

Пост на FB http://0x1.tv/20191115CH Tatiana Gavrilova. Почему интеллект-карты так трудно создавать: когнитивные ловушки и ошибки. Основная мысль доклада очень проста. В любой карте есть оформление и есть смысловая картина кусочка мира. И когда говорят о mindmap, то фокус делают на оформлении, об этом же книг Тони Бузена, который их придумал. А для реального эффекта использования важно содержание и именно на него надо обращать основное внимание.

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

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

В презентации были примеры конкретных mindmap, и она их разбирала, и был mindmap типологии ошибок.

• 1 рода - серьезные, по сути понимания предметной области
  • семантические: ошибки понимания, фрагментарность
  • системные: дробление и детализация, разнородность уровня, хаос
• 2 рода - оформление
  • синтаксические
  • эргономические

И оформление - не слишком важно по сравнению с содержанием, кроме, быть может, перегруза - человек воспринимает 7 объектов плюс-минус 2, а современный - всего 5 (американские исследования), зато быстрее обрабатывает визуальную информацию.

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

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

В вопросах спрашивали про онтологии. Они занимаются, их рисовать сложно. Языки онтологий - сложные. Поэтому сначала в mindmap рисуют скелет онтологии, а потом доводят их до concept map.

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

Из комментариев. Иван Гаммель Я кажется уже половину коллег подсадил на FreeMind, который когда-то сам увидел в Custis. Сейчас ни одно совещание в IT не обходится без него - пишем протоколы, анализируем инциденты и делаем планы релизов, да вообще кучу всего. На английском кстати проще оказалось работать, чем на русском или немецком.

Привет! Я Ауригорь и я Бот

Пост на FB http://0x1.tv/20191115CI Привет! Я Ауригорь и я Бот. Внутренний проект Аурига разработки бота, который бы разгружал HR от типовых вопросов сотрудников, и давал единую точку входа спросить о том, на что бот ответить не может. Бот работает в skype, который у них корпоративный мессенджер, небольшой фронт - на Azure, а дальше уходит на внутренний сервер, где формируются и выдаются ответы и есть web-админка для настройки.

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

В докладе была организационная часть, которую рассказывал Mikhail Chkalov и техническая, которую рассказывал разработчик (Владимир Малышев), не указанный в программе, а я не успел записать. Организационные проблемы понятны - на внутренний проект сначала просто давали свободного разработчика, который каждые две недели менялись, новый видел написанный код, и рвался переписать. И так полгода было без особого прогресса. Пришлось применить правильный менеджерский подход, подумать о постоянных ресурсах, которые были бы в контексте. Задачу - решили. А техническая часть показывала архитектуру решения, как раз устройство админки для настройки диалогов HR, решения по авторизации.

Александр Поломодов. Управление знаниями в привлечении Tinkoff

Пост на FB http://0x1.tv/20191115CJ Александр Поломодов из Tinkoff. Управление знаниями в привлечении Tinkoff. В докладе рассказ про организацию знаний по мере роста команды, точки 10-30-70-150. Команда поддерживает публичные web-сайты Тинькова, она не только обновляет материалы и структуру сайта, но и персонализирует выдаваемое содержимое, создает для аналитиков возможности для проведения экспериментов, и работает с покупкой трафика.

Даже когда их было 10, было несколько продуктов и 3 команды по 3 человека. Начинали с Jira + Confluence + Git и Bitbucket. Confluence-пространство - про бизнес, а техническая часть была раскидана. И тогда они привели в порядок - подразделы по продуктам, flow в Jira.

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

• Добавили часть про найм: в вики описание позиций, и результат собеседования - там фиксировать.
• Улучшили разделы про продукты - добавили инструкцию первого дня.
• А еще добавили технические планы и roadmap.

Команды еще выросли 70 - несколько команд над одним продуктом, надо синхронизировать представления

• Структура описания позиций: почему крутая, обязанности.
• Открытая позиция - согласованная, с конкретной задачей в jira
• Карточка кандидата. Включая отчеты о собеседовании.
• Карточка сотрудника. Включая информацию о продукте и команде. И чеклист первого дня.
• Карточка команды.
• И всякие отчеты

Потом их стало 150. Появляются люди, помогающий организовать команды, структура уже усложнилась. И уже потребовалось средство визуализации и анализа связей сложную структуру связей. Перешли на Neo4j, сущности стали нодами, отношения стали ребрами. В Neo4j есть язык, чтобы делать выборки по графу и получать визуализации. И он показывал ряд структурных графиков: связь лидер-подчиненный, Команда-подкоманда, manager-teamleader-team. И совмещение позиций. Это помогает разбираться.

Scott Gould. Everything you need to know about getting people engaged

Пост на 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, проделанные мастерски - запуск стикеров со сцены большого зала, так что долетает до задних рядов - это зрелище.

На этом я завершаю рассказ.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 13:51, 7 января 2020 • нет комментариев