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 и будьте первым, кто прочитает следующую статью и раскритикует ее в комментариях.

Григорий Петров
Комментарии Facebook
Продолжить чтение
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

Новости

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

Лучшие материалы о разработке и маркетинге технологических продуктов.

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

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

/

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

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Мероприятия

Avito iOS Meetup Winter Edition: 2 декабря в Москве

Зима близко! Уже второго декабря состоится традиционный Avito iOS Meetup.

AppTractor

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

/

Автор:

Мы обсудим Data Driven подход, практическое применение Mach-O, lldb и dSYM, возможности расширения lldb, методологию Type Driven, а также концептуальные различия архитектур. В мероприятии примут участие представители Avito, Badoo, Туту.ру и Яндекс.

Программа:

  • Метрики всему голова
    Вадим Смаль (Avito)
    Поговорим о Data-driven подходе к разработке. Вадим продемонстрирует, какие метрики можно собирать, как они помогут быть эффективным и как следить за качеством разрабатываемой функциональности. Подробно рассмотрим, как замерять время компиляции отдельных фреймворков, размер приложения, время запуска приложения, CrashFree, OOM. Если вы до сих пор думаете, что метрики это только для менеджеров и аналитиков — будете приятно удивлены.
  • Расширения lldb
    Сергей Лем (Badoo)
    Все хотят писать код без багов. Но, к сожалению, пока что мало у кого это получается.И почти всегда отладка приложений занимает львиную долю времени при разработке.Поэтому важно иметь наиболее совершенные инструменты в своем арсенале и не тратить время не ерунду. Сергей Лем расскажет о том, как прокачать lldb при помощи  расширений на Python и сделать отладку приятнее и быстрее.
  • Mach-O, lldb, dSYM на практике
    Владислав Алексеев (Avito)
    В докладе речь пойдёт о бинарном формате исполняемых файлов Mach-O, об отладочной информации и объектных файлах. Рассмотрим, как работают брейкпоинты и символизация крешлогов. Поймем, когда и зачем нам нужны файлы dSYM, а в каких случаях их создавать совершенно не требуется. Также изучим случаи непрямого использования dSYM-файлов для анализа содержимого скомпилированного бинарного файла.
  • Type Driven Development
    Валерий Попов (Yandex)
    В докладе Валерий рассматривает строгую типизацию, которая может стать еще одним рубежом обороны надежного приложения от ошибок разработчика. На примерах будет показано, как дополнительная информация, переданная на этапе компиляции, поможет отловить ряд ошибок, не доводя систему до падения в runtime. Расскажет, что мобильный разработчик может почерпнуть из языков, которые ставят типы во главе процесса разработки.
  • Architecture overdose
    Стас Цыганов (Туту.ру)
    Стас Цыганов предлагает поговорить о разных архитектурах: как верхнего слоя, так и всего приложения. Речь не о баззвордах и сравнениях, у кого больше букв: цель —  понять, чем же они концептуально отличаются. Разберемся, почему появляется по архитектуре в неделю и почему в них нет ничего нового. Ну и в конце посмотрим, на что надо будет обратить внимание при выборе архитектуры следующего приложения.

Участие в мероприятии бесплатное, регистрация обязательна. Сбор участников: 12:00. Начало докладов: 12:30. Адрес: офис компании Avito, Лесная 7.

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

Новости

Эксперты выяснили, для чего Google форкнул Swift

Теоретически, добавление Swift позволит быстро портировать приложения c платформы Apple.

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

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

/

На прошлой неделе Google на GitHub форкнул Swift, язык программирования, который создала Apple для разработки iOS/macOS/tvOS/watchOS приложений.

Эксперты полагали, что Google сможет вносить дополнения в открытый язык или использовать его для разработки внутренних инструментов для iPhone и iPad.

Однако последние коммиты в репозиторий Swift показывают, что Google работает над поддержкой Fuchsia OS. На GitHub вы уже можете посмотреть на “Hello World” приложение на Swift для. Fuchsia

