Дополнение о конференции Живая компания: Валера Разгуляев написал, что его презентацией можно делиться, и я включил ее в отчет 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 Школа продолжает поступательное движение вперед и это - радует.

Анатолий Левенчук на конференции ШСМ говорил о четырех ролях созидателей-инженеров и четырех ролях менеджеров. Если на них посмотреть, то можно увидеть соответствие с ролями в развитии системы разделения труда, которые выделяет Петр Щедровицкий, стилями руководства Адизеса и структурой организации по Минцбергу. Сопоставление представляется интересным, и я написал о нем статью 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 А вам, возможно, любопытно будет почитать.