Текущая версия на 10:48, 9 сентября 2024

Впервые был на MergeConf в Иннополисе. Конференция молодая, проходит в третий раз. При этом собрала более 1500 участников со всей страны, это — не региональная конференция. Очень широкий профиль и много докладов, 11 параллельных треков. Доклады — качественные, по уровню, на мой взгляд, сравнимы с докладами highload и teamlead, если учитывать, что у конференции несколько другая аудитория, в которой меньше топовых технологических компаний. И очень хорошая атмосфера активного общения.

Я лично для себя вынес с конференции несколько вещей.

1. Надо внимательнее посмотреть книгу Team Topologies, о ней говорил Вацлав Довнар. Я о книге слышал, но плотно не смотрел, быстро нашел обзор Александра Поломодова и еще несколько, проглядел. Идеи — понятные, есть простая типология команд и типов взаимодействия. Но основная идея — в постановке конструкции команд и взаимодействия под управление, при этом с учетом закона Конвея. Интересно, есть ли аналог закона Конвея для не-ИТ, а для сферы услуг и производства? Учитывая разнообразие продуктов и всякие композитные конструкции.
2. Методы работы с изменениями, которые раньше звучали в докладах по agile-трансформации, теперь звучат в докладах по devops.
3. Вопросы мотивации надо рассматривать комплексно: что драйвит, а что — напрочь отбивает мотивацию. Казалось бы, очевидно. Но на практике много докладов, которые именно про создание мотивации — что бесполезно, если есть ее регулярное обнуление.

Еще был интересный доклад про методы социальной инженерии, где рассказывали про способы действия мошенников. В нем интересно, что в числе источников — материалы call-сервера в Бердянске, где были захвачены сервера со всей информацией, центр совершал до 100к звонков ежедневно.

Я был не только на менеджерских докладах, но и на нескольких технических, для расширения кругозора. И несколько из них хочу отметить.

1. Про архитектуру софта для управления транспортными беспилотниками, в котором фокус был на сельскохозяйственную и другую спец.технику, у которой есть большое разнообразие задач.
2. Про практическое применение ИИ на основе GenAI в Газпромнефти, где рассказывали про конструкцию и использование нескольких ИИ-помощников для разных задач, и даже предлагали самим их потестировать — они уже эксплуатируются.
3. Про сравнение RESTful и Json-RPC в пользу последнего за счет простоты и меньших накладных расходов. При этом, разрабатывая выставленные по RPC api никто не мешает пользоваться принципами REST для их проектирования. Просто вызов будет по-другому.

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

Сам я рассказывал про самоопределение: Самоопределение: чего я хочу от жизни и работы. Предыдущий доклад на эту тему был осенью на SQAdays. Хотя название совпадает, но презентация и содержание — дополнено. Правда, записей с MergeConf не будет, поэтому если тема интересна — смотрите осенний доклад или читайте статьи.

Менеджерские доклады

Александр Крылов из Bimeister. Методы управления сопротивлением при внедрении новых процессов в компании

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

Тезис состоит в том, что сопротивление при изменении сложившихся практик неизбежно, к этому надо быть готовым и уметь с этим работать. Часть работы — умение убедить людей и продать изменения команде. У того, кто хочет изменений, даже если это руководитель, не всегда есть эти умения — и тогда стоит найти человека, который сможет быть вашим голосом и убедить его. Отмечу, что при этом с ним придется поделиться с ним успехом успешного изменения, но тут уж вопрос, что для вас важнее: результат изменений или признание вашего вклада. Вообще это часть общего подхода: не настаивая на собственном авторстве идеи часто можно добиться гораздо больших изменений.

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

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

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

Следующий подход — Теория изменений, Theory of Change. Александр сказал, что не смог найти первоисточник найти не смог, теория восходит к одному из экономистов Штатов 60-х. Вообще статья вики Theory of Change трассирует теорию к Питеру Друкеру и его Management by Objectives, управлению по целям (не путать с OKR, это — другое), но дальше ссылки идет на 1990-е, так что, по-видимому, реальная проработка была тогда.

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

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

Третий подход — теория изменений Коттера. В ней 8 шагов, и ключевой — первый. Надо натолкнуть топов на мысль, что изменения — неизбежны, если не сделаем — будет ай! Сформировать мысль острой необходимости изменений. И тут хорошая метафора: пингвины на льдине, которая идет к экватору или аналогичная, и это надо показать. Потому что основная история — поддержка изменений. руководством.

