25 и 26 февраля,
Москва

Заявки на доклады

Поиск по тегам:

Смысл работы и его искажения

Что сделать, чтобы миссия компании не стала пустым звуком

Артём Сусеков

Когда IT-инженер не понимает ценность того, что делает – это сводится к тому, что он просто «пилит тикеты» или, другими словами, обменивает своё время на деньги. Такая картина выглядит особенно печально, если вспомнить про то, что наша работа – это творческий процесс.

Я расскажу, каким образом мы вовлекаем IT-инженеров в процесс разработки – мотивация, смысл, personal contribution, как соотносятся цели и миссия компании с повседневной работой разработчика.

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Психологические инструменты влияния в организации, экологичность

Баланс огня в работе: антипригарное покрытие для команд и организаций

Мария Берлин

* Выгорание - что это и откуда берется. Когда вовремя нужно предпринять действия по предотвращению (спойлер: на старте проекта).
* Какие факторы ключевые.
* Осторожно, мессенджеры! - как управлять инфострессом.
* Какой уровень неопределенности и тревоги способствует креативности, а какой выжигает.
* Чеклист для проверки экологичности среды и состояния команды.



Программный комитет ещё не принял решения по этому докладу

Инструментарий тимлида

Как мы пытались заменить менеджера простым скриптом на питоне, и что из этого получилось

Александра Косилова

