Я был абсолютно двинутый на компьютерах и геймерствовал безбожно. В юности хотел пойти писать игрушки и даже некоторое время писал. Рос, рос, рос. Был в разное время разработчиком, тимлидом, проект-менеджером. Выяснилось, что в проекте надо не только кодить, но и предлагать какие-то решения сходу, обосновывать их, договариваться, быстро переключаться между разнородными задачами. Лично для меня это серьезная нагрузка на . Перейти из режима «кодить» и «говорить ртом» — отнимает много сил.
Полтора года назад я пришел на проект портала облачной платформы Техносерв Cloud. Появилась возможность собрать новую команду и больше не переключать роли ПМ и разработчика.
Вообще, конечно, когда ты в маленьком проекте работаешь, то смешиваешь все роли, даже если не хочешь. Никуда не спрятаться. Если бы у меня было честное резюме, то туда бы попала должность «главбух», потому что такое тоже было. Но давайте расскажу, как у нас тут устроено, и как, с моей точки зрения, быть тимлидом. Возможно, вы знаете, как сделать лучше, но что есть, то есть.
Самое интересное — это собирать команду под себя на новый проект.
Роли
С моей точки зрения, распределение такое:
- Разработчик пишет код, причём такой, что его, если что, могут править и читать коллеги. В маленькой команде на 5-6 человек нет ничьего индивидуального кода, есть только общая задача. Кто-то ушёл в отпуск или заболел — мы можем дописать хотфикс или внедрить новую фичу, не дожидаясь его.
- Тимлид собирает людей, ставит им задачи, делает оценки, превращает требования архитектора или аналитика в техзадание разработчикам, ведёт трекер и вообще занимается всем тем, что относится к процессу промышленного получения кода из . Но при этом тимлид не разговаривает с людьми особо за пределами команды.
- Проект-менеджер как раз занимается взаимодействием между теми, кому что-то надо от разработчиков и разработчиками. Если у него выделенная роль, то трекер уже на нём, приоритеты задач, способы решения, — всё это обсуждается с ним. Проект-менеджер получает нужные ресурсы, занимается документами и решает организационные задачи, выделяет работы, разбивает задачи. За просроченный проект отвечает ПМ, за качество реализации — тимлид.
- Архитектор или аналитик пронзают мыслью пласты времени и читают мысли заказчика по поводу того, что же надо. У нас выделенного архитектора нет, точнее, архитектор выступает одним из бизнес-заказчиков. Про эту работу лучше расскажет мой коллега архитектор, который занимается крупными вещами, у меня ничего длиннее 5 лет не было.
- Продуктолог продумывает разработку услуги от и до, а программист обеспечивает воплощение идей продуктолога и вдобавок делает всё, чтобы клиент смог удобно, безопасно, со всеми необходимыми SLA, без риска поломки или «падения» от нагрузки заказать услугу.
Ключевое отличие ПМ’а от тимлида не только в круге общения, но и в том, что ПМ вообще-то не должен разбираться в том, как делать работу. Он говорит, что делать, тимлид — как делать. Я до этого был ПМ’ом в геймдеве, там был отличный пример — надо ставить задачу композитору для музыки уровня. И ты должен сказать, какую музыку ты хочешь. «Более роскошно, у тебя слишком быстрый ритм» — вроде, он понимает, но ты чувствуешь, что что-то не то. Повезёт, если найдёте общий язык. Так и с дизайнером и интерфейсником нужно договариваться. Утомительно.
Я такое смешение ролей не рассматривал как путь карьерного развития. В ретроспективе это хороший опыт, чтобы находить общий язык с другим . Но важно потом, уже будучи на большом проекте, перестать «перепрыгивать» в разные роли, иначе задачи начнут провисать.
Как устроена работа в команде сейчас
Заказчик говорит аналитику, что он хочет. Аналитик идёт к нам, мы обсуждаем задачу и разбиваем её на логические части. Точнее, аналитик формирует бэклог (список требуемых изменений), мы выдаем оценки времени, потом аналитик совместно с ПМ'ом расставляют приоритеты — что делаем вначале, что в конце. Профит от аналитика в том, что в его голове хранится логика портала целиком, и он выдает нам задачи, которые в эту логику укладываются, а не так, что «сделали, как просили, посмотрели — чота ой, переделали потом 8 раз, пока не перестало ойкать».
Я разбираю бэклог и набиваю тасктрекер. Около 50% времени уходит на работу с командой и задачами: обсуждаем задачи, рисую схемки на бумажках, управляю тасктрекером, делаю ревью. Сейчас ревью делаю в основном я, эпизодически скидывая на других разработчиков. Хочу перейти на модную схему кросс-ревью, когда все ревьюят всех. Около 40% времени пишу код сам (его ревьюят внутри команды). Ещё около 10% времени уходит на «условный девопс», потому что мы сами поддерживаем свою тестовую среду.
Разработка архитектуры портала — на команде разработки — одна из наших задач. Это в такое обсуждение — «как нам сделать вот такой набор фич, чтобы потом на поддержке не погибнуть». Вычислительно или алгоритмически-сложных задач у нас как-то немного. Зато много задач как раз насчет архитектуры, гибкости настроек и множественной и обильной интеграции. То есть хардкор как бы в другом — в архитектуре приложения.
Тестами покрываем сами, но тестирование фич типа где и что в интерфейсах отдаём наружу. Тут я очень рад, что к нам приезжает всё от ПМ’а в нужной нарезке — любые ресурсы.
Без тестов код не уходит в релиз. На ревью смотрим сначала на тесты, только потом на код.
У нас в команде есть отдельные разработчики бекенда и фронта. В принципе наши бекенд-разработчики могут что-то поправить и дописать в Ангуларе, но это сильно тормозит работу — выгрузить из головы питон, загрузить ангулар — вообще-то утомительно. И, да, я не люблю Angular. Фронтендщик может из кода бекенда прочитать параметры вызовов API, и мы этим нагло пользовались, чтобы не документировать код. Потом завели автоматическую генерацию доков по API и перестали его мучить.
Начало нового проекта
Самое главное в тимлиде — это команда. Если у вас есть люди, в которых вы не уверены, или которые недостаточно технически подкованы — это прямая угроза для проекта. Поэтому в момент, когда мне торжественно вручали проект Техносерв Cloud (мы делаем биллинг, управление ресурсами облака, интеграционный слой и веб-витрину для потребителей), мне нужно было набрать людей, которые смогли бы хорошо работать друг с другом.
Что я дал HR:
Стек: Уверенное владение javascript (vanillaJS) и HTML5CSS3, понимание базовых принципов UX или желание их изучить, способность запилить кроссбраузерное решение, MobileFirst, Responsive design, опыт использования популярных фреймворков — ReactAngularBackbonejsMarionette, использование инфраструктуры сборки и тестирования — Bower, Grunt, Gulp и проч. Понимание современных подходов к клиент-серверному взаимодействию (Restful, msgpack, graphql). Использование распределенных систем контроля версий — GitHg. Будет плюсом тестирование кода, работа с тестовыми библиотеками. Опыт построения «больших» js-приложений, в особенности решения с использованием Reactgraphqlfluxrelay. Опыт разработки для backend-а. Опыт разработки для мобильных устройств. Опыт работы с WebSocket. Проектирование и разработки фронтенда для веб-сервисов компании. Наша специфика — управление сложными технологическими системами, разнообразная статистика с графиками, мониторинг — множество интересных задач. Нужно быстрое прототипирование интерфейсов. Есть реверс-инжениринг и, при необходимости, доработка сторонних решений.
3 месяца до планируемого старта.
Дал описание вакансии нашим HR, получил через две недели первые 20 встреч. Всего было наверное 50 интервью, чтобы отобрать 4 человек. Я просмотрел около 100 анкет, отсеялись те, кто не может переехать, не проходит по аудиту безопасности, не имел достаточного опыта в нашем технологическом стеке.
С самими собеседованиями было непонятно, как за 1 час оценить, как человек будет работать. Через 5-6 встреч появился общий шаблон, и я перестал стесняться.
На собеседованиях я интересовался, в каком проекте человек работал, как там был выстроен процесс. Это для того, чтобы понимать, освоил ли кандидат хорошие инженерные практики или плохих нахватался. Например, точно ли кандидат работал в команде или просто сидел рядом с ребятами и одиноко пилил свой пухлый модуль, и некому было сказать ему «твой код — барахло!». Заставляли ли его старшие товарищи писать тесты до функционала или и так сойдет? То есть, было ли в жизни разработчика достаточно очистительного страдания, полезного для души, или так как-то проскочил.
Мы все на собеседовании любим говорить, что в предыдущем проекте было широко поставлено code-review. Вот и сейчас, извините за неровный почерк (см. выше). На практике интересно — что под этим понималось. В проектах с горящими сроками разработчики должны выделять на это время, а это не всегда выходит. Бывают такие проекты, где до ревью дело не доходит никогда по «объективным причинам». Ох, как вспомню опыт первых работ, что технический долг приходит, когда у тебя 15 минут до планируемого релиза… Я надеюсь, что надежно вытеснил всё это из памяти. Повторения не хотелось совсем.
Ещё спрашивал, какая была самая сложная задача, как решал, с чем приходилось сталкиваться. Во-первых, интересно, какие хоть у настоящих профессионалов задачи бывают, и потом интересно посмотреть — человеку самому-то это все интересно или как-то уже не очень.
Дальше интересно было посмотреть на собственно код. Если есть проекты на GitHub — ну вообще клёво тогда, можно, во-первых, водить пальцем по коду, задавать вопросы вида «почему так, а не сяк», «как это можно улучшить» и «какая тут алгоритмическая сложность». Во-вторых, если кто-то запилил сам своей проект — ну, значит, может все-таки сам себя замотивировать, а это хороший, полезный скилл. Но, естественно, не у всех он был. Тогда в дело вступала тестовая задачка — очень маленькая, строк на 20.
В задачке было нужно выяснить, насколько системно человек подходит к решению: владеет собственно языком программирования, что знает про алгоритмы, вычислительную сложность, и что у компьютера внутри. Это, в общем, не контрольная, это, скорее, нужно, чтобы о коде поговорить.
Еще проще оценивать опыт, если он схож с моим собственным: разработку игрового бекенда в портфолио считаю за «плюс» — ясно, что на человека валились шизовые задачи вида «уменьшить тайминги выпадения монеток» или там «запоминать координаты котиков при переходе в другую локацию» — следовательно, как минимум, у человека крепкая психика.
Одобрил человек 17. В компании не быстрый процесс найма. За это время кандидат может получить ещё офферов и тупо не ждать. Безопасники проверяют всех кандидатов. Пара человек просто тренировалась ходить на собеседования.
Что у нас в принципе надо знать? Помимо собственно Python-а (стандартная библиотека, управление памятью, алгоритмы вообще) — архитектуру веб-сервисов в принципе, базы данных (SQL, индексы, транзакции). Желательно представлять, что случится с сервисом под нагрузкой, иметь представление о безопасности и возможных векторах взлома.
Ещё моменты
Есть интересные стереотипы. Например, «у программистов логический склад ума». Скорее всего, это так и есть, но никому от этого не легче — даже внутри команды проекта у каждого кодера в голове разная картина проекта, и у каждого — очень логичная, но при этом все их картинки взаимно-противоречивы. Задаешь простой вопрос «а можно сделать иконку фиолетовой?» — у человека мука на лице. По-моему, со стороны должно выглядеть непоследовательно и странно.
Еще «чтобы круто кодить, необходимо техническое образование» или «хорошо знать математику». Пока нас всех не заменили нейронные сети, разработчиков требуется много, и не все из них должны быть хардкорными. Техническое образование и математика, конечно, прокачивают мозговую мышцу и системное , но, мне кажется, не менее эффективно качать ее специфическими для разработки разделами математики (логика, множества, графы, алгоритмы) и кодить всё, что под руку попадет.
По-моему, не влияет на фрилансе работать или в офисе. Мне кажется, начинать лучше в офисе, в команде с поставленным процессом разработки — так проще нахвататься от более опытных котанов. На фрилансе это сложнее из-за трудностей с коммуникацией — просто больше времени на нее уходит, задавать вопросы становится затратно, получаешь меньше обратной связи, испытываешь меньше боли, отсюда иллюзия собственного величия. Хотя, возможно, я неправильно готовил фриланс.
Это материал нашего тимлида Петра Матюхова (он на фото команды, как положено, с бородой и в свитере).
Автор: TS_Cloud
