#Teadmlead Максим Смирнов. Как рассказывать архитектурные диаграммы. Доклад из двух частей. Сначала пять затруднений, которые возникают при презентации архитектуры и способах их преодоления, а потом - о том, как сделать хороший рассказ. Вторая часть не следует из первой, она поверх нее.

Рассказывать на реальном сложно - погружение в контекст. Есть кейсы, на которых O'Reily проводит соревнования архитекторов, варианты выкладываются на github. Если не в курсе - гуглите, это интересно. И рассказ был на кейсе Sysops Squad: гигант электроники с продажами по всей стране. При покупке - абонентское обслуживание, при проблеме специалисты приезжают.

Пять затруднений
1. Пояснить запутанную диаграмму - в этом запутываешься сам и путаешь других
2. Неясно, что надо рассказывать
3. Риск потеряться в вариантах развития событий. Их много, люди не держат контекста
4. Сложно не утонуть в обсуждении деталей
5. Непонятно, как донести замысел архитектурного решения
Теперь про каждую.

Сложность. В примере большая c4 диаграмма, как водится с мелкими надписями. Подробно рассказать - невозможно, а перечисление типа "5 контейнеров, 8 очередей" - это не содержание!

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

Другая идея: смотреть на картину как на карту и поверх нее рассказывать, как развиваются события - просто показать последовательность как взаимодействуют компоненты. Я бы для этого тоже крупно заранее пронумеровал пунты такого взаимодействия.

Еще отмечу, что это - два разных рассказа, для разных целей и аудиторий, и надо понимать, что именно ты рассказываешь.

В алгоритмах и поведении есть развилки, а в историях - их нет. Use case решают это через основной и дополнительные ветви. И в рассказе тоже не нужно рассказывать все варианты. Расскажите основной. Я тут дополню, что часто кроме основного есть особенно интересные кейсы, обычно касающиеся того, с чем имеются или предполагаются трудности. А структура через use case еще и поможет при вопросах про детали: вы переключаетесь на дополнительную ветку, потом возвращаетесь.

Как донести замысел решения? Есть формат.
1. Цель: желаемый результат, целевое состояние в которое хотим понять
2. Что мешает достичь целевого результата просто - препятствия
3. Хитрость, ловкий прием чтобы преодолеть эти препятствия

Три подсказки.
1. Используйте шаблон ADR записи архитектурного решения
2. Обсуждайте альтернативные варианты. Их обязательно надо сформулировать и обсудить
3. Передайте эстафету решения вашим слушателям

Шаблон Y-statements
1. Контекст - для чего применимо архитектурное решения
2. Facing - для каких требований архитектура, что мешает просто взять и сделать
3. we decided - что решили
4. and neglected - от чего отказались
5. we achieve - что мы достигнем
6. accepting what - какую цену заплатим

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

Зачем обсуждать альтернативы? Тут пример домика: дешево и быстро, быстро и дорого, дорого и хорошо, слишком хорошо. Мы проектируем индивидуально, не вовлекая заказчика. И он далеко не всегда специалист. Но если мы предлагаем варианты - то получается пространство выбора. И критерии могут быть различны.

B конце презентации был канвас для рассказа, он опубликован на канале Максима @it_arch, посвященному архитектуре.

Доброе утро! Готовы ко второму дню Saint TeamLead Conf 2024? Будет не менее насыщенно!

☕ А пока мы предлагаем выпить чашечку ароматного кофе и полистать расписание

🖐️ Друзья, в 10:00 начинаются первые доклады второго дня Saint TeamLead Conf 2024:

🔹 «00 Зал Башня». Как не превратиться из хорошего программиста в плохого менеджера. Фёдор Борщёв (Школа Сильных Программистов)

Все траектории профессионального роста можно условно поделить на два вида — «хакеры» и «лидеры». Хакеры достигают результата своими руками. Лидеры достигают результата чужими руками. Кто что качает, и почему эти треки равнозначны?

🔹Зал «08 Шатер Голубой». Сергей Трегуб (Яндекс 360)

Нанять хорошего тимлида — это всегда непростая задача. Сергей предлагает по-новому взглянуть на этот вопрос. Поделится своим опытом, как они научились нанимать тимлидов. Будет интересно. Обязательно приду послушать.

🔹 «04 Зал Красный». Вынужденное развитие. Оптимизация команды с ростом пользователей. Алексей Шемонаев (Т-Банк)

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

🔹 «03 Зал Синий». Жизнь после онбординга: как «включать» сотрудников в компании в периоды изменений без потерь. Дарья Мулык (Независимый эксперт)

При приеме кандидат проверяется на наличие профессиональных знаний, которые потом не используются в полном объеме или остаются «нераспакованными». Дарья расскажет и даст рекомендации, как осуществить грамотное включение сотрудников в изменение процессов с помощью модели ситуационного лидерства.

МТС — одна из цифровых экосистем в России. В компании работает более 8000 сотрудников по 18 направлениям ИТ.

Приходите на стенд МТС, чтобы узнать больше о продуктах экосистемы (вы удивитесь, сколько их!) и о The Platform — комплексе сервисных, технологических и интеллектуальных платформ, систем безопасности и бизнес-решений. Он объединяет все сквозные ИТ-решения экосистемы.

А еще МТС активно поддерживает ИТ-сообщество, развивает True Tech - комьюнити для лидеров ИТ-отрасли и начинающих специалистов. Заглядывайте — расскажут.

Думаем, что не нужно указывать на схеме расположение стенда компании. Достаточно поднять взгляд вверх, чтобы увидеть его. Вас ждут :)