Teamplify (https://teamplify.com/)

1. Собирает всю активность разработчиков в одном месте (Slack, Github, Gitlab, Jira, отчеты о выполненной работе за период, отпуски, праздники, больничные). Приносит больше спокойствия как менеджерам, так и разработчикам, так как в любой момент времени доступна полная информация о текущей деятельности как команды, так и разработчика.
2. Позволяет выявить характерные проблемы в работе команд.
3. Экономит время разработчика и менеджера и, как следствие, экономит деньги компании.
4. Избавляет менеджеров от заметной части рутины (умные нотификации): знает про государственные праздники в 180 странах мира, и автоматически напомнит про те, которые актуальны для вашей команды; предупреждает, если человек идет в отпуск; напоминает о приближении дедлайнов; напомнит о необходимости сделать апдейт в задаче; напомнит о необходимости написать отчет.



Программный комитет ещё не принял решения по этому докладу

Дизайн-спринт: Как пройти от идеи до прототипа за 5 дней?

Абсамат Ханбабаев

Дизайн-спринт - это супер-популярный на Западе фреймворк. Его используют стартапы, огромные корпорации и акселераторы. Методолoгия позволяет им сэкономить несколько месяцев на создание и проверку идей новых продуктов и фич.

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

Мы в Useful проводим дизайн-спринты пару лет. Пробовали их в своих продуктах и в продуктах наших клиентов. Каждый раз убеждаемся в эффективности методологии и поэтому хотим распространить знание о Дизайн-спринтах.

Дизайн-спринт помогает понять:
• Как должен выглядеть и работать продукт?
• Стоит ли идея месяцев работы?
• Найдет ли ваше ценное предложение отклик у аудитории?
• Как «продать» идею команде и руководству?

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

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

В рамках выступления мы расскажем:
• Про методологию и упражнения.
• Для каких задач подходит Дизайн-спринт.
• Как организовать эффективный Дизайн-спринт.
• Где узнать больше про Дизайн-спринт.
• Как продать Дизайн-спринт команде и руководству.
• Свой опыт на примере кейса с Лабораторией Касперского.

Программный комитет ещё не принял решения по этому докладу

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

Александр Зиза

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

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

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

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

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

Управление / другое
Программный комитет ещё не принял решения по этому докладу

Автоматический тимлид: автоматизация управления разработкой программного обеспечения

Сергей Собко

Сказ о том, как я научился собирать статистику с систем контроля версий (GitHub, GitLab), трекеров задач (GitHub, GitLab, Jira, TFS) и месседжинговых систем (Exchange, Slack), агрегировать ее и менять любые элементы оных программным способом, а затем заопенсорсил библиотеку Flower (https://github.com/PositiveTechnologies/flower) для построения своего автоматического тимлида на Clojure.

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

Фреймворки
,
Java
,
Прочие языки
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Организационная структура

Вашей команде не нужен Scrum Master

Владислава Беганова

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

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

Модели руководства
,
Корпоративная культура и мотивация
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Круглый стол

Как тимлидам эффективно взаимодействовать с HR и не сойти с ума

Екатерина Семенова

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

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

Другое
Программный комитет ещё не принял решения по этому докладу

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

Иван Демшин

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

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Продуктовая разработка
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Коммуникация

Remote only в продуктовых и аутсорс командах разработки

Александр Моторин

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

Программный комитет ещё не принял решения по этому докладу

Инструменты визуализации как средство синхронизации команд

Иван Демшин

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

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

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

"Разговоры в курилке": как эволюционирует общение с ростом компании

Дмитрий Марущенко

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

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

Программный комитет ещё не принял решения по этому докладу

Коммуникация между комадной и окружением проекта: проблемы и решения

Анастасия Олейниченко

Все понимают, что коммуникация в проекте очень важна. Нехватка взаимопонимания между участниками зачастую приводит к большим проблемам или даже срыву проекта. Каждый может рассказать историю, как это бывает, и не одну. Почему же в таком случае разработчики систематически страдают от сложностей с коммуникацией? Потому что решительное желание наладить контакт с другими участниками проекта толкает их в крайности. Одна крайность: мы всё будем записывать, и поэтому ни в чем не запутаемся. Другая крайность: мы будем постоянно общаться и обо всем договариваться. Результаты обескураживают: партнеры по проекту в какой-то момент начинают вести себя так, словно они утратили способность к пониманию человеческой речи. И тогда возникает вопрос: "Что случилось? Ведь всё было так хорошо!" А вот в чем. Для успешной коммуникации кроме желания необходимы еще понимание позиции партнера, а также общий язык и базовые представления о предмете разговора. Внутри рабочей группы это все хотя бы худо-бедно есть, но об окружении проекта этого не скажешь. К окружению проекта относится, конечно, заказчик, а также другие заинтересованные стороны, в частности, будущие операторы системы и отраслевые либо государственные регуляторы. Их приоритеты, квалификация и представления о прекрасном -- случайная величина для разработчиков.
Что можно с этим сделать? Предлагаем несколько путей решения вопроса:
- "Вжиться" в роль заказчика, усвоить его язык и его представления: «с волками жить -- по-волчьи выть».
- Обратить заказчика в "истинную веру", погрузить его в собственные представления о прекрасном и способах обсуждения этого прекрасного.
- Найти с заказчиком общий язык, именно общий, а не принять его или навязать или "продать" ему свой.
В докладе будут рассмотрены эти три пути, их сильные и слабые стороны, уместность каждого из них в зависимости от особенностей ситуации.
Вопросы коммуникации интересны не только и не столько руководителям проекта, но и тимлидам проекта. Ведь, как показывает практика, именно тимлиды при условии успешно решенных задач вырастают до руководителей. И получают все возможности и рычаги внедрять полученный опыт в дальнейшие проекты, организовывая коммуникации наиболее оптимальным образом для всех его участников.

Программный комитет ещё не принял решения по этому докладу

Извлечение, структурирование и коммуникация мыслей в проектах

Дмитрий Кудрявцев

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

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

Проектные артефакты, инструментарий
,
Теории и техники анализа
,
Аналитика / другое
Программный комитет ещё не принял решения по этому докладу

Эффективные коммуникации. Как помочь команде быстро и эффективно принимать решения

Николай Фабричев

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

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

Программный комитет ещё не принял решения по этому докладу

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

Наталья Свешникова

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

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

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

Доклад принят в программу конференции

Эффективная онлайн-коммуникация для удалёнщиков

Иван Соболев

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

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

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

Другое
Программный комитет ещё не принял решения по этому докладу

Выстраивание технологического процесса

Шаблоны процессов разработки для Data Science-команд

Павел Филонов

Для построения процессов разработки ПО существуют испытанные временем шаблоны, которые позволяют добиться прозрачности и предсказуемости результатов. Попытка напрямую применить данные шаблоны к DS-проектам иногда напоминает желание вставить квадратное в круглое или наоборот. При этом не все руководители знают, что для этой области существуют свои шаблоны (CRISP-DM, KDD, TDSP и проч.), которые можно научиться сращивать с привычными методологиями (SCRUM, Kaban, waterfall) и практиками (Code Review, CI/CD).

В докладе будут рассмотрены конкретные примеры построения процессов работы DS-команды на примере шаблона CRISP-DM и его отображение на систему управления проектами. Также будут рассмотрены такие общепринятые практики разработки, как то:
* как оформлять репозитории;
* как вести документацию;
* как проводить Code Review
в специфике DS.

Code Review
,
Инструментальная поддержка, декомпозиция задач
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Как создавать достаточно хорошие пользовательские интерфейсы без дизайнера

Евгений Романовский

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как определять барьеры в технологическом процессе и как их преодолевать

Алиса Гусева
Лилия Земнухова

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

Программный комитет ещё не принял решения по этому докладу

Строим эффективную мобильную разработку: опыт Badoo

Иван Бирюков

C 2013 года мобильная разработка в Badoo выросла с 20 до 50 человек, с 1 до 5 продуктов, прошла через перестройку процессов на разных уровнях и структуры подразделения.

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

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

Особенности процессов разработки и тестирования мобильного ПО
Программный комитет ещё не принял решения по этому докладу

Может ли ваша команда доставлять продукт пользователям без доступа к проду

Виктор Еремченко

В инженерной команде RealtimeBoard более 50 технических специалистов и только 4 из них DevOps-инженеры. Они обеспечивают доставку продуктового инкремента на продакшн-окружение.

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

Непрерывное развертывание и деплой
,
Менеджмент в эксплуатации
,
Непрерывная интеграция
,
Автоматизация разработки и тестирования
Программный комитет ещё не принял решения по этому докладу

Построение процесса разработки с нуля. Практический опыт

Денис Юрьев

Когда проект только зарождается, желание творить пересиливает скучные порывы к различным «ограничениям» творческого процесса (документация, тесты, обсуждения с коллегами своих планов). Зачем, когда хочется попробовать все паттерны, о которых прочитал вчера вечером? Нужно же быстрее нарабатывать опыт, а не сидеть описывать сделанное! Да и бизнес стоит за плечом.

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

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

PHP
,
Бэкенд / другое
,
Рефакторинг
,
Методы и техника разработки ПО
Программный комитет ещё не принял решения по этому докладу

Внедрение инженерных подходов и практик после оценки эффективности команды

Виктор Фабриченко

На прошлой Saint TeamLead Conf 2018 сделали первый шаг и обсудили, как измерить текущую эффективность команды. Общий результат: на создание нового тратится около 25-30% времени разработчиков.

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

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

Что будем рассматривать? НИОКР, парное программирование, разработка через тестирование, создание тестового окружения, специалистов широкого профиля.

Программный комитет ещё не принял решения по этому докладу

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

Евгений Рыжков

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

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

Стандарты кодирования
,
Методы и техника разработки ПО
,
Безопасность программного кода, SQL и прочие инъекции
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Code Review
,
Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Тестирование безопасности
,
QA / другое
Программный комитет ещё не принял решения по этому докладу

Управление изменениями и внедрением процессов, инструментов, инноваций в команде

Иван Михеев

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

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

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

Программный комитет ещё не принял решения по этому докладу

От монолитов до open source: как и зачем мы меняли подход в разработке

Павел Савельев

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

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

Методы и техника разработки ПО
,
Разработка библиотек, включая open source библиотеки
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Корпоративная культура и мотивация
,
Процессы и инструменты в enterprise
Программный комитет ещё не принял решения по этому докладу

Как распространить культуру компании в новые офисы на этапе гиперроста

Алина Денисенко

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

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

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

Программный комитет ещё не принял решения по этому докладу

NoOps-команды: менеджмент и создание

Виталий Левченко

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

Я работал с этим в командах из 3-7 бекэнд-разработчиков с 0-4 админами. Результаты работы без админов («девопсов») и передача их ответственности разработчикам превзошли мои ожидания.

Я расскажу:
• как обычной команде разработки передать ответственность за продакшн. Как меняется процесс, что решилось и какие боли остались;
• проблемы найма и адаптации специализированного разработчика (site reliability engineer, SRE);
• опыт миграции от раздельных команд администрирования и разработки к универсальной команде разработчиков.

Я верю, что закончилось время системных администраторов, что методология SRE (когда инженер работает с системой в целом, не ограничиваясь кодовой базой, БД, оркестрацией и настройками ОС) лучше подходит современному продакшну.

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

Программный комитет ещё не принял решения по этому докладу

Бюрократия, взаимоотношения с государством

Закон 152 ФЗ. Как веб-студии и разработчики подводят своих клиентов под уголовную ответственность

Михаил Смирнов

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

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

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

Программный комитет ещё не принял решения по этому докладу

Выстраивание стратегии развития

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

Александр Поломодов

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Осознанный путь от иерархической структуры к плоской, от навязанного софта - к иннерсорсу

Валерий Лаптев

1) Вчера
a. Старт бизнеса по шаблону без IT.
b. Проблемы навязанного софта и заказной разработки, теневое ИТ.
c. Тимлид в иерархической структуре.
2) Сегодня
a. Необходимость цифровой трансформации.
b. Реструктуризация IT:
i. создание собственной фабрики разработки,
ii. изменение в инфраструктуре,
iii. программы по направлениям.
c. Проблемы компании, которая никогда сама не разрабатывала.
d. Вопрос необходимости создания кросс-функциональных команд.
e. Нужен ли тимлид в плоской структуре?
f. Проблемы быстрого роста, новые вызовы.
3) Завтра
a. Иннерсорс.
b. Создание сообществ.

