Pull to refresh

Comments 50

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

пять балов, чо…

Ну, к сожалению, это так, да.
Это ни сколько не уменьшает важности уметь программировать, систематизировать и проектировать. Но эти люди… они везде, и они все чертовски разные.

Сперва набирают «домашних» программеров
Потом к ним ищут тимлида на 200К+
Получают супер софт
Недорого
Профит
Гуманитарий, что взять…
Не проводил, походу, по 60 часов в неделю у белой доски в жарких спорах и поиске решений…

А если перефразировать, лиду нужен специфический опыт — работа с людьми, и ему точно не научиться дома, он должен уметь правильно систематизировать все задачи, планировать, контролировать и программировать в общем случае не обязан, но может и точно мог). Это бывший сеньер, который ещё имеет навыки управления работой, людьми,… И этому можно научиться в основном только через реальный опыт. У нас есть 10 отличных программеров, но компетенция и Лида обладает один, максимум два. Это большая проблема

UFO just landed and posted this here
Отвечает != лично сам руками делает. В данном случае задача TULа позаботиться о том чтобы код был качественный, а способов это сделать может быть много, например: ревьюить самому если есть экспертиза, иметь в команде по сильному разработчику нужных функций которые отвечают за ревью, договориться с коллегами из смежных или платформенных команд о кросс-ревью и т.п.
Для обеспечения безопасности тоже есть свои практики и инструменты, например практика Security Champions. В дополнение к этому есть отдельная команда со специалистами по безопастности которая может сделать аудит по запросу, но для этого TUL должен к ним прийти с этим запросом :)
Отвечает — контролирует. Адекватно контролировать такое количество разных технологий (2 мобильных, фронт, бэк (в количестве стэка авито) — это новый уровень фулстэка. Но нужны еще навыки ПМ/Лида (на уровне техлида). -> Архифулстэк.
И отдельное НО
договориться с коллегами из смежных или платформенных команд о кросс-ревью и т.п.
Другие команды — это неконтролируемая сфера. У них может быть релиз, авария и тд. и им не до ревью ваших фич. Плюс они вне контекста проекта, и оптимальность решений могут оценить только на уровне кода, но не на уровне взаимодействия с другими элементами проекта.
Отвечает — контролирует

Это так, но вот дальше следствие из этого не совсем корректное. Как я писал выше, можно контролировать все лично, если есть экспертиза и время. А можно выстроить процесс так, что этим будет заниматься человек у которого есть нужная экспертиза. И тут много разных вариантов в зависимости от ситуации в компании и окружения.

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

Согласен, это очевидный минус такого решения :) Но бывают ситуации когда это работает.
UFO just landed and posted this here
Если так, то это самое что ни на есть обычное руководство. Менеджмент. Тут нет ничего чтобы требовало специальных технических навыков

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

Вы зачем-то совмещаете должность архитектора, техлида, менеджера.

Архитектора точно не совмещаем. А чем по вашему техлид отличается от менеджера?
UFO just landed and posted this here
зачем для этого отдельный человек для всех направлений сразу (и как ещё всё это успевать), когда очевидно что специализирующиеся на чём-то одном люди сделают это лучше

Потому что у нас кроссфункциональные команды, которые помогают нам быстрее и лучше разрабатывать продукт. Я про это отдельно писал в статье.
Да у нас требования к TULам более высокие, чем к обычным функциональным тимлидам. Но такая структура имеет свои плюсы по сравнению с функциональным делением.
Утром работала).
Сейчас перевыложим на Гитхаб.
Sorry, something went wrong. Reload?

Короче, понятно все с вашими домашними программерами и тимлидами…
А что там?
Я вижу надпись 20.3 MB и котейку-лоадер
Предполагаю, что 20.3 MB pdf-a вызывают таймаут у браузера при коннекте меньше 1Mb/s

это не вина Avito, а особенность GitHub — он большие файлы не грузит в просмотр и там есть кнопка "Download" для загрузки:

То есть вины Авито никакой нет, что мы тут всей толпой не можем понять как их слайды смотреть?
И то что все эти слайды с котятами можно было в 2-3 мегабайта засунуть без визуальной потери качества?
Это все вина GitHub-a, я правильно понял?
Вы тоже у них тимлидом работаете?

