Просмотр исходного текста страницы Блог:Максима Цепкова/2026-04-13: Стачка-2026: два дня, 13 треков, много интересного - жизнь продолжается

После 12-летнего перерыва приехал на Стачку. Предыдущий раз был в 2014 году, конференция тогда произвела большое впечатление – можно посмотреть мой старый отчет '''[[Стачка-2014]]''' с фото из Ленинского мемориала, где конференция проходила тогда. Но с тех пор как-то приехать не складывалось.

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

Атмосфера несколько изменилась, но хуже не стало, и впечатления – позитивные. Конференция такая же грандиозная, 13 параллельных разноплановых треков выступлений и мастер-классов. На открытии сказали, что было 576 заявок, из которых отобрано более 200 выступлений. Так что выбор конкретного выступления – сложная задача и наверняка я не попал на много интересных выступлений.

Многие доклады вызвали размышления, с одними я согласен, с другими – нет, и я делюсь этим дальше. Среди них хочется отметить выступление '''Ольги Зубковой и Рафаэля Фахреева «Эволюционное проектирование ИТ-решений»''' о том, как они сделали обобщенное решение сегментации сотрудников – пользователей внутреннего портала, которое используется многими конечными сервисами для разных целей. Это – достаточно редкая в наше время разработка, когда делают базовый функционал для нескольких продуктов, а не конечного пользователя, не замахиваясь при этом на большую платформу.

А у '''Екатерины Фёдоровой''' в выступлении «Почему в онлайн-обучении не работают «правильные» стратегии: взгляд через данные» была очень интересная аналитика: наиболее '''высокие баллы по ЕГЭ среди тех, кто идет на высокий балл, получают те учащиеся их онлайн-школы, которые чаще других нажимают кнопку «объясни подробнее»''', вызывая ИИ-помощника или куратора. Корреляция получена на нескольких тысячах учащихся. А вот корреляции со сроками подготовки (у них есть 10, 6 и 3 месяца), временем, которое учащийся делал задания, многократным возвращениям к урокам и другими характеристиками из тех, что доступны для измерения по логам, они не обнаружили. '''Любопытство ведет нас к успеху'''. В рамках первоначальных гипотез такого не было, извлечено из данных. Исследование – по результатам прошлого года,в этом они встроили механики, побуждающие обращаться за объяснениям, ждут результата.

А еще на конференции был '''Александр Бындю''' с мастер-классом по '''Карте гипотез''' – замечательному методу, который позволяет технологично работать с продуктовыми гипотезами и стратегией. На мой взгляд, формат гипотезы, придуманный Сашей, по эффекту сопоставим с форматом user story, который в свое время придумал Майкл Кон. Я на мастер-классе не был, потому что знаком с методом давно, и у меня есть подробный [[Александр Бындю. Карта гипотез-2|отзыв на книгу «Карта гипотез»]]. И выступал '''Алексей Пименов''', рассказывая про то, как запускать эволюционное развитие. Потому что эволюция в организациях – не естественный процесс, а искусственный, естественным образом все становится хуже, а не лучше.

У меня самого было два выступления: [[Архитектура предприятия: бизнес и софт как единая система (Стачка-2026)]] и [[Визуальное проектирование масштабируемых приложений (Стачка-2026)]] – новые версии моих предыдущих выступлений по этим темам. Традиционно, я не конспектирую свои выступления, но вы можете посмотреть презентации и предыдущие версии, пока нет записи этих – там есть ссылки.

А теперь – мои размышления по конкретным выступлениям с их кратким конспектом. Учитывайте: было 13 треков, так что это – очень малая часть выступлений

== Александр Утков и Валерия Рубанова. Египетская сила: как мы учили OCR для чтения древних иероглифов ==

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

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

== Софья Калинина. System Design для системного аналитика: от интервью к реальной работе ==

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

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

== Владимир Понаревский. Боль тимлида: я наладил операционку в команде. А что дальше? ==

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

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

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

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

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

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

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

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

Еще один совет – про коммуникации. Руководство смотрит на работу через цифирки результатов – чего достигли. А инженеры смотрят как приключение: они работали, старались, решали проблемы, было сражение вокруг дизайна и утаптывание релиза и так далее. Надо уметь переводить рассказ одного в язык другого. Особенно для performance review.

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

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

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

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

И последний совет. Вам нужно готовить себе замену, иначе вы не сможете двигаться дальше.

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

Вопрос. А есть два сотрудника, которые не хотят вместе работать без него. Что делать? Ответ: если два человека работают только через вас – надо починить, сначала собираете и ставите задачу, потом пробуете, а затем одного убираете.

Вопрос. Где грань, чтобы не стать неудобным, кто отказывает бизнесу. Ответ. Руководитель грань озвучит. Говорить «нет» надо обоснованно, с учетом целей руководителя.

