Мы не выбрали таск-трекер и создали собственный за два дня. Канбан исчез через два с половиной часа
В небольшой команде из шести разработчиков одновременно шло около пятнадцати проектов. Задачи хранились где придётся: часть - в Excel, часть - в рабочих чатах, остальное - в памяти сотрудников. Постепенно вопрос "кто этим занимается?" стал звучать чаще, чем "как это реализовать?". Стало очевидно: без единого таск-трекера работа начинает зависеть от личной внимательности каждого.
Мы изучили существующие решения, но ни одно не подошло полностью. Поэтому в понедельник открыли пустой репозиторий, а уже во вторник перенесли реальные задачи в собственную систему. Самым неожиданным оказался не результат, а путь к нему: канбан-доска, которую изначально считали главным элементом продукта, прожила в интерфейсе всего два с половиной часа.
Почему готовые сервисы не устроили
Jira и Linear не прошли по требованиям к размещению данных. Внутренняя информация не должна находиться во внешнем облаке, а работа с российскими аккаунтами у этих поставщиков оставляет слишком много неопределённости.
Российские продукты - Kaiten, YouGile и Weeek - функционально выглядели лучше, однако тоже предполагали облачное хранение. Кроме того, платить за полноценную подписку, используя лишь небольшую часть возможностей, команда не хотела.
Ближе всего оказался self-hosted Plane. Но ради шести человек пришлось бы разворачивать, обновлять и обслуживать довольно крупную систему. Это выглядело избыточно: собственный трекер должен был решать конкретную задачу, а не превращаться в отдельный инфраструктурный проект.
GitHub Issues команда уже использовала и считала удобным инструментом для разработчиков. Однако он оказался недостаточно наглядным для руководителя: нужны были карточки, сроки, распределение нагрузки и общая картина по проектам. Список задач с лейблами этого не давал.
При этом решение писать собственный продукт было связано не только с ограничениями. Команде действительно хотелось попробовать свои силы. Если такого интереса нет, готовый сервис почти всегда окажется рациональнее. Самописный инструмент имеет смысл лишь при коротком цикле разработки, ясных требованиях и готовности быстро отказаться от неудачных решений.
Минимальный и понятный стек
Технологический набор намеренно оставили простым:
- FastAPI и SQLAlchemy 2 на серверной части;
- Alembic для миграций;
- Next.js 15 и React 19 в интерфейсе;
- TanStack Query для работы с данными;
- PostgreSQL 16;
- Redis;
- nginx;
- шесть контейнеров в Docker Compose.
Отдельного сервера не было, поэтому приложение разместили на виртуальной машине, где уже работал другой сервис. Чтобы не создавать конфликтов, использовали самостоятельный compose-проект с отдельными томами и сетью. Наружу вывели только порт 8443, а системный nginx менять не стали. Сервисы фактически жили рядом, но не зависели друг от друга.
Канбан появился первым - и почти сразу исчез
Первый прототип выглядел ожидаемо: доска, несколько колонок, карточки задач и перетаскивание между этапами. Для drag-and-drop подключили dnd-kit. Через два с половиной часа появился коммит с говорящим названием - "Отказ от досок".
Когда в систему начали переносить настоящие задачи и показывать её коллегам, обнаружилась главная проблема. Канбан отвечал не на те вопросы, которые команда задавала ежедневно.
Доска хорошо работает там, где несколько человек вместе ведут один продукт и хотят видеть движение задач по этапам. Но в рассматриваемой команде у каждого разработчика было по два-три проекта. Поэтому запросы звучали иначе:
- разработчику важно понимать, какие задачи принадлежат ему и какие требуют немедленной реакции;
- ответственному за проект нужно видеть собственные поручения и задачи, задержавшиеся без движения;
- руководителю необходимо знать, кто перегружен и какой проект остановился.
Обычная доска не давала быстрых ответов ни на один из этих вопросов. Нужны были не колонки, а фильтры, сроки, возраст задачи и сводка по исполнителям.
В результате доску полностью убрали из пользовательского интерфейса. На главной странице появились плитки проектов, внутри каждого проекта - список задач с указанием стадии, а отдельно - общий перечень по всем проектам и экран загрузки сотрудников.
Канбан остался внутри системы
Хотя визуальную доску удалили, сам принцип этапов не исчез. Его сохранили в структуре данных:
Project → Board → BoardColumn → Task
У каждой колонки появился машиночитаемый тип: "поставлено", "в работе", "на проверке" или "готово". Стадия задачи определяется именно колонкой. Интерфейс ориентируется на значение `kind`, а не на отображаемое название. Поэтому колонку можно переименовать без поломки бизнес-логики.
Это стало главным архитектурным выводом эксперимента: канбан - не обязательно способ отображения задач. В первую очередь это модель жизненного цикла. Этапы, переходы и правила обработки действительно важны, а визуализация в виде вертикальных столбцов подходит далеко не каждой команде.
Жизненный цикл важнее перетаскивания
Вместо механики drag-and-drop сделали явные действия: "взять в работу", "отправить на проверку", "завершить", "вернуть на доработку". Такой подход оказался понятнее и надёжнее.
Кнопка перехода может учитывать права пользователя, текущий статус, наличие исполнителя и обязательность комментария. Например, закрыть задачу без результата нельзя, а отправить её на проверку может только назначенный исполнитель. В канбане подобные правила часто скрываются за простым перемещением карточки.
Кроме того, явные переходы удобнее для аудита. Система может записывать, кто и когда изменил этап, сколько задача находилась в каждом состоянии и где чаще всего возникают задержки.
Что пришлось добавить сверх базового списка
Одного перечня задач оказалось недостаточно. Чтобы трекер помогал управлять работой, в него добавили несколько важных признаков:
- ответственного сотрудника;
- автора постановки;
- срок выполнения;
- приоритет;
- дату последнего изменения;
- текущий этап;
- проект;
- оценку трудоёмкости;
- историю переходов.
Особенно полезным оказался возраст задачи - время с момента последнего изменения. Задача, которая формально находится в статусе "в работе", но неделю не менялась, должна быть заметнее свежей задачи, созданной час назад.
Фильтры сделали основным элементом интерфейса. Пользователь может быстро вывести свои задачи, просроченные карточки, работу конкретного проекта или всё, что ждёт проверки. Для руководителя важнее сводные представления: количество активных задач, распределение по исполнителям и список проектов без движения.
Почему два дня - не универсальный рецепт
Создать минимальный рабочий прототип за два дня получилось благодаря ограниченному масштабу. Команда заранее отказалась от сложных функций: автоматизаций, интеграций, многоуровневых ролей, мобильного приложения, расширенной аналитики и универсального конструктора процессов.
Также помогло то, что разработчики сами были будущими пользователями. Не пришлось проводить длинные согласования или составлять подробные технические задания. Увидели проблему - изменили модель, интерфейс или фильтр сразу.
Однако быстрый запуск не означает, что продукт готов для любой компании. Перед публикацией на более широкую аудиторию понадобились бы резервное копирование, мониторинг, контроль доступа, защита от потери данных, документация и план обновлений. В самописном решении ответственность за всё это ложится на команду.
Как понять, нужен ли компании собственный трекер
Перед разработкой стоит ответить на несколько вопросов:
1. Есть ли ограничения по размещению рабочих данных?
2. Действительно ли готовые сервисы не закрывают ключевой сценарий?
3. Кто будет сопровождать приложение после запуска?
4. Можно ли сформулировать минимальный набор функций?
5. Готова ли команда отказаться от красивых, но ненужных возможностей?
6. Есть ли возможность регулярно собирать обратную связь пользователей?
Если проблема сводится к отсутствию дисциплины, самописный продукт её не решит. В этом случае важнее договориться о правилах постановки задач, сроках и ответственности. Новый интерфейс не заменит управленческий процесс.
Собственный трекер оправдан, когда он сокращает путь от возникновения вопроса до ответа. В данном случае ценностью стала не канбан-доска и не набор технологий, а единое место, где можно быстро выяснить, кто чем занят, какие задачи остановились и где требуется вмешательство. Именно короткий цикл обратной связи, а не сам факт разработки за два дня, сделал эксперимент полезным.
