Как инженеру вырасти в техлида28.05.2020 16:17

Кто такие тимлид, архитектор или QA и чем они занимаются, в IT представляют себе примерно все. Но с пониманием, кто такой техлид, за что отвечает и как им стать, возникают трудности. Мы провели десятки интервью со специалистами крупных компаний и узнали, что это инженер, который инициирует процессы: связывает людей и инструменты с целями организации. Он берёт инициативу и ответственность за технологическое развитие продукта и радеет за качество технических решений. При этом качество это не только тестирование, а архитектура, дизайн, инженерные практики и эксперименты, работа с техдолгом и техническое совершенствование компании в целом.

wby2y1bmrsdfqflx_xfqk6jdcnw.png

Также мы выяснили, что для техлидов есть много конференций. Но почти все они концентрируются на  инструментах, а не на инженерных практиках и процессах. Именно поэтому мы запустили новую конференцию TechLead Conf 2020 Online — для тех, кто хотел бы стать техлидом и разобраться с тем, что такое качество. 

На TechLead Conf 2020 Online вторичен вопрос «С помощью какого технического инструмента решалась проблема?». Эта конференция для тех, кто борется за качество технических решений и берёт на себя ответственность за технологическое развитие продукта. С 8 по 10 июня мы изучим опыт внедрения и использования практик, управления технологиями и процессами в компании. Подробнее о программе и о чём будем говорить на мероприятии, расскажем дальше.

Краткая программа


Программа TechLead Conf 2020 Online идёт от обсуждения развития техлида до применения DDD на практике и состоит из нескольких блоков.

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


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

Карта развития техлида


Техлид — это роль инженера, который управляет процессами. Обычно это инженеры уровня не ниже senior: разработчики, архитекторы, автоматизаторы, SRE, реже — CTO. Иногда им может быть и тимлид. Но тимлид строит команды, управляет людьми и их развитием.

Техлид строит процессы: принимает технические решения, которые влияют на развитие продукта в условиях неопределённости.

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

Успех компании во многом зависит от наличия сильных специалистов. Чем отличается техлид от других профессий, мы уже описали, а чем отличается хороший техлид от других техлидов, расскажет Владимир Горовой — Data Science Product Manager в Яндекс.Вертикалях. Из доклада «Как стать хорошим техлидом» узнаем, с чего начать свое развитие, какие навыки и качества прокачивать. Владимир поделится богатым опытом участия в создании проектов Яндекс.Путешествия, Яндекс.Недвижимости и Яндекс.Маркета, чтобы проиллюстрировать тезисы выступления.

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

  • Писать код или заниматься стратегией технологического развития продукта и команды?
  • Решать сложные технические задачи самому или делегировать?
  • Как не разорваться между написанием качественного кода и выкатыванием фич?


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

Объединяем бизнес и разработку


Поддерживать высокое качество кода и принимать правильные технические решения — это не вся работа. Ещё приходится постоянно доказывать бизнесу и заказчикам необходимость вкладывать силы и время в архитектурные и технические задачи. Алексей Дерюшкин из Better Life Company знает по опыту, каково это: 15 лет руководства командами и 5 лет опыта консалтинга. В докладе «Как „продать“ технические задачи бизнесу» на примерах из жизни покажет, как вести диалог с бизнесом, чтобы делать классные фичи и не забывать о качестве.

Борьба между бизнесом и разработкой — стандартная проблема в IT-проектах. Часто у бизнеса нет ТЗ, а только «идеи» и просьбы. Это приводит к неправильным решениям, которые приходится исправлять месяцами или поддерживать годами костыльные решения. Как найти баланс между разработкой и бизнесом, поделится Артур Дементьев в докладе «Между двух огней: разработка и бизнес». Артур в IT с  2009 года, на примере историй из практики проиллюстрирует разные подходы к внедрению MVP-фич.

Когда бизнес и разработка договорились — пора приступать к следующему этапу. Теперь у техлида есть несколько месяцев, чтобы внедрить новый продукт. Чаще всего в таких ситуациях создается минимально работающий продукт для проверки гипотез (MVP). Сразу после тестирования, код прототипа выкидывают и пишут приложение «как положено». Но как поступить, когда тестовый запуск прошел успешно, и в «поделке» уже живут настоящие пользователи? Узнаем от Максима Аршинова из доклада «Как запустить MVP и не превратить его в техдолг».

Выбираем и внедряем инженерные практики


Внедрять что-то новое всегда сложно, тот же MVP, ЯП или фреймворк. Новинка может оказаться «сырой» и не оправдать надежд. Как сделать правильный выбор и «Внедрить новую технологию и не растратить все полимеры», расскажет Павел Минеев, тимлид из Рокетбанк.

