Мышление.
* Цель мышления - вывод ответа, решение задач. Проверка гипотез. Этим занимается когнитивная система и в ней есть баги.
* Методы: Обобщение, Классификация, Абстракция.
* Виды: Предметно-действенное - до 3 лет. Наглядно-образное - может быть сложное, но очень сложно ложится на алгоритмизацию. Словесно-логическое или понятийное. Два полушария, фокусировка одного на наглядно-образном, другое на словесно-логическим.

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

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

Разговор с уточкой. Объясняешь другому - и наконец-то сам понимаешь.

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

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

Эффект Зейгарник. Заканчивайте на самом интересном месте.

Рекомендации
* учить язык каждый день 5-10 минут, читать по 5 страниц дважды каждый день
* магическое число 7+-2. Задача Эйнштейна, решить без бумаги - потому что надо держать много сущностей.
* Инженерные практики: цикломатическая сложность (7-9), количество реализуемых интерфейсов (5), количество методов до 9, глубина наследования до 5 - чтобы все это помещалось в голову.

Виды памяти - двигательная, образная, эмоциональная и так далее.
Рекомендация для запоминания - мелкая моторика, доски и маркеры, механическая клавиатура, беседа с уточкой, организация офиса (дартс, пинг-понг, турник, xbox). Виды внимания: непроизвольное, произвольное-волевое, послепроизвольное...

Follow ups - необходимость, иначе мысли размазываются и несфокусированные. Не только по встречам и созвонам, но и обсуждению с чатиками. Потому что когнитивные искажения, несосредоточенное внимание.

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

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

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

* Каждый шаг - деньги - нужно основание
* лучшее основание - валидные цифровые данные
* решение исполнено - надо оценить результат
* лучшее оценка исполнения - рост цифр
* Decision Execution Management - DXM - это очень дорого
* Минутки и заметки со встреч - DXM на минималках

Главное перестроение мышления: все что приходит в голову ему или продукту - это гипотеза. Поэтому не надо бросаться делать, надо остановиться и сказать: с чего бы это? Каждая гипотеза распадается на три: гипотеза проблемы (у пользователя есть проблема), гипотеза решения (решает проблему), гипотеза ценности (решение ценно пользователю, он готов платить). Много людей восторгаются продуктами и фичами, но платить за них не готовы.

В докладе фокус на гипотезе решения. Распадается на две: What (какую фичу реализуем) и How (как ее реализуем).
* What. Часто очевидные шаги, то что есть у конкурентов - не аргумент, большие рискованные шаги. Но быстро понятно, когда идете не туда.
* How - можно сделать по-разному, формально и просто, либо большой проработкой пользовательского опыта. Это влияет на имидж продукта. И они дают кумулятивный эффект. Аналитик тут может помогать и подсвечивать слепые зоны. У него mindset копать в детали даже простую фичу и из-за этого могут не попадать в сроки.

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

Контексты решений
* Активности продукта: поиск, проектирование, разработка и поставка, развитие
* Жизненный цикл разработки: анализ, дизайн, разработка, релиз, поставка, эксплуатация. И мониторинг
* Жизненный цикл продукта

SWOT-анализ и PESTEL. Делаются, но игнорируются, и потому делаются поверхностно. Когда наняли продукта, решение о стартапе принято. Хотя это была гипотеза, и ее стоит проверять. Но для этого от продукта нужна смелость. И надо копать в недостатки и Угрозы, Преимущества и Возможности Продукт прокапает сам.

Product Vision как артефакт. Нужно для решения о деньгах. Надо собрать основания. На слайде - конкретное содержание, 10 пунктов, включая Lean canvas.

CJM и USM.
* На действующем продукте строим CJM - продукт есть. И вокруг него USM, выделяя активности и провалы.
* На стадии стартапа наоборот, строим USM, и дальше на основе опросов пользователи конкурирующего продукта делаем CJM.

Основной источник фич - USM. Но дальше надо позиционировать фичи, с учетом реализации конкурентов, ожиданий пользователей, объемов реализации.

Гипотезы - HADI-циклы
* Очень плохо работает на старте, так как не видна разница между проверкой гипотезы и разработкой.
* Наиболее эффективно - на growth
* Плохо проверяет What, хорошо How

