24 и 25 сентября,
Санкт-Петербург

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

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

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

Инженерный Буткамп и суперспособности новых разработчиков

Игорь Луканин

Число разработчиков и команд в нашей компании ежегодно растёт на 20 %. Сейчас это 70 команд и больше 1000 человек. Два года назад наши «обычные» процессы подбора, найма и адаптации новых разработчиков забуксовали и перестали работать. Мы провели серьёзный рефакторинг и запустили инженерный Буткамп. Теперь у новых разработчиков есть суперспособность выбирать для работы любую команду, однако это только самое заметное изменение.

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

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

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

Коммуникации как performance-зона работы тимлида

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

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

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

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

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

Как организовывать Knowledge Sharing внутрь и наружу

Евгения Голева

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

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

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

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

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

Алексей Шаграев

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

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

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

Энергия и Лидер

Анна Обухова

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

В современном мире принята концепция Servant Leader или Powerless Leader, когда в общем слова менеджер или лид вообще нет, а работать-то надо.

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

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

Работа в команде или как быть максимально эффективной боевой единицей

Наталья Ёркина

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

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

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

# Инструменты управления большой командой

Дмитрий Безуглый

Создание команды - далеко не простая задача. Размер "естественной" команды 7+/- 2 человека. Создание и управление командой, в которой больше 30 человек - это управленческий и лидерский вызов. Перед каждым руководителем стоит задача: 
* достичь целей (удовлетворить стейкхолдеров),
* сохранить и развить команду (создать условия для продуктивной работы),
* выжить .

Для решения этой задачи посмотрим на коллектив с точки зрения методов развития и управления командой. Системный подход к организации работы команды Хокинса включает пять областей командной компетенции:
* Управление целями и исполнением. Каждая группа и команда внутри коллектива достигает своих целей и задач, и регулярно возникает вопрос: "Зачем что-то делать для других?". "С нашей стороны пули вылетели..." и т.д.
* Отношения и коммуникация. Что значит выстроить доверие между командами? Руководители часто сталкиваются с проблемой того, что руководители команд - не команда. И каждое столкновение интересов приходится "разруливать" вручную. 
* Внутренние процессы. Коллективы решают задачи разного типа и определить один workflow для всех видов задач сложно. Хорошо, когда 9 женщин должны родить 9 младенцев, а если нет? В докладе рассмотрим, как использовать три модели взаимодействия команд.
* Внешние процессы и среда. В больших коллективах политические процессы сложны и часто на работу с коллективом времени катастрофически не хватает. Чем может помочь команда руководителю? 
* Обучение. Процесс самообучения команды еще можно представить как сумму накопленных индивидуальных знаний, но для коллектива само по себе это уже не работает. Наличие знаний не гарантирует их применения. Мы рассмотрим три аспекта - работу с хард- и софт-навыками и компетенциями и развитие команд.

Системные инструменты, которые помогают решить эту задачу:
* Карта территории. Диагностика культуры и командных процессов.
* Формирование штаба.
* Ваша команда внутри коллектива.
* Управление групповой динамикой на уровне команды руководителей.
* Менеджмент и лидерство. Смешать, но не перемешивать.
* Обучение и развитие 
* Hard skills - алмазы получаются под давлением. Жизненный Цикл сотрудника.
* Soft skills - поддержка руководителей, создание среды и развитие команд.

Обязательно оставим время на обсуждение вопросов.

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

Рост команды на порядок или как не сойти с ума будучи frontend тимлидом в привлечении Тинькофф Банка

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

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

Я расскажу как менялись процессы разработки, а также роль и задачи тимлида по мере роста беклога, размера команды и в зависимости от стиля взаимодействии с внешними заказчиками:
- много заказчиков, а тимлид один
- много заказчиков, тимлид один, но на входе в команду стоит project manager
- есть отдельные product owner'ы для важных бизнес-линеек, тимлид один, но их нужно больше:)
- много продуктов, много product owner'ов, есть отдельные команды и тимлиды в них
- появление релиз-менеджеров в командах, которые поддерживают процессы и появление общего процесса улучшения процессов разработки в командах

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

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

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

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

Why we should care about diversity and inclusion in tech?

Yuliya Kurapatsenkava

I would like to cover examples of how diversity changed the way Spotify is driving its product. I will show how by changing the approach to diversity and inclusion teams can change the way they work. I will cover some practical steps of what has been done in Spotify to address diversity and inclusion issues and what benefits it gave the company, local committees and countries where the company is represented.

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

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

