Стерлюкин | 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