Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.
Это становится особенно заметно, когда компания сталкивается с одним из следующих вопросов: как собеседовать тимлида, как оценивать его работу, как составить ему план развития. Тимлиды тоже довольно много фрустрируют – они не понимают, насколько их текущий опыт работы останется релевантным при переходе в новую компанию, какие пробелы в знаниях и навыках существуют и как их можно заполнить. Короче говоря, куда не посмотришь, везде с тимлидами как-то сложно.
С этой проблемой столкнулись и мы со Стасом Цыгановым. Но в этот раз вместо того, чтобы обойтись простым решением текущих проблем, мы захотели подойти к вопросу фундаментальнее, собрать информацию об ожиданиях от тимлидов в разных компаниях и обобщить ее в единую общую модель. И, кажется, у нас получилось.
Роадмап
Роадмап содержит в себе два раздела:
- Роли и обязанности. Перечень высокоуровневых рабочих ролей и более конкретных обязанностей и зон ответственности.
- Personal Skills. Личные навыки и качества, наличие которых необходимо для определенных ролей и обязанностей.
Эту модель можно использовать как угодно – для составления собственного плана развития, для формирования должностных инструкций в компаниях, для составления вакансий или проведения собеседований. Учтите, что скорее всего вам нужны не все ветви потенциального развития – и это нормально.
Немного про роли:
- Resource Manager – управление людьми и командами.
- Administrator – управление проектами и процессом разработки задач.
- Technical Lead – технологии, качество, архитектура, автоматизация.
- Product Owner – управление продуктом, целями и бэклогом.
- Integrator – понимание бизнеса, ценностей и структуры компании.
Почему роадмапу можно верить
Основная проблема, о которой я уже упоминал – это разница в восприятии роли тимлида в разных компаниях. При составлении общей модели нельзя было опираться только на наш опыт работы в Авито, Туту и Рамблере. Нужно было исследовать больше компаний.
Начали мы со сбора информации, создав рабочую группу из десятка человек, которые поделились информацией о том, кто такой тимлид в их случае. В этой группе приняли участие руководители разработки как из российских, так и зарубежных компаний, как из небольших стартапов, так и очень крупных заведений. Первый брейншторм подтвердил нашу изначальную гипотезу. Несмотря на большое количество различий, все ожидания и обязанности можно было обобщить в несколько отдельных кластеров-ролей.
Дальше мы ушли детально прорабатывать каждую роль, разделяя ее на ветки и листья с непосредственными обязанностями тимлида, стараясь одновременно не перегрузить роадмап и не сделать его слишком абстрактным. Каждая из обязанностей связана с описанием в базе знаний, которое раскрывает следующие секции:
- Что это за ветка?
- Почему ветка важна?
- Что будет, если ее не делать?
- На кого можно ее делегировать?
- Примеры поведения
- Способы прокачки
Получившуюся структуру мы валидировали через серию интервью с руководителями разработки из разных компаний. На интервью мы задавали серию вопросов, чтобы узнать все обязанности тимлида в компании, и одновременно отмечали их на своем роадмапе. В конце получившуюся модель мы показывали интервьюируемому и проводили финальную валидацию. Судя по результатам, мы практически ничего не упустили.
Как роадмап использовать
Для компании
- Скачайте себе Mindmap с полной моделью тимлида.
- Изучите все ветви обязанностей тимлида. Удалите те, которые в вашей компании не требуются, либо уже выполняются кем-то еще.
- Сформируйте из получившейся карты нужные вам артефакты: профиль для найма, описание ожиданий от роли, план развития.
- Для углубления в любую из веток используйте нашу базу знаний. Для каждой из веток мы детально описываем ее смысл, мотивацию к использованию, примеры хорошего и плохого поведения, способы развития на практике и в теории.
Для тимлида
- Скачайте себе Mindmap с полной моделью тимлида.
- Отметьте на нем те компетенции, которыми вы уже обладаете и те, которые вам требуются для дальнейшего роста внутри компании. Для подсказки – посмотрите на то, чем занимается ваш руководитель или коллеги. Если тут все еще есть сложности – задайте вопрос в нашем чате.
- Составьте список с теми компетенциями, которые находятся между вашим текущим профилем и целевым.
- Используя нашу базу знаний, сформируйте себе план развития по каждой из компетенций, который включает в себя теорию, консультации и практическое применение.
- Покажите свой план развития руководителю и попросите содействовать в нем.
Работа над роадмапом только начинается – мы делаем первый релиз и нам очень важно собрать еще больше фидбэка:
- Насколько предложенная структура ложится на вашу компанию?
- Каких навыков не хватает в отдельных ветках?
- Какого контента и ссылок не хватает в описании в базе знаний?
Пишите комментарии к статье, issues на GitHub и предложения в наш чат!
Комментарии (18)
Ghedeon
24.07.2019 16:58Так это, тимлид же все. Не по скраму. Оказалось, при хорошем тимлиде очень трудно втюхать фирме скрам-мастера. Эти роли конфликтуют и соревнуются за влияние и кол-во митингов, которые каждый может назначить. Тимлид, грешным делом, может навести порядок, а это прямая угроза эджайл коучу. Текущий тренд: тимлид — роль деспотичная, авторитарная. Ограничивает свободу и креативность команды. Вопиющая несправедливость в эпоху эгалитаризма. Только равенство и плоская иерархия, за все отвечает «команда» и никто в частности.
VolCh
24.07.2019 19:37Если смотреть на роли в посте, то чистый тимлид (без обязанностей техлида) совмещает роли ПО и скрам-мастера. Если тимлид не віполнет обязанности ни техлида, ни ПО, то он скрам-мастер :)
sparhawk
24.07.2019 20:09+1В теории плоская иерархия, SCRUM и самоуправляемая команда с полностью взаимозаменяемыми senior разработчиками — это замечательно. На практике все стараются нанять вчерашних студентов или тех, кто готов работать за небольшие деньги, и одного ведущего над ними, который становится тимлидом. Такой тренд я вижу чаще.
chilicoder
25.07.2019 00:21+1Это нормально. Если у вас тимлиды, значит вы выстраиваете классическую иерархическую модель управления с персонифицированной ответственностью. Если скрам-мастеры, то у вас коллективная ответственность команды.
У вас не роли конфликтуют, а подходы к ответственности (и полномочиям)
>тимлид — роль деспотичная, авторитарная. Ограничивает свободу и креативность
Это стереотипы. Тимлид также может быть Y руководителем, сдувающим пылинки с членов команды.
Выбор подхода определяет конкретная ситуация (извините, что банально). А именно, насколько много ответственности возложено на команде. Как много систем нужно поддерживать, как часто происходят форс-мажоры, со сколькими другими группами нужно держать контакт и тд.
Чем больше когнитивная нагрузка, тем выше вероятность, что если вы поставите одного человека отвечать, ему разорвет мозг и он станет боттлнеком, тормозящим процесс.
Но не думайте, что командная ответственность это модно, стильно, современно. Чтобы это заработало нужно построить команду из опытных членов, выстроить доверие внутри этого мини-коллектива, следить за коммуникацией и многое другое. Иначе будет просто бардак.
0x1000000
24.07.2019 23:26Вообще странно, что позицию тим лида рассматривают как промежуточную или даже тупиковую. По моему мнению, это вершина профессионального роста работника из IT сферы после которой наступает лишь деградация, ведь основной признак тим лида — это способность заменить ЛЮБОГО члена команды, пусть и не со 100% эффективностью, то есть своего рода "стволовая клетка " в организме проекта.
VolCh
26.07.2019 15:13Вовсе не обязательно тимлид должен быть способен заменить любого члена команды. Его задача, чтобы команда продолжала работать даже если одного человека не будет по каким-то причинам. Самому быть готовым заменить, дублировать компетенции, хоть формально (минимум 2 QA, 2 фронта, 2 бэка, 2 девопса), хоть путём набора/развитиея T и Ш специалистов ("фуллстэков"), иметь допбюджет и полномочия на например контракторов на время болезни сотрудника — это лишь инструменты достижения цели
pprometey
25.07.2019 07:08Действительно, очень основательный поход. Заморочились что называется. Остается только поблагодарить.
testopatolog
26.07.2019 12:43Ряд пожеланий к «снежинке» (чем-то она мне всё-равно не нравится):
1. в ветку «Построение цикла разработки > Получение задач» добавить листьев:
— Обследование
— Анализ
2. в ветку «Technical Lead»:
— подветвь «Обеспечение качества продукта > Тестирование» добавить лист:
Администрирование test-ландшафта
— подветвь «Обеспечение технического качества» добавить лист:
Администрирование dev-ландшафта
3. в ветку «Resource Manager > Управление командой»:
— добавить лист Ресурсные конфликты
— убрать «Обеспечение прозрачности», т.к. Прозрачность — это ценность (см. «Integrator > Ценности» — пусть там их и обеспечивают).testopatolog
26.07.2019 19:02Также, по-моему (кто тонко понимает, надеюсь, это увидели), большое заблуждение Автора — смешать в одну кучу на роадмап «Teamlead > Technical Lead > Обеспечение качества...», т.е. хочу сказать, что стратегически грамотнее развести это в разные ветви:
1. «Teamlead > Technical Lead»
2. «Teamlead > QA»
и соответственно получается:
1.1 «Teamlead > Technical Lead > Знание технологий»
1.2 «Teamlead > Technical Lead > Архитектура»
1.3 «Teamlead > Technical Lead > Capacity Management»
Примечание 1: к пп. 1.3 добавить листья:
— ресурсы
— IT-услуги
— бизнес
2.1 «Teamlead > QA > Обеспечение качества продукта (QC) > ...»
2.2 «Teamlead > QA > Обеспечение технического качества > ...»
2.3 «Teamlead > QA > Автоматизация цикла разработки > ...»
2.4 «Teamlead > QA > Управление знаниями > ...»
И соответственно роли надо подправить:
Resource Manager – управление людьми и командами.
Administrator – управление проектами и процессом разработки задач.
Technical Lead – технологии,качество,архитектура, автоматизация.
new QA – качество, автоматизация, управление знаниями…
Product Owner – управление продуктом, целями и бэклогом.
Integrator – понимание бизнеса, ценностей и структуры компании.
Durimar123
26.07.2019 15:50Я правильно понял(из вашего подхода), тимлид — это в каждой бочке затычка?
Иначе: если никто эту функцию не выполняет, значит это функция тимлида.
ответственный определен — бизнес спасен
jaddd
26.07.2019 17:19Очень интересно!!!
Хотя, конечно, отличие верхней ветки от нижней не очень большое. И там и там есть и hard skills и soft skills, просто пропорции разные.
puyol_dev2
Вопрос — сколько можно выиграть в произвотительности труда, используя такие методики, и стоят ли они затраченного времени на их разработку?
YourDestiny Автор
18%, проверено!
puyol_dev2
Это не шутка? Как считали?