Собственный таск-трекер нужен компании тогда, когда готовые сервисы управления задачами перестают подходить под реальные процессы. Команда подстраивается под ограничения инструмента, часть работы ведётся в таблицах и чатах, данные о задачах нельзя связать с CRM или учётом, а стоимость подписки растёт вместе с числом сотрудников. В такой ситуации разработка своей системы может оказаться разумным решением. В клубе ВИПМИ мы проектируем и разрабатываем такие системы, подробнее на странице разработка собственных систем управления задачами.
Разберём, когда готового сервиса достаточно, а когда пора задуматься о своём трекере, какие функции заложить в первую версию, как избежать типичных ошибок и как организовать разработку.
Когда готового трекера достаточно
Популярные сервисы управления задачами хорошо подходят для большинства команд. Они быстро подключаются, имеют мобильные приложения, интеграции и привычный интерфейс. Если ваши процессы стандартны, команда небольшая, а основная задача — видеть, кто что делает и в какие сроки, готовый сервис почти всегда выгоднее. Его не нужно поддерживать, а новые функции появляются без вашего участия.
Прежде чем начинать разработку, честно оцените, не решится ли проблема настройкой существующего сервиса, сменой тарифа или переходом на другой готовый продукт. Собственная система требует вложений не только в разработку, но и в поддержку.
Собственный таск-трекер: признаки, что пора разрабатывать
- процессы компании не укладываются в стандартные статусы и типы задач;
- задачи нужно связывать с заказами, клиентами, объектами или оборудованием;
- требуется автоматический расчёт сроков, стоимости или загрузки по вашим правилам;
- нужны особые права доступа, например для клиентов или подрядчиков;
- данные должны храниться на собственных серверах по требованиям безопасности;
- стоимость подписок на всю команду стала сопоставима с разработкой;
- сотрудники ведут параллельный учёт в таблицах, потому что трекер не покрывает потребности.
Если совпадает несколько пунктов, собственная система может окупиться за счёт экономии времени, отказа от подписок и повышения прозрачности процессов.
Важно знать. Собственный трекер не обязан повторять все функции популярных сервисов. Его сила в том, что он делает именно то, что нужно вашей компании, и ничего лишнего.
Какие функции заложить в первую версию
Первая версия должна решать главную проблему, ради которой затевается разработка. Остальные функции добавляются по мере использования. Типичный состав минимальной версии:
- Задачи и статусы под ваш процесс, с исполнителями и сроками.
- Связь с сущностями бизнеса: заказами, клиентами, проектами.
- Уведомления о новых задачах, изменениях и просрочках.
- Роли и права доступа для сотрудников, руководителей, внешних участников.
- Отчёты по загрузке, срокам и выполнению.
- Интеграции с ключевыми системами: CRM, почтой, мессенджерами.
Данные трекера затем становятся источником для дашбордов и отчётов руководителя. Как построить такой экран, мы рассказали в статье панель показателей для директора.
Осторожно. Самая опасная ошибка — пытаться сразу сделать «идеальную систему» со всеми функциями. Разработка затягивается, бюджет растёт, а команда продолжает работать в старых инструментах. Запускайте минимальную версию и развивайте её по обратной связи.
Готовый сервис или своя разработка: сравнение
| Критерий | Готовый сервис и своя система |
|---|---|
| Скорость запуска | Готовый сервис сразу, своя система после разработки |
| Соответствие процессам | Готовый ограничен настройками, своя система под ваш процесс |
| Стоимость во времени | Готовый: подписка, своя система: разработка и поддержка |
| Интеграции | Готовый: доступные коннекторы, своя система: любые нужные |
| Хранение данных | Готовый: у провайдера, своя система: где решите |
Плюсы и минусы собственного трекера
| Плюсы | Минусы |
|---|---|
| Система точно повторяет ваши процессы | Нужны вложения в разработку |
| Связь задач с данными бизнеса | Требуется поддержка и развитие |
| Нет зависимости от тарифов сервиса | Мобильное приложение нужно разрабатывать отдельно |
| Полный контроль над данными | Команде нужно время на переход |
Мнение эксперта
«Перед разработкой мы просим команду две недели фиксировать, где и как они на самом деле ведут задачи. Почти всегда выясняется, что реальный процесс отличается от того, что описано в регламентах. Трекер, построенный по реальному процессу, принимается командой гораздо легче.»
Эксперт клуба ВИПМИ, руководитель направления разработки
Как организовать разработку
Начните с описания процессов: какие типы задач существуют, через какие этапы они проходят, кто участвует на каждом этапе, какие данные нужны. Опишите проблемы текущего инструмента и то, что хотелось бы получить. По этому описанию подрядчик готовит прототип интерфейса, который можно показать команде и скорректировать до начала программирования.
После запуска минимальной версии важно собирать обратную связь от пользователей и регулярно выпускать улучшения. Назначьте внутреннего ответственного за систему: он собирает пожелания, расставляет приоритеты и согласует изменения с подрядчиком. Общий обзор того, какие инструменты учёта используются в командах, — в статье рабочие трекеры и системы учёта.
Переход команды на новую систему
Даже удобная система встречает сопротивление, если внедрять её резко. Лучше начать с одной команды или одного процесса, отладить работу и только потом подключать остальных. Подготовьте короткие инструкции, проведите обучение и договоритесь о дате, после которой задачи ведутся только в новой системе. Перенесите активные задачи из старого инструмента, чтобы не было параллельного учёта.
Совет. Добавьте в трекер то, чего команде не хватало в старом инструменте. Когда сотрудники видят, что новая система решает их собственные проблемы, переход проходит быстрее.
Трекер как часть внутренней платформы
Собственный трекер часто становится ядром внутренней платформы компании. К нему подключаются клиентский кабинет, учёт рабочего времени, база знаний, генераторы документов и визуальных материалов. Например, задачи на создание рекламных креативов могут автоматически запускать сборку баннеров по шаблону. Об этом подходе мы рассказали в статье генератор рекламных баннеров по шаблонам.
Закладывайте архитектуру с запасом на развитие: понятную структуру данных, программный интерфейс для интеграций, разграничение прав. Тогда новые модули можно будет добавлять без переписывания системы с нуля.
Типичные ошибки
- разработка без описания реальных процессов;
- попытка сразу сделать все функции популярных сервисов;
- нет ответственного за систему внутри компании;
- параллельная работа в старом и новом инструменте;
- отсутствие мобильной версии для сотрудников в разъездах;
- нет плана поддержки после запуска.
Чек-лист перед стартом разработки
- описаны типы задач и этапы процессов;
- собраны проблемы текущего инструмента;
- определены роли и права доступа;
- выбраны системы для интеграции;
- назначен внутренний ответственный;
- согласован состав минимальной версии.
Безопасность и хранение данных
В задачах хранится много чувствительной информации: данные клиентов, условия сделок, внутренние документы, переписка. В готовых сервисах эти данные находятся на серверах провайдера, и компания зависит от его политики безопасности и доступности. Для некоторых отраслей и компаний это неприемлемо, например из-за требований к хранению персональных данных или внутренних правил информационной безопасности.
Собственная система позволяет самостоятельно выбрать, где хранить данные, кто имеет к ним доступ и как настроены резервные копии. Но вместе с контролем приходит и ответственность. Нужно продумать регулярное резервное копирование, обновление серверного программного обеспечения, журнал действий пользователей, двухфакторную аутентификацию для доступа, порядок отключения учётных записей уволенных сотрудников. Эти вопросы стоит обсудить с подрядчиком на этапе проектирования, а не после запуска.
Если требования к безопасности высокие, заложите в план работ проверку системы на уязвимости перед запуском и периодически после крупных обновлений. Это недорого по сравнению с последствиями утечки данных клиентов.
Помните, что доверие команды к системе во многом строится на уверенности, что данные в ней сохранны и не потеряются при сбое сервера.
Частые вопросы
Сколько времени занимает разработка трекера?
Зависит от сложности процессов и интеграций. Минимальная версия обычно делается заметно быстрее полной системы, поэтому лучше начинать с неё.
Можно ли перенести задачи из готового сервиса?
Обычно да, если сервис позволяет выгрузку. Перенос планируется заранее вместе со структурой данных.
Нужно ли мобильное приложение?
Если сотрудники работают вне офиса, мобильный доступ важен. Часто достаточно адаптивного веб-интерфейса.
Кто будет поддерживать систему?
Подрядчик или собственный разработчик. Важно заранее договориться об обновлениях, исправлении ошибок и развитии.
Можно ли подключить клиентов к трекеру?
Да, с отдельными правами доступа. Клиенты видят только свои задачи и статусы.
Обсудим собственный трекер для вашей команды
Расскажите о процессах и проблемах текущего инструмента. Мы оценим, нужна ли разработка, и предложим состав первой версии.
