❓Что будет с командой, если тимлид исчезнет на 2 недели?
❗️Продолжатся ли дейлики и планирования? ❗️Сможет ли команда сама разобраться с блокерами? ❗️Кто пойдет к бизнесу, если нужно принять решение? ❗️Кто поднимет риск по срокам? ❗️Или большая часть вопросов просто будет ждать возвращения тимлида?
Для меня это один из главных признаков зрелости команды: она должна уметь двигаться вперед без постоянного участия лида.
Я провел диагностику автономности своей команды в Авито и на ее основе собрал Team Autonomy Playbook - практический гайд о том, как постепенно снижать зависимость команды от тимлида.
Не в формате «теперь разбирайтесь сами», а через понятные роли, правила принятия решений, делегирование и постепенную передачу ответственности.
✔️ Почему это может быть полезно:
1. Команда становится устойчивее
Если тимлид уходит в отпуск, заболевает или просто на несколько дней выпадает из операционки - процессы не должны останавливаться.
2. Ответственность распределяется внутри команды
Не нужно выращивать одного «заместителя тимлида» и создавать новую точку зависимости.
Команда учится сама проводить ритуалы, поднимать блокеры, принимать локальные решения и коммуницировать с PM, бизнесом и смежными командами.
3. Автономия становится управляемой
Одна из проблем делегирования - непонятные границы.
Поэтому в playbook есть простое разделение: → что команда решает сама; → где достаточно уведомить; → что обязательно нужно эскалировать.
4. Меньше хаоса в спринте
Внутри собрал готовые чеклисты для daily, planning, refinement и retro, правила работы с блокерами, роли Shadow Lead / Facilitator / Task Owner, схему на случай отпуска или болезни тимлида и метрики автономности.
Отдельно добавил план внедрения на 3 спринта, чтобы автономность не осталась красивой концепцией, а постепенно превратилась в рабочий процесс.
📕 Для меня здесь важна одна мысль:
Автономная команда - это не команда, которой не нужен тимлид. Это команда, которой не нужен тимлид для каждого следующего шага.
Playbook сделал универсальным, поэтому его можно взять за основу, адаптировать под свою команду и дополнить своими практиками.
Выложил всё в открытый доступ на GitHub.
🔗 Ссылка
· 3 ч
В моем случае, работа как шла так и идёт. Если задачи в бэклоге окончились всегда есть тесты и рефакторинг. Всегда есть список тудушек которые наконец то можно взять.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 3 ч
Это хорошо, но я имел в виду более широкие границы автономности. Например, если команда полностью продуктовая и выпускает релизы каждые две недели, то автономность - это уже не только самостоятельно взять задачу из бэклога и написать тесты.
Здесь появляется гораздо больше ответственности: межкомандное взаимодействие, работа с бизнесом и стейкхолдерами, управление сроками и рисками, принятие решений, решение блокеров и доведение задач до релиза. То есть вопрос скорее в том, насколько команда способна самостоятельно вести весь процесс - от идеи до результата, не завязывая каждое решение на тимлида.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 2 ч
Мм мм... По разному бывает. Особенно с решением блокеров. Тут как правило у начальства лоб толще, нижняя челюсть увесистее и круг связей шире.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён