Вырастая из «Трекера»: как GetTask обрел структуру разработки на SimpleOne SDLC

О компании

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

Предпосылки проекта

До внедрения SimpleOne SDLC команда разработки GetTask использовала Яндекс.Трекер для управления задачами. Однако по мере роста компании стали очевидны ограничения этого инструмента:

Основные проблемы:

1. Технический долг накапливался из-за отсутствия структурированного подхода к планированию.
2. Непрозрачность процессов разработки — команда теряла видимость над статусом задач и релизов.
3. Примитивная статусная модель — невозможность настроить сложные workflow под специфику процессов.
4. Отсутствие разделения релизов и спринтов — все смешивалось в одну структуру.
5. Ограниченные возможности группировки — сложно было организовать задачи по фичам и эпикам.
6. «Бункерность»  команды — разрозненная работа без единого информационного пространства.

Выбор решения

При выборе новой платформы команда GetTask ориентировалась на следующие критерии:

1. Российское решение из реестра отечественного ПО для минимизации рисков.
2. Продвинутая функциональность для управления полным циклом разработки.
3. Гибкие настройки процессов с поддержкой Scrum и Kanban.
4. Возможность масштабирования под растущую команду.
5. Интеграция с корпоративными решениями в рамках группы компаний.

SimpleOne SDLC полностью соответствовала этим требованиям: платформа предлагает комплексный подход к управлению разработкой с поддержкой всех этапов SDLC — от аналитики до готового релиза.

Задачи проекта

Перед командой GetTask стояли следующие цели:

1. Навести порядок в процессах разработки — создать управляемый и прозрачный процесс доставки изменений в продакшн.
2. Разделить релизы и спринты — использовать разные сущности для разных целей планирования.
3. Внедрить группировку по фичам — структурировать работу над крупными функциональными блоками.
4. Минимизировать технический долг — за счет строгих процессов и прослеживаемости задач.
5. Преодолеть «бункерность» — создать единое информационное пространство для команды.

Процесс внедрения

Миграция на SimpleOne SDLC была организована интегратором ITGLOBAL.COM и прошла в сжатые сроки:

Этап 1: Февраль 2025 — старт и быстрая миграция

На первом этапе команда получила доступы к платформе SimpleOne SDLC, была настроена базовая структура проектов и продуктов, созданы шаблоны задач и настроены доски. Особенностью проекта стал быстрый переход — команда сознательно прекратила использование Яндекс.Трекера уже через месяц после начала работ, полностью переключившись на SimpleOne SDLC.

Этап 2: Март — Декабрь 2025 — адаптация и оптимизация

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

Этап 3: Январь 2026 — стабилизация процессов

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

Результаты внедрения

После года работы с SimpleOne SDLC команда GetTask проанализировала изменения в процессах разработки. Миграция с Яндекс.Трекера позволила решить основные проблемы, с которыми столкнулась команда: были упорядочены процессы планирования, появилась прозрачность статусов задач, а технический долг перестал накапливаться бесконтрольно.

1. Процессы разработки стали управляемыми

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

2. Минимизировали технический долг

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

3. Ежедневная работа стала удобнее

После периода адаптации команда разработки отметила практические преимущества платформы:

• интуитивно понятный интерфейс — современный UI с относительно быстрым освоением;
• гибкие фильтры — возможность быстро находить нужные задачи;
• стабильная производительность — система работает быстро при текущих объемах данных;
• конструктивный фидбэк — возможность получать поддержку от владельца продукта.

4. Преодоление «бункерности»

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

Перспективы развития

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

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

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