Кейс Docsvision: как повысить скорость разработки?

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

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

Roadmap определяет приоритеты для команды – какие фичи команда разработки реализует, опираясь на стратегию. Запросов, идей и потребностей всегда больше, чем ресурсов на разработку. Можно ли делать больше, закрывать больше фич за спринт, не раздувая команду?

Чтобы решить эту задачу, большая команда разработки была разбита на несколько маленьких команд по 8-10 человек. Разработчик, тестировщик, аналитик – каждая команда кросс-функциональна и может решить любую задачу. Сделать функциональное требование, закрыть тех. долг, подготовить демостенд для пресейла, провести митап или консультацию – каждая команда может сделать всё, исходя из приоритетов.

Дополнительно есть одна «поддерживающая команда». В её составе системный аналитик, product owner, системный архитектор, дизайнер, devops, – если бы они входили в каждую команду, то раздули бы её снова до «неудобных» размеров. Задача поддерживающей команды – убрать любые препятствия, которые возникают на пути работы других команд, оптимизировать, помочь пройти через проблемы. Задача – помочь, а не руководить командами. Команды разработки свободны в выборе инструментов планирования, разработки, подключении дополнительных сервисов – всех вопросов по работе.

В результате реорганизации большой команды разработки на несколько маленьких удалось:

  1. Повысить скорость реализации новых функций в продукте
  2. Отрабатывать больше гипотез и делиться результатами друг с другом, ещё раз повышая скорость разработки
  3. Равномерно распределять разнородные задачи

Денис Елхов, руководитель отдела производства, рассказал о том, как команды «тащат» спринт за спринтом.

Как команды развивают платформу Docsvision и реализуют Roadmap?

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

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

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

Команды крайне независимы. Как они мотивируют себя?

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

Например, так у команд появились тимбилдинги. Одна команда придумала проводить тимбилдинги раз в месяц. Эта идея понравилась второй команде, но они поменяли правила и формат тимбилдинга. Когда ещё одна команда захотела провести тимбилдинг, то пригласила игрока из другой команды, который согласился помочь им с организацией.

Поддерживающая команда также стремится отмечать достижения команд, мотивирует быть яркими, «жечь» – в прямом смысле этих слов.

Как формировались команды? Как одна большая команда разработки разбилась на несколько маленьких?

Ох, как же кратко это описать? Условно, вся большая команда была приглашена в большую комнату. В комнате стояли стулья: сколько человек, столько и стульев. Стулья стояли за столами в соответствие с новым числом команд. Требовалось рассесться, чтобы сформировать команды и договориться о её названии. Когда команда придумала себе имя, то на 80% она уже сформировалась. Дальше команды выстраивали свой ритм, процессы.

Расскажи про «культурный код» Docsvision

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

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

При этом мы не ставим цели законсервироваться в текущем составе или размере штата, поэтому, если вы хотите присоединиться к команде специалистов и развивать платформу Docsvision вместе с нами, будем рады видеть отклик на вакансии «ДоксВижн».

Похожие публикации
17 апреля 2024
В этой статье мы рассмотрим практические кейсы перевода СЭД на ОС Linux.
21 марта 2024
Практические аспекты и опыт миграции БД в рамках СЭД на базе платформы Docsvision с использованием утилиты миграции.
Подпишитесь на рассылку
Нажимая на кнопку «Отправить», вы даёте согласие на обработку ваших персональных данных, в соответствии с политикой «ДоксВижн» в отношении обработки персональных данных.
Поддержка МЧД в СЭД Как изменится порядок подписания? Как подготовить предприятие к изменениям? Как адаптировать СЭД?