Connect with us

Разработка

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

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

Григорий Петров

Опубликовано

/

     
     
[button color=4d61d7 icon=arrow-left-2 url=https://apptractor.ru/develop/grigoriy-petrov-o-magii-v-razrabotke.html] Предыдущая статья [/button]

 

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

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

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

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

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

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

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

Ants-carrying-twig-teamwork-concept

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

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

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

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

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

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

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

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

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

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

nn_2_52

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

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

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

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

experiment_explode

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

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

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

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
3 комментария

3 Comments

  1. Могу ошибаться, но статья все же больше о техлиде, чем о тимлиде. Хотя допускаю, что это вопрос терминологии и того, как чаще у нас должности называются  
    Также мысль про то, что “Код, который пишет тим лид, будет труден для поддержки другими разработчиками” тоже цепляет – я так и не понял почему так: идея про то что он более и опытный и поэтому пишет сложный код, тобой же опровергается (код будет скорее всего будет более понятный), а посыл про трудности понимания “почему код был так написан” думаю легко применяется к любому разработчику. Вот эта мысль просто отличная: “тим лид программирует, но не с помощью языка программирования, а с помощью своей команды”, согласен.

  2. Kirill Volkov

    08.03.2016 at 19:50

    Интересная статья, но все же не согласен с Вашим подходом.

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

    В итоге тим лид если и код пишет, то очень мало. Если дальше из тим лида растить ПМ-а, то подход конечно оправдан.
    Но качество кода и архитектурных решений будет ниже, если тим лид = тех лид и занимается чисто техническими вопросами.

    • Grigory Petrov

      09.03.2016 at 11:20

      Атож! Индустрия айти – она очень большая. На любой кейс найдется область, где это не работает вообще или работает прямо противоположным образом. В том же геймдеве все будет совсем не так :)

You must be logged in to post a comment Login

Leave a Reply

Мероприятия

ВКонтакте открывает регистрацию на чемпионат по программированию VK Cup 2018

ВКонтакте анонсировал ежегодный чемпионат по программированию VK Cup 2018. К участию приглашаются программисты от 14 до 23 лет. В одной команде может быть один или два человека.

AppTractor

Опубликовано

/

Автор:

Призовой фонд VK Cup 2018 составляет 2,5 млн руб.:

  • 1 место – 1 048 576 руб.
  • 2 местo – 524 288 руб.
  • 3 местo – 262 144 руб.
  • 4-8 места – 131 072 руб.

Соревнование пройдёт в несколько этапов на площадке Codeforces. Начать свой путь к чемпионскому кубку можно с одного из квалификационных раундов 24 февраля или 2 марта.

В финале VK Cup 2018, который состоится в августе в Санкт-Петербурге, сразятся 20 команд, прошедших все этапы предварительных отборов. ВКонтакте покроет расходы на проезд и проживание финалистов.

Комментарии
Продолжить чтение

Разработка

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

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

Анна Гуляева

Опубликовано

/

“Почему мы так медленно выпускаем новые функции так медленно?” — думал я спустя год после присоединения к быстро растущему стартапу. Релиз каждой новой функции был болезненно долгим. Это не то, чего я ожидал — стартапы должны двигаться быстро. Особенно, если вы ещё не нашли свою нишу. В начале моей работы у нас было три команды разработки. Спустя год и несколько миллионов инвестиций у нас в распоряжении было девять команд разработки. Наша способность к разработке утроилась, но новые функции выходили с той же скоростью. В чем же дело? Я думаю, что дело было в законе Брукса, который утверждает, что добавление новых разработчиков в проект на поздней стадии, приводит к ещё большему замедлению проекта. Мы наняли многих отличных разработчиков, но им нужно было понять что замедляло остальных сотрудников.

Наш мотивирующий постер для разработчиков

Спустя полгода мы по-прежнему выпускали новые функции медленно. Поэтому, очевидно, закон Брукса был уже не при чем. Должна была существовать ещё одна причина, но какая? Потом мы столкнулись с проблемой в производстве, которая указала мне на возможного виновника.

Проблема и урок

Мы только выпустили новую функцию фильтрации по тегам. Поддержка получала жалобы о том, что функция не работает. Первым делом я попытался загрузить картинку и отметить её как “Не хот-дог”. Потом я попробовал отфильтровать картинки по этому тегу и убедился, что фильтрация не работает. Я составил список команд, которые участвовали в создании функции. Каждая команда была ответственна за свой компонент:

  1. Загрузка и обработка изображений.
  2. Elasticsearch.
  3. Фронтенд фотоальбома.
  4. Команда DevOps, ответственная за инфраструктуру и развертывание новых функций в облаке.