Программный комитет ещё не принял решения по этому докладу

Как построить команду в абсолютно новой сфере и вывести ее в плюс

Гузель Рахимова

Доклад о том, как получилось развить с нуля новое направление по бизнес-анализу в ИТ-компании.

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

Расскажу о подводных камнях, лайфхаках и граблях.

Поиск и развитие команды
,
Выбор стратегии долгосрочного развития, KPI
Программный комитет ещё не принял решения по этому докладу

Как разваливаются творческие команды из умных людей: признаки и возможности профилактики

Алексей Самойлов

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

Это очень важные задачи для каждого тимлида.

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

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

Модели руководства
,
Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Этапы эволюции обратной связи в команде разработки

Александр Черный

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Опенсорсная разработка модели компетенций тимлида

Алексей Свечинов

* По каким критериям выбирать тимлида?
* Какими качествами он должен обладать?
* Чему его обучать в первую очередь?
На все эти вопросы отвечает Модель Компетенций тимлида.

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

Мы провели серию интервью с тимлидами и их руководителями в нескольких IT-компаниях. На основании полученных данных сформировали перечень необходимых компетенций. И решили выложить все в открытый доступ с лицензией creative commons!

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

Программный комитет ещё не принял решения по этому докладу

Я стал тимлидом, и что?

Трансформация. Управление как компетенция

Дмитрий Смирягин

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

Лидерство, нужно ли интроверту становиться экстравертом? Идеальная пирамида тимлида. Четыре типа управления. Все хорошие тимлиды делают это. Ошибки сделаны до нас, повторять их необязательно. Трансформация — путь к «идеальной пирамиде тимлида».

Модели руководства
,
Корпоративная культура и мотивация
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Практическая шпаргалка тимлида

Евгений Ртищев

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

Хочется систематизировать основные инструменты и процедуры (performance review, командные церемонии, взаимодействие с руководителем / product- или project-менеджером, делегирование, управление тех. долгом, развитие и рост разработчиков), рассказать об определённых практических методах, поделиться советами и собственными ошибками.

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

И да! У меня есть уверенность, что получится поделиться чем-то новым и интересным и с более матёрыми и опытными руководителями :-)

В настоящий момент в компании начинаю помогать выстраивать процессы в командах и растить новых лидов.

Программный комитет ещё не принял решения по этому докладу

История назначения тимлида глазами тимлида и его менеджера

Анатолий Иванов
Алексей Куксенок

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

