В Петербурге подряд прошли конференции Saint Highload и Saint Teamlead, и поэтому я публикую общий отчет с обоих конференций. Конференции, в целом - не сильно отличаются от соответствующих московских по общему направлению. При этом доклады - не повторяются, так что имеет смысл быть и в Москве и в Питере. Питерские меньше московских, но собирают по 1000 участников каждая, так что нет впечатления, что они камерные, как было на первых, уже нет.

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

Организаторы, помимо обычных докладов, стремятся дать на каждой конференции какую-то тему. Для Saint Highload это были обзорные доклады по истории - архитектуры, языков программирования, способов интернет-атак и так далее. А на Saint Teamlead - доклады про психологию от профессионалов, не только психологов, но и психиатра. Все это есть в моих заметках по докладам.

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

Происходящее актуализирует тему личного самоопределения. Этой весной профессиональное самоопределение оказалось завязано на геополитику гораздо сильнее, чем раньше. И принимать решения о том, как жить и действовать дальше, самоопределяться приходится гораздо чаще. Об этом было мой доклад Как строить образ будущего и идти к нему - схемы самоопределения (Saint Teamlead-2022) - я давал схемы, которые позволяют думать о самоопределении системно. При этом многие из них нужны не только для самоопределения, но и для коммуникации, понимания других, постановки цели, работы с собственным драйвом от деятельности и так далее. Это все смежные темы, и без них самоопределение не слишком получится. Поэтому схем - много, а доклад - обзорный. Но по части из них у меня есть материалы, а по другим - готов подробнее ответить.

Ну а теперь - про доклады. Только не забывайте, что на обоих конференциях было по 6 треков, так что у меня - малая часть. А из тех, что я слушал, я бы особенно отметил доклад Филиппа Дельгядо про микросервисы и Никиты Логинова про отличие мышления экспертов на основе реально научных исследований. Еще я бы отметил доклад Дениса Васина про блокчейн в корпоративной архитектуре, там было про технические и социальные аспекты, которые делают такое решение уместным. Но другие доклады тоже реально интереснее, перечитывая заметки, которые я публиковал в ходе конференции при переносе в отчет я снова это вспомнил.

Содержание

Saint Highload

Александр Тоболь. Архитектура: история и будущее на примере ВКонтакте

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

Но самое интересное - про архитектуру, и в чем разница между архитектурой и структурой. Александр считает, что то что обычно называют архитектуру - это структура конкретных приложений. А вот архитектура - это принципы, по которым архитектура разрабатывается. Надо будет обдумать этот тезис. Конечно, тут вопрос терминологии, но вот про принципы - важно. И в смысле этого определения архитектуры может не быть, в делаете структуру по месту, без всяких принципов. И так не просто можно - у Александра тезис о том, что over engineering еще хуже, чем ad-hoc без всякой архитектуры. В любом случае, Архитектура слишком сложна, чтобы архитектором был один человек, это дело коллективное. Но Архитектуру ВКонтакте в смысле принципов Александр НЕ рассказал. Он рассказывал только структуру.

История web

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

Wed 1.0 по 2003. Web 2.0 - социальные сети. С web 3.0 - проблема. Все думали, что будет AI и всякие помощники. Но все закрылись, весь контент стал внутри каждой сети отдельно. И открытой системы не случилось.

По Вконтакте - пересказывать не буду. Там кэши и балансировка, оптимизация хранения, куча собственных решений, таких как собственный RPC поверх UDP. Из интересного для меня - язык KPHP, который сначала был транслятором на C++ для производительности, теперь транслирует в бинарники и там при совместимости с PHP есть контроль типов, шаренная память, параллелизм. А по железу - отказ от RAID, потому что если сервер работал 10 лет и остановился - все диски не стартуют. Поэтому распределенное хранение на многих серверах с восстановлением памяти.

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