== Ольга Зубкова и Рафаэль Фахреев. Эволюционное проектирование ИТ-решений ==

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

Само решение обеспечивает '''сегментацию сотрудников''', которая далее используется продуктами для разных целей: подстройки интерфейса, определения релевантной информации, проверки прав доступа и так далее. В МТС 60к сотрудников, которые работают через внутренний портал HR hub с множеством продуктов, и задача сегментации – актуальна Но раньше решалась в рамках конкретных продуктов и по-разному. '''Очень жаль, что выступлении не показали принципиальную архитектуру''', не рассказали как устроена сегментация и какие возможности настройки. На мой взгляд, это было бы интересно, и представляло опыт, который можно взять себе. Потому что задача сегментации пользователей – актуальная для многих. Но принципы проектирования подобных решений, о которых они рассказывали, тоже интересны.

МТС – большой ИТ-ландшафт и много команд. Куча внутренних регламентов, процессов, подразделений. А они автоматизируют HR: пашут над внутренним порталом, корпоративным обучением и так далее. Принятие решений – бег с препятствиями. '''Есть институты, которые издают процедуры, им надо следовать. Но получается не армия, а броуновское движение. Вектор развития есть, но стейкхолдеры и регуляторы так далее, они вносят хаос'''. Отмечу, что это – очень точное наблюдение за корпоративным миром.

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

HUB – HR-платформа, которая дает единое окно сотруднику, его разрабатывают от 40 до 150 команд – мощность разработки сильно дышит в зависимости от ситуации. Сотрудников много, и важно выдавать им релевантную информацию. Для этого предложили сегментировать пользователей по цифровым профилям сотрудников. В профиле – кадровая и другая информация, по ней надо по ней накладывать ограничения. И делать это динамично – система активно живет. Сегментирование – не контроль доступа, она не отвечает за право доступа куда-то. Но сегмент может использоваться для этого.

Сложность в том, что на такое решение 6нет заказчика, который бы поставил задачу. Есть видение, что сейчас каждый продукт делает свое, и у всех получается не слишком хорошо. В том числе потому, что это – не критичная вещь, не новая фича.

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

Это принцип KISS. Он не в том, что не надо моделировать и делать архитектуру, а просто разрабатывать. Он в том, чтобы отсечь лишнее и оставить суть. '''Упростить – не значит сделать просто, а значит выделить суть'''. Это ментальная модель, способ мышления.

'''Итеративное проектирование'''. НА этапе начальной проработки '''проектирование останавливаем, как только видна достижимость'''. Проект – не самоцель, а снятие неопределенности. Как только путь ясен – остальное допилим по ходу реализации.

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

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

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

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

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

Я тут отмечу, что проблема многих современных фреймворков – жесткая проверка транспортного объекта по xsd или JSON-схеме. Это закладывают из лучших соображений – контроль типов. Но в результате, если вы расширяете транспортный объект атрибутом, который нужен двум приложениям из пяти, то править надо все пять. Гибкое решение – если любое приложение толерантно к расширению набора атрибутов, да еще умеет их прозрачно передавать дальше.

Делим разработку на этапы и '''ставим цель: что должна делать на этом этапе''', какова точка остановки. Далее – требования к такой системе, и реализация – и контроль, что ты не вылез за концепцию. Система сегментирования пошла с тираж, и в процессе тиражирования нам удалось остаться в рамках архитектуры системы, не выйти за границы. При этом запросы, которые противоречат границам отклоняют жестко. Система сегментирования отдельно ценности не представляет, она интегрируется внутрь других. А по этапам – они расширяют количество процессов, в который можно вовлечь.

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

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

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

== Максим Смирнов. Типы архитектурных решений ==

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

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

А еще в выступлении было очень интересное размышление. В свое время набрал популярность подход ADR – фиксации архитектурных решений. И было даже впечатление, что «все так делают», пока в 2023 году группа исследователей tyt провела анализ по большому количеству репозиториев на github и не выяснило, что в лучшем случае ADR пишет один энтузиаст в проекте и актуальность их непонятна, а чаще всего этот энтузиаст написал решение однократно, и на этом дело закончилось – практика не взлетела. Кстати, в процессе исследований они сформировали некоторую интересную выборку из 1к github проектов при начальном списке кандидатов около 100к, отобрав из всего множества живые проекты, развиваемые некоторым сообществом. С тех пор на эту выборку используют в разных исследованиях.

Но сейчас ситуация может измениться: LLM явно умеет писать решения, в том числе их можно попросить это сделать по анализу кода, и может их проверять. Так что количество решений может увеличиться. Будет ли от таких решений польза – вопрос другой. Максим сказал, что это – как фальшивые елочные игрушки: выглядят как настощие, а радости – никакой.

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

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

