1. Команда начинается с Team Lead (один в поле - воин).
2. Набор команды, поиск, собеседования. Брать умных, исполнительных или всех подряд :)
3. Управляемый хаос. Когда можно забить на процессы, а когда нужно стать диктатором.
4. Инструментарий, автоматизация рутины, индикаторы, KPI, тестирование, развертывание.
5. Правая рука системного архитектора, левая начальника отдела. Почему важно быть везде или минус 50000 евро за 4 часа.
6. Вперед, орлы, а я за вами! Обучение и психологический климат команды.
7. На чем стоИт Team Lead. В чем сила, брат? :)

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

Уважение и признание делают инженера ведущим.

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

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

Представьте, мы сделали большой и сложный проект с большим количеством участников. Такие проекты редко проходят без накладок. Особенно, если это происходит на фоне сжатых сроков. Неважно, что послужило причиной этих сроков: неожиданно наступивший конец декабря с feature freeze, объективная необходимость выпустить продукт быстрее конкурента или что-то другое. Результат, как правило, один – участники вымотаны проектом, раздражены и готовы высказать коллегам “пару ласковых слов”.

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

Уверен, правильный ответ – “Нет, проводить ретроспективу нужно”. Но нужно сделать это правильно, минимизируя ущерб и максимизируя пользу.

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

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

Компания Booking.com существует уже больше 20 лет. За это время она выросла от небольшого голландского стартапа до крупной международной корпорации - лидера на рынке онлайн-бронирования путешествий с офисами по всему миру.

За последние несколько лет Booking.com увеличил количество сотрудников в IT-департаменте. И это повлекло за собой изменения в роли тимлида. Мы прошли путь от причастности тимлида к ограниченному кругу людей ("касте"), частичного отказа от лидов на какое-то время в пользу автономных команд, и до их возвращения под новой концепцией "Servant Leader". В ходе этой трансформации у нас накопилось много полезного опыта, которым я с удовольствием с вами поделюсь.

В своём докладе я расскажу, как мы адаптировались к взрывному росту числа сотрудников в IT и с какими проблемами столкнулись, о роли тимлида в этом процессе, об эволюции этой роли за последнее время, что она значит сейчас, а также как устроен IT-менеджмент в Booking.com в целом.

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

Тимлидов на всех не хватает!

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

Исследуем, что можно сделать, чтобы восполнить дефицит компетентных тимлидов в команде.

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

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

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

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

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

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

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

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

Но когда разговор заходит о разработчиках, никто не знает, на какие характеристики смотреть, чтобы измерить их эффективность.

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

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

Разберем конкретные проблемы и найдем под них метрики.
* Индивидуальные:
1. Разработчик часто застревает на задаче.
2. Разработчик плохо прорабатывает задачи до начала разработки.
3. Разработчик-перфекционист.
4. Разработчика постоянно отвлекают.
5. Разработчик демотивирован.
6. Разработчик перегружен.
7. У разработчика нет фокуса на своевременный выпуск задач.
8. Неточные оценки задач.

* Командные:
1. Неравномерное распределение знания кодовой базы.
2. Катимся в пучину технического долга.
3. Текучка разработчиков.
4. Неточные продуктовые требования.
5. Плохой онбординг.
6. Конфликты на код-ревью.

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

Маленький пример: в формате user story "как <роль> я хочу <сделать что-то> для того чтобы <достичь целей>" часть с целью появилась не сразу. Она нужна, чтобы разработчик мог поставить себя на место пользователя, если в процессе реализации надо выбрать между несколькими альтернативами. Казалось бы, можно спросить, однако прерывание разработки – дорого, и разработчики часто додумывают за пользователя, и часто ошибались. Указание цели пользователя позволяет уменьшить число неверных решений. Кстати, сам формат появился при переходе к итеративной разработке как средство обеспечить инкрементальную поставку ценного продукта.

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

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

Управление знаниями имеет еще один аспект, который находится за рамками проекта - обмен профессиональными знаниями между специалистами разных проектов. Здесь я рассчитываю поделиться практиками и кейсами, знакомыми мне из участия в сообществе Knowledge Management Russia, в конференциях которого я принимаю участие с 2010 года (отзывы на моем сайте http://mtsepkov.org/KM).

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

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

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

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

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

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

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

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

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

Я стал тимлидом 3 года назад. Я совершенно не понимал, что мне нужно делать, и каков теперь мой круг обязанностей. Мне стало понятно, что мне нужно развивать свою команду и расширять ее. Пришлось работать с наймом сотрудников. В процессе найма я столкнулся с тем, что люди ленивые, и не все готовы работать и соблюдать процессы хорошей разработки ПО. Писать тесты, настраивать CI, планировать спринты и укладываться в срок, доводя дела до конца. Пришлось исправлять эти проблемы. Также, ввиду большой конкуренции с рынками РФ и Беларуси, и в связи с большим оттоком кадров, я решил открыть стажировку, на которой люди бы обучались базовым вещам совершенно с нуля.

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

1. Виды позитивной и отрицательной мотивации. На ком что лучше работает.
2. Что было испробовано за 3 года и что зарекомендовало себя с хорошей стороны в нашем случае.
3. Какие личные качества человека мне важны.
4. Что важнее? Софт-скиллы или хард-скиллы?
5. Статистика по итогам трех лет.

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

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

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

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

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

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

Вот ты и стал тимлидом! Минуты ликования от признания твоих заслуг прошли, и наступает рутина.

Становясь тимлидом, многие по-новому начинают видеть свою команду, и неизбежным этапом в какой-то момент наступают первые разочарования. Я, как HR, очень часто слышу, что «команда «бесит», они ничего не делают, я за них разгребаю косяки, прикрываю, а они меня подводят. Еще и стали скрывать, что думают на самом деле…». Как итог – происходит сбой в коммуникации, съезжает процесс, эмоциональные сложности в общении и выгорание.

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

"1000 и 1 фидбэк" или "Как внедрить практику позитивного и конструктивного фидбэка в высококритичную среду разработчиков".

Зачем нужен этот навык? Что ломается в компании, когда навыка нет, и сколько это стоит? Почему эффект от тренингов стремится к нулю? Эти вопросы затронем, но нет, я не буду продавать саму идею фидбэка. Если пришли, значит, уже наболело, для вас очевидна ценность и важность этого скила у тимлидов. Доклад точно не тренинг по тому, как давать фидбэк. Основные принципы буду напоминать.

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

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

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

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

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

В своем докладе я затрону следующие темы:
• найм в распределенную команду (поиск, собеседование, испытательный срок);
• создание команды, а не n людей, работающих над одним продуктом;
• обмен опытом, обучение;
• построение эффективных и приятных коммуникаций;
• мотивация, контроль, прозрачность;
• совсем немного об инфраструктуре / QA / инструментах.

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

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

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

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

В командах разработки численностью больше 100 человек все чаще применяется вариант скрама с использованием Value Stream(ов). Для увеличения скорости разработки по конкретным продуктовым фичам создаются кроссфункциональные команды, в которых участвуют специалисты разных компетенций.

В ivi в одной команде встречаются люди со знаниями Swift, Java, Java Script, Go, QA. Представьте, что несколько, скажем, iOS-разработчиков сидят в разных командах в разных комнатах, пилят разные фичи, но в рамках одного приложения, и только тимлид гильдии iOS-разработчиков может не допустить анархии и хаоса в коде.