Для внедрения новинок оптимально использовать подход governance as a code. При данном подходе у всех правил свой жизненный цикл, они подвержены тестированию и ничем не отличаются от обычного программного продукта. Из доклада Александра Токарева «Governance as a code: как соблюдать стандарты разработки и не тормозить доставку фич» узнаем, как применять этот подход: как и что проверять в процессе разработки ПО, как подход позволяет разрабатывать более безопасные и качественные приложения. 

Когда стандарты внедрены, самое время их проверить, например, на чём-то масштабном — создать техноплатформу. МТС — это крупная IT-компания, реализующая проекты от телемедицины до IoT. Каждый новый проект стимулирует спрос на следующие и удешевляет их создание. Это возможно только благодаря внедрению лучших инженерных практик. Но есть и трудности: сотни команд с разными уровнями и процессами, legacy, необходимость «продавать» идеи бизнесу. Как с этим задачами справляются в компании, узнаем из доклада «Что нам стоит создать техноплатформу? Пошаговый гайд от идеи до внедрения». Расскажет о секретах Филипп Бочаров — руководитель проектов по разработке в МТС ИТ.

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

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


Платформенные команды


Вернемся к платформам. Над их разработкой и поддержкой трудятся несколько разных команд. Они отвечают за свои зоны, а ответственных «за всё» нет — возникают «сквозные» боли. Эти проблемы решают платформенные команды: создают инфраструктуру для разработки приложений и их работы на продакшн, помогают работать быстрее и качественнее, отвечают «за всё». Как создать такую команду и применять продуктовое мышление, расскажет руководитель группы разработки платформы goods.ru Дмитрий Вишин в докладе «Платформенные команды — это важно. Почему?»

Создать платформенную команду мало. Нужно суметь её не развалить до того, как платформой начнёт кто-то пользоваться. На этом пути могут повстречаться злобные еноты. Да, именно еноты. Откуда еноты и как они связаны со стабилизацией платформенной команды, узнаем от ведущего разработчика в МТС Елизаветы Голенок из доклада «Платформенная команда и 4 злобных енота».

Доклады дополнит круглый стол «Платформенные команды: польза или вред». Во время круглого стола Филипп Уваров (Spotify) и Андрей Александров (Mafin) обсудят несколько вопросов.

  • Зачем нужны эти команды и нужны ли вообще?
  • Почему стало модно их создавать?
  • Есть ли от них польза или это хайп?
  • Какие проблемы плодятся платформенными командами и где «подстелить соломки», чтоб не повторять типичные проблемы?


Пишем код


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

Первый — «Как писать читаемый код» Григория Петрова, Head of Developer Relations в Evrone. Григорий организует разработку, конференции (Moscow Python Conf++), хакатоны, генералист и нейрофизиолог-любитель. Как следствие, в докладе будет много нейрофизиологии, когнитивной и социальной интуиции. Но главное, что Григорий расскажет откуда берется сложность кода, почему её нельзя убрать и как с ней жить.

Второй — доклад «Баланс противоречий. Выбор лучших практик в коде и в команде» Глеба Лобастова. Глеб — техлид и руководитель команды разработки в OneTwoTrip с опытом в 10 лет. В докладе поделится подходами к написанию «хорошего» кода — понятного и удобного в поддержке, и ответит на несколько вопросов:

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


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

Legacy и рефакторинг


Тему кода, точнее старого кода, продолжим в блоке о legacy и рефакторинге. Многие знакомы со статическим анализом, как с удобным инструментом. Но иногда возникают трудности, например, когда в проекте огромная база legacy-кода. Когда статанализ находит ошибки, что с ними делать? Как соблюсти баланс между правками старых ошибок и отловом новых? Узнаем из доклада «Как исправить сотни ошибок в legacy-коде и не умереть (на примере Unreal Engine 4)» Георгия Грибкова.

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

Любая долгоживущая IT-компания сталкивается с замедлением производственных процессов. Её провоцирует много факторов, например, усложнение технологий и рост числа сотрудников. Это приводит к тому, что затягиваются согласования, ответственность никто не несёт, а системы становятся хрупкими. Лев Гончаров (T-Systems) в докладе «Agreements as Code: как отрефакторить процессы и не сломаться» поделится историями из 14-летнего опыта, которые помогут ускорить инфраструктурные процессы и сделать их явными.

