Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 621 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru |
Последний постВпервые был на MergeConf в Иннополисе. Конференция молодая, проходит в третий раз. При этом собрала более 1500 участников со всей страны, это — не региональная конференция. Очень широкий профиль и много докладов, 11 параллельных треков. Доклады — качественные, по уровню, на мой взгляд, сравнимы с докладами highload и teamlead, если учитывать, что у конференции несколько другая аудитория, в которой меньше топовых технологических компаний. И очень хорошая атмосфера активного общения. Я лично для себя вынес с конференции несколько вещей.
Еще был интересный доклад про методы социальной инженерии, где рассказывали про способы действия мошенников. В нем интересно, что в числе источников — материалы call-сервера в Бердянске, где были захвачены сервера со всей информацией, центр совершал до 100к звонков ежедневно. Я был не только на менеджерских докладах, но и на нескольких технических, для расширения кругозора. И несколько из них хочу отметить.
В целом на конференции технических докладов — абсолютное большинство, просто меня больше интересовали менеджерские. Так что мои заметки в этом смысле не репрезентативны. Сам я рассказывал про самоопределение: Самоопределение: чего я хочу от жизни и работы. Предыдущий доклад на эту тему был осенью на SQAdays. Хотя название совпадает, но презентация и содержание — дополнено. Правда, записей с MergeConf не будет, поэтому если тема интересна — смотрите осенний доклад или читайте статьи. Менеджерские докладыАлександр Крылов из Bimeister. Методы управления сопротивлением при внедрении новых процессов в компанииАлександр работает над devops-трансформациями и изменениями в работе службы поддержки, и он рассказывал об управлении изменениями на своих кейсах. Но при этом кейсы использовались больше как иллюстрация к описанию методов и подходов к работе с изменениями и сопротивлением им. Тезис состоит в том, что сопротивление при изменении сложившихся практик неизбежно, к этому надо быть готовым и уметь с этим работать. Часть работы — умение убедить людей и продать изменения команде. У того, кто хочет изменений, даже если это руководитель, не всегда есть эти умения — и тогда стоит найти человека, который сможет быть вашим голосом и убедить его. Отмечу, что при этом с ним придется поделиться с ним успехом успешного изменения, но тут уж вопрос, что для вас важнее: результат изменений или признание вашего вклада. Вообще это часть общего подхода: не настаивая на собственном авторстве идеи часто можно добиться гораздо больших изменений. Первая теория, о которой говорил Александр — Теория парадоксальных изменений Арнольда Бейсера. Основная идея: человек когда меняется — он просто становится тем, кем он является, просто почему-то раньше не стал, он проявляет свою внутреннюю сущность. И задача изменений — помочь человеку стать способным к изменениям, сохраняя его индивидуальность. Очевидное применение — с джунами, которые пока не раскрыли свой потенциал, и их надо подтолкнуть. Можно порекомендовать книги, послать на конференции. Но важно не просто дать направление, а поддерживать изменения, сохранять человека на дистанции. Мы не просто делаем индивидуальный план развития, а трекаем движение. Но в этой парадигме можно также работать с мидл-менеджментом и со сложившимися сотрудниками: ты можешь большего достигнуть и стать лучше, только еще этого не знаешь. Отмечу, что тут основная засада — сформулировать это «лучше» и «больше» в той системе оценок, которую человек для себя признает, ведь людям важно разное: одним — профессиональная оценка, другим — сервис клиентам, третьим — развитие карьеры или повышение зарплаты. Однако, тут работает и альтернативный подход: изменения неизбежны, это — часть общего тренда, который не остановить, и именно ты можешь сделать первый шаг, получив больше профит от этого. Впрочем, я тут отмечу, что это сработает не для всех, есть разные отношения к моде и инновациям, и многим комфортнее быть последователем, а не первооткрывателем, и об этом тоже есть типологии и модели, которых Александр не касался, например, модель Роберта Мертона. Следующий подход — Теория изменений, Theory of Change. Александр сказал, что не смог найти первоисточник найти не смог, теория восходит к одному из экономистов Штатов 60-х. Вообще статья вики Theory of Change трассирует теорию к Питеру Друкеру и его Management by Objectives, управлению по целям (не путать с OKR, это — другое), но дальше ссылки идет на 1990-е, так что, по-видимому, реальная проработка была тогда. Подход задает четыре компоненты изменений: действие — предпосылки — результаты — влияние. А как ключевой вопрос ставит определение выгоды: для вас, для тех кому надо измениться и, в идеале — еще для всей компании. Подход совместим с первым, вообще подходов много, между ними надо уметь переключаться. Третий подход — теория изменений Коттера. В ней 8 шагов, и ключевой — первый. Надо натолкнуть топов на мысль, что изменения — неизбежны, если не сделаем — будет ай! Сформировать мысль острой необходимости изменений. И тут хорошая метафора: пингвины на льдине, которая идет к экватору или аналогичная, и это надо показать. Потому что основная история — поддержка изменений. руководством. Далее — более техническая работа.
Дальше был рассказ про методы управления сопротивлением: принудительный, адаптивный, кризисный, управляемый. Основное — метод управляемых сопротивлений: совершить изменение без принуждения, в удовлетворительные сроки. Стимулы для участия сотрудников: капитальные проекты; ожидания потребителей; внутренняя конкуренция; понимание топов; разработка новых продуктов; производительность и эффективность; манипуляции и кооптации (если не умеете — не лезть, заручитесь поддержкой прямого руководителя и отдайте ему); явные и неявные принуждения (сверху вниз, вплоть до увольнения). Я тут хочу остановиться, и дать ссылку на еще один фреймворк, который Марк Розин рассказывал на ПИР-2021, описание можно посмотреть в моем конспекте. У него четыре метода изменений, два из них — достаточно известны: жесткий реинжиниринг и мягкая сила постепенных изменений, а еще два не столь очевидны: островной метод с постепенным прорастанием изменений и метод блефа с жесткой угрозой и расторговкой, за счет чего сопротивление снижается. А в докладе дальше рассказ на конкретном кейсе реорганизации техподдержки. Аккуратно, с учетом того, что какую-то нагрузку предполагается увеличить — а значит это надо компенсировать, в том числе передачей каких-то функций другим подразделениям, например, на площадку для обучения. А обучение новому повысит их ценность как специалистов — и надо думать про способы удержания. В конце презентации чеклисты, описание этапов, опросник дл проекта и способы борьбы с сопротивлением в разных точках, их можно использовать. У меня дальше пунктирный конспект, лучше взять из презентации. Чеклист: зачем внедряем процесс; какая выгода от внедрения; какие команды затронет, зааффектит; есть ли кто будет против; есть ли те, кто за. Был заполнен для проекта, и Александр его рассказал с комментариями. Этапы.
Опросник на вход в проекте. На 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 фокусируется на когнитивную нагрузку, которая для умственного труда, к которому относится разработка, фактически определяет время выполнения задач. Выделение когнитивной нагрузки — важная фишка. Она связана с удержанием и восстановлением в голове активного контекста для работы с доменными областями. Это не связано напрямую с конкретными задачами, в том смысле, что если идет поток задач из одной области, то переключения не требуется, а вот для выполнения задачи из другой области необходимо сделать отдельную работу по переключению. Получается, что это — характеристика выполнения потока, а не стоимость отдельной задачи. Время переключения контекста — существенное, все мы знаем, что если вдруг прилетела задача по области проекта, который пару лет был стабилен, то чтобы ее вспомнить может потребоваться полдня, а то и пара дней — хотя решение самой задачи может быть дешевым. Так что это надо учитывать при планировании. По когнитивной нагрузке есть опросник, его можно мерять по всем командам и работать с результатами. Способы снижения:
Александр Бындю. Стратегия решает проблемы на всех уровнях компанииАлександр рассказывал про карту гипотез как метод наглядной и понятной для всех визуализации стратегии. Об этом у него есть книга, а рассказ опирается на опыт проведения стратегических сессий во многих компаниях. Со стратегией есть вот какая проблема. Традиционный подход предполагает, что некоторое ядро компании собирается на стратегическую сессию, работает, вырабатывает какую-то стратегию — а потом результаты специально упаковываются и транслируются на всю компанию. По факту при упаковке происходит сокращение и изменение смыслов, и в результате контекст и понимание стратегии в голове у тех, кто был на сессии и тех, кто получил готовое оказывается разный. Карта гипотез — инструмент визуализации, с которым можно работать на сессии, при этом результат получается достаточно наглядный, чтобы не требовать отдельной упаковки — проблема снимается. И простота визуализации тоже важна, традиционные стратегии на 50 страниц текста люди вообще не понимают. Шахматы. Есть цель: выиграть игру до 30 хода, поставить мат. Есть задачи — ходить фигурами. А вот стратегия выигрыша — слепая зона. Научить ходить фигурами в шахматах можно ребенка. А вот стратегия — гораздо сложнее. Кто знает стратегию своего проекта? 10 рук в зале. Итак, есть три уровня.
Пропуск стратегии всем ИТ-шникам известен. К вам приходит бизнес с проблемой, он договорить не успевает — у вас уже готовое решение в голове, только закодировать надо. А потом оказывается, что то, что закодировали не решает задачу. Эффективность стратегии определяется двумя факторами
Если нет описания стратегии, то стратегия все равно есть, просто каждый придумает сам. Каждый надеется за счет чего-то достичь цели. Но у каждого представление о пути свое, и оно разное. Низкая мотивация у людей. Стратегия текстом — сложно читать, воспринимать, вовлечь людей, сложно менять: изменения текста локальны, и надо учитывать связи, а для этого стратегию целиком загрузить в голову, восстановив смыслы. Визуализация — можно создавать совместно, связи проставлены — легко меняем. Типичные проблемы компании без стратегии.
Карта гипотез — метод стратегического планирования для проектирования следующего шага развития. Схема построения: Цель — субъект (чью жизнь меняем) — гипотезы — задачи (почему сработает) Типичная ситуация примерно такая. Нефтянка. Задача — уменьшить травмы на производстве за 2 года. Очень крутая задача. Цель — есть, из нее выписаны задачи на 10 лет вперед. Но трассировки от задач до целей — нет, нет гипотез. Например, есть идея делать ролики про травмы — и снизит травмы. Но это надо превратить в гипотезу, объяснить, почему именно просмотр ролика подействует: люди проникнуться соблюдением правил, или испугаются последствий травм, или еще почему-либо. Разные гипотезы — разные ролики. И важно, чтобы в гипотезе было про тех людей, на которых роликами предполагается воздействовать, что поменяется в них и почему. Аналогично — про каски: что должно измениться для людей, и почему оно изменится. Потому что если они будут воспринимать это просто как блажь начальства и показуху — это не скажется на травмах, зато мотивацию снизит. Еще пример. Компания ставит задачу стать более публичными. Реактивное решение — идем выступать, писать, давать интервью. Но! Было бы неплохо узнать — зачем. Скажут: бренд, узнаваемость. Но дальше спрашиваем: а как узнаем, чего достигли? Если узнаваемость для прибыли или новых заказов — то это одни выступления и публикации. И тут еще надо понимать, на каком шаге воронки продаж фокусируемся: чтобы пришло больше лидов, или чтобы решение клиентами принималось с большей уверенностью за счет репутации. Если хотят в 2 раза больше заявок — то следующий шаг: почему их станет больше: кто-то услышит и придет или порекомендует — это определяет площадки и содержание. А если публичность — для привлечения и удержания сотрудников — то это другие публикации и выступления, на других площадках. Еще пример. Компания ставит задачу на то, чтобы стандарты качества были одинаково высокие.
Когда есть гипотезы — ставим приоритеты. Есть 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- и все. Через пару часов звонил повторно, говорил, что «мы видим сбои» — и у человека ощущение, что звонит знакомый специалист, и человек делает все, что скажут. При этом надо обходить триггеры, всех учат «не сообщать пароль», поэтому он говорил «надо сменить пароль, я пришлю ссылку, перейдите, сгенерите пароль» — ссылка вела на его ресурс, он получал данные. Полноценно нельзя защититься — мозг не патчится. Но на старте можно научиться прерывать контакт:
Еще работают блокировки, которые снимаются только на следующий день так, что нужна пауза. Еще лучше, чтобы был нужен визит в банк, но тут уже страдает удобство. При этом атаки — не целевые, а массовые. Звонок от имени начальника или знакомого — тоже автоматизировано, скриптами и массово. Целевые атаки начинаются с очень высокого уровня владельцев и топов крупных фирм и корпораций, на котором служба безопасности всерьез работает, и это — другая история. С подменой номеров бороться начали давно, подмена на коротки и городские — забанена уже несколько лет, а вот подмену на сотовые технически тяжело закрыть при соучастниках-админах, которые держат оборудование. Идеи, что нельзя отдавать свой голос — это все мифы и испуг. Конечно, нейросеть сейчас может синтезировать голос. Но атаки «мама я попал в аварию» были 15 лет назад, когда этого не было, а родственники уверенно отвечали, что был правильный голос — потому что стресс, короткая фраза, потом трубку брал другой человек. Евгений Антонов из Яндекса. Всё, что вы хотели знать о демотивации, но боялись спроситьМного разговоров про мотивацию, но очень мало — про демотивацию. А демотивации вокруг — очень много. От нее — ущерб. Что такое — демотивация?
В отличие от выгорания, демотивация идет на фоне ярких эмоций. При выгорании на эмоции уже нет сил, она на фоне усталости. Есть теория двухфакторной мотивации по Герцбергу: гигиенические и мотивационные факторы, необходимы плюсы в мотивации и отсутствие провалов в гигиене. Бывает, что в гигиене хорошо, но мотивации — нет. Он по аналогии сделал двухфакторная демотивация по Антонову.
Внешние факторы
Внутренние факторы.
Конкретные истории.
Если люди расстраиваются и забивают на работу — компания теряет миллионы. Он видел команду, которая специально имитирует работу: им на нас наплевать, а нам — на них. Демотивация распространяется между людьми и командами — это заразно. Как распознать демотивацию.
Тут важны не только обсуждения, но и опросы: 1:1, общие, анонимные, публичные… Профилактика — лучшее лекарство. Уважение. Что делать, если не уследили?
Важно думать о мотивации, но не менее важно думать о демотивации. Делайте хорошо, а плохо — не делайте! Что делать, если ты в демотивированной команде
Алексей Цыбульник. Предупреждён — значит вооружён. Что следует ожидать ИТ сотрудникам от эволюционных измененийРазличают два типа изменений
Нормативные — легче. Понятно, что грань — не очевидна, но важен режим эксперимента и возможность отката назад. В Agile два самых известных метода — Scrum и Kanban. Scrum — это структурные изменения, революцию. Ты не тестировщик, мы все — равная команда. А Kanban — эволюция, он начинается с нормативных изменений. С структурные — не сразу, и только если выяснится необходимость. Канбан-метод никогда не даст процесс «как надо» — он поможет подстроить ваш процесс. Принципы перехода на Kanban это поддерживают.
Дальше был рассказ про Kanban STATIK, но с необычной точки зрения: что каждый из шагов дает команде.
Накидали кучу проблем — а они сохраняются, действия не делают. Значит есть какие-то причины.
Лев Ушаков. Управление состояниями команды для решения творческих задачЛев — тренер творческих состояний. Эту профессию придумали в Сколково в 2014, она появилась в списке будущих профессий. В 2017 появились люди, которые начали пробовать, сейчас 72 русскоязычных специалиста в 11 странах, идет институализация. Подача доклада — крутая. Сначала — движуха, чтобы получить активность и вовлеченность. Самооценка — состояние, активность, энергия — разными жестами, 5 баллов, 10, высота. Перекидывание мандаринов после контакта взглядом. В аудитории — контакт, чувство безопасности, настроение. Мышление — в головах, но часто — коллективно и интерактивно. И важны условия для группового мышления. Мышление не живет отдельно от твоего состояния. Зум с камерами или без них — разные ситуации. 3 системы: человек — команда — компания, в креативной экономике. Состояние человека: физическое + психоэмоциональное + когнитивное + свойства личности. Плюс внешняя среда. Когда заходит топ — как реагируют люди в комнате. Есть ли безопасность и возможность ошибаться, говорить что думаю и так далее. Состояние — не просто сейчас. Есть проект 2-3 месяца. Есть динамика состояния человека, когда он в лучшей форме. Различают оперативное (20 сек), текущее (от 2 минут до дня) и длительное (любовь, депрессия и другие). Разработчики, дизайнеры, ученые — у всех может быть творческий кризис. Остановка движения. Творческие инсайты случаются при отвлечении. Прогуляться, пожонглировать. Иногда хватает пары минут — недолго. Важно, чтобы не было переключения с фокусом. Пирамида: состояние — мышление — действия — результат. Вирус в человеке. Он появляется, температура поднимается — а потом иммунитет борется и в следующий раз быстро подавляет. В удачном сценарии. Вирус не-адаптивное поведение. Художник в среде разработчиков, менеджеров — может стимулировать креативность. И иногда такое не-адаптивное дают внутри. Транзакт-анализ: родитель — взрослый — ребенок.
Расширение модели: контролирующий родитель — заботливый родитель и адаптивное дитя — естественное дитя. У всех свои особенности. Адаптивное дитя — часто подавленная энергия. Естественное дитя — берегов нет. Этапы решения
Это показывает, что важно своими состояниями управлять. Динамика между тактами работы
Сессия, встреча в усталом состоянии — бесполезна. Начинать надо с себя. И с команды — чтобы среда была привлекательна топ-специалистам. Смузи — уже не привлекает. Елена Колесникова. Развитие команды через командный коучингЕлена — руководитель команды обучения и развития персонала в Directum. Это компания-вендор, 900+ сотрудников, площадки — Ижевск, Москва, Уфа, Тюмень. Ее команда learning and development разрабатывают и проводит обучение внутри компании. 3 менеджера по обучению и развитию + 2 тренера + она — лидер и тренер. Командный коучинг — одна из техник, которую они предоставляют другим командам. За два года через него прошли 15 команд: разработчики, продажи и другие. И каждый раз это работа по конкретному запросу.
Рассказ был на конкретном кейсе ее собственной команды. Они на очередной рефлексии поняли, что нет цели команды вдолгую. И что по конкретным задачам, например, организации обучения, неясна ценность для бизнеса: вроде, если его не проводить — ничего страшного не будет, так может, и вообще ценности нет? Тут особенность в том, что в компании еть OKR, но цели каскадируются только на бизнес-направления, а их подразделение — вне этой системы. Кейс — понятный. Обычно у них коучинг проходит в очном формате примерно два дня. но они решили сделать распределенный. Поставили регулярные встречи по 2.5 часа, но наложили дополнительное условие: должны присутствовать все члены команды. Поэтому 6 встреч заняли полгода. Суммарно по времени — те же два дня. Техника решения — через пирамиду Дилтса: окружение — поведение — способности — убеждения — идентичность — видение. Нижние уровни прошли быстро, а вот на уровни убеждений, помимо общего, проявились разные установки. С тем, что не всем нужно обучение в моменте и тем, что компания вкладывается в сотрудников — все согласны. А вот по поводу того, кого нужно обучать есть разные мнения: одни полагают, что только по явному запросу бизнеса, а другие — что надо помогать каждому, если есть запрос. И тут было нетривиальное решение: принять различие ценностей, а не пытаться всех выровнять. Это — уважение права человека на свои убеждения. Дальше были уровни идентичности — кто мы, и видения — для чего работаем. Тут открыли много нового. Но получили согласованные формулировки. Они были в презентации, они длинные и достаточно общие, и смысл не в тексте, а в том, что они — продукт понимания каждого человека в команде, в процессе согласования они были интериоризированы каждым. А потом вернулись к ценностям, взяли объединяющее, учли идентичность и видение — и сформулировали 7 штук, они тоже есть в презентации. Там достаточно подробные формулировки, но смысл, опять-таки, в совместном обсуждении. И дальше — миссия. Каждый сам формулировал, потом делали объединенную. Для миссии — снова прошли пирамиду Дилтса через 5 лет, но такой, как она будет через 5 лет. И тут как раз уровень окружения становится не очевидным: какой через 5 лет будет компания, сколько сотрудников и какие они. Ведь очевидно, что придет молодежь, которая как-то будет отличаться от нынешней, и надо понять — что важно. И новые технологии — они тоже изменят компанию за это время. У них получилось сформулировать цель, из нее — четыре направления развития и дальше — задачи, которые можно начинать решать уже сейчас. Коучинг завершился, проблема решена. Что получили.
А регулярные встречи они оставили — для общей работы над развитием технологий работы подразделения. В общем, такая история. Она интересна, но лично для меня — относительно очевидная. Было бы интереснее услышать в докладе не одну историю, а некоторый обобщенный опыт по применению инструмента, иллюстрированный, естественно, конкретными кейсами. Все-таки, было 15 штук, это достаточно много. В конце были рекомендации, но они — общего характера, понятные: коучинг — для сложных задач, требующих коллективного мышления, не для операционки. Он требует доверия в команде, достаточной зрелости. И имеет смысл только для долговременных команд. Технические докладыНа конференции их — абсолютное большинство, просто мои интересы больлше в области менеджмента. Поэтому выборка — не репрезентативна. Вадим Царегородцев из Островка. Вперёд в прошлое! Или как подружить чистую архитектуру и RSCRSC — это React server component, новая возможность React, который позволяет вести рендеринг на серверной стороне. Доклад был о том, как и для чего это использовать. Если кратко, то старый подход можно описать формулой ui = f(state). При этом state размазан между фронтом, бэком и базой данных и идет бесконечная синхронизация между ними. Серверные компоненты позволяют поменять формулу на ui = f(data)(state), при этом данные всегда достаем из базы с любого уровня, это убирает потребность синхронизации. И получается проще. Детали надо смотреть в выступлении, там было много технических деталей, в которых я, увы, плаваю, потому как на react не разрабатывал… Кирилл Святов. Архитектура систем управления наземными высокоавтоматизированными транспортными средствамиКогда говорят про беспилотный транспорт в России, то все вспоминают Яндекс и КАМАЗы, которых не так много. Но еще есть грузовики, которые уже активно работают на складских и промышленных предприятиях. без выезда на дороги общего пользования. Я об этом слышал несколько докладов на других конференциях. А Кирилл говорил о беспилотниках для сельского хозяйства. Там много особенностей. Во-первых, рассчитывать на разработку принципиально новой беспилотной техники — не реалистично. Вместо этого на существующие УАЗ и Газели устанавливают дополнительное оборудование, превращая их в беспилотники. Во-вторых, там большое разнообразие задач с разным дополнительным оборудованием — транспорт, разбрызгивание удобрений и химикатов, другое навесное оборудование. И движение не по дорогам, а в полях, с разными условиями. Профит — в том, что автопилоту не нужна защита от химикатов, а еще он не устает, и в подходящих погодных условиях может работать круглосуточно. Но при этом, в отличие от других проектов, есть потребность создавать не одну программу управления беспилотником, а много разных, с учетом многообразия выполняемых задач. И они делают платформу. которая позволит создавать такие программы не с нуля, а на основе готовых компонентов. Платформа включает следующее.
Построено все это на базе 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.
Но есть ложка дегтя. Или даже бочка. Связанная с тем, что это — не 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).
И усугубляется это подходом «фреймворки — зло, лучше напишем сами», так считают многие. Отношение к этому может быть разное.
Как поддерживать?
Дальше была история, как он для своего продукта делал валидаторы. Для начала он поискал, чтобы использовать: может, оно уже есть, стандартная же задача. Не обнаружил. Пошел в основную команду разработчики, там сказали «да-да, мы как раз собирались делать, давай ты и сделаешь для всех, а не только для себя». Требования понятны: от широко используемого фреймворка, большое количество готовых правил из коробки, возможность дописать специфичные правила, простота использования. Варианты: illuminate/validation laravel, symphony/validator; laminas-validator. Посмотрел их. Выбрал знакомое. Реализовал, там был рассказ, особых проблем не было. Есть проблема: фреймворки обычно не рассчитаны на автономное использование. Поэтому одна библиотека валидации тянет полфреймворка, почти 40 компонентов. В symphony n laminas с этим полегче, но десяток все равно тянется. Но конкретно для них проблемой не было, так как компоненты laravel в проекте уже использовались. А так на это стоит обращать внимание. Алексей Романов. Неудобные вопросы про RESTful или как проектировать API, чтобы не было так стыдноРассказ о концепциях RESTful и о разработке API с соблюдением этих принципов. Казалось бы, капитан очевидность. Если бы не множество примеров, как делают api без их соблюдения, которые былри в докладе. И тут есть не только технический аспект: используя api или разбираясь в коде, люди предполагают, что принципы соблюдаются, поэтому отступление от них усложняет использование. А с api есть сложность: вам часто надо поддерживать обратную совместимость. Так что если вы сделали плохо, потом переделали хорошо и красиво, старый вариант все равно остается. Доклад — для того, чтобы сразу делать красиво. Концепция RESTful:
Отличие от rpc в том, что там вы можете вызывать произвольный код. И можно создать смешанное api, например, упаковав создание нескольких сущностей или действие над ними в один вызов. Я хочу отметить, что в целом разница между RESTful и rpc — это разница объектным и процедурном подходами, примененными к api. Но, помимо концептуальной разницы есть техническая: RESTful предполагает http и синхронное взаимодействие, а у rpc таких ограничений нет. И потому может быть целесообразно использовать rpc, сохраняя при этом принципы RESTful при реализации классов и процедур, к которым предоставляется доступ. И еще я хочу отметить, что те, кто придумывали RESTful перенесли на него шаблон создания сущности с генерацией ключа на стороне сервера. Это уместно и удобно при работе с базой данных, когда у вас есть сессия и транзакции, а вот при взаимодействии при отсутствии транзакций и отсутствия гарантий доставки это — неудобно, так как не дает идемпотентного создания ресурсов. Спецификации типа Json-rpc решают эту проблему. Вообще сравнение RESTful и Json-rpc было в другом докладе. Впрочем, создание сущностей можно делать через put, а не post, и тогда создавать ключ на стороне клиента. Вообще, общий принцип: put и patch — идемпотентны, post — нет, а get — лишь запрашивает данные, поэтому его можно кешировать — в отличие от других запросов. Важный принцип — uri ссылается на ресурс, а не на действие. Дальше пересказывать доклад я не буду, смотрите презентацию. Потому что основная суть — не в описании протокола, который всем известен, а в паттернах и антипаттернах применения, которые были на слайдах. И их надо смотреть. Использование может быть в двух режимах.
Согласование спецификации до кодирования важно: иначе можно сделать api, которое не пригодно пользователям для их целей.
Екатерина Неделина и Ян Шишеня из Газпром Нефть. Новые «люди»: как ИИ-сотрудники меняют бизнес-ландшафтПока теоретики спорят о то, что ChatGPT может, а что — нет, практики делают виртуальных помощников, на которых перекладывают конкретные рабочие задачи, например, по первичному отбору кандидатов, по помощи заказчику сформулировать вакансию или задание на разработку или по исследованию данных по публичным источникам. Речь идет о проекте Профессионалы 4.0, задачей которого является привлечение фриланса на проекты. Начиналось с ИТ, там люди часто не хотят устраиваться в штат к корпорациям, но не против поработать в конкретном проекте. А потом распространилось на других специалистов, часто редких, напримеР, почвоведов. Сейчас там 45к спецов в базе, при этом от бизнеса идет большой поток проектов, около 3к. И есть задача — выбрать профи, сопоставив описание проекта и требуемых ролей с резюме специалистов. Проект вырос из того, что Ян, работая как бриф-менеджер по созданию документов на основе беседы с бизнесами, решил привлечь к этому делу ChatGPT и получилось настолько удачно, что опыт решили развивать, искать другие места в бизнесе, где помощь ИИ-агентов была бы уместна. Это было на слайдах. В результате уже создано четыре виртуальных помощников с разными специализациями, о которых рассказывали в докладе, показывая, что под капотом.
Хотя начиналось все с Дианы. наиболее продвинулось создание Wendy. Работает с июня, почти год. Экономия 50-70 % сотрудников на выполнение рутинных задач. Результат стабильный, объективный на любых объемах. Например, сравнение кандидатов. А заказчикам дает новые возможности сервиса. Что делает Wendy?
Чтобы построить методы обучения кандидатов, работали с выборкой 3000 откликов, которые оценивали люди. И построили несколько альтернативных методов оценки.
По всем оценкам — требуют аргументацию. Нейросеть ищет позитивно, но мы цепочкой промптов заставляют выставить балл и обоснование — там довольно сложная цепочка, 4 промпта, и каждый 2 страницы. Оценка кандидатов человеком по-прежнему остается, но по опыту использования, люди перестают ее заполнять для всех откликов, смотрят только те, что ИИ-агент оценил высоко по каким-то критериям. Бывает, что оценки человека и нейросеток расходятся. Они анализировали соответствие. И поняли, что есть кейсы, когда люди оценивают хуже. От заказчика по результатам собеседования идет обратная связь, ее учитывают для дальнейшего обучения. Раньше в talent team два админа, которые обеспечивали коммуникации и так далее — рутину. Сейчас один на других задачах, а второй — частично, больше занимается коммуникациями. Робинзон. Ищет актуальную информацию по открытым источникам, готовит в структурированном формате отчета. Вопросы разные: про тренды, просят конкурентный анализ, просят оценить кандидата, или наоборот, спрашивают, стоит ли присоединиться к команде, спрашивают про современные методы обучения, например, сварщиков, про размеры зарплат, просят обзор маркетинговых стратегий. Построена специальная система оценки ответов, для генерации без глюков, проверки ссылок. Екатерина задавала вопрос про профессиональные сообщества — ChatGPT отвечал с глюками, а Робинзон это отсеял. Как это работает? Это — последовательность запросов к ChatGPT и в системы поиска. Сначала Робинзон определяет свою роль. Затем семантически расшивает запрос, делит его на кусочки и варианты. Затем эти запросы выполняются в поисковых системах, берут 10-15 верхних ссылок и источники из них. Затем делает отчет, объединяя их. Дальше агент, которые проверяет стыковки, и говорит предыдущему «перепиши, фигня», если их нашел. Используется ChatGPT-4 или 3.5 — они оптимизируют стоимость. |
Блоги друзей |