Как вырасти из разработчика в тимлида и жить с этим дальше

Екатерина Евтухова

Тимлидами не рождаются — тимлидами становятся.

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

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

Этап первый: проявляем задатки тимлида, или все начинается с самоменеджмента.
1) Проявляй самостоятельность.
2) Помогай.
3) Анализируй.

Этап второй: я стала тимлидом. Что же дальше?
4) Терпение, терпение и еще раз терпение.
5) Тотальная честность.
6) Делегируй.
7) Экспериментируй.
8) Обучайся.
9) “Мы подумали, и я решила” (с).

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

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

Додоверие. Ценности и принципы в компании Додо Пицца

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

Есть ли жизнь без тимлидов, проджект-менеджеров и жесткого давления? Конечно!
Один из принципов agile-манифеста гласит: "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им".

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

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

О вреде ярлыков с компетенциями

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

* Синдром мёртвой команды, или как категоризация людей по их компетенциям и развешивание ярлыков убивают команду.
* Отсутствие ярлыков с компетенциями не означает отсутствие специализации.
* Как создать среду для естественной или "органической" специализации и развития команды.
* Чем сильна команда с органической специализацией.

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

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

Фабрика по выпеканию кода

Кирилл Ветчинкин

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

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

В докладе мы поговорим о процессах в заказной разработке: методиках оценки приоектов, минимизации рисков на старте проекта, организации процессов разработки, как удалось подружить Kanban и "Scrum" и выстроить поток от идеи до реализации, где в этом процессе архитектор, DevOps, где и как можно сократить стоимость.

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

Школа программистов как решение проблемы найма

Лев Екасов

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

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

Рассмотрим, как и чему мы учим в школе, кто ведёт занятия, что вообще делают в школе и после её окончания.

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

Накапливание знаний в команде

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

Светлана Новикова
Константин Кафтан

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

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

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

Мы расскажем о том, как применили две модели, две различные техники создания матрицы компетенций (hard-skills matrix или competency matrix) и привязали к ним процесс обучения и управления знаниями, управления ресурсами внутри команды: knowledge sharing sessions, тренинги, обучения, тесты на понимание, чек-листы и другое, о том, какой, вообще, от этого профит бизнесу и как его обосновать. Нам это позволило понять точки роста сотрудников и в качестве success story добиться для них смены позиции или расширения набора навыков.

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

Доклад будет представлен на опыте отделов разработки и технической поддержки компании Iponweb, мы работаем по модели SaaS, у нас порядка 50 проектов, которые используют один стек и компоненты (http-server, predict machine, reporting), но имеют разную кодовую базу для бизнес-логики. Для нашей компании период включения нового сотрудника в проект сократился с 4-5 до 2-3 месяцев, мы сформировали план обучения и документирования, добавили разнообразные методы управления знаниями и полностью обновили адаптационный план для новых разработчиков.

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

Как вырастить фичакоманду за 3 месяца

Антон Бевзюк

3 месяца назад моя команда CodeMonkeys работала только над одним компонентом DodoIS - кассой ресторана, в основном на C#.

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

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

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

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

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

Максим Бабич

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

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

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

Как собирать метрики и стоит ли на них полагаться

Макс Богуславский

Свой доклад я основываю более чем на 5-летнем опыте руководства и взаимодействия с командами разработки (разных размеров и конфигураций).

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

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

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

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

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

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

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

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

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

Мотивация команды через майнинг игровой валюты

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

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

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

Часто перед нами встают вопросы и проблемы:
1) Кого повышать? Заслуживает ли человек повышения?
2) Какой вклад этот человек делает в развитие продукта?
3) Каков вклад этого человека по отношению к другим членам команды?
4) Как правильно контролировать и учитывать экстренные задачи в общей эффективности?
5) Как контролировать и поддерживать своё внимание к каждому члену команды?
6) Как не забыть чьих-то заслуг или проколов?
7) Как ввести что-то новое, чтобы усилить интерес и вовлеченность коллег?
8) Как настроить команду на соревновательный дух, который идёт на благо продукта?
9) Как мотивировать команду через систему понятных наград и возможностей?

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

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

Оцениваем процессы в команде разработки на основе объективных данных

Сергей Семенов

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

