Доклады

Коммуникации для тимлида — это либо главный инструмент, либо главный источник стресса и затруднений.

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

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

Доклад, посвященный такому средству коммуникации в проектной команде как meeting notes (заметки или протокол собрания). Цель доклада — рассмотреть все аспекты работы с заметками с собрания: что это такое, зачем они нужны, какую пользу приносит их написание и чтение как лиду, так и всей его команде, а также поделиться практическими советами.

Доклад рассчитан на широкую аудиторию, он будет полезен как практикующим лидам и менеджерам, так и тем, кто собирается ими стать.

PM просит срочно взять в спринт “маленькую” задачку, а потом вся команда влетает в овертаймы, потому что “слона-то мы и не приметили”? И вроде сталкиваешься с оценками и планированием чуть ли не каждый день, но при этом раз за разом с оценками что от команды, что со своими собственными (что еще ужаснее) — творится какая-то ерунда.

В этом докладе я не буду пересказывать Википедию. Не буду учить вас “сколько вешать в граммах” помидорами или рубашками и умножать на 3.14. Вместо этого я хочу рассказать про физиологию нашего мозга и как он нас дурит.

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

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

Почему так происходит и можно ли этого избежать?

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

Справимся?

Мы тратим много сил на то, чтобы сделать команду сильнее. Придумываем тимбилдинги, проводим 1:1, приглашаем коучей.

Это чудесно, но иногда достаточно просто не мешать. Не подавлять инициативу и саморазвитие, не обесценивать чужие достижения.

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

Все вокруг говорят, что обратная связь необходима. Существует куча техник, шаблонов обратной связи и способов её выдавать. Но вот беда — несмотря на все "смягчители", фидбэк всё ещё воспринимается как что-то болезненное, страшное и вместо пользы приводит к обидам и недопониманиям.

На этот воркшопе мы решили подойти к вопросу обратной связи с другой стороны — со стороны майндсета. Приглашаем вас в игровой форме поисследовать психологические особенности обратной связи и потренироваться давать (и получать) её вместе с нами.

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

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

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

Как же понять, когда человеку не хватает хорошей команды, а когда он демотивирован тем, что не получает обратной связи должным образом? А может быть, его задачи слишком просты для него, и он готов к более сложной работе? Попробуйте провести с ним карточную игру Game of Motivations. Не знаете как? Приходите на доклад, на котором я не только проведу сессию игры, но и научу проводить такие игры в вашей команде и компании в целом. У вас будет шанс попробовать себя не только в роли участника, но и в роли ведущего этой игры.

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

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

Однако, в реальности всё идёт не так. То руководитель схватится сам делать руками, то сотрудник сделает что-то не то, то вообще никто ничего не сделает. Да ещё и с разными людьми по-разному! Один получит задачу, пойдёт и сделает, другой завалит вопросами, третий будет её "задвигать" до последнего. Как это исправить?

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

План мастер-класса:
1. Общая проблематика.
2. Ситуационное лидерство (Херши-Бланшар).
3. Покер делегирования (Ю. Аппелло).
4. План действий.

В какой-то момент процессы в вашей команде могут начать стагнировать и определить свой следующий шаг для его развития будет непросто. Вы не сможете поменять все и сразу — даже самые блестящие идеи разобьются о то, что команда, заказчик, QA и др. будут говорить: "Зачем так сложно?". Процесс эволюции нужно бить на маленькие понятные шаги. Я покажу, как можно пройти этот путь с минимальными потерями и какие грабли ждут вас за каждым из поворотов.

1. Персональный Канбан. Как научиться не выгорать (WIP-лимит) и понять, что вы готовы идти дальше.
2. Командный Канбан. Как “схлопнуть” персональный Канбан у команды разработчиков в одну систему. С чем вы столкнетесь при таком расширении команды, как бороться с попытками заказчиков впихнуть нам побольше задач и что будет с WIP-лимитами.
3. Агрегированный командный Канбан. Как включить в свои процессы соседнюю команду (QA, аналитики) и какие бонусы это вам даст: разработка может разгрузить тестеров, вы будете “видеть” процесс полностью.
4. Классы обслуживания. Как сделать систему более предсказуемой.

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

Иногда спасение видится в больших переменах: внедрить Agile, Continuous Delivery, DevOps. Но в ситуации пожара такие инициативы либо отклоняются руководством, либо начинаются и проваливаются.