Это, кстати, вполне согласуется с моим опытом, более того, во многих проектах эти неформальные диаграммы жили на протяжении всего проекта. Часть из них я показывал в своем выступлении [[Архитектура предприятия: бизнес и софт как единая система (Стачка-2026)]].

== Ханна Гринберг. Думай как продакт: решаем задачи любого уровня абстракции ==

Это был рассказ про Lean – систему постоянных улучшений, через процесс из 5 шагов: define – measure – analysis – improve – control, нацеленный на устранение различных потерь и лишней работы. Но до того, как улучшать, необходимо получить общий взгляд на процесс в целом. Для этого есть формат '''XPM''' – карта процесса, на котором отмечаешь проблемные точки. К сожалению, хотя Ханна и говорила о своем опыте, рассказ получился чисто теоретический, в нем не было разобрано решение каких-то конкретных проблем, чтобы приземлить теорию на практику. А без этого получается не так интересно – книжек и статей про теорию можно найти громадное количество, а вот применить их в своей ситуации куда сложнее.

Замечу, что Ханна говорила не просто про Lean, а про Lean Six Sigma. Это гримасы нынешнего инфополя, когда на базовые вещи навешивают крутые названия. Потому что Lean Six Sigma – это не просто про улучшения, а про то, как за счет процесса обеспечивать статистическую гарантию отклонений меньше трех сигма. Та самая надежность 99.99%, которая есть, например, при производстве мониторов. И там, помимо просто постоянных улучшений, есть много тяжелых механик, о которых речи не шло. Тем более, что в ИТ (а не производстве железа) эти механики не уместны, ввиду быстрого развития технологий, которые не успевают достаточно стабилизировать надежность базовых фреймворков и софтверной инфраструктуры. А вот Lean – вполне уместен.

Итак, Lean говорит о том, что во всяком процессе есть потери, связанные с разными причинами.

* Muda – лишняя работа и недоиспользованный потенциал
* Muri – перегрузка, например, объемные требования
* Mura – неравномерность работы, то пусто то густо.

Для устранения потерь есть пять шагов выявления проблемы и поиска решения: define – measure – analysis – improve – control.

* Когда копать: знаем ли проблему и знаем ли решение – тогда это задача в бэклог.
* Если решения не знаем – то нужен быстрый поиск решения. Отслеживаем, QRQC.
* А бывает решение без проблемы – а тогда зачем.
* А еще есть абстрактные задачи. Нет проблемы и нет решения, что сто-то можно сделать

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

Ее команда занимается обучением и развитием массового персонала. Они делают приложение для Самоката, и дальше – обучение директоров, товароведов (это их продукт). И когда она пришла, то решила посмотреть процесс с помощью карты XPM (Experience-Process Mapping). Есть другие методы: диаграмма вариантов, CJM или другие. XPM – карта вариантов, развернутая по горизонтали и дополненная, например, результатами исследований по отдельным точкам. Собираем все в одном месте. '''Мы видим весь процесс и проблемы на нем'''.

Дальше analyze – что можно померить сейчас, чтобы сравнивать. Можно провести UMUX опрос до, и через месяц-два.

'''Поиск решения'''.

* Группируем похожие проблемы
* Собираем команду по каждой группе. И брейнстормим идеи по решению. 10-15 минут индивидуально накидывают решения. Дальше голосование звездочками. Появляются лайки.
* Раскидываем решения по матрице: Усилия по внедрению против ценности. И берем зеленую и желтую зоны.
* По отобранному – гипотезы в бэклог.

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

Шаблон для описания продуктовых инициатив. Цель, эффекты, заказчик сроки. Проблема – чья (и потери от нее). Ценность, которую приносим бизнесу (включая экономический эффект). Окупаемость. Риски там тоже есть, в методологии 4 типа, но по ним она всегда заглядывает в шпаргалку.

Важная вещь- '''архив стратегических решений''': если были важные решения, то запишите основания.

Приоритизация. RACI или что-то еще стандартное. Или можно побаловаться с ChatGPT и нарисовать свою формулу. У нее: Приоритет от бизнеса, эффекты, есть ли ручной процесс, и так далее. А как понять что все раскопали? Один из вариантов – смотреть на метрики, если дальше задачи, которые не принесут эффекта – ищем другую область. Если проблем не видно – не факт, что их нет, например, с клиентами не общаемся – можно их поискать.

Сколько для этого надо времени? Это зависит от накопленных данных. Если есть описание процесса и проблемы на нем, то пара часов брейншторма, чтобы породить гипотезы решений. А если процесса неясен, то исследования требуют времени. Надо выяснить процесс, отрисовать, опросить про проблемы. Опрашивать можно через UMUX – отправить всем, кто-то заполнит, или через глубинное интервью, там обычно 80 человек.