Далее — более техническая работа.

2. Группа поддержки

3. Видение перемен

4. Что хотите добиться — образ будущего

5. Устраняйте препятствия

6. Добейтесь маленьких побед, особенно важно в трансформации большой компании по частям

7. Развивайте изменение

8. Закрепите изменения — этап стабилизации, это обязательно, а про него забывают

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

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

Я тут хочу остановиться, и дать ссылку на еще один фреймворк, который Марк Розин рассказывал на ПИР-2021, описание можно посмотреть в моем конспекте. У него четыре метода изменений, два из них — достаточно известны: жесткий реинжиниринг и мягкая сила постепенных изменений, а еще два не столь очевидны: островной метод с постепенным прорастанием изменений и метод блефа с жесткой угрозой и расторговкой, за счет чего сопротивление снижается.

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

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

Чеклист: зачем внедряем процесс; какая выгода от внедрения; какие команды затронет, зааффектит; есть ли кто будет против; есть ли те, кто за. Был заполнен для проекта, и Александр его рассказал с комментариями.

Этапы.

• Информация: описание, защита, правки, переговоры, обучение, поддержка
• поиск сторонников: участники, горизонт, лиды, cio/cto
• внедрение: 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-метод.

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

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

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

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

Александр Бындю. Стратегия решает проблемы на всех уровнях компании

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

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

Шахматы. Есть цель: выиграть игру до 30 хода, поставить мат. Есть задачи — ходить фигурами. А вот стратегия выигрыша — слепая зона. Научить ходить фигурами в шахматах можно ребенка. А вот стратегия — гораздо сложнее. Кто знает стратегию своего проекта? 10 рук в зале.

Итак, есть три уровня.

1. Целеполагание: куда идем и как увидим, что пришли
2. Стратегирование — определение пути к цели, способа ее достижения, обоснование, что путь приведет к цели — и это часто пропускают
3. Тактика. Какие задачи конкретно нужно сделать.

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

Эффективность стратегии определяется двумя факторами

1. Единое понимание на всех уровнях, скорость и точность понимания (передачи), дешевая смыслов синхронизация между людьми
2. Возможность быстрого перестроения стратегии при изменении ситуации — в нынешнем мире это актуально

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

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

Визуализация — можно создавать совместно, связи проставлены — легко меняем.

Типичные проблемы компании без стратегии.

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

Карта гипотез — метод стратегического планирования для проектирования следующего шага развития.

Схема построения: Цель — субъект (чью жизнь меняем) — гипотезы — задачи (почему сработает)

Типичная ситуация примерно такая. Нефтянка. Задача — уменьшить травмы на производстве за 2 года. Очень крутая задача. Цель — есть, из нее выписаны задачи на 10 лет вперед. Но трассировки от задач до целей — нет, нет гипотез.

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

Еще пример. Компания ставит задачу стать более публичными. Реактивное решение — идем выступать, писать, давать интервью. Но! Было бы неплохо узнать — зачем. Скажут: бренд, узнаваемость. Но дальше спрашиваем: а как узнаем, чего достигли? Если узнаваемость для прибыли или новых заказов — то это одни выступления и публикации. И тут еще надо понимать, на каком шаге воронки продаж фокусируемся: чтобы пришло больше лидов, или чтобы решение клиентами принималось с большей уверенностью за счет репутации. Если хотят в 2 раза больше заявок — то следующий шаг: почему их станет больше: кто-то услышит и придет или порекомендует — это определяет площадки и содержание. А если публичность — для привлечения и удержания сотрудников — то это другие публикации и выступления, на других площадках.

Еще пример. Компания ставит задачу на то, чтобы стандарты качества были одинаково высокие.

1. Как поймем, что пришли? Метрики качества? Или возможность показать в продажах? Или отсутствие инцидентов?
2. Субъекты. Например, новый сотрудник перепроверяет по чек-листу — чтобы выработать привычку — это гипотеза.
3. Задача — обучить на онбординге. И появляется логика: HR обучает не потому, что заставили, а для такой цели, и это — мерять можно.

Когда есть гипотезы — ставим приоритеты. Есть RICE и другие методы. Делают по-разному, где-то ставит генеральный, а где-то — голосование звездочками.

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

