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

Новости

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

В дайджесте две статьи от Яндекса, музыка Super Nintendo и рассказ о бедах разработка сайтов для взрослых.

AppTractor

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

/

Автор:

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

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

Разработка

Karma получает $12 млн на маркетплейс по продаже излишков продуктов

По данным Продовольственной и сельскохозяйственной организации Объединенных Наций, около трети еды, производимой каждый год – 1.3 миллиарда тонн – либо теряется, либо выкидывается. Это эквивалентно потере 1 триллиона долларов.

AppTractor

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

/

Автор:

На этом фоне стартап Karma, маркетплейс, который хочет уменьшить потери еды, собрал 12 миллионов долларов в Серии А. В ней приняли участие шведская инвестиционная фирма Kinnevik, Bessemer Venture Partners, Electrolux, E.ventures и другие. Общие инвестиции в Karma достигли 18 миллионов долларов.

Пока Karma работает только в Швеции и Лондоне, но с получением новых денег планирует расширение на новые рынки –  сначала в Европе, а потом и в США.

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

Стартап был основан в Стокгольме в 2015 году, в ранние годы Karma предлагала другой сервис – это была скорее программа скидок, немного напоминающая Groupon. Но компания сделала пивот и изменила направление своей деятельности.

«Нам стало ясно, что разные предложения путают пользователей Karma, и мы решили сузиться до нескольких или даже одной категории», – рассказал VentureBeat генеральный директор Karma Хьялмар Стальберг Нордегрен. «Одной из наиболее популярных категорий в нашем раннем приложении была еда, и, рассмотрев то, что на самом деле продают, мы поняли, что на самом деле это излишки, которые владельцы ресторанов добавляли на нашу платформу».

Группа основателей обратилась к мировой проблеме пищевых отходов, и это стало началом Karma в ее нынешнем виде. Это еще один классический пример своего рода «случайной» эволюции стартапа на ранней стадии, основанной на действиях пользователей – посмотреть, как пользователи на самом деле используют платформу и развивать ее на основании этого.

Karma является частью мировой тенденции, когда компании строят бизнес вокруг концепции «сокращения отходов». В прошлом году лондонский Winnow получил 7.4 миллиона долларов на измерение пищевых отходов, Full Harvest из Сан-Франциско собрал 2 миллиона для продажи уродливых фруктов, а на прошлой неделе лондонская Unmade подняла 4 миллиона долларов на платформу для производства одежды по требованию, которая позволяет брендам производить только те предметы одежды, которые фактически продаются.

«Karma превращает выкидывание продуктов в продажи – в этом достаточно много смысла», – отметил Кент Беннетт из Bessemer Venture Partners. «Но помимо самих продуктов, мы полагаем, что связь между клиентами и их любимыми местными продавцами может иметь огромную долгосрочную ценность».

Сейчас у Karma более 1,500 заведений, таких как рестораны, гостиницы, продуктовые магазины, кафе и пекарни, которые продают свои избытки примерно 350,000 пользователям приложения. Это действительно беспроигрышная ситуация: розничные продавцы могут монетизировать продукты питания, которые в противном случае окажутся на свалке, в то время как потребители могут сэкономить большие деньги. И именно эта бизнес-модель может помочь платформе набрать обороты: чтобы сделать приложение более привлекательным для продавцов, оно действительно должно быть коммерчески выгодным, а не просить их делать пожертвования.

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

Медиа

Podlodka #72: Профессиональное выгорание

С этим явлением так или иначе сталкиваются многие программисты по ходу своей карьеры.

AppTractor

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

/

Автор:

Podlodka

С Александром Орловым из Стратоплана поговорили о выгорании как с биологической, так и с психологической точки зрения. А самое главное, разобрались, как из этого состояния выходить.

Тайминг:

  • 00:06:48 — Представление гостя
    
  • 00:08:12 — Выгорание студентов
    
  • 00:30:06 — Симптомы и гормоны
    
  • 00:33:24 — Восстановление и саббатикал
    
  • 00:41:21 — Проекция и эффект Барнума
    
  • 00:49:50 — Работа с психотерапевтом
    
  • 01:18:36 — История про общение с токсичным человеком
    
  • 01:21:13 — Стивен Кови про роли и миссии в жизни
    
  • 01:27:34 — Что если ваши сотрудники выгорают?
    
  • 01:53:53 — Александр сам подводит черту :)
    
    
    
Комментарии
Продолжить чтение

Новости

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

У нас Swift и Auto Layout, обучение Unreal Engine и аналитика.

AppTractor

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

/

Автор:

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

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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