== Екатерина Гриценко. User Experience выгорания: проектируем recovery-путь для самого себя ==

В компании Екатерины нагруженные проекты, и выгорание – распространенная проблема. Она наблюдала выгорающих и год назад сама пережила. Основной посыл выступления в том, что '''надо вести мониторинг своего состояния, чтобы зафиксировать проблемы с выгоранием на ранних стадиях'''. Для этого Екатерина перенесла методы UI/UX дизайна на работу с выгоранием, и сейчас ими действует. В принципе, это разумно: взять профессиональные навыки, которыми ты владеешь, и перенести на область психологии.

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

Так что, думаю, что идея перспективная, и вполне возможно, что такой мониторинг может помочь людям. Только тут важно помнить, что '''все люди – разные''', у различаются и взаимная сила разных нейрофизиологических систем мотивации (их четыре: дофамин, тестостерон, окситоцин, серотонин), им нужны разные способы восстановления энергии (одним прогулки в одиночестве, а другим – общение и обнимашки), и так далее. Поэтому то, что подходит одному – плохо подходит другому. А вообще по теме я всячески рекомендую выступления Анны Обуховой, их очень много на youtube (и других площадках). У меня есть обзор ее выступлений https://mtsepkov.org/ObukhovaNeuroCollect, включая большой вебинар «Выгорание стресса и выгорание скуки». У Анны – шесть высших образований, включая биологию и нейрофизиологию, и она много работает в ИТ. Думаю, будет полезным.

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

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

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