Выбор языков становится все важнее по мере того, как ИТ становится основой бизнеса. Основной тезис доклада - что выбор языка ситуативен, определяется контекстом проекта. И он многофакторный: стоимость начальной разработки, стоимость поддержки и модификаций, производительность, надежность кода, экосистема, стоимость обучения.

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

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

Правда, это - про JIT-языки первого эшелона - Java, C# - с которыми работают серьезные команды, которые делают JIT-компиляцию. Для динамически компилируемых языки второго эшелона JIT (Python, PHP) - хуже. Но для них есть своя ниша. Так же как для интерпретируемых (Lua и др.). Именно потому, что выбор - многофакторный и для разных проектов важно разное.

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

А еще сильное упрощение - программа никогда не заканчивается не по своей воле, сохраняется при перезагрузке сервера, с ее точки зрения это была пауза. Это идея Phantom OS. У тебя данные в переменной лежат вечно, не надо ничего сериализировать, более простой код, нет ограничений для структур данных, мгновенный перезапуск. Например, вы рисуете график от датчика - вместо сохранение истории в файл у вас три строки: получил цифру - поставил точку на экране, и она там будет всегда, не надо перерисовывать при перезапуске программы. Это - тоже возможный вектор развития.

Станислав Сидристый. Гибридная архитектура: разделяемый на микросервисы монолит

Обычно такие доклады - про то, как из большого монолита выделяли микросервисы, вплоть до полного разделения. А у них - обратная задача. Есть масштабируемое решение текст-голос, под обработку большого количества сообщений, хорошо масштабируемое. Но приходят клиенты, которым масштабирование не нужно, у них - малые объемы. И им нужно развернуть все это на малом железе без накладных расходов. Идея - разделить сервис на модуль, в котором содержательный код, и оболочку, которая завертывает его в сервис. И научиться заворачивать в сервис сразу много модулей, управляя этим на уровне конфигурации сборки. Получим один поток, общую память и так далее. Они сделали, выигрыш по памяти в 5-7 раз, по производительности вдвое. При этом важно еще подменить межсервисное взаимодействие по http/mq на прямые вызовы, чтобы и тут получить выигрыш, для этого у них библиотека.

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

Антон Быстров. Dashboard as a code, или Путь от правок в UI до grafonnet

Задача. Когда у вас множество дашбордов. Стандартный способ создания dashboard - через UI, при сохранении получается примерно 5к строк кода на dashboard. А дальше возникает задача доработать какую-то конкретную панель, которая присутствует сразу во многих дашбордах. Конкретно у них возникла задача про панель, которая была на 50 дашбордах. И вносить идентичные правки через UI - тяжело и дорого. Можно напрямую править описания, но это на свой страх и риск. Они начали искать способ, инструментов - несколько, есть на Kotlin и Python, а они выбрали Grafonnet. Это средство на основе jsonnet, который создавался в Google для описания конфигураций, развитое для Grafana, где есть набор шаблонов для описания именно дашбордов. И дальше был рассказ с примерами кода, как это делается. При этом сначала новый дашборд делают через UI - потому что по текстовому описанию сложно представить, как будет на экране, удобнее накидать визуально и потом - переводят в описание json для grafonnet. В целом работает, есть сложности с обновлением версий Grafana - нет совместимости шаблонов, надо вручную.

Денис Васин. Блокчейн в корпоративной архитектуре — дань моде или необходимость?

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

Копия базы лежит у каждого участника. А вот исполняют смарт-контракты только валидаторы, к ним особые требования по инфраструктуре. И для исполнения 2/3 вадидаторов должны придти к консенсусу по исполнению смарт-контракта - тогда блок принимается. Один валидатор собирает новый блок, а остальные - подтверждают, после этого блок публикуется с подписями валидаторов. При этом валидатор-лидер меняется, это - не выделенная точка отказа.

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

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

Александр Поломодов. Канал. Продукт. Платформа, или Эволюция подходов к развитию мобильного банка Тинькофф

Доклад про эволюцию разработки от первого приложения, сделанного на заказ через инхауз-разработку, которую ведет одна команда, пусть большая на 50 человек, к множеству feature team. А сейчас следующий шаг - feature team делают вниз от мобильного приложения через APIs к Backend. Важно, что при этих переходах надо не просто реорганизовывать команды, а реструктурировать софт, потому что работает закон Конвея, пока софт делала одна команда - был монолит, а теперь это надо поменять. При этом ситуация осложняется тем, что мобильное приложение поставляется как бинарное приложение, его нельзя разделить на микросервисы, поставляемые раздельно.

Интересно, то при переходе на сквозные команды Mobile - APIs - Back изменилось проектирование: от описания изменений экранов и API перешли к описанию user story, которые дают целостную картину изменений.

Наряду с feature teams есть core-команда, но у нее задачи - не общая платформа или библиотеки, а инфраструктурные вещи: архитектурные подходы по модульному делению; надежность через мобильные SRE и фиксацию проблем; масштабируемость - как мерить просадку, и лучше на тестах, а не у пользователей.

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

Еще в докладе была ссылка на книгу Team Topologies. В ней описаны триггеры потребности в эволюции команд: софт стал чрезмерно большим; темпы поставки значительно замедлились; бизнес-сервисы опираются на разрозненный набор нижележащих, собираешь паззл. И симптомы по каждому, это было в презентации. А еще типы команд и взаимодействий, и это помогает конструировать ваш набор команд. Типы: streamed-aligned команды, enabling, complicated subsystem, platform team. Взаимодействие: collaboration, as service, facilitating. И это использовалось при переходах как шаблоны.

Филипп Дельгядо. Микросервисы через боль и превозмогание

У Филиппа всегда очень емкие и насыщенные доклады. Поэтому практически конспект по тезисам. Микросервисы - 150+ определений. Определение Криса Ричардсона с microservices.io, там часть - пожелания, а часть - про организацию. При этом у него были проекты (и малое приложение и enterprise). Его определение тоже социальное: много компонентов (5+), много баз данных, современные протоколы, современные подходы к разработке.

Зачем нужны. Крис много пишет, частично копируя определение. При этом многое вовсе не есть черта микросервисов, а частично и противоречат. И даже если это - правда, вопрос - что мы платим. Проблемы:

Зачем же они?? Пример - продажи.

Если монолит - то все это должно быть у всего монолита, и это - сложно. Если мы поделили на микросервисы, то:

Далее часть - как работать со сложностью - у нас множество взаимодействующих микросервисов. Есть инструменты

Дальше набор источников

Надежность

Варианты для саги

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

Не сага: мы выполняем по-шагам, запоминаем результат, при сбое - повторяем сценарий, пропуская уже выполненное. При таймауте и ошибках - сценарий отмены. Есть средства - Cadence, Temporal, Comunda, можно сделать свою библиотеку.

Аналитика - нет решения. Подходы типа Data mesh и другие - скорее называют проблему, они все сложные. Есть микропаттерны и советы.

А еще проблемы

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

Михаил Малышкин. Как сэкономить на масштабировании, переехав с Cassandra на Scylla DB

Понятный доклад о переезде. Рекомендательный сервис для банков по данным мобильных операторов - экспресс-оценка заемщика, жесткие требования по ответу сервиса, и как следствие - по ответу БД, при этом БД ежедневно 800GB новых данных. Проблемы: всплески latency на garbage collector, фантомные данные после подключения ноды после падения - откуда-то подтягивались, они не мешали, но беспокоили, загрузка данных 12 часов - не укладывались в ночь, дорогое масштабирование (12 нод в кластере и вкидывание новой - не давало прироста).

Переход на Scylla показался quick win. Она совместима по протоколу. Думали, что за 2 спринта, оказалось чуть подольше. Сделали кластер 3 нод, зеркалирование запросов, чтобы оценить скорость выполнения и запустили сравнительный - мониторинг - время отклика меньше.

