Как быть тимлидом — моя версия


    Я был абсолютно двинутый на компьютерах и геймерствовал безбожно. В юности хотел пойти писать игрушки и даже некоторое время писал. Рос, рос, рос. Был в разное время разработчиком, тимлидом, проект-менеджером. Выяснилось, что в проекте надо не только кодить, но и предлагать какие-то решения сходу, обосновывать их, договариваться, быстро переключаться между разнородными задачами. Лично для меня это серьезная нагрузка на мозг. Перейти из режима «кодить» и «говорить ртом» — отнимает много сил.


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

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

    Самое интересное — это собирать команду под себя на новый проект.

    Роли


    С моей точки зрения, распределение такое:
    • Разработчик пишет код, причём такой, что его, если что, могут править и читать коллеги. В маленькой команде на 5-6 человек нет ничьего индивидуального кода, есть только общая задача. Кто-то ушёл в отпуск или заболел — мы можем дописать хотфикс или внедрить новую фичу, не дожидаясь его.
    • Тимлид собирает людей, ставит им задачи, делает оценки, превращает требования архитектора или аналитика в техзадание разработчикам, ведёт трекер и вообще занимается всем тем, что относится к процессу промышленного получения кода из мозга. Но при этом тимлид не разговаривает с людьми особо за пределами команды.
    • Проект-менеджер как раз занимается взаимодействием между теми, кому что-то надо от разработчиков и разработчиками. Если у него выделенная роль, то трекер уже на нём, приоритеты задач, способы решения, — всё это обсуждается с ним. Проект-менеджер получает нужные ресурсы, занимается документами и решает организационные задачи, выделяет работы, разбивает задачи. За просроченный проект отвечает ПМ, за качество реализации — тимлид.
    • Архитектор или аналитик пронзают мыслью пласты времени и читают мысли заказчика по поводу того, что же надо. У нас выделенного архитектора нет, точнее, архитектор выступает одним из бизнес-заказчиков. Про эту работу лучше расскажет мой коллега архитектор, который занимается крупными вещами, у меня ничего длиннее 5 лет не было.
    • Продуктолог продумывает разработку услуги от и до, а программист обеспечивает воплощение идей продуктолога и вдобавок делает всё, чтобы клиент смог удобно, безопасно, со всеми необходимыми SLA, без риска поломки или «падения» от нагрузки заказать услугу.

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

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

    Как устроена работа в команде сейчас


    Заказчик говорит аналитику, что он хочет. Аналитик идёт к нам, мы обсуждаем задачу и разбиваем её на логические части. Точнее, аналитик формирует бэклог (список требуемых изменений), мы выдаем оценки времени, потом аналитик совместно с ПМ'ом расставляют приоритеты — что делаем вначале, что в конце. Профит от аналитика в том, что в его голове хранится логика портала целиком, и он выдает нам задачи, которые в эту логику укладываются, а не так, что «сделали, как просили, посмотрели — чота ой, переделали потом 8 раз, пока не перестало ойкать».

    Я разбираю бэклог и набиваю тасктрекер. Около 50% времени уходит на работу с командой и задачами: обсуждаем задачи, рисую схемки на бумажках, управляю тасктрекером, делаю ревью. Сейчас ревью делаю в основном я, эпизодически скидывая на других разработчиков. Хочу перейти на модную схему кросс-ревью, когда все ревьюят всех. Около 40% времени пишу код сам (его ревьюят внутри команды). Ещё около 10% времени уходит на «условный девопс», потому что мы сами поддерживаем свою тестовую среду.

    Разработка архитектуры портала — на команде разработки — одна из наших задач. Это в такое обсуждение — «как нам сделать вот такой набор фич, чтобы потом на поддержке не погибнуть». Вычислительно или алгоритмически-сложных задач у нас как-то немного. Зато много задач как раз насчет архитектуры, гибкости настроек и множественной и обильной интеграции. То есть хардкор как бы в другом — в архитектуре приложения.

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

    Без тестов код не уходит в релиз. На ревью смотрим сначала на тесты, только потом на код.

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

    Начало нового проекта


    Самое главное в тимлиде — это команда. Если у вас есть люди, в которых вы не уверены, или которые недостаточно технически подкованы — это прямая угроза для проекта. Поэтому в момент, когда мне торжественно вручали проект Техносерв Cloud (мы делаем биллинг, управление ресурсами облака, интеграционный слой и веб-витрину для потребителей), мне нужно было набрать людей, которые смогли бы хорошо работать друг с другом.

    Что я дал HR:
    Стек: Уверенное владение javascript (vanillaJS) и HTML5\CSS3, понимание базовых принципов UX или желание их изучить, способность запилить кроссбраузерное решение, MobileFirst, Responsive design, опыт использования популярных фреймворков — React\Angular\Backbonejs\Marionette, использование инфраструктуры сборки и тестирования — Bower, Grunt, Gulp и проч. Понимание современных подходов к клиент-серверному взаимодействию (Restful, msgpack, graphql). Использование распределенных систем контроля версий — Git\Hg. Будет плюсом тестирование кода, работа с тестовыми библиотеками. Опыт построения «больших» js-приложений, в особенности решения с использованием React\graphql\flux\relay. Опыт разработки для backend-а. Опыт разработки для мобильных устройств. Опыт работы с WebSocket. Проектирование и разработки фронтенда для веб-сервисов компании. Наша специфика — управление сложными технологическими системами, разнообразная статистика с графиками, мониторинг — множество интересных задач. Нужно быстрое прототипирование интерфейсов. Есть реверс-инжениринг и, при необходимости, доработка сторонних решений.

    3 месяца до планируемого старта.

    Дал описание вакансии нашим HR, получил через две недели первые 20 встреч. Всего было наверное 50 интервью, чтобы отобрать 4 человек. Я просмотрел около 100 анкет, отсеялись те, кто не может переехать, не проходит по аудиту безопасности, не имел достаточного опыта в нашем технологическом стеке.

    С самими собеседованиями было непонятно, как за 1 час оценить, как человек будет работать. Через 5-6 встреч появился общий шаблон, и я перестал стесняться.

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

    Мы все на собеседовании любим говорить, что в предыдущем проекте было широко поставлено code-review. Вот и сейчас, извините за неровный почерк (см. выше). На практике интересно — что под этим понималось. В проектах с горящими сроками разработчики должны выделять на это время, а это не всегда выходит. Бывают такие проекты, где до ревью дело не доходит никогда по «объективным причинам». Ох, как вспомню опыт первых работ, что технический долг приходит, когда у тебя 15 минут до планируемого релиза… Я надеюсь, что надежно вытеснил всё это из памяти. Повторения не хотелось совсем.

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

    Дальше интересно было посмотреть на собственно код. Если есть проекты на GitHub — ну вообще клёво тогда, можно, во-первых, водить пальцем по коду, задавать вопросы вида «почему так, а не сяк», «как это можно улучшить» и «какая тут алгоритмическая сложность». Во-вторых, если кто-то запилил сам своей проект — ну, значит, может все-таки сам себя замотивировать, а это хороший, полезный скилл. Но, естественно, не у всех он был. Тогда в дело вступала тестовая задачка — очень маленькая, строк на 20.

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

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

    Одобрил человек 17. В компании не быстрый процесс найма. За это время кандидат может получить ещё офферов и тупо не ждать. Безопасники проверяют всех кандидатов. Пара человек просто тренировалась ходить на собеседования.

    Что у нас в принципе надо знать? Помимо собственно Python-а (стандартная библиотека, управление памятью, алгоритмы вообще) — архитектуру веб-сервисов в принципе, базы данных (SQL, индексы, транзакции). Желательно представлять, что случится с сервисом под нагрузкой, иметь представление о безопасности и возможных векторах взлома.

    Ещё моменты


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

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

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

    Это материал нашего тимлида Петра Матюхова (он на фото команды, как положено, с бородой и в свитере).
    ТЕХНОСЕРВ 201,09
    Компания
    Поделиться публикацией
    Комментарии 30
    • +8
      В статье несколько раз упоминается проверка кандидатов «безопасниками». Мне интересно, что может проверять аудит безопасности частной компании в отношении программистов? Не сидели ли за тяжкие преступления? Не участвовали ли в акциях протеста? Просто непонятно, откуда такой акцент на проверку «безопасниками» категории населения, которая, в принципе, редко занимается чем-то криминальным.
      • –1
        Уголовные и административные наказания, причины ухода с предыдущих мест работы и пр.
        • +4
          Интересное перечисление…
          • +4
            Насчет причин ухода с предыдущих мест работы согласен, но это же может сделать и HR по своим каналам. И, возможно, даже быстрее и эффективнее. Насчет уголовных преступлений… Вы серьезно думаете, что существует так много программистов с уголовным прошлым, что стоит ради них держать целый отдел безопасности? Насчет административных правонарушений… Думаю, «административка» в отношении работников IT-сферы будет касаться превышения скорости, нарушений правил парковки и прочих малозначимых для IT-компании вещей. Ради проверки этих фактов опять-таки, по моему мнению, не стоит держать целый отдел безопасности.
            • +2
              Безопасники занимаются не только новыми сотрудниками и не только программистами. На пример, они могут проверят потенциальных контрагентов и давать свое заключение по работе с ними. Текущая деятельность компании тоже объект их интереса.
              • +1
                Текущая деятельность компании тоже объект их интереса.
                — Товарищ гендиректор, наша фирма закрыла этот год со слишком большой прибылью, риск рейдерского захвата превышен, в этом году сбавьте обороты.
            • +8

              Только если всплывет, что вы не взяли человека из-за судимости, которая погашена, вам влетит. У нас конечно не Европа, но прециденты судебных разбирательств были, поэтому говорить о таких вещах на Хабре не самая умная идея.

              • 0
                Прецедентов, думаю, не было. Просто потому как никто не даст официальный ответ, что не приняли потому как судимость.
            • +3
              а вот не признаются безопасники, на что и как они проверяют кандидата(( говорят, мы к вам в работу не лезем и вы к нам тоже не лезьте. а если твой подчиненный займется промышленным шпионажем или начнет обмазывать фекалиями стенки туалета в офисе (реальная история), то разгребать придется не только уборщице
              • +7
                Насколько помню — Техносерв активно работает на госсектор. Лет десять назад — всех разработчиков поголовно проверяли на полиграфе, а рабочие помещения батюшка освящал :)
                • +1
                  Вы серьезно про батюшку?
                  • 0
                    Да. Если почитайте про основателей компании, то всё встанет на свои места.
                    • 0
                      Техносерв активно работает на госсектор.
                      а рабочие помещения батюшка освящал
                      Вроде очевидно, не?)
                • 0
                  «Тестами покрываем сами, но тестирование фич типа где и что в интерфейсах отдаём наружу.»
                  Можно подробнее описать процесс тестирования?
                  • 0
                    hosher, процесс такой: пишем автотесты, когда все тесты проходят, разворачиваем новую версию на тестовом стенде. Там уже новые «фичи» тестирует вручную аналитик, а бизнес-заказчики вносят дополнения. Перед релизом новую версию всегда проверяет служба эксплуатации.
                    • 0
                      Там уже новые «фичи» тестирует вручную аналитик
                      — тестировщики-то у вас есть? Если да — то как разделяете: что именно должен тестировать аналитик, а что тестировщики? Если нет — то по какой причине?
                      • 0
                        Тестировщиков у нас нет, в этой роли попеременно выступают разработчик фронта, тимлид (Петр), аналитик и коллеги из службы эксплуатации.  Аналитик делает первичную приемку по use-кейсам, которые он для нас разработал, после него или вместе с ним бизнес-заказчики тестируют то, что поменялось. Еще мы запускаем selenium-тесты интерфейса основных сценариев.
                        Поэтому пока все эти специалисты тестируют, разработчики получают от мониторинга «алерты» и логи ошибок (от фронта и от бекенда), и видят, «падает» что-то или нет, даже если это незаметно для тестирующих
                  • 0
                    Добротная обзорная статья, особо без деталей, но все же, правильная.
                    Ещё спрашивал, какая была самая сложная задача, как решал, с чем приходилось сталкиваться. Во-первых, интересно, какие хоть у настоящих профессионалов задачи бывают, и потом интересно посмотреть — человеку самому-то это все интересно или как-то уже не очень.

                    А это, наверное, самый интересный вопрос на собеседованиях.
                    • 0
                      Вот вы так все расписали хорошо. Так все у вас проверяется тщательно. Захотел зайти на главную вашего сайта и прямо расстроился…
                      Картинка не грузится
                      • 0
                        Да, спасибо. Это основной сайт «Техносерва», увидели глюк (возник при блокировке swf) и уже исправили. Мы сейчас полностью будем менять отображение баннеров, чтобы подобное не могло возникнуть в дальнейшем.
                        • 0
                          Нужно флеш включить.
                        • +2
                          Что я дал HR:
                          Стек: Уверенное владение javascript (vanillaJS) и HTML5\CSS3, понимание базовых принципов UX или желание их изучить, способность запилить кроссбраузерное решение, MobileFirst, Responsive design...

                          Вот прямо такими словами и дали? А они знают все эти слова?
                          • +2
                            ко мне как-то приходили с описанием вакансии:
                            Design Patterns — singltone, chain of responsebility, factoty, facade, circuit bracker и future and promises, etc

                            орфография оригинала сохранена :)
                            • 0
                              Да, прям так и дали. Да, понимали почти всё — задавали уточняющие вопросы, где неясно. Судя по подобранным резюме, всё поняли хорошо: по фронтендщикам совершенно левых резюме не было. А сами кандидаты всё понимали, мы проверили.
                            • +2
                              Можете привести размер зарплаты для ваших вакансий и город.
                              • +3
                                Что то за большие требования наверное из за переизбытка разработчиков можно ставить космическую планку, какую зарплату предлагали кандидатам?
                                • +2

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


                                  в статье озвучен интересный вопрос — как нам сделать вот такой набор фич, чтобы потом на поддержке не погибнуть? Я добавил его 4-м в коллекцию своих вопросов:


                                  • как нам организовать наше дело так, что-бы его результаты были не хуже планов, ожиданий?
                                  • для лидов/менеджеров — что можно сделать в текущей ситуации, что-бы приблизиться к релизу проекта?
                                  • для девов — как реализовать запрошенное, выполнить поставленную техническую задачу?
                                  • 0
                                    Любого кандидата когда проверяют, это норма, я считаю.
                                    • 0

                                      В статьях вроде "Быть %должность% — это..." интересны цифры по распределению времени — на оперативные, стратегические задачи, пятое, десятое. Даёт неплохое представление о трудовых реалиях.


                                      С другой стороны — хотелось бы понять, например. Вот продажник — это драйв, энергия, азарт! А Тимлид? Это больше про лидерство или системность? Про взвешенные решения или грамотно выстроенные коммуникации? Больше абстрактных материй, в общем. Спасибо!

                                      • 0
                                        Тимлид это вообще одна только голая системность. В смысле, способность справляться со сложностями, которые все время экспоненциально растут. Когда ты программист, ты пишешь код, когда ты тимлид, приходится подбирать людей, смиряться с разными способами мышления, выстраивать коммуникацию внутри команды, параллельно «обрастая» трекерами, вики, досками и CI.  Если это не драйв, то что же тогда? Вообще, спасибо вам за хорошую мысль! Чуть позже мы соберем побольше материала и постараемся рассказать обо всех трудовых реалиях в предложенном разрезе.

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

                                      Самое читаемое