Fuchsia: новая операционная система от Google

Fuchsia поддерживает Dart, C++ и Go. Теоретически, добавление Swift позволит быстро портировать приложения c платформы Apple.

Леонид Боголюбов
Комментарии Facebook
Продолжить чтение

Разработка

AR стала частью реальности: что дальше?

Сегодня мы поговорим о важном событии в истории Apple (и это не запуск iPhone X) – мы поговорим о том, благодаря чему дополненная реальность (AR) стала чем-то большим, чем несбыточной мечтой маркетологов.

Джей лаб

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

/

Автор:

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

На сегодняшний день практически все эти препятствия исчезли. С помощью ARKit любой разработчик может создавать приложения в интерактивном формате, которые будут работать на новых iPhone, а также на некоторых предыдущих версиях (6 и выше) с iOS 11. Сотни миллионов пользователей iPhone, а также 100 миллионов устройств Android, которые теперь используют ARCore SDK от Google, означают, что настал переломный момент в переходе технологии AR на массовый рынок.

И как всегда, когда поведение потребителей начинает меняться, каждый хочет знать: «Что это значит для брендов? Как маркетологи могут использовать эту новую, интересную технологию для привлечения внимания потребителей?». С появлением оптимизированного оборудования у компаний появилось больше возможностей. Но как ими правильно воспользоваться?

Почему ARKit лучше альтернатив?

Ждите и наблюдайте

Помните, когда появился 3D Touch? Многие разработчики полагали, что он предоставит совершенно новый уровень навигации по мобильному приложению и что «долгое нажатие» станет таким же общепринятым действием, как «свайп». Но так ли это на самом деле? Вы, например, им пользуетесь? :) У меня есть доступ к этой функции уже более двух лет, и я только недавно обнаружил, что на обычном фонарике на iPhone есть три разных степени интенсивности, которые доступны только при глубоком нажатии на значок в Настройках. Теперь я постоянно использую уровень «низкого света» – но, согласитесь, два года – это совсем не быстрый уровень принятия новой функции.

То же самое касается AR. Все предсказания о том, что дополненная реальность войдет в повседневную жизнь пользователей, не подтвердятся, если на то не будет веской причины.

Конечно, демо-версия игры The Machines выглядит круто, но достаточно ли круто для ежедневного использования большим количеством юзеров? Для того, чтобы AR действительно стала частью нашей повседневной жизни, она должна создавать ценность, выходящую за пределы развлечения. Демо-версия приложения Главной лиги бейсбола выглядит гораздо интереснее, потому что информация о ходе игры и командах, отображающаяся прямо во время матча – это ценная информация, которую пользователи хотят видеть.

Сфера туризма и путешествий также готова к буму AR: приложения, которые накладывают указатели направлений на реальные улицы, отображают перевод надписей на реальных поверхностях, выдают информацию о достопримечательностях в непосредственной близости от них, – все они расширяют границы нашего восприятия мира. Мало кто знает, что до того, как Niantic запустили Pokémon Go, они создали Field Trip для Google Glass, которые уже поддерживали эту функцию.

Начните с малого – затем совершенствуйте, адаптируйте и переориентируйте

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

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

Внедряйте лучшие методы и практики

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

На данный момент AR – это все еще «новая модная вещь», но стоит потратить немного своего времени и энергии, и мы действительно сможем понять, как мы можем эффективно ее использовать и устанавливать свои стандарты, создавая при этом новое рекламное пространство.

Джей лаб
Комментарии Facebook
Продолжить чтение

november

24novallday26What the hack?!

25novalldaySmart Taler 2017

25novalldayLadies Code: время технологий

30novalldaySmart Cars & Roads 2017

december

02decalldayAvito iOS Meetup Winter Edition

05dec18:3022:00Яндекс изнутри: глазами iOS-разработчика

08decallday09Кубок СTF России

09decallday10Games Gathering 2017

09decalldayЛекционный день по игровой индустрии

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

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

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

Наш Facebook

Популярное

X

Спасибо!

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