0) вы — не толпа
1) (ответный переход на личности) простите, как вы работаете удалённо, если проблема загрузить 20Мб и незнанием взаимодействия с достаточно распространённым VCS-ресурсом?
2) нет, я не работаю у них тимлидом. И вообще, в настоящее время, у них не работаю.

0) кроме меня тут и у других людей недоумение
1) я вам показал ошибку — Sorry, something went wrong. Reload?
Она была и наверняка не только у меня. Это ошибка по определению, ее быть не должно. И мне кажется Авито должна заботиться не только обо мне с моим коннектом, но и о людях на 3G.
3) все равно лицо заинтересованное, как видно по комментам

кхм. А разве не "Доставка" первая переписывалась на "технологии Avito" и тому подобное в 2017 году?

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

цитата:


Первый проект — это Domofond.

не надо пацанов из Доставки забывать :) Я хоть уже и не там, но помню кого первым в "жернова" перемолки отправили

Там в предыдущем абзаце подводка:

Пара примеров на основе вакансий, которые у меня были.

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

тим лид — это когда пытаешься сократить тех лида и пм-а до 1 человека, чтобы в итоге платить меньше?

ПМ — это кто? Проектный Менеджер или Продуктовый Менеджер?
Согласен с Gemorroj, немного можно смягчить формулировку, но суть останется та же.
Хотя могу и на вашу сторона встать и придумать десятки ситуаций почему «так» более эффективно и оправдано.
Отвечая на ваш вопрос: ПМ или ПМ, то ответ может быть неожиданным для вас, но «Вам виднее». Я сталкивался и Project Manager и с Product Manager разница небольшая. Все зависит от организации и продукта. Чисто теоретически разница между ними только в том что ПрожектМ имеет более конкретные цели и более жесткий дедлайн и по окончании проекта вроде как можно умывать руки. А ПродактМ в свою очередь типа ведет продукт бусконечно долго из года в год и из спринта в спринт. А в остальном из квалификация одинаковая и отбирать кандидатов надо примерно по одним и тем же критериям. Это мое мнение. Буду рад услышать каково ваше.
Возвращаясь к первоначальному замечанию, мне тоже кажется что происходит постоянная и порой не очень понятная трансформация терминов и ролей. Тот круг обязанностей что вы описываете я бы тоже скорее отнес к роли Прожект Менеджера нежели к техлиду. Но так было и раньше когда стали появляться первые DevOps раньше были админы, кодеры, техлиды, синьоры а теперь есть новый класс ДевОпсов и они уже делятся и почкуются внутри нового класса специалистов и порой действительно трудно сказать как отличить одно от другого.
Я спрашивал, потому что Продукт Менеджер у нас как раз есть и это отдельный человек и роль. В статье есть картинка со структурой команды. Эта позиция у нас называется Unit Leader и он как раз отвечает за продуктовую составляющую, сбор болей и потребностей пользователей, за наполнение бэклога нужными инициативами чтобы бизнес достигал своих целей, за постановку квартальных и годовых целей и т.п. А задача Technical Unit Leader чтобы команда разработки качественно и в срок доставляла задачи из бэклога до пользователей.
А Проектные Менеджеры обычно бывают в компаниях где разработчики поделены на функции (бэк, фронт, qa и т.п.) и для разработки какой-то фичи нужно собрать из них команду и управлять разработкой проекта. Обычная матричная структура вобщем. Но в таких компаниях другие процессы и конечно будут другие требования к тимлидам.
А мне интересно, насколько реалистичны (и, соответственно, нужны в природе) «планы на ближайшие 100 дней»? Есть хоть один человек, который с уверенностью скажет, что сколь угодно подробное планирование «на N дней» вместо «роадмапа» на «квартал» там, «год» не было пустой тратой времени?
«планы на ближайшие 100 дней» — тут да, была не очень удачная формулировка. Мы просили сделать «роадмап» на квартал + хотели услышать что человек планировал лично, как менеджер, делать в первые месяцы работы.
Тестовое задание на 2 недели с диаграммами ганта, человечками, ФОТ, план на 100 дней для проекта на 6 месяцев (100 дней, не 3 месяца, чувствуете разницу?), расчет бюджета на переход.

