Когда RACI матрица может быть полезной

RACI матрица – удобный инструмент для того, чтобы в явном виде распределить роли и уровни ответственности группы людей. Как и у любого другого инструмента, область применения его довольно ограничена. Например, использовать его в плотно сыгранной команде, работающей над общей целью, будет даже вредно.

В статье перечисляются кейсы, когда RACI может быть оправдана. Несколько примеров:

*️⃣Речь идет не о команде, а о временной рабочей группе
*️⃣В команде происходит регулярная ротация ее участников
*️⃣Работа над большим проектом с кучей зависимостей и ограничений
*️⃣Сложности в коммуникациях
*️⃣Разные руководители тащат группу в разные стороны и требуют разного

Во всех этих случаях RACI – просто подорожник, который не исправляет корневую проблему, а помогает временно полечить симптомы. Если вы хотите исправить проблему в долгую, к ней надо подходить по другому.

Новый сезон Podlodka Teamlead Crew

Моя любимая конференция для тимлидов (а как же иначе, ведь я ее организую) проводится вот уже в десятый раз! В новом сезоне решили отойти от привычной концепции “одна неделя – одна тема", и попробовать собрать сборную солянку полезных докладов, которые будут рассказывать самые звездные спикеры.

👨‍👩‍👧‍👦Виталий Шароватов разберет, что такое настоящая командная работа, и почему тимлиду нельзя фокусироваться на индивидах
😔Евгений Антонов закопается в механизмы работы демотивации, ее причины и последствия
💪Настя Абрашитова научит методам влияния на людей, которые не находятся у вас в формальном подчинении

А кроме них выступят Евгений Кот, Глеб Михеев, Стас Цыганов, Никита Дубко и другие крутые ребята, докладами и статьями которых я тут регулярно делюсь.

📆Даты конференции: 10-14 апреля
👉Регистрация

Вопросы, которые надо задать себе, когда вас раздражает ваша команда

🤔Достаточно ли явно я объяснил ожидаемый результат работы?
🤔Насколько оправданы мои ожидания от команды, соотносятся ли они с доступными им ресурсами?
🤔Знаю ли я, что именно могло вызвать проблемы у конкретного сотрудника?
🤔Не скатился ли я в микроменеджмент?
🤔Одинаково ли я отношусь ко всем в команде?
🤔Даю ли я честную, ясную и actionable обратную связь?

Переговоры об оффере со стороны нанимающего менеджера

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

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

📆Дата: 30 марта, 20:00
👉Регистрация

Обещание как проект

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

Как управлять командой крутых сеньоров

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

Поделитесь в комментариях, как руководителю правильно построить работу с такой командой и определить систему принятия решений!

А если вы уже очень уверены в своем ответе, пройдите тест от SETTERS EDUCATION по мотивам курса «Как управлять командой и собой». В нем можно разобрать четыре сложных кейса, оценить свою способность принимать сложные управленческие решения и получить ништяки.

Результаты нашего исследования руководителей разработки

Ура, мы наконец-то закончили подбивать результаты исследования и оформлять красивую инфографику! В опросе приняло участие 570 человек, из которых:
- 68% – линейные руководители
- 22% – менеджеры менеджеров
- 9% – директора

Держите подборку интересных фактов из исследования, которое мы провели вместе с AvitoTech:

🤔90% руководителей перешли в менеджмент в той же компании, где работали инженерами.
🌟Топ-3 обязанности руководителей любого уровня: собеседования, развитие людей в команде и оценка их перфоманса.
💪80% тимлидов считают себя сильнее большинства инженеров в своей команде.
💻Половина руководителей пишет код или занимается другой инженерной работой. Большинство занимается этим в пределах трети своего времени.
👀Активно ищет работу только каждый десятый тимлид.

В полном отчете куча графиков, ссылок на полезные каналы, курсы и книги. Читайте сами, шарьте своим коллегам, выкладывайте скриншоты в Твиттер!

Видеообзор исследования тимлидов

Пару недель назад я писал, что подумываю завести блог на YouTube. Так вот, оно наконец-то произошло! Я решил начать с простого, и записал короткий видеообзор интересных фактов из исследования. Заходите, смотрите (обязательно до конца, чтобы алгоритмы обучились), и подписывайтесь на канал! Очень постараюсь в ближайшие пару недель записать что-нибудь еще.

Несколько советов по онбордингу в проект

📖Начните с бэкграунда. Расскажите, как появилась ваша команда, какую проблему решает проект.
➡️Объясняйте архитектуру не по компонентам системы, а по user journey. Сторителлинг поможет выстроить в голове у человека связную картинку того, что и зачем происходит в проекте.
🎨Нарисуйте простую схему взаимодействия ваших компонентов друг с другом. Она очень упростит объяснения и ее можно будет переиспользовать и в будущем.

Зачем командам нужны тимлиды, и можно ли обойтись без них

6 апреля на YouTube Подлодки пройдет батл, в рамках которого будут разбираться, насколько различным командам нужны тимлиды, в чем состоят их главные обязанности, и возможны ли полностью автономные команды. Спикеров специально подобрали с полярными взглядами и бэкграундом: Алексей Шаграев, Барух Садогурский, Влад Козуля, Георгий Могелашвили.

Подключайтесь к трансляции, подливайте масла в огонь, разжигайте холивар и делитесь своим опытом и кейсами!

📆Дата: 6 апреля, 19:00 по Москве

Тимлид как щит для команды

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

Автор статьи предлагает ограничивать функции щита в общем виде до следующего:

✋Не давать внешним для команды людям самостоятельно ставить задачи на ваших сотрудников.
🤔Решения, связанные с жизненным циклом сотрудников, не должны приниматься без вашего прямого участия.
💬Вы должны вовлекаться в решение конфликтов и настройку коммуникаций.

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

