Расскажу про модель Management 3.0.

Расскажу, что из модели мы считаем важным и уже сейчас используем.

Покажу некоторые практики из M3.0 и объясню, как вы можете использовать их у себя в командах.

Год назад я рассказывал о том, как мы прошли Agile-трансформацию, каких результатов добились, создав масштабируемый scrum c value stream'ами (http://teamleadconf.ru/2018/abstracts/3199).

Такая организационная структура отлично подходит, когда у тебя уже есть продукт и технологические рельсы, и ты пилишь новые feature. Но что делать, если тебе нужно создать продукт заново, забыв обо всем, что было раньше, если продуктового видения еще нет, старые framework'и вызывают отвращение, ты все чаще слышишь слово legacy к месту и ни к месту и, как это обычно бывает, исправить ситуацию нужно вчера.

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

Только за последний год в Авито мне довелось поучаствовать в запуске десятка команд как в качестве инициатора, так и в качестве участника.

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

Проводить Code Review - это непростая задача, и я поделюсь наработками и приёмами, помогающими в этом нелёгком деле.

Мы поговорим:
1. о том, кто должен выполнять code review;
2. о визуализации статусов задач по code review;
3. о мониторинге процесса code review;
4. о взаимодействии с командой тестирования;
5. о том, какие дефекты следует заводить, а какие нет;
6. как разрешать споры и не подраться;
7. как оформлять code review;
8. как начать любить code review и получать удовольствие.

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

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

Этот доклад будет не про то, как можно удержать сотрудников, которые приходят к вам с оффером от другой компании. Удерживать, конечно, можно и нужно. Для этого есть масса вариантов. Но “тушить пожар” - это всегда дороже, чем проактивно предупреждать его с помощью грамотного people management.

В своем докладе я расскажу про то, как мы в Wargaming Platform собираем данные об эмоциональном состоянии сотрудников, а именно как определить:
- мотивационный статус (и что это такое),
- уровень стресса, 
- степень удовлетворенности, 
- риск ухода, 
- риск профессионального выгорания, 
- эффект от ухода.

Мы поговорим о том, как WG Platform начинает переходить к ongoing performance review process, и как мы работаем в направлении развития талантов.

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

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

Как быть крутым тимлидом, не работая по 12 часов в день? Никак, придется много работать. Но есть спасение: работать над командой, делая ее независимой от тимлида. Для этого недостаточно "делегировать задачки" или "внедрить методологию", потребуется время.

Расскажу об опыте усиления команд: подходы и практические советы.

Я всю жизнь работал в локальных командах. Однажды стал тимлидом, переехал в Москву, был вынужден набирать людей из Питера и строить распределённую команду. Я расскажу об этом опыте.

• Удалённый найм. Как адаптировались собеседования.
• Менеджмент требований. Что сломалось от удалённой работы, и как это исправить.
• Менеджмент людей. Как сделать разработчика частью команды. Как сохранить привычный для офисной работы коннект с подчинённым.
• Выстраивание самостоятельной команды. Цель: команда сама из бизнес-требований формирует 1.5-месячную задачу, делит между собой и делает за <2 недель в рамках плана.
• Что дал второй офис, и стоило ли регулярно приезжать для личного общения.

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

Я верю, что распределённые команды могут быть не менее эффективными, чем локальные. Распределённые команды — это не страшно!

Работа со сроками в Badoo — это неотъемлемая часть инженерной культуры, цель которой — постоянное улучшение процессов, рост сотрудников и повышение эффективности работы команды.

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

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

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

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

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

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

Часто ли вы сталкиваетесь с тем, что тимлид и менеджер играют в «пинг-понг», стремясь перекинуть выполнение задачи друг на друга? А бывает так, что кто-то берет на себя лишнюю ответственность и делает чужую работу в ущерб своим основным обязанностям? Приходится спорить по вопросу «кто должен это делать?» или находить компромисс, чтобы задача двигалась к результату?

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