Проблемы

Что тестировали

Результаты: избавились от фантомов, упростили инфраструктуру (5 нод вместо 12, пробовали 2 добавить - оказались лишние), удешевили масштабирование. ускорили загрузку - 7-8 часов вместо 12, избавились от пиков. В целом Scylla обходится в 1.5 раза дешевле при лучших характеристиках.

Проблемы эксплуатации. Мониторинг. Scylla дает 1500 метрик на каждый сервер, которые в развертке по времени превращаются в 150к точек, Prometheus не очень хорошо себя с этим чувствует, все метрики нужны. Надо ограничивать CPU и память, иначе она заберет все, и все убьет. Не усмотрели за диском - тоже надо, чтобы не сожрала весь диск и ушла в аварию.

После доклада - много вопросов, на такой переезд смотрят многие.

Дарья Петрова. Цифровизация бизнеса на базе Jira: от сейла до бухгалтера

Рассказ о том, как Jira из инструмента разработчика сначала стала использоваться для управления проектами (пилоты и внедрение), затем охватило остальные отделы - бухгалтерия, юристы, а затем - заменила CRM. Драйвером первого этапа была интеграция проектных задач с задачами разработки, которые обеспечивают их выполнение. При этом потребовался технологический отдел, который бы прорабатывал технологичное использование Jira, обеспечивал потребности пользователей, так как там не очевидные решения и надо сопрягать потребности разных команд.

Когда топы начали видеть проекты в Jira у них было желание подтянуть туда все процессы компании. Но административно это не сработало, не взлетало. Путь был иным, через success story. сделали в Jira внутренний Service Desk и управление потоком кандидатов - там были готовы меняться. Процессы затрагивали все отделы, и попробовав работать с ними, другие отделы тоже захотели для своих задач. Ведение задачи в Jira стало частью корпоративной культуры.

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

И последний такт - продажи, там была своя CRM. Большинство CRM - на большой поток коротких продаж, а у них поток невелик, а продажи длинные, до трех лет. Сначала был Excel, по мере роста Мегаплан, Битрикс, в 2017 выбрали Zoho CRM, но проблемы с аналитикой везде были, и Excel сохранялся как параллельная штука. При этом внутри продажи запускаются пилоты и проект внедрения, это - в Jira. Проблема двух систем - систем - ручной перенос, у сейлов нет доступа к задачам разработки, а у Product Owner не было доступа к CRM. Плюс Zoho CRM - облако, там проблемы. B 2020 еще раз анализ. CRM - под потоковые продажи, SalesForce - очень дорого и много лишнего. А в 2021 году коммерческий директор понял, что все остальные - в Jira, увидел аналитические отчеты, которых ему не хватало - и решился на переход. Они с Jira сделали интерфейсы под account manager, визуально аналогичные проектному менеджменту (она показывала скрины) и аналитику по воронкам продаж. Разработка CRM в Jira - 650тр, это полгода использования Zoho.

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

Евгений Лукин. Как не провалить импортозамещение. Меняли в Сбере шину данных, а сделали платформу

На входе - MQ на IBM Web Sphera. Отдельные команды интеграции - перегружены - задача от постановки в очередь до решения 1 год при длительности выполнения 5-7 часов. А еще - централизованное решение перестало работать даже на топовом сервере, потребовалось много шин под разные данные и выросла сложность.

Идея: принципиально изменить способ интеграции, чтобы ее могли делать сами разработчики, и отдельных команд интеграции было не нужно. Взяли Service Mesh. Интеграция описывается через Yaml-конфигурации, и могут делать сами команды разработки. Это было в идеале, а на практике разработчикам надо было научиться писать Yaml и это оказалось сложно, Yaml реально много. Они начали обучать, но этого не хватало. Сделали внутренний dev-портал, где разработчик начинает разработку. dev-труба, sizing, готовые схемы интеграции. SyMPLe. B Yaml-файлики автоматом генеряться, какая-то тестовая интеграция уже ходит.

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

