Комментарии 12
Чтобы стать тимлидом в первую очередь нужно работать на бизнес и иметь возраст >20 с опытом от 3 лет.
Нужно просто остаться последним человеком на проекте ?
опять смешались кони, люди - тим лид нужен для управления командой, а не быть архитектором или супер пупер рок старом в разработке
тим лид нужен для управления командой, а не быть архитектором или супер пупер рок старом в разработке
Все верно, и не противоречит написанному в статье ?
Чтобы стать тимлидом - нужно убить предыдущего тимлида
Статья интересная, спасибо!
У меня есть вопросы по этому подходу:
Правда: в работе такое действительно встречается и приходится называть сроки на очень ранних этапах разработки. Всегда можно взять время на анализ задачи, но тимлиду необходимо понимать и транслировать бизнесу риски на ранних этапах разработки проекта в условиях неопределенности.
А не бывает потом проблем с тем, что команда говорит: "сроки спустили сверху, а нам за них отвечать?" или "сам назвал сроки, сам в них и влезай"
Не думали ставить отдельные встречи с командой для оценки трудозатрат по предстоящим задачам? Как относитесь к такому подходу?
Проводятся ли в компании архитектурные ревью? Если есть, то кто их проводит
Спасибо за обратную связь и вопросы! Отвечу на ваши вопросы.
Таких проблем не должно быть, если Тимлид синхронизирован с командой, понимает ее темп и возможности. Опытный Тимлид имеет хороший уровень экспертизы и погружение в контекст команды разработки – это позволяет дать наиболее адекватную оценку по срокам. Но конечно же Тимлид берет на себя ответственность за сроки, которые он назвал. Если сроки на каком то из этапов разработки начнут расходиться, важно погрузить в это бизнес заказчика и вместе проговорить компромиссное решение.
К оценке трудозатрат командой я отношусь нейтрально. Собираться всей командой и пытаться оценивать проект я бы не стал. Как правило, разработчики сильно погружаются в детали, и весь процесс оценки сильно усложняется, не просто фасилитировать такое обсуждение. Гораздо проще накидать предварительную декомпозицию проекта на отдельные модули/этапы, и там где меньше экспертизы посинкаться с экспертами в направлении – это сделать гораздо быстрее и проще. Когда то давно мы также пробовали внедрять покер планирование, но спустя небольшое время отказались, тк большой пользы не увидели. Но даже покер планирование требует предварительной проработки и декомпозиции проекта на задачи.
Архитектурные ревью мы проводим в рамках процесса с RFC и ADR. Когда прорабатывается какой либо проект, разработчик или системный аналитик готовит RFC, который должны посмотреть люди из состава архитектурного комитета, но при этом. любой член команды может также посмотреть RFC и оставить свои замечания/предложения. Архитектурный комитет состоит из старших и ведущих разработчиков.
Таких проблем не должно быть, если Тимлид синхронизирован с командой, понимает ее темп и возможности. Опытный Тимлид имеет хороший уровень экспертизы и погружение в контекст команды разработки – это позволяет дать наиболее адекватную оценку по срокам
Мне кажется, что тут слово синхронизирован взято в абсолют. Предположу, что в Тинькофф есть тим лиды, которые не спускаются в кодовую базу, так как попросту не хватает времени. Не знаю, какое соотношение в компании тим лидов, которые кодят, и которые проводят/не проводят ревью кода. Вторых может быть даже больше, судя по описанию обязанностей. Если тим лид не пишет код, то он вряд ли может предположить, как будет решаться та или иная задача
Давайте на примере. Допустим тим лид оценил эпик/задачу на 100ч/попугаев, учитывая прошлый опыт. Затем разработчик осознаёт, что задачу надо будет решить, используя кеш или БД или облако, что приведёт к увеличению трудозатрат вдвоё (или даже больше). Или даже упростим пример. Разработчик в ходе работы над задачей понял, что потребуется провести ADR (перепроектировать/расширить архитектуру). Хочется тут понять 2 вещи:
Это всё заранее прорабатывает тим лид, чтобы оценить примерные трудозатраты? А разработчики в компании максимум решают, какой паттерн использовать
Если тим лид этого не делает и даёт лишь высокоуровневую оценку, то как часто бывают случаи, когда в задаче стоит n часов/попугаев, а в результате получается сделать за >= 2*n часов/попугаев?
Если на второй вопрос ответ не часто, то, по-видимому, тим лиды дают оценку с запасом х3-х4, а то и более от реальных трудозатрат разработчика
Как стать тимлидом?