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

Раньше у разработчиков было много разных инструментов: бэклог задач в Google Docs, ТЗ в TEAMLY, макеты в Figma. Поэтому новые фичи отгружали дольше. Теперь выкатываем 2 обновления в год и каждые 2 недели отгружаем новый функционал. Расскажем, как.

Привет! На связи Владимир Манеров, исполнительный директор и руководитель отдела разработки в TEAMLY. Сегодня расскажу, как мы создаем новые фичи продукта и почему решили объединить несколько инструментов «под одной крышей». Для этого поэтапно разберу жизненный цикл, который у нас проходит любая задача.

Для разработки и проектирования мы использовали одновременно несколько инструментов. Бэклог и приоритизацию задач вели в Google Docs → Затем фичи, которые должны пойти в релиз, переносили в Smartsheet → Текущей работой управляли в трекере, технические задания писали в TEAMLY, а дизайн рисовали в Figma.

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

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

Все это позволяет работать эффективнее и быстрее отгружать новый функционал.

Насколько решение оказалось полезным, показывают результаты:

Теперь расскажу подробнее, из каких этапов состоит работа над функционалом продукта и какие инструменты TEAMLY для этого используем. Весь процесс мы построили так, чтобы максимально сократить time to market — время от возникновения идеи фичи до выхода в продуктивную среду.

Этап 1. Планирование — составляем бэклог задач и дорожную карту.

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

Для каждой задачи составляем дорожную карту с помощью диаграмм Ганта внутри умных таблиц. Инструмент помогает связать процессы друг с другом и отслеживать дедлайны.

Этап 2. Проектирование — разрабатываем концепцию, создаем дизайн, пишем техзадание.

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

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

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

Техническое проектирование выполняем тоже внутри TEAMLY — нужные инструменты у нас есть. Например, с помощью блок-схем отрисовываем модели хранения информации и потоки данных.

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

Этап 3. Разработка — декомпозируем задачи и выполняем двухнедельные спринты.

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

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

Далее выполняем декомпозицию крупных задач и добавляем их в бэклог, откуда они попадают на канбан-доску команды. Более мелкие подзадачи группируем по принципу юзер-стори. А чтобы сократить рутинную работу, используем функцию автоматизации. Например, когда фича переходит на этап код-ревью, ответственный тимлид получает об этом уведомление.

Этап 4. Релиз и демо — тестируем функционал и отгружаем на боевой сервер.

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

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

Этап 5. Актуализация документации — рассказываем клиентам о новом функционале.

У нас есть внешняя база знаний, которая называется Teamly Academy. Здесь находятся текстовые и видеоинструкции для пользователей, а также записи обучающих вебинаров.

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

С помощью умных таблиц собираем обратную связь от клиентов. Инструмент позволяет создавать специальные формы опросов — по аналогии с Google-формами. Только теперь данные от пользователей сразу попадают в рабочее пространство команды, а не хранятся в разрозненных файлах.

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

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

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

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

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