И дальше было много разных доработок. Горизонтальное масштабирование. В теории можно растягивать на кластер, а потом - освобождать. На практике старт - по использованию CPU. Но старт подов - дорого до 40 секунд и ресурсоемко. А вот на Go - старт быстрый. И по производительности тоже. В результате ключевые компоненты, в частности адаптер MQ переписали на Go.

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

Плата ресурсами за надежность. Два дата-центра и балансировщик. И в каждом ЦОД под должен быть поднят, а лучше два для дублирования, потому что между дата-центрами не перекидывают трафик - и получается дорого. Перешли на Federated Super Mesh. В результате если в одном ЦОД упало, трафик перенаправят в другой - можно не дублировать.

Стандартного OpenSource в Enterprise не хватает. Например, визуализация подтянула все связи кластера - out of memory. Или service mesh - рассылает все файлики всем, а у вас 10к сервисов и файликов - надо рассылать умнее.

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

Резюме - совмещайте импортозамещение с решением архитектурных проблем.

Даниил Разумов. Общий флоу разработки в Ozon. Как сделать жизнь разработчиков проще?

Идея проста: flow доставки приложения на тест, а затем - на прод - достаточно сложная конструкция. Поэтому при множестве сервисов эффективно сделать стандартные потоки, которые настраивают специалист, которыми бы пользовались все команды. Это они и сделали, около 40 вариантов flow собраны в проект в git, и в проект включают подходящий. Но это потребовало определенной стандартизации процесса разработки - всегда в feature-ветке, с процессами тестирования и стандартизации состояний в jira, так как проход по flow должен отражаться в движении тикетов в jira, например, первый комментарий с тикетом - сигнал к переходу в InProgress, merge request feature-brahch синхронизован с переходом в InReview и так далее. Синхронизация с jira особенно важна на конечных этапах, когда релиз со многими задачами движется целиком.

В докладе был подробный рассказ на примере flow для Go. На мой взгляд, рассказ излишне подробный, потому что flow - относительно очевидный. Интереснее было бы, наверное, остановиться на каких-то важных особенностях, которые появились не просто так, а дали конкретный эффект. Или рассмотреть разные стратегии для обновления прода. Или сравнить разные flow, если есть не очевидные отличия - не зря же их 40 вариантов. А подробные схемы - оставить как приложение к презентации. Но все равно, оклад был интересный и актуальный, вопросов в конце было много.

Анастасия Абрашитова из Яндекса. Вторая космическая: как преодолеть притяжение внутренней платформы разработки и выйти в открытый код

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

Профит

А в дальнейшем - самостоятельно коммерческому успеху продукта.

Георгий Тарасов. Эволюция распределенных атак в Интернете: 1994 — настоящее время

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

Saint Teamlead

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

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

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

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

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

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

Виталий Леонов. Приборная панель тимлида. Как оцифровать все и спать спокойно

В докладе - подробно рассказан набор метрик, которые показывают здоровье команды по трем направлениям: техническое качество, процессы, команда. Метрики в целом хорошо известны: стоимость инфраструктуры на пользователя, среднее время отклика, cumulative flow diagram, lead time for changes, текучесть сотрудников, скорость онбординга и так далее. Так что ценность тут, скорее, про то, что дан некоторый исчерпывающий список, которого достаточно. Но вот выбор именно таких метрик - раскрыт слабо, при том, что метрик довольно много.

А еще в метриках самое интересное - не смотреть как они ползут на графиках, и фиксировать проблемные ситуации и разбиратьcя в них. В докладе был один пример - вырос scope drop и волатильность velocity, разбор показал, что продукт начал нового проджекта, которому не передал договоренности по работе с командой, и это начало стрелять. Договоренности восстановили, метрики исправились, потом их еще зафиксировали в артефактах и включили в онбординг. В ответах на вопросы был еще один пример: именно метрики найма позволили выявить, что менеджеры фейлили сроки своих интервью, этап затягивался и появились не профессиональные сотрудники. Примеры - хорошие, но их явно мало. Я понимаю, что это - очень много материала, только по метрикам процесса Канбана Пименов делал отдельный доклад, а это примерно восьмая часть состава метрик. И у него про борьбу с текучкой через метрики был отдельный доклад на прошлом тимлиде. Но все равно, тут хочется больше материала, хотя бы в виде ссылок А еще, думаю, это в каком-то виде можно было бы говорить в презентации метрик: не раскрывать, что она меряет, тем более, что для многих это очевидно, а говорить про назначение и направления анализа при инцидентах

Никита Логинов. Мышление эксперта. Как опытные специалисты принимают решения

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

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

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

А дальше - конспект, потому что интересного много.

Что именно отличает эксперта от новичка.

Примеры, которые считаются универсальными.

Постановка точных диагнозов в медицине. Не-специалисты - студенты - закончившие обучение - 10 лет работы. Число точных диагнозов с профессионализмом возрастает, ожидаемо. Интересно: через 10 минут просят вспомнить кейс - оказывается, что эксперты кейс быстро забывают, в отличие от предыдущих. А это значит, что эксперты работают на интуиции, а не на рациональном мышлении. Я: отчасти понятно, но именно как вывод из пары метрик - сомнителен. У экспертов много неосознанного знания, но при объяснении экспертности они это рационализируют, а дальше пишут книги про success story - в них получается ложь. Есть исследования, как можно нащупать пути передачи опыта, например, моторными датчиками меряем напряжение мышц опытного пианиста, а потом электродами стимулируем мышцы новичков - оно работает. Или фокусировкой внимания по траектории глаз эксперта - эффективность новичка повышается.

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

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

Другой кейс - диктатор-бургомистр в маленьком немецком городе Лоххаузен. Хорошие бургомистр отличались следующим.

Феномен имплицитного поведения. Хотя мы учимся чему-то, мы не замечаем что все лучше. Сахарная фабрика, директор, определяем количество сотрудников на каждый день. Есть показатель 9 тыс. тонн. Связь между числом людей и выпуском связаны сложной формулой, которые человек не знает, и есть случайные флуктуации. Испытуемый варьирует и подбирает, у него лучше и лучше - но он не может сказать, как проявляется. Аналогично - феномен освоения языка, ребенок его осваивает, говорит, но не знает, как язык устроен. Это же в кулинарии, вождении автомобиля.

Тезис про снятие ограничений как источник инсайтов иллюстрирован языковыми головоломками

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

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

В основе. Есть неявная классификация области: какие области мы считаем стабильными, а какие - изменчивыми, где можно работать.

И это дает неявные установки, которые нас ограничивают.

Пути формирования экспертности.

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

Книга Expertise and Expert Performance (Cambridge, группа авторов)

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

Олег Балбеков из Evrone. Забота компании о сотрудниках — это измеримый показатель

Как организовать заботу, автоматизировать и правильно считать ее на масштабах сотен человек. Забота - это польза, которую компания нанесла сотрудникам. Деньги, внимание ,сервисы. Подарок на день рождения, митап, решение проблем выгорания, выявленных на 1:1. Забота повышает лояльность. В компании 29 видов забот наносят разные отделы. На этих масштабах хорошо бы это измерять - сколько заботы нанесли всего, что никто из сотрудников заботой не обделен и никто не потребляет чрезмерно.