Roadmap. Когда напилили на фичи - декомпозировали по ролям и раскладываем. Product increment у них 6 спринтов. Но! На старте нет требований, нет понимания в деталях. Поэтому резервируем место. А далее попадаем в сроки через варьирование бантиков.

Сегментация аудитории - только тогда, когда понимаем состояние продукта, которое можем транслировать в рынок. Понятно, что гипотезы были. ABCX сегментации. Понимайте, что сегмент X может убить продукт. Не дай бог продукт вашего self-made стартапа захочет на ранней стадии купить госбанк, которому нужно ИБ и много другого - это угробит незрелый продукт.

Квадраты по определенности для продукта, стейкхолдера и клиента.

Сущности и скоуп продукта. Диаграмма классов - первое, что просит от аналитика. Оно хорошо обрисовывает скоуп продукта.

UX-концептинг 101. Берем сценарий, и описываем по шаблону

Бюджет, сроки, маркетинг. Режем скоуп, меняем позиционирование, ходим в рынок.

Продуктовая аналитика: экономические метрики и поведенческие метрики CJM - как пользователи реально ходят по продукту.

Презентация моего доклада выложена на моем сайте https://mtsepkov.org/DocStateTaskflow

Ирина Ремизова. Есть проблема? Нет проблем! Инструменты принятия решений. Доклад начался с выбора добровольцем из зала между яблоком и грушей, после которого вскрывалась дополнительная информация, которая, возможно, влияла на решение. И которая заставляла сожалеть о решении. Почему сложно принимать решения? Неопределенность, вариативность, влияние других людей, боязнь неверного решения.

Как можно уменьшить весь этот негатив за счет процедуры принятия решений? Есть рекомендации от Тони Робинса
* Всегда принимайте решения на бумаге. Когда прокурчиваем в голове - зацикливаемся,
* Надо ответить на вопрос: какая цель, что я хочу получить. Не руководство или семья, а именно сам.
* Учитывайте, что решение основано на вероятностях. Пришел в ресторан с целью что-то попробовать, а там этого сегодня нет - это не катастрофа и не стоит сильно расстраиваться, так бывает..
* Правило "решение - уточнение". Собираем факты и в моменте принимаем решение. Могут появиться новые факты - решение меняется, это нормально.

Как работать с проблемой? Есть много workflow, она делится своим.
* Определение проблемы или задачи без оценочных суждений, как цель.
* Массив возможных вариантов - все записываем на бумагу. Например, все варианты поездки в отпуск, даже если сходу отвергаем
* Оценка - вычеркните непригодное, от чего отказаться
* Выбор из оставшихся альтернатив (это дальше)
* Внедрение решения - сразу, не уходить вподбор и поиск новых вариантов. Нет аналитическому параличу.
* Анализ внедряемого решения и изменение в случае не обходимости

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

1. Квадрат Декарта. Каждое решение оцениваем с 4 сторон.
* Мотивация. Что будет, если сделаю.
* Не хочу терять. Что будет, если не сделаю
* Цена решения. Что НЕ будет, если сделаю.
* Что мешает. Что НЕ будет, если НЕ сделаю.
В каждом квадранте выписываем последствия - положительные и отрицательные. Там есть плюсы и минусы. Можно посчитать плюсы и минусы по каждому решению.

2. Дальше мы видим, что проскакивает общее для всех сотрудников: знание предметной области, загрузка сотрудников, компетенция документирования, компетенция сбора требований и так далее. Значит это можно считать критериями выбора - и сделать матрицу принятия решений. Ставим весы критериев, или баллы, или произведение. Используем матрицу только когда решения сопоставимы. Если вы выбираете между теплым морем и горными лыжами, то там мы выбор сделаем просто поставив вес.

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

Схема рабочая, она применяла ее на решении о переходе на роль куратора из системных аналитиков с помощью инструментов. Было 4 варианта, принимала решение неделю. И тогда реально не знала решение. Это - не подгонка обоснования под заранее придуманное решение. Хотя понятно, что в таком режиме тоже можно: поиграла весами - и получило нужный результат. Но это при любом методе можно. Есть и другие инструменты - диаграммы Парето, диаграммы Исикавы и так далее. Их тоже можно применять.

