В начале февраля в Москве прошла конференция Teamlead Conf 2018. Событие, можно сказать, знаковое — произошло осознание того, что проблемы твоей должности вполне достойны не только локальных митапов или треков, но и самостоятельной большой конференции. Мы не могли пропустить такое мероприятие, и вчетвером отправились из новосибирского офиса Plesk прямиком в столицу впитывать опыт коллег.
В нашей компании есть традиция: по возвращению с конференции проводить ретроспективу поездки с участниками и заинтересованными коллегами. Обычно мы рассказываем о своих впечатлениях в целом, выбираем доклады, которые мы рекомендуем к просмотру, обсуждаем услышанные идеи и практики, которые хочется применить у себя в компании. Так мы поступили и с TeamLead Conf 2018. Стоит отметить, что все доклады были на высоком уровне. Почти не было таких, которые мы не рекомендовали к просмотру. Вероятно, организаторы конференции сделают подробный обзор докладов, здесь же хотим поделиться общими впечатлениями о конференции и отметить наиболее приглянувшиеся для нас выступления. Сразу скажем, что и остальные доклады на отличном уровне (почти не было таких, которые получили вердикт “не рекомендую к просмотру”). В итоге решили выбрать 3 наиболее понравившихся доклада и сделать их обзор. Темы не должны повторяться, иначе выбор бы остановился на докладе “Управление большой распределенной командой” Алексея Катаева — уж больно он нам всем понравился и был довольно близок по духу решения проблем.
Управление большой распределенной командой
Потрясающий по концентрации информации доклад: Алексей Катаев охватил темы от собеседований до построения эффективных коммуникаций в команде и вовлечённости каждого инженера в разработку продукта, вдогонку предоставил много полезных материалов, которые можно брать и применять у себя. Кстати, некоторое время назад Алексей немного переработал свой доклад и выложил в виде статьи.
У нас в Plesk 2 офиса разработки в Новосибирске и 1 офис в Кёльне. Даже при такой структуре многие советы нам пригодятся. Например, как структурировать общение в Slack, чтобы информировать всех вовлечённых и при этом не спамить половину компании, а также как сделать наши TechTalk’и более эффективными и разнообразными. Я думаю, что доклад будет полезен компаниям, которые активно растут, и с ростом команды им нужно сохранить уровень информированности разработчиков и при этом не потерять время на постоянные разговоры и отвлечения.
В общем, лучше один раз посмотреть (или даже несколько раз пересмотреть) этот доклад, чем пересказывать его. Настоятельно рекомендуем к просмотру и применению.
Оцениваем разработчика на основе объективных данных
Думаю, организаторы неспроста поставили первым докладом второго дня выступление Сергея Семенова и Александра Киселева (первые доклады каждого дня транслировались одновременно в обоих залах).
Собственная эффективность невозможна без применения хороших инструментов. Вместо откровенного пиара собственного стартапа (компания GitLean как раз и занимается разработкой инструментов анализа активности разработчиков) ребята постарались рассказать о том, какие метрики собирать, откуда черпать данные, как строить по ним выводы. Какие-то метрики вполне очевидны, а какие-то в комбинации между собой дают интересные наблюдения.
Доклад цеплял в первую очередь тем, что было множество практических примеров. Ребята говорили, что общались с большим количество компаний, CTO, тимлидами. И охотно веришь им, потому что смотришь на слайды и кажется, что интервью брали у тебя самого: ты так же думал, как добавить объективности субъективным 1:1 и performance review, также писал скрипты, выуживающие данные из git’а и JIRA, а потом пытался анализировать, найти корреляцию и причины просадки производительности или возникновения проблем.
Конечно, не забыли они упомянуть и о том, что метрики — это не панацея и не инструмент поиска виноватых. В первую очередь, это должен быть инструмент поиска проблем в работе команды. Например, какую-то область кода на протяжении длительного времени коммитит лишь один человек (bus factor) или фича оказалась плохо реализована, потому что опрос team morale показал очень низкие оценки.
Но хватит уже спойлить. Всем, у кого команды больше двух-трех человек, смотреть обязательно.
1000 и 1 фидбэк
Финальный доклад конференции оказался, пожалуй, самым эмоционально ярким за все два дня конференции.
Как уже было сказано на другом докладе Александра Зизы “В поисках тимлида: долго, дорого и никаких гарантий!”, то, что для инженеров является софт скиллом (например, коммуникативность, умение давать фидбек), то для менеджера или тимлида является вполне себе хард скиллом, который нужно тренировать и развивать. Данный доклад Евгении как раз про то, как можно и нужно развивать умение давать фидбек. Обратная связь очень важна для сотрудников, и это не только 1:1 встречи.
Чтобы развить какую-то способность, необходимо практиковаться и стараться чаще её применять в повседневной жизни. Евгения в своем докладе рассказывает об организации разговорного клуба в компании. Эта инициатива принесла положительные результаты в развитии навыков публичного выступления с одной стороны, и навыков предоставления качественной обратной связи с другой. Люди регулярно тренировались давать фидбек правильно, а Евгения помогала им в этом процессе.
Доклад рекомендуется всем, кто понимает, что в работе менеджера или тимлида важная часть коммуникации — это фидбек, и кто задумывается о том, как развить в себе способность делать это на качественно новом уровне.
Итоги
Конференция получилась интересной, в первую очередь, благодаря отличному контенту. Надо отдать должное организаторам: собрать нужную аудиторию и нужных докладчиков у них явно получилось.
Было несколько технических моментов, над которыми, нам кажется, нужно поработать: видимость экранов (нижняя треть экрана не была видна дальше 3-4 ряда) и качество связи. Это можно считать небольшими придирками, так как на общее впечатление они не повлияли.
Данную конференцию однозначно хочется отнести к категории, когда возвращаешься на работу и разбираешь по кирпичикам, переосмысливаешь услышанные доклады, готов пробовать новые идеи, экспериментировать и улучшать процессы разработки. Цель “получить опыт и вдохновение” достигнута на 100%.
Автор: SibProgrammer
