7023
правки
Изменения
м
Далее - Далее — более техническая работа.
Основное - Основное — метод управляемых сопротивлений: совершить изменение без принуждения, в удовлетворительные сроки. Стимулы для участия сотрудников: капитальные проекты; ожидания потребителей; внутренняя конкуренция; понимание топов; разработка новых продуктов; производительность и эффективность; манипуляции и кооптации (если не умеете - умеете — не лезть, заручитесь поддержкой прямого руководителя и отдайте ему); явные и неявные принуждения (сверху вниз, вплоть до увольнения).
Визуализация - Визуализация — можно создавать совместно, связи проставлены - проставлены — легко меняем.
Мозг - Мозг — легаси, и в нем с доразумных времен сохранились функции, обеспечивающие жесткое выполнение инструкций. И задача злоумышленника - злоумышленника — просто ввести жертву в этот режим выполнения. За 2000 лет мозг не обновился, а информационный поток - поток — возрос. Мозг для адаптации выработал механизм стереотипного последовательного поведения. И манипуляции - манипуляции — через ввод в это состояние.
Профилактика - Профилактика — лучшее лекарство. Уважение.
Лев - Лев — тренер творческих состояний. Эту профессию придумали в Сколково в 2014, она появилась в списке будущих профессий. В 2017 появились люди, которые начали пробовать, сейчас 72 русскоязычных специалиста в 11 странах, идет институализация.
Мышление - Мышление — в головах, но часто - часто — коллективно и интерактивно. И важны условия для группового мышления. Мышление не живет отдельно от твоего состояния. Зум с камерами или без них - них — разные ситуации.
Состояние - Состояние — не просто сейчас. Есть проект 2-3 месяца. Есть динамика состояния человека, когда он в лучшей форме. Различают оперативное (20 сек), текущее (от 2 минут до дня) и длительное (любовь, депрессия и другие).
Елена - Елена — руководитель команды обучения и развития персонала в Directum. Это компания-вендор, 900+ сотрудников, площадки - площадки — Ижевск, Москва, Уфа, Тюмень. Ее команда learning and development разрабатывают и проводит обучение внутри компании. 3 менеджера по обучению и развитию + 2 тренера + она - она — лидер и тренер.
Кейс - Кейс — понятный. Обычно у них коучинг проходит в очном формате примерно два дня. но они решили сделать распределенный. Поставили регулярные встречи по 2.5 часа, но наложили дополнительное условие: должны присутствовать все члены команды. Поэтому 6 встреч заняли полгода. Суммарно по времени - времени — те же два дня.
RSC - RSC — это React server component, новая возможность React, который позволяет вести рендеринг на серверной стороне. Доклад был о том, как и для чего это использовать.
Воркеры - Воркеры — процессы обработки данных, зацепленные в конвейер.* Получение семантической сегментации с камеры. Есть библиотеки. Перевод изображения в автомобили, деревья и так далее. Параллельно - Параллельно — нейронка определяет объекты.
Они - Они — не коммерческая история. Гранты в Университете - Университете — аспиранты и студенты. Но взаимодействуют с площадками в Липецке и Новосибирске, которые беспилотники делают.
SpaceWeb - SpaceWeb — хостинг, 200+ услуг, 450+ взаимодействий. Стояли задачи сделать единую панель управления, мобильный клиент, api для доступа для клиентов.
Нет описания правки
{{Conf-Ref}}Впервые был на [http://mergeconf.ru '''MergeConf'''] в Иннополисе. Конференция молодая, проходит в третий раз. При этом собрала '''более 1500 участников''' со всей страны, это - это — не региональная конференция. Очень широкий профиль и много докладов, '''11''' параллельных треков. Доклады - Доклады — качественные, по уровню, на мой взгляд, сравнимы с докладами highload и teamlead, если учитывать, что у конференции несколько другая аудитория, в которой меньше топовых технологических компаний. И очень хорошая атмосфера активного общения.
Я лично для себя вынес с конференции несколько вещей.
# Надо внимательнее посмотреть книгу Team Topologies, о ней говорил Вацлав Довнар. Я о книге слышал, но плотно не смотрел, быстро нашел [https://tellmeabout.tech/review-team-topologies-part-1-205533a027c0 обзор Александра Поломодова] и еще несколько, проглядел. Идеи - Идеи — понятные, есть простая типология команд и типов взаимодействия. Но основная идея - идея — в постановке конструкции команд и взаимодействия под управление, при этом с учетом закона Конвея. Интересно, есть ли аналог закона Конвея для не-ИТ, а для сферы услуг и производства? Учитывая разнообразие продуктов и всякие композитные конструкции.
# Методы работы с изменениями, которые раньше звучали в докладах по agile-трансформации, теперь звучат в докладах по devops.
# Вопросы мотивации надо рассматривать комплексно: что драйвит, а что - что — напрочь отбивает мотивацию. Казалось бы, очевидно. Но на практике много докладов, которые именно про создание мотивации - мотивации — что бесполезно, если есть ее регулярное обнуление.
Еще был интересный доклад про методы социальной инженерии, где рассказывали про способы действия мошенников. В нем интересно, что в числе источников - источников — материалы call-сервера в Бердянске, где были захвачены сервера со всей информацией, центр совершал до 100к звонков ежедневно.
Я был не только на менеджерских докладах, но и на нескольких технических, для расширения кругозора. И несколько из них хочу отметить. # Про архитектуру софта для управления транспортными беспилотниками, в котором фокус был на сельскохозяйственную и другую спец.технику, у которой есть большое разнообразие задач. # Про практическое применение ИИ на основе GenAI в Газпромнефти, где рассказывали про конструкцию и использование нескольких ИИ-помощников для разных задач, и даже предлагали самим их потестировать - потестировать — они уже эксплуатируются. # Про сравнение RESTful и Json-RPC в пользу последнего за счет простоты и меньших накладных расходов. При этом, разрабатывая выставленные по RPC api никто не мешает пользоваться принципами REST для их проектирования. Просто вызов будет по-другому.
В целом на конференции технических докладов - докладов — абсолютное большинство, просто меня больше интересовали менеджерские. Так что мои заметки в этом смысле не репрезентативны.
Сам я рассказывал про самоопределение: [[Самоопределение: чего я хочу от жизни и работы (Merge-2024)|'''Самоопределение: чего я хочу от жизни и работы''']]. Предыдущий доклад на эту тему был [[Самоопределение: чего я хочу от жизни и работы (SQAdays-2023)| '''осенью на SQAdays''']]. Хотя название совпадает, но презентация и содержание — содержание — дополнено. Правда, записей с MergeConf не будет, поэтому если тема интересна - интересна — смотрите осенний доклад или [[:Категории: Самоопределение|читайте статьи]].
= Менеджерские доклады =
== Александр Крылов из Bimeister. Методы управления сопротивлением при внедрении новых процессов в компании ==
Александр работает над devops-трансформациями и изменениями в работе службы поддержки, и он рассказывал об управлении изменениями на своих кейсах. Но при этом кейсы использовались больше как иллюстрация к описанию методов и подходов к работе с изменениями и сопротивлением им.
Тезис состоит в том, что сопротивление при изменении сложившихся практик неизбежно, к этому надо быть готовым и уметь с этим работать. Часть работы - работы — умение убедить людей и продать изменения команде. У того, кто хочет изменений, даже если это руководитель, не всегда есть эти умения - умения — и тогда стоит найти человека, который сможет быть вашим голосом и убедить его. Отмечу, что при этом с ним придется поделиться с ним успехом успешного изменения, но тут уж вопрос, что для вас важнее: результат изменений или признание вашего вклада. Вообще это часть общего подхода: не настаивая на собственном авторстве идеи часто можно добиться гораздо больших изменений.
Первая теория, о которой говорил Александр - Александр — '''Теория парадоксальных изменений Арнольда Бейсера'''. Основная идея: человек когда меняется - меняется — он просто становится тем, кем он является, просто почему-то раньше не стал, он проявляет свою внутреннюю сущность. И задача изменений - изменений — помочь человеку стать способным к изменениям, сохраняя его индивидуальность. Очевидное применение - применение — с джунами, которые пока не раскрыли свой потенциал, и их надо подтолкнуть. Можно порекомендовать книги, послать на конференции. Но важно не просто дать направление, а поддерживать изменения, сохранять человека на дистанции. Мы не просто делаем индивидуальный план развития, а трекаем движение.
Но в этой парадигме можно также работать с мидл-менеджментом и со сложившимися сотрудниками: ты можешь большего достигнуть и стать лучше, только еще этого не знаешь. Отмечу, что тут основная засада - засада — сформулировать это "лучше" «лучше» и "больше" «больше» в той системе оценок, которую человек для себя признает, ведь людям важно разное: одним - одним — профессиональная оценка, другим - другим — сервис клиентам, третьим - третьим — развитие карьеры или повышение зарплаты.
Однако, тут работает и альтернативный подход: изменения неизбежны, это - это — часть общего тренда, который не остановить, и именно ты можешь сделать первый шаг, получив больше профит от этого. Впрочем, я тут отмечу, что это сработает не для всех, есть разные отношения к моде и инновациям, и многим комфортнее быть последователем, а не первооткрывателем, и об этом тоже есть типологии и модели, которых Александр не касался, например, модель [https://ru.wikipedia.org/wiki/Мертон,_Роберт_Кинг Роберта Мертона].
Следующий подход - подход — Теория изменений, Theory of Change. Александр сказал, что не смог найти первоисточник найти не смог, теория восходит к одному из экономистов Штатов 60-х. Вообще статья вики [https://en.wikipedia.org/wiki/Theory_of_Change Theory of Change] трассирует теорию к Питеру Друкеру и его Management by Objectives, управлению по целям (не путать с OKR, это - это — другое), но дальше ссылки идет на 1990-е, так что , по-видимому, реальная проработка была тогда.
Подход задает четыре компоненты изменений: действие - предпосылки - результаты - действие — предпосылки — результаты — влияние. А как ключевой вопрос ставит определение выгоды: для вас, для тех кому надо измениться и, в идеале - идеале — еще для всей компании.
Подход совместим с первым, вообще подходов много, между ними надо уметь переключаться.
Третий подход - подход — теория изменений Коттера. В ней 8 шагов, и ключевой - ключевой — первый. Надо натолкнуть топов на мысль, что изменения - изменения — неизбежны, если не сделаем - сделаем — будет ай! Сформировать мысль острой необходимости изменений. И тут хорошая метафора: пингвины на льдине, которая идет к экватору или аналогичная, и это надо показать. Потому что основная история - история — поддержка изменений. руководством.
: 2. Группа поддержки
: 3. Видение перемен
: 4. Что хотите добиться - добиться — образ будущего
: 5. Устраняйте препятствия
: 6. Добейтесь маленьких побед, особенно важно в трансформации большой компании по частям
: 7. Развивайте изменение
: 8. Закрепите изменения - изменения — этап стабилизации, это обязательно, а про него забывают
Дальше был рассказ про методы управления сопротивлением: принудительный, адаптивный, кризисный, управляемый.
Я тут хочу остановиться, и дать ссылку на еще один фреймворк, который Марк Розин рассказывал на ПИР-2021, описание можно посмотреть в [[Блог:Максима Цепкова/2021-12-12: отчет о ПИР-2021 - развитие продолжается|моем конспекте]]. У него четыре метода изменений, два из них - них — достаточно известны: жесткий реинжиниринг и мягкая сила постепенных изменений, а еще два не столь очевидны: островной метод с постепенным прорастанием изменений и метод блефа с жесткой угрозой и расторговкой, за счет чего сопротивление снижается.
А в докладе дальше рассказ на конкретном кейсе реорганизации техподдержки. Аккуратно, с учетом того, что какую-то нагрузку предполагается увеличить - увеличить — а значит это надо компенсировать, в том числе передачей каких-то функций другим подразделениям, например, на площадку для обучения. А обучение новому повысит их ценность как специалистов - специалистов — и надо думать про способы удержания.
В конце презентации чеклисты, описание этапов, опросник дл проекта и способы борьбы с сопротивлением в разных точках, их можно использовать. У меня дальше пунктирный конспект, лучше взять из презентации.
* внедрение: roadmap, манипуляции (продать бизнесу красиво); принуждение (токсик, вплоть до увольнения, требовать альтернативы до упора); стабилизация
Опросник на вход в проекте. На github, к нему есть подробное описание.
Точки борьбы с сопротивлением
* бизнес - бизнес — не готов на расходы. Борьба через риски и др.* вендоры/подрядчики - подрядчики — им нагрузка и новые требования. Жесткая позиция* поддержка - поддержка — им работа.
== Вацлав Довнар. Что общего у Team Topologies & Kanban STATIK? ==
Вацлав отвечает за безопасность, его задача - задача — выстроить процессы между разработкой, где 20-50 команд и 2-3 командами безопасности. Специалисты по безопасности отдельно, так как потребность в них - них — фрагментарна, она возникает на отдельных этапах решения задач, а не постоянно. Тут ситуация аналогично с потребностью в опытном DBA.
Team topologies ему помогло разобраться и выстроить взаимодействие между командами с опорой на шаблоны - шаблоны — а это всегда легче и построить и, главное, объяснить людям: ты не предлагаешь что-то оригинальное, что точно будут критиковать, а используешь промышленный шаблон. А Kanban-метод помогал разобраться с производительностью при взаимодействии команд с помощью взгляда через цепочки создания ценности.
В докладе был неожиданный взгляд: поскольку оба метода Вацлав применял для организации межкомандного взаимодействия, то попробовать выделить, что они говорят по конкретным вопросам организации взаимодействия. И в презентации - презентации — довольно много таких таблиц сопоставления, в том числе - числе — какие практики предлагаются для каждого из путей devops. Таблицы я в конспекте приводить не буду, смотрите презентацию. Сами методы подробно не раскрывались.
Методы дополняют друг друга, но фокусы у них - них — сильно разные. Team topologies говорит про четыре типа команд, и про способы организации межкомандного взаимодействия. А в Kanban-методе есть процесс STATIK, который формализует шаги по анализу сложившегося взаимодействия между командами в вашей конкретной компании. Можно считать, что Team topologies дает типологический язык, который можно применить в ходе Kanban STATIK. Хотя тут появляется опасность, что применяя типологию, мы упустим существенные моменты взаимодействия.
Для понимания читателями необходимо отметить, что, хотя в названии доклада и слайдах говорится про "Kanban STATIK"«Kanban STATIK», реально речь шла не только о этапе внедрения Kanban, для которой применяется процедура STATIK, но и о последующих этапах оптимизации текущей работы, описывая которые обычно говорят просто про Kanban-метод.
В операционном процессе методы тоже дополняют друг друга: Kanban через свои метрики и диаграммы работает с о скоростью прохождения потока задач, а Team Topologies фокусируется на когнитивную нагрузку, которая для умственного труда, к которому относится разработка, фактически определяет время выполнения задач.
Выделение когнитивной нагрузки - нагрузки — важная фишка. Она связана с удержанием и восстановлением в голове активного контекста для работы с доменными областями. Это не связано напрямую с конкретными задачами, в том смысле, что если идет поток задач из одной области, то переключения не требуется, а вот для выполнения задачи из другой области необходимо сделать отдельную работу по переключению. Получается, что это - это — характеристика выполнения потока, а не стоимость отдельной задачи. Время переключения контекста - контекста — существенное, все мы знаем, что если вдруг прилетела задача по области проекта, который пару лет был стабилен, то чтобы ее вспомнить может потребоваться полдня, а то и пара дней - дней — хотя решение самой задачи может быть дешевым. Так что это надо учитывать при планировании.
По когнитивной нагрузке есть опросник, его можно мерять по всем командам и работать с результатами. Способы снижения:
* Уменьшать количество доменных зон, чтобы снизить переключение контекстов
* Определить границы ответственности команды - команды — выяснение серых зон в каждом конкретном случае требует переговоров * Упростить процессы, автоматизировать рутинные задачи - задачи — ручной привод тоже дает нагрузку и ошибки* разработать team api и интерфейсы межкомандного взаимодействия - взаимодействия — точки входа, ожидаемый результат и так далее, чтобы не заниматься этим в конкретном случае.
== Александр Бындю. Стратегия решает проблемы на всех уровнях компании ==
Александр рассказывал про карту гипотез как метод наглядной и понятной для всех визуализации стратегии. Об этом у него есть книга, а рассказ опирается на опыт проведения стратегических сессий во многих компаниях.
Со стратегией есть вот какая проблема. Традиционный подход предполагает, что некоторое ядро компании собирается на стратегическую сессию, работает, вырабатывает какую-то стратегию - стратегию — а потом результаты специально упаковываются и транслируются на всю компанию. По факту при упаковке происходит сокращение и изменение смыслов, и в результате контекст и понимание стратегии в голове у тех, кто был на сессии и тех, кто получил готовое оказывается разный. Карта гипотез - гипотез — инструмент визуализации, с которым можно работать на сессии, при этом результат получается достаточно наглядный, чтобы не требовать отдельной упаковки - упаковки — проблема снимается. И простота визуализации тоже важна, традиционные стратегии на 50 страниц текста люди вообще не понимают.
Шахматы. Есть цель: выиграть игру до 30 хода, поставить мат. Есть задачи - задачи — ходить фигурами. А вот стратегия выигрыша - выигрыша — слепая зона. Научить ходить фигурами в шахматах можно ребенка. А вот стратегия - стратегия — гораздо сложнее. Кто знает стратегию своего проекта? 10 рук в зале.
Итак, есть три уровня.
# Целеполагание: куда идем и как увидим, что пришли
# Стратегирование - Стратегирование — определение пути к цели, способа ее достижения, обоснование, что путь приведет к цели - цели — и это часто пропускают# Тактика. Какие задачи конкретно нужно сделать.
Пропуск стратегии всем ИТ-шникам известен. К вам приходит бизнес с проблемой, он договорить не успевает - успевает — у вас уже готовое решение в голове, только закодировать надо. А потом оказывается, что то, что закодировали не решает задачу.
Эффективность стратегии определяется двумя факторами
# Единое понимание на всех уровнях, скорость и точность понимания (передачи), дешевая смыслов синхронизация между людьми
# Возможность быстрого перестроения стратегии при изменении ситуации - ситуации — в нынешнем мире это актуально
Если нет описания стратегии, то стратегия все равно есть, просто каждый придумает сам. Каждый надеется за счет чего-то достичь цели. Но у каждого представление о пути свое, и оно разное. Низкая мотивация у людей.
Стратегия текстом - текстом — сложно читать, воспринимать, вовлечь людей, сложно менять: изменения текста локальны, и надо учитывать связи, а для этого стратегию целиком загрузить в голову, восстановив смыслы.
Типичные проблемы компании без стратегии.
* Низкая мотивация
* Споры за приоритеты между членами команды
* Споры за приоритеты проектов и задач с руководителями
* Попытки пропихнуть бесполезную и дорогую задачу. Особенно директором или другим топом.
Карта гипотез - гипотез — метод стратегического планирования для проектирования следующего шага развития.
Схема построения: Цель - Цель — субъект (чью жизнь меняем) - гипотезы - — гипотезы — задачи (почему сработает)
Типичная ситуация примерно такая. Нефтянка. Задача - Задача — уменьшить травмы на производстве за 2 года. Очень крутая задача. Цель - Цель — есть, из нее выписаны задачи на 10 лет вперед. Но трассировки от задач до целей - целей — нет, нет гипотез.
Например, есть идея делать ролики про травмы - травмы — и снизит травмы. Но это надо превратить в гипотезу, объяснить, почему именно просмотр ролика подействует: люди проникнуться соблюдением правил, или испугаются последствий травм, или еще почему-либо. Разные гипотезы - гипотезы — разные ролики. И важно, чтобы в гипотезе было про тех людей, на которых роликами предполагается воздействовать, что поменяется в них и почему. Аналогично - Аналогично — про каски: что должно измениться для людей, и почему оно изменится. Потому что если они будут воспринимать это просто как блажь начальства и показуху - показуху — это не скажется на травмах, зато мотивацию снизит.
Еще пример. Компания ставит задачу стать более публичными. Реактивное решение - решение — идем выступать, писать, давать интервью. Но! Было бы неплохо узнать - узнать — зачем. Скажут: бренд, узнаваемость. Но дальше спрашиваем: а как узнаем, чего достигли? Если узнаваемость для прибыли или новых заказов - заказов — то это одни выступления и публикации. И тут еще надо понимать, на каком шаге воронки продаж фокусируемся: чтобы пришло больше лидов, или чтобы решение клиентами принималось с большей уверенностью за счет репутации. Если хотят в 2 раза больше заявок - заявок — то следующий шаг: почему их станет больше: кто-то услышит и придет или порекомендует - порекомендует — это определяет площадки и содержание. А если публичность - публичность — для привлечения и удержания сотрудников - сотрудников — то это другие публикации и выступления, на других площадках.
Еще пример. Компания ставит задачу на то, чтобы стандарты качества были одинаково высокие.
# Как поймем, что пришли? Метрики качества? Или возможность показать в продажах? Или отсутствие инцидентов? # Субъекты. Например, новый сотрудник перепроверяет по чек-листу - листу — чтобы выработать привычку - привычку — это гипотеза. # Задача - Задача — обучить на онбординге. И появляется логика: HR обучает не потому, что заставили, а для такой цели, и это - это — мерять можно.
Когда есть гипотезы - гипотезы — ставим приоритеты. Есть RICE и другие методы. Делают по-разному, где-то ставит генеральный, а где-то - то — голосование звездочками.
А дальше приоритизированные задачи - задачи — в дорожную карту, это уже техника. Но дальше на нее смотрим, и, может, меняем.
Результаты наличия стратегии.
* Мотивация
* Приоритеты
* Перестают конфликтовать, даже собственники - собственники — рисуют что важно* Задачи нельзя взять и сделать - сделать — надо приземлить на веточки. Если не приземляется - приземляется — можно порисовать веточки. А если не рисуется - рисуется — да, супер-круто, но не понятно зачем, надо придумать. Очень хорошо отрезвляет фантазеров.
'''Критерий хорошей стратегии: когда джун берет задачу и думает "зачем «зачем мы это делаем" - делаем» — он может увидеть ответ за 15 минут понять его.'''
Дальше в презентации ссылка на доп.материалы: топология, примеры карт, ошибки, официальная группа карты гипотез. Александр развивает метод, можно познакомиться и использовать, можно обучиться и стать тренером. Метод построен как дальнейшее развитие impact map, просто дополнений накопилось настолько много, что получилась уже отдельная конструкция. Выложил в open source? сделал коммьюнити.
В ответах на вопросы обсуждали ситуацию больших корпораций при инициативе снизу. Там до топов часто нельзя дойти, и это надо как-то решать, налаживать контакт.
Важно: в стратегии гипотезы, и по дороге может произойти что угодно. Можем не дойти. Тут проблема у госов: если закоммитился на результат - результат — он же должен быть. Нужно заранее проговаривать: если потыкались и не получается - получается — то кто-то должен осмыслить, персонально - персонально — и принять решение всех собрать.
== Антон Бочкарев. Взлом мозга, основы социальной инженерии ==
Это доклад не про менеджмент, а он про то, как работают телефонные мошенники. И тут интересен материал. Мошенники в России массово работают с территории Украины, это было еще до эпохи СВО. Есть данные, что в Днепропетровской области до 3030 % трудоспособного населения работали в call-центрах, и там это продуманная технология. Когда в начале СВО заняли Бердянск, то персонал call-центра убежал, а сервера - сервера — остались, и в докладе были результаты анализа их скриптов и данных по созвонам. Также были результаты анализа по кейсам поджогов, которые были недавно. И собственный опыт - опыт — Антон по заказу компаний проверяет устойчивость их к различным атакам, используя скрипты, аналогичные используемым злоумышленниками.
Все это - это — предельные случаи, но механизмы, которые при этом используются - используются — совершенно общие, их используют и при промышленном шпионаже, атаках на компании. 4343 % атак на организации и 9090 % атак на частных лиц идет не через уязвимости софта, а через социальную инженерию, основанную на багах нашего мозга.
Барьером на этом пути служит критическое мышление и оценка ситуации. Фишка в том, что когда мы в стрессе, то механизмы мозга сами отключают функции критического мышления и анализа. Именно поэтому сколько бы людям в компаниях не объясняли, что нельзя переходить по ссылкам в письмах, устанавливать софт и так далее, всегда 77 % это делают просто потому, что они решили разобрать почту в момент стресса, связанного с посторонними рабочими или семейными обстоятельствами, и это делал их некритический автопилот. Так что просто надо атаковать массово.
А еще во многих ситуациях человек продолжает делать привычное. Мы сменили место работы, а автопилот ведет на старое. Уважительное отношение к коллегам предполагает, что если человек просит - просит — у него есть причины, надо выполнить просьбу. Был эксперимент с очередью к ксероксу: если человек просил пропустить, потому что "надо «надо срочно и всего пару листов"листов», то пропускали в 9494 %, а если просил просто фразой "мне «мне надо скопировать документы" - документы» — то в 9393 %, то есть люди не анализируют основания.
Механизмы известны, можно почитать Психологию влияния Чалдини и другие книги. На них же основан маркетинг и политтехнологии, и ими же пользуются мошенники. И я хочу отметить, что, возможно, именно из-за их использовании в маркетинге и политтехнологиях, в школьное образование не включено создание барьеров против такого влияния, потому как методики-то тоже известны.
С мошенничеством связано много мифов. Первый - Первый — то что жертвами прежде всего становятся пожилые. Просто пожилых - пожилых — жалко, поэтому СМИ шире освящают именно эти случаи. Статистика по обращению в полицию говорит, что основная масса жертв - жертв — от 18 до 54. И статистика call-центра Бердянска тоже говорит, что целевой аудиторией были молодые, от 20 до 40 лет. Там - Там — вполне промышленные масштабы, 100к звонков ежедневно, конверсия по переводам денег 1-22 %.
Про малообразованных людей - людей — тоже миф. Это много исследовали, и выяснили, что между когнитивными способностями и вероятностью стать жертвой мошенника нет корреляции. Поджигательницы в Татарстане: студентка, кандидат наук, самозанятая, пациентка психдиспансера. Отчасти это ложная самоуверенность, есть статистика, что опытные водители попадают в аварии чаще, а опытные пловцы тонут чаще неопытных. А отчасти - отчасти — у них в силу работы обычно перегруз информационным потоком больше, и, соответственно, автопилот включен чаще.
Проще всего человека загнать в стереотипное поведение через перегруз. Эмоциональный - Эмоциональный — через страх или эйфорию, или сенсорно, создать обстановку, когда много сигналов. При этом страх поддерживать легче - легче — работают через него.
Из 7 факторов Чалдини обычно подключаются факторы авторитета, дефицита и последовательности. Авторитета - Авторитета — через должности звонящего, через экспертность - экспертность — там специально в скриптах сложные формулировки, призванные показать ложный профессионализм. Дефицит - Дефицит — страх потерять, говорят, что вас уже взломали, а мы защищаем, реже - реже — желание получить бесплатно, выиграть приз. Если на фуршете из одной тарелки взять несколько бутербродов - бутербродов — будут разбирать с нее, даже если рядом стоит такая же.
А последовательность - последовательность — через постепенный переход от безопасных действий и ответов к опасным. Исторически в обществе последовательность - последовательность — приветствуется, даже если потом оказываешься неправ. Признать ошибку, отступить назад - назад — сложно. На ипподроме вопрос о клубе до ставки и после - после — возрастает. Был интересный эксперимент: на открытый тренинг с "таблеткой «таблеткой от всего" всего» пришли исследователи и в конце начали рационально опровергать то, что впаривали. Парадокс в том. что такое действие увеличивает продажи: люди пришли уже подготовленные купить, разогретые, а жесткое опровержение создало впечатление, что могут запретить. И мошенники стали этим просто пользоваться через подсадных людей.
Эксперимент с пожертвованием на онкологию. Если людей сначала попросить поносить недельку значок "я «я против онкологии"онкологии», а при возврате предложить сделать пожертвование - пожертвование — то жертвуют больше, чем если просят просят сделать пожертвование. В Шатах был эксперимент - эксперимент — просили разрешение поставить перед домом уродливую штуку с призывом к безопасному вождению. А других сначала просили подписать бумагу с призывом к безопасному вождению, а только потом - потом — поставить штуку. Во втором случае процент больше, люди хотят быть последовательными. Оценка шансов на успех лошади на ипподроме меняется после того, как человек сделал ставку.
Не просят перевести все деньги, сначала безопасное действие, потом просят помочь немного, потом чуть больше. Мы звоним из банка, у вас карту не украли, паспорт не украли. Затем - Затем — контактные данные, проверить мобильное приложение. А потом - потом — поставьте приложение, дайте доступ и так далее. Чем больше маленьких шагов - шагов — тем больше вероятность.
Люди, которые поджигали, до этого висели на трубке по 3-4 часа, переводили деньги, их к этому вели последовательно, маленькими шагами, не объясняя следующий шаг. Не Не было "надо «надо поджечь, для этого сделайте смесь"смесь», было "купите «купите это и это, смешайте, отвезите туда, быстро бросьте"бросьте», очередной шаг выдавали после выполнения предыдущего и держали в напряжении. Объяснения - Объяснения — нелогичные, "в «в здании преступник, его надо срочно арестовать"арестовать», с предыдущими объяснениями это не связано.
Еще есть техника двойного касания, когда первый звонок максимально безопасен. Когда он исследовал безопасность компаний, то была техника. Первый звонок - звонок — от имени техподдержки провайдера, все ли в порядке с инетом, а то мы видим сбои. Отвечали, что все хорошо 0- и все. Через пару часов звонил повторно, говорил, что "мы «мы видим сбои" - сбои» — и у человека ощущение, что звонит знакомый специалист, и человек делает все, что скажут. При этом надо обходить триггеры, всех учат "не «не сообщать пароль"пароль», поэтому он говорил "надо «надо сменить пароль, я пришлю ссылку, перейдите, сгенерите пароль" - пароль» — ссылка вела на его ресурс, он получал данные.
Полноценно нельзя защититься - защититься — мозг не патчится. Но на старте можно научиться прерывать контакт:
* не брать непонятные звонки
* не быть мягким, добрым, не вовлекаться - вовлекаться — человеколюбие эксплуатируемое. Если звонок вгоняет в стресс - стресс — не бояться бросать трубки и хамить* при сомнении, зафиксировав давление - давление — бросаем трубку на 10 минут, что бы вам не говорили. Выйти из стресса, включить анализ.* Если родным звонят и они остекленели - остекленели — отберите телефон, они не будут ничего слушать в этом состоянии, надо прервать контакт.* Можно вырабатывать триггеры у себя - себя — чтобы на старте понять, что происходит не то.
Еще работают блокировки, которые снимаются только на следующий день так, что нужна пауза. Еще лучше, чтобы был нужен визит в банк, но тут уже страдает удобство.
При этом атаки - атаки — не целевые, а массовые. Звонок от имени начальника или знакомого - знакомого — тоже автоматизировано, скриптами и массово. Целевые атаки начинаются с очень высокого уровня владельцев и топов крупных фирм и корпораций, на котором служба безопасности всерьез работает, и это - это — другая история. С подменой номеров бороться начали давно, подмена на коротки и городские - городские — забанена уже несколько лет, а вот подмену на сотовые технически тяжело закрыть при соучастниках-админах, которые держат оборудование.
Идеи, что нельзя отдавать свой голос - голос — это все мифы и испуг. Конечно Конечно, нейросеть сейчас может синтезировать голос. Но атаки "мама «мама я попал в аварию" аварию» были 15 лет назад, когда этого не было, а родственники уверенно отвечали, что был правильный голос - голос — потому что стресс, короткая фраза, потом трубку брал другой человек.
==Евгений Антонов из Яндекса. Всё, что вы хотели знать о демотивации, но боялись спросить ==
Много разговоров про мотивацию, но очень мало - мало — про демотивацию. А демотивации вокруг - вокруг — очень много. От нее - нее — ущерб.
Что такое - такое — демотивация?
* Отсутствие желания делать рутинную работу, не требующую особых затрат.
* Отсутствие вдохновения делать или придумывать новое
* Негативное отношение к коллегам и работе - работе — все не так.
* Общее ощущение несчастья, апатии, бессмысленности. В воскресенье расстраиваться, что завтра в понедельник.
В отличие от выгорания, демотивация идет на фоне ярких эмоций. При выгорании на эмоции уже нет сил, она на фоне усталости.
Есть теория двухфакторной мотивации по Герцбергу: гигиенические и мотивационные факторы, необходимы плюсы в мотивации и отсутствие провалов в гигиене. Бывает, что в гигиене хорошо, но мотивации - мотивации — нет.
Он по аналогии сделал двухфакторная демотивация по Антонову. * Внешние факторы: обман, непрозрачность, неуважение, деньги - деньги — ими можно управлять* Внутренние факторы - факторы — это только косвенно, мы - мы — не психологи.
Внешние факторы
* Обман - Обман — обещали и не дали. Премию, прибавку к зарплате, отпуск. * Давление: "выходи «выходи в выходной, а то..."то…», или "ты «ты такой молодец, возьми еще проектик"проектик»
* Не уважение. На ревью обесценивать, доказывать, что не специалист.
* Чувство несправедливости. Абсолютной справедливости нет, но двойные стандарты, например, когда ему можно пораньше с работы, а тебе - нет - тебе — нет — явно демотивируют. Понятно, что люди - люди — разные и бывают всякие ситуации, и тут важна прозрачность, явное объяснение причин.
* Недоверие к человеку, особенно публичное.
* Отсутствие цели, позиция "выполняй «выполняй и не спрашивай, для чего"чего». * Деньги, зарплата и премии - премии — тут много разных историй.
Внутренние факторы. * синдром отличника, синдром самозванца - самозванца — тут может помочь обратная связь, но без гарантий.* Не умение рассчитывать силы и время, все время надеются на лучшее, а потом - потом — еще и есть себя: я плохой, не сделал, что обещал, и спираль раскручивается.
* Личные проблемы могут сильно снижать продуктивность, при этом человек может молчать. Тут нужен доверительный разговор, ситуация может быть временной, может, надо помочь.
Конкретные истории.
* Обещания. Сначала договорился с компанией о прибавке через полгода, а потом они передумали. Дальше человек получает офер - офер — и ему делают контрофер. По сути - сути — двойной обман. По ситуации он может и согласиться, но отношение к работе будет иное. * Мальчик кричал ASAP. Менеджер придумывал важные и срочные проекты, а оказывалось, что это работа в стол. Хотя бывает, что это - это — не в стол, а в портфолио менеджера. * Нерадивый товарищ. Я месяц нифига не делаю - делаю — а я знаю, я за двоих делаю.* Big angry boss. Много примеров компаний, когда на людей кричат и до слез доводят. Печально и тому, кого доводят, и тем кто доводит, просто потом - потом — люди уходят и пишут истории, репутация компании страдает.* Ложная риторика "мы «мы все семья"семья». Классическая семья предполагает, что "если «если еды лишь на троих - троих — каждый будет есть меньше"меньше», а в корпоративной "раз «раз еды на троих - троих — ты не наша дочь"дочь». Ситуации с премиями и сокращениями. * Человек собирался, попросил отпускные, не дали, он поскреб все что было. Вернулся - Вернулся — попросил. Руководитель сказал "письмо «письмо напиши, будет непрочитанным - непрочитанным — я вспомню"вспомню», и два месяца непрочитанным. В компании появился мем.
Если люди расстраиваются и забивают на работу - работу — компания теряет миллионы. Он видел команду, которая специально имитирует работу: им на нас наплевать, а нам - нам — на них.
Демотивация распространяется между людьми и командами - командами — это заразно.
Как распознать демотивацию.
* Игнорирование. Договорились - Договорились — и никто не делает* Агрессия * Итальянская забастовка. Сделаю все как просил - просил — но так, что получается фигня* Постоянные отмазки - отмазки — ни одну задачу до конца не доносят, ссылаясь на внешние причины* Нежелание принимать решение и нести ответственность, гробовая тишина на призыв предложить. - — потому как странное распределение работ, риски ошибиться
* Непризнание причастности к проекту и команде. Не мы, а вы, я вне команды.
Тут важны не только обсуждения, но и опросы: 1:1, общие, анонимные, публичные...публичные…
Что делать, если не уследили?
* Откровенно поговорить. Тема капитанская - капитанская — но не говорят. Стремно.
* Обозначить конкретные шаги и сроки
* Держать в рсе о прогрессе и результатах. Даже если не получается. * Разогнать всех к чертовой матери. Плохой. Но расформирование команды иногда лечит.
Важно думать о мотивации, но не менее важно думать о демотивации.
Делайте хорошо, а плохо - плохо — не делайте!
Что делать, если ты в демотивированной команде
* Обсудить с коллегами - коллегами — может, это только у меня неправильно* Обсудить с руководителем 1:1 - 1 — вот проблемы, что делать будем* Собственный список плюсов и минусов: может, уходить пора, а не бороться*
== Алексей Цыбульник. Предупреждён — Предупреждён — значит вооружён. Что следует ожидать ИТ сотрудникам от эволюционных изменений ==
Различают два типа изменений
* структурные - структурные — меняются наши отношения с другими людьми, наша идентичность* нормативные - нормативные — меняется способ работы или инструменты, идентичность сохраняется.Нормативные - Нормативные — легче. Понятно, что грань - грань — не очевидна, но важен режим эксперимента и возможность отката назад.
В Agile два самых известных метода - метода — Scrum и Kanban. Scrum - Scrum — это структурные изменения, революцию. Ты не тестировщик, мы все - все — равная команда. А Kanban - Kanban — эволюция, он начинается с нормативных изменений. С структурные - структурные — не сразу, и только если выяснится необходимость. Канбан-метод никогда не даст процесс "как надо" - «как надо» — он поможет подстроить ваш процесс.
Принципы перехода на Kanban это поддерживают.
# Начинаем с того, что есть сейчас - сейчас — вы как-то работаете. Насколько вы понимаете, насколько понимают новые - новые — изучаем. Непонятки - Непонятки — выясняем. Уважаем сложившиеся практики, организационную модель, ролевую структуру.# Поощряем проявления лидерства на всех уровнях. От рядовых до топов. Озвучивание проблемы - проблемы — тоже шаг лидерства. Не наказываем за формулирование проблем, за инициативы. Здесь есть хорошая книга: Дэвид Марке "Разверните «Разверните ваш корабль"корабль».# Договоритесь об эволюционных инструментов. Мы не выбрасываем старое, мы берем новый инструмент и его пробуем. И только потом решаем: использовать или нет. Предложение попробовать - попробовать — безопаснее, чем предложение перестроить работу.
Дальше был рассказ про Kanban STATIK, но с необычной точки зрения: что каждый из шагов дает команде.
: 1. Предзназначение - Предзназначение — общее пониание всех участников. И я, как член команды - команды — получаю понимание зачем я работаю. И узнав это - это — я могу выработать отношение к этому.: 2. Источники неудовлетворенности, внутренние и внешние. Это отрезвляет менеджмент, и дает ему информацию о неудовлетворенностях. Накидали кучу проблем - проблем — а они сохраняются, действия не делают. Значит есть какие-то причины.
: 3 и 4. Анализ запросов и возможностей. Дает знание, что мы делаем и для кого. Тип запросов, сколько времени занимает работа по каждому. Сколько мы можем поставить.
: 5. Изучаем и описываем, как работа проходит по вашей системе. Мы понимаем, как на самом деле устроена наша работа ,какие у нас есть критерии готовности, поставки и вытягивания. :: Тут было отступление: работа как процесс накопления знаний. Разработка, измерение улучшений, подтверждение клиентом. Как задача в школе: прочитали условие - условие — начали писать и решать - решать — сделали решение готовым. Решая, могли забыть по дороге, но сделанные знания - знания — не исчезают. Даже если пошли другим путем - путем — опыт предыдущего все равно есть. Нет возврата.: 6. Формализируйте классы обслуживания. Архетипы стоимости задержки - задержки — 4 класса: линейный равномерный - равномерный — чем быстрее тем лучше потери, фиксированная дата (к празднику), S-кривая; 0 (когда-нибудь будет плохо). Зачем это надо знать? Чтобы разумно организовывать работу.: 7. Визуализация и базовые правила. Явные договоренности о действиях и решениях, чек листы. WIP-лимит - лимит — пример такого правила.
==Лев Ушаков. Управление состояниями команды для решения творческих задач ==
Подача доклада - доклада — крутая. Сначала - Сначала — движуха, чтобы получить активность и вовлеченность. Самооценка - Самооценка — состояние, активность, энергия - энергия — разными жестами, 5 баллов, 10, высота. Перекидывание мандаринов после контакта взглядом. В аудитории - аудитории — контакт, чувство безопасности, настроение.
3 системы: человек - команда - человек — команда — компания, в креативной экономике.
Состояние человека: физическое + психоэмоциональное + когнитивное + свойства личности. Плюс внешняя среда. Когда заходит топ - топ — как реагируют люди в комнате. Есть ли безопасность и возможность ошибаться, говорить что думаю и так далее.
Разработчики, дизайнеры, ученые - ученые — у всех может быть творческий кризис. Остановка движения.
Творческие инсайты случаются при отвлечении. Прогуляться, пожонглировать. Иногда хватает пары минут - минут — недолго. Важно, чтобы не было переключения с фокусом.
Пирамида: состояние - мышление - действия - состояние — мышление — действия — результат.
Вирус в человеке. Он появляется, температура поднимается - поднимается — а потом иммунитет борется и в следующий раз быстро подавляет. В удачном сценарии. Вирус не-адаптивное поведение.
Художник в среде разработчиков, менеджеров - менеджеров — может стимулировать креативность. И иногда такое не-адаптивное дают внутри.
Транзакт-анализ: родитель - взрослый - родитель — взрослый — ребенок.* Ребенок - Ребенок — радость, креатив.* Родитель - Родитель — контроль, знает как надо, традиции.* Взрослый - Взрослый — посредник между ними.
Расширение модели: контролирующий родитель - родитель — заботливый родитель и адаптивное дитя - дитя — естественное дитя. У всех свои особенности. Адаптивное дитя - дитя — часто подавленная энергия. Естественное дитя - дитя — берегов нет.
Этапы решения * Взрослый: ключевые вопросы, формулирование задачи. * Естественное дитя - дитя — генерация идей, дивергентное мышление. Заботливый родитель останавливает, когда достаточно, мягко не обломать
* Дальше надо выбрать 1-2 варианта, конвергентное мышление. Это взрослый.
* И так далее.
* Презентовать заказчику можно в разных состояниях - состояниях — зависит от ситуации.
Это показывает, что важно своими состояниями управлять.
Динамика между тактами работы
* выдох: расслабление, празднование, ассимиляция. снять усталость.
* пауза: быть в контакте, кто я и куда идем...идем…
* вдох: вдохновение на новые победы.
Сессия, встреча в усталом состоянии - состоянии — бесполезна.
Начинать надо с себя. И с команды - команды — чтобы среда была привлекательна топ-специалистам. Смузи - Смузи — уже не привлекает.
== Елена Колесникова. Развитие команды через командный коучинг ==
Командный коучинг - коучинг — одна из техник, которую они предоставляют другим командам. За два года через него прошли 15 команд: разработчики, продажи и другие. И каждый раз это работа по конкретному запросу.
* Нужно научиться решать конфликты в команде
* Нет общей цели, непонятно куда идем
* Разобраться с тем, что не умеем быстро внедрять изменения.
Рассказ был на конкретном кейсе ее собственной команды. Они на очередной рефлексии поняли, что нет цели команды вдолгую. И что по конкретным задачам, например, организации обучения, неясна ценность для бизнеса: вроде, если его не проводить - проводить — ничего страшного не будет, так может, и вообще ценности нет?
Тут особенность в том, что в компании еть OKR, но цели каскадируются только на бизнес-направления, а их подразделение - подразделение — вне этой системы.
Техника решения - решения — через пирамиду Дилтса: окружение - поведение - способности - убеждения - идентичность - окружение — поведение — способности — убеждения — идентичность — видение.
Нижние уровни прошли быстро, а вот на уровни убеждений, помимо общего, проявились разные установки. С тем, что не всем нужно обучение в моменте и тем, что компания вкладывается в сотрудников - сотрудников — все согласны. А вот по поводу того, кого нужно обучать есть разные мнения: одни полагают, что только по явному запросу бизнеса, а другие - другие — что надо помогать каждому, если есть запрос. И тут было нетривиальное решение: принять различие ценностей, а не пытаться всех выровнять. Это - Это — уважение права человека на свои убеждения.
Дальше были уровни идентичности - идентичности — кто мы, и видения - видения — для чего работаем. Тут открыли много нового. Но получили согласованные формулировки. Они были в презентации, они длинные и достаточно общие, и смысл не в тексте, а в том, что они - они — продукт понимания каждого человека в команде, в процессе согласования они были интериоризированы каждым.
А потом вернулись к ценностям, взяли объединяющее, учли идентичность и видение - видение — и сформулировали 7 штук, они тоже есть в презентации. Там достаточно подробные формулировки, но смысл, опять-таки, в совместном обсуждении.
И дальше - дальше — миссия. Каждый сам формулировал, потом делали объединенную. Для миссии - миссии — снова прошли пирамиду Дилтса через 5 лет, но такой, как она будет через 5 лет. И тут как раз уровень окружения становится не очевидным: какой через 5 лет будет компания, сколько сотрудников и какие они. Ведь очевидно, что придет молодежь, которая как-то будет отличаться от нынешней, и надо понять - понять — что важно. И новые технологии - технологии — они тоже изменят компанию за это время.
У них получилось сформулировать цель, из нее - нее — четыре направления развития и дальше - дальше — задачи, которые можно начинать решать уже сейчас.
Коучинг завершился, проблема решена. Что получили.
* Синхронизация по ценностям
* Члены команды стали проявлять инициативу и предлагать идеи развития - развития — раньше это делала она как лидер. Там много* При составлении ИПР ориентируемся на общую цель и навыки из пирамиды
* Проще расставлять приоритеты
А регулярные встречи они оставили - оставили — для общей работы над развитием технологий работы подразделения.
В общем, такая история. Она интересна, но лично для меня - меня — относительно очевидная. Было бы интереснее услышать в докладе не одну историю, а некоторый обобщенный опыт по применению инструмента, иллюстрированный, естественно, конкретными кейсами. Все-таки, было 15 штук, это достаточно много.
В конце были рекомендации, но они - они — общего характера, понятные: коучинг - коучинг — для сложных задач, требующих коллективного мышления, не для операционки. Он требует доверия в команде, достаточной зрелости. И имеет смысл только для долговременных команд.
= Технические доклады =
На конференции их - их — абсолютное большинство, просто мои интересы больлше в области менеджмента. Поэтому выборка - выборка — не репрезентативна.
== Вадим Царегородцев из Островка. Вперёд в прошлое! Или как подружить чистую архитектуру и RSC ==
Если кратко, то старый подход можно описать формулой ui = f(state). При этом state размазан между фронтом, бэком и базой данных и идет бесконечная синхронизация между ними. Серверные компоненты позволяют поменять формулу на ui = f(data)(state), при этом данные всегда достаем из базы с любого уровня, это убирает потребность синхронизации. И получается проще.
Детали надо смотреть в выступлении, там было много технических деталей, в которых я, увы, плаваю, потому как на react не разрабатывал... разрабатывал…
== Кирилл Святов. Архитектура систем управления наземными высокоавтоматизированными транспортными средствами ==
Когда говорят про беспилотный транспорт в России, то все вспоминают Яндекс и КАМАЗы, которых не так много. Но еще есть грузовики, которые уже активно работают на складских и промышленных предприятиях. без выезда на дороги общего пользования. Я об этом слышал несколько докладов на других конференциях. А Кирилл говорил о беспилотниках для сельского хозяйства.
Там много особенностей. Во-первых, рассчитывать на разработку принципиально новой беспилотной техники - техники — не реалистично. Вместо этого на существующие УАЗ и Газели устанавливают дополнительное оборудование, превращая их в беспилотники. Во-вторых, там большое разнообразие задач с разным дополнительным оборудованием - оборудованием — транспорт, разбрызгивание удобрений и химикатов, другое навесное оборудование. И движение не по дорогам, а в полях, с разными условиями. Профит - Профит — в том, что автопилоту не нужна защита от химикатов, а еще он не устает, и в подходящих погодных условиях может работать круглосуточно.
Но при этом, в отличие от других проектов, есть потребность создавать не одну программу управления беспилотником, а много разных, с учетом многообразия выполняемых задач. И они делают платформу. которая позволит создавать такие программы не с нуля, а на основе готовых компонентов.
Платформа включает следующее.
* Устройства для переоборудования техники под беспилотники, элементы для переоборудование конкретных узлов - узлов — рулевое управление, педали
* Типовые системы управления
* Карты. Глобальные, на них путь. И высокоточные локальные: что видит сейчас и что видел в прошлый раз в этом месте. Редакторов карт не более 5 в мире, карты сильно сильно платные, а редакторы вообще не дают.
* Движки. Есть Apollo drive и Autovei, но они оба ориентированы на городскую среду.
* Архитектурные программные шаблоны
* Инструменты для настройки оборудования: лидар (128 лучей, 11 герц, 120к точек * 11 в секунду), камера (блики, освещенность, серые, обычные и стерео - стерео — они дальность определяют), и то и другое надо калибровать. При этом лидары - лидары — дорогие, камеры - камеры — сильно дешевле, и у них разные плюсы и минусы, может требоваться совместное использование.
* Платформа для симуляции, чтобы вести отладку не только в реальных условиях. Платформ есть несколько, основной дефакто CARLA, но он дорог и ориентирован на городскую среду, поэтому они взяли за основу другой симулятор.
Построено все это на базе ROS-2 - 2 — операционная система роботов, на базовом уровне поддержана передача данных от сенсоров, и модели передачи между процессами. Все на питоне, пока производительности хватает, если будут проблемы - проблемы — перепишут часть на С. Контроллер транспортного средства связывается всегда с 2 видами исполнителей: реальный автомобиль и симулятор для отладки. В презентации была довольно большой компонентная архитектура системы управления.
* Разворот вида вперед на вид сверху. Матрица гомографии, специально надо получать с учетом расположения камеры. Получается локальная карта. Лидар может уточнить дальность.
* Дальше модуль поведенческого анализа - анализа — предсказание движущихся объектов. Беспилотник должен предсказывать на время до остановки. И максимальная скорость - скорость — скорость обработки кадров и достоверность предсказания.
* Дальше планировщик пути, разные алгоритмы для простой и для сложной траектории с разворотами. Здесь же ограничения правил движения
* Управление транспортным средством
Есть инструментарий для разработки воркеров, включая редактор карт. И конфигуратор - конфигуратор — переключение состояний, в каждом - каждом — свой набор воркеров. Разработаны виртуальные перегоны в беспилотниках.
Для безопасности, помимо внутри еть несколько независимых систем систем: две стоп-кнопки, независимая от основного контура управления система обнаружения препятствий и остановки перед ними, и автономная система внутри системы управления, оценивающая достоверность оценки обстановки и тоже останавливающая.
Это все уже работает, в презентации были видео и там реальные поездки, не только симуляции. Вся обработка - обработка — на борту, информации от сенсоров столько, что никакого инета не хватит. Для 20 км/ч хватает производительности мощного ноута с GPU. Для 120 км/ч - ч — уже нужен кластер. Но для сельхозтехники скорость не нужна.
К симулятору есть доступ из web - web — докер-контейнер с симуляторов, visual-studio и ти т.п п., так что можно проводить соревнования для школьников и других интересующихся.
== Виталий Киреев из SpaceWeb JSON-RPC 2.0 как альтернатива REST API. Почему стоит использовать его? ==
Первая мысль - мысль — использовать rest ful api. Но! Реализация через стандартные библиотеки, например, python FastAPI, предполагает разработку специальных оберток. Методов взаимодействия - взаимодействия — много, объектов - объектов — много, и это ведет к большому количеству времени. Кроме того, при всяком изменении реализации надо изменять и обертку.
Json-rpc позволяет выставлять реализацию без отдельных оберток, при этом можно выставить все публичные методы класса. И это экономит время реализации, а также поддержки: изменение класса, добавление новых методов автоматом меняет API.
Кроме того, из коробки есть возможность изменения протокола - протокола — можно перейти от http на imqb через rabbit mq или аналоги. Это сразу дает возможность асинхронного взаимодействия, где оно уместно. В частности, нотификации вообще не ожидают отклика, а они встречаются часто. Также из коробки есть возможность передать пачку запросов, ответ потом придет индивидуально. Реализация REST таких возможностей не предоставляет.
Ускорение разработки для json-rpc получилось примерно вдвое по сравнению с RESTful на fastAPI и вчетверо по сравнению с django, добавление новых функций - функций — в два раза, unit-тесты - тесты — в полтора. А ускорение взаимодействия, уменьшение расходов на транспорт за счет смены протокола получилось примерно вдвое, и это - это — существенно.
В презентации были примеры кода реализации разных вызовов. При этом ничто не мешает при реализации классов, используемых в качестве API, придерживаться принципов REST. То есть разница именно техническая, а не в принципах реализации.
В rpc в запросе обязательно передается уникальный ключ запроса, и это позволяет обеспечить идемпотентность из коробки. Кроме того, передается версия, и есть возможность сохранять обратную совместимость через этот механизм.
Плюсы использования rpc.
* разделяем код по уровням
* не надо менять слой rpc при изменении логики
* можно покркыть тестами каждый уровень
* можно настроить мониторинг каждого слоя
* прозрачность, осутствие оберток
* уникальный идентификатор запроса дает идемпотентность из коробки и эффективное логирование.
* версия в запросе дает версионирование клиентов и api.
Но есть ложка дегтя. Или даже бочка. Связанная с тем, что это - это — не mainstream. Своя спецификация api, нет инструментов типа swagger и слабее комьюнити.
Спецификацию можно писать на Yaml, по ней есть генератор документации, но было много ошибок. Поэтому они написали свой генератор и свободно отдают его код, в докладе - докладе — ссылка на github.
По спецификации есть генератор на typescript для фронта, а для бэка им пришлось писать самим, они сделали для python, php, на подходе для node.js - js — тоже отдают.
Не взирая на эту бочку дегтя и на то, что api для клиентов оказалось не привычным rest, преимущества клиенты оценили: число клиентов, использующих api увеличилось в 3 раза.
Кроме json-rpc есть еще grpc от google. Они выбирали в 2017, тогда с ним были проблемы. Сейчас он доведен, и для новых проектов - проектов — хорош. А для legacy все равно бывают проблемы.
== Сергей Сахаров. Laravelize It! Или второе дыхание Legacy ==
Специфика legacy-проектов (php).
* Отсутствие договоренностей, слоистая структура разных стилей и подходов
* Проблемы архитектуры - архитектуры — смешение подходов в одном проекте. Одно через action, другое - другое — через один контроллер (30к строк!)
* От кода исходит дурной запах (Роберт Мартин)
* Дубли и повторы в коде
И усугубляется это подходом "фреймворки - «фреймворки — зло, лучше напишем сами"сами», так считают многие.
Отношение к этому может быть разное. * Классика-1: проблемы нет, все же работает. инет-магазин на ucms, а api - api — свое на switch-case * Классика-2: перепишем все с нуля. Это невозможно, даже если дописывают - дописывают — новый комок, который потом выбросят* Удушающее приложение - приложение — параллельно на новом стеке. strangler app - app — в принципе есть, но это вариант все переписать
* Выкинуть нельзя, поддерживать и улучшать по-возможности.
* Всех заинтересованных собрать для выработки соглашений по разработке и архитектуре
* Статические анализаторы соблюдения договоренностей
* Планы рефакторинга - рефакторинга — проблемы и боли* Использование инфраструктурных решений от популярных фреймворков - фреймворков — symphony, laravel, laminas и ти т.д д. Работа с БД, очереди, кэш
Дальше была история, как он для своего продукта делал валидаторы. Для начала он поискал, чтобы использовать: может, оно уже есть, стандартная же задача. Не обнаружил. Пошел в основную команду разработчики, там сказали "да«да-да, мы как раз собирались делать, давай ты и сделаешь для всех, а не только для себя"себя».
Требования понятны: от широко используемого фреймворка, большое количество готовых правил из коробки, возможность дописать специфичные правила, простота использования.
Варианты: illuminate/validation laravel, symphony/validator; laminas-validator. Посмотрел их. Выбрал знакомое. Реализовал, там был рассказ, особых проблем не было.
Есть проблема: фреймворки обычно не рассчитаны на автономное использование. Поэтому одна библиотека валидации тянет полфреймворка, почти 40 компонентов. В symphony n laminas с этим полегче, но десяток все равно тянется. Но конкретно для них проблемой не было, так как компоненты laravel в проекте уже использовались. А так на это стоит обращать внимание.
==Алексей Романов. Неудобные вопросы про RESTful или как проектировать API, чтобы не было так стыдно ==
Рассказ о концепциях RESTful и о разработке API с соблюдением этих принципов. Казалось бы, капитан очевидность. Если бы не множество примеров, как делают api без их соблюдения, которые былри в докладе. И тут есть не только технический аспект: используя api или разбираясь в коде, люди предполагают, что принципы соблюдаются, поэтому отступление от них усложняет использование.
А с api есть сложность: вам часто надо поддерживать обратную совместимость. Так что если вы сделали плохо, потом переделали хорошо и красиво, старый вариант все равно остается. Доклад - Доклад — для того, чтобы сразу делать красиво.
Концепция RESTful:
* Сервер работает с ресурсами. Ресурс - Ресурс — это информация, сущность, их хранит сервер. У ресурса есть идентификатор.
* Клиент работает с представлением этих ресурсов
* Типы запросов
** Определение ресурсов
** Управление ресурсами
* stateless обработка сообщений - сообщений — в них идет полная информация, включая пользователя и контексте сессии в заголовке
Отличие от rpc в том, что там вы можете вызывать произвольный код. И можно создать смешанное api, например, упаковав создание нескольких сущностей или действие над ними в один вызов.
Я хочу отметить, что в целом разница между RESTful и rpc - rpc — это разница объектным и процедурном подходами, примененными к api. Но, помимо концептуальной разницы есть техническая: RESTful предполагает http и синхронное взаимодействие, а у rpc таких ограничений нет. И потому может быть целесообразно использовать rpc, сохраняя при этом принципы RESTful при реализации классов и процедур, к которым предоставляется доступ. И еще я хочу отметить, что те, кто придумывали RESTful перенесли на него шаблон создания сущности с генерацией ключа на стороне сервера. Это уместно и удобно при работе с базой данных, когда у вас есть сессия и транзакции, а вот при взаимодействии при отсутствии транзакций и отсутствия гарантий доставки это - это — неудобно, так как не дает идемпотентного создания ресурсов. Спецификации типа Json-rpc решают эту проблему. Вообще сравнение RESTful и Json-rpc было в другом докладе.
Впрочем, создание сущностей можно делать через put, а не post, и тогда создавать ключ на стороне клиента. Вообще, общий принцип: put и patch - patch — идемпотентны, post - post — нет, а get - get — лишь запрашивает данные, поэтому его можно кешировать - кешировать — в отличие от других запросов. Важный принцип - принцип — uri ссылается на ресурс, а не на действие.
Дальше пересказывать доклад я не буду, смотрите презентацию. Потому что основная суть - суть — не в описании протокола, который всем известен, а в паттернах и антипаттернах применения, которые были на слайдах. И их надо смотреть.
Использование может быть в двух режимах.
* Code first - first — сначала разработчики создают код, по нему порождается open api * Contract first - first — сначала open api. Сначала согласуют, а потом дают разработчикам. Разработчики закодируют не так - так — но есть генератор, который сделает ровно то, что нужно.
Согласование спецификации до кодирования важно: иначе можно сделать api, которое не пригодно пользователям для их целей.
== Екатерина Неделина и Ян Шишеня из Газпром Нефть. Новые «люди»: как ИИ-сотрудники меняют бизнес-ландшафт ==
Пока теоретики спорят о то, что ChatGPT может, а что - что — нет, практики делают виртуальных помощников, на которых перекладывают конкретные рабочие задачи, например, по первичному отбору кандидатов, по помощи заказчику сформулировать вакансию или задание на разработку или по исследованию данных по публичным источникам.
Речь идет о проекте Профессионалы 4.0, задачей которого является привлечение фриланса на проекты. Начиналось с ИТ, там люди часто не хотят устраиваться в штат к корпорациям, но не против поработать в конкретном проекте. А потом распространилось на других специалистов, часто редких, напримеР, почвоведов. Сейчас там 45к спецов в базе, при этом от бизнеса идет большой поток проектов, около 3к. И есть задача - задача — выбрать профи, сопоставив описание проекта и требуемых ролей с резюме специалистов.
Проект вырос из того, что Ян, работая как бриф-менеджер по созданию документов на основе беседы с бизнесами, решил привлечь к этому делу ChatGPT и получилось настолько удачно, что опыт решили развивать, искать другие места в бизнесе, где помощь ИИ-агентов была бы уместна. Это было на слайдах. В результате уже создано четыре виртуальных помощников с разными специализациями, о которых рассказывали в докладе, показывая, что под капотом. * Диана - аналитик - Диана — аналитик — формирование структурированных документов по кратким ответам пользователя, формирование ТЗ* Wendy(из какого-то сериала) - — hr 4.0 - 0 — первичный отбор подходящих кандидатов* Анатолий (почти Вассерман) - — data-ассистент - ассистент — работа с данными в формате вопрос-ответ* Robinzon (плавание по инету) - researcher - — researcher — ИТ-агент для маркетинговых и других исследований по публичным источникам
Хотя начиналось все с Дианы. наиболее продвинулось создание Wendy. Работает с июня, почти год. Экономия 50-7070 % сотрудников на выполнение рутинных задач. Результат стабильный, объективный на любых объемах. Например, сравнение кандидатов. А заказчикам дает новые возможности сервиса.
Что делает Wendy?
# Описание потребности от заказчика. Много вопросов, чтобы исполнитель понимал объем работ. И заказчики своими словами описывают в открытой форме, а Wendy кладет в бриф. Заказчик-HR может написать "разработать «разработать мобильное приложение для ..."…», и дальше она дополняет - дополняет — что там нужно. Результат - Результат — проект размещен на платформе. # Талант может откликаться - 70откликаться — 70 % около-ИТ проекты, там спецов много. А если сложные проекты - проекты — гидроразрыв пласта или почвоведы. И если на платформе откликов мало, то надо искать на ресурсах, где специалисты собираются. ChatGPT дают описание проекта и вакансии, и он делает вкусное описание под конкретную аудиторию. На одни ресурсы его отправляют автоматом. на другие - другие — публикуют люди.# Оценка откликов на вакансии. Дают 4 вопроса: 2 по релевантному опыту и и 2 на hard-скилл. Надо ответить в свободной форме. Все это собирается в базу. И там же порождают нормальные ответы на вопросы - вопросы — для сравнения.# Сравнение исполнителей по базе, бывает до 50 человек откликаются. Одна оценка от человека, и еще три - три — разными методами от ИИ. Дальше люди с учетом этих оценок делают шот-лист для заказчика.
Чтобы построить методы обучения кандидатов, работали с выборкой 3000 откликов, которые оценивали люди. И построили несколько альтернативных методов оценки.
* Direct - Direct — на вход ChatGPT информация о проекте и о кандидате, и вопрос: насколько вероятно, что успешно выполнит, обоснуй* Rules - Rules — 5 параметров, и правила по каждому* Competence - Competence — через GenAI создаем набор компетенций исполнителя, по каждой 4 балла, а потом GenAI оценивает компетенции исполнителя и вероятность, что он прокачает компетенции. В том числе явно не названные: 10 лет работы означает, что git владеет с высокой вероятностью.По всем оценкам - оценкам — требуют аргументацию. Нейросеть ищет позитивно, но мы цепочкой промптов заставляют выставить балл и обоснование - обоснование — там довольно сложная цепочка, 4 промпта, и каждый 2 страницы.
Оценка кандидатов человеком по-прежнему остается, но по опыту использования, люди перестают ее заполнять для всех откликов, смотрят только те, что ИИ-агент оценил высоко по каким-то критериям.
Бывает, что оценки человека и нейросеток расходятся. Они анализировали соответствие. И поняли, что есть кейсы, когда люди оценивают хуже.
От заказчика по результатам собеседования идет обратная связь, ее учитывают для дальнейшего обучения.
Раньше в talent team два админа, которые обеспечивали коммуникации и так далее - далее — рутину. Сейчас один на других задачах, а второй - второй — частично, больше занимается коммуникациями.
Робинзон. Ищет актуальную информацию по открытым источникам, готовит в структурированном формате отчета.
Вопросы разные: про тренды, просят конкурентный анализ, просят оценить кандидата, или наоборот, спрашивают, стоит ли присоединиться к команде, спрашивают про современные методы обучения, например, сварщиков, про размеры зарплат, просят обзор маркетинговых стратегий.
Построена специальная система оценки ответов, для генерации без глюков, проверки ссылок. Екатерина задавала вопрос про профессиональные сообщества - сообщества — ChatGPT отвечал с глюками, а Робинзон это отсеял.
Как это работает? Это - Это — последовательность запросов к ChatGPT и в системы поиска. Сначала Робинзон определяет свою роль. Затем семантически расшивает запрос, делит его на кусочки и варианты. Затем эти запросы выполняются в поисковых системах, берут 10-15 верхних ссылок и источники из них. Затем делает отчет, объединяя их. Дальше агент, которые проверяет стыковки, и говорит предыдущему "перепиши«перепиши, фигня"фигня», если их нашел. Используется ChatGPT-4 или 3.5 - 5 — они оптимизируют стоимость.
{{wl-publish: 2024-04-23 13:21:36 +0300 | MaksTsepkov }}