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

https://youtu.be/8nI2STePwQQ

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

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

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

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