Просмотр исходного текста страницы Блог:Максима Цепкова/2025-06-10: ЛАФ - много крутых докладов и нетворкинга

{{Conf-Ref}}
Прошел очередной [https://events-pro.ru/conference/LAF2025/program '''ЛАФ-2025''']. Костромская область, дом отдыха Серебряный плес, полтора дня, шесть треков докладов и мастер-классов. И, как всегда громадное количество нетворкинга: вечером накануне после заезда и на афтерпати, который продолжается далеко за полночь.

Самое сильное впечатление от фестиваля мне дал доклад [[#Регина Шарафутдинова и Мария Хромых из Газпромнефти. Будущее бизнес-анализа: Роль критического мышления в эпоху автоматизации и ИИ]], на котором я впервые ощутил работу будущего с повсеместным использованием ИИ-помощников: с их помощью обрабатывают интервью, придумывают решения и делают другие задачи. Это, конечно, не дошло до уровня фантастических книг, в которых герой всегда на связи с сетью, но достаточно близко. И изменения принципиально сильнее, чем от появления интернета и поиска, которые появились: тогда, конечно, появились принципиально новые возможности, но материалом интернет наполнялся относительно медленно, сначала найти можно было очень мало, а тут GPT сразу все знает, да еще общается на естественном языке. Сам доклад был не об этом, он был про приемы критического мышления, которые важны для проверки того, что вам выдал GPT. Но они не специфичны для ИИ, владение критическим мышлением всегда было важным для аналитиков, чтобы проверять интервью заказчиков и другую информацию. Сейчас важность еще возросла. А вот повсеместное использование GPT проходило в докладе фоном, примерно как использование смартфоном или мессенджером. Я впервые ощутил, насколько будущее не просто наступило, а стало повседневностью.

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

Еще я хочу отметить выступления '''Максима Дорофеева, Ольги Подолиной, Ирины Гертовской, Жени Скорикова''' и '''Ирины Баржак'''. '''Ирина Гертовская''' говорила о том, что задача аналитика — не превращение интервью стейкхолдеров в требования, а восстановление комплексной картины, описывающий проблематику бизнеса и комплексные задачи, которые требуют решения. А '''Женя Скориков''' попробовал дать интересный взгляд на описание бизнеса как связку процессов и ресурсов. Но это — чисто субъективные предпочтения.

Еще хочу заметить, что в названии мастер-класса Максима Дорофеева используется «душнота» в смысле «внимание к деталям и логике рассуждений». Такая вот переинтерпретация, чтобы в ответ на заявление «ты душнила», подразумевающее негативные коннотации «ты консерватор, душишь новые идеи и полет творчества» заявить «да, я такой — внимательно смотрю, логичны ли твои рассуждения», в котором нет негатива. На распространенность эпитета «душнила», который люди применяют к себе с гордостью, я обратил внимание зимой на WAW, написал в отчете и [https://t.me/mtsepkov/952 у меня на канале] было интересное обсуждение на 30+ коментов как раз на эту тему. А теперь понятие вошло в язык, выходит уже в названиях выступлений.

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

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

= Максим Цепков. Сначала проект, потом анализ: прошлое возникает из будущего =

Я выступал с открывающим докладом, в котором решил поделиться своим способом ведения проектов, который сильно отличается от классического подхода. Классика говорит: описываем As Is, и лишь потом потом строим To Be. А я обычно после начальных интервью, на которых очерчено проблемное поле, делаю vision будущей конструкции, которая призвана решить черченное проблемное поле. И дальше обследование идет с фокусировкой на проектирование этого будущего. И это касается не только проекта в целом, но и планирования проекта: мы сначала определяем последовательность демонстраций и этапов внедрения, и уже они определяют логику разработки. Такой подход я практически применяю с самых первых проектов, хотя не всегда четко осознавал, а рассказать с фокусом внимания именно на этом отличии решил только сейчас.

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

Подробного конспекта доклада не будет. Он построен на примерах реальных проектов, презентацию можно посмотреть на странице доклада [[Сначала проект, потом анализ: прошлое возникает из будущего|'''Сначала проект, потом анализ: прошлое возникает из будущего''']], там же есть ссылки на другие мои материалы, к котором можно обращаться, пока видео не опубликовано.

При обсуждении доклада на конференции Женя Скориков рассказал, что метод фокусировки анализа через проблемное поле описан у Голдратта в Цель-1. Я не замечал, хотя книгу читал, он тоже сказал, что заметил далеко не с первого прочтения. Это герою рекомендует уже в конце, когда героя уже повысили, и он думает, как разбираться — совет начать с проблем. Но подробно применение метода не описано.

= Регина Шарафутдинова и Мария Хромых из Газпромнефти. Будущее бизнес-анализа: Роль критического мышления в эпоху автоматизации и ИИ =

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

Критическое мышление — активная позиция, когда мы принимаем информацию на веру, обращаем внимание на факты, учитываем контекст.
* Сомневаться разумно — блокировать эмоции и автопилоты, не вестись на очевидное. Самые опасные ошибки — там, где «всем понятно». Отслеживать эмоциональность и предвзятость.
* Думать строго — про логичность, структурность, четкость. Тезисы, аргументы, если связь между ними. Замечать неявные предположения, о которых умалчивается, часто в них суть
* Проверять коварно — не залипать на первой гипотезе, смотреть спектр вариантов.

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

Доклад интересный. Но я хочу заметить, что есть два принципиально различных варианта мышления: нарративное, примером которого являются литературные тексты, но в повседневной жизни ей пользуются, и мышление структурными моделями разной степени формализации, при котором ты выделяешь типы и экземпляры объектов и не путаешь их, различаешь роли и индивидов, которые их играют, и так далее. ИИ мыслит нарративно. Так вот, доклад был об нарративном мышлении. Критическое мышление было лишь инструментом проверки нарративных текстов на формальную логику, разрывы аргументации, что важно. Но для аналитиков важнее структурное мышление моделями, и даже когда ему поступает текст — он должен его разметить, выделить понятия, определить их типы и так далее. ИИ, кстати, это тоже частично умеет — если специально попросить. Это базовое умение есть не у всех, в школе и институте этому не учат. В Школе системного менеджмента Левенчука об этом был курс Онтологики Прапион Медведевой, который сейчас вошел как часть [https://aisystant.system-school.ru/ курса Рациональной работы] (требуется регистрация, online-вариант доступен бесплатно).

А про причинную связь и отличие причин от корреляций я тут хочу порекомендовать книгу The Book of Why (есть по-русски), в которой как раз разбирается современная разделение причин от корреляций на материале проверки лекарств, выявления причин болезней и других подобных темах. Там не тривиально.

= Анастасия Кайнова. Deep Dive in Problem Solving: опыт сотрудника поддержки в карьере аналитика =

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

= Артем Шуткин. Аналитик как страховой агент взаимозаменяемости участников команды =

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

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

= Наталья Седова из Skillbox. Карта компетенций как вариант оценки и развития навыков аналитика =

При команде 15+ неформальное понимание о компетенциях сотрудников уже не укладывается в голове, его надо выложить в экзокортекс и сделать наглядным, а для этого — сделать структурным. Так появляется задача сделать карту компетенций. Она к ней подступалась несколько раз, но заканчивалось все длинными mindmap навыков на 225 вопросов, с которой непонятно что делать, стандартная оценка нет/знает/применяет/может обучить — не прививается в компании. Она поменяла подход. Создание карты запустила как командный проект, с разделением по задачам и людям. Это дало нужный организационный фокус, а еще карта компетенций получилась коллективным достоянием, она не была в одной голове. И это позволило оценивать карту компетенций через интервью с обсуждением вместо формальной оценки.

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

В заключении я хочу порекомендовать тем, кто тоже решит создавать карту компетенций, посмотреть имеющиеся конструкции. Есть довольно много докладов, где люди рассказывают про свое. Есть отраслевые конструкции, и тут я предлагаю смотреть не на российские стандарты, а на SFIA — там конструкция, которая мне больше нравится. У меня в свое время был доклад [[Профстандарты и модели компетенций - желания и возможности (TeamLead-2023)]]. Но не брать готовое. Основная фишка опыта, которым делилась Наталья — совместное создание карты компетенций командой, что сделало ее совместным достоянием и позволило проводить интервью многими людьми.

= Ирина Гертовская. Почему требования — не всегда требования. А если не требования — то что? =

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

Дальше были инструменты из BABOK: схема BACCM со связями: начинаем с контекста (предметной области) и стейкходеров, а затем надо понять потребности стейкхолдера и ценности — ради чего работает бизнес. Ключевой вопрос даже не «Зачем», а «кому нужно (кто будет деньги выбивать)?» — и у него спрашивать «зачем?». Далее области знаний, это по сути треки в проекте. И техники, которых в BABOK 50 с описанием на 185 страниц. И это — справочник, в который полезно заглянуть, чтобы не упустить что-то важное в новом проекте, чего у вас не было в предыдущих.

А при формирование требований не забыть полезна модель Грейди FURPS — функциональность, то есть выполнение системой своих функций. В ней, помимо основных функций — поддержка: администрирование, логгирование, инфобез, почта и соцсети, подсказки, печать…

Выводы.
* Системы для людей и для выполнения целей бизнеса
* Выявляем основное назначение, затем декомпозируем
* Серебряной пули нет, работа на результат — следствие многих техник.
* Не забываем про эффект второй системы. 
Что такое - эффект второй системы, слушатели не знали. Я быстро погуглил - он в том, что на смену маленьким и элегантным системам приходят тяжелые и сложные, с кучей ненужного функционала. А в переписке Ира меня поправила: "Брукс говорит о второй (порядковый номер) системе для каждого проектировщика, независимо от величины проекта:
общая тенденция заключается в перегруженности проекта второй системы идеями и украшательствами, благоразумно отложенными в сторону при работе над первым проектом."

= Евгений Скориков. Декомпозиция и композиция функциональных моделей при цифровизации бизнес-процессов на практике в аспекте множественности и параллельности =

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

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

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

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

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

= Ильназ Хайдаров из Московской биржи. Интеграция как предметная область: чем и как управляем? =

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

Я хочу отметить, что в ноябре на AnalystDays [https://analystdays.ru/ru/talk/125534 Лев Немировский из ПСБ делал аналогичный доклад], но для асинхронных интеграций, которые описываются спецификацией AsyncAPI ([[AnalystDays-2024b|мой конспект в отчете]].

= Ирина Баржак. Менеджмент конфликтов =

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

А дальше техника трех да. Люди не любят, когда их лишают выбора. Если вам навязывают дают дополнительный scope — не говорите нет, скажите: это можно, но втрое дороже, или вдвое медленнее, или если вы дадите нам людей. Можно несколько вариантов, и пусть он выберет. И другая техника — присоединение: признать проблемы и предложить вместе подумать над решением. Работает на поддержке и в call-центрах, Ирина обучала ей людей в МФЦ. Потому что кричать можно на другого, а тут вы получаетесь в одной команде.

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

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

В конце конспекта я хочу заметить, что у Ирины был аналогичный доклад осенью на SQAdays, вы можете посмотреть конспект в [[SQAdays-2024b|моем отчете]], и там же — ссылка на сайт конференции, где опубликовано видео и презентация. У меня про тот доклад были размышления о том, что безусловно помогая справиться с проблемами тем, кто в слабой позиции техники доклада при этом усиливают тех, кто уже обладая сильной позицией отвергают любую обратную связь. В этом докладе такого отчетливого впечатления не возникло — появился выход в конструктив через технику трех да, через присоединение. Техника трех да была и в прошлом докладе, но не так акцентировано. Наверное, есть и другие примы, или просто иллюстрация кейсами. И в целом доклад ценный, потому что очень важно, чтобы люди не плакали потому, что на работе на них кричат или обесценивают результат.

= Дмитрий Безуглый. Техплатформа как продукт: стратегия, развитие и коммуникация ценности =

Рассказать про техплатформы Дима не успел, эти слайды были в конце и он пробежал их пунктиром. Зато он далее весьма едкую картину траекторий развития ИТ-компаний. Но эо — в середине, а начал он с тезиса о том, что когда мы сидим в проекте, который делает какую-то хрень, то мы увеличиваем несчастье людей, хотя и получаем за это деньги. И вспомнил, что ЛАФ в 2010 начался с сообщества uml2.ru, которое собралось в 2005 как раз из людей, которые е хотели делать всякую хрень по классическим лекалам.

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

Дальше была цитата из доклада Димы на ЛАФ-2015. Три такта развития работы с требованиям у аналитиков:
* Управление требованиями — собрать и открыжить
* Разработка требований — перестаньте, наконец, их собирать и начните создавать
* Создание продуктов

И когда мы делаем продукт, то бесполезно создавать требования впрок, разработчиков надо кормить только свежими требованиями. Потому что продукт живет в непрерывно развивающемся динамичном окружении рынка. Это тоже цитата из какого-то доклада Димы на ЛАФ. Но сон разума в бюрократиях рождает чудовищ повсеместно, люди (например, из Минцифры) не понимают про динамику и свежие требования, а предлагают сделать roadmap развития продукта на 20 лет. Ну а теперь еще добавляют идею "и скормим этот роадмап GPT, чтобы следовал он. Какая такая цифровая трансформация? У нас как было хорошо с бюджетами, так и дальше хорошо. Правда, сейчас пришла справедливость и на эту поляну: бюджеты начали сокращать.

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

В инхаус-разработке есть проблема. Даже если вы делаете разработку в 10 раз быстрее, окупить не получается. Потому что 5 разработчиков — это 25 млн в год, не считая аналитиков и менеджеров. И это 20 сотрудников операционки, которые ручками что-то делают. Тут я не совсем согласен, вопрос в том. что именно делать. Обработки большого количества документов, например, для обеспечения эффективной логистики, в принципе невозможно организовать на ручном приводе с помощью Excel с малым количеством ошибок и со средствами разбора инцидентов. Есть области, где автоматизация дает принципиально новые возможности. Но ее далеко не всегда используют для этих целей. А еще, как справедливо отмечает Дима, в корпоративных структурах с правильными методами все очень медленно. Когда разработчик о задаче говорит «2 недели», это превращается в срок 6-12 месяцев для заказчика. И это в хорошей культуре. А банках от служебки о необходимости разработки до получения фичи пользователем часто проходит сильно больше года.

После всего этого вступления было то. что составляет основную часть доклада: варианты эволюции компании-команды. Компании начинаются в плоской стартап-модели (flat startup model), даже если в основе — не стартап продукта, а какая-то заказная разработка. Если компания развивается и увеличивается, то есть несколько вариантов. в зависимости от того, кто во главе.
* Тупичок Семейной компании (название Димы), в нем сохраняется теплая ламповая атмосфера, но есть предел — 70 человек.
* Если главный — хастлер-менеджер (hustler — энергичный пробивной делец, а также мошенник, шлюха и порножурнал), то получается функциональная структура с жесткими правилами. В простонародье — силос, кучи, где сгнивают идеи, и задача аналитика — отобрать из этих куч еще не сгнившее и скормить разработчикам. Таковы вендоры. А главные там бизнес-менеджеры и бизнес-аналитики, которые внутри продуктов не разбираются, видят их как входы в кроличьи норы, и с удивлением смотрят, откуда выпрыгнет кролик, если его туда запустить.
* Если преобладают хакеры с бэкграундом интеграторов, то получается проектная команда, IT-Project driven development. Про продукт там не понимают: «В смысле продукт? Мы проект делаем, продукт внутри». Но так не работает: проект — разовая активность, это штука без памяти, задача — забыть предыдущий опыт и идти к новому. Потому что когда тебе кажется, что это было — есть куча нюансов, которые все не позволяют. Но аналитики в таких компаниях как раз играют роль корпоративной памяти. подтягивают знание из прошлого. В теории это должны быть архитекторы, но на практике архитекторы выстраивают процессы согласования архитектуры из позиции «я здесь главный, вы обоснуйте ваши решения, тогда я, может быть, их утвержу». А на уровне управления в проектной модели некомпетентный ИТ-заказчик ставит требования некомпетентному в бизнесе разработчику — это вечная схема.
* Если преобладают хипстеры, то получается гибкая Agile-Tribe-Stream модель. Они делают продукт. Новый тип вендора, они все знают лучше пользователей и их благодетельствуют новыми фичами. Но когда у них заканчиваются деньги, полученные на пики первого взлета, и тогда на смену хипстерам могут придти хастлеры, начинают организовывать процессы, компания гниет.
 
Предупреждаю, что записывал с голоса пунктиром, а в отчете, превращая в связный набор тезисов, наверняка исказил слова. Но думаю, что смысл передал точно. И цель понятна — обесценить работу аналитиков вместе с содержанием большинства проектов, побудить их переместиться из позиции анализирующих или даже проектирующих, но для решения кем-то поставленных задач, в активную позицию тех, кто развивает продукт и принимает решения. Дима об этом говорит регулярно разными способами, в этом докладе было сказано таким образом. Я с этим тезисом не согласен, равно как и с неизбежностью таких негативных сценариев для большинства компаний. Я вижу, что жизнь разнообразнее. ЛЮди ищут разные компании, находят то. что им подходят, работают в них. Важно понимать, что есть большой спектр возможностей, и что рынок ИТ сейчас — это рынок выбора персонала, а не работодателя. Хотя при заключении контракта выбор всегда обоюдный.

GPT-модели могут дать второе дыхание проектной модели. Они готовы для замены аналитиков в ней. Эту модель в ближайшие годы ждут интересные изменения.
* Сделал RAG, дальше за 15 минут проанализировал 200 внешних и 50 внутренних источников и готов выдать отчет любого объема, вам 10, 20 или 150 страниц нужно?
* Требования от GPT лучше, чем требования от человека, они логичны и выверены, а проблемы — скрыты.
* В команду вкидываем не спеку, а userstory, и сразу получаем результат.
* Зачем нужны фронтендеры? Нарисовал wire-фрейм, дальше все понятно. А можно вкинуть копилоту. То есть или аналитик заберет работу разработчика, или наоборот, разработчик с помощью GPT заберет работу аналитика. В разных командах будет по-разному наверняка. Вы смотрите, как будет в вашей.
* Хороший архитектор закроет стандартизированную layer-архитектуру с помощью co-pilot. У каждой системы есть прибитая граница, где стандартизированный API — это уже закрывают аналитики с помощью GPT, через пару лет и аналитик будет не нужен, и разработчик тоже. Разработчики нужны там, где гибкая открытая граница.
* Для аналитиков перспектива в том, что текущий менеджер не может с помощью GPT сделать ничего: не умеет задавать вопросы, не понимает ответы. В текущей конструкции аналитики направляют силы на удовлетворение менеджеров. Но GPT развивается, и чЧерез два года научится понимать менеджеров, заберет роль коммуникативного клея. Если вы не будете в позиции принимающих решений, то остальные не нужны.
Это тоже была запись пунктиром с голоса, так что наверняка есть искажения смысла. Часть тезисов Дима говорил уже после платформ, я перенес сюда. Но, как я уже писал, доклад [[#Регина Шарафутдинова и Мария Хромых из Газпромнефти. Будущее бизнес-анализа: Роль критического мышления в эпоху автоматизации и ИИ]] показывает начало значительных изменений, связанных с повседневным использованием GPT.

В последней части пунктиром было про платформы, потому что время почти закончилось.
* P0 уровень платформы — тулбокс для разработчиков, core-команда. Аналитики там не нужны.
* P1 — технические платформа. Там уже законченные сервисы, обеспечивающие обвязку для содержательной части приложений. Аутентификация, логирование и так далее, прямой пользы пользователям от этих сервисов нет. Проектируют архитекторы, но аналитики тоже могут. А для выхода на следующий уровень нужны именно аналитики.
* P2 — бизнес-платформа, платформа масштабирования. На входе им нужна тех.платформа, на песке строить нельзя. И аналитики, разбирающиеся в техплатформе тоже нужны. Если мы в компании унифицируем платежи — это экономия 5 человек в каждой команде и так далее.
** В notion монолит рулит — это не бизнес-система, это простое приложение, которое техплатформа его отмасштабировала на множество пользователей.
** Технологическая платформа может обеспечить конкурентное преимущество. У zoom протокол передачи видео работает на тех каналах, на которых не работают открытые библиотеки. Правда, все остальное при этом может лежать, канал забивают полностью. Но — работают. Этим обусловлен успех. У остальных видео — на открытых библиотеках и на плохих каналах, в том числе когде трафик административно режут, это не работает. Но вот навороты поверх, который zoom пробует делать — не взлетают.
* P5 Платформа — ядро экосистемы. Microsoft, FANG (Facebook-Amazon-Netflix-Google), OpenAI. Об этом подробно не было, а уровень P4 где-то по пути был.

= Максим Дорофеев. Душнота по понятиям как детектор логических ошибок =

Мастер-класс Максима Дорофеева стоял параллельно с докладом Дмитрия Безуглого, но был длиннее, поэтому я успел посмотреть последнюю треть. А концепцию мне в кулуарах рассказал сам автор.

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

Отмечу, что это довольно похоже к чувству онтологического дребезга, о котором говорит Прапион Медведева в [https://aisystant.system-school.ru/ курсе Рациональная работа Школы системного менеджмента Анатолия Левенчука] (доступно бесплатно после регистрации, но без всех упражнений). Хотя Прапион говорит не о синтаксической проверке, а о понятийной разметке текстов, это больше, чем проверка логики, это построение модели, при чем на быстром мышлении, но с проверками. В этом смыле делать логические проверки на быстром мышлении тоже можно натренироваться, потому что логический язык — частный случай схемного мышления, это будет тренировка перевода услышанного в схемы. Но тренировка строить на быстром мышлении онтологические модели — полезнее, решается более сложная задача, чем просто логическая проверка, потому что с моделью дальше можно работать.

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

Проверка реальности действия:
* Глагол — наблюдаемое действие: не «соседний отдел не хочет выполнять работу», а «мы переделываем больше половины задач от них»
* Глагол — не идиома: руководиель не задушил идею, а потребовал обоснований
* Глагол в активном залоге: не «я получил повышение», а «руководитель меня назначил»

Проверка на понятность объема понятий.
* Существительные — речь идет про все экземпляры, или некоторые, или конкретные экземпляры? Если написано «хочу быстрее делать задачи» — о каких задачах идет речь?
* Глагол — аналогично, это происходит всегда, иногда, часто, редко. Если написано «команда продалбывает сроки» — она это делает каждый раз, или часто, или вообще сделала один раз и все запомнили?
И тут надо быть особенно осторожным, потому что часто в подобных утверждениях еще и используют вымышленные цифры. «Вдвое быстрее» — а почему вдвое, а не в 1.5 раза или в три? «Продалбывает половину задач» или «делает вдвое дольше» — это почти всегда по нечетким ощущениям, статистика может показать что угодно.

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

Например, в утверждении «Чтобы переехать в загородный дом, надо найти удаленную работу» ответ «При работе в офисе я буду тратить слишком много времени на дорогу» — умозаключение. А может быть «Я раньше летом уезжал на дачу, это два часа дороги туда и столько же обратно, и сильно выматывался» — личный опыт. А «Вася сказал, что тебе потребуется три часа в день на дорогу и ты сдохнешь» — свидетельство другого. Все варианты подлежат проверке, и проверки — разные. Но главное тут во-время сделать стойку на неясные основания и задать вопрос. Есть языки, где основания вшиты в грамматику, если вы говорите «менеджеры проекта выгорают», то форма глагола уже показывает: я видел, мне сказали, или я так думаю по косвенным признакам. Русский — не такой.

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

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

= Ольга Подолина. BABOK — как извлечь полезное =

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

BABOK долгое время был сакральным знанием, доступным только сертифицированным специалистам соответствующего института. А тут они опубликовали его в свободном доступе и есть русский перевод, он доступен на сайте [https://business-analytics-russia.ru/ business-analytics-russia.ru]. А Ольга проводила обучение BABOK по заказу Центробанка и проработала материал. Результат ей не сильно понравился, книга написана так, что учить по ней невозможно. Это не учебник (manual), а справочник (reference). Но в ней собрано много полезной информации со ссылками и она хорошо структурирована. И у Ольги задача — собрать сообщество заинтересованных и сделать-таки приемлемый учебник, потому что жалко содержания, которое пропадает.

Ольга сделала очень интересный шаг по популяризации изложения — написала книгу, где основные положения положены на сюжет фэнтези. Книга [https://www.litres.ru/book/olga-georgievna-podo/agentstvo-svet-dalekoy-zvezdy-biznes-analiz-po-babok-72007435/ бесплатно доступна на litres]? она выложена как черновик и постоянно дописывается. А пришедшим на доклад был еще бумажный авторский экземпляр с автографом автора. Я еще не читал, но в планах есть.

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

А потом было обсуждение, обмен опытом изучения BABOK — его смотрела не только Ольга, и не только она пыталась учить. Если сообщество организуется, думаю, будет полезно. Впрочем, тут надо отметить, что и BABOK и PMBOK несут родовые проблемы: первая версия появилась в те времена, когда казалось, что можно подумать — и сделать правильный метод, следуя которому решать задачи изменения бизнеса или ведения проекта можно с гарантированным результатом, бюджетом и сроками. А это — ложное убеждение. В ИТ-разработке понимание принципиальной невозмжности такого метода привело к появлению, а затем повсеместному распространению Agile-методов. Авторы стандартов не могли это игнорировать, попробовали сделать гибриды, но получилось плохо. Во всяком случае в PMBOK, и в результате PMI-институт смирился, и сертифицирует не только по классическому проектному управлению, но и по Agile-методам. И это — закономерно, потому что различие носит принципиальный характер, это разный mindset, то есть разные представления о конструкции мира. У меня об этом есть статья [https://vc.ru/hr/272211 '''Agile-методы и проектный подход — в чем разница?'''] и доклад '''[[Почему проектный подход не работает в IT (Teamlead-2022)]]'''. B это различие картин мира необходимо учитывать, когда работаешь с BABOK и PMBOK.

= Елизавета Румянцева из Альта Текнолоджи. IT Ординатура. Как накормить компанию в условиях кадрового голода =
 
Альта Текнолоджи — небольшая компания, выросшая за несколько лет от 40 до 80 человек. Есть проблема обеспечить этот рост наймом персонала. И они пошли по пути организации стажировок. Успешно, было два потока, разработчиков и аналитиков, и большинство выпускников проработали в компании уже более года, а разработчики — более двух. При этом по экономике стажировки обходятся дешевле, чем найм персонала: по рынку найм и погружение примерно обходится в шесть окладов, а стажировки сейчас 4.75, и они думают, что цифра еще сократиться. И по срокам тоже достаточно быстро: стажировка занимает 2.5 месяца (если я не путаю), на выходе есть 4-7 человек в штате, уже погруженные в контекст проектов компании — они на стажировке работали над реальными проектами. Вполне нормальная скорость. И они не планируют делать стажировки регулярным процессом, а обращаются по необходимости, под планируемую потребность.

Стажировку разработчиков они проводили с помощью аутсорсинга, была команда коучей, а сами готовили материалы. А вторую, для аналитиков, решили проводить сами. На входе информация широко публикуется, и дальше — первичный отсев, кого взять в группу. На стажировку стажеров было 500+ откликов, но за счет простенького теста и технического собеседования отсеялось очень много, а на аналитиков откликов было в 10 раз меньше, но и отсев гораздо меньше. Дальше со стажером подписывают юридически обязывающий договор, предусматривающий, что при успехе он должен полгода отработать в компании или компенсировать затраты на стажировку, включая стипендию. Сумма стипендии «по нижней планке джуна». Там был пункт о праве отчислить «если будет филонить», но им по факту не пользовались — все стажеры старались, горящие глаза были одним из критериев отбора. Но получалось не у всех, кто-то уходил, поняв, что это не его, кого-то отчисляли по результатам аттестации — стажировка была разбита на 3 этапа по три недели после вводной недели. Но в этом случае компенсаций от стажеров не требовали. Набирали вчерашних студентов, так как они еще «в потоке обучения».

Стажер учится полную неделю, 40 часов, участие во всех занятиях обязательно. Всего 72 часа лекций, 400 часов практики, 28 часов коучинга и коммуникаций, 20 часов психологии. Коучинг получился по месту: услышала про проблемы с организацией времени — экспромт-лекция. А больше было встреч с экспертами из соседних подразделений — девопсы, продукты, разработчики. Митап, сначала был короткий рассказ, что ждут от аналитика, потом вопросы. Узнали много нового даже сами — о том, чему были рады, а где смирились.

Лекции — по живым проектам, лектор свой, из бывших сотрудников, ушедший преподавать, он знал проекты и взял три разноплановых, которые детально разбирал на лекциях. Содержание: диаграммы, swagger, sql, проектирование архитектуры, гост-34, ux, функциональные и нефункциональные требования, use case.

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

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

Как я писал в начале, в целом — успешно и экономически оправдано.
{{wl-publish: 2025-06-10 09:22:43 +0300 | MaksTsepkov }}