Как организовать спринт так, чтобы команда не выгорала09.02.2024 11:30

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

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

Год назад, когда я пришла в IT-разработку Kokoc Group, в компании был целый список организационных особенностей, усложняющих решение задач:

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

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

Зачем выгорать, если можно не выгорать

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

Нереалистичные сроки: когда дедлайны слишком сжаты, и вы в постоянной ситуации работы наперегонки со временем, это может оказывать огромное давление;
Неясные ожидания: если члены команды не знают, чего от них хотят, или если цели постоянно меняются, это может привести к психологическому истощению;
Плохая коммуникация: в нашей сфере сотрудничество играет большую роль, поэтому нечёткая постановка задач может привести к недопониманию, переделкам и ненужному стрессу;
Недостаток ресурсов: нехватка инструментов, технологий или рабочих рук может сделать нагрузку слишком высокой;
Монотонная работа: выполнение одних и тех же задач без особого разнообразия приводит к потере интереса;
Дисбаланс между работой и личной жизнью: размытый график, переработки и отсутствие личного времени накапливают усталость, за руку с которой идёт и выгорание;

Чёткая структура — ключ к порядку

Зовите меня Капитан Очевидность, но первый шаг к эффективности и адекватному планированию — это структура. В данный момент мы ведём одновременную работу над сайтами заказчика и отдельным большим продуктом — платформой. Все задачи для команды синхронизированы в едином спринте, со стандартным сроком в 1 неделю. В Jira выстроена понятная группировка задач по проектам, релизам, типам специалистов и текущему статусу. Поток задач (workflow) задокументирован в регламенте работы группы.

Workflow задач в Jira

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

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

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

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

Голосование в командном чате

Кстати, кто эти мы и сколько нас? Команда состоит из 10 человек:

Тимлид;
3 backend-разработчика;
2 full-stack-разработчика;
1 верстальщик;
2 тестировщика;
менеджер проекта.

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

Понятность конкретной задачи обеспечивает подробная документация с описанной логикой фронтенд и бэкенд разработки. В моем прошлом опыте проектного управления требования подробно описывались в отдельных задачах, но так и оставались внутри таск-менеджера. Это делало процесс познания проекта сложным для тестировщиков или новых членов команды, а когда приходило время собрать комплексное описание, задача выглядела слишком объемной и до неё никак «не доходили руки». Сейчас я начинаю вести документацию в Confluence с самого старта проекта. Здесь информация упорядочена и доступна в одном месте. Если мы вносим изменения в структуру или логику между версиями, эти обновления также отражаются в документации под соответствующим номером релиза. Для специалистов при работе с новой фичей или страницей задача в Jira выглядит так: ссылка на Wiki с дизайном и детальными требованиями к бэкенду и фронтенду, а также краткие комментарии, если что-то нужно особо подсветить.

Wiki

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

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

Гибкость или дисциплина: why not both?

Стандартные дни релиза — это как звёзды на небе моряка или маяки, которые помогают не потеряться в океане задач. Поначалу мы больше ориентировались на пожелания от заказчика по очередной версии проекта: например, через 3 недели у клиента мероприятие, и нужно запустить лендинг с определенным пакетом информации, а также возможностью собирать заявки. Значит не позже, чем за 1 день до ивента, мы должны выложить лендинг в продакшн. Дисциплины при таком подходе меньше, а стресса больше: задачи затягиваются, баги от тестировщиков или правки от клиента не заканчиваются.

Теперь у нас фиксированный день релиза, и мы крайне редко его двигаем. Новые приоритетные задачи от заказчика, которые пришли после пятничного планинга, относятся уже к следующему спринту. «Релизный поезд» отходит по расписанию, а значит и дедлайн ключевых задач конкретного спринта понятен.

Случается ли, что регулярный рейс отменяется? Редко, но да, так как разработка это сложный процесс, и что-то может пойти не так. Для того, чтобы минимизировать вероятность переносов релиза, мы внедрили Регламент обработки багов — он призван помочь тестировщикам в понимании срочности и критичности ошибок в коде. QA оценивает баги и возвращает в разработку только те, которые очевидно мешают работе пользователей с ресурсом. Остальное правим в следующий спринт.

Календарь релизов в Jira

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

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

Но работа проектного менеджера не сводится к краткосрочному планированию, нам нужно уметь смотреть далеко за один спринт. Фиксированный день релиза помогает мне гибко спланировать свою неделю и распределить силы. Для качественной подготовки задач важно настроить собственную рабочую неделю так, чтобы проводить быстрый мониторинг текущего состояния дел, а большую часть времени оставлять на спокойную и вдумчивую аналитику. Даже с учётом 8-летнего опыта в сфере, пасьянс проекта до сих пор не всегда очевиден, и мне приходится взвешивать важность и сложность тех или иных доработок. В своем календаре такие слоты я называю «Focus time» и блокирую под них самые продуктивные часы. Иначе постоянные отвлечения на чаты и созвоны «обсудить голосом на 15 минут» могут сыграть с планами злую шутку.

И ещё к части задач я постепенно подключаю AI, но это спойлер моей следующей статьи, не переключайтесь.

Что ещё помогает в работе с проектом

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

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

Ротация кадров. Важный фактор, который может спасти команду от выгорания. Это не просто перетасовка специалистов, а инструмент повышения продуктивности и заинтересованности. При планировании задач мы стараемся давать сотрудникам возможность попробовать себя в чём-то новом. Когда с одного части проекта переходишь к другой, начинаешь понимать всю его комплексность, развиваешь навыки мультизадачности и растёшь профессионально. Кроме того, ротация помогает избежать «фактора автобуса» и спокойно ходить в регулярные отпуска. Факт: за последний год все в команде сходили в отпуск 2 раза по 2 недели, и я тоже. Work-life баланс соблюдён!
Отслеживание настроения. Иногда так случается, что человек приуныл и начинает искать другую работу. При этом не всегда возможно удержать его повышением зарплаты, так как он не дотягивает по хард скиллам. В таком случае я советую искать компромисс. Например, отдать сотруднику другие задачи, требующие погружения в новые инструменты, некритичные для бизнеса, но нацеленные на оптимизацию инфраструктуры проекта. Переключив его на другую зону ответственности, вы можете повысить мотивацию. Разработчик может перестать бояться, что у него не получится, если задача для него новая; начнёт проявлять инициативу при поиске решений; сам приходить с вопросами, если что-то не понял в описании. В общем, не теряйте веру в людей и их возможности.
Атмосфера команды. Скажу честно, я весёлый, но требовательный руководитель — к работе подхожу со всей серьёзностью. И всё-таки стараюсь делать общение человечным и увлекательным. Поэтому некоторое время мы проводили командные созвоны в виртуальном пространстве gather town: при входе ты настраиваешь своего рисованного персонажа и попадаешь вот в такой офис — с рабочими местами, кухней, самокатами и гигантскими шахматами в саду. Только из-за ограничений бесплатной версии мы ушли оттуда обратно в скучный мир Гугломитов. Так что, если вы придумали какую-то командную шалость — сделайте её, и спринт пройдёт на позитиве.

Gather town

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