Стерлюкин | IT

Организация команд по Team Topologies

При этом подходе есть 4 типа команд:
- stream aligned;
- platform;
- complicated subsystem;
- enabling.

Stream aligned

Отвечает за полный цикл доставки пользовательского инкремента. E2E команды.
Например:
- команда мобильного приложения;
- команда сайта;
- команда управления финансами компании.

Метрика успеха: скорость доставки фич, удовлетворённость клиентов.

Platform

Создаёт внутренние сервисы и инструменты для stream aligned команд. Представляет собой внутренние продукты с API.
Например платформенная команда может заниматься:
- предоставлением единого механизма сбора и визуализации метрик приложения;
- реализацией IDP - внутренней платформы разработки для того, чтобы разработчики stream aligned команд могли быстро создавать микросервисы по шаблонам, фокусируясь на бизнес-логике.

Метрика успеха: время на интеграцию продуктовых команд с платформенными инструментами. Удовлетворённость клиентов - только в качестве клиента для platform выступают члены stream aligned команд.

Complicated subsystem

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

Метрика успеха: простота интеграции для stream aligned команды.

Enabling

Помогает другим командам освоить подходы, технологии. Кратковременно работает с определённой командой - обучает её и переходит на другую команду.
Например:
- эксперты в DevOps;
- эксперты в ML;
- эксперты в построении командных процессов (scrum master, delivery manager).

Метрика успеха: обучаемая команда получила набор необходимых знаний и умений. И теперь в состоянии самостоятельно решать задачи, требующие этих умений.

Все типы команд взаимодействуют друг с другом тремя способами:
- collaboration;
- x-as-service;
- facilitation.

Collaboration

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

X-as-Service

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

Facilitation

Команда приходит и обучает другую команду. Обычно, таким образом Enabling команда помогает Stream aligned команде.
Это временный тип взаимодействия. Он должен быть чётко ограничен по времени.

#процессы

Подборка за январь

1) управление стейкхолдерами - как грейдировать, как взаимодействовать с каждым грейдом, чеклист по работе со стейкхолдерами

https://t.me/sterlyukin_it/176

2) raci-матрица - роли, чеклист по правилам ведения

https://t.me/sterlyukin_it/185

RACI-матрица

Это матрица распределения зон ответственности в команде. Кто, за что отвечает в проекте/процессе.

Роли:
- R - responsible - тот, кто делает работу. Ответственный за исполнение. Может быть несколько на одной задаче
- A - accountable - ответственный за результат. Принимает итоговое решение. Может быть только один на задаче
- C - consulted - консультант, с которым нужно советоваться до принятия решения
- I - informed - сотрудник, которого нужно информировать после решения.

Например, реализация фичи:
- R (ответственные за исполнение) - developer, QA, devops
- C (консультант) - представитель бизнеса
- A (ответственный за результат) - тимлид
- I (информируемый) - представитель команды, которая зависела от реализации этой фичи

Чеклист внедрения/правила использования:
- только один A (ответственный за результат) на задачу;
- не все роли обязательны. Например, в некоторых задачах может не быть C (консультант) и I (информируемый);
- A (ответственный за результат) может быть одновременно и R (ответственный за исполнение) на каких-то задачах;
- на задаче может быть одновременно несколько R (ответственный за исполнение);
- сокращайте количество C (консультантов, с которыми нужно советоваться до принятия решения) - это замедляет процесс принятия решений. Но важно соблюсти баланс и учесть все точки зрения и потребности.

#процессы

Шпаргалка по стейкхолдер менеджменту

Ссылка на полный пост - https://t.me/sterlyukin_it/176

Ссылка на канал про менеджмент в IT - https://t.me/sterlyukin_it

Управление стейкхолдерами

Любой проект, который ты делаешь - имеет заинтересованных лиц. По-другому, стейкхолдеры.

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

Стейкхолдеров необходимо оценить по двум направлениям:
- власть;
- заинтересованность.

В градации:
- низкая;
- высокая.

Например:
- руководитель работников (власть = высокая, заинтересованность = высокая)
Влияние близко к максимальному, а заинтересованность максимальна, т.к. его сотрудники будут ежедневно работать в этой системе.

- руководитель разработки (власть = высокая, заинтересованность = низкая)

Максимальная власть, но при этом средняя заинтересованность. Руководителю важно, чтобы продукт был надлежащего качества и удовлетворял потребностям бизнеса.

- руководитель технической поддержки (власть = низкая, заинтересованность = высокая)

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

Взаимодействие со стейкхолдерами строится исходя из таблицы заинтересованности

- высокая власть + высокая заинтересованность = постоянно взаимодействовать
- высокая власть + низкая заинтересованность = держать в курсе
- низкая власть + высокая заинтересованность = периодически информировать
- низкая власть + низкая заинтересованность = реагировать по запросам.

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

Высокая власть + низкая заинтересованность = держать в курсе
- периодические статусы - например, 1 раз в 2-3 недели;
- в отчётах - общий статус, без подробностей;
- отчётность по срокам;
- привлечение в случае наличия проблем.

Высокая заинтересованность + низкая власть = периодически информировать
- статусы 1 раз в месяц;
- рассылки, общее описание статусов.

Низкая заинтересованность + низкая власть = реагировать по запросам
- отвечать по тем вопросам, которые приходят.