В прошлом нашем докладе на Teamlead conf “Оцениваем разработчиков на основе объективных данных” мы рассказывали, как можно подойти к вопросу измерения работы отдельного разработчика. Теперь мы собираемся поговорить уже не об отдельных разработчиках, а о командах разработки и расскажем, как оценивать эффективность процессов, которые вы заводите в своих командах. Также немного поговорим про теорию ограничения систем и как ее применять для изменения процессов разработки.

Обсудим следующие вещи:
* Немного повторим тезисы предыдущего доклада:
** Где брать данные для метрик? github/gitlab/bitbucket, таск-трекеры, мессенджеры.
** Почему нет одной единственной хорошей метрики.
** Подход от проблем.

* Поговорим про конкретные процессы в команде и метрики, нужные для их измерения:
** Метрики для процесса планирования.
** Метрики для процесса имплементации в коде.
** Метрики для процесса код-ревью.
** Метрики для процесса тестирования.

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

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

Управление договоренностями

Стас Михальский

"Договорились и сделали!" Да? Ага, как же...
Сколько раз, получив от сотрудника положительный ответ или даже клятвенное заверение, что "все будет пучком", мы в итоге получали противоположный результат?

А сколько раз за "Да, хорошо" нам четко слышалось "Только отстань, все равно завтра уже и сам забудешь"?
Вот и выходит что договорились, да не договорились...

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

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

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

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

Фантастические тимлиды и где они обитают

Анатолий Панов

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

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

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

Organisational Structure in Spotify

Yuliya Kurapatsenkava

In this talk I would like to cover the organisational structure of Spotify. What is the line between giving more autonomy to the squads while expecting accountability from them? I will cover how the organisational model of Spotify transformed over time experiencing a hyper-growth phase in terms of hiring and scaling of the product and maintaining the company culture. I will describe the leadership model of teams and how we transformed from the approach of Chapter Leads to Engineering managers.

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

Посев, выращивание и уход за тимлидами. Советы практикующего тимлидовода.

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

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

Честно, я не знаю... универсального решения:)

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

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

Об этом в моем докладе. Приходите, будет интересно;)

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

Роль тимлида в рекрутинге

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

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

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

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

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

Tinkoff.ru: Фабрика супергероев

Андрей Тимонич

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

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

В Tinkoff.ru мы умеем и любим централизованно находить молодые таланты, обучать их и брать в штат. Но задача адаптации их к реальной работе ложится на плечи непосредственных руководителей и тилидов. Доклад основан на 2-летнем опыте руководства одним из IT-отделов Tinkoff.ru, выросшим за это время в 4 раза за счет прихода молодых и талантливых, но не всегда опытных людей.

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

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

Как оценить эффективность команды

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

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

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

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

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

Один в поле не воин. Путь до эффективной командной работы

Евгений Федореев

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

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

Как управлять распределённой командой начинающих специалистов?

Сергей Попов

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

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

Совместная работа дизайнеров и верстальщиков
,
Code Review
,
Совместная работа, система контроля версий, организация веток
,
Большие проекты/команды
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
Доклад принят в программу конференции

Управление командой на основе ценностей (value-based team management)

Марина Пайч

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

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

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

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

MVP тимлида: что делать, когда они очень нужны, а их нет

Виктор Никишин

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

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

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

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

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

Не сбавляя темпов роста. Как мы переходили от функциональных команд к продуктовым

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

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

Расскажу, как мы переходили от функциональной структуры к кросс-функциональной (aka продуктовой), как повышали автономность команд, как снижали Time To Market, с какими проблемами столкнулись, и что из всего этого получилось.

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Продуктовая разработка
Доклад принят в программу конференции

Круглый стол "Как измерить программиста?"

Георгий Могелашвили

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

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

Техническая ипотека: что и кому должен тимлид

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

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

Должен всем и каждому.

После полутора лет работы тимлидом в Lamoda я хотел бы рассказать о том, как я справляюсь со всеми этими задачами, и какие подходы показали себя лучше всего.

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

Пережить изменения с командой

Станислав Беляев

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

Эти изменения не так просты, как может казаться на старте. И кажется что это все изменится быстро.

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

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

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

Практический воркшоп по созданию договоренностей в Scrum-команде

Александра Баптизманская
Евгения Чумачкова