После рефакторинга процессов инфраструктуры можно перейти к её стандартизации. Например, избавиться от «зоопарка» технологий. Как это сделать на примере опыта стандартизации инфраструктуры одного отдельно взятого большого приложения, расскажет Илья Митруков — Infrastructure Manager (Technical Information Security Officer) Технологического Центра Дойче Банка. 

В докладе «Не боги горшки обжигают. Стандартизация инфраструктуры» не будет ничего об апгрейде технологий, инновационных решениях, технологическом «Космосе» или пайплайнах CI/CD. Будет только инфраструктурный быт проектов длиной в пару лет, минимизация затрат и поддержка бизнес-разработки.

От кода, процессов и инфраструктуры перейдем к рефакторингу технологий. Как перевести проект, в который коммитят 70 человек в день, на React и TypeScript, так, чтобы никто не заметил? Спросим у Яндекса, точнее у Евгения Дашкевича, руководителя группы в Яндексе. В докладе «Как переехать на новую технологию, чтобы 70 разработчиков ничего не заметили» Евгений поделится историей перевода и причинами для обновления технического стека в проекте, который рендерит миллионы разных комбинаций поисковых результатов в день.

DDD, Event Storming и управление знаниями


В этом блоке конференции поговорим о проектировании, используя подходы и практики DDD — Domain Driven Design (предметно-ориентированное проектирование). Часто от неё отказываются из-за того, что это методология без чётких указаний, что и как делать. Но в Райффайзенбанке уже 5 лет в различных проектах используют практики DDD для декомпозиции системы на микросервисы, общения с заказчиком и внутри команд и создания приложений, которые не сопротивляются новым требованиям. Как применять подход, какие практики использовать и не допускать ошибок, узнаем из доклада Константина Густова «Как приручить DDD».

В DDD есть много практик. Одна из них — Event Storming. Она облегчает дальнейшую работу в области DDD и проектирования микросервисов. При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, в докладе Сергея Баранова (ScrumTrek) «Моделирование микросервисов с помощью Event Storming».

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

Илья Кашлаков руководит отделом фронтенд-разработки из 50 человек в Яндекс.Деньгах. С таким количеством разработчиков жизненно необходимо делиться знаниями и следить за архитектурой. В докладе «Logic Review — как инструмент принятия сложных технических решений» Илья расскажет об этом инструменте: как придумали Logic Review, какие метрики собирали и как определяли успешность этого процесса. Всё это с примерами проблем, описанием изменений, которые случились в процессе от старта до наших дней.

Для реализации проектов нам понадобится много документации. Чтобы ее хранить используют, например, легковесные языки разметки: Markdown, reStructuredText, Asciidoc. В них легко писать, а файлы удобно хранить в репозитории. На мастер-классе «Чем публиковать Markdown и RST? Обзор современного документационного инструментария» поговорим, как их применять техлидам:

  • Константин Валеев (Ростелеком ИТ) поделится способом создания кастомизированных PDF и HTML из Markdown-исходников;
  • Семён Факторович (documentat.io) расскажет о «швейцарском ноже» Pandoc и как с его помощью победить генерацию DOCX;
  • Николай Волынкин (Plesk) — как генерировать огромные HTML-порталы с помощью Sphinx-doc.


Три спикера поделятся своим опытом и каждый сможет задать им свой вопрос по теме.

TechLead Conf 2020 Online для тех, кто хочет вырасти в техлида


Конференция TechLead Conf 2020 Online для техлидов и тех, кто хочет им стать: инженеров, разработчиков, тимлидов, QA, руководителей разработки. Даже если вы ещё не техлид, приходите на конференцию, соберём для вас инструкцию, как им стать — карту компетенций техлида. 

Вся конференция пройдёт в новом формате — в онлайне. Благодаря этому мы добавили в три дня мероприятия больше контента, чем в оффлайне: больше 30 докладов, lightning talks (короткие доклады с ответами на вопросы), OST для обмена опытом, круглый стол и различные форматы нетворкинга. Для программы подготовили расписание — посмотрите, отметьте понравившиеся доклады или мастер-классы в календаре, чтобы не пропустить.

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

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

29 мая в 18:00 с нашими докладчиками в уютной обстановке проведём сессию с онлайн-вопросами. Обсудим конференцию, идею построить в течении конференции путь развития техлида и maturity model.

После сессии вас ждёт стрим на тему тестирования интеграции с помощью контрактного тестирования. Обсудим цели контрактного тестирования и на что обращать внимание при проверке интеграции. Будет сессия live-кодинга, на котором посмотрим реализацию контрактов с помощью Spring Cloud Contract и Pact. Встреча открытая, но нужно зарегистрироваться.

© Habrahabr.ru