Результаты наличия стратегии.

• Мотивация
• Приоритеты
• Перестают конфликтовать, даже собственники — рисуют что важно
• Задачи нельзя взять и сделать — надо приземлить на веточки. Если не приземляется — можно порисовать веточки. А если не рисуется — да, супер-круто, но не понятно зачем, надо придумать. Очень хорошо отрезвляет фантазеров.

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

Дальше в презентации ссылка на доп.материалы: топология, примеры карт, ошибки, официальная группа карты гипотез. Александр развивает метод, можно познакомиться и использовать, можно обучиться и стать тренером. Метод построен как дальнейшее развитие impact map, просто дополнений накопилось настолько много, что получилась уже отдельная конструкция. Выложил в open source? сделал коммьюнити.

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

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

Антон Бочкарев. Взлом мозга, основы социальной инженерии

Это доклад не про менеджмент, а он про то, как работают телефонные мошенники. И тут интересен материал. Мошенники в России массово работают с территории Украины, это было еще до эпохи СВО. Есть данные, что в Днепропетровской области до 30 % трудоспособного населения работали в call-центрах, и там это продуманная технология. Когда в начале СВО заняли Бердянск, то персонал call-центра убежал, а сервера — остались, и в докладе были результаты анализа их скриптов и данных по созвонам. Также были результаты анализа по кейсам поджогов, которые были недавно. И собственный опыт — Антон по заказу компаний проверяет устойчивость их к различным атакам, используя скрипты, аналогичные используемым злоумышленниками.

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

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

Барьером на этом пути служит критическое мышление и оценка ситуации. Фишка в том, что когда мы в стрессе, то механизмы мозга сами отключают функции критического мышления и анализа. Именно поэтому сколько бы людям в компаниях не объясняли, что нельзя переходить по ссылкам в письмах, устанавливать софт и так далее, всегда 7 % это делают просто потому, что они решили разобрать почту в момент стресса, связанного с посторонними рабочими или семейными обстоятельствами, и это делал их некритический автопилот. Так что просто надо атаковать массово.

А еще во многих ситуациях человек продолжает делать привычное. Мы сменили место работы, а автопилот ведет на старое. Уважительное отношение к коллегам предполагает, что если человек просит — у него есть причины, надо выполнить просьбу. Был эксперимент с очередью к ксероксу: если человек просил пропустить, потому что «надо срочно и всего пару листов», то пропускали в 94 %, а если просил просто фразой «мне надо скопировать документы» — то в 93 %, то есть люди не анализируют основания.

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

С мошенничеством связано много мифов. Первый — то что жертвами прежде всего становятся пожилые. Просто пожилых — жалко, поэтому СМИ шире освящают именно эти случаи. Статистика по обращению в полицию говорит, что основная масса жертв — от 18 до 54. И статистика call-центра Бердянска тоже говорит, что целевой аудиторией были молодые, от 20 до 40 лет. Там — вполне промышленные масштабы, 100к звонков ежедневно, конверсия по переводам денег 1-2 %.

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

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

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

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

Эксперимент с пожертвованием на онкологию. Если людей сначала попросить поносить недельку значок «я против онкологии», а при возврате предложить сделать пожертвование — то жертвуют больше, чем если просят просят сделать пожертвование. В Шатах был эксперимент — просили разрешение поставить перед домом уродливую штуку с призывом к безопасному вождению. А других сначала просили подписать бумагу с призывом к безопасному вождению, а только потом — поставить штуку. Во втором случае процент больше, люди хотят быть последовательными. Оценка шансов на успех лошади на ипподроме меняется после того, как человек сделал ставку.

Не просят перевести все деньги, сначала безопасное действие, потом просят помочь немного, потом чуть больше. Мы звоним из банка, у вас карту не украли, паспорт не украли. Затем — контактные данные, проверить мобильное приложение. А потом — поставьте приложение, дайте доступ и так далее. Чем больше маленьких шагов — тем больше вероятность.

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

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

Полноценно нельзя защититься — мозг не патчится. Но на старте можно научиться прерывать контакт:

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

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

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

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

Евгений Антонов из Яндекса. Всё, что вы хотели знать о демотивации, но боялись спросить

Много разговоров про мотивацию, но очень мало — про демотивацию. А демотивации вокруг — очень много. От нее — ущерб.