Выходить самому надо раньше – не первых стадиях. И Екатерина предлагает использовать колесо баланса, оценить жизнь по главным категориям. В идеале должно быть равномерно. А у нее карьера вышла на первое место – она забила на встречи с друзьями, на хобби и так далее. В презентации – ссылка на [https://disk.360.yandex.ru/i/M5sOldDMxSHsmQ чек-лист на выгорание]. Еще есть опросник по Маслач – небольшой, шкала депрессии Бэка и коэффициент усталости.

'''Дальше – надо собрать гипотезы'''. Работа с установками.

* Рефрейминг. Работа как клетка, ничего не могу изменить. Я не могу изменить культуру, но все-таки могу работать с границами. Надо проговорить и создать позитивный прототип жизни. Не мы плохие, а конкретные факты.
* Reverse thinking. Утверждение: я истощен. Вопрос: на все нет сил или на работу? Если проблема в работе – то значит что-то надо не нравится, и надо выписать список проблем. Не мы плохие по площади, есть список проблем.<br />

* Energy audit. Были инструменты, которые дали триггеринг – выписываем негативные моменты ,что испортило настроение, что опустошило. И что наоборот дало энергию. И далее выбираем наименее энергозатратный способ. Если это внашей силе – мы это делаем.

Прорабатываем установки и выписываем проблемы.

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

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

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

'''Визуализация завершенности''' – дневники. Не ToDoList – там будет незавершенное, будем себя гнобить, а '''DoneList''' – без важности и приоритетов. Главное понять, что день прошел не напрасно.

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

Тест текущего состояния – '''дневник настроения''': эмоции, чувство смысла, удовлетворенность неделей. И число сделанных дел их done list. Качественное – каждый день, раз в неделю ретро – по работе прототипа, может его улучшить.

Как понять, что идем куда нужно? 2-4 недели, если что-то идет в плюс – значит оно работает.

Выводы. UX-дизайнер не обязан быть сверхчеловеком. Может отказывать. Не надо идти вопреки себе. Самый важный продукт – вы сами, следите за собой как за продуктом. И не страшно обратиться к специалисту.

Уволиться – не лучшая идея. Потому что когда в выгорании – у тебя уже хронический стресс. Смена работы – дополнительный стресс. И мы принесем свои старые паттерны в новое место. Так что тут вопрос диагностики.

Вопрос. Как объяснить работодателю. Ответ. Хороший работодатель – заинтересован в тебе. Он не будет отказывать в отпуске, он войдет в положение. Говорить полезно в любом случае, даже если вам кажется, что невозможно: может быть, у руководителя будет иное мнение. Хотя возможно, придется увольняться, если вы не вывозите темп работы в компании.

Вопрос. Какой баланс? Отказываться от встречи, чтобы экономить силы, но при этом не вгонять себя в социальное одиночество. Ответ. Для нее прорезающим оказался вопрос от психотерапевта: если бы не устал – я бы пошел гулять с друзьями? Если нет – депрессия. Можно отследить по списку симптомов.

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

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

== Екатерина Фёдорова. Почему в онлайн-обучении не работают «правильные» стратегии: взгляд через данные ==

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

Обычная идея для качественной подготовки – давать больше и разнообразнее. И еще – давать инструкции решения по шагам, тем более, что ученики сами этого хотят, ссылаются на ролики? где это есть. Они это сделали, и получили повышение среднего балла на 2%. У них разные ученики. Одним нужно «просто сдать», получить 70 баллов. А другие целятся в максимальные баллы. 90-95-100, и таких больше. И тут есть тонкость, в ЕГЭ есть вторая часть с нестандартными задачами, и на ней решения «по шагам» срабатывает плохо, потому что разные задачи решать надо по-разному. Поэтому, хотя в целом решения по шагам оказались полезны, есть большая категория учеников, которым они наоборот, мешают.

Они решили выяснить, а чем отличаются ученики, которые получают высокие баллы от других. И результат, намой взгляд – наиболее интересное в выступлении. Оказалось, что наиболее '''высокие баллы по ЕГЭ среди тех, кто идет на высокий балл, получают те учащиеся их онлайн-школы, которые чаще других нажимают кнопку «объясни подробнее»''', вызывая ИИ-помощника или куратора. Корреляция получена на нескольких тысячах учащихся. А вот корреляции со сроками подготовки (у них есть 10, 6 и 3 месяца), активности учеников, времени, которое учащийся делал задания, многократным возвращениям к урокам, вниманию ученика и другими характеристиками из тех, что доступны для измерения по логам, они не обнаружили. Так что '''любопытство ведет нас к успеху'''. В рамках первоначальных гипотез такого не было, извлечено из данных.

Исследование – по результатам прошлого года,в этом они встроили механики, побуждающие обращаться за объяснениям, ждут результата. Такая возможность, проведя исследования, сразу попробовать получить на их основе практический результат, очень привлекает Екатерину в онлайн-школе. Как она сказала, она именно поэтому ушла из ВУЗа, где между исследованием и практическим результатом проходит много лет. Кстати, это очень явно было видно в вопросах преподавателей в конце: там была куча гипотез о том, что еще можно попробовать исследовать (часть из них уже проверены, Екатерина рассказала), и не одной идеи про улучшение процесса обучения. Такая вот особенность восприятия.

== Сергей Макаров. Чистая архитектура in action ==

Это рассказ о чистой архитектуре применительно к фронт-разработке, с примерами из своего опыта, а не просто пересказ книги. Дальше – пунктирный пересказ.

Основа чистой архитектуры – SOLID.

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

'''DIP'''. Инверсия зависимостей – зависим от абстракций, а не чего-то конкретного. Клент зависит от интерфейса, а не реализации. Дает стабильность интерфейсов, упрощает рефакторинг, позволяет разнести по командам и т.п.

'''Слои'''. Не относятся к SOLID, но выводятся из DiP и других. Схема – его, у вас может быть другая. Domain – не Entities – основа приложения. Что есть Пицца. Дальше доменная логика – купить пиццу, приготовить пиццу. Дальше есть презентация и инфраструктура.

'''Правило зависимостей'''. Как компоненты вызывают – все стрелки идут в центр. use case вызывает entties. Если у вас основной доменный объект – Пицца, то нельзя из ее кода вызывать почту для уведомлений. UI → Presenters → (Use cases + Entities) → Repository → DB. В такой архитектуре нет циклических зависимостей.

Принципы связанности. '''Cohesion'''.

* Reuse, release. Раньше код могу вызывать друг друга. Если вы берете код и используете в своем – нужна синхронизация по релизным циклам.
* CRP – если вам что-то не требуется – не надо туда пихать.

Все они – баланс, хвост вытащишь – но увязнет.

Сплоченности – '''coupling'''. Нет циклическим зависимостям. Компонет стабильным и абстрактным одновременно. Чем меньше зависимостей от абстракций – тем стабильнее. И не надо в стабильное запихивать нестабильное.

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

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

У них – стайл гайд и линтер. И проверяют.

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

Кроме SOLID есть YAGNI, KISS – что с ними? Он их не любит, потому что они не конкретны, они как поговорки, в отличие от SOLID.

== Даниил Пилипенко. История кризисов в IT за 25 лет ==

Даниил – директор Центра подбора IT-специалистов SymbioWay. Кризисы им видны: их зовут не оценивать кандидатов, а сотрудников на предмет увольнения или повышения квалификации.

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

Историю кризисов в ИТ Даниил начал с кризиса доткомов в 2000-2002. Это классика завышенных ожиданий, которые не оправдались. Там давали инвестиции вообще без бизнес-модели. В 2008 – ипотечный кризис потянул все остальное, но на российский рынок он повлиял не сильно.

В 2014-2015 – подорожание доллара и спад в областях, которые рассчитывали на низкий курс. Я тут отмечу, что в других областях наоборот, был подъем: если компания работала по западным заказам, то высокий курс позволил снизить внешние цены в долларах и получить поток заказов, с которым компании не могли справиться, нанимали разработчиков. От таких компаний тогда были парадоксальные предложения: релокация из Москвы в провинцию с увеличением зарплат.

2022-2024: пандемия вызвала рост ИТ – вложения в онлайн-продукты. А в 2022 стало понятно, что вложения не оправдываются, пошел откат в оффлайн и уменьшение инвестиций. Не только в России, а во всем мире. А в России с 2023 идет кризис дорого капитала.

Как реагирует рынок кандидатов и работодателей в кризис? Доткомы – массовые увольнения, снижение и стагнация зарплат, жесткая конкуренция, кандидаты начали думать о резюме, и разочарование в профессии. Кандидаты пытались стать универсалами (fullstack), соглашаться на работу без бонусов и опционов, уходить в госсектор. Выжили фундаментально подготовленные – компании начали их нанимать, перестали нанимать про запас, очистили от низкоквалифицированных. В 2008 – так же, сокращение спроса, заморозка проектов. В России проявился слабо.

А дальше в презентации был интересный график, котрый они ведут с 1 кв. 2014: вакансии против резюме. До 2020 рынок потихоньку рос, и вакансий больше резюме примерно на 40%. Там есть регулярная волна в 4 квартале – в конце любого года число вакансий обычно сокращается. А вот со 2 кв. 2020 по 2 кв. 2022 на графике – пик вакансий с сохранением числа резюме. Максимум – с 2 кв. 2021 до 4 кв. .2021, превышение вакансий в 3-3.5 раза над числом резюме: 85к против 22к. Люди ринулись в ИТ, и с 1 кв. 2022 пошел рост числа резюме с сокращением количества вакансий, и разрыв вернулся к 40%.

В Европе и США – тоже самое, с июня 2022 по 2023 вакансий уменьшилось в 2.5 раза, потом медленный рост до текущей точки.

Таким образом в 2021 был рынок кандидата. В 10 утра резюме и к вечеру 80 писем и 30 звонков. И можно получить офер в тот же день, если есть репутация. С 2022 – рынок работодателя, рекрутер получает 1000 откликов в день, берет 10 и выбирает вменяемых. Массовые увольнения, BigTech уволил тысячи людей.

Я тут отмечу, что формально это не так, потому что вакансий по-прежнему на 40% больше, чем кандидатов. Более того, если смотреть структурно, то тоже есть проблема: на рынке много новичков, а требуются более опытные. Просто при разрыве в три раза брали действительно любых, а теперь действуют избирательнее. Недавно я был на Tech Writer Day ([[TechWriterDays-2026|отчет]]), там был анализ рынка технических писателей. Они там внимательно смотрели на рынок, потому что идут сокращения и они хотели понять, не связано ли это с ИИ. Ответ – нет, идут общие сокращения проектов и бюджетов, технических писателей увольняют вместе с остальными. При этом крупные компании прием не продолжают, вакансии открыты.

Даниил про ИИ отметил, что идет реструктуризация профессии, люди начинают работать эффективнее. Это было и со средами разработки или автодополнение в свое время. Итог – джунам почти невозможно найти работу, а мидлы конкурируют с бывшими в Google.

ИИ начинался с поиска, сейчас – AI IDE, мультиагентные системы, а что дальше? У него осторожный прогноз, что рост использования ИИ замедлится. Был период в 2023-2024, когда ИИ использовали бездумно и накопили тех.долг. И поняли, что надо подходить по-умному, включать программистскую часть мозга. И есть ощущение, что на этом все закончится в ближайшие годы – ограничения по железу и энергетике.

Я с этим согласен лишь отчасти. ИИ делает работу эффективнее в режиме личного помощника для разработчика, аналитика, тестировщика. В оценке эффективности почему-то все сходятся на цифре 30%, я ее слышал из очень разных источников, и даже в Baidu осенью мне называли именно эту цифру (я в октябре был в китайских технологических компаниях – Baidu, Xiaomi и других, отчет и материалы – [[:Категория:Китай становится лидером|здесь]]]]). А сейчас ИИ-агентов уже встраивают в цепочки разработки, поручая им конкретные задачи в команде и повышая производительность в целом – с ноября этого года об этом много выступлений на конференциях. И этот процесс явно не завершен, должны появиться устойчивые структурные паттерны команды, где ИИ работает совместно с человеком, новый вариант Team topologies. Но вернемся к выступлению.

