Сегодня я на #AnalystDays. Первый доклад - Юрий Куприянов, ChatGPT в работе аналитика. Очень подробный рассказ про использование ChatGPT в роли помощника аналитика, с примерами из разных предметных областей. Что он может сделать? Помочь разобраться в предметной области, сделать план интервью, самому провести интерфейс с тобой, построить по тексту модель объектов и связей, построить диаграмму бизнес-процессов, диаграмму классов и диаграмму последовательности по текстовым описаниям, описать user story и use case, сделать SRS на приложение, предложить API интеграции, сделать описание по коду, написать SQL-запрос. Графики он строит через вывод результатов в формате graphviz или plantuml или bpmn, дальше их копируешь. Ответы - уточняешь и просишь дополнить. В докладе все было достаточно подробно, с техникой развернутых вопросов, примерами детализации ответов, и это можно увидеть в презентации, которая будет очень скоро. Все это не значит, что ChatGPT заменит аналитика, но он его явно усилит. И Юра сказал, что в последнее время все больше использует эти возможности в реальной работе. Что круто.

#AnalystDays Леонид Юденков. Рациональное "нет". Как отказать бизнесу и остаться друзьями. Рассказ о типовых конфликтах при взаимоотношении с бизнесом.

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

Модель-2. Команда продукта или проекта, вместо рынка - бизнес. Инхауз, заказная разработка и так далее. В команде тогда Proxy PO. Команда разработки контролирует ресурсы и качество, а у бизнеса - бюджет и желаемые сроки (новая версия - до годовой отчетности или новогодних распродаж).

В Модели-2 вместо гипотез появляются Требования. И требования - довольно жестко, они у террористов или детей. Аналитик - между бизнесом и командой. И что делать, если они не конструктивны, вредны для архитектуры и так далее.

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

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

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

Решение вместо потребности. Нужно размотать задачу до исходной проблемы (pain point) и ее носителя. Очень аккуратно и бережно - кто-то сделал работу и ее нельзя обесценить, даже если у него не получилось.

Вредные требования, нарушающие архитектуру, подходы к дизайну и т.д. Главное - понять, почему выдвигаются требования именно в таком виде. Бизнес пытается решить проблемы так, как видит? и у него есть основания. Например, добавить blockchain - потому что министр сказал "в любой нормальной системе должен быть blockchain" - и они развернули мини-сетку, куда скидывали логи при смене состояния, дешевая штука, которую потом выпилили.

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

Негативные паттерны. Могут быть оправданы, но точечно.
* Радикальный отказ. Этим мы сжигаем мостик, не слушаем потребности. Это может решить здесь и сейчас, но в долгую - в минус.
* Конфронтация. Можно, но очень осторожно. И не факт, что поможет.
* Соглашательство или пассивное согласие. Деморализация и аналитика и команды.

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

Матрица: Эффективность в моменте против долговременного партнерства.

Переговорная теория и концепция win-win. Есть теория для разовых переговоров, управленческих поединков, когда извлекаешь максимум профита в моменте. Это стратегия win-lose, и вдолгую она не оправдывается.

Что делать, если партнер не хочет сотрудничать? Тогда используйте переговоры win-lose, отказывайте четко и аргументировано, вызывайте контролируемый конфликт, привлекайте дополнительный вес - эскалация. Или дайте бизнесу просто ошибиться.

Business Relationship Maturity Model - 5 уровней, от работы по запросу ad hoc до стратегического партнерства.

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

#AnalystDays Александра Дахина из SM Lab. Как мы учим бизнес готовить вкусные дашборды. Они используют Tableau, в котором очень много возможностей, но он сложен, хотя порог входа для простых дашбордов - низкий. Дашбордов надо много, и большинство из них - простые. Поэтому решение - ревью готовых дашбордов, который готовят начинающие разработчики или даже бизнес, которое позволяет быстро обучать людей готовить вкусные дашборды.

Дашборд - красивые интерактивные визуализации с быстрыми фильтрами и drill-down. Вкусные: функциональные, производительные, красивые.
* Функциональные - облегчают принятие решений, отвечают на нужные вопросы - не надо сопоставлять дофига данных вручную, не заставляют страдать пользователей - интуитивно-понятные
* Производительные - не ждешь ответа, заваривая чай, случайные нажатия не приводят к непонятным переходам.
* Красивые: облегчают принятие решений, тип визуализации отвечают задачам, не диаграммы с 20 сегментами, в которых не разберешься, единый стиль, хорошие цвета и текст.

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

