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

#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-код для показа на кассе, то именно для него хорошо бы применить паттерн автономной работы с периодическим обновлением - чтобы если сеть затупила в тот момент, когда покупатель выбивает чек, не создавалась очередь других покупателей. А вот все остальное может работать только при приемлемой сети - за счет этого можно использовать шаблон тонкого клиента, обновляя преимущественно серверную часть. Отметим, что способ преодоления в этом случае, как и во многих других, необходимо заложить в архитектуру решения. И, возможно, обсудить с бизнесом.

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

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

#lafest Ирина Баржак. Как вытащить требования из заказчика без гипноза (и без паяльника)? Я слушал только вторую половину доклада, потому что он пересекался с докладом Жени Скорикова. Поэтому кратко. Ирина рассказывала модель GROW структурирования встречи и задавания вопросов, которая разработана в коучинге. Встреча делится на четыре части
1) Goal - Цели, зачем почему и что мы хотим сделать
2) Reality - реальность сейчас, как это устроено, какие с этим проблемы, почему они появились и так далее
3) Options - возможности по решению проблем: какие вы видите, чтобы вы посоветовали в такой ситуации другу и так далее
4) Way Forward - как приступить к действиям - какой первый шаг, что надо предусмотреть и так далее
К каждой части на слайде было больше десятка вопросов, которые могут помочь вытащить информацию. вопросы - нетривиальные, участники придумывали свои с интересными формулировками. Например, "как наши действия помогут вам достичь наших целей?" - это про цели.

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