Как извлекать пользу? Кризис – встряска, когда можно выстроить новую систему отношений и двигаться вперед. Как с кризисом доткомов. Сейчас стереотипы поведения повторяются. Можно развивать архитектурное мышление, прокачивать другие компетенции. Он всегда был бэк, а в ковид изучил vue.js – и стал лучше разбираться, это помогает руководить фронтом тоже.

Кризисы будут, они происходят каждые 3-6 лет и надо уметь адаптироваться. Сейчас стоит избавляться от завышенных ожиданий. Молодежь хочет 200-300-400, а стоит 150-200 максимум. С мидлами и сеньорами тодже аналогично, просто цифры другие. И тут много трагедий, особенно, если взял ипотеку на 500к, а зарплаты сейчас есть на 250 максимум.

Тренды.

* AI-центричность, использование инструментов
* Дефицит сеньоров при избытке джунов. Потому что зарплата x2, а эффективность x4
* Кибербезопасность как приоритет №1
* Локализация и суверенитет, мировой рынок дробится
* Российский рынок стабилизировался и переходит к росту. К ним снова заявки на оценку при найме, а не только при сокращении

Вопрос. А что с ГПХ? Начнут ли нанимать надолго? Ответ. Заказы – краткосрочны, это факт. Раньше проект – год-два, а сейчас проект 2-3 месяца, а потом неясно – выстрелит или нет. Так что ГПХ будет развиваться.

