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

«У нас особый взгляд на ситуацию с пандемией»  

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

В частности об этом говорит Павел Камнев, директор департамента информационных технологий группы компаний «ЛитРес». 

«У нас особый взгляд на ситуацию с пандемией. Весь «ЛитРес» исторически вырос из аутсорс-разработки. Еще четыре года назад все наши процессы разработки были заточены на разработчиков, которые работали  удаленно. Мы долгое время обходились без тимлидов и компенсировали это тем, что нанимали на работу высоко мотивированных профессионалов. Но учитывая, что мы работали с Perl, мотивированные профессионалы довольно быстро закончились. А нам нужно было расширяться, поэтому в тот момент, когда мы начали ронять планку требований к разработчикам и брать на работу менее компетентных и мотивированных людей, в компании возникла роль тимлида. Но тимлиду проще работать, когда вся его команда находится в офисе. У нас была такая концепция: мы собирали свои команды в офисе, и производительность работы росла. Люди лучше включались в работу, общались», — отмечает он.

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

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

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

В свою очередь Александр Раковский, тимлид, Senior Java разработчик ITentika, автор Youtube-канала про рефакторинг уверен, что некоторым действительно гораздо удобнее работать из дома.

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

С ним согласен Леонид Лифшиц, руководитель направления .Net компании Artezio.

«У нас переход большей части сотрудников на удаленку оказался довольно безболезненным для компании. Мы еще до пандемии практиковали возможность удаленной работы, пусть и частично. И с самого начала, когда разработчик приходит на проект, мы договариваемся с ним о соблюдении определенных правил работы в команде. В частности, что рабочий график всей команды должен совпадать с графиком заказчика. Еще одно важное условие - присутствие на митингах. Мы эти рамки для коллег обозначили еще до пандемии и нашли понимание необходимости таких мер, поскольку мы являемся сервисной компанией. Когда началась пандемия и люди полностью перешли на удаленку, эти же правила и рамки остались, и сотрудники их соблюдают», — говорит Леонид Лифшиц. 

Он приводит данные статистики, когда за первые полгода пандемии производительность труда немного упала, сотрудники, которые любили работать в офисе, лишились социализации. 

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

«Нужно не подгонять разработчиков, нужно мотивировать их работать»  

Эльмин Мамедов, руководитель отдела управления проектами интернет-агентства Future, считает, что в новых условиях нужно не подгонять разработчиков, а мотивировать их работать. Хотя в условиях удаленки это стало сложнее, признается он. 

«Одна из ключевых ролей тимлида - это мотивация команды, чтобы она понимала, куда нужно двигаться. Когда все перешли на удаленку, тимлидам пришлось быстро прокачивать свои soft skills и мотивировать людей дистанционно. Это не так просто, как если бы сотрудники были в одном офисе и можно было даже своим примером показать, как нужно работать. Когда мы только перешли на удаленку, был резкий всплеск продуктивности, когда команда стала работать эффективнее в 1,5 раза. Но через какое-то время все поняли, что дома можно несильно напрягаться и не работать до глубокого вечера, тогда продуктивность работы стала снижаться. И тут мы уже начали работать над тем, чтобы больше мотивировать людей. То есть не просто поставить задачу и отправить сотрудника ее выполнять, а дополнительно мотивировать человека к усердной и ответственной работе. Конечно, многое зависит от людей. Есть ребята, которые сами по себе ответственные и будут работать в любых условиях. Но есть и те, у кого чувство ответственности снижается за пределами офиса», — говорит эксперт.  

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

«Будет ли это Teams, Slack или другой специализированный инструмент - неважно. Но однозначно это должны быть не массовые решения типа Telegram. На самом деле Telegram - это совсем не корпоративный мессенджер, в нем нет сохранения истории, базы знаний компании, нет управления чатами с точки зрения безопасности. С Teams и Slack разработчикам гораздо удобнее работать.  Учитывая, как часто сегодня люди общаются в мессенджерах, выбор инструмента для коммуникации является крайне важным. И у тимлида уходит много сил и времени, чтобы поддерживать единое информационное поле и площадку для общения. Все делается для того, чтобы команда не развалилась, а чувствовала себя собранной и вовлеченной», — рассказывает эксперт. 

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

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