Реклама ПАО «МТС» erid: LjN8KYF4H

🖐️ В 11:20 стартуют следующие доклады и мастер-классы:

🔹 «00 Зал Башня». Как окунуться в новую предметную область и не утонуть. Юлия Лукина (Ozon)

Иногда мы боимся погружаться в незнакомую предметную область, будь то новый проект или смена работы (или даже профессии). Юлия предложит простой и понятный инструмент, который поможет преодолеть страх и достигнуть успеха в новом деле.

🔹 Зал «08 Шатер Голубой». Конвейер роста тимлидов. Александр Пряхин (Авито)

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

🔹 «04 Зал Красный». Функциональные тесты: развёртывание, интеграция в CI и сбор покрытия. Максим Вишневский (Циан)

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

🔹 «03 Зал Синий». Самообучающееся сообщество как альтернативный традиционным тренингам и воркшопам подход к развитию компетенций. Дарья Рымарева (Циан)

Какие плюшки можно получить, если скоординировать создание сообщества вокруг курса обучения для сотрудников команды? Как такой подход повысит эффективность обучения? Как всё это организовать у себя, и какие сложности вас ждут? Обо всём этом расскажет Дарья.

🔹 «06 Зал Зелёный». Мастер-класс. Как формулировать проблемы так, чтобы их решения приближали к цели (НЖЯ, ТОС). Александра Брызгалова (bryzgalova.ru)

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

🔹 Зал «07 Шатер Оранжевый». Мастер-класс. Маркер всевластья, практика визуальных встреч. Александр Зинченко (Яндекс 360)

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

🔹 Зал «09 Шатер Фиолетовый». Мастер-класс. Командные встречи: неизбежное зло или секрет вашей антихрупкости. Дарья Вьюнова (OTUS Онлайн-образование)

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

Как окунуться в новую предметную область и не утонуть? Руководитель проектов Ozon Tech Юлия Лукина составила чек-лист, с которым получится без лишнего стресса разобраться в новой сфере.

Не забудьте заглянуть на стенд Ozon Tech, чтобы познакомиться со спикерами и экспертами Ozon Tech. Сможете задать все вопросы и обменяться опытом.

А ещё ребята привезли онлайн и офлайн игры — идеально, чтобы отвлечься.

Реклама ООО «Озон Технологии» erid: LjN8KXaAq

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

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

Цели - фиксируем ожидания. Операционное ревью: есть цели и факт. И если есть невыполнение или риск невыполнения - должен сработать триггер и дать корректировку действий.

Были рассмотрены 5 задач.
1. Контролировать результативность и эффективность
2. Настраивать процессы чужими командами
3. Запускать команды чужими руками
4. Контролировать перформанс-менеджмент
5. Развивать старших инженеров.
Теперь о них по порядку.

1. Контролировать результативность и эффективность. Результативность - делать правильные вещи, эффективность - делать их правильно (быстро, качественно). Это - разное, следить надо за обоими.

Burndown. Результативность - поставка того, что выпускает. План-факт. А скорость - эффективность, производная от скорости. Одна из метрик - cycle time.

Если цель - запустить ипотечную анкету на мобильных платформах. Отставание 10 дней, один из эпиков заблокирован смежниками. Метод изменений: в начале квартала сверять планы свои со смежниками. Цель по cycle time может быть не достигнута по той же причине.

Тимлид докапывается до причин, а руководитель тимлидов смотрит на светофор. Есть еще несоклько метрик индексов: support ticket sla reaction, zero bug policy, crashes, LSR SLA

2. Настраиваем процессы чужими руками. Досталось легаси плохого качества, много пользователей обращались в поддержку. Обращения матчатся с багами, для каждого известно. Цель: привести HD count к целевому значению. И количество решенных тикетов от суппорта 10+. Дальше мониторили - и получилось успешно за пару кварталов. Потом вывели на мониторинг.

3. Запускать команды чужими руками. При запуске команды есть общее: процессы и практики соответствуют стандарту. Agile periodic table - чек лист. Начал печатать, класть на стол и помечать. Но не масштабируется.

В Авито есть модель зрелости Team maturity model. Опрос по соответствию. И дальше по каждому пункту светофорная модель. Тимлид видит детали у себя, а руководитель - сводку по командам и динамику. И раз есть метрика - мы можем ставить цели по движению по по модели.

4. Контролировать performance management. Тимлиды затягивают обратную связь сотрудникам. Особенно начинающие. И начал включать в операционное ревью мини-оценку сотрудника. При этом требовалось каждого оценить, обязательно хорошо-плохо. Бинарно, нормально объединено с хорошо, и это - сознательно. Потому что у начинающего тимлида нормально - это плохо, по которому он не хочет выдавать обратную связь. Если плохо - то причины и action plan. Это побуждает тимлида давать обратную связь.

5. Развивать старших инженеров. Стандартные планы не работают, нужны нестандартные challenge. Например challenge: реализовать платформу календарей и применить для разных платформ. Или повысить SLA.

Как часто? Есть быстродействие, регулирование и точность. Слишком часто - задергаем команду, слишком редко - не будем реагировать. Целеполагание - как целеполагание в организации, у них раз в квартал. А операционное ревью 10% - 1-2 недели (9 дней формально). На последней период операционного ревью есть выполнение целей. И мы можем воспользоваться для обратной связи. Но! Это не должно становиться KPI, это должно быть поддерживающей штукой.

Итак, построение системы управления
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают

В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.