Виктор Редров и Илья Бушмелев из РТ Лабс. Как 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 и рекомендую книгу к прочтению! В ней — интерпретация Марком Спиральной динамики применительно к культурам организаций, основанная на его опыте. В книге теория обильно подкреплена историями из опыта, но вместе с тем соблюдается строгость и точность рассказа. Отмечу, что именно Марку принадлежит применение Спиральной динамики для организаций и описание культур Принадлежности, Силы, Правил, Успеха. Это было сделано задолго до выхода книги Фредерика Лалу, который также активно опирался на Спиральную динамику при построении своей классификации организаций.

За долгую практику работы в ИТ меня всегда удивляло внимание к требованиям, стремление к их тщательной проработке. Я лично предпочитал быстро переходить к моделям и работать с ними, рассматривая требования как промежуточный этап. Сейчас задумал статью с размышлениями на эту тему, но она получилась слишком большой, так что читайте пока первую часть https://habr.com/ru/company/custis/blog/703758/ Продолжение следует.

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

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

Статья https://habr.com/ru/company/custis/blog/705958/ Domain Driven Design: модели вместо требований продолжает тему работы с постановками, начатую статьей https://habr.com/ru/company/custis/blog/703758/ Какие нужны требования: развитие концепта. Здесь рассказывается альтернативный классическим требованиям подход, когда очень быстро переходят к моделям и именно они становятся предметом обсуждения с заказчиком.

Опубликовал очередную статью по самоопределению https://vc.ru/hr/573995 – о создании аватара, который пойдет в будущее. Публикация перед самым Новым годом, но, думаю, это будет востребовано – ведь длинные новогодние каникулы для многих – время подумать о планах на будущий год, А если нет – можно вернуться к этому позднее, а пока – праздновать. С наступающим Новым годом!

Вчера был на замечательном спектакле - Театр Глас, Горящие письма https://www.theatreglas.ru/repertoire/goryashhie-pisma/. Это - настоящее волшебство театра. Такими вещами стоит делиться, и я решил написать не только об этом спектакле, но и еще о нескольких прекрасных, которые видел в последнее время https://maksiq.livejournal.com/146206.html

Очередная статья по самоопределению https://vc.ru/hr/577856 рассказывает модель человека как команды аватаров-субличностей, играющих спектакль жизни на двух сценах: внешней в объективной реальности и на внутренней у себя в голове. Модель позволяет работать с внутренними конфликтами, и наглядно показывает, откуда появляется различие ожиданий даже у тесно взаимодействующих людей.

Каникулы позволили почитать статьи и доклады конференций, которые пропустил. Об одном из них я хочу рассказать. Фарит Хуснояров из VK на Enterprise Agile "Когда все сроки вышли, а результат нужен завтра". История про перестройку в этом году команды, которая делает vk messenger. Проблема в том, что он сильно отстал от других платформ. За прошлый год ни одна из фич не была доведена до релиза. При том, что команда из квалифицированных профи с хорошей мотивацией, люди любят vk и искренне хотят нанести пользу пользователям. Но не получается. И проблема - в организации работы. Кейс, на мой взгляд - характерный для многих инженерных команд, чем и интересен.

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

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

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

Организационно это было сделано через процедуру квартального планирования, PI planing из SAFe. Фарит раньше работал в РТ Лабс, которая делает госуслуги, там это начали активно применять, чтобы разгрести завал работы, спровоцированный ковидом. Главное что дает процедура - прозрачность планирования, это важно и для руководства и для заказчика, она дает представление что будет сделано и в какие сроки. На конференции был доклад РТ Лабс, где это рассказывали, отзыв у меня в конспекте есть. В целом команда против планирования не возражала, вопросы были в технической осуществимости.

А дальше нужна фокусировка на том, чтобы фичи были сделаны целиком, на всех платформах. Решение тут известное - фичи-тимы или мультиплатформенные команды. Фарит эти две конструкции различает, хотя я не очень понял разницу. У них на первую итерацию было сделано две мультиплатформенных команды, в каждую взяли по 2 разработчика из каждой платформы. При этом платформенные команды - остались, они дорабатывают механизмы ядра, если это нужно для фич, через них проходят новые сотрудники при онбординге. Отмечу, что в целом конструкция сложная, но известная и понятная. О ней, например, рассказывал Евгений Россинский из ivi на Teamlead-2018.

В первую итерацию каждая команда взяла по 1 фиче. Эксперимент признан удачным, сейчас вторая итерация, команд уже 4, они взяли 9 фич. Естественно, был вопрос про организацию работы такой команды - потому что люди пришли из разных команд, в каждой из которой была своя организация. Решили иcпользовать Scrum. Основное возражение - что это долго и требует обучения, но тут подключился ScrumTrek, все сделали быстро.

Еще одна проблема - мощность команды разработки. Когда роадмап сделали, то стало понятно, что нынешней мощностью телеграм нагонят к 2030 году, не раньше. Значит надо что-то делать и быстро. Но культура требовала отбора настоящих профессионалов, были тяжелые собеседования, и больше одного сотрудника в месяц - не приходило. Но и изменить культуру быстро не получалось, люди не были готовы работать с теми, кого не считают "настоящим профи". И тут был workaround - через аутсорсинг. Компании-аутсорсеры предложили лидов, которые прошли собеседование. И те уже под себя набирали команды, а взаимодействие все шло через квалифицированных людей. Таким образом получилось в короткое время добавить 5 команд, 20 человек. Которым отдали все мелочи и исправление багов. Взаимодействие тоже возложено на команды платформ.

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

Очередная статья по работе с требованиями https://habr.com/ru/company/custis/blog/709912/ посвящена тем методам, которые принес Agile. Ведь если мы признаем, что гарантировать успех проекта невозможно, а сами требования могут изменяться в процессе реализации, то тщательная проработка становится бесполезной тратой сил, необходимо работать по-другому, чем предлагал классический подход. При этом, в соответствии с Agile -манифестом, многие методы представляют собой фокусируются не на форме и содержании документов, а на способах эффективного проведения встреч, на которых требования проясняются.

Очередная статья по самоопределению https://vc.ru/hr/586589 – о моделях, которые позволяют понять, будет ли деятельность приносить драйв и энергию, и об управлении драйвом в своей работе.

Всем привет!

А вот и анонс: 31/01/23 в 19-30 по МСК состоятся чаепития с Максимом Цепковым.

Мероприятие - online (в googlemeet), запись (как всегда) будет на youtube.

Приходите, обещаем общение, беседу с Максом и возможность задать любые вопросы!

И, конечно, же не забудь кофе/чай и булочки!

До встречи во вторник!

ссылка на мит: https://meet.google.com/pio-eadv-fem

Во вторник 31/01 продут Аналитические чаепития (это канал такой есть) с моим участием, мы будем беседовать про модель для современной сервисной архитектуры с активными акторами. У меня об этом была серия докладов https://mtsepkov.org/ActorModel