Движение вперёд: что делать, чтобы команда нашла общую цель

Рассказывают два agile-коуча.

Привет, с вами Steford. Мы стартап в Красной Поляне, который объединяет вокруг себя людей из ИТ. Среди прочего мы развиваем выездные кэмпинги — команды из ИТ-компаний приезжают к нам, чтобы поработать в коворкинге и пообщаться друг с другом в неформальной обстановке.

Совместные путешествия помогают командам сплотиться. Но что делать, если у компании нет возможности организовать сотрудникам поездку? Мы решили разобраться в этом и узнать, как общая цель помогает командам двигаться в одном направлении и самореализоваться всем её участникам.

В помощь мы позвали двух agile-коучей: Дмитрия Курдюмова из Smart Units и Кирилла Максимкина из Mars In.

Product Owner не должен писать детальное техническое задание и затем распределять задачи на каждого члена команды. Всё должно быть иначе: владелец продукта объясняет цели, вижн, приносит задачи, например, сформулированные в пользовательских историях. Затем команда самостоятельно придумывает, как решить ту или иную потребность пользователя.

При таком подходе сотрудники видят реальные потребности, потому что проработка идёт в тесном взаимодействии владельца продукта и команды. Соответственно, понимание, что мы делаем и зачем, становится яснее.

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

Чтобы изменить положение дел, в agile-командах сперва убирают распределённую ответственность, а вместо неё формулируют главную цель, которая приводит к общей ответственности за результат.

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

Третий шаг — вместо того чтобы спускать задачи сверху, на общее обсуждение приносится цельная пользовательская задача. Далее, обсуждая между собой, участники команды самостоятельно строят план её реализации.

Естественно, переход на новый формат — сложный процесс.

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

Культура по щелчку не меняется, поэтому всегда следует начинать со структуры, в которой появляются новые роли с новой ответственностью. Например в agile-командах за результат в итерации отвечает команда, а не проджект или продакт. Все вместе отвечают за достижение цели спринта и создание наилучшего решения.

Очень важно на старте правильно установить новую структуру, поэтому часто компании приглашают agile-коучей, которые смогут провести команду через сложный процесс изменений. И конечно, в новый формат нужно вовлечь и менеджмент — без его голоса изменений не будет.

Таким образом, чтобы команда начала жить по-новому, мы создаём для неё новые условия и требуем других результатов. И если с тем, что команда должна сама распределять задачи, мы разобрались, то вот с результатами вопросы остаются.

Смысл в том, чтобы в конце каждой итерации работы требовать показать работающий продукт на регулярной встрече (демо или обзор спринта). Люди постепенно привыкают к этому — и команда будет друг друга мотивировать и подстёгивать, чтобы поставленные задачи доводились до готовности. А затем вместе собирать у бизнеса обратную связь.

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

В конце добавлю, что главная ошибка, которая случается при появлении командного целеполагания и работы, — отсутствие прямого общения с бизнесом или пользователем.

Допустим, есть руководитель, который доносит проблему до разработчиков в формате: «Мне сказали, у нас такая-то проблема, надо решить». Но почему это проблема, почему её решение важно — эти вопросы не звучат, ответы на них тоже, а поэтому и люди не понимают, к чему всё это.

Поэтому также нужно вовлекать команду в бизнес. Собирать совместные встречи, чтобы разработчики задавали вопросы стейкхолдерам и пользователям. Прямой диалог без передатчиков упрощает коммуникацию.

Приведу пример из одной компании и расскажу, как мы проводили переход на Agile.

Вначале мы собрали agile-команду из добровольцев. Потом вместе с бизнесом и командами сформулировали продуктовые цели, выраженные в цифрах. Такой целью может быть «мы хотим улучшить конверсию в сообщение на сайте».

Далее на основе цели пересобрали бэклог задач продукта и вместе подумали, какие задачи нас приведут к цели.

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

