https://youtu.be/8nI2STePwQQ

Видео вчерашних чаепитий с Максимом

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

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

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

Вышел подкаст Бирюзовые организации и самоуправление в ИТ в 2023 году с моим участием на ITBizRadio. Разговор был очень содержательным и интересным, получилось затронуть очень разные кейсы и аспекты самоуправления, поговорить об исторических основаниях, о том, что сейчас происходит в разных компаниях и о практическом применении. Вообще разговор шел из практического залога, от практики к теоретическим основаниям, а не наоборот. И он сейчас продолжается в чатике канала https://t.me/ITBizRadio_chat. А вообще на канале много интересных материалов, смотрите.

В четверг 09.02 в 18:00 (мск) у меня вебинар в Школе Системного Анализа (Денис Бесков). Будет разговор про Domain Driven Design - основы, отличия от других подходов, вопросы применения. Это будет не лекция, а живой разговор, можно будет задать свои вопросы. Регистрация по ссылке https://sysanschool.timepad.ru/event/2315991/ Приходите!

Очередная статья по самоопределению https://vc.ru/hr/601692 «Понимаем себя и других» рассказывает о типологиях человека, которые дают способ понять мышление другого, сильно отличающегося от тебя человека. Ведь человек действует в команде, совместно с другими. Сильными являются команды непохожих, однородные команды – слабы, это показали исследования Белбина. И вам надо коммуницировать и взаимодействовать с разными людьми на вашем пути в будущее. Типологии позволяют делать это эффективно.

В пятницу-субботу прошла шестая конференция Живая компания. Публикую отчет https://mtsepkov.org/LiveBusiness2023 Я бы уверенно оценил эту конференцию "выше ожиданий" по содержанию докладов, качеству общения и организации самой конференции! Поэтому громадное спаcибо всем: организаторам, спикерам и участникам.

Дополнение о конференции Живая компания: Валера Разгуляев написал, что его презентацией можно делиться, и я включил ее в отчет https://mtsepkov.org/LiveBusiness2023

Опубликовано видео https://youtu.be/D6YEeBUard8 моего вебинара 09.02 в Школе Системного Анализа Дениса Бескова с таймкодами, разбивкой на эпизоды, ссылками на презентации, которые я использовал и полезные материалы. Получилось очень хорошо, такая публикация - супер!

Продолжение - https://youtu.be/ruOBs4EF-oo

Очередная статья по самоопределению https://vc.ru/hr/617491 посвящена применению модели спиральной динамики к вопросам самоопределения. Я уже касался этой модели, говорят о корпоративных культурах в статье «Человек для компании или компания для человека?», а в этой статье рассмотрю два прикладных аспекта: различные представления о том, что такое самоопределение, связанные с каждым уровнем и путь по уровням при освоении новой деятельности.

На #TeamLeadConf я, к сожалению, был только первый день. Но успел услышать в докладах много ценного. Так что даже не публиковал заметок в ходе конференции, потому что содержания в докладах было много и превратить конспект в публикуемый текст прямо в ходе конференции не получалось. Поэтому читайте отчет https://mtsepkov.org/Teamlead-2023 - в нем это сделано. Отчет будет дополняться, я точно посмотрю доклад Анны Обуховой, на который не смог пойти, потому что он шел параллельно с моим, и, возможно, другие доклады, и буду писать о том, что посмотрю.

Очередная статья по самоопределению https://vc.ru/hr/648132 «Надо ли идти к светлому будущему?» о том, стоит ли непременно идти путем развития, и надо ли направлять на этот путь других, если вам кажется. что они лишь плывут по течению и не реализуют свой потенциал. Думаю, она будет завершающей в этой серии статей. И надеюсь, что схемы в них помогут вам в самоопределении, как помогают мне.

Я тут поехал отдохнуть в Гоа, был на интересной экскурсии про Португальское наследие, рассказ и фотки - в моем ЖЖ https://maksiq.livejournal.com/146736.html Читайте, кому интересно.

Сегодня я на #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 Школа продолжает поступательное движение вперед и это - радует.