Вы хотите ПМа не тимлида.
Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде. Это диаметрально противоположные области интересов.
«2 недели» это столько нам обычно называли сами кандидаты в среднем. Мы не ставили жестких сроков, хоть два месяца готовься, хоть 1 день.

Про расчет бюджета в поставленных задачах ничего нет :) Только в описании текущей ситуации, чтобы у кандидатов было понимание про то на какую команду можно расчитывать.

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

Вы хотите ПМа не тимлида.

Нет, я не хочу ПМа :) Мне был нужен технический руководитель. Хороший технический руководитель не junior уровня, должен учитывать в своих планах расходы на сервера, людей и ПО. Не обязательно в деньгах, но в штуках точно.

Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде.

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

Возможно он имел ввиду планирование фиче беклога, как в скраме и разбиение фич на задачи для спринт бэклога, там вполне себе можно на пол года вперёд расписать количество спринтов, но потом корректировать по завершению каждого спринта. Это как раз задача тим Лида, ПМ не сможет разбить фичи на задачи по 4-8 часов, надо и архитектуру понимать и что от чего зависит и как правильно распаллелить.

Фантастические тимлиды и где они обитают

Какая толстая отсылка к почти одноимённому фильму. Вы что-то имеете против тимлидов?
Для тех кто вдруг не в курсе о чём я
Название почти одноимённого фильма: «Фантастические ТВАРИ и где они обитают»
Отсылка есть, второго смысла никакого нет. Если вы тимлид и вас это оскорбило, прошу прощения.

Они же там, в кино, удивительно классные и очень редкие…

Спасибо за интересную статью!
Про фантастических тимлидов тема раскрыта, про «где обитают» не совсем.

Не могли бы вы осветить (в тех пределах, что позволяет коммерческая тайна), как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?
И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?
Сколько времени занял найм?

Я работаю в Минске. Тут рынок труда, конечно, поменьше, чем в Москве. Но, предполагаю, что ситуация в общем схожая. С такими критериями позиции закрывались бы настолько долго, что могли стать не актуальными. Даже на интересном проекте с высокими зп и вкусными печеньками.
как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?

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

И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?

2 недели это «грязное» время. Реально люди же работают, занимаются своими делами, поэтому времени на подготовку уходит не так много. Кандидатов мы никак особо не мотивировали, все с пониманием относились к тестовому заданию. Мне кажется потому что все понимают, что позиция менеджерская, и цена ошибки при найме достаточно высока, поэтому с понимаем относятся.

Сколько времени занял найм?

Сейчас точно не скажу, но где-то 3-4 месяца на каждую позицию.

Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.

Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.

Для новых офисов в других городах мы еще не достаточно большие, нам проще помогать кандидатам с релокацией в Москву.
А для полностью распределенных команд мы пока морально не готовы. С ними нужно работать по другому, а у нас все процессы заточены сейчас на то что со всеми нужными людьми ты либо сидишь рядом, либо можешь пообщаться лично.
Ну и 3-4 месяца для поиска руководителя это не так много, мне кажется. Я сомневаюсь что в распределенную команду мы бы нашли человека быстрее.
Трудно найти тимлидера хорошего, так как в разработке все часто меняется, постоянно появляются новые технологии и пока человек доучиться до тимлидера появятся новые технологии, на которых опять человек зависает и не дослуживается выше.
Во-вторых многие раньше уходят из разработки, чем дорастают до руководился, либо меняют технологии внутри профессии чтобы поддержать разнообразие. Это слишком скучная, асоциальная и не подходящая и не благородная профессия чтобы её рассматривать на всю жизнь.
То что вы описываете больше похоже на путь разработчика, чем руководителя. Принципы управления программистами меняются не так быстро и сейчас все еще актуальны книжки написанные в 70-е годы. Например тот же Брукс и его Мифический человеко-месяц.
Ну и тимлид это не обязательно лучший разработчик в команде. Если есть желание быть тимлидом, то не надо в него расти качая знания в новых технологиях. Там нужны совсем другие навыки.
Sign up to leave a comment.