TeamLead

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

Тезисы и структура:

– О себе: бекграунд и путь

– Про продукт и команду: проекты Mail.ru, Почта, Направление Антиспама

– Универсальные инструменты тимлида: к чему мы привыкли

– Факапы руководства и трансформация через них

– Мои принципы руководства

– Универсальный набор практик через призму личного опыта

– Результаты: влияние на команду, на продукт, на бизнес-группу и на собственные достижения / ощущения

Когда мы имеем большую команду, то за распределением задач не всегда можно уследить. Кто-то загружен на 30% работы, а кто-то на все 130%. Такая ситуация может привести к выгоранию одного сотрудника, и поиску новой работы из-за состояния "я не развиваюсь" - другого сотрудника.

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

Основные тезисы:

1. Особенности распределения задач в больших командах и почему за этим необходимо следить руководителю

2. Методы оценки загрузки сотрудника

3. Распределение задач между сотрудниками, а также вопросы делегирования

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

Расскажем, почему процесс управления доступностью важен и как он развивался в Петрович-Техе.

Эволюция процесса: первые два этапа, тактический уровень:

1 этап - "тушение пожаров”

2 этап - “устранение причин возгорания”

3 этап - “физика и химия горения”

Как работает этап 3, стратегический:

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

Миры бизнеса и IT - радикально отличаются, или чем-то похожи? А может быть, мы все из одного теста, но просто говорим на разных языках?

Я побывала и в сфере бизнеса, и в сфере IT, и на своем примере ощутила, как преодолеть вызовы и различия с обеих сторон.

На основе личного опыта расскажу:

1 Какие основные сложности возникают при взаимодействии между IT и бизнесом;

2 По каким аспектам различается восприятие;

3 Про инструменты, которые помогут построить эфективные коммуникации и достичь классных результатов.

Важно понимать, что IT и бизнес - единое целое, и все мы помогаем компании добиться амбициозных целей.

Актуальность

Наверняка вы сталкивались с ситуациями, когда даже хорошо спланированный IT-проект, обеспеченный ресурсами и поддержкой руководства, по итогам реализации выходит за рамки сроков и бюджетов. И дело здесь не только в объективных причинах, но и во влиянии так называемых когнитивных искажений (проще говоря – ловушек мышления). В динамично развивающейся IT-отрасли, где зачастую решения нужно принимать быстро и на основе неполной информации, ловушки мышления могут серьёзно искажать восприятие реальности, ведя к ошибкам в проектах и управлении командами. Осознание и управление когнитивными искажениями могут значительно улучшить качество разработки и управления проектами, минимизируя ошибки и повышая продуктивность и взаимодействие в команде.

Что такое «когнитивные искажения»

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

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

Топ-5 когнитивных искажений для IT-команд

1. Предвзятость подтверждения (Confirmation Bias). Склонность искать и интерпретировать информацию так, чтобы она подтверждала уже существующие убеждения. В IT-команде это может привести к нежеланию рассматривать альтернативные решения и упускать важные детали.

2. Эффект якоря (Anchoring bias). Склонность переоценивать первую полученную информацию и строить дальнейшие суждения на ее основе. В IT-команде это может привести к неправильным предположениям о стоимости проекта или сроках его реализации.

3. Фундаментальная ошибка атрибуции (Fundamental attribution error). Склонность объяснять поведение других людей внутренними факторами (характером, способностями), недооценивая роль внешних факторов (например, обстоятельств). Как следствие, ошибки или отставание от графика объясняется некомпетентностью или неэффективностью разработчика, а факторы, которые могли повлиять на его работу (например, недостаток документации или непредсказуемые проблемы с инфраструктурой), игнорируются.

4. Искажение в пользу своей группы (Ingroup bias). Мы склонны относиться к членам своей группы более положительно, чем к членам других групп. Члены IT-команд высоко оценивают и ценят идеи, которые исходят изнутри группы, при этом идеи, полученные извне, они считают лишенными инноваций или ценности и, как следствие, упускают возможность повысить свою эффективность за счёт альтернативных предложений.

5. Этот пункт получился бонусным, в итоге мы рассмотрим не 5, а 6 когнитивных искажений, поскольку Группомыслие (Groupthink) и Эффект ложного согласия (False consensus effect) – две стороны одной медали. Первое описывает стиль мышления людей, при котором возникающее стремление к единомыслию оказывается важнее реалистической оценки возможных вариантов действий. А второе – склонность человека считать своё поведение типичным и общепринятым, полагать, что другие люди придерживаются такой же точки зрения. Вы, наверное, тоже встречались с ситуациями, когда кажется, что плохая идея овладевает коллегами, и они держатся за нее изо всех сил. Или были сильно удивлены, обнаружив, что вы глубоко заблуждались, считая, что остальные члены команды придерживаются того же мнения на решение проблемы, что и вы сами. В IT это может привести, к примеру, к ситуации, когда разработчик пользовательского интерфейса будет искренне уверен, что пользователи именно так будут взаимодействовать с приложением, а члены команды не захотят вступать с ним в конфликт и промолчат о своих сомнениях.

Как избежать влияния когнитивных искажений

0. Для IT-специалиста, привыкшего к точности и логике, понимание когнитивных искажений — это как отладка собственного мышления. Понимание "багов" в программном обеспечении нашего мозга – это первый шаг к их преодолению.

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

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

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

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

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

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

Осознание необходимости метрик - с чего все началось?

Масштабы внедрения. А кого мы будем измерять?

Большая ответственность или как объяснить всем, что метрики - это не контроль, а польза?

От разговоров к действиям: немного о процессе внедрения

Первые отчеты и размышления о них

И все-таки есть , куда улучшаться: как внедрение всего 3-х метрик первых привело нас к масштабным изменениям процессов

На личных примерах в докладе расскажу о:

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

- как и когда внедрять изменения

- как сохранить продуктивную атмосферу если команда резко уменьшилась (люди стали уходить) или резко увеличилась

- как взаимодействовать с командой, если все пошло не по плану

- мотивации участников команды

Какую проблему решит ваш доклад?

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

быстро и успешно адаптироваться в команде

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

Основные темы:

- Оптимизация процессов

- Управление командой

- Онбординг / обучение

- Автоматизация

- Численные показатели эффективности

- Декомпозиция, технические задания и т.п.

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