В докладе я расскажу, как можно реагировать на пожары, чтобы постепенно вывести проект в стабильное состояние. И как при этом не сгореть самому и не спалить команду.

У нас 8 платформенных и 3 продуктовых команды разработки, это 60+ человек и 30+ digital-продуктов. Летом 2020 года мы решили перейти на гибкие методологии разработки, сохранив нашу "неклассическую" структуру с существенной взаимосвязанностью команд. Это позволило нам не расширять штат разработки и получить "плюшки" Agile в виде улучшения T2M и быстрого развития всех наших продуктов. Я расскажу, как мы это делали и с какими сложностями столкнулись.

Тренды в remote-мире.

Хайринг: Формирование ожиданий. Скиллы и опыт успешного remote-кандидата.
Инструмент: Skills Matrix с секцией про remote working skills.

Как работать над развитием скиллов (в том числе remote) сотрудников и зачем один сотрудник работает над идеей Garage Sale, а другой — над аналитикой по продуктовому фидбэку.

Аутсорсинг бизнес процессов (BPO): упрощенный найм профессионалов в свою команду или целых команд для SMB и Enterprise бизнесов.

Прозрачность зон ответственности: методология RACI/RASCI.

Remote-эмпатия: методология HDI; как выбрать эффективный инструмент для совместной работы и коммуникации (Zoom/Skype; Wrike; Bonusly; Shared calendars; Virtual party).

Подводя итог, посмотрим, как много плюсов дает работа в распределенной команде. Особенно, когда это неизбежно :)

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

1) Горизонтальные связи, здоровая коммуникация, ценностные процессы — в каких компаниях важны и какую долгосрочную повестку развития команды формируют.
2) Как развивать среду в компании, оптимальную для проявления творчества, изобретательства, работы на стыке разных департаментов и кросс-функциональных задач? Какие виды внутренней мотивации человека мы поддерживаем через те или иные инструменты внешних "систем мотиваций"?
3) Как мотивировать сотрудников, если у них всегда и так все хорошо? Как создать ту гравитацию в компании, которая будет "увлекать" даже "выросших" и сильных.

One-on-ones, code review, P&L, Agile/Scrum, performance review — популярные практики, повышающие эффективность работы. В 2020 году о них было слышно из каждого утюга. Но что делать, когда всё очевидное уже изучено и опробовано, а всё подходящее уже внедрено, принесло результаты и поддерживается?

Докладу предшествовало исследование: из практик, которые мы используем в Wargaming Platform, мне помогли выделить полезные, но не самые очевидные и популярные.

Вас ждет список нехайповых, но полезных практик для инженерных лидов:
- с областью применения;
- с описанием сути практики;
- с оценкой ожидаемой пользы;
- с оценкой сложности реализации и будущей поддержки.

* Трансформация процесса автоматизации. Сокращение time-to-market от 8 месяцев до 14 дней за год.
* Взаимодействие с Заказчиком (понять Заказчика и успеть за трендами рынка).
* Управление бэклогом.
* Эффективное планирование.
* Безопасное и оперативное масштабирование ресурсов.

- "Перестройка" команд из разделения по тех. стекам в продуктовые.
- Формирование состава команды: кто нужен и в чем его роль.
- Оценка эффекта влияния типа личности на занимаемую роль в команде.
- Изменение процесса взаимодействия внутри команды. Переход на Agile: грабли и лайфхаки.

Чек-лист для тимлида при трансформации процессов автоматизации.

В 2014 году мы впервые столкнулись с темой нересурсности руководителей. Из 500 тимлидов и менеджеров, которые пришли к нам учиться, 60% оказались на достаточно низком уровне энергии и удовольствия от работы. Вероятно, именно это и подтолкнуло их к обучению как средству что-то изменить.

С той поры тема энергии в работе, выгорания и его профилактики занимает меня довольно сильно. Наблюдения за тысячами наших студентов, а также индивидуальная работа с людьми показали, что, похоже, есть две основные причины, почему тимлиды и руководители команд теряют энергию:
1. Тимлиды и начинающие руководители не очень хорошо умеют отслеживать свое состояние, а бизнес этому невольно способствует. Каждые две недели мы что-то выкатываем, все время куда-то бежим, а на бегу довольно непросто думать о себе.
2. Тимлиды и начинающие руководители берут на себя много лишнего. И речь здесь не про формальные области ответственности, а про ежедневные разговоры и обсуждения рабочих проблем. Что интересно, команда (вот сюрприз!) привыкает уступать тимлиду место основного драйвера.

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