Вопрос. Что будет с «Войти в АйТи»? Ответ. Народ уже разочаровался. Все онлайн-школы в 2022 ушли вниз. Онлайн может быть качественным. Когда-то надо было учиться долго. Потом – за 2-3 месяца стало достаточно. А теперь смотрят длинное образование. Куда будет уходить? Сфера ИТ – очень большая, есть, например, 1С, который будет расти. К С# можно дополнить Java, мобильные приложения – больше навыков. А пока – брать малые задачи, рынок фриланса растет – многим компаниям нужно быстро и маленькое. Фриланс дает опыт. А еще – накапливать подушку на кризис, чтобы год без работы пережить.

А еще есть специализации, где спрос вырос. Например, системный анализ: в августе было 5к вакансий, сейчас 10к. Любой разраб может за 3 месяца выучиться на системного аналитика. Да, это может быть не очень приятно, но если нужны деньги – то почему нет?

Статистика. На hh – 40% вакансий от всего рынка, анализ репрезентативен. На habr – меньше, и там искажения – размещаются крупные. Они смотрят оба. Можно поставить фильтр, и смотреть интересное вам.

Есть ли сегмент обучения ИИ? Нет, использовать ИИ – не такой сложный навык, даже мультиагенский. А вот на грамотную постановку задачи – спрос будет расти. Это как раз системный анализ.

Я тут добавлю, что с обучением ИИ происходит тоже самое, что и с другими курсами. На stepik.org – много бесплатных или дешевых курсов, и среди них есть сделанные настоящими профи, которые дают много больше пользы, чем дорогое обучение у каких-то вендоров. Я слышал истории, где люди просто сравнивали в компании объявляли, что желающие могут выбрать себе курс, разные люди пробовали разное, а потом в работе сравнивали результаты, и лучшим оказался короткий курс за 5к, в котором полезного оказалось сильно больше, чем в раскрученном за 50к. Ссылки не даю, потому что история – старая, сейчас эти курсы не актуальны.

== Алексей Пименов. Управляемая эволюция. Как это делается ==