Я решил сначала поговорить с командой по загрузке изображений. Я спросил руководителя команды, почему их функция не работала. Он посмотрел, что теги были сохранены и предположил, что они не были проиндексированы, что привело меня к команде Elasticsearch. Разработчик из следующей команды заглянул в Elasticsearch. Тег был проиндексирован, все выглядело отлично. Поэтому он отправил меня к команде фронтенда альбома. Они обнаружили, что фронтенд-библиотека была развернута в более старой версии. Функция фильтрации зависит от этой библиотеки, поэтому это, вероятно, было причиной проблемы. Фронтенд-команда посоветовала мне поговорить с командой DevOps, чтобы они развернули нужную библиотеку. Я устал ходить от одной команды к другой и сказал им, чтобы они сразу исправили эту проблему. Наконец проблема была решена. Я понял, что командам не хватало ответственности за то, что они создавали. Команды были разбиты по компонентам, и никто из них не чувствовал ответственности за функции – каждый работал только над маленьким кусочком пазла. Разбитие команд по компонентам сделала быстрый выпуск новых функций сложным. Все их усилия были тесно связаны. Если одна из четырех команд не работала или задерживалась, это влияло на выпуск всего функционала.

Почему компании начали разбивать команды по компонентам?

В начале разработки продукта команды часто самостоятельно разбиваются по компонентам. Если сам продукт пока не имеет структуры, то технические компоненты для его работы понятны. Поэтому команды проще организовать по этим компонентам. Эта идея довольно проста — каждая команда ответственна за один или более компонентов. Такая структура помогает увеличить продуктивность разработчиков, которые работают над конкретными частями системы. Создание чего-то нового на Amazon RedShift? Только одна команда должна беспокоиться об изучении RedShift. Недостаток таких команд заключается в том, что менеджеры должны беспокоиться о выпуске функций. Границы между командами создают зависимости, которые требуют активного управления. Это возможно, если у вас не так много компонентов или функции не распределены между множеством команд. Представьте, что вы владелец продукта и хотите внедрить Feature 2,  как на картинке ниже. Она зависит от двух компонентов, за которые отвечают разные команды. Функция выйдет, только если обе команды завершат необходимую работу над своими компонентами. Вернемся к примеру с фильтрацией тегов. Так как даже причину неисправности было сложно установить, представьте, как неэффективно было заставлять все эти команды координироваться ради одной маленькой функции. Любая задержка в любом компоненте вызывала задержку релиза функции. Чем больше компонентов и команд вовлекалось в дело, тем больше возникало проблем с координацией и вынужденного ожидания. Если один спринт одной команды проваливается, функция не может быть выпущена.

Альтернатива: команды по функциям

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

Переход к командам по функциям

Многие команды начинают с команд по компонентам, потому что структура продукта неясна в начале существования проекта. Но в какой-то точке команды по компонентам могут начать вас тормозить. Вот симптомы, которые подскажут вам, что ваша структура вас замедляет:

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

Если это происходит, вам стоит рассмотреть переход на команды по функциям. Такая работа имеет свои сложности: вам нужно будет придумать лучшее распределение компонентов между командами и подстроить свою архитектуру, чтобы разъединить как можно больше компонентов. Переход к командам по функциям — это самая сложная часть работы с подобной структурой. Как структурировать команды? Как передавать знания? Как убедиться, что организация разрешит вам изменить структуру? Этому будет посвящена уже другая статья.    https://apptractor.ru/develop/myi-uvolili-nashego-luchshego-razrabotchika.html https://apptractor.ru/info/articles/vyi-uvolili-luchshego-razrabotchika-nadeyus-vyi-dovolnyi.html  

Комментарии
Продолжить чтение

Новости

Интересные материалы: 21.02

В новой подборке ASCII-арт, карты развития, практики и ловушки.

Леонид Боголюбов

Опубликовано

/

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Программирование

Создание анимации в 7 строк кода

Android-разработчик Леонардо Пирро рассказывает, как создать простую анимацию при помощи ConstraintLayout и ConstraintSet.

Анна Гуляева

Опубликовано

/

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

ConstraintLayout + ConstraintSet

Я хочу поделиться с вами новым способом создания анимаций в приложении при помощи всего семи строк кода, используя Keyframe Animations, ConstraintLayout и ConstraintSet. Эта концепция заключается в создании двух разных макетов: одного для начальной точки и одного для конечной точки анимации. Давайте посмотрим, что мы хотим создать: наша цель — создать плавную анимацию детали, которая будет появляться при нажатии пользователем на экран.

Анимация создается при помощи двух файлов макета: circuit.xml and circuit_detail.xml. Эти макеты очень похожи и различаются только тем, что на первом элементы вынесены за экран, а на втором — находятся в нужной позиции.

Поэтому давайте создадим анимацию и увидим, как просто создавать анимацию при помощи ConstraintLayout и ConstraintSet.

Пусть магия произойдет

Сначала создадим отдельный ConstraintSet, куда мы скопируем ограничения второго макета, вызвав метод clone():

val constraintSet = ConstraintSet()
constraintSet.clone(this, R.layout.circuit_detail)

Теперь создадим объект перехода, используемый для установки интерполятора и продолжительности анимации:

val transition = ChangeBounds()
transition.interpolator = AnticipateOvershootInterpolator(1.0f)
transition.duration = 1200

Сейчас вызовем TransitionManager.beginDelayedTransition(), который используется для осуществления перехода на следующий кадр рендеринга. Затем мы вызываем applyTo(), чтобы начать анимацию.

TransitionManager.beginDelayedTransition(constraint, transition)

constraintSet.applyTo(constraint)

Это действительно семь строк кода. Вот и все! Вы можете посмотреть полный пример в моем репозитории GitHub по этой ссылке.

Комментарии
Продолжить чтение

Постеры для разработчиков

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.