Программный комитет ещё не принял решения по этому докладу

N+1 уроков музыки для тимлидов и их команд

Владимир Красильщик

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

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

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

Программный комитет ещё не принял решения по этому докладу
Программный комитет ещё не принял решения по этому докладу

Брошюра с граблями, или Как восемь человек год были тимлидами

Никита Русин

Год назад в нашей компании официально появились тимлиды. Как говорится, "приплыли"! Основная цель была расплывчата: повысить эффективность работы отделов и взаимодействия между ними. Как это сделать, какие инструменты использовать, где взять эту эффективность и измерить ее повышение?

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

Программный комитет ещё не принял решения по этому докладу

6 вопросов, с которых начинается путь тимлида

Владимир Ионов

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

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

А вот и сами вопросы:
1. Какую часть своего рабочего времени тимлид должен кодить?
2. Можно ли мне, как тимлиду, брать на себя продуктовые задачи?
3. За последние 2 месяца я почти не писал код. Выходит, я почти ничего не делаю?
4. Могу ли я, как тимлид, влиять на что-то кроме непосредственной разработки продукта?
5. Потеряю ли я навыки разработчика, когда стану тимлидом?
6. Я теперь тимлид. Как мне развиваться?

Неопределенность и сомнения, которые вносят эти вопросы в сознание тимлида, комфорта не прибавляют.
Поэтому неопределенность сведем к конкретике, а сомнения развеем.

Программный комитет ещё не принял решения по этому докладу

Скорая помощь для тимлида

Анастасия Кабищева

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

Как быстро перестроить мышление, стиль работы и избавиться от страха?

Я расскажу, как сама прошла путь от инженера до тимлида, какие средства «первой помощи» были действительно эффективными, а что можно использовать только при наличии времени и свободных ресурсов.
1. Рефлексия тимлида: пройти все стадии от отрицания до принятия и перейти к конструктивным действиям.
2. Позиционирование: обозначить свою новую позицию в профессиональном сообществе.
3. Работа с командой: использовать фасилитационные практики и искать «своих».
4. Дела для души: сохранить внутреннее спокойствие.

Программный комитет ещё не принял решения по этому докладу

Отдел тестирования с нуля: личный опыт

Валерия Шевцова

В этом докладе я расскажу о своем опыте создания отдела тестирования с нуля:
- как мы вырастили отдел тестирования в растущей компании (с 1 до 15 сотрудников за 1,5 года);
- как нанимать первых ласточек;
- как обучать сотрудников и себя;
- как вносить коррективы в свою работу, чтобы они были полезны;
- как менять процессы в зависимости от размера и состава отдела;
- как мы готовимся к масштабированию;
- почему работа никогда не заканчивается, и нет предела совершенству.

Программный комитет ещё не принял решения по этому докладу

Мало опыта — много собеседований: как задавать вопросы на интервью, чтобы от вас не скрывали правду

Катерина Гаврилова

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

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

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

Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Я – Тимлид. Что дальше? Путь развития через борьбу со внутренним сопротивлением

Артём Боков

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

Программный комитет ещё не принял решения по этому докладу

Бизнес-процессы

Ведение кросс-командных проектов

Павел Аксёнов

* Что такое кросс-командный проект?
* Как его инициировать и вести?
* Чем его ведение отличается от ведения обычных маленьких проектов?
* Как обеспечить сходимость и запуск?

Доклад принят в программу конференции

Построение бизнес-процессов в digital-агентстве

Алексей Коровянский

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

Слушатели доклада увидят, как из разных кубиков (примеры кубиков: OKRs, market positioning, marketing strategy, performance review и других) складывается цельная и высокоэффективная компания. Взгляд с "высоты птичьего полета" поможет взглянуть на бизнес глазами бизнеса и глубже понять материал других докладов на конференции.

В основу доклада легли более пяти лет опыта по построению команд в США и России.

Программный комитет ещё не принял решения по этому докладу

Танцы с саппортом: виды и формы поддержки

Александр Афенов

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

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

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

Программный комитет ещё не принял решения по этому докладу

Методология как конструктор: инструкция по сборке

Филипп Дельгядо

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

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

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

Доклад принят в программу конференции

Когда тестировщик берётся исправлять баги... во внутренних процессах

Маргарита Калинина

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

Управление / другое
,
Управление изменениями, управление требованиями
,
QA / другое
Программный комитет ещё не принял решения по этому докладу

Как внедрить в компании ретроспективы всех типов проектов, а, главное, зачем?

Андрей Дорофеев

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

Программный комитет ещё не принял решения по этому докладу

Инфраструктура

Бессерверная архитектура как будущее программной разработки

Константин Анисимов

1.Все уходят в облака. Что дальше?
2.Что такое Serverless и как это ускоряет разработку ПО, сокращает затраты на инфраструктуру и DevOps.
3.Docker и Kubernetes устарели. Переходим на следующий уровень.
4.Выбираем сценарии использования Serverless.
5.Что могут противопоставить российские разработчики Amazon Lambda?

Логирование и мониторинг
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Аппаратное обеспечение
,
Сетевое администрирование
,
Администрирование баз данных
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Как тимлиду отстаивать бюджет на закупки для программистов

Андрей Карпов

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

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

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

Управление / другое
,
Другое
Программный комитет ещё не принял решения по этому докладу

Инфраструктура компании как продукт

Артём Науменко

Задавали вы себе вопрос, сколько стоит ваша инфраструктура (сервера, зарплаты, внешние сервисы и тому подобное)?