Помимо постоянных коммуникаций - бывают срочные, тактика поведения также зависит от матрицы. Основные:
- риск срыва сроков - уведомить 2 группы - "высокая власть + высокая заинтересованность" и "высокая власть + низкая заинтересованность";
- завершение важной фичи - уведомить все группы, кроме "низкая власть + низкая заинтересованность";
- изменение приоритетов - уведомить группу "высокая власть + высокий интерес".

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

#процессы

Как называть сроки

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

Ответ - это займёт 1 год/1 месяц/1 неделю - плохой. Используй вилку в оценке и дай несколько вариантов.

Например:

- с текущим составом команды и приоритетами = 1 год;
- если дадите ещё одного бэкендера, 2 фронтендеров и оставите текущие приоритеты = 9 месяцев;
- если дадите ещё одного бэкендера и 2 фронтендеров, понизите приоритеты других работ и основным будет новый проект = 4 месяца;
- если дадите ещё одного бэкенда и 2 фронтендеров, сократите скоуп до X и понизите приоритеты других работ = 2 месяца.

Комбинаций может быть много. Главное - обозначить основные. Так вы сможете найти точку компромисса.

Итоговый вариант скорее всего будет представлять собой гибрид - дадим только 1 фронтендера, сократим скоуп на X/2, частично поменяем приоритеты и будем довольны сроком = 7 месяцев.

#soft_skills

Часть 2 - как грамотно распределить силы

В предыдущем посте я написал про основные ошибки обучающихся - ЗДЕСЬ.

Сейчас я расскажу, как грамотно распределить свои силы во время обучения. Это релевантно не только для IT, но и для любого процесса приобретения навыков.

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

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

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

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

Иначе ты рискуешь наткнуться на когнитивное искажение - когда тебе кажется, что ты ничего не сделал. Хотя ты просто не замечаешь объёма проделанной работы - ретроспектива позволяет нивелировать такие проблемы.

Чередуй способы обучения
Одна из причин отсутствия прогресса в тренажёрном зале - привычка мышц к определённому виду нагрузок. Смена тренировочного подхода или упражнений - лучший способ выхода из такого тупика. Тоже самое касается обучения - не позволяй мозгам зачахнуть и привыкнуть. Постоянно варьируй нагрузку.

Например, сначала час почитай книгу про system design, а потом час попиши свой пет проект или попрактикуй новый фреймворк, который ты недавно узнал.

Постоянно держи цель в голове
Это очень важно. Без цели ты будешь блуждать, растрачивая мотивацию. Если ты поставишь себе цель - ты будешь адаптировать свою жизнь на её достижение.

Обучение только ради обучения - не масштабируется.

Кстати, вот ЗДЕСЬ я подробнее писал про постановку целей на примере наших работодателей.

#карьера_и_деньги

Типичные ошибки обучающихся. Часть 1

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

В этой статье я расскажу про типичные ошибки при обучении. Я многократно сталкивался с ними при обучении учеников и их подготовке к офферам.

Отсутствие чёткой цели

У тебя всегда должна быть цель. Устроиться на 300к, пройти собеседование на senior-позицию, повыситься до тимлида. Без цели ты будешь вечно блуждать, т.к. у тебя не будет чёткого ориентира - куда нужно двигаться.

Цель должна быть описана по S.M.A.R.T. Вот тут я подробно рассказывал об этом - https://t.me/sterlyukin_it/156

Спойлер - цель “улучшить свои hard-skill’ы” не подойдёт. А вот “устроиться на senior должность с зарплатой 300 000 гросс до 1-го мая 2025 года” - подойдёт. Учиться просто ради процесса учёбы - не масштабируемый подход. Рано или поздно ты выгоришь и не захочешь продолжать. Если захочешь - моё почтение, но тогда этот пост явно не для тебя.

Отсутствие чёткого скоупа

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

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

Кстати, вот здесь я выкладывал пост с наиболее частыми вопросами про распределённые системы - https://t.me/sterlyukin_it/119

Постановка интенсивности выше постоянства и ожидание вдохновения

Ошибка возникает из-за “внезапных” приливов мотивации. Ты устал на своей текущей работе, зашёл в твиттер и прочитал про 300к/секунду, замотивировался. И вот в 12 часов ночи ты изучаешь преимущества микросервисной архитектуры, чтобы пройти собеседование в компанию мечты. Такого заряда мотивации хватает ещё примерно на неделю. Потом из-за хаотичного обучения мотивация падает и ты постепенно забрасываешь это дело ещё на полгода.

Лучше учиться 1 час в день, по сформулированному плану, чем 1 день 10 часов и потом неделю ничего не делать. Так у тебя будет формироваться привычка постоянно учиться и это будет входить в твою рутину, ты привыкнешь к постоянному умственному труду. Более того, ты сможешь перевести полученные знания в долгосрочную память и будешь лучше помнить всё, что изучаешь.

Для обучения используй технику помодоро. Не старайся за день выучить вообще всё. Периодически отдыхай и разгружай голову.

#карьера_и_деньги

Итоги февраля

1️⃣ основы redis. Всё, что спрашивают на собеседованиях про redis в формате карточек - https://t.me/sterlyukin_it/158

2️⃣ реакция на ошибки. Фреймворк, который помогает правильно реагировать на ошибки и извлекать из них пользу - https://t.me/sterlyukin_it/164

3️⃣ основы транзакций в реляционных БД. Всё, что спрашивают на собеседованиях про транзакции в реляционных БД в формате карточек - https://t.me/sterlyukin_it/165

Транзакции - основы, про которые спрашивают на собеседованиях.

Сохраняй и отправляй друзьям.

Подписывайся на канал про развитие в IT - t.me/sterlyukin_it

#бэкенд