По итогу пилота мы увидели, что в таком режиме работа шла лучше. Time to market упал в два раза — с шести до трёх недель, улучшилась прозрачность для бизнеса и качество решений. Стейкхолдеры начали видеть продукт каждые две недели. Количество обратной связи выросло.

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

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

Самая простая причина, по которой нет общей цели, — её просто никто не сформулировал. А порой она есть, но это огромное и длинное предложение, которое может занимать полстраницы. И это проблема — если цель нельзя запомнить или повторить, она бессмысленна.

При этом формулировать цель должен не один человек, а вся команда и заинтересованные стороны. Кроме того, менеджер продукта или тимлид должен обладать полномочиями, чтобы напоминать команде и другим участникам проекта о векторе, а заодно в любой спорной ситуации отрезать то, что цели не соответствует.

Ещё желательно, чтобы цель была измеряемой. Ты получаешь то, что измеряешь. И мерить нужно не только техническую сторону, но и продуктовую.

Из реальных примеров. Разработка отчётности для отдела продаж.

Цель звучала так: «Обеспечить компанию чёткими качественными данными, на основе которых можно принимать успешные бизнес-решения». Может звучать как «успешный успех», но оказалось, что это легко запомнить и под данную цель можно сформулировать метрики.

К примеру, метрика Usage Index — какие отделы и должности и сколько раз за месяц использовали отчёты. Или же то, сколько раз пользователи выгружали отчёт в Excel (чем меньше, тем лучше).

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

Вместе с тем в движении к цели играет роль вовлечённость. Члены команды должны чувствовать ответственность за то, что они создали. Цель и её формулировка будет их детищем.

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

При этом каждый раз, когда достигли какого-то промежуточного результата, нужно задаваться вопросом «глобальная цель по-прежнему актуальна?». Частота данного вопроса зависит от ритма работы.

Например, если речь о скрам-команде, то сверяться с целью продукта можно хоть каждый спринт. Если перед нами классический проджект-менеджмент, то ежемесячно. Так периодическая актуализация цели сохраняет мотивацию и вовлечённость.

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

Как правило, разработчики встречают эту идею в штыки. Часть из них привыкла работать по техническому заданию и просит их не трогать, но если они идут в мир agile, так не получится. Никто не будет заставлять общаться с людьми постоянно, но это и не презентация на 250 слайдов в стиле «садитесь, мы вам всё расскажем».

Смысл в том, чтобы общение с заказчиками было живым. Если вы разрабатываете приложение, то покажите его заказчику, а он пусть даст вам обратную связь.

Современным IT-командам важны возможность развития и свобода, но без хаоса. У разработчика есть цели, метрики, видение. Команда двигается в определённом направлении, но как именно по нему двигаться — решать самим разработчикам.

Как не ошибиться в этом процессе?

Например, тимлиду не надо становиться секретарём. Сто лет назад Генри Форд думал, что люди хорошо выполняют однотипные задачи, поэтому нужен кто-то, кто будет мысленно обдумывать эти однотипные задачи и назначать их. Конечно, это утрированное описание того, как в XX веке формировался классический менеджмент.

В наше время этот подход не сработает — слишком много неопределённости вокруг. Поэтому абсурдно считать, что один человек в состоянии решить, что делать целой команде. В конце концов, десять человек наверняка будут эффективнее в креативном порыве, чем один.

Сейчас мы видим нехватку кадров, поэтому отношение к людям как к винтикам вредит рабочему процессу. Любой человек уникален. Он личность со своим набором навыков, софт-скилов и личных предпочтений. И если должность заменима, то человек — нет.

Почему мы вообще считаем, что в корпоративном мире спускать задачи и указывать — плохо? Разработчики взрослые люди, зачастую даже с семьями. И уж если их наняли на работу, то и выполнение работы им доверить можно. Для этого не нужен кто-то, кто будет контролировать задачи.

#менеджмент #agile