В своем докладе я хочу рассказать, как мы решали возникающие проблемы и помочь тем, кто столкнулся (или скоро столкнется) с трудностями, решить их за счет нашего опыта, а не собственных ошибок.
В частности, поговорим о следующем:
— кто за что отвечает: распределение ответственности между менеджером и тимлидом;
— как должна выглядеть эффективная коммуникация между тимлидом и менеджером: правильные и неправильные вопросы;
— как исключить перебрасывание задачами внутри команды;
— «Сначала я на тебе поезжу, а потом ты меня покатаешь»: как сделать так, чтобы каждый занимался только своей работой;
—jira-workflow в AGIMA как пример эффективного взаимодействия «менеджер-тимлид-другие роли»;
— «побочная» работа, которую все равно нужно делать: как тимлид должен планировать свое время.

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

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

OKR в Авито используются уже 2,5 года. В последнем квартале к системе подключились 73 разные структуры, среди которых вся компания, функции, вертикали и конкретные команды.

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

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

Рано или поздно каждому тимлиду приходится решать конфликтные ситуации.

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

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

Работа построена по основе реальной программы развития тимлидов компании ЦФТ.

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

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

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

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

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

Вы узнаете:
● Какие факторы влияют на доверие в команде.
● Почему важно поддерживать прозрачность и открытость.
● Как применять на практике Team Trust Canvas - новый инструмент для командной работы.
● Как Доверие улучшать от итерации к итерации.

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

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

Я хочу рассказать о том, как менялась команда платформы. Почему эти изменения были необходимы. Как именно мы меняли и меняем инженерную культуру. Почему для нас "инженерная культура" - это не очередной buzz word.

Пара историй, для подтверждения того, что наш выбранный путь это верно:
- Обмен знаниями.
- Workshops.
- Meetups.
- 1 on 1.
- Performance review.
- Почему инженеры лучше менеджат инженеров.
- Внутренние технические дайджесты.
- Изменения релизных процессов.
- Эксперименты в командах.
- CI/CD.
- Pass gather.

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

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

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

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

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

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

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

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

Мы долго думали, как максимально адаптировать процесс обучения под тимлидов. Поняли, что такое обучение должно максимально отвечать системе ценностей профессии, отрасли, компании. Возникла идея! А что, если отнестись к тимлиду, как к “программному продукту”, который необходимо быстро выпустить и который отвечал бы требованиям заказчика? Как в этом случае мы могли бы построить процесс обучения? Развивая тимлида в духе Agile и используя Scrum, мы расстраиваем обучение тимлида как разработку "продукта “Тимлид”.

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

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

Я хочу поделиться опытом Lamoda в борьбе с потоком саппортных задач. Подход держится на следующих ключевых аспектах:
- регулярность работы с саппортным бэклогом;
- четкое ранжирование задач по уровню критичности/срочности;
- приоритет на поиск root cause вместо прикладывания подорожника к симптомам;
- кросс-системные мониторинги;
- четкая последовательность действий при возникновении major incidents;
- обязательная автоматизация тестирования;
- приоритет на корректность и стабильность работы, а не на огульное наращивание функциональности.

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

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

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

Все идеи буду демонстрировать на реальных примерах из собственного опыта.

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

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

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

Музыкальная индустрия и IT - это фундаментально схожие сферы деятельности, в которых действуют практически одинаковые законы творчества и бизнеса. Именно к такому выводу я пришел, основываясь на 15-тилетнем опыте работы в промышленной разработке софта и будучи музыкантом-любителем с более чем 30-тилетним стажем. Если мой вывод верен, то это означает, что для достижения командного успеха программисты и тимлиды могут просто брать и применять в своей работе “лучшие практики” из более зрелой и отлаженной музыкальной индустрии.

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

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

Вам наверняка попадались сведения об устройстве Performance Review в больших командах: Badoo, Avito, Яндекс. Эти достойные практики не всегда хорошо ложатся на команды меньшего размера. Вы как руководитель пришли к решению, что какая-то оценка сотрудников нужна, но какая именно — неясно. Вы ограничены в ресурсах: нет возможности сидеть над сведением данных, нет возможности привлечь проектного менеджера или HR'а, нет возможности остановить текущую работу.

В рамках доклада попробуем ответить на следующие вопросы:
* в чем отличие Performance Review, Feedback и One-to-One;
* зачем давать обратную связь сотрудникам;
* как обойтись малыми силами.

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

Если вы не teamlead, берите инициативу в свои руки. Доклад поможет вам сформировать критерии для проверки себя.

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

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

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

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

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

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

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