«Задача тимлида — уберечь людей, чтобы они не ушли» 

Говоря об эффективном управлении Тимур Гайфулин, руководитель группы разработки IT-компании DD Planet, акцентирует внимание на том, что угрозами наказания добиться от разработчика ПО положительного результата сложно.

«Хорошая и продуктивная команда строится на принципах открытости и доверия друг к другу, что никто ни за кем следить не будет. А если кто-то и наблюдает за работой, то делает это для того, чтобы подсказать и помочь, а не пожурить. Нужно всегда разбираться в причинах, по которым произошел срыв сроков или возникли трудности на проекте. Причины могут быть разные, и нельзя сказать, что с помощью какого-то механизма наказаний их можно будет нивелировать заранее», — говорит специалист. 

По словам Гайфулина, если человек не справляется, то нужно искать способы адаптации человека в команде. 

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

Илья Куликов, ведущий Backend-разработчик Comindware, против любых систем контроля, которые позволяют фиксировать отработанное время. «Это очень сильно демотивирует людей, заставляет их работать в промежутке времени, а не стремиться к решению задачи и получению результата. И тут нужно понимать, что стремление к достижению результата может стать одной из причин выгорания. Задача тимлида - уберечь от этого людей, чтобы они через месяц активной работы на результат просто не ушли с проекта», — считает Куликов. 

Есть еще и другие, не совсем стандартные методы мотивации разработчиков тимлидом. 

Олег Чирухин, Head of Developer Advocacy в команде Axiom JDK компании «БЕЛЛСОФТ»: «Наши разработчики мотивируются достаточно необычными для индустрии опциями. Например, задачами, которые представляют собой особый уровень хардкорности и на которых разработчикам дается как можно больше личного управления. Другими словами, есть разработчики, которым нравится, когда им поставили тикет в Jira, они его взяли и сделали. В Open Source обычно все наоборот, каждый разработчик является микроменеджером для своей собственной фичи и части продукта. И когда ты даешь дополнительный кусочек проекта, который человек сам может вести, — это хороший бонус и мотиватор. Разработчик постоянно думает в режиме продакт-менеджера».

«А если мы говорим про проекты в Open Source, то фичи и задания для разработчика приходят из комьюнити. Не от непосредственного руководителя, а фактически от заказчика. И тут мотиваторами могут считаться имя в титрах, почет и слава. Например, когда ты коммитишь что-то в Open JDK, то все коммиты подписываются не именем компании, а лично разработчиком. И сообщество знает в первую очередь конкретного автора, а уже потом - в какой компании он работает. Это приятно, и люди привыкают быть самостоятельными и нести ответственность за то, что они делают. Как результат, они делают свою работу хорошо», — дополняет эксперт.

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

«С головы разработчика надо на некоторое время слезть»  

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

Павел Камнев считает, что интеллектуальный труд, которым и является труд разработчика ПО, требует определенного погружения и настроя. Периодически нужно отключиться от задачи, переключиться на какую-то другую, дать задаче отлежаться и т.д. Это подразумевает определенную свободу личного графика. 

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

«Тимлид обязательно должен быть вовлечен в code review»  

Одна из обязанностей тимлида — code review. Участники дискуссии сошлись во мнении, что это важная и даже ключевая роль лидера команды. 

Code review нужен для того, чтобы контролировать развитие начинающих и среднего уровня разработчиков, считает Леонид Лифшиц, руководитель направления .Net Artezio.

«Никто не проводит code Review у senior специалистов, им по умолчанию компания доверяет написание кода. Поэтому code Review — это способ не контроля, а помощи в развитии навыков разработки у начинающих специалистов. Code Review занимаются опытные разработчики, которые выполняют роль наставников, помогают понять философию продукта и стиль разработки», — отмечает он.  

Тимлид обязательно должен быть вовлечен в code review, рассказывает Павел Камнев.  