Алексей Зуев. Чайка-анализ. Колесо баланса и BACCM для сил добра. В докладе два метода: (1) рисуем колесо баланса жизни или работы и (2) применяем модель базовых бизнес-понятий BACCM для принятия личных решений. Кажется, что это интересно, но способ принятия решений до конца не проявлен. Может быть потому, что это был блиц, и просто не успел раскрыть. Если кратко изложить то, что я понял, будет следующее. Модель выявления бизнес-понятий при применении к личным ситуациям позволяет выявить ценности и факторы, которые важны именно для тебя в какой-то области, например, касающихся ведения проектов. И дальше построить в Excel матрицу оценки, применить ее для прошлых проектов и для будущих. Разглядывание матрицы может позволить увидеть корреляцию и сделать кластеризаци.

Например, оценивая свои проекты, он так выяснил четыре типа: чайки, прингвины, тупики и альбатросы. И построил колесо профессионального баланса, а также смог сформулировать ожидания от новых проектов. И это не просто выбор, это как раз типология проектов, которая позволяет ориентироваться на будущее. Алексей применял этот метод не только к проектам, но и к решению о возможном переезде. И вот здесь модель базовых бизнес-понятий BACCM помогла ему выявить ценность "доехать до родителей за три часа", которое неожиданно подсветило вопрос переезда, а при обычных рассуждениях - не проявлялось. В общем, надо будет еще посмотреть на слайды детально. Да, про название. Почему это чайка-анализ я так и не понял. На входе был тезис, что это не про чайка-менеджмент, а ассоциировано с Чайкой по имени Джонатан Лингвистон Ричарда Баха, но деталей я не понял. Может, потому, что давно читал книгу.

Анастасия Прохорова из Райффайзенбанк. Event happens. Переход на Event Driven архитектуру глазами аналитика. Рассказ на простом примере "Хочу пиццу", по которому надо принять оплату, приготовить пиццу и ее доставить. В сервисной архитектуре это отдельные сервисы, которым надо дать команды: Прими оплату, Приготовь, Привези. Но Потребитель не хочет управлять, он хочет сказать "Хочу пиццу" и все. Это одно событие, на которые должны среагировать все сервисы.

Из чего делать событие?
* Разбор процесса от начала и до конца. Для Запрос-ответ мы можем взять кусочек и окружение. А тут надо найти начало, конец и всю цепочку.
* Выделение шагов-задач, необходимых для достижения цели.
* Поиск объектов, участвующих в процессе. Например, Заказ пицц. И изменение состояние объектов связан с процессом.
* Определение зависимостей. Когда повар должен начать готовить пиццу? Когда заказ становится оплаченным.
Важно мыслить не отдельными функциями, а целиком процессом.

Как вести документацию? По стримам разработки - им соответствуют процессы от начала и до конца.
* Бизнес: цели и гипотезы, не требования
* Объекты: жизненный цикл и событийный ряд
* Архитектура: схемы и зависимости
* State machine diagram и sequence diagram
* Документация - не со стороны отправителя, а со стороны получателя, их цели. Страничек - много, но они маленькие.

Как организовать события? Персонаж хочет пиццу. У разных подписчиков - разные вопросы по этому поводу.
* Notification: событие только сообщает про изменении объекта, а дальше потребитель спрашивает что ему нужно. Можно пакетировать - несколько изменений. Нагрузка на источник - повышенная.
* Event-carried state transfer - передача атрибутов в событии. В расчете на то, что их будет достаточно для всех подписчиков.

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

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

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

Event storming. Коллаборация бизнес-пользователей и ИТ по исследованию области бизнеса. И помимо разбора бизнес и ИТ вырабатывают общий язык. Там выделяют Событие, Команда, Правило, Агрегат. Начинают с события - что произошло? Дальше команды как реакция на события и агрегаты, с которыми работаем. И в конце - выделяем ограниченные контексты.

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

