Как избежать выгорания команды разработки?

Достаточно популярная задача в ИТ-компаниях – делать много. В основном, делать очень много, быстро и при ограниченных ресурсах. Результат такой скорости – возникновение свалки в бэклоге и бесконечный техдолг.

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

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

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

Сегодня в данном подразделении работают 26 человек. Из них только разработкой, без тестирования, занимаются 13 программистов. Одновременно в развитии находится несколько продуктов (ЗУП, БУХ, УТ11, WOS, WMS). Так как идёт развитие ещё и web-продуктов и мобильных приложений, то к этому прибавляются задачи по интеграции. Про поддержку сразу обозначим, что это другой тип задач, которые могут быть решены быстро. И это отдельно ещё одна выделенная команда из 5 человек, осуществляющая круглосуточную поддержку пользователей из разных регионов. Такой институт дежурных специалистов позволяет команде двигаться вперёд значительно быстрее.

Ключевые изменения, реализованные руководителем направления:

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

2. Выделение ролей в каждой команде с чётко обозначенными границами деятельности и зоной ответственности. На текущий момент в каждой команде есть: продакт, техлид, разработчики, аналитики, тестировщики и менеджеры хранилищ. У каждого продукта есть product owner и релиз-менеджер. Такая «развесистая» ролевая модель позволила чётко определить зоны ответственности каждого сотрудника, сфокусировать его на чётком наборе обязанностей, которыми он хорошо владеет, сделать распределение задач и жизненный цикл продукта прозрачными.

3. Оценка компетенций каждого сотрудника. Это позволило быстро и правильно принимать решения по формированию команд под цели конкретного проекта и осуществлять ротацию между ними. Растить таланты.

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

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

6. Архитектурный комитет. Как только команд становится больше одной, на первое место встаёт вопрос синхронизации между ними. В техническом ракурсе мы возложили эту ответственность на наших техлидов. Они стоят на страже совместимости доработок, выполняемых параллельно нашими командами. Они видят взаимное влияние механизмов и по необходимости оперативно проводят синхронизацию. Также раз в 2 недели проходит обязательное собрание архитектурного комитета, на котором мы не только проводим «архитектурное ретро», но и вырабатываем план по развитию архитектуры наших продуктов, стандартов и практик разработки. На выходе мы получаем постоянный рост технического уровня нашей разработки.

7. Ключевые задачи в особом фокусе. В продуктовой разработке часто поток мелких задач размывает видение и можно упустить что-то важное. Чтобы этого не допустить, ключевые задачи (в том числе боли) бизнеса мы ведём отдельно от общей массы и отдельно контролируем. Это позволяет нам не утонуть в текучке и фокусироваться прежде всего на самом главном.

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

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

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