* Можно ли рассматривать инфраструктуру как продукт?
* Можно и нужно ли считать ROI для инфраструктуры?
* Какие ключевые метрики выбрать для подсчета?
* Как работать над улучшением выбранных метрик?

Как мы строим инфраструктуру в Skyeng, и как это влияет на работу бизнеса. Реальный кейс из практики нашей команды.

Менеджмент в эксплуатации
,
Devops / другое
,
Методологии и процессы разработки ПО; Сроки и приоритеты
Программный комитет ещё не принял решения по этому докладу

Тимлид в организации

Каково это — быть тимлидом в аутсорсе

Андрей Минкин

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

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

Программный комитет ещё не принял решения по этому докладу

Как не потерять все полимеры, став руководителем в новой компании

Алексей Петров

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как проводить собеседования, чтобы выбирали вас

Семен Левенсон

За последний год я провел много собеседований со стороны интервьюера, а недавно и со стороны кандидата.

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

Программный комитет ещё не принял решения по этому докладу

LevelUp! Работа над собой

Жанна Диченко

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

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

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

Программный комитет ещё не принял решения по этому докладу

Тимлид вылупился: что дальше?

Вячеслав Циунчик

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

Автор доклада, как тимлид отдела backend-разработки, около полугода находится на тернистом пути становления профессионала в новом для себя амплуа.

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

Бэкенд / другое
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Корпоративная культура и мотивация
,
Управление / другое
,
Бэкенд мобильных приложений
Программный комитет ещё не принял решения по этому докладу

Тимлид и продакт: эффективное сотрудничество

Анна Федорук

1. Все, что мы делаем - мы делаем для бизнеса.
2. Роли в команде: продакт и тимид.
3. Чего ждет продакт от тимлида:
- проактивность;
- конечная постановка задачи (оценка адекватности, технические решения);
- прозрачность: проблемы и сдвиги сроков;
- заинтересованность в бизнесе и продукте;
- гибкость.
4. Как принять изменения в бизнес-процессах и не беситься.
5. Команда и продуктовые решения.
- Что делать, если хочется сказать “Мы не будем это делать”, “Мы не можем это сделать”?
6. Как выбивать время и ресурсы на работу с техдолгом.
7. Должна ли разработка быть черным ящиком?
- Должен ли бизнес (продакт) принимать участие в жизни команды?
- Что должна знать команда о бизнесе?
8. Процессы, инструменты и приемы.

Программный комитет ещё не принял решения по этому докладу

Тимлид как “программный продукт”. Развитие soft-skills тимлида в Scrum-стиле

Андрей Сухоносенко

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

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

Программный комитет ещё не принял решения по этому докладу

Кто такой лид в Wargaming Platform?

Илья Росляков

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

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

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

Программный комитет ещё не принял решения по этому докладу

Аутсорс vs. продуктовая компания. Что хотят менеджеры от тимлидов в таких организациях?

Алексей Куксенок
Анатолий Иванов

Многие, работающие в ИТ, говорят, что мир ИТ делится на два типа компаний: продуктовые и “аутсорс”. В какой-то мере так и есть: это два самых распространенных типа компаний. Но не все знают, чем же они отличаются, даже после работы в таких организациях. Задача этого доклада как раз показать эту самую разницу на пальцах, а точнее на примерах. “Показать” – значит в какой-то степени противопоставить и объяснить природу различий между ними.

Зачем и кому это нужно? Для инженеров в проекте нет особой разницы между такими компаниями, а вот для менеджеров, начиная с тимлида, эта разница видна и существенна. В рамках данного доклада мы станем “адвокатами” аутсорса и продуктовой компании и объясним, чем они отличаются друг от друга именно для тимлидов, в частности, что хотят от тимлилдов менеджеры в аутсорсе и продуктовой организации.

Программный комитет ещё не принял решения по этому докладу

Трансформационные изменения в людях и командах

Engineering culture in WG Platform team

Вячеслав Костиков

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

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

Программный комитет ещё не принял решения по этому докладу

Тимлид, убей в себе менеджера!

Стас Щетиннков

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

Программный комитет ещё не принял решения по этому докладу

Развиваем доверие в командах

Алексей Пикулев

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

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

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

Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Токсичное лидерство. Как лидер может разрушить команду?

Сергей Дерябин

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

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

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

Большие проекты/команды
,
Модели руководства
,
Поиск и развитие команды
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Доставка ценности в масштабе

Сергей Артемов

Постараюсь ответить на вопросы:
* Как понять, сколько команд программистов нужно, чтобы они справлялись?
* Как управлять доставкой ценности?
* Какая обратная связь должна быть?
* Почему важен Time to market?
* Какие необходимые условия для изменений нужны?
* И что делать с обратной связью.

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
Программный комитет ещё не принял решения по этому докладу

Внутренние разработки как решение проблемы контроля, мотивации и коммуникации веб-студии

Андрей Андреев

У всех команд разработки схожие проблемы.

- Сложности в согласовании ТЗ и дизайна. Порой клиент не знает, чего он хочет. А еще додумывает новый функционал после утверждения стоимости проекта.
- Отсутствие мотивации. Сотрудникам незачем изучать новые фреймворки и библиотеки. Им и так нормально.
- Недостаток контроля команды. Приходится стоять у каждого сотрудника за спиной и смотреть, кто что делает. Или хотя бы трекать время, проведенное за компьютером.
- Горящие дедлайны. Разное случается. Например, программист заболел или просто перегорел. Разработка проекта стоит на месте, а время неумолимо летит.