В своем докладе я буду основываться на продолжительной работе с несколькими группами студентов, являющихся тимлидами, менеджерами и руководителями отделов в самых разных ИТ-компаниях.

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

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

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

Мы живем в то время, когда сильные специалисты уезжают в крупные города. Когда рынок в регионах просто пустует. Зато задачи остаются с нами. Как выживать в такой обстановке? Попробовать нанять тех, кто еще молод и горят глаза, но не хватает опыта — джунов.

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

Часто получается так, что тимлидом в команде становится самый прокачанный разработчик. Зачастую этот разработчик хорош в hard skill’ах, но менеджментом до этого не занимался. В своем докладе я попробую рассказать о том, как принципы SOLID могут помочь технарю понять базовые правила менеджмента. Мы поговорим про людей и их роли, а также поймем, все ли из этих принципов применимы к управлению командой.

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

Я была в роли тимлида, от которого уходили крутые ребята, потому что они не видели, как и куда дальше развиваться в компании, а я ничего не могла с этим сделать. Я была в роли сотрудника и тимлида, который думал об уходе по той же причине. Я была в роли сотрудника, которому компания дала возможность выдохнуть и разобраться в себе во время творческого отпуска и который смог в результате передоговориться с компанией и прийти к win-win. Этим опытом и хочу поделиться с двух точек: как практика «творческий отпуск» поможет компании (и тимлиду в роли руководителя), и как — человеку (и тимлиду в роли сотрудника).

Мой рассказ может быть полезен, если:
→ вы не хотите потерять ценных сотрудников, но не понимаете, что им предложить прямо сейчас;
→ вы не можете похвастаться сильным EVP и ищете дополнительные преимущества работы в вашей компании;
→ у вас кризис развития и вы думаете об уходе.

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

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

Рассмотрим практические кейсы – наши ошибки и успешные решения конфликтных ситуаций в командах.

Довольно очевидно, что junior-разработчику и тимлиду требуется сильно различающийся набор навыков. И если в случае hard skills всё уже миллион раз проанализировано и посчитано, то о необходимом наборе soft skills в зависимости от должности мы можем только понимать на уровне ощущений и здравого смысла. При этом данная информация могла бы быть крайне полезной при найме и развитии своих разработчиков.

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

Поиск, адаптация и развитие сотрудников — процесс бесконечный, но крайне важный.

Поговорим о том, чем HR может быть полезен тимлиду, как эффективно с ним взаимодействовать для достижения целей команды:
1. Как найти сотрудника, который гарантированно впишется в вашу команду.
2. Как адаптировать новичка, чтобы максимально быстро получать от него результат в работе.
3. Как выстроить процесс развития талантов: работа с HiPo, школа наставничества, кейс-клуб для руководителей.
4. Что HR точно сделает лучше, а куда HR лучше не пускать.

В период карантина и самоизоляции пышным цветом расцвело направление Developer Relations (DevRel) — рассказывание профессиональных историй инженерами инженерам. Из каждого утюга стало доноситься по онлайн-митапу или вебинару. Статьи с Хабра, VC и остальных мест пошли непрерывным потоком.

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

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

Тем удивительнее увидеть, что удалёнка сделала DevRel не только источником раздражения, но и открыла новые возможности инженерам извлекать пользу из DevRel.

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

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

За много лет работы с Open Source я нашел несколько закономерностей: на что стоит обращать внимание при выборе технологий, как правильно участвовать в их развитии, а какие проекты лучше обходить стороной. Но обучить разработчиков пользоваться Open Source "в лоб" оказалось не так просто. Поэтому я придумал хитрый трюк, которой позволяет моим коллегам получать все лучшее от участия в проектах с открытым исходным кодом, одновременно обучая их выбирать и правильно использовать Open Source на благо компании.

Токсичные люди не просто так появляются в коллективе. Иногда они появляются сами, иногда это epic fail при найме «энергичного и амбициозного лидера», иногда это «щука в пруду», которую начальник держит, «чтобы карась не дремал».

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

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

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

Как понимать, воспринимать, коммуницировать, как с ним работать, как способствовать тому, чтобы он изменил свое поведение. Будем рассматривать принципы и практики, наши и ваши примеры.

Практика коммуникации с токсичными сотрудниками, чтобы сделать дело и сохранить себя.