Статья 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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