«Ведь код — это то, ради чего разработчики приходят на работу. Да, разработка — это творчество, но правила написания кода никто не отменял. И одну и ту же задачу можно решить разными способами. Разработчиков как раз мотивирует поиск лучшего решения. Поэтому нельзя отказывать людям в удовольствии обсуждать задачи и различные варианты их решения. В случае с senior использовать code review как инструмент обучения вполне возможно. Ведь все люди разные, у всех разный взгляд на вещи, контекст и стилистику. Есть даже такое выражение “обстучать идею о другого человека”. Когда специалисты уровня senior проводят code review друг для друга, повышается качество разработки. Это как раз тот самый “золотой” творческий процесс, во время которого возникает наиболее эффективный, талантливый и долгоиграющий код. Кроме того, я сторонник баланса, поэтому должен быть кто-то, кто будет проверять проверяющего. Ведь все мы живые люди, и у нас есть желание где-то проскочить, срезать угол. Но когда ты точно знаешь, что твой код будут проверять, это лишний раз будет повышать самодисциплину. Поэтому если есть такая возможность, то senior должны проверять senior», — говорит эксперт.

По словам Ильи Куликова, ведущий Backend-разработчик Comindware, если человек, чьи pull request ты оцениваешь, достаточно опытный, то ошибки можно сильно не расписывать.

«Достаточно будет показать, где разработчик что-то забыл или не продумал. А если сотрудник совсем неопытный, то нужно достаточно подробно описывать, что пошло не так. И в этом случае code review можно использовать как инструмент для обучения. Сказать, мол, давай отойдем на шаг назад, и приходить к решению задачи постепенно. И я бы не стал говорить, что code review применим только к новичкам. Проверять код можно и сотрудников уровня senior, особенно если у компании есть для этого ресурсы. Это пойдет любому проекту только на пользу», - говорит он.  

«Чтобы стать тимлидом, нужно начинать вести себя как тимлид»

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

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

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

«У нас в практике не было того, чтобы на роль тимлида приходил чистый управленец», — рассказывает Леонид Лифшиц, руководитель направления .Net Artezio.

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

«Проблемы могут быть, если в команде две альфы»  

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

Павел Камнев считает, что проблемы могут возникнуть, если в команде две альфы.

«Если у нас складывается ситуация, когда в команде появляется сильный технический специалист наряду с существующим тимлидом, то это идеально. Как правило, все уверены в профессионализме senior специалиста, и тимлид ходит к нему советоваться по архитектурным решениям. И тимлиду комфортно: он знает, что всегда подстрахован. Проблемы могут быть, если в команде две альфы. Когда оба специалиста хотят стать тимлидами, вот тогда их нужно разводить. Ещё нужно помнить: если у вас тимлид не позволяет, чтобы в команде вырастали технические специалисты сильнее его и блокирует это развитие, то это плохой тимлид», — отмечает он. 

«У тимлида есть гарантия, что те решения, которые он принимает, будут проходить валидацию внутри команды. Причем эта валидация будет проводиться экспертом, который сильнее его. В свою очередь, эксперт получает позицию, к которой он стремился, но при этом он несильно связан работой с людьми в отличие от тимлида. Он принимает свои экспертные решения, может что-то советовать или браковать. И не нужно думать, что специалист в какой-то момент вырастет и выбросит тимлида из команды. Мы говорим про разные ветки развития в команде. Одна ветка — про то, как налаживать работу в команде, решать организационные вопросы. Другая — сугубо техническая и экспертная. Эти ветки друг другу не противоречат. Места для конфликта в команде между техническим специалистом высокого уровня и тимлидом нет, если только они не претендуют на одну должность. Если каждый находится на том месте, на котором он хочет находиться, и движется в свою сторону, то все развивается в позитивном ключе», — отмечает Илья Куликов, ведущий Backend-разработчик Comindware. 

Согласны ли вы с мнением экспертов? Напишите нам, изменилась ли роль тимлида в вашей компании и с какими трудностями вы столкнулись. А еще мы бы очень хотели узнать ваши рекомендации о том, как стать тимлидом. Напишите их в комментариях под видео на Youtube. Как быстро пройти путь от идеи до успешного бизнеса? Поделитесь своим мнением в комментариях. 

Полную запись разговора экспертов, включая практические советы и ответы на вопросы зрителей, можно посмотреть на Youtube.

А ещё мы в постоянном поиске талантливых разработчиков. Актуальные вакансии можно посмотреть тут. Приглашаем в нашу команду.