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

Для тех, кто не знает: SkuVault — это система управления складом (WMS). Подобно швейцарскому ножу, SkuVault управляет вашим инвентарём и синхронизирует его между платформами электронной коммерции, POS-системами, логистикой и складами, обеспечивая точные остатки, чтобы предотвращать отсутствие товаров в наличии. Штаб-квартира SkuVault находится в Луисвилле, штат Кентукки; компания помогает управлять запасами сотням клиентов по всему миру.

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

Наблюдательное исследование и сценарии оптимизации

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

- Нет тимлидов. Это означало, что разработчики разбивались на команды для code review и проверяли код друг друга.
- Технологический стек (.NET в SkuVault против Scala / Riak / react.js в Storia). При всех плюсах и минусах, в командах .NET-разработки нет столь чёткого разделения на BE / FE: бэкенд-разработчики могут работать над фронтенд-задачами через ASP.NET MVC, поэтому наши разработчики больше похожи на (..универсальных солдат).
- В рабочем процессе нет этапа UX / UI-дизайна. Именно эта часть делает принятие любых решений намного быстрее. Сам продукт (приложение SkuVault для управления складом) использует Bootstrap и с точки зрения дизайна очень утилитарен. Ключевой фактор здесь — простота использования (насколько это вообще применимо к промышленному приложению).
- Распределённая команда по обе стороны Атлантики, покрывающая почти 24-часовой период.
- SkuVault используют сотни клиентов по всему миру, исправления ошибок происходят ежедневно, и у ошибок разные приоритеты. Этот момент плохо сочетается с типичными циклами «спринт->релиз» (потому что приоритеты могут меняться довольно быстро или что-то нужно срочно выпустить).

Учитывая все эти различия, я начал упорядочивать рабочий процесс в JIRA.

Статусы, переходы, рабочий процесс

Мне удалось сократить количество статусов.

- Было: 23 (при этом между любыми статусами были разрешены любые переходы)


- Стало: 9 (с чёткой последовательностью статусов, отражающей состояние ошибки / новой функции).

Большинство статусов были избыточными; некоторые я заменил сочетанием «метки + статус», а некоторые были устранены и заменены обобщёнными статусами (например, статусы «Design Holds», «Client Clarification» изменены на статус: Hold + метка «IncompleteDescription»).

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

Общий поток и действия каждого участника команды (BA / PM / Dev / QA) описаны в нашей wiki, как и терминология, список применяемых меток (для меток есть специальный глоссарий). Я объясняю рабочий процесс как последовательность шагов, чтобы имелась инструкция на случай чрезвычайной ситуации или адаптации нового сотрудника.

Дежурные команды

В течение первой недели мы начали просить разработчиков заполнять небольшую анкету, чтобы выяснить, как часто их отвлекают от разработки новых функций срочные запросы клиентов или исправления ошибок, требующие немедленного внимания. Оказалось, что значительное время (до 80%) занимали срочные задачи, которые отвлекали разработчиков и снижали эффективность их работы.

Поэтому управленческая команда (точнее, это скорее PM, CEO, CTO и руководитель поддержки) решила создать команды дежурных разработчиков. Эти команды (2 разработчика: Frontend и Backend) работали бы только со срочными тикетами, позволяя остальной команде работать над обычными задачами, в идеале — без отвлечений.

Концепция дежурной команды несколько раз переосмысливалась, и сейчас мы стремимся иметь по 3 дежурных разработчика в каждой смене, поскольку клиентская база значительно выросла, а вместе с ней — запросы, задачи и точки внимания. Некоторых разработчиков по-прежнему привлекают к срочным задачам, поскольку SkuVault сильно зависит от интеграций с другими SaaS- / eCommerce- / системами доставки, которые меняют свои API, совершенствуют продукты и иногда могут изменить способ взаимодействия с нашей системой. А у дежурных разработчиков могут возникнуть вопросы к разработчику, изначально создавшему интеграцию.

Тем не менее сама концепция оказалась чрезвычайно полезной, и в целом проблема решена.

Наставничество

Это обычная практика, когда у вас есть старшие и младшие разработчики :) Чтобы прояснять вопросы общей архитектуры системы, старшие разработчики наставляют остальных и проводят code review.

Стандарты описания тикетов

Создание чётких рекомендаций по заполнению полей и обязательной информации для ошибки / новой функции / или любого другого типа задачи необходимо для упорядочивания разработки.

Переход от Kanban к гибридному Scrumban

Если кратко, год назад доски разработки (одна для планирования, другая для разработки) включали множество статусов, были чрезвычайно тяжёлыми (ведь нужно отображать около 1 тыс. тикетов) и сложными в управлении. Респект Тиму Дженнейсу и команде, которым удалось смело (и успешно) работать с этой доской и поддерживать её!

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

- Доска разработки, где тикеты переходят от ToDo к Ready to Release: Scrum-доска;
- Доска срочных задач, которой пользуются дежурные команды и которая включает только тикеты Critical и Blocker: Kanban-доска;
- Доска контроля качества, где разработчики и менеджеры по тестированию могут увидеть объём тикетов, которые им нужно проверить: Kanban-доска;
- Доска релизов, чтобы менеджер релизов мог просматривать и управлять тикетами, которые следует слить в master: Kanban-доска.

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

С другой стороны, чистые циклы спринт -> релиз не отражают работу SkuVault из-за срочных задач, которые нужно выпускать почти ежедневно. Поэтому спринты здесь больше похожи на папки: они позволяют нам прогнозировать примерные или конкретные даты начала / релиза для тикетов и ограничивать объём функций в заданный период времени. Поэтому это и называется ScrumBan :)

Уведомления, сроки и т. д.

Я также настроил автоматические уведомления по электронной почте о Pull Request или задачах, которые не проходят ревью / тестирование более 2 дней.

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

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

Ключевые выводы этого года:

- Не делайте сам релиз целью. Цель — качественный продукт. Поэтому можно пропустить один или два релиза, но выпустить что-то хорошее. Даже если клиентов много, они поймут важность стабильности, а не функции, которую хотят получить в первую очередь;
- Пишите ретроспективы проблемных моментов, чтобы укреплять основу своего опыта для себя и других. Старайтесь собирать дополнительные данные и мнения внутри команды, чтобы рассматривать проблему под более широким углом;
- Делайте всё возможное, чтобы поддерживать хорошие человеческие отношения с разработчиками и другими членами команды. Вы коллеги, и хороший человек всегда постарается сделать всё возможное, если он мотивирован (см. статью о мотивации);
- Горизонтальная иерархия и немного анархии разработчиков — это всегда хорошо. Голос каждого члена команды должен быть хотя бы услышан;
- Постоянно обновляйте обратную связь команды о том, как идут дела: это необходимо, чтобы поддерживать поток актуальным и решать проблемы, которые могут быть у разработчиков. Ведь в IT именно команда определяет успех, а задача хорошего менеджера — облегчать работу и мотивировать людей;
- Поддерживайте комфортный темп релизов для команды и клиентов;
- Читайте профессиональную литературу, но не забывайте проверять, как это работает в реальности :)
- Всегда есть место для оптимизации. Вам просто не хватает времени! Можно тратить дни на микроменеджмент, чтобы позднее экстраполировать оптимизацию на глобальный поток. Бесконечная увлекательная работа.
- Поддерживайте баланс работы и личной жизни. Не позволяйте команде перерабатывать.

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

Спасибо Ксении, Славе и Ким за ревью, а команде SkuVault — за поддержку.