На каждое ревью - задача в jira, в которой описание и ссылка на задачу. Первый шаг ревьюера - до 3 дней, обычно один, результат - список замечаний в confluence. Дальше доработка, срок - 2 недели. Если не успели - задача уходит в песочницу. После доработки - новое ревью. Чек-лист проверки. 7 разделов: источники, вычисления, фильтры, визуализация, дашборд, общее оформление, правила публикации. 66 критериев. Есть обязательные требования (фильтр по дате обновляется при открытии), технические критерии, рекомендации, style guide.

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

#AnalystDays Ильдар Гиматдинов. Архитектор системы vs Архитектор решения. Очень интересное сопоставление двух архитекторов. Software Architect отвечает за архитектуру приложений вместе технологическим уровнем, а Solution Architect обеспечивает согласованное понимание на всех уровнях, вертикальный колодец от стратегии и бизнес-архитектуры до архитектуры приложений и технологическая. В докладе было два разных взгляда на интернет-банкинг как модельный пример. Фокус первого - на стоимость владения, на выверенную архитектуру и правильные, выверенные решения. А второго - на поддержку бизнеса, на гибкость системы. Оба используют диаграммы, но разные, потому что разные viewpoint. Хотя основой для обоих может быть Archimate. Для Архитектора систем хорошо подходит c4model. Хорошая диаграмма - вложенные компоненты и потоки данных между ними. Архитектор решений -связь уровней: бизнес и его поддержка на уровне приложений. Архитектор решений борется за понимание, однако упрощение не должно скрывать сложность, которая вскроется на этапе реализации. Бизнес должен понимать сложность решения.

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

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

Не пишем сразу все микросервисы с однократным переходом, а переводим постепенно. Фаулер: если вы переписываете все и сразу, то у вас получится только сломать все и сразу.

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

Шаги изменения, на примере выделения отправки документа и файла от из интернет-банка в банковские системы исполнения.
* Собрали отправку файла в отдельный компонент file-sender внутри монолита
* Поставили перед отправкой файла отдельный интерфейс
* Сделали собственный отдельный сервис на основе выделенной отправки файла
* Поставили в интерфейсе переключатель: используем встроенный компонент или вызываем внешний сервис
* Переключаем, проверяем
* Убираем отправку файла из монолита.

Работа с данными на переходе. Для обкатки - можно напрямую обратиться к БД монолита. Потом - определяем данные, их передаем в API, делаем отдельное хранение.

#AnalystDays Татьяна Яковлева. Инструменты для визуализации данных: от простого к сложному. Хорошая личная история развития аналитика: от анализа данных в Excel к созданию там дашборд, подключенного к базе данных и далее - к дашбордам на python dash. Вывод: все доступно, дорогу осилит идущий, на этой дороге сложностей нет, а где есть, например, с CI/CD - разработчики помогут.

#AnalystDays Презентация моего доклада опубликована у меня на сайте https://mtsepkov.org/ReqVsModel

В выходные был на конференции Школы системного менеджмента Анатолия Левенчука и публикую отчет https://mtsepkov.org/SysSchool2023 Школа продолжает поступательное движение вперед и это - радует.

Анатолий Левенчук на конференции ШСМ говорил о четырех ролях созидателей-инженеров и четырех ролях менеджеров. Если на них посмотреть, то можно увидеть соответствие с ролями в развитии системы разделения труда, которые выделяет Петр Щедровицкий, стилями руководства Адизеса и структурой организации по Минцбергу. Сопоставление представляется интересным, и я написал о нем статью https://vc.ru/hr/681839-chetyre-osnovnye-roli-v-kompanii Думаю, такое сравнение взглядов разных теорий будет полезным.

В конце марта прошла первая ИТ-конференция МТС TrueTechDay. Организаторам удалось собрать очень качественный контент, и я надеюсь, что уровень следующих конференций будет не хуже. Читайте https://mtsepkov.org/TrueTechDay-2023 - мой отчет с конференции.

Проходя учебник по курсу онтологики Школы системного менеджмента Анатолия Левенчука, решил разобраться с онтологиями социальных отношений. Публикую результат https://mtsepkov.org/SocialOntology как учебную работу. Получилось много букв, что логично для такой темы. Но, думаю, будет полезно не только мне.

Весенняя конференция #AnalystDays порадовала меня содержанием докладов: по моим впечатлениям, улучшилось с прошлой конференции. Я публиковал впечатления с докладов сразу в ходе конференции, и сейчас собрал из них отчет https://mtsepkov.org/AnalystDays-2023a К сожалению, у меня получилось быть только первый день, потому что второй пересекся с конференцией Школы системного менеджмента, поэтому в репортаже наверняка нет многих ценных докладов.