Что такое — демотивация?

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

В отличие от выгорания, демотивация идет на фоне ярких эмоций. При выгорании на эмоции уже нет сил, она на фоне усталости.

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

Он по аналогии сделал двухфакторная демотивация по Антонову.

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

Внешние факторы

• Обман — обещали и не дали. Премию, прибавку к зарплате, отпуск.
• Давление: «выходи в выходной, а то…», или «ты такой молодец, возьми еще проектик»
• Не уважение. На ревью обесценивать, доказывать, что не специалист.
• Чувство несправедливости. Абсолютной справедливости нет, но двойные стандарты, например, когда ему можно пораньше с работы, а тебе — нет — явно демотивируют. Понятно, что люди — разные и бывают всякие ситуации, и тут важна прозрачность, явное объяснение причин.
• Недоверие к человеку, особенно публичное.
• Отсутствие цели, позиция «выполняй и не спрашивай, для чего».
• Деньги, зарплата и премии — тут много разных историй.

Внутренние факторы.

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

Конкретные истории.

• Обещания. Сначала договорился с компанией о прибавке через полгода, а потом они передумали. Дальше человек получает офер — и ему делают контрофер. По сути — двойной обман. По ситуации он может и согласиться, но отношение к работе будет иное.
• Мальчик кричал ASAP. Менеджер придумывал важные и срочные проекты, а оказывалось, что это работа в стол. Хотя бывает, что это — не в стол, а в портфолио менеджера.
• Нерадивый товарищ. Я месяц нифига не делаю — а я знаю, я за двоих делаю.
• Big angry boss. Много примеров компаний, когда на людей кричат и до слез доводят. Печально и тому, кого доводят, и тем кто доводит, просто потом — люди уходят и пишут истории, репутация компании страдает.
• Ложная риторика «мы все семья». Классическая семья предполагает, что «если еды лишь на троих — каждый будет есть меньше», а в корпоративной «раз еды на троих — ты не наша дочь». Ситуации с премиями и сокращениями.
• Человек собирался, попросил отпускные, не дали, он поскреб все что было. Вернулся — попросил. Руководитель сказал «письмо напиши, будет непрочитанным — я вспомню», и два месяца непрочитанным. В компании появился мем.

Если люди расстраиваются и забивают на работу — компания теряет миллионы. Он видел команду, которая специально имитирует работу: им на нас наплевать, а нам — на них.

Демотивация распространяется между людьми и командами — это заразно.

Как распознать демотивацию.

• Игнорирование. Договорились — и никто не делает
• Агрессия
• Итальянская забастовка. Сделаю все как просил — но так, что получается фигня
• Постоянные отмазки — ни одну задачу до конца не доносят, ссылаясь на внешние причины
• Нежелание принимать решение и нести ответственность, гробовая тишина на призыв предложить. — потому как странное распределение работ, риски ошибиться
• Непризнание причастности к проекту и команде. Не мы, а вы, я вне команды.

Тут важны не только обсуждения, но и опросы: 1:1, общие, анонимные, публичные…

Профилактика — лучшее лекарство. Уважение.

Что делать, если не уследили?

• Откровенно поговорить. Тема капитанская — но не говорят. Стремно.
• Обозначить конкретные шаги и сроки
• Держать в рсе о прогрессе и результатах. Даже если не получается.
• Разогнать всех к чертовой матери. Плохой. Но расформирование команды иногда лечит.

Важно думать о мотивации, но не менее важно думать о демотивации.

Делайте хорошо, а плохо — не делайте!

Что делать, если ты в демотивированной команде

• Обсудить с коллегами — может, это только у меня неправильно
• Обсудить с руководителем 1:1 — вот проблемы, что делать будем
• Собственный список плюсов и минусов: может, уходить пора, а не бороться*

Алексей Цыбульник. Предупреждён — значит вооружён. Что следует ожидать ИТ сотрудникам от эволюционных изменений

Различают два типа изменений

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

Нормативные — легче. Понятно, что грань — не очевидна, но важен режим эксперимента и возможность отката назад.

В Agile два самых известных метода — Scrum и Kanban. Scrum — это структурные изменения, революцию. Ты не тестировщик, мы все — равная команда. А Kanban — эволюция, он начинается с нормативных изменений. С структурные — не сразу, и только если выяснится необходимость. Канбан-метод никогда не даст процесс «как надо» — он поможет подстроить ваш процесс.