Ирина Гертовская. Не башня из слоновой кости, а руководство к действию (о профстандарте системного аналитика). Минтруда регулярно обновляет профессиональные стандарты. Для них это - средство поставить задачу ВУЗам по подготовке специалистов. И они стараются собрать хорошую рабочую группу для этого по мере возможности. А рабочая группа обычно состоит из людей, которые видят в стандерте не только средство поставить задачу для подготовки специалистов ВУЗами, но и нанести пользу через прояснение содержание работ и квалификации, связанных с профессией. И учесть интересы обобщенных стейкхолеров: руководителей и заказчиков, проджект-менеджеров и тимлидов, самих аналитиков, в докладе эти интересы были обозначены. У меня лично скепсис по поводу такого влияния стандарта на отрасль, но это уже отдельная тема для обсуждения.

Предыдущий стандарт системного аналитика делала группа под руководством Дениса Бескова в 2014, а новый - группа под руководством Сергея Нужненко, в которой около 140 человек и 40 экспертов. Организует ВНИИ Труда. Ирина в этом активно участвовала, а в докладе - рассказывала об изменениях в стандарте. Основное - изменили содержание работы аналитика, вместо формулировки "Содержание работ: разработки требований" стала формулировка "Миссия: координация на уровне проектных решений". То есть меняется разделение труда. Такое изменение - не их произвол, оно проявлено в индустрии, например, это видно по изменениям требований к позиции на HH. При этом написано разграничение со смежным ролями: бизнес-аналитик проектирует организацию; системный выявляет рамки автоматизации, собирает требования, включая атрибуты качества и проектирует; архитектор создает конструкцию, реализующая атрибуты качества и детальные требования; есть границы с техническим писателем, разработчиком, тестировщиком. Правда, открытый вопрос - отражено ли это изменение в смежных профессиональных стандартах?

Содержание работы системного аналитика определено через трудовую функцию, включающую трудовые действия, необходимые умения и необходимые знания. По сравнению с предыдущим стандартом добавлена защита информации, интеграция и API, распределенные системы - в 2014 это было сильно менее актуально. А также навыки программирования. Доработан и уточнен глоссарий. Уровни квалификации: младший - работа с требованиями, средний - разработка техпроекта, старший - концепция ТЗ и ведущий - управление группой. При этом после среднего уровня - развилка, а не линейное развитие: руководить группой можно без навыков старшего аналитика. Но я подозреваю, что на практике эту развилку не воспримут. По уровням расписаны не только профессиональные компетенции, но и ответственность, работа с неопределенностью и другие, в презентации были примеры. Интересно, насколько это соотносится с аналогичными уровнями в других профессиональных стандартах. На мой взгляд, тут интересен опыт британского стандарта SFIA, где семь уровней определены сквозным образом для всех специализация с точки зрения ответственности, самостоятельности и ряда других характеристик, при этом некоторые специализации заканчиваются на 4-5 уровне, в то время как другие, руководящие - начинаются с 3-4 или выше.

Стандарт находится в стадии предчистовика, идет окончательное согласование и утверждение в Минтруда, и он доступен в интернете - в презентации были ссылки, и можно будет посмотреть - презентации скоро выложат. Быстрым поиском в официальных материалах я нашел только реестр пересматриваемых профстандартов, но не их проекты.

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

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

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

Андрей Бураков. Брокеры сообщений. Основы использования в интеграционных задачах. Основное в докладе следующее: гарантированная однократная доставка сообщения (exactly once) в природе не встречается, брокеры или теряют сообщения (at most once) или могут их дублировать (at least once), в том числе дубль может получить другой экземпляр сервиса-получателя, дублирование будет, если проблемы возникли с передачей квитанции после обработки. И вам надо проектировать системы, устойчивые к возникающим при этом проблемы. Вы не можете от проблем избавиться, но можете выбрать, с чем именно будете разбираться. Как разбираться - тоже немного было. Например, идемпотентная обработка обладает устойчивостью к дублированию. А регулярная отправка, например, биржевых курсов - устойчива к потерям.

Поведение может быть заложено в архитектуру брокера, или управляться настройками для конкретной очереди или подписки. При этом классическая подписка со многими получателями работает как at least once, а в Kafka мы имеем подписку, в которой политикой смещения счетчика (at most once или at least once) вроде может управляться для каждого получателя.

