Григорий Петров: Страшный зверь Team Lead

Как я и обещал в предыдущей колонке, сегодня я поделюсь с вами своим видением того, что делает Team Lead в проекте и попробую рассказать что-нибудь полезное. Еще раз предупрежу, что все изложенное ниже — мое личное мнение, собранное по крупицам из моего опыта как full time работы, так и частных консультаций. Многое спорно, и я с удовольствием пообщаюсь с вами как в комментариях, так и в Facebook.

Первоначально я хотел написать эту статью намного позже в цикле, предварительно рассказав много всего странного про психологические, физиологические и социальные аспекты работы в команде. Но прикинув, сколько всего интересного можно рассказать про командную работу, я пришел к выводу? что в таком случае статья про тим лида получится страниц на двадцать. А Wall of Text — совсем не мой стиль, поэтому было принято решение разбить эту интересную тему на несколько статей. В этой статье я расскажу в общих чертах про роль тим лида и его миссию в борьбе со сложностью. А в следующем году отдельно допишу про нюансы работы с людьми, отслеживание выгорания и прочие интересные, но неочевидные штуки.

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

Одна голова хорошо, а две — мутация

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

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

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

Чукча не писатель, чукча — читатель

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

Как вы, наверное, уже догадались, я придерживаюсь немного другой точки зрения. Team Lead, безусловно, должен уметь писать код. Но ни в коем случае не должен этого делать на основных проектах компании. Более того — он не должен говорить разработчикам как этот код писать. Только читать код каждое утро и плакать. Вот такая интересная позиция, и сейчас я ее попробую аргументировать.

Вспомним основные проблемы разработки в изложении для команды:

• разработке мешает сложность;
• код — отражение мыслей автора, он у всех немного разный;
• со сложностью борются декомпозицией и фреймворками;
• отражая ход своих мыслей, каждый программист делает декомпозицию по-разному, и пытается изобрести собственный фреймворк.

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

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

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

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

Мне нравится фраза: «тим лид программирует, но не с помощью языка программирования, а с помощью своей команды».

Team Lead и Управление рисками

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

Чтобы в середине проекта не обнаружить фатальный изъян в выбранных технологиях или написанном коде, тим лиду важно в самом начале работы выявить наиболее рискованные части проекта. Обычно риск связан с теми областями разработки, в работе с которыми у команды меньше всего опыта: будь это операционная система, фреймворк или специфическое требование вроде сотни тысяч одновременных пользователей. Выявив эти узкие места, тим лид обычно поручает разработчикам провести ряд простейших экспериментов и тестов, которые покажут, все ли работает так, как ожидается. Чем опытнее тим лид, тем лучше он видит баланс между минимально необходимыми проверками и перестраховкой, способной поглотить месяцы работы на создание бесполезных «экспериментальных прототипов». На вопрос «а сколько времени займет этот проект?» опытный тим лид обычно отвечает, что ему нужно провести несколько проверок и через пару дней можно будет поговорить о сроках.

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

Team Lead и Управление техническим долгом

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

Конец первой части.

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

Григорий Петров: Где найти тим лида?