Доклады

Никто не любит манипуляции, и все говорят о сотрудничестве.

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

Что лучше — аджайл или водопад? Ответ на вопрос неочевиден, где-то лучше одно, где-то — другое.

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

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

Но как именно лидеру команды делать это на практике? Что, если команда не особо проявляет инициативу и берет ответственность? Как добиться того, чтобы команда сама драйвила проекты и предлагала решения?

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

На нашем воркшопе вы:
- сможете на практике попробовать себя в роли фасилитатора;
- узнаете базовые принципы принятия групповых решений;
- освоите техники фасилитации командных обсуждений;
- сможете применять навыки со своими командами уже завтра.

До встречи на воркшопе!

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

Цель, как написано о цели Wiki, — идеальный или реальный предмет сознательного или бессознательного стремления субъекта. А у психологов есть гипотеза, что у человека только 15-20% — это сознательная работа мозга, а остальные 80% (если повезет) — бессознательная. Получается, что нами движут бессознательные цели?

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

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

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

На практическом занятии мы посмотрим, как формируется командная динамика, как формируются продуктовые (и не очень) цели, как организуется командная работа для безупречного продуктового результата.

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

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

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

Ретроспектива — обязательное мероприятие для развития и роста команды.

Что будет на воркшопе?
1. Вы узнаете, как вести ретроспективную встречу.
2. Какие инструменты для этого использовать.
3. Как помочь команде генерировать идеи и превращать их в план.
4. Какие ловушки вас ждут и как их преодолеть.
5. В чем разница между еженедельной и стратегической ретроспективой.
6. Как помочь команде, если участники не могут договориться.
7. Как с помощью ретроспектив повысить безопасность, ответственность и вовлеченность участников команды.

Ключи к влиянию.
Внутренний антрепренер.
Футбольная схема поиска сторонников.
Волшебный маркер.
Преодоление Status Quo (опровергни меня).
Метод решения споров Stuck Issues.
Схемы питчей.

Мастер-класс про разговор с сотрудником на достижение договоренностей и развитие ответственности. Будет практика, разбор, немного психологии и фреймворков.

1. Уходим в рейд. Прощай корпорация!
2. Учимся объединяться быстро. Расстаемся без обид. Рейдовый принцип командообразования.
3. Бороться за единство команд глупо. Слишком много факторов за разъединение.
4. Более высокая роль лидеров.
5. Сверхпродуктивные люди. Как с ними жить.
6. Сверхпродуктивные команды. Как их формировать.
7. Новая твердость и новая гибкость в управлении. Изменение системы мотивации и контроля.
8. Шэринг головного мозга.

Построение кросс-функциональных команд в промышленности.
Построение Team Minecraft в реальности.

При осуществлении "цифровой трансформации" в компании немаловажное место занимает построение кросс-функциональных автономных команд.

В чем отличие построения команд разработки в "кровавом энтерпрайзе" от стандартных ИТ-компаний?

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

Я расскажу о том, что можно привнести в собеседование, чтобы оно не превратилось в скучный технический собес по чек-листу. А также расскажу, почему это должен делать тимлид, а не HR.

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

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

Источником решений будет Социократия. Это система самоуправления, предложенная Огюстом Контом в середине 19 века и успешно имплементированная для организаций в послевоенной Голландии и некоторых других странах. А недавно ее набор принципов и шаблонов был пересобран с учетом достижений Agile, холакратии, бирюзовых организаций, концепции поток создания ценности и других современных методов, и появилась Социократия 3.0. Хотя Социократия представляет собой целостную систему, авторы вовсе не настаивают на использовании ее целиком. Наоборот, они говорят: "В любой организации есть проблемы. Вы можете попробовать отдельные шаблоны социократии для их решения, и если они помогут — применяйте их дальше".

Мозговой штурм, One-on-ones, scrum — популярные практики, повышающие эффективность работы. Но что делать, когда очевидные варианты закончились?

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

Как повысить эффективность программы обучения? Раскрыть собственный ресурс команды? Как увеличить вовлеченность, чтобы люди доходили до конца? Или создать инициативную, поддерживающую среду в команде, без больших вложений и внешних трансформаторов? Как быстро адаптировать новичков и удерживать «таланты»?

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

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

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

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

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

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

Ценный сотрудник покинул вашу команду — и увёл за собой ещё пару человек?
Я же открыт для диалога — почему он не подошёл ко мне раньше?
Почему отправил counter-offer в корзину, даже не прочитав?
Знакомая ситуация, правда?

Я расскажу о двух мощных инструмента удержания — культуре доверия и one-to-one-встречах.
Рассмотрю 10 вопросов — они помогут вам оценить состояние команды и ее участников.

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