Новость для системных аналитиков!
Тинькофф ищет опытных специалистов, чтобы создавать лучшие финтех-решения на рынке. Спойлер: задачи сложные, но интересные. Посмотреть и откликнуться можно тут: https://v.tinkoff.ru/prof_sa

Архитекторы – это антипаттерн

Замечательная разжигающая статья. Если вам лень читать, вот основные аргументы:

😷 У архитекторов нет шкуры в игре. Они принимают решения, а реализуют за них другие люди. Они не обучаются на последствиях решений.
😞 Если в явном виде назвать кого-то ответственным за архитектуру, остальные инженеры станут уделять ей меньше внимания, и как результат мы получим более слабых разработчиков и хуже спроектированные системы.
😡 Так как архитекторы удалены от настоящей разработки, они могут не понимать всего контекста и сравнительную важность существующих проблем. Как результат – они могут тормозить прогресс, а не двигать его.
👴 Скилы архитекторов могут быстро устаревать, потому что, опять же, они перестают писать код каждый день, считая это менее важной задачей.

А вот что автор предлагает делать, чтобы проблема горела не так ярко:

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

Научпоп конференция от Wildberries

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

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

📆Дата: 7 апреля
🗺️Место: Москва, Технопарк “Сколково”, вход свободный по регистрации

Скрытая стоимость архитектурной сложности

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

🐞Разница в плотности дефектов в проектах с высокой архитектурной сложностью и с низкой составляет целых три раза.
💪Производительность разработки падает на 50%.
👋Вероятность текучки в проектах с неоправданно сложной архитектурой повышается в 10 раз.

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

Как определить, стоит ли инженеру расти в тимлида

Про золотой стандарт нашей индустрии в виде «подойти к самому сильному разработчику в команде, похлопать по плечу и назвать новым руководителем» знают все – кто-то прошел через него сам, кто-то смотрел сбоку, а у кого-то был как раз такой руководитель. В статье разбирается более разумный способ определения, готов ли разработчик расти в тимлиды. Если не вдаваться в детали, то автор советует такой алгоритм:

1️⃣Посмотреть, умеет ли кандидат строить процессы, потому что в этом и будет заключаться большая часть его работы.
2️⃣Посмотреть, что у него с мотивацией людей – есть ли шанс, что он сможет повести людей за собой, и насколько велик риск, что команда с ним распадется.
3️⃣Оценить, насколько сам человек готов переключиться с инженерной работой на руководство.
4️⃣Делает ли он уже сам какие-то шаги в сторону менеджерской работы – берет на себя ответственность за крупные проекты, что-то читает по теме.
5️⃣Насколько он вникает в суть того, что и зачем делает. Действует ли строго в рамках выданной задачи, или ориентирован на результат.
6️⃣Насколько он открыт и конструктивно говорит о проблемах.

У меня алгоритм вопросов не вызвал, и показался довольно разумным. Отдельно хочу отметить четвертый пункт – я всегда топил за то, что плохая идея назначать тимлидом того, кто уже не начал вести себя, как тимлид.

Согласно отчету McKinsey, автоматизация HR-процессов в найме, сокращает время на подбор сотрудников на 40%, а автоматизация обучения и развития, повышает эффективность обучения на 50%.

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

Обсудят 13 апреля в 18:00 на онлайн-встрече с OTUS, где разберутся в преимуществах для бизнеса от автоматизации HR-процессов и насколько они существенны для его развития.

В рамках встречи вы узнаете, как:
– Оценивать уровень автоматизации HR процессов в компании
– Формировать требования при внедрении новых HR решений
– Подбирать метрики и процессные KPI для каждого этапа жизненного цикла сотрудника
– Идентифицировать, какие риски стоит учитывать при автоматизации HR и разработке HR аналитики

👉Регистрируйтесь https://otus.pw/yuhw/ и приглашайте коллег!

Реклама. Информация о рекламодателе на сайте otus.ru

Подборка рекомендованных книг из недавнего исследования тимлидов

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

Так вот, это оказалось идеальным кейсом применения ChatGPT:

✍️Сначала я попросил выделить названия существующих книг и их авторов из сырых ответов.
🇬🇧Затем – использовать оригинальные англоязычные названия.
🔗А в финале – обогатить список ссылками на Amazon на все книги (для скептиков – в промпте просил не вставлять ссылку, если LLM не уверена в ней).

В итоге вместо нескольких часов ужасно скучной рутинной работы потратил 10 минут времени, из которых большую часть ждал обработки результатов.

А сам список книг классный, разбирайте!

Polyglot – автоматическая локализация приложений

Локализацию в приложениях часто делают по остаточному принципу. Основная причина, конечно – количество времени, требуемого на то, чтобы перевести все строки и поддерживать их актуальными при последующих релизах. Ребята выпустили новый инструмент, который автоматизирует вообще все. Вот как он работает:

1️⃣Добавляете один шаг в конфигурацию проекта
2️⃣Запускаете сборку, и мгновенно получаете машинный перевод (не абы какой, а сделанный с помощью ChatGPT с использованием контекста, где собственно текст будет использоваться). На данном шаге вы потратили 10 минут и уже можно смело отправлять в App Store.
3️⃣При последующих сборках переводы будут корректироваться и улучшаться по мере того, как переводчики сервиса их проверяют.

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

Диаграмма Исикавы для Root-Cause анализа

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

Флоу работы с ней максимально простой:

✍️Выписываете проблему и рисуете линию. Это – «позвоночник» диаграммы.
✍️По диагонали выписываете основные факторы, повлиявшие на проблему. Это «кости» скелета.
✍️Для каждого из факторов определяете основные причины, которые повлияли на его появление. Их снова записываете по горизонтали, получая «кости» поменьше.

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