2023-05-16: AnalystDays - высокое качество докладов

Короткая ссылка: AnalystDays-2023a

Ссылки сюда (1) →

О других конференциях

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

Я публиковал впечатления с докладов сразу в ходе конференции, и сейчас собираю из них отчет. К сожалению, у меня получилось быть только первый день, потому что второй пересекся с конференцией Школы системного менеджмента (мой репортаж), поэтому в репортаже наверняка нет многих ценных докладов.

Мой доклад Требования или модели - как писать постановки

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

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

А еще я планирую продолжить эту тему на ЛАФ 9-11.06, фокусируясь на Domain Driven Design в современных условиях. Об этом у меня тоже был доклад 10 лет назад, с тех пор видение существенно развивалось: появилось понимание отличий DDD от построения объектных моделей (OOAD), осознание различий между проектированием автоматизации «с чистого листа» и заменой существующей основной системы, представление о применении DDD в современной микросервисной архитектуре и многое другое.

Юрий Куприянов, ChatGPT в работе аналитика

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

Леонид Юденков. Рациональное "нет". Как отказать бизнесу и остаться друзьями

Рассказ о типовых конфликтах при взаимоотношении с бизнесом.

Модель-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 до стратегического партнерства.

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

Александра Дахина из SM Lab. Как мы учим бизнес готовить вкусные дашборды

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

Дашборд - красивые интерактивные визуализации с быстрыми фильтрами и drill-down. Вкусные: функциональные, производительные, красивые.

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

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

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

Что обеспечено.

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

Ильдар Гиматдинов. Архитектор системы vs Архитектор решения

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

Александр Теплицкий из Райффайзена. От монолита к микросервисам

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

Надо принять решение по принципам.

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

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

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

Шаги изменения, на примере выделения отправки документа и файла от из интернет-банка в банковские системы исполнения.

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

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

Татьяна Яковлева. Инструменты для визуализации данных: от простого к сложному

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 11:38, 16 мая 2023 • нет комментариев