Ну, а вообще, можно работать по-другому...

Я расскажу про внутренние инструменты Alef Development для решения этих проблем и сколько денег они нам сэкономили, а вы сможете определить для себя — в чем провисаете, как это исправить, и нужны ли под это внутренние разработки или достаточно существующих инструментов вроде Trello или Jira.

Инструментальная поддержка, декомпозиция задач
,
Автоматизация разработки и тестирования
,
Корпоративная культура и мотивация
Программный комитет ещё не принял решения по этому докладу

Рефакторинг легаси-команды и процессов разработки

Ахмед Шериев

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

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

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

Доклад принят в программу конференции

Трансформация в распределённую SCRUM-команду разработки

Михаил Мордвинцев

Была команда разработки проекта из опытных сотрудников, которые сидят вместе ввосьмером в одном офисе. У нас получилось вывести половину людей на другие проекты, а вместо них набрать разработчиков и тестировщиков в новый офис в другом городе, превратив команду в полностью распределённую (6 человек в одном, 4 - в другом, заказчики - в третьем).

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

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

Программный комитет ещё не принял решения по этому докладу

Как слезть с иглы тимлидозависимости

Михаил Осотов

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

Программный комитет ещё не принял решения по этому докладу

OKR: инструкция по применению

Егор Толстой

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

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

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

Большие проекты/команды
,
Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
,
Управление / другое
Доклад принят в программу конференции

Workshop "Опыт как игра: создаём программу развития тимлидов своими силами"

Ольга Давыдова

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

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

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

Программный комитет ещё не принял решения по этому докладу

Кругом враги. Как параноику планировать свою работу

Григорий Петров

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

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

Большие проекты/команды
,
Оценка сложности проекта
Программный комитет ещё не принял решения по этому докладу

Развитие осознанности

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

Анастасия Калашникова

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

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

Доклад принят в программу конференции

Борьба с перегрузками

Александр Бикманов

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

В своем докладе хочу рассмотреть данную проблему c разных точек зрения:
- работа с потоком задач (как уменьшить поток/улучшить качество задач, как делать задачи быстрее, можно ли их совсем не делать);
- отношение к задачам (как повысить психологическую устойчивость, как перестать переживать о невыполненных задачах и не загубить дело);
- управление своей энергией (как не выдыхаться к вечеру);
- управление своим временем (только основные моменты);
- можно ли ничего не делать;
- что совсем не работает.

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

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

Управление / другое
Программный комитет ещё не принял решения по этому докладу

Новая культура организации: бирюзовые, холакратия, agile

О доверии и контроле

Никита Соболев

Мы вынуждены доверять людям.
И при том самым разным: членам команды, заказчикам, исполнителям.
Иногда через силу.

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

Как должно формироваться доверие?
Как сказать людям, что ты им не доверяешь, и не поссориться с ними?
Как выстраивать доверительные отношения и при том все контролировать?

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

Программный комитет ещё не принял решения по этому докладу

Разрешение противоречий в командах и на уровне руководства

Менеджер vs тимлид: распределение ответственности

Андрей Рыжкин

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

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

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

Доклад принят в программу конференции

Стартап Беда. Авралы, обмен знаниями, типовые решения, организация работы, стандарты обучения и трудоустройства.

Валерий Степанов

Доклад о том, как уменьшить боль в стартапе.

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

Программный комитет ещё не принял решения по этому докладу

Как занести продуктовый подход в компанию, которая 25 лет на рынке

Дмитрий Ватютов

1. С чего начать, если твоим проектом (не продуктом) за 1 год управляли 3 менеджера?
2. Так мы делаем продукт или проектом занимаемся?
3. Расскажи, чем отличается продакт-менеджер от ПМ руководителю, коллегам и собственникам.
4. Как создать неформальную партию продактов по изменениям?
5. Так у тебя команда или сотрудники на проект? И почему так?
6. Что из современных подходов менеджмента разработки стоит пробовать, и есть ли универсальные советы?
7. Что дальше?

Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Модели руководства
,
Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
,
Работа со внешним заказчиком/исполнителем
,
Работа с зарубежным заказчиком/рынком
,
Продуктовая разработка
,
Взаимодействие с государством
Программный комитет ещё не принял решения по этому докладу

Раскрытие талантов, психология достижений, OKR

Performance Review в команде Sberbank Online

Александр Черушников

1) Performance Review как процесс.
2) Что брали за основу и с чего начинали.
3) Из каких этапов состоит Performance Review в нашей команде.
4) Какие инструменты используем для проведения Performance Review.
5) Первые результаты после внедрения.

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
Программный комитет ещё не принял решения по этому докладу

Особенности национального найма и обучения тестировщиков

Екатерина Батеева

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

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

Поиск и развитие команды
,
QA / другое
Программный комитет ещё не принял решения по этому докладу
Программный комитет ещё не принял решения по этому докладу

Чем профессиональные разработчики отличаются от любителей?

Даниил Пилипенко

* Из 20 человек, называющих себя программистами, только один действительно им является.
* Какие качества отличают профессионального программиста от любителя.
* Практические советы по повышению точности подбора программистов.

Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

12 недель и 1 стажер

Марина Лесняк

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

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

Корпоративная культура и мотивация
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Работа над собой, собственное развитие

7 с половиной ошибок, которые сделают тебя тимлидом

Антон Тузлуков

Ошибки - зло, а отсутствие ошибок - еще большее зло.

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