Принципы перехода на Kanban это поддерживают.

1. Начинаем с того, что есть сейчас — вы как-то работаете. Насколько вы понимаете, насколько понимают новые — изучаем. Непонятки — выясняем. Уважаем сложившиеся практики, организационную модель, ролевую структуру.
2. Поощряем проявления лидерства на всех уровнях. От рядовых до топов. Озвучивание проблемы — тоже шаг лидерства. Не наказываем за формулирование проблем, за инициативы. Здесь есть хорошая книга: Дэвид Марке «Разверните ваш корабль».
3. Договоритесь об эволюционных инструментов. Мы не выбрасываем старое, мы берем новый инструмент и его пробуем. И только потом решаем: использовать или нет. Предложение попробовать — безопаснее, чем предложение перестроить работу.

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

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

2. Источники неудовлетворенности, внутренние и внешние. Это отрезвляет менеджмент, и дает ему информацию о неудовлетворенностях.

Накидали кучу проблем — а они сохраняются, действия не делают. Значит есть какие-то причины.

3 и 4. Анализ запросов и возможностей. Дает знание, что мы делаем и для кого. Тип запросов, сколько времени занимает работа по каждому. Сколько мы можем поставить.

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

Тут было отступление: работа как процесс накопления знаний. Разработка, измерение улучшений, подтверждение клиентом. Как задача в школе: прочитали условие — начали писать и решать — сделали решение готовым. Решая, могли забыть по дороге, но сделанные знания — не исчезают. Даже если пошли другим путем — опыт предыдущего все равно есть. Нет возврата.

6. Формализируйте классы обслуживания. Архетипы стоимости задержки — 4 класса: линейный равномерный — чем быстрее тем лучше потери, фиксированная дата (к празднику), S-кривая; 0 (когда-нибудь будет плохо). Зачем это надо знать? Чтобы разумно организовывать работу.

7. Визуализация и базовые правила. Явные договоренности о действиях и решениях, чек листы. WIP-лимит — пример такого правила.

Лев Ушаков. Управление состояниями команды для решения творческих задач

Лев — тренер творческих состояний. Эту профессию придумали в Сколково в 2014, она появилась в списке будущих профессий. В 2017 появились люди, которые начали пробовать, сейчас 72 русскоязычных специалиста в 11 странах, идет институализация.

Подача доклада — крутая. Сначала — движуха, чтобы получить активность и вовлеченность. Самооценка — состояние, активность, энергия — разными жестами, 5 баллов, 10, высота. Перекидывание мандаринов после контакта взглядом. В аудитории — контакт, чувство безопасности, настроение.

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

3 системы: человек — команда — компания, в креативной экономике.

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

Состояние — не просто сейчас. Есть проект 2-3 месяца. Есть динамика состояния человека, когда он в лучшей форме. Различают оперативное (20 сек), текущее (от 2 минут до дня) и длительное (любовь, депрессия и другие).

Разработчики, дизайнеры, ученые — у всех может быть творческий кризис. Остановка движения.

Творческие инсайты случаются при отвлечении. Прогуляться, пожонглировать. Иногда хватает пары минут — недолго. Важно, чтобы не было переключения с фокусом.

Пирамида: состояние — мышление — действия — результат.

Вирус в человеке. Он появляется, температура поднимается — а потом иммунитет борется и в следующий раз быстро подавляет. В удачном сценарии. Вирус не-адаптивное поведение.

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

Транзакт-анализ: родитель — взрослый — ребенок.

• Ребенок — радость, креатив.
• Родитель — контроль, знает как надо, традиции.
• Взрослый — посредник между ними.

Расширение модели: контролирующий родитель — заботливый родитель и адаптивное дитя — естественное дитя. У всех свои особенности. Адаптивное дитя — часто подавленная энергия. Естественное дитя — берегов нет.

Этапы решения

• Взрослый: ключевые вопросы, формулирование задачи.
• Естественное дитя — генерация идей, дивергентное мышление. Заботливый родитель останавливает, когда достаточно, мягко не обломать
• Дальше надо выбрать 1-2 варианта, конвергентное мышление. Это взрослый.
• И так далее.
• Презентовать заказчику можно в разных состояниях — зависит от ситуации.

Это показывает, что важно своими состояниями управлять.