Собрал свои заметки с #AnalystDays в отчет и дополнил несколькими темами, которые всплыли в обсуждениях в кулуарах, но, мне кажется, будут интересны и за рамками частного разговора https://mtsepkov.org/AnalystDays-2022c Хорошего чтения на выходных! Спасибо организаторам!

Анатолий Левенчук недавно написал два важных и интересных поста, на которые я хочу обратить внимание. Первый https://ailev.livejournal.com/1656653.html - фундаментальное изложение онтологии системного подхода, опираясь на работы современных авторов, со ссылками уровня научной публикации. Там много интересного и глубокого. В частности - мир абстрактных объектов и мир физических объектов, и физические вычислители, компьютеры и люди, которые работают с обоими мирами, создавая новые абстрактные объекты или воплощая их в физическом мире, при этом управляются они во многом как раз абстрактными объектами. Такой дуализм Декарта в современном виде и, естественно, без всяких ссылок на него, это все - современные авторы. И там много еще чего интересного, пересказывать я не буду, это надо вдумчиво читать.

Второй пост https://ailev.livejournal.com/1654601.html включает тему "А чо таково?" - как разбираться с тем, что люди всерьез воспринимают всякую хрень, считая ее равноправной с научными теориями, при этом указания на противоречия на них не действуют, они не считают это основанием для отказа от теорий. Это интересный вопрос, имея ввиду не только астрологию и аналогичную эзотерику, но и имеет практический смысл в современной геополитике и этике - вопрос об основаниях для рассуждений и действий.

Я исторически читаю Анатолия в livejournal, мне там удобнее, но он публикует и обсуждает посты в FB и телеграм, там есть ссылки, так что кому удобны другие площадки - можно читать там.

Конференция Enterprise Agile Russia - истории Agile в крупных корпорациях. Первый доклад Евгения Меньшикова из ВТБ. Журавль в руке: опыт трансформации процессов производства ПО. Вид сверху на трансформацию ВТБ за последние три года с 2019, за которое ИТ увеличилось с 3 до 20 тысяч человек, при этом они сильно ускорились, перейдя от 4 релизов в год с ТТМ 9 месяцев к непрерывной поставки софта и ТТМ около месяца. Для перехода к непрерывной поставки пришлось существенно изменить ИТ-ландшафт: легаси-системы, которые были на входе для этого не пригодны. У трансформации было несколько особенностей:
* Цели - бизнесовые, были поставлены перед банком в 2019 в 1.5 раза розницы, вдвое средний и мелкий бизнес при росте дохода на 15-35% при этом сохранить сегмент крупного бизнеса.
* Команда была уверена, что ключ успеха - в Agile-методах. При этом в банке Agile был дискредитирован предыдущим опытом, били пилоты, которым не удалось взлететь. Поэтому фокус был на бизнес-целях, не на методах.
* Трансформация по площади и на всех уровнях - потому что этап островов уже проходили. При этом идти этапами по полгода, с конкретными целями на каждый этап, и сначала - расшатывание ситуации.
* Принципы, о которых договорились: фокус на создании ценности - поддержке бизнеса; совместная работа; инкрементальность; измеряемость; универсальность; надежность автоматизиции и инфобезопасность.
* Смешанная структура программ и проектов с продуктовыми стримами. Синхронные изменения многими участниками, и синхронизация. На некоторые стримы - 3-4 программы, развитие продукта + технологические изменения и т.п. Стримы вокруг продуктов их удерживают.
* На входе была разобщенность ИТ и бизнеса. Поэтому вместо принципа единственного product owner - правило двух ключей: ИТ + бизнеса. Проследили консенсус, и пропорции в целеполагании: 50-70 бизнес, 30-50 технологические.
* Надо менять не только change, но и run, и единая модель управления для обоих, единый такт работы. По факту run всегда на такт позже, но все равно вместе, вовлечение стримов сопровождения с первого планирования.
* Как вовлекаем? Постоянное общение. Townhall - сотрудники говорят с менеджерами, не в варианте "начальники решили - я делаю". Линия поддержки, включая методологию изменений, регулярные обучающие сессии. Гильдии, сначала SM, потом на остальное. Телега и развлекательно-информационный контент. Активности по рассказу.
* Прозрачность. 3d-мониторинг viewpoint: программа, архитектура, стрим, команда. Все дашборды доступны всем.
* Метрику NPS сотрудников - не вводили, пациента на хирургическом столе глупо спрашивать, доволен ли он, и ориентироваться на его мнение проводя операцию. Но все время спрашивали "что не так", и эту обратную связь обрабатывают.
Команда трансформации: начинали в 2019 15 человек, и команда по методологии продолжает оставаться небольшой. А команда внутренней автоматизации, инженерные практики, мониторинг - около 400.

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