Многие команды пытаются работать по Scrum, но обещанной Agile-экспертами магии не случается. Зато порой случаются конфликты, зафейленые спринты и недовольство. Почему так происходит?
“Scrum is: Lightweight; Simple to understand; Difficult to master”(с) Scrum Guide
В Scrum-гайде сказано, что несмотря на простоту, Scrum-ом непросто овладеть. И опыт полностью это подтверждает. В гайде описаны роли, мероприятия и артефакты, но не написано, как правильно организовать работу.
На нашем практическом воркшопе, вы научитесь одному важному практическому навыку. А именно - как в рамках Scrum-фреймворка создать в команде рабочие договоренности, которые заставят Scrum действительно работать.

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

Как создать эффективную команду проектных менеджеров

Константин Шубин

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

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

3. Фидбэк подчиненным каждый день!
Встречи 1:1 дали крепкий фундамент для улучшений, пора давать регулярную обратную связь.
- Покажу на примерах, как давать фидбэк, в каких случаях и как часто (спойлер: подход "раз в полгода" не работает).
- Отмечу, что любой фидбэк (положительный или запрос на изменения) направлен на позитивные изменения в будущем.
- Расскажу, что делать, если фидбэк не работает, и изменений нет.

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

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

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

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

Взрывной рост производительности

Александр Павлють

Завязывайте уже с Эджайлом, куда ни глянешь - сплошной стыд и Скрам.

Вступление

В основе создания (воплощения) любой идеи - от зубочистки до космического корабля - лежит объектная сложность (от слова сложение).

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

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

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

Основы

Окружение важнее и первичнее целевого замысла.

Всегда будет проект — потом на основании него действие.

Замысел начинается с онтологии.

То, что не записано — не реализуемо.

Факты — только те действия, что приносят экономическую выгоду.

Основа экономики — система организации труда (действий).

Экономический смысл — основа и проверка всего на пригодность.

Деятельность — это в первую очередь информация о деятельности.

Любая вещь создается не из материалов, а из деятельности по созданию этой вещи.

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

Технологическое разделения труда — единственный источник богатства.

Система разделения труда — цепочка отнормированных операций, проверяемая и предъявляемая.

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

Инновация в систему разделения труда — единственный способ создания новой системы разделения труда.

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

Практикум

- Еще раз общая онтология.
- Никто не умеет SMART цель, потому что (онтология):
- Намерение.
- Проект (как контракт) на Продукт. (Проект vs Продукт).
- <strike>Job To Be Done</strike> => WPTBP!
- Архитектура (КОНКРЕТИКА).
- Компоненты.
- Модули (вещество).
- Размещения.
- Все это РАБОТЫ во времени.
- Ответственность и бирюзовое лидерство.
- Краткий пересказ СМД - перформер и его изменения.
- Что будет дальше с ТимЛидами.
- Что им делать.

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

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

Тимур Павлов

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

Мы проанализировали проблемы, которые возникают при работе с продашн-багами. Учитывая эти проблемы, стали планировать и управлять трудозатратами на исправление дефектов. Изменили workflow работы и ввели новые роли в командах. В результате создали систему, которая навела порядок в работе с багами. Теперь, если мы срываем релизы, то баги продакшна тут не причем :)

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

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

Использование багов для совершенствования процессов разработки и тестирования

Тимур Павлов

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

Мы изменили процесс работы с дефектами в нашем продукте. И это стало основой системы самосовершенствования процесса разработки и тестирования.

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

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

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

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

“Сообразим на троих?” или мини-команды как наш путь масштабирования разработки

Артём Назыров

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

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

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

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

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

Эволюция разработки в международном digital-агентстве

Андрей Степанов
Антон Пермяков

Сейчас мы digital-агентство с офисами в Лондоне, Лидсе и Челябинске, которое работает с крупными мировыми брендами. Но так было не всегда.

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

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

Что мы (теперь) знаем об эффективности разработки

Павел Егоров

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

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

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

Как каждые 4 месяца выпускать 7 связанных продуктов и не поубивать друг друга

Сергей Кукс

За 15 лет .NET отдел в JetBrains вырос из одного продукта-расширения для Visual Studio 2003 в более полудюжины продуктов, которые разрабатывают более 90 человек. Эти продукты запускаются на разных операционных системах, интегрируются в 5 разных версий студии, имеют общие части и тесно взаимодействуют друг с другом. Релизный цикл также изменился от feature-driven релизов примерно раз в год до регулярных date-driven релизов каждые четыре месяца, не считая багфиксов.

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

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

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