Динамика между тактами работы

• выдох: расслабление, празднование, ассимиляция. снять усталость.
• пауза: быть в контакте, кто я и куда идем…
• вдох: вдохновение на новые победы.

Сессия, встреча в усталом состоянии — бесполезна.

Начинать надо с себя. И с команды — чтобы среда была привлекательна топ-специалистам. Смузи — уже не привлекает.

Елена Колесникова. Развитие команды через командный коучинг

Елена — руководитель команды обучения и развития персонала в Directum. Это компания-вендор, 900+ сотрудников, площадки — Ижевск, Москва, Уфа, Тюмень. Ее команда learning and development разрабатывают и проводит обучение внутри компании. 3 менеджера по обучению и развитию + 2 тренера + она — лидер и тренер.

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

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

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

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

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

Техника решения — через пирамиду Дилтса: окружение — поведение — способности — убеждения — идентичность — видение.

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

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

А потом вернулись к ценностям, взяли объединяющее, учли идентичность и видение — и сформулировали 7 штук, они тоже есть в презентации. Там достаточно подробные формулировки, но смысл, опять-таки, в совместном обсуждении.

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

У них получилось сформулировать цель, из нее — четыре направления развития и дальше — задачи, которые можно начинать решать уже сейчас.

Коучинг завершился, проблема решена. Что получили.

• Синхронизация по ценностям
• Члены команды стали проявлять инициативу и предлагать идеи развития — раньше это делала она как лидер. Там много
• При составлении ИПР ориентируемся на общую цель и навыки из пирамиды
• Проще расставлять приоритеты

А регулярные встречи они оставили — для общей работы над развитием технологий работы подразделения.

В общем, такая история. Она интересна, но лично для меня — относительно очевидная. Было бы интереснее услышать в докладе не одну историю, а некоторый обобщенный опыт по применению инструмента, иллюстрированный, естественно, конкретными кейсами. Все-таки, было 15 штук, это достаточно много.

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

Технические доклады

На конференции их — абсолютное большинство, просто мои интересы больлше в области менеджмента. Поэтому выборка — не репрезентативна.

Вадим Царегородцев из Островка. Вперёд в прошлое! Или как подружить чистую архитектуру и RSC

RSC — это React server component, новая возможность React, который позволяет вести рендеринг на серверной стороне. Доклад был о том, как и для чего это использовать.

Если кратко, то старый подход можно описать формулой ui = f(state). При этом state размазан между фронтом, бэком и базой данных и идет бесконечная синхронизация между ними. Серверные компоненты позволяют поменять формулу на ui = f(data)(state), при этом данные всегда достаем из базы с любого уровня, это убирает потребность синхронизации. И получается проще.

Детали надо смотреть в выступлении, там было много технических деталей, в которых я, увы, плаваю, потому как на react не разрабатывал…

Кирилл Святов. Архитектура систем управления наземными высокоавтоматизированными транспортными средствами

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

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

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

Платформа включает следующее.

• Устройства для переоборудования техники под беспилотники, элементы для переоборудование конкретных узлов — рулевое управление, педали
• Типовые системы управления
• Карты. Глобальные, на них путь. И высокоточные локальные: что видит сейчас и что видел в прошлый раз в этом месте. Редакторов карт не более 5 в мире, карты сильно сильно платные, а редакторы вообще не дают.
• Движки. Есть Apollo drive и Autovei, но они оба ориентированы на городскую среду.
• Архитектурные программные шаблоны
• Инструменты для настройки оборудования: лидар (128 лучей, 11 герц, 120к точек * 11 в секунду), камера (блики, освещенность, серые, обычные и стерео — они дальность определяют), и то и другое надо калибровать. При этом лидары — дорогие, камеры — сильно дешевле, и у них разные плюсы и минусы, может требоваться совместное использование.
• Платформа для симуляции, чтобы вести отладку не только в реальных условиях. Платформ есть несколько, основной дефакто CARLA, но он дорог и ориентирован на городскую среду, поэтому они взяли за основу другой симулятор.

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

Воркеры — процессы обработки данных, зацепленные в конвейер.

