По 300 релизов в месяц: как мы выстроили процессы и до сих пор не выгорели

Привет, это Миша Шпаков из Timeweb Cloud. Вообще я управляю отделом разработки, но отдел маркетинга по-дружески попросил написать статью на VC.

Рассказываю об устройстве команды из 25 фулстек-разработчиков, которые каждый месяц делают сотни релизов.

Но для начала дисклеймер.

Timeweb Cloud — облачная платформа, появившаяся в конце 2021 года. Она принадлежит группе компаний, создавшей одноименный хостинг.

Предоставляя облачные решения, мы помогаем клиентам по всему миру в создании, управлении и масштабировании IT-инфраструктуры. Обеспечиваем защищенное хранение данных, а также предлагаем управляемые сервисы Kubernetes, DBaaS и другие продукты как для бизнеса, так и для частных лиц.

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

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

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

Шаг №1. Потратили время на вижн и планирование релизов

Первым делом мы поставили глобальные цели на 3-5 лет вперед, согласовали их с инвесторами и фаундерами. Далее сформировались итерации на полгода или год.

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

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

Шаг №2 Сформировали команду

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

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

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

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

Все разработчики Timeweb Cloud — фулстек. Говоря простым языком, эти ребята могут все: и красивый интерфейс сверстать (frontend), и архитектуру сделать (backend). Прежде чем прийти к такой схеме, мы пробовали набирать команду с классическим делением: front и back отдельно.

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

Команда фулстек-разработчиков дает нам максимальную скорость: мы можем брать ASAP-задачи, работать с трендами и менять вектор. Тем не менее часть команды стабильно закреплена за важными для бизнеса проектами — они занимаются конкретным продуктом и не двигаются из релиза в релиз.

Шаг №3 Проработали алгоритм для ASAP-задач

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

Например, когда тренд с нейросетями был на пике популярности, мы внедрили TimewebGPT на базе GPT 3.5 в службу поддержки Timeweb Cloud. Искусственный интеллект стал отвечать на вопросы пользователей. Из-за оперативного внедрения проекта в роадмап, часть разработчиков поставила на «стоп» текущие задачи и перешла работать с новым продуктом. Так у нас появился TimewebGPT в короткие сроки.

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

1. Получение и анализ ТЗ от продактов

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

2. Разработка решения и доставка кода

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

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

3. Постревью

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

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

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

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

Такая скорость выпуска релизов дала нам пару корпоративных традиций.

Пятничные «Демо». Из-за сжатых временных рамок и формата дейликов мы создали традицию пятничных встреч.

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

Сначала на таких встречах был только наш бизнес-модуль, но с каждым новым «Демо» к нам присоединялось все больше коллег из других отделов Timeweb.

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

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

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

Так, локальный чат вырос в новостной канал, в котором мы собрали активное комьюнити IT-специалистов, наших клиентов и тех, кому интересна тема облачных технологий.

Кстати, подписаться на него можно по ссылке.

• Планируйте релизы и определяйте степень приоритетности задач на старте. Пока вы не будете понимать, к чему вы должны прийти, вы не сможете определить маршрут.
• Собирайте команду исходя из запросов бизнеса. Нужно четко проанализировать задачи и уже под них подбирать исполнителей.
• Продумайте план адаптации работы к обстоятельствам: как вы будете реагировать на срочные запросы, тренды или последствия ошибки сотрудника.
• Не прячьте «внутреннюю кухню» — ваша корпоративная культура может стать имиджевой особенностью компании.

* * *

Такой путь нам пришлось пройти за два года, чтобы сейчас уверенно держать темп в 300 релизов каждый месяц, продолжать расширять команду и не расстраивать инвесторов и фаундеров 🙂

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