Комментарии 50
Программированию можно научиться, сидя дома за компьютером, а чтобы стать хорошим тимлидом, обязательно нужна практика с живыми людьми.
пять балов, чо…
Ну, к сожалению, это так, да.
Это ни сколько не уменьшает важности уметь программировать, систематизировать и проектировать. Но эти люди… они везде, и они все чертовски разные.
Не проводил, походу, по 60 часов в неделю у белой доски в жарких спорах и поиске решений…
А если перефразировать, лиду нужен специфический опыт — работа с людьми, и ему точно не научиться дома, он должен уметь правильно систематизировать все задачи, планировать, контролировать и программировать в общем случае не обязан, но может и точно мог). Это бывший сеньер, который ещё имеет навыки управления работой, людьми,… И этому можно научиться в основном только через реальный опыт. У нас есть 10 отличных программеров, но компетенция и Лида обладает один, максимум два. Это большая проблема
Для обеспечения безопасности тоже есть свои практики и инструменты, например практика Security Champions. В дополнение к этому есть отдельная команда со специалистами по безопастности которая может сделать аудит по запросу, но для этого TUL должен к ним прийти с этим запросом :)
И отдельное НО
договориться с коллегами из смежных или платформенных команд о кросс-ревью и т.п.Другие команды — это неконтролируемая сфера. У них может быть релиз, авария и тд. и им не до ревью ваших фич. Плюс они вне контекста проекта, и оптимальность решений могут оценить только на уровне кода, но не на уровне взаимодействия с другими элементами проекта.
Отвечает — контролирует
Это так, но вот дальше следствие из этого не совсем корректное. Как я писал выше, можно контролировать все лично, если есть экспертиза и время. А можно выстроить процесс так, что этим будет заниматься человек у которого есть нужная экспертиза. И тут много разных вариантов в зависимости от ситуации в компании и окружения.
Другие команды — это неконтролируемая сфера. У них может быть релиз, авария и тд. и им не до ревью ваших фич. Плюс они вне контекста проекта, и оптимальность решений могут оценить только на уровне кода, но не на уровне взаимодействия с другими элементами проекта.
Согласен, это очевидный минус такого решения :) Но бывают ситуации когда это работает.
Если так, то это самое что ни на есть обычное руководство. Менеджмент. Тут нет ничего чтобы требовало специальных технических навыков
Ну тимлид это и есть менеджер у технической команды. Если технической командой будет руководить человек без технического опыта, который не понимает что они делают, он не сможет ими нормально руководить. Не сможет заниматься их развитием, не сможет оценивать результаты их работы, не сможет оценить технические решения которые предлагает команда. Поэтому ему и нужны технические навыки.
Вы зачем-то совмещаете должность архитектора, техлида, менеджера.
Архитектора точно не совмещаем. А чем по вашему техлид отличается от менеджера?
зачем для этого отдельный человек для всех направлений сразу (и как ещё всё это успевать), когда очевидно что специализирующиеся на чём-то одном люди сделают это лучше
Потому что у нас кроссфункциональные команды, которые помогают нам быстрее и лучше разрабатывать продукт. Я про это отдельно писал в статье.
Да у нас требования к TULам более высокие, чем к обычным функциональным тимлидам. Но такая структура имеет свои плюсы по сравнению с функциональным делением.
teamleadconf.ru/spb/2018/abstracts/3876 — Internal Server Error
Сейчас перевыложим на Гитхаб.
Короче, понятно все с вашими домашними программерами и тимлидами…
это где так? по ссылке от rafinirovannoe всё нормально открывается
Я вижу надпись 20.3 MB и котейку-лоадер
Предполагаю, что 20.3 MB pdf-a вызывают таймаут у браузера при коннекте меньше 1Mb/s
это не вина Avito, а особенность GitHub — он большие файлы не грузит в просмотр и там есть кнопка "Download" для загрузки:
И то что все эти слайды с котятами можно было в 2-3 мегабайта засунуть без визуальной потери качества?
Это все вина GitHub-a, я правильно понял?
Вы тоже у них тимлидом работаете?
0) вы — не толпа
1) (ответный переход на личности) простите, как вы работаете удалённо, если проблема загрузить 20Мб и незнанием взаимодействия с достаточно распространённым VCS-ресурсом?
2) нет, я не работаю у них тимлидом. И вообще, в настоящее время, у них не работаю.
1) я вам показал ошибку — Sorry, something went wrong. Reload?
Она была и наверняка не только у меня. Это ошибка по определению, ее быть не должно. И мне кажется Авито должна заботиться не только обо мне с моим коннектом, но и о людях на 3G.
3) все равно лицо заинтересованное, как видно по комментам
кхм. А разве не "Доставка" первая переписывалась на "технологии Avito" и тому подобное в 2017 году?
Софт тем временем превращается в совершенно неюзабельное гуано.
тим лид — это когда пытаешься сократить тех лида и пм-а до 1 человека, чтобы в итоге платить меньше?
Хотя могу и на вашу сторона встать и придумать десятки ситуаций почему «так» более эффективно и оправдано.
Отвечая на ваш вопрос: ПМ или ПМ, то ответ может быть неожиданным для вас, но «Вам виднее». Я сталкивался и Project Manager и с Product Manager разница небольшая. Все зависит от организации и продукта. Чисто теоретически разница между ними только в том что ПрожектМ имеет более конкретные цели и более жесткий дедлайн и по окончании проекта вроде как можно умывать руки. А ПродактМ в свою очередь типа ведет продукт бусконечно долго из года в год и из спринта в спринт. А в остальном из квалификация одинаковая и отбирать кандидатов надо примерно по одним и тем же критериям. Это мое мнение. Буду рад услышать каково ваше.
Возвращаясь к первоначальному замечанию, мне тоже кажется что происходит постоянная и порой не очень понятная трансформация терминов и ролей. Тот круг обязанностей что вы описываете я бы тоже скорее отнес к роли Прожект Менеджера нежели к техлиду. Но так было и раньше когда стали появляться первые DevOps раньше были админы, кодеры, техлиды, синьоры а теперь есть новый класс ДевОпсов и они уже делятся и почкуются внутри нового класса специалистов и порой действительно трудно сказать как отличить одно от другого.
А Проектные Менеджеры обычно бывают в компаниях где разработчики поделены на функции (бэк, фронт, qa и т.п.) и для разработки какой-то фичи нужно собрать из них команду и управлять разработкой проекта. Обычная матричная структура вобщем. Но в таких компаниях другие процессы и конечно будут другие требования к тимлидам.
Вы хотите ПМа не тимлида.
Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде. Это диаметрально противоположные области интересов.
Про расчет бюджета в поставленных задачах ничего нет :) Только в описании текущей ситуации, чтобы у кандидатов было понимание про то на какую команду можно расчитывать.
Остальные цифры про деньги нужны для того чтобы подготовить реалистичный план миграции. Например я ожидал что кандидат предложит какое-то техническое решение и напишет сколько ему надо под это серверов, поэтому сразу писал граничные условия по важным вещам.
Вы хотите ПМа не тимлида.
Нет, я не хочу ПМа :) Мне был нужен технический руководитель. Хороший технический руководитель не junior уровня, должен учитывать в своих планах расходы на сервера, людей и ПО. Не обязательно в деньгах, но в штуках точно.
Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде.
Да, согласен. Я об этом прямо не писал в статье, но для меня тимлид это в первую очередь человек который руководит командой, а не пишет код. Я не ожидаю от него подвигов, но хороший технический бэкграунд и кругозор обязательны.
Возможно он имел ввиду планирование фиче беклога, как в скраме и разбиение фич на задачи для спринт бэклога, там вполне себе можно на пол года вперёд расписать количество спринтов, но потом корректировать по завершению каждого спринта. Это как раз задача тим Лида, ПМ не сможет разбить фичи на задачи по 4-8 часов, надо и архитектуру понимать и что от чего зависит и как правильно распаллелить.
Фантастические тимлиды и где они обитают
Какая толстая отсылка к почти одноимённому фильму. Вы что-то имеете против тимлидов?
Про фантастических тимлидов тема раскрыта, про «где обитают» не совсем.
Не могли бы вы осветить (в тех пределах, что позволяет коммерческая тайна), как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?
И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?
Сколько времени занял найм?
Я работаю в Минске. Тут рынок труда, конечно, поменьше, чем в Москве. Но, предполагаю, что ситуация в общем схожая. С такими критериями позиции закрывались бы настолько долго, что могли стать не актуальными. Даже на интересном проекте с высокими зп и вкусными печеньками.
как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?
На самом деле мы очень много людей без нужных скиллов звали на очное интервью, в надежде что они не написали, но умеют. Но очное собеседовать отнимает очень много времени, поэтому если буду нанимать в следующий раз, то буду обязательно делать скрининг. За тот же час, можно поговорить с двумя — тремя людьми, а не одним.
На обе позиции в сумме:
— отсмотрел резюме больше сотни
— на очное интервью звали человек 20-30
— до кейса дошло человек 7
— оферов соотвественно сделали 2
И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?
2 недели это «грязное» время. Реально люди же работают, занимаются своими делами, поэтому времени на подготовку уходит не так много. Кандидатов мы никак особо не мотивировали, все с пониманием относились к тестовому заданию. Мне кажется потому что все понимают, что позиция менеджерская, и цена ошибки при найме достаточно высока, поэтому с понимаем относятся.
Сколько времени занял найм?
Сейчас точно не скажу, но где-то 3-4 месяца на каждую позицию.
Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.
Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.
Для новых офисов в других городах мы еще не достаточно большие, нам проще помогать кандидатам с релокацией в Москву.
А для полностью распределенных команд мы пока морально не готовы. С ними нужно работать по другому, а у нас все процессы заточены сейчас на то что со всеми нужными людьми ты либо сидишь рядом, либо можешь пообщаться лично.
Ну и 3-4 месяца для поиска руководителя это не так много, мне кажется. Я сомневаюсь что в распределенную команду мы бы нашли человека быстрее.
Во-вторых многие раньше уходят из разработки, чем дорастают до руководился, либо меняют технологии внутри профессии чтобы поддержать разнообразие. Это слишком скучная, асоциальная и не подходящая и не благородная профессия чтобы её рассматривать на всю жизнь.
Ну и тимлид это не обязательно лучший разработчик в команде. Если есть желание быть тимлидом, то не надо в него расти качая знания в новых технологиях. Там нужны совсем другие навыки.
Фантастические тимлиды и где они обитают