Программный комитет ещё не принял решения по этому докладу

Как использовать преимущества своего стиля лидерства в управлении командой

Марина Пайч

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

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

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

Модели руководства
,
Поиск и развитие команды
,
Управление / другое
Доклад принят в программу конференции

Модели softskill для тимлида

Максим Цепков

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

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

Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции

Как вписаться в новую команду?

Паша Финкельштейн

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

Управление / другое
Программный комитет ещё не принял решения по этому докладу

Планирование и оценка задач, ретроспектива

Планируй, декомпозируй, выполняй!

Евгений Ртищев

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

Правильно составленные и декомпозированные задачи неоспоримо важны. Хорошо, когда они есть. Но что делать, если их нет?

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



Программный комитет ещё не принял решения по этому докладу

Как искать причины проблем и строить пути их решения. Опыт применения элементов теории ограничения систем в работе тимлида IT

Михаил Румянцев

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Выбор стратегии долгосрочного развития, KPI
,
Бизнес-планы, медиапланирование
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Управление распределенной командой в режиме многопроектности

Сергей Гончарук

Какие проблемы и вызовы возникают при управлении распределенной командой, которая поддерживает более 20 “горячих” проектов одновременно?

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

Инструментальная поддержка, декомпозиция задач
,
Большие проекты/команды
,
Модели руководства
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Работа со сроками как часть инженерной культуры

Николай Крапивный

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

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



Программный комитет ещё не принял решения по этому докладу

Fail Story: как мы внедряли планирование в аутсорс-команде

Алексей Цыкарев

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

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

Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Сказка про репку, или Как рождаются правильные задачи

Антон Костерин

• Как должны появляться задачи, отвечающие интересам заказчика - цепочка от глобальной цели компании до постановки задачи с разбиением на слои. Зоны ответственности и выделение порождаемых артефактов.
• Проблемы и боли teamlead'а и команды разработки в целом при плохой/ не правильной/ не полной постановке задач.
• Критерии корректно поставленной задачи, состав минимально необходимой постановки для достижения успешного результата.
• Инструментарий по работе с задачами:
- валидация;
- техническая декомпозиция;
- линковка задач;
- оценка трудозатрат / технических рисков;
- приоритизация.

Инструментальная поддержка, декомпозиция задач
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
,
Управление / другое
,
Управление изменениями, управление требованиями
,
Общение с заказчиком, извлечение требований
Программный комитет ещё не принял решения по этому докладу

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

Project Team Lead - успеть за 13 месяцев

Анна Шестакова

Как проектному тимлиду по разработке за 13 месяцев (в среднем) проекта внедрения ERP:
- разобраться, что нужно внедрить: оценить объем и спланировать работы;
- набрать команду: какие компетенции требуются и когда. Где найти специалистов и как проводить собеседования;
- управлять командой: процесс, инструменты, риски. Как не бояться удаленных фрилансеров и быть готовым к форсмажорным ситуациям;
- научиться делегировать и не выгореть к концу проекта;
- сделать всё вовремя (ну почти).

Программный комитет ещё не принял решения по этому докладу

Нематериальная мотивация в групповой работе

Татьяна Бахаревская

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

Программный комитет ещё не принял решения по этому докладу

Мотивация, делегирование и автоматизация: рецепт создания суперкоманды

Алексей Катаев

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

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

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

Автоматизация разработки и тестирования
,
Модели руководства
,
Корпоративная культура и мотивация
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Распределённые команды — это не страшно!

Виталий Левченко

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Как работать с джуниорами?

Сергей Попов

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

Поиск и развитие команды
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Удержание сотрудников: опережая оффер от другой компании

Ольга Проходская

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

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

Основные инсайты, которые, я надеюсь, посетят, слушателей:
1. счастливые сотрудники не ищут работу, при этом каждый рецепт счастья уникален;
2. ты определяешь 90% счастья сотрудников: не веришь сам - уходи;
3. мерить счастье, перформанс сотрудников - это просто .

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

Программный комитет ещё не принял решения по этому докладу

Создание и запуск команд. Руководство пользователя

Иван Лукьянов

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

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

Программный комитет ещё не принял решения по этому докладу

Асинхронная работа распределенной команды

Артем Германов

- Работа распределенной по миру команды с непересекающимися рабочими часами.
- Асинхронная работа команды.
- Преимущества и недостатки распределенных команд.
- Полезные инструменты.
- Болевые точки.

Модели руководства
,
Поиск и развитие команды
,
Работа с зарубежным заказчиком/рынком
,
Юридические вопросы
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Эффективная работа с неполнофункциональной командой: интеграция аутстаф-фронтенд-разработки

Иван Утенков

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

Программный комитет ещё не принял решения по этому докладу

Удаленная команда без тотального контроля - как мы нанимали людей и строили процессы

Сергей Марина

Мы в Maxilect уже три года управляем удаленной командой из 40 человек уровня senior и middle. Но вместо "тотальной слежки", которую применяют некоторые компании, мы выстроили все внутренние процессы так, чтобы контролировать результат на уровне качества. Тратим больше времени на оценку задач, но зато можем поручиться за бюджет и сроки (с точностью до недели).

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

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Оценка сложности проекта
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Как быть командой, а не рабочим коллективом

Кирилл Роговой

- В чем разница между рабочим коллективом и командой;
- зачем становится командой;
- почему быть командой – сложно;
- как стать командой;
- как быть с bus factor?

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Как измерить производительность программиста?

