Привет! Меня зовут Вьет, и больше 10 лет я с любовью пишу код. В прошлом году меня пригласили в программный комитет, в котором большие фанаты качественной разработки делали конференцию QualityConf. Мы верим, что качественная разработка не ограничивается вопросами тестирования, поэтому собрали под одной крышей доклады про различные аспекты качества продуктов. Но нашу команду поджидали две серьезные проблемы. Мы поняли, что нужно лучше узнать нашу аудиторию, поэтому занялись продуктовыми интервью. Мы приходили в гости к разным компаниям и спрашивали — что для вас есть качество? Кто отвечает за качественную архитектуру, дизайн? Кто принимает решение о необходимости внедрения инженерных практик? И главный вопрос — кто отвечает за технологическое совершенствование компании? За культуру работы с техническим долгом, измеримость инженерных экспериментов. Ведь именно это напрямую влияет на качество разработки. Инженерные практики придают уверенности в том, что команда выпускает и будет продолжать выпускать качественный продукт. Мы провели несколько десятков интервью и поняли, что нужно переформатировать конференцию и сузить проблемную область. Во время брейншторма мы дружно решили создать конференцию о том, как управлять технологиями и процессами в компании. Для тех, кто радеет за качество технических решений, берет инициативу и ответственность за технологическое развитие продукта. Для техлидов. Мы опросили больше 50 человек и вот что поняли: Подробнее о результатах исследования рассказываем в отдельной статье. Эти ребята работают с технологическими процессами — то есть, интегрируют людей с инструментами. 
Кадр из фильма «Робокоп». Если добавить живых людей к технологиям, то появляется куча интересных моментов: Можно найти в сети решения подобных проблем? Да. Но как их затащить в свои команды, как понять что получилось успешно? Есть щепотки информации в различных блогах, но в них мало контекста, не хватает истории. Есть книги, но они оставляют за собой вопросы без ответов. Поэтому важно обсуждать вживую и задавать вопросы, спорить и вместе находить новые идеи. Но большинство технических конференций в России — про инструменты, конкретные экосистемы или языки программирования. Инженерным процессам уделяется меньшая часть докладов. Техлидам, дабы оставаться на гребне волны, приходится либо посещать все хоть чем-то релевантные конференции, либо ждать записей в сети. Во втором случае они не смогут обсудить интересующие вопросы с теми, кто сталкивается с такими же проблемами.  Мы решили, что нужно собрать сообщество техлидов и создать площадку для живого поиска новых идей. Нужна самостоятельная конференция. Для нас важен опыт внедрения и использования практик, а не ответ на вопрос «с помощью какого технического инструмента решалась проблема?». Конференция однодневная, но максимально концентрированная с точки зрения контента — планируется более 20 докладов. Будут lightning talks, мы организуем OST для обмена опытом и круглый стол. А для тех, кому еще сложно выйти из зоны комфорта, сложно начать активно налаживать новые связи — мы организуем различные форматы нетворкинга. 8 июня в Москве (ИнфоПространство). Даже если вы еще не техлид, приходите на конференцию, мы соберем для вас инструкцию, как им стать — карту компетенций техлида. Для чего мы хотим ее создать?  Если хотите поучаствовать в её создании или есть мысли на эту тему, то пишите в Телеграм @subzerov или @stereohorse. Мы будем рады пообщаться :) Выбор и внедрение инженерных практик Мы хотим рассмотреть реальные кейсы применения инженерных практик, максимально абстрагируясь от конкретного инструментария. Например, внедрение TDD как культуры, чтобы команда не плевалась от него через пару месяцев и не разругалась во время насаждаемых парных сессий. Technical Excellence В agile-манифесте 1 из 12 принципов гласит: «Continuous attention to technical excellence and good design enhances agility».  Команды, которые используют agile-подходы в разработке, должны уделять постоянное внимание техническому совершенству. Но многие из нас встречают противоположную ситуацию, в которой отсутствие инженерной культуры и накопление технического долга оправдываются использованием agile-подхода. Техническое совершенство заключается именно в том, что вы используете практики, которые позволяют вам ускорять создание продукта.  Поэтому наш программный комитет ищет в первую очередь те темы, которые сейчас являются особенно болезненными для индустрии, а именно: Платформенные команды Это ребята, которые занимаются «сквозными» болячками команд — делают инфраструктуру для разработки приложений и их работы на проде, помогают им работать быстрее и качественнее. Зачастую их продукт — Whatever As Service. Хранение данных как сервис, CI/CD как сервис и т.п.  Но как создать такую команду? Когда в этом есть смысл? Как им применять продуктовое мышление в своих инфраструктурных задачах? И ещё темы: Чтобы ответить на этот вопрос, нужно понять отличие техлида от тимлида. Но иногда эти роли и вовсе объединяются в одном человеке! В чем же отличие? Задача тимлида – это построение команды, управление людьми и их развитием. У техлида задачи другие — принимать технические решения, влияющие на развитие продукта в условиях неопределенности. Поэтому на нашей конференции не будет докладов про управление людьми, про их мотивацию. У нас будут только темы, связанные с управлением технологиями, техническим лидерством и построением инженерных процессов.  А если есть кто-то, кого бы вы хотели услышать на конференции, также пишите нам в telegram-группу. Приходите к нам за знаниями, вдохновением и новыми знакомствами! Passionate developer