Если кто вдруг не знает, Алексей – самый крутой спец по Канбану в России. А кроме Канбана сейчас активно работает с картой гипотез Александра Бындю – методы дополняют друг друга. Эволюция – про Канбан-метод. [https://sqadays.com/ru/talk/127019 Аналогичный доклад] Алексей делал полтора года назад на SQAdays, так что, если интересно, вы можtnt посмотреть видео, пока со Cтачки еще не готово.

Типичный процесс изменений устроен так. Есть причина – что-то, что не устраивает в текущей ситуации: медленно, мало, не то, что нужно. Появляется кто-то (гуру, коуч) и говорит «вы – динозавры, нужны best practice, и будет счастье через некоторое время». Если показать график, то от времени там будет текущая ситуация, где какая-то величина равна 1, и целевая точка через полгода-год или другое время, где этот показатель выше. Засада в том, что '''по пути будет провал''' – кривая Виржинии Сатир. А подальше вправо еще есть асимптота – ограничение модели, которое выше текущей (это если правильно выбрали). Провал происходит потому что есть переходный процесс, сопротивление людей.

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

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

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

Эволюция – с учения Чарльза Дарвина. Градуализм. Виды меняются малыми мутациями через миллионы лет. Антропологи и палеонтологи видят это в истории. Но вот переходные виды не появляются. И не всегда миллионы лет, есть резкие изменения, позвоночные появляются очень быстро по меркам эволюции. И есть теория Нильса Элриджа и Стивен Джей Гулд – они предложили прерывистое равновесие.

Экосистема есть в двух состояниях: пунктуация, когда мутации идут быстро. Например, кембрийский взрыв из-за накопления критической массы кислорода в атмосфере, появление позвоночных. Или прилетел метеорит. А есть периоды равновесия – зоны комфорта. Эффект Галапагосских островов, где сохранились реликтовые древние виды.

Что такое для человека период пунктуации? Свадьбы, разводы, рождение детей, смерть родственников, миграции, смена места работы. Вот привезли жену с ребенком из роддома, и первая ночь – дыхание ребенка, к этому надо адаптироваться. А '''период равновесия – это не когда хорошо, а когда не настолько плохо, когда надо подорваться и что-то делать'''.

В организации – слияние, поглощения, выход менеджера, смена топов и так далее. Государство – кризисы, войны, пандемии, блокировка телеграма.

'''Формула эволюционных изменений: стрессор, пространство для рефлексии, акт лидерства'''.

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

Состояние взрыва, воздействие стрессора – краткосрочное. И надо сделать пространство рефлексии. Собрать всех: вот, делаем полгода, а вы говорили – две недели. Что делать? Люди начинают шушукаться. Усиление стрессора.

И в этот момент '''можно предлагать улучшения'''. Можно длинный путь – мозгоштурмы, группы. А можно в этот момент предложить решения. Но подсунуть, а не велеть, предложить – чтобы они считали себя автором.

А дальше надо превратить в план – должен проявиться '''акт лидерства''', когда кто-то начал это делать.

Да, это манипуляция. Но у нас любые изменения – манипуляция.

Стрессор – как канатаходец. Причины провала две. (1) предлагаешь слишком много, слишком новое и люди не готовы. (2) Не дожимаете. Вызвали бабушке скорую, она сделала укол, а на предложение сделать диагностику – бабушка говорит, что не надо, уже лучше. Так и с организациями: ввели практику, стало легче – и люди уже не меняются. Стрессор – как анестезия при операции. Чтобы не убить, но не проснулся при операции.

Классический кейс такой конструкции – Фолклендская война в 1980-х. Фолкленды контролируют обход Южной Америки с юга. Там всегда жили британцы – они их заселили, до них населения не было. Аргентинцы многократно пытались отжать. Обычно премьеру Британии ложится сводка “планируют”, и они посылают флот. Аргентина успокаивается. Но в 1980-х Тэтчер в конце первого срока, и у нее нет особых достижений, а уходить она не хочет. И поэтому она не посылала флот, специально ждала, пока аргентинцы не захватили, и только тогда посылает флот. Мелкая война на 3 месяца, 200 человек потерь британцев и 600 человек аргентинцев. И Тэтчер – героиня, железная леди, а президента Аргентины Гальтиери сняли. Искусственная точка стрессора – чревата увольнениями персонала, не доходите до этого.

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

Вопросы.

* А если на стрессор команда говорит: и что? Ответ. Просто рассказать – недостаточно. В одной из компании техдир сдерживал негатив на одно из подразделений, боялся что уволятся. И поток отпустили – команда узнала. Или сказать, что «каждый отдельно прекрасен, но вместе – ленивые бездельники».
* Регулярно наблюдает, когда на людей натравливают фасилитаторов и коучей, те начинают лучше общаться, но в производстве не меняется ничего. Потому что ограничение в процессах, а не во взаимоотношениях, общаются и так неплохо.
* Если пришли к выводу на основании данных, провели изменения, а они неверны – надо для начала признаться. «Я первый скажу, что потратили лишние миллионы, давайте выбираться». Но любое действие должно иметь риск-тейкера – того, кто рискует сам, проводя изменения.
* А когда нужны революции? Ответ. Мы должны сделать не разовое изменения, а культуру постоянных изменений, и тогда с каждым разом можно делать более серьезные изменения, которые можно откатить. Будет все меньше провалов. А второй ответ. Есть боль-профит, и есть истории когда больно долго, а профит не сразу, а бывает, что боль недолго. Если команда завязла в болоте – то лучше прыжок боли, а потом выгребаем эволюционно.

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

То есть надо не просто иметь адекватную модель сотрудника, но и представлять, какая у этих сотрудников модель компании и руководства, и что они думают о самих себе. Такой подход называется «рефлексивным управлением», о нем есть хорошая книга «Алгебра совести» Лефевра, в которой он строит такую алгебру моделей, которые у конкретного индивида могут быть верными и неверными, и показывает различия, которые из этого вытекают. Кому интересно – у меня есть [[Лефевр. Алгебра совести|отзыв-конспект книги]]. Для создания моделей вполне можно применять технологию персонажей, используемую в UX, и ИИ вполне способен помогать в их создании, а потом – оценивать те или иные сообщения от лица этого персонажа. В некоторых компаниях эту технику используют для подготовки к переговорам: готовят для ИИ контекст из информации о компании и конкретных руководителях из открытых источников (статей, выступлений и др.), также истории коммуникаций, а потом просят оценить презентацию или компред и помочь с доработкой.
{{wl-publish: 2026-04-13 11:42:41 +0300 | MaksTsepkov }}