А если говорить про детали, то доклад был посвящен устройству процесса планирования на 100+ команд и 2000 сотрудников, при этом между отдельными сервисами в продукте - сильные связи. Это трехдневная сессия, в которой очно участвует 400 человек от компании и Минцифры, и еще 1000 участвует online. Стандартный формат PI SAFe дополнен тактом согласования квартальных планов с министром и заместителями, которое начинается после получения финальных презентаций в 16 часов строго дня и идет вечер второго и третий день. В докладе и презентации этот процесс показан очень детально, с этапами, промежуточными точками и контрольными вопросами по ним. Презентации уже доступны в программе конференции, так что можно смотреть. Что важно, результат планирования - это не просто набор фич у каждой команды, формируются цели и ключевые результаты, в соответствии с подходом OKR и привязка к ним реализуемых фич. Для технической поддержки сделано решение, которое позволяет формировать презентации на основе задач в Jira.

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

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

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

Этапы жизни гильдии, начинается с запуска.
* Желание сотрудника запустить гильдию. У кого инициатива - пишет. Вопрос - насколько кросскомандная.
* Появляется лидер гильдии - еще до запуска. HR помогают найти экспертов в командах - получается рабочая группа.
* Проводят общую встречу, гильдия появляется.
* Этап строительства. У каждой гильдии есть чек-лист: цели, правила, площадки коммуникации, идентичность, матрица компетенций...
* Этап полета. Регулярные встречи - раз в 1-2 недели
Есть коммюнити лидеров гильдий - для обмена оптом и помощи. Каждая гильдия берет практики, которые важны в моменте. Плюс общее позиционирование гильдий и встраивание в общие HR-процессы.

У гильдий - свои метрики. Есть общие - по долям участников. И Чувство сообщества - оценка, насколько участники оценивают соответствие идеальной картине.

Было три кейса, что может пойти не так.
* Быстро выполнили цель гильдии - что делать? Расширение спектра тем и увеличение числа участников
* Участников много, а активности мало. DevOps - почти все могут вступить. Но при этом оказалось, что devops-инженеры не чувствуют ценности. Ту гильдию оставили, но devops стали 2.0
* Новостная повестка может повлиять на развитие гильдии. Сотрудники могут оказаться слишком занятыми, либо смениться моральное состояние. И в эти моменты надо сделать паузу, а потом вернуться и продолжить идти. Остаются точки оперативной синхронизации статуса. Паузы были с конца феврале до начала июня, и замедление в октябре (слабее - только моральное состояние, а не занятость).

Что сделано? Описание методологии, на новый уровень вышел обмен знаниями и внутренние обучающие курсы - там прикладные конкретные вещи. Вместо бесконечных Excel создания компетенций появился свой инструмент. Есть общее информирование, задача Анны - сделать, чтобы лиды отпускали людей. Гильдии сами определяют правила вступления, и в некоторые, например, девопс - есть входной барьер по профессии или нужна рекомендация.

Евгения Хосейни. Продуктовая экосистема или как получилось строить самолет, летая на нём. Компания разрабатывает решения для видеонаблюдения. И на входе комплексные решения собирали партнеры, которые предлагали заказчикам комплексное решение. Они приходили с запросами на доработки - шло несколько тактов уточнений без прямого контакта с клиентом, в результате вместо 2 месяцев делали за 9 и даже если получалось нужное - это оказывалось специализированное решение под 1-2 клиентов, которое потом надо было сопровождать. Эту ситуацию принципиально изменили, создав отраслевые команды, ориентированные группы клиентов, которые напрямую взаимодействуют, собирают потребности клиентов, делают отраслевую экоситему и пилотируют на небольшой группе клиентов.

