Привет!

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

Но нашу команду поджидали две серьезные проблемы.

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

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

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

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

Кто такой техлид в России?

Мы опросили больше 50 человек и вот что поняли:

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

Подробнее о результатах исследования рассказываем в отдельной статье.

Какие головные боли у техлидов?

Эти ребята работают с технологическими процессами — то есть, интегрируют людей с инструментами.

Кадр из фильма Робокоп
Кадр из фильма «Робокоп».

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

Больше неопределенности. Если работу программ в худшем случае можно предсказать по фазам луны, то в системах с людьми можно полагаться только на «вероятнее всего это сработает». Ваша команда тратит слишком много времени на merge кода, и вы считаете, что trunk based-стратегия вам поможет? Да… но это не точно.
Отложенность эффектов. Работая с кодом, мы можем быстро получить обратную связь с помощью тестов. Если они работают дольше десятков секунд — уже больно. Но вы теперь техлид? Добро пожаловать в мир, где результаты вашей работы будут видны в лучшем случае через месяцы.
Сложно масштабировать решения. Даже в пределах одной компании все очень зависит от контекста. Иногда даже не до конца понятно, почему решение взлетело.

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

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

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

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

Что такое TechLead Conf 2020?

TechLead Conf — конференция, полностью посвященная инженерным практикам и процессам. Она для техлидов и про техлидов.

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

Конференция однодневная, но максимально концентрированная с точки зрения контента — планируется более 20 докладов. Будут lightning talks, мы организуем OST для обмена опытом и круглый стол.

А для тех, кому еще сложно выйти из зоны комфорта, сложно начать активно налаживать новые связи — мы организуем различные форматы нетворкинга.

Когда и где будет конференция?

8 июня в Москве (ИнфоПространство).

Кого мы ожидаем на конференции?

техлидов (тимлиды, архитекторы, QA лиды, руководители разработки);
тех, кто хочет вырасти в техлида;
руководителей техлидов (CTO).

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

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

Если хотите поучаствовать в её создании или есть мысли на эту тему, то пишите в Телеграм @subzerov или @stereohorse. Мы будем рады пообщаться :)

О чем поговорим на конференции?

Выбор и внедрение инженерных практик

Мы хотим рассмотреть реальные кейсы применения инженерных практик, максимально абстрагируясь от конкретного инструментария. Например, внедрение TDD как культуры, чтобы команда не плевалась от него через пару месяцев и не разругалась во время насаждаемых парных сессий.
Technical Excellence

В agile-манифесте 1 из 12 принципов гласит: «Continuous attention to technical excellence and good design enhances agility».

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

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

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

Это ребята, которые занимаются «сквозными» болячками команд — делают инфраструктуру для разработки приложений и их работы на проде, помогают им работать быстрее и качественнее. Зачастую их продукт — Whatever As Service. Хранение данных как сервис, CI/CD как сервис и т.п.

Но как создать такую команду? Когда в этом есть смысл? Как им применять продуктовое мышление в своих инфраструктурных задачах?

И ещё темы:

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

Чем эта конференция отличается от TeamLead Conf?

Чтобы ответить на этот вопрос, нужно понять отличие техлида от тимлида. Но иногда эти роли и вовсе объединяются в одном человеке! В чем же отличие?

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

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

Если вам близок наш подход, вы уже нащупали путь построения инженерной культуры или добились того самого «качества» в IT-продуктах — приходите выступать на TechLead Conf. Присылайте заявки до 20 апреля, а мы в программном комитете поможем сфокусировать доклад и доработать выступление.

А если есть кто-то, кого бы вы хотели услышать на конференции, также пишите нам в telegram-группу.

Приходите к нам за знаниями, вдохновением и новыми знакомствами!

Долой техдолг! На TechLead Conf 2020 расскажем как