Для измерения сделали информационную систему. Любое нанесение заботы - touchpoint, точка касания. Каждый имеет 3 характеристики: польза сотрудника, стоимость в деньгах, уровень эмоций - все оценили в баллах 0-10, эмоции оценила группа экспертов, на слайде - примеры. Интересно, что стоимость для компании прибавляют, а не вычитают, и для этого показателя выгодно заботиться дорого - но ограниченность бюджета побуждает заботиться эффективно. Любой touchpoint фиксируется - и обновляется индекс заботы. Большинство данных обновляется автоматом, так как фиксируется в ERP. На слайдах виды заботы по категориям: знания (митапы, конференции, обучение), развлечения, компенсация и рост (премии, грейды), поддержка (фидбеки по программе роста, one2one, смена проекта).

Недостаточно просто суммировать touchpoints. Нужен показатель, чувствительный ко времени. И тут аналог из игр, где у каждого персонажа есть мана, она тратится на выполнение работ и пополняется за счет заботы. Каждый рабочий день уменьшает ману. Гипотеза: если мана есть - сотрудник лоялен.

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

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

Юрий Сиволап. Психиатрия в обыденных ситуациях

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

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

Юлия Аравина. 6 «мягких» навыков для того, чтобы не разрушаться в кризис

Практический доклад о том, как можно держать себя в кризисной ситуации. Основа - методика Хэррис. Навыки:

Дальше был обобщенный кейс тимлида Вани, который обеспокоен текущей ситуацией, с расшифровкой, какие техники применять.

Что делали команды и компании

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

Кирилл Бобрик из ЦФТ. Менеджмент vs Разработка: причины конфликтов и как их преодолевать

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

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

Правила:

Обязательства

В результате получилась хорошая система работы с бизнесом. Исчез фактор стресса.

Потом был второй такт, работа с TTM. Структурировали, там две больших части: Разработка и Согласование юридической части - оно ПОСЛЕ разработки, а может потребовать переработки. С этим пока ничего не сделали. А свою часть поменяли.

Для декомпозиции рисуют Гант на задачу с взаимными зависимостями, и пытаются вычленить минимум. Договариваются со смежниками, когда они сделают, когда есть зависимости. Потом план-факт смотрят.

И еще OKR - фокусировка на целях и прозрачность. Результаты: поток упал; поняли что бизнес не умеет измерять и прогнозировать результат новой фичи. OKR не ускоряет производство, задачи сложные.

Как резюме. для преодоления конфликта

Илья Прахт. На работу как на праздник — как сделать так, чтобы сотрудники кайфовали на своих проектах

Компания Lineate, 150 человек, 30 проектов одновременно, работа на рынки Штатов и Европы, головной офис в Нью-Йорке, 2 офиса разработки в России, теперь 3 новых офиса - Армения, Польша, и выходят на рынок России. До ковида была матричная структура - people mаnаgement - функциональные подразделения, delivery - проектный офис. Люди реально счастливые, они это измеряли, и не было проблем с наймом при средней зарплате, текучка меньше 10% в квартал. Но дорогой менеджмент - утилизация 60-70%, 30+% на менеджмент. Когда пришел ковид - заказчики начали отваливаться, были проблемы и перестала сходиться экономика из-за дорого менеджмента. Они перешли от матричной структуры на проектное управление, убрали много дополнительных активностей, менеджмент стал всего 5+% и 90+% утилизации, но люди стали недовольны - много запросов на ротацию, текучка до 30% в квартал. Они поняли, что нужна компенсация и сделали систему пипл-менеджмента, и счастье сотрудников вернулось, при этом затраты на менеджмент выросли не так сильно, сейчас 10+%. О деталях и был рассказ.

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

Что меняли в пипл-менеджмент

Улучшения стаффинга: процесс ротации, сделали, чтобы люди работали на интересные задачи.

Ротация:

Интересность проектов

Инструмент Technical summaries: инфо о клиенте, проблема, что сделали, почему интересно, результат, технологии, крутые вызовы, которые решили. Можно писать по каждой проблеме. Пишет кто-то их команды - тимлид или разработчик. И это - классная заготовка для маркетинга (на американский рынок). Поставлено на поток, 5-10 summary за квартал. 30 за год при 30 одновременных проектов. Очень влияет на мотивацию команды - они же сами пишут и гордятся проектом.

