TeamLead

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет! Меня зовут Константин Палфинов и в настоящее время я работаю в качестве консультанта и бизнес-тренера, передавая свои знания и накопленный за 20 лет работы в операционном бизнесе опыт.

Вы задумывались, почему даже самые тщательно спланированные IT-проекты часто выходят за рамки сроков и бюджетов, несмотря на наличие всех необходимых ресурсов? Причины отклонений зачастую связаны с ловушками мышления – когнитивными искажениями. Именно они могут привести к неправильным решениям, конфликтам в команде и снижению продуктивности. На «Стачке» в Питере я буду выступать с темой «Mental Debugging. Как избежать влияния когнитивных искажений в IT-командах». Для своего доклада я выбрал 5 основных ловушек мышления, с которыми чаще всего сталкивался при работе в командах. Я расскажу, в чём эти когнитивные искажения проявляются, к каким последствиям могут провести и что сделать, чтобы минимизировать их влияние на работу IT-команды. И хотя свой доклад я адресую в первую очередь Тимлидам, уверен, это будет интересно и полезно многим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По самым скромным оценкам, 2 из 5 специалистов в IT имеют высокий риск выгорания. 42% близких к выгоранию сотрудников уволятся в течение 6 месяцев.

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

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

А что если не справляться с выгоранием и его последствиями, а предотвратить его? Предотвратить выгорание – это управление эффективностью команды. А не это ли задача тимлида?

Мы исследовали выгорание целый год. Я поделюсь данными исследований и расскажу:

– как распознать выгорание у сотрудников;

– какие личностные особенности уберегают сотрудника от выгорания или, наоборот, способствуют ему;

– что может сделать тимлид или любой другой руководитель, чтобы снизить риск выгорания сотрудников;

– что делать с теми, кто уже сгорел.