Каждому тимлиду, проджекту или руководителю отдела однажды приходилось настраивать жизненный цикл для задач, фич, багов и т.п. и потом, возможно, визуализировать это дело на доске в Jira, Youtrack и тому подобных инструментах. А потом вы получали кучу вещей, таких как:
- доской и трекером не пользуются;
- люди сопротивляются тому workflow, который вы сделали;
- адекватных данных из трекера не достать;
да и вообще у ваших подопечных больше вопросов, чем у вас ответов.

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

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

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

Основные блоки:
1. Меняем модель мышления — личные достижения или успехи команды?
2. Я не успеваю работать руками! — что съедает время руководителя.
3. Потеря компетенции и синдром самозванца.
4. Почему найм в команду — это тоже ваша работа.
5. Как перестать бояться увольнений.
6. Делать самому или делегировать, как найти ответ?
7. Важные навыки руководителя.
8. Соблюдение work-life balance, возможно или нет.
9. Разрешение конфликтов. Почему конфликты — это не плохо?

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

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

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

Буду рассказывать на примере личных кейсов за последние 8 лет :-)

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

Что будет в докладе:
- Что такое выгорание и почему борьба с симптомами не поможет — развеиваем мифы aka сходи в отпуск и все пройдет.
- Почему средства лечения PTSD (посттравматического стрессового синдрома) работают и для выгорания тоже.
- Что может выглядеть как выгорание, но им не является (карьерный кризис, депрессия, необходимость сменить работу по причинам, отличным от выгорания, несовместимость с культурой компании или руководством).
- Как предотвратить выгорание.
- Что делать чтобы не выгореть второй раз.
- Как помочь коллеге или подчиненному не выгореть.
- Как обратить внимание коллеги, что он, кажется, скоро выгорит.
- "Ты не одинок в своих переживаниях относительно выгорания" — это терапевтично для тех, кому уже очень не очень.

Чего в докладе не будет:
- Кидания помидорами в работодателя(ей) и культуру компани(й).
- Рекомендаций формата "мы все выгорели и сходи-ка в отпуск" = хочется акцентировать, чтобы не навредить, потому что если неправильно преподнести тему, окажется, что все мы выгорели.
- Ничего про реалии российского здравоохранения или особенностей европейской медицины.
- Наставлений "всем на психотерапию".

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

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

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

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

В своем докладе расскажу про кейсы хороших и плохих способов вовлечения команды в работу над продуктом и совместное принятие решений.
До встречи!

Мы в Перекресток Впрок работаем с аутстаффом. Не с аутсорсом — его почти нет, а именно с аутстаффом.
Сейчас у нас на ~20 команд порядка 15% сотрудников, подключенных по модели аутстаффа.

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

Зачем мы запретили слова "аутстаффер", "сотрудник подрядчика", как ребята перестали различать "своих" и "чужих" сотрудников, и почему аутстаффер — тоже человек — об этом в моем рассказе.

Казалось бы, что общего может быть между тимлидом и актером? Не так и много. Но занятия в группе по актерскому мастерству и сценической речи могут дать вам очень много нужных навыков:
* побороть в себе стеснительность и замкнутость;
* говорить с кем угодно о чем угодно;
* лучше выражать эмоции и мысли;
* прокачать эмоциональный интеллект;
* громко, четко и выразительно говорить перед группой;
* управлять своими страхами и эмоциями;
* показать уточку на сцене одной из крупнейших профессиональных конференций страны.

Я занималась актерским мастерством больше трех лет, и это радикально помогло мне в профессиональном и личном развитии. Мне очень хочется поделиться своим опытом с вами, чтобы рассказать, что это правда работает.

Хочу показать большую картину работы с людьми, из которой выводится и “деврел”, и выстраивание коммуникации внутри команды в рамках процесса производства ПО, и работа по найму, и работа по росту/развитию, и подготовка сотрудников к увольнению и последующая работа с ними.

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

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

Однако в работе с людьми почему-то системного подхода я вижу очень мало.

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

Меня зовут Александр и я отвечаю за отдел автоматизации бизнес-процессов в Lamoda. Отделов в tech-блоке много, в каждом у ролей техлида и архитектора есть свои особенности, и я хочу поделиться тем, как менялся концепт техлидства в компании по мере её роста и развития.

За последние 5 лет был пройден сложный путь от dedicated-техлидов в командах до виртуальных техлидов проектов, появления архитекторов направлений, отделов и даже позиции chief architect. Одни изменения происходили под гнётом обстоятельств, другие были частью IT-стратегии.

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

Кроме того, в программе: архитектурные комитеты, взаимодействие с бизнесом, OPS, PMO, CTO, chief architect и о том, куда приводят кросс-командные проекты без техлидов.

Стать менеджером — это стресс. В стрессе мы привыкли к развилке "бей-беги". Это интуитивно понятно и привычно.

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

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

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

В рамках своего доклада я расскажу о жизни ИТ-департамента международной логистической компании СДЭК после ухода сначала CIO, а затем и руководителя разработки.

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