Процесс технических улучшений: люди искали и потом продавали заказчикам. Дополнительные модули, изменения архитектуры, смена фреймворков, техдолг. Упаковать и предложить заказчику. Заказчик часто заинтересован, это было сюрпризом. Что-то можно делать невидимым образом. Можно поставить на поток - 5 в квартал. И поддержка упаковки для продажи заказчику. Легко в продукте, сложнее в аутсорсинге. Очень сильно влияет на мотивацию - люди сами находят и инициируют.

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

За реорганизацию 6+ месяцев - довольные сотрудники (5 из 6), интересность проектов (5 из 6), запросы на ротацию 2-3 в месяц, текучка 10-15% в квартал, средняя по отрасли.

Ван Хачатрян из Ozon. Как делать звезд, а не нанимать их

Основной тезис доклада: в любой команде нужны звезды - сверхпродуктивные сотрудники, способные драйвить команду. Если их получается нанять - хорошо, но это сложно и тогда их стоит растить внутри. Не из каждого сотрудника, но из одного-двух, а когда они выходят на этап самостоятельного роста - переключаться на следующих, это должен быть процесс. Потому что молодые (20-25) работают в команде 1.5 года, и потому звезды нужны новые. Да , с ними сложнее, но плюсов больше чем минусов, это разобрано.

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

Как их растить? Есть базис.

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

Эрик Бурыгин и Виталий Качановский. Как я перестал бояться общаться с руководителем

Клевый парный доклад людей об общении, на котором спикеры были в постоянном диалоге. Основной тезис - с руководителем нужно общаться. Дальше был разбор трудностей и советы по эффективному общению.

Какие трудности?

Как общаться эффективно

Когда начинать? Чем раньше - тем лучше. А если распределенная команда? Zoom рулит: можно в настолки играть, чай пить. У одного из них есть встреча 1.5 часа по не-рабочим вопросам.

Артур Орлов. Дебажим коммуникацию: протоколы общения человеков

Коммуникация неизбежно идет с потерей информации, этому есть системные причины: сообщение с полным контекстом были бы бесконечны, поэтому мы их запаковываем, опуская известный контекст и разные общеизвестные вещи, а получатель сообщения - распаковывает на то, что ему известно. Ему известно другое, и понимает он по-другому. Задача - минимизировать потери. Об этом и был рассказ. Теперь подробности.

Disclaimer: Если рассказанное противоречит тому, что вы знаете - вспомните 4 закон Артура Кларка: для любого эксперта существует аналогичный с противоположной точкой зрения - мне очень понравился.

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

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

Если после выкладки посыпалась смежная система, то заявление "Какого *** вы не предупредили о выкладке?" - не конструктивно, второй уходит в защиту, а еще запоминает наезд. Потому в сообщении нет цели.

Коммуникация - обмен сообщениями, двухсторонний, (реже 3-4, больше - разваливается на парные), асинхронный. Кажется, что часто синхронный диалог - но это отдельный навык, а когда двое кричат друг на друга - никакого диалога. Мультиканальный вербальная и невербальная; информационная и эмоциональная составляющая (факт и отношение к нему). Эмоции чаще передают невербально, но это не обязательно так. Далее - про вербальную историю. Невербальная - отдельные тренинги.

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

Синхронизация контекстов.

Виды потерь информации.

Как восстанавливать.

Ключевые идеи доклад.

Чек-лист на коммуникацию.

Анастасия Артамонова. 10 «синдромов» в одной команде

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

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

Доклад про налаживание работы совместных команд из производственников и ИТ для реализации технических проектов. Культура отличается очень сильно по широкому спектру вопросов, от бытовых до экзистенциальных:

При этом время сработаться - ограничено, и есть недоверие к взаимодействию на входе.

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

Советы в смешанной команде

Советы руководителю