Всем привет! Павел Ступко, которого я знаю достаточно долго, проводит вебинар на интересную тему. Он и его коллеги используют при внедрении 1С практики бирюзовых организаций. И Павел хочет поделиться этим опытом на бесплатном вебинаре завтра 25.05 в 16:00 https://sites.google.com/iteal.expert/vebinar-25-05 Думаю, будет интересно.

Проходя учебник по курсу онтологики Школы системного менеджмента Анатолия Левенчука, вспомнил альтернативные базовые (foundation) онтологии, которые мне рассказывали давным-давно на курсе философии в МФТИ и о которых читал в разных книгах. И мне показалось интересным написать о них https://mtsepkov.org/AltFndOntology А вам, возможно, любопытно будет почитать.

В своей работе часто вижу, как налаживание реальных бизнес-процессов подменяют налаживанием процессов согласования документов. А ведь это – симуляция: цель бизнес-процесса – технологичное создание ценности, а согласование внутреннего документа ценности не несет, а наоборот, замедляет процесс ее создания. Проблема распространенная, и потому написал об этом отдельную статью https://vc.ru/hr/716180 Потому что в организациях часто уверены, что хотя их конкретный процесс имеет недостатки, в целом процесс согласования документов – штука нужная и правильная.

#lafest Сегодня на ЛАФ-2023, это интересная и содержательная конференция. Первый доклад Сергей Нужненко. Занимательная картография и археология для аналитиков. По системам часто нет документов или громадное количество доков с инкрементом без целостного описания. Это может быть и с легаси, и с относительно свежей системой - пара студентов за год могут очень многое написать. И получается змея, кусающая хвост: бизнес спрашивает у аналитиков, аналитики - у бизнеса. Реверс за 10% затрат для системы которую 6-10 человек писали 10 лет - не реалистичен. Надо уметь понять существующее относительно дешево. Как сделать обрывочную, неточную, но полезную карту. Часто именно такую задачу ставят аналитикам. Об этом - доклад, это и есть картография и археология. Проблема типична, потому что постоянная актуализация - она тяжелая.

Что нам надо картировать, описывает V-модель, к которой сейчас наверху надо достроить бизнесовую часть. И дальше был краткий рассказ про карты, которые прижились.
* Короткая бизнес-модель
* Карта деятельности: CJM + Service, BluePrint, Карта процессов; Value stream maping. B все это - на встречах
* Карта пользователей историй Story map
* Карта системного ландшафта - потоки данных
* Карты систем: функциональная; информационная; развертывания доступа и обслуживания -- это архитектура

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

Карты деятельности: Карта процессов и Цепочка прибавленной стоимости; Customet Journey Map + Service BluePrint - что за сценой.

Из CJM получается Story map. Есть еще Impact Mapping: цели, деятельность. Но на ней можно потерять важное.

Раньше аналитик описывал поведение системы в целом, и команде было достаточно для разработки. А сейчас требуется перевести это во взаимодействие сервисов, фронта и бэка. Это DataFlow диаграмма. Что сервис хранит, что он получает, что выдает другим. Форматы, что передается, интерфейсы.

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

Функциональные карты: use case, DFD, User story mapping, Sequence, Robustness...
Информационная карта. Функции меняются, информация живет годами.

Получаем карту с белыми пятнами: здесь копали, здесь не копали. Но она - корректная.

Я отмечу, что тут все равно много получается. Но! Это дешевле, чем полное описание "по старым канонам", и реально можно делать неполно.