Если подробнее, что поменяли
* Сквозные процессы. Экосистема - она из нескольких продуктов, продуктовый хаб. Внутри делание по сегментам.
* Отраслевая команда: Менеджер сегмента + Продукт, который тащит сгенеренные продукты + Исследователь трендов.
* Выделение сегмента рынка - целевые клиенты, их потребности, что удовлетворяем, а что нет. Дальше продавцы по целевым клиентам.
* Отраслевой бизнес-аналитик - отдельная позиция, дало неожиданный результат. Интегрирован в отраслевую команду, и выясняет у целевых клиентов реальные потребности. И собирает задачку внутри команд разработки, она расползается по стримам.
* Целеполагание. Цели на год в деньгах по каналам. Идеи, гипотезы продуктовые, околопродуктовые, непродуктовые. И дальше на квартал получаются задачи по формированию гипотез под идеи, цели в продуктовых и непродуктовых метриках и так далее.

Ошибки
* Избыточная сложность и длительность согласования на этапе разработки, даже для небольших фич - сделали простой процесс
* У них была переоценка собственной продуктовой экспертизы, клиенты используют продукты для других целей и не так как задумывалось - и это надо исследовать
* 100% план на недоукомплектованную команду - не работает, его не выполняют, и надо учитывать реальную комплектацию при планировании
* Не провели аудит инструментов анализа данных - не видели как бежим сразу
* Не зафиксировали метрики рентабельности целевой системы
* Не зафиксировали метрики здоровья

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

Конференция Enterprise Agile была очень динамичной, поэтому публиковать заметки у меня получилось только по части докладов. Компенсирую это, выкладывая отчет по горячим следам https://mtsepkov.org/AgileEnterprise-2022, дополнив его общими впечатлениями. И я хочу обратить внимание: эта конференция не про то, как используются Agile-методы в ИТ-разработке, хотя такие доклады были. Она о том, как с помощью Agile-методов организовывать деятельность крупной корпорации или банка, где работают тысячи сотрудников. Или изменять ее, координируя несколько десятков программ, в которые так же вовлечены тысячи человек. И это - интересно.

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

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

В общем, жаль, что вопросы инженерной культуры сводятся к наборам правил.

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

#Highload Слушая выступление Александра Зиза по мышлению и реплики слушателей, зафиксировал интересный конфликт школ. Есть школа СМД-методологии, которая говорит, что мышление возникает в ситуации, когда у вас есть проблема, с которой надо что-то делать, а вы не знаете, что именно. И есть школа нейрофизиологии, которая говорит что в стрессе блокируется поступление дофамина (и еще каких-то важных веществ) в кору головного мозга, что выключает возможность сложного мышления, остаются только типовые реакции. понятно, что противоречие не фатально, ты просто должен сначала И специально говорят о том, что сначала надо выйти из стресса, уже потом запускать мышление. Но при этом, получается, выйти из стресса надо, сохранив представление о проблемности ситуации - иначе мышления не будет.

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

На прошедшей Highload у меня практически не получалось публиковать заметки с докладов. Но у мсебя на ноуте я их делал, и сейчас собрал отчет и опубликовал https://mtsepkov.org/Highload-2022b. В отчете не только Highload, но и DevRelConf, которая была сразу после Highload.

Прочитал книгу Марка Розина «Восхождение по спирали», публикую свои заметки https://mtsepkov.org/RozinClimbSD и рекомендую книгу к прочтению! В ней — интерпретация Марком Спиральной динамики применительно к культурам организаций, основанная на его опыте. В книге теория обильно подкреплена историями из опыта, но вместе с тем соблюдается строгость и точность рассказа. Отмечу, что именно Марку принадлежит применение Спиральной динамики для организаций и описание культур Принадлежности, Силы, Правил, Успеха. Это было сделано задолго до выхода книги Фредерика Лалу, который также активно опирался на Спиральную динамику при построении своей классификации организаций.