Отвечу на следующие вопросы:
* Как не “выйти в окно” после таких твистов?
* Что теряет ИТ-департамент без CIO с точки зрения процессов, проектов, стратегии и что приобретает?
* Как меняется при этом отношение бизнеса к ИТ?
* Какие изменения аккумулируются в командах и для отдельных сотрудников?
* Как сохранить команду и культуру?
* Как продолжить запускать успешные проекты и улучшать ключевые метрики?

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

Начну с вопроса перегруженности инфраструктурой команды и необходимости выделения технических продуктов и, как следствие, формирования команд, которые будут их развивать. Реализации продуктового подхода в платформенной разработке. Раскрою наш опыт внедрения лучших практик:
- Team Topologies;
- метод OKR — Objectives and Key Results;
- портфель технических проектов.

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

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

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

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

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

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

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

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

Из доклада вы узнаете:
- как понять, кому из кандидатов можно повысить зарплату, несмотря на отягощающие факторы (оффер от другой компании, чувство вины, большой стаж и т.д.);
- какие всё-таки метрики влияют на повышение зарплаты кандидата и есть ли они;
- об опыте руководителей Газпромбанка.

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

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

Почему гиг, а не фриланс?

Многим придется еще поработать с новым типом сотрудников, которых становится всё больше.

Мой 10-летний опыт в гиг-экономике:
* когда это полезно;
* особенности работы;
* проблемы и как их предупредить;
* тимбилдинг, который никто не отменял.

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

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

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

"Доколе?!" — однажды хором воскликнули топы, техдиры и HR'ы Центра Финансовых Технологий. И реализовали проект «ЦФТ tema», направленный на создание и поддержку профессиональных сообществ в компании. Казалось бы, а что тут удивительного? А то, что он действительно работает около двух лет и продолжает развиваться.

Что будет в докладе:
1. Покажу труп пилотного проекта, с которого всё началось. Объясню, почему он издох в муках и чему нас научил.
2. Расскажу, как мы сейчас мотивируем коллег выступать на внутренних митапах — возможно, ты что-то позаимствуешь для себя.
3. Накидаю идей, как сделать внутренние митапы явлением стабильным, полезным и привлекательным.

Планирование — инструмент тимлида для управления:
• процессом разработки,
• ожиданиями заказчиков,
• непредвиденными внешними факторами.

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

В моем докладе содержатся ответы на вопросы:
* Что и как планировать в процессе разработки?
* Какие использовать инструменты?
* Какую точность планирования считать рабочей?
* Как обрабатывать и использовать результаты плана и факта?
* Как снизить негатив на необходимость постоянного «треканья» времени?

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

- Индивидуальный план развития как инструмент для личностного и профессионального роста себя и своей команды.
- Поиск карьерной цели и мотивации.
- Сложности в развитии мягких навыков (Softskills).
- Использование Колеса Компетенций для определения зон для развития.
- Как я могу определить, что я развил софт-скил?
- Движение в направлении развития навыка — что делать? Как конкретно развивать?

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

Системный коучинг рассматривает организации и команды как живые системы.
Важно знать основные принципы, чтобы:
1. знать, как подойти к нерешаемым обычными способами проблемам;
2. выявлять такие проблемы и не тратить силы и доверие команды на попытки решить их очевидными способами;
3. самому не плодить системные проблемы команд;
4. знать, какие проблемы лучше не браться решать изнутри компании.

Я расскажу об основных принципах и особенностях применения в agile-среде на основе работы в этом подходе с одним тимлидом, тремя скрам-мастерами, двумя коучами, одной продуктовой командой и о собственном опыте переживания системных динамик в IT-компаниях.

Наша команда начала собираться в Почте менее года назад, перед нами была поставлена задача в максимально сжатые сроки развить существующие и создать новые продукты для рынка ЕКОМ и курьерской доставки. Сложности со сроками усугублялись размерами Почты и развитым ИТ-ландшафтом. Если оценить процесс, самый дорогая часть — это реализация, при этом это узкое горлышко, которое не позволяет на старте оценить конечный результат и сроки, а на старте проекта не позволяет на 100% распараллелить процессы подготовки к эксплуатации и тестирование.

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

В феврале 2020 года Яков Беккер сделал известный доклад на TeamLead Conf о том, как международной продуктовой ИТ-компании PropellerAds удалось отказаться от тимлидов и что из этого вышло. Яков ушел из компании, а эта история — продолжение от меня, директора по разработке этой же компании, о том, как мы продолжаем лететь без тимлидов, с какими сложностями при этом сталкиваемся, как история с плоскими самоуправляемыми командами продолжила работать в пандемию на удаленке, как работаем с ожиданиями бизнеса, который не хочет меняться и продолжает по старинке искать тимлида в каждой ИТ-команде, и почему отказаться от тимлидов получилось в конце концов только в продуктовом блоке.