Также мы выяснили, что для техлидов есть много конференций. Но почти все они концентрируются на инструментах, а не на инженерных практиках и процессах. Именно поэтому мы запустили новую конференцию TechLead Conf 2020 Online — для тех, кто хотел бы стать техлидом и разобраться с тем, что такое качество.
На TechLead Conf 2020 Online вторичен вопрос «С помощью какого технического инструмента решалась проблема?». Эта конференция для тех, кто борется за качество технических решений и берёт на себя ответственность за технологическое развитие продукта. С 8 по 10 июня мы изучим опыт внедрения и использования практик, управления технологиями и процессами в компании. Подробнее о программе и о чём будем говорить на мероприятии, расскажем дальше.
Краткая программа
Программа TechLead Conf 2020 Online идёт от обсуждения развития техлида до применения DDD на практике и состоит из нескольких блоков.
- Карта развития техлида. До сих пор мало понимания, кто это такой и чем занимается. А вопросы, как вырасти до техлида и что он должен уметь, задаются ещё реже, поэтому в первом блоке обсудим, кто это такой и как им стать.
- Часть программы отвели взаимодействию бизнеса и разработки. Техлиды работают с технологическими процессами — интегрируют людей с инструментами, чтобы решать бизнес-задачи, поэтому появляется «человеческий фактор». Работу программы можно предсказать, а человека — нет: проснулся в плохом настроении, заболел хомяк или Луна в Козероге. В системах с людьми можно полагаться только на «вероятнее всего это сработает». Поэтому в программе уделим внимание взаимодействию команд, бизнеса и техлида и особенностям внедрения MVP.
- Отложенные эффекты инженерных практик. В работе с кодом обратная связь быстрая: написал, протестировал, задеплоил, работает. Но в мире техлида результат его работы заметен только через месяцы. Поэтому добавили доклады обо всех этапах жизненного цикла инженерных практик: появление идеи, MVP, предотвращение ошибок и измерение результатов после успешного запуска на реальных кейсах.
Также обсудим:
- платформенные команды: когда и для чего нужны, какие проблемы решают;
- как писать хороший код;
- работу с legacy и рефакторинг: как с этим жить и надо ли, как обновить не только код, но и процессы и инфраструктуру на примерах;
- способы управления техническими знаниями внутри компании и DDD.
Расскажем подробнее о каждом блоке и докладах в них.
Карта развития техлида
Техлид — это роль инженера, который управляет процессами. Обычно это инженеры уровня не ниже 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. Встреча открытая, но нужно зарегистрироваться.
ссылка на оригинал статьи https://habr.com/ru/company/oleg-bunin/blog/504232/
Добавить комментарий