Я хочу поделиться своими ошибками и открытиями о проведении управляемых кросс-функциональных встреч для 6-12 человек.

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

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

Здесь можно задать вопрос к круглому столу: https://www.sli.do/#TLCONF-Remote

Обсудим, какие существуют подходы в настройке персонального роста IT-инженеров в продуктовых Agile-командах. Скрам ничего не говорит о роли тимлида. Может ли скрам-мастер, функциональный техлид или владелец продукта выполнить роль персонального менеджера для IT-специалиста и поддержать его развитие в команде. Как могут меняться подходы с ростом команды из 10 в 200 IT-инженеров.

Формат: обсуждение. Делимся опытом успешной работы тимлидов и HR, совместными усилиями рисуем варианты success-path.

1. Коммуникации.
Ищем общую терминологию для тимлидов и HR. Учимся измерять и оценивать HR-процессы и разбираемся, что сделать для их улучшения. Договариваемся про общие, понятные всем метрики.
2. Совместная работа.
Поговорим про возможную совместную деятельность HR и тимлидов. Как работать вместе благодаря друг другу, а не вопреки? Подробно остановимся на HR-бренде, IT'шных сообществах и внутренней культуре отдела разработки.
3. Границы и ограничения.
Обсудим, что этично и неэтично при найме и о чем нужно договориться на берегу. Так вышло, что HR и IT по-разному видят репутацию компании, а также, что допустимо, а что неприемлемо в общении между коллегами и соискателями. Поговорим про нормы, которые есть сейчас, и про то, какие нормы мы хотели бы видеть.
4. HR и DevRel.
Помимо HR в компаниях появляются еще и DevRel. Поговорим про то, чем они могут и должны заниматься, что было и остается HR-функцией, а что обязанность руководителя/тимлида.

За 7 лет наша компания прошла путь от небольшой команды системных администраторов, решающих задачи заказчиков в дневное время, до полноценного DevOps-продакшна, ведущего непрерывную круглосуточную работу по настройке, поддержке, развитию инфраструктур и оптимизации процессов разработки для более чем 100 компаний в круглосуточном режиме. При этом в ночное время мы работаем не только в формате техподдержки и реагируем, когда у какого-то клиента что-то сломалось, но и продолжаем полноценную активную работу по текущим инфраструктурным задачам, которые зачастую довольно объёмные и могут длиться по нескольку недель.

В докладе я расскажу о подводных камнях, с которыми столкнулись на пути, выработанных нами решениях и рабочих процессах, которые мы опробовали и можем рекомендовать к применению другим компаниям и командам. А именно:
- как передавать задачи между сменами так, чтобы инженерам не нужно было гадать, какие задачи и с какого места им нужно подхватить;
- какие рабочие графики для 24/7 мы перепробовали и к чему в итоге пришли, чтобы решить проблемы выгорания ночных инженеров, не допускать их отрыва от команды и избегать текучки кадров;
- как выстроить алгоритм приоритизации задач, когда в стеке более 100 активных проектов, чтобы в каждый конкретный момент времени инженеры понимали, какие задачи и по каким проектам важные и срочные;
- как организовать удобную систему нотификаций, чтобы свести к минимуму информационный шум и каждый участник получал только релевантные для него уведомления.

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

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

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

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

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

Что будет:
- Формирование опыта vs формирование знаний.
- Ретроспектива vs рефлексия.
- Две схемы проведения рефлексии:
- на нахождение и понимание проблемы,
- на мотивацию.
- Развитие осознанности в команде.
- Алгоритм развития управленческих навыков и ключевые переходы в карьере руководителя.

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

Сегодня как никогда актуален вопрос формирования графических методик, позволяющих воспринимать и усваивать информацию более эффективно. Успех графической визуализации объясняется тем, что человеческий мозг склонен рисовать картинки, мыслить образами, и язык рисунка – универсален!

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

"Я верю, что байки старичков - лучшая документация" vs "Мы пишем тонну спек и отлично себя чувствуем".

Обсудим, как примирить эти две позиции, почему и как можно успешно сочетать самодокументируемый код, устную традицию и документацию as is. Спойлер: мы пока и сами не знаем.

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