Yuliya Kurapatsenkava

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

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

Программный комитет ещё не принял решения по этому докладу

Управление удаленной R&D-командой

Виталий Давыдов

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

Тезисы доклада:
- Почему нанимать людей из разных мест нашей страны — это круто?
- Минимизируем потерю времени в research-процессе для задач машинного обучения.
- Как настроить процесс разработки и кодревью разработчиков и дата-саентистов.
- Как наладить коммуникацию внутри команды?
- Прозрачность работы. Как ее повысить без фанатизма и бюрократии.
- Инструменты удаленной работы. Как все организовать и быть в курсе.

Модели руководства
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Как довести джуниора до мидла и не превратить в говнокодера

Леонид Сущев

Нужна помощь в формулировке (см. тезисы для программного комитета)

Большие проекты/команды
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Почему не нужно искать senior-разработчиков

Владимир Теблоев

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

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

Программный комитет ещё не принял решения по этому докладу

Масштабирование через не могу

Михаил Емельянов

Проект растет, команда растет, кажется, куда больше, зачем? А главное - что с этим делать?

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

Проследим, как менялся весь процесс разработки: от написания и ревью кода, до git flow и автоматизации инструментов. Также рассмотрим, какие изменения потребовались в архитектуре проекта. И как происходит интеграция разработчиков в целую сеть команд.

Code Review
,
Совместная работа, система контроля версий, организация веток
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Архитектура мобильного приложения
Программный комитет ещё не принял решения по этому докладу

Как я нанимал системных аналитиков и как буду это делать в следующий раз

Сергей Нужненко

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Практические приёмы проведения Code Review

Владимир Романько

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

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

Доклад принят в программу конференции

Как жить, когда генеральный директор - басист, или Как собрать идеальную команду, из которой спецы не захотят уходить (… даже домой)

Сергей Спорышев

Девиз нашей компании: "Мы собираем безумных людей и вместе спасаем Интернет". А спасение Интернета, как вы понимаете, – дело круглосуточное. Многие из нас проводят в работе до 18 часов в сутки. Моя задача тимлида - сделать эти часы не только продуктивными, но и комфортными, сытыми и веселыми. И чтобы несколько пар боксерских перчаток для разгрузки, и своя рок-группа для духовной подпитки, и корпоративные мемасики начальников для Telegram, в конце концов…

Отдельно расскажу, где и как мы ищем «безумных». Огромное значение при рекрутинге для нас имеют нетехнические навыки соискателей. Нам важно, чтобы человек был открыт для общения, не боялся ошибок, но умел извлекать и делиться уроками. А чтобы разглядеть интересную личность, с которой потом и в огонь, и в воду, и в деплой ночью с пятницы на субботу – мы часто проводим нестандартные собеседования. Есть музыкальное образование в резюме? - Сыграй нам что-нибудь из Deep Purple. А если сможешь переспорить нашего Исполнительного директора в вопросе антропологического материализма Фейербаха, тогда все наши корпоративные плюшки и чудесные перспективы карьерного роста к твоим услугам.

Большие проекты/команды
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

"Имя им легион". Зачем и как нанимать Junior'ов?

Александр Пряхин

Рынок в IT развит крайне неравномерно. И каждый руководитель команды не раз сталкивался со сложностью найма опытных разработчиков. Однако при этом рынок переполнен начинающими специалистами: студентами, выпускниками курсов, теми, кто сам занялся своим дополнительным образованием. Да, они ещё не могут в Agile и не умеют правильно инвертировать зависимости. Но так ли это плохо? И что из этого можно получить?

Попытаемся разобраться во всех хитросплетениях сознания новичка и аспектов его появления в "стае" матерых программистов.

Программный комитет ещё не принял решения по этому докладу

Строим пирамиду обратной связи в команде

Андрей Степанов

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

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

Code Review
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу

Во имя нового продукта

Евгений Россинский

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

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

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

Доклад принят в программу конференции

Работа с командой: делегирование и мотивация

Management 3.0. Теория и практика в Додо Пицце

Евгений Пешков

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

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

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

Корпоративная культура и мотивация
,
Поиск и развитие команды
Доклад принят в программу конференции

Главное не качество, а количество!

Егор Бугаенко

I truly believe that quality is not what programmers should care about. They must care only about speed—close tasks as soon as possible— which means make money. Won't this attitude ruin the project and turn the code base into a mess? Yes, it will. If the project doesn't care about its quality either. There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications. I wrote about this: http://www.yegor256.com/2018/03/06/speed-vs-quality.html

Программный комитет ещё не принял решения по этому докладу

Как управлять инженерами, если им и без тебя неплохо

Александр Сырков

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

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

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Продуктовая разработка
Программный комитет ещё не принял решения по этому докладу

Метод Пульса - ToolKit для тимлида

Алексей Васильев

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

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

Совместная работа, система контроля версий, организация веток
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Антикризисный менеджмент
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Эскалация справедливости (капитализма)

Алексей Гаранин

Опытный путь решения задач мотивации и справедливой оплаты сотрудников при минимальном контроле собственника/руководителя. Включает в себя:
* учет задач и контроль сроков/трудозатрат;
* контроль качества и объема;
* сдельная схема оплаты;
* мотивация сотрудников;
* приоритизация стратегических задач.

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

В каких случаях процессы и проблемы одной команды отражаются на работе другой и как с этим жить

Сергеевна

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

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

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

Управление / другое
Программный комитет ещё не принял решения по этому докладу