iTechArt logo

Софт скилы тим лида: что такое ориентированность на результат?

Development & QA

Руководитель команды в IT — позиция, требующая определенных софт скилов. Ориентированность на результат, способность принимать решения, умение делегировать, общение и построение отношений, менторинг и мотивирование — шесть необходимых навыков для этого специалиста. 

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

Наш собеседник
Павел Ханкевич.jpg

Павел Ханкевич

Team Manager iTechArt

Успешно совмещает нынешнюю позицию с лидингом на проекте.

Что же такое «ориентированность на результат»?

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

Допустим, вы тим лид. Вам нужно оценить производительность своей команды:

  • Бэкенд-команда проекта включает в себя тим лида и двух разработчиков: Машу и Олега. Релизы — каждую неделю. Маша работает над критическим багом, Олег — над задачей.
  • В середине недели выясняется, что Маша исправит баг, но будет это делать до конца недели. Олег уже никак не успевает исправить свою задачу, но к следующему релизу будет готово.

Это важная информация, но для тим лида, который должен оценить производительность, она бесполезна. Пока. Ему необходимо знать, какие цели стояли перед командой до релиза, чтобы сравнить обещания с результатом. Давайте поставим цели:

Закончить задачу. Исправить баг.

Цели выставлены, выглядит так, будто мы не справимся: Маша разберется с багом, а Олег не закончит задачу. Но есть ощущение, что чего-то не хватает. Сроки завершения? Приоритеты? Это все относится к прозрачности целей.

Для чего нужна прозрачность целей?

Непонятные цели хуже, чем просто отсутствие каких-либо целей. Добавим ожидаемые сроки выполнения:

Закончить задачу за 2 недели. Исправить баг до релиза.

Кроме сроков стоит упомянуть и о приоритетах. Нам они помогут понять, что сейчас важнее:пофиксить баг или реализовать задачу. Можно, конечно, ввести понятие приоритета для каждой сущности. Тогда понятно, какой баг важнее. С задачами то же самое. Что тогда делать при равном приоритете бага и задачи, непонятно. Зададим приоритет через общий, пронумерованный список:

  1. Закончить задачу за 2 недели
  2. Исправить баг до релиза

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

Для чего нужна оценка целей?

Оценка целей не менее важна, чем их прозрачность. В нашей ситуации, Маша могла бы сказать, что не успеет исправить баг до релиза. Это новая информация и повод подумать над вариантами решения. Возможно, стоит подключить Олега? С его помощью команда успеет и пофиксить баг, и реализовать задачу в указанный срок. Это, опять же, нужно обсудить с командой, чтобы вместе оценить вероятность успеха.

Не стоит забывать и о приоритетах. Выясняется, что баг Маши оказался критическим. Критикал баг звучит как что-то, что должно быть исправлено в первую очередь. Вы все еще не умеете читать мысли. Если бизнес пообещал демонстрацию задачи Олега к сроку релиза через 2 недели и баг ставит под угрозу данные планы, он может легко поменять приоритет. И вам надо будет уже рассматривать вариант подключения Маши в помощь к Олегу.

Павел Ханкевич, Team Manager

Изначально полагаясь на реалистичные оценки и говоря правду, не придется после придумывать оправдания за заранее недостижимые результаты.

Так что же все-таки такое этот «успех команды»?

С понятными и оцененными целями мы теперь можем оценить успех команды. В начале пути у нас имелся тим лид и два независимых разработчика: Маша и Олег. Развиваясь, команда работала как единый механизм, который придумывал цели, оценивал их и действовал сообща. Это главный результат. Теперь не Маша исправила баг, не Олег выполнил задачу, а команда достигла успеха. 

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

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

Павел Ханкевич, Team Manager

Определение успеха команды важно как для указания направления команде, так и для сравнения успеха итераций и корректировки планирования.

Какие инструменты помогут тим лиду для достижения результата?

Не стоит придумывать велосипед. Существует много практик и методологий для лидов и команд, некоторые из которых я неявно использовал в примере с Машей и Олегом. Agile, Scrum, Kanban — популярные инструменты управления проектами. Для средне-легких проектов, таких, как мы разобрали в примере, они отлично подойдут.

Agile

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

Scrum

Scrum — это одна из методологий Agile для управления проектами. В ее основе — серии итераций фиксированной продолжительности, называемых спринтами.

Привяжем недельные циклы релиза к спринтам. Теперь 1 спринт равен 1 неделе. Это позволит использовать ключевые точки спринта: планирование, ежедневные стендапы, демонстрация спринта, а также ретроспектива. В ходе планирования определяется объем работы на спринт и способы выполнения этой работы. Для синхронизации работы команды — ежедневные стендапы. Демонстрация фокусируется на том, что было выполнено. Ретроспектива посвящена тому, как была проделана работа.

Такие артефакты Scrum, как project backlog и sprint backlog, тоже тоже будут полезны. Они нужны не просто для того, чтобы перетащить задачи в спринт. Они дадут представление о планах на будущее. Так вы сможете более стратегически планировать свои спринты и не брать не до конца понятные и оформленные задачи. Scrum board визуализирует текущее состояние задач команды. Введение понятий capacity и velocity дадут возможность посчитать количество взятых и законченных задач и с этими данными скорректировать количество запланированных задач на будущее. Sprint goal позволит указать цель для спринта и оценить успех.

Кажется, практики Agile и Scrum могут избавить нас от всех проблем. Кроме одной. В методологии Scrum команды расставляют приоритеты в работе и выполняют определенное количество задач в течение спринта. Как же быть, если посредине спринта появилась незапланированная задача, например, Маше понадобилась помощь с багом?

Kanban

Kanban не ограничивается итерацией или спринтом — он поддерживает непрерывную доставку. Когда мы не можем полагаться на запланированные спринты и нам приходится реагировать незамедлительно, когда требования, сроки и приоритеты могут поменяться, я рекомендую использовать Kanban. Здесь разница скорее ментальная. Scrum-board и Kanban-board практически идентичны. Нюанс в том, что изменять Scrum-board разработчики не могут, в отличие от Kanban.

KPI & SMART

Для постановки целей тоже есть свои методологии, например: KPI и SMART. KPI расшифровывается как Key Performance Indicator. Этот термин относится к измеримой ценности, которая показывает, насколько эффективно организация достигает своих общих целей компании. В то время как SMART — аббревиатура от «Конкретный, измеримый, достижимый, реалистичный и своевременный». Мы выставляем KPI для целей бизнеса, проекта, команды, тогда как SMART используется для целей конкретных сотрудников. В нашем случае KPI для команды такой: «снизить количество багов системы до 0».

В то время, как SMART цель для Маши будет выглядеть следующим образом:

  • S — Исправить баг
  • M — Написать автоматизированные тесты, чтобы проверить наличие ошибок
  • A — Команда достаточно квалифицирована и имеет достаточно времени
  • R — Баг является блокером и имеет максимальный приоритет для заказчика
  • T — Фикс должен быть готов до релиза

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

Выбирать инструменты и практики следует из необходимости. Если проект управляется методологией SCRUM, он всё ещё разрабатывается и не релизнулся, а сроки не горят, то внедрять Kanban для переоценки задач и их приоритетов посередине итерации бессмысленно.

Выбирать инструменты нужно, ориентируясь на проблемы. Если проект в активной стадии поддержки, он достаточно простой и приоритеты меняются быстрее, чем открывается IDE, то разумнее выбрать Kanban.

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