Переход с Wrike на Яндекс.Трекер

Прошёл более года с момента нашего перехода с Wrike на Яндекс.Трекер. Выбор системы был длительным — мы рассмотрели десятки аналогичных продуктов, включая SaaS-сервисы, платные и бесплатные решения, но в итоге остановились на Яндексе.

Основные компоненты Яндекс.Трекера

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

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

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

Структура рабочего процесса в разработке

Начальный статус задачи — «Отложена». Это наш бэклог проекта, содержащий задачи для будущей реализации.
Далее задача может пойти по двум путям:

1. «Оценка задачи» — отдельный процесс для декомпозиции и оценки. После этого задача попадает на дашборд с покер-планированием и переходит в статус «Ожидает проверки».
2. «Активна» — при установке этого статуса обязательно указываются дата начала, дедлайн и исполнитель. Задача появляется на рабочем столе исполнителя.

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

Из статуса «Ожидает проверки» есть несколько путей:

1. Простой путь: автор проверяет задачу и переводит в статус «Выполнена» с соответствующей резолюцией.
2. «Готов к релизу» — для задач, которые выпускаются версиями или патчами. Задача проверена, протестирована и ждёт релиза.
3. Путь через QA: если требуется тестирование, задача получает статус «Требуется тестирование», попадает на дашборд QA-отдела, переходит в «Тестируется». Далее либо возвращается на доработку, либо переходит в «Ожидает проверки».

Существует также статус «Отменена» с соответствующей резолюцией, необходимый из-за невозможности удаления задач.

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

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

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

Почему не Jira и Bitrix24

Подобный функционал, вероятно, есть во многих системах, включая Jira. Кстати, Jira тоже рассматривалась, но не подошла из-за сложностей с необходимыми нам отчётами. Bitrix24 также не подошёл по этой причине.
Для автоматизации процессов мы довольно много используем API для сбора, подсчета и прочей обработки данных. Об этом я наверное расскажу в следующий раз.