• Получение семантической сегментации с камеры. Есть библиотеки. Перевод изображения в автомобили, деревья и так далее. Параллельно — нейронка определяет объекты.
• Разворот вида вперед на вид сверху. Матрица гомографии, специально надо получать с учетом расположения камеры. Получается локальная карта. Лидар может уточнить дальность.
• Дальше модуль поведенческого анализа — предсказание движущихся объектов. Беспилотник должен предсказывать на время до остановки. И максимальная скорость — скорость обработки кадров и достоверность предсказания.
• Дальше планировщик пути, разные алгоритмы для простой и для сложной траектории с разворотами. Здесь же ограничения правил движения
• Управление транспортным средством

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

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

Это все уже работает, в презентации были видео и там реальные поездки, не только симуляции. Вся обработка — на борту, информации от сенсоров столько, что никакого инета не хватит. Для 20 км/ч хватает производительности мощного ноута с GPU. Для 120 км/ч — уже нужен кластер. Но для сельхозтехники скорость не нужна.

К симулятору есть доступ из web — докер-контейнер с симуляторов, visual-studio и т. п., так что можно проводить соревнования для школьников и других интересующихся.

Они — не коммерческая история. Гранты в Университете — аспиранты и студенты. Но взаимодействуют с площадками в Липецке и Новосибирске, которые беспилотники делают.

Виталий Киреев из SpaceWeb JSON-RPC 2.0 как альтернатива REST API. Почему стоит использовать его?

SpaceWeb — хостинг, 200+ услуг, 450+ взаимодействий. Стояли задачи сделать единую панель управления, мобильный клиент, 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 — тоже отдают.

Не взирая на эту бочку дегтя и на то, что api для клиентов оказалось не привычным rest, преимущества клиенты оценили: число клиентов, использующих api увеличилось в 3 раза.

Кроме json-rpc есть еще grpc от google. Они выбирали в 2017, тогда с ним были проблемы. Сейчас он доведен, и для новых проектов — хорош. А для legacy все равно бывают проблемы.

Сергей Сахаров. Laravelize It! Или второе дыхание Legacy

Специфика legacy-проектов (php).

• Отсутствие договоренностей, слоистая структура разных стилей и подходов
• Проблемы архитектуры — смешение подходов в одном проекте. Одно через action, другое — через один контроллер (30к строк!)
• От кода исходит дурной запах (Роберт Мартин)
• Дубли и повторы в коде

И усугубляется это подходом «фреймворки — зло, лучше напишем сами», так считают многие.

Отношение к этому может быть разное.

• Классика-1: проблемы нет, все же работает. инет-магазин на ucms, а api — свое на switch-case
• Классика-2: перепишем все с нуля. Это невозможно, даже если дописывают — новый комок, который потом выбросят
• Удушающее приложение — параллельно на новом стеке. strangler 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 — это разница объектным и процедурном подходами, примененными к api. Но, помимо концептуальной разницы есть техническая: RESTful предполагает http и синхронное взаимодействие, а у rpc таких ограничений нет. И потому может быть целесообразно использовать rpc, сохраняя при этом принципы RESTful при реализации классов и процедур, к которым предоставляется доступ. И еще я хочу отметить, что те, кто придумывали RESTful перенесли на него шаблон создания сущности с генерацией ключа на стороне сервера. Это уместно и удобно при работе с базой данных, когда у вас есть сессия и транзакции, а вот при взаимодействии при отсутствии транзакций и отсутствия гарантий доставки это — неудобно, так как не дает идемпотентного создания ресурсов. Спецификации типа Json-rpc решают эту проблему. Вообще сравнение RESTful и Json-rpc было в другом докладе.

Впрочем, создание сущностей можно делать через put, а не post, и тогда создавать ключ на стороне клиента. Вообще, общий принцип: put и patch — идемпотентны, post — нет, а get — лишь запрашивает данные, поэтому его можно кешировать — в отличие от других запросов. Важный принцип — uri ссылается на ресурс, а не на действие.

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

Использование может быть в двух режимах.

• Code first — сначала разработчики создают код, по нему порождается open api
• Contract first — сначала open api. Сначала согласуют, а потом дают разработчикам. Разработчики закодируют не так — но есть генератор, который сделает ровно то, что нужно.

Согласование спецификации до кодирования важно: иначе можно сделать api, которое не пригодно пользователям для их целей.

Екатерина Неделина и Ян Шишеня из Газпром Нефть. Новые «люди»: как ИИ-сотрудники меняют бизнес-ландшафт

Пока теоретики спорят о то, что ChatGPT может, а что — нет, практики делают виртуальных помощников, на которых перекладывают конкретные рабочие задачи, например, по первичному отбору кандидатов, по помощи заказчику сформулировать вакансию или задание на разработку или по исследованию данных по публичным источникам.

Речь идет о проекте Профессионалы 4.0, задачей которого является привлечение фриланса на проекты. Начиналось с ИТ, там люди часто не хотят устраиваться в штат к корпорациям, но не против поработать в конкретном проекте. А потом распространилось на других специалистов, часто редких, напримеР, почвоведов. Сейчас там 45к спецов в базе, при этом от бизнеса идет большой поток проектов, около 3к. И есть задача — выбрать профи, сопоставив описание проекта и требуемых ролей с резюме специалистов.

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

• Диана — аналитик — формирование структурированных документов по кратким ответам пользователя, формирование ТЗ
• Wendy(из какого-то сериала) — hr 4.0 — первичный отбор подходящих кандидатов
• Анатолий (почти Вассерман) — data-ассистент — работа с данными в формате вопрос-ответ
• Robinzon (плавание по инету) — researcher — ИТ-агент для маркетинговых и других исследований по публичным источникам

Хотя начиналось все с Дианы. наиболее продвинулось создание Wendy. Работает с июня, почти год. Экономия 50-70 % сотрудников на выполнение рутинных задач. Результат стабильный, объективный на любых объемах. Например, сравнение кандидатов. А заказчикам дает новые возможности сервиса.

Что делает Wendy?

1. Описание потребности от заказчика. Много вопросов, чтобы исполнитель понимал объем работ. И заказчики своими словами описывают в открытой форме, а Wendy кладет в бриф. Заказчик-HR может написать «разработать мобильное приложение для …», и дальше она дополняет — что там нужно. Результат — проект размещен на платформе.
2. Талант может откликаться — 70 % около-ИТ проекты, там спецов много. А если сложные проекты — гидроразрыв пласта или почвоведы. И если на платформе откликов мало, то надо искать на ресурсах, где специалисты собираются. ChatGPT дают описание проекта и вакансии, и он делает вкусное описание под конкретную аудиторию. На одни ресурсы его отправляют автоматом. на другие — публикуют люди.
3. Оценка откликов на вакансии. Дают 4 вопроса: 2 по релевантному опыту и и 2 на hard-скилл. Надо ответить в свободной форме. Все это собирается в базу. И там же порождают нормальные ответы на вопросы — для сравнения.
4. Сравнение исполнителей по базе, бывает до 50 человек откликаются. Одна оценка от человека, и еще три — разными методами от ИИ. Дальше люди с учетом этих оценок делают шот-лист для заказчика.

Чтобы построить методы обучения кандидатов, работали с выборкой 3000 откликов, которые оценивали люди. И построили несколько альтернативных методов оценки.

• Direct — на вход ChatGPT информация о проекте и о кандидате, и вопрос: насколько вероятно, что успешно выполнит, обоснуй
• Rules — 5 параметров, и правила по каждому
• Competence — через GenAI создаем набор компетенций исполнителя, по каждой 4 балла, а потом GenAI оценивает компетенции исполнителя и вероятность, что он прокачает компетенции. В том числе явно не названные: 10 лет работы означает, что git владеет с высокой вероятностью.

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

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

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

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

Раньше в talent team два админа, которые обеспечивали коммуникации и так далее — рутину. Сейчас один на других задачах, а второй — частично, больше занимается коммуникациями.

Робинзон. Ищет актуальную информацию по открытым источникам, готовит в структурированном формате отчета.

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

Построена специальная система оценки ответов, для генерации без глюков, проверки ссылок. Екатерина задавала вопрос про профессиональные сообщества — ChatGPT отвечал с глюками, а Робинзон это отсеял.

Как это работает? Это — последовательность запросов к ChatGPT и в системы поиска. Сначала Робинзон определяет свою роль. Затем семантически расшивает запрос, делит его на кусочки и варианты. Затем эти запросы выполняются в поисковых системах, берут 10-15 верхних ссылок и источники из них. Затем делает отчет, объединяя их. Дальше агент, которые проверяет стыковки, и говорит предыдущему «перепиши, фигня», если их нашел. Используется ChatGPT-4 или 3.5 — они оптимизируют стоимость.