#lafest Бунто Татьяна. ETL-интеграции без валидола. Хороший доклад про разработку надежно работающей интеграции между разными системами. Про особенности и распространенные грабли, которые надо учитывать. Дальше - содержание в тезисах.
* ETL: Extract - Transform - Load. Разобраться надо со всеми тремя частями. И нужны команды, готовые отвечать.
* Надо всегда рассчитывать, что после загрузки будут корректировочные инкременты, до нескольких лет.
* Перелив данных может идти долго, у них было до 20 дней. Исправление и полная перегрузка при этом тоже 20 дней, полезна точечная перегрузка.
* В реальном мире часто интегрируют сразу на продах. Или Prod->Test. Потому что тестовые контура могут отсутствовать или не содержать репрезентативных данных. И это требует заранее проработать доступы, и дает требования на нагрузку.
* Сделайте чек лист условий для запуска: реализованы представления, открыты каналы, установлены нужные релизы и так далее.
* Трассируем бизнес-данные на их хранение в системах источниках. Например, где правильные телефоны и емейлы для юриков и физиков - это может быть в разных местах.
* Фильтры отбора: только клиентов с контрактами, или не грузите технических абонентов, или не грузите если есть признак устаревшего. Все это надо перевести в технические условия и посмотреть, что получается.
* Система-приемник. Там таблицы, ключи, обязательные поля, которые могут быть пустыми в источнике - что делать.
* Совместимость типов, особенно с датами и часовыми поясами. Что делать, когда строки не лезут в приемнике.
* Протокол системы-приемника. Например, система модет быть рассчитана только на ежедневные инкременты, а может быть на нумерацию.
* Ключи. Бывает, что в системе-источнике контактные лица юрика - вообще не отдельные сущности-люди, а в системе-приемнике есть таблица физ-лиц контактов с идентичностью.
* Событийная модель. Не только создание или изменение, а с учетом фильтров. Например, абонент стал анонимным, которого не грузим.
* Логирование. Чтобы интеграция записывала, что сделала, и почему упала, и фиксировала - что там было, и в каком сообщении это пришло.
* Срочные догрузки: я нашел карточку, и срочно загрузите. Да еще со связанными сущностями. И это задача точечной перегрузки.
В том числе - перегрузка пула ошибочных записей, которые нашли.
* Сверки могут быть, но они дорогие для нагруженных базах. Поэтому это обычно не регулярная процедура, а разовая.
* На начальной стадии нужно тестирование, в том числе через сверку на репрезентативных кейсах.
* Все учесть невозможно. Надо мониторить и быть готовым ко всему. Например, прилетит огромный инкремент, потому что в системе-источнике решили что-то глобально обновить.

#lafest Презентация моего доклада - на моем сайте https://mtsepkov.org/DDD-LAF2023

#lafest Андрей Василевский. Мысли как архитектор. Распиливаем монолит с помощью шаблонов DDD. В докладе - конкретная методика. Сначала Event Storming для выявления групп процессов. Добавляем набор объектов, с которыми эти процессы работают. Кластеризуем процессы по их общему, визуально группируем. Границы кластеров - размыты. Если просто использовать эти группы для разрезания монолита, получится микролит - сильно связанные сервисы.

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

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

#lafest Евгений Скориков. Нефункциональные требования? Модели обеспечения качества! Очень хороший доклад, о том, что нефункциональные требования в их привычном виде "отказоустойчивость 99.5%" или "отклик системы 5 секунд" - совершенно бесполезная вещь: непонятна осмысленность, способы удовлетворения и тестирования и риски. 99.5% - это 0.5% сбоев, если система не работает в год 1.5 суток подряд - это как, нормально? Для многих - ненормально, хотя в норматив формально укладывается. В общем, эта критика - понятная, эти требования часто берут произвольно. Например, по производительности, кстати, нет достоверных исследований: как именно скорость работы сайта влияет на бизнес. Понятно, что если ваш сайт жутко тормозит, и есть сайт конкурента, который делает все тоже самое и быстро, то люди уйдут туда. Но в реальной жизни сайт конкурента делает НЕ тоже самое, там есть чего-то меньше и чего-то больше, у него есть другая эргономика. И как это влияет? Исследований нет. Честное исследование - замедлить сайт для части клиентов и сравнить, но на это ни один бизнес не пойдет.

Гораздо интереснее, что в докладе был рассказ, чем их следует заменять, чтобы это имело смысл и реально работало. С практическими примерами, которые в интерактиве обсуждали с аудиторией. Общая схема такова.
1) Берем аспекты работы с системами: отказоустойчивость, производительность, масштабируемость, эргономичность интерфейса и другие.
2) Для каждого аспекта есть специфические проблемы, и мы декомпозируем систему с точки зрения этих проблем. Например, для отказоустойчисовти смотрим на отказы базы данных, серверов приложений, сетевой инфраструктуры, клиентских приложений. Для производительности - деградацию на выполнении различных функций. И так далее.
3) Выписываем возможные проблемы в каждой части, оцениваем их значимость: если это случится - каковы последствия, потери для бизнеса.
4) Для проблем - есть специфические тактики предотвращения, которые снижают ущерб и имеют определенную стоимость. Выбираем тактики и проектируем варианты решения.
5) Выбор решения - по балансу потерь против стоимости.
6) Проектируем тест выбранного решения.

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

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