Почему мы написали собственный таск-менеджер вместо того, чтобы использовать готовое решение?

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

Мы в нашей команде всегда были фанатами точной письменной постановки задач, поэтому изначально экспериментировали с различными трекерами для управления задачами — сначала использовали их для личного планирования, а затем перенесли этот опыт на управление задачами всей команды.

В разработке долгое время работали с opensource трекером Mantis. Он нас устраивал, хотя был не очень красив внешне. Работали с ним не только наши разработчики, многих клиентов мы тоже «подсадили» на него. Однако, некоторые задачи решались плохо — мы не могли реализовать правильный учёт времени, гибко управлять правами доступа и т.п.

Начали дописывать недостающий функционал, тем более что Мантис написан на php. Дорабатывали его год или два, пока не поняли, что в рамках Мантиса написать что-то сильно отличающееся от Мантиса будет очень сложно, а список дополнительных требований к тому моменту вырос до нескольких десятков пунктов.

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

Готовое решение искали, но все таск-менедеры, платные и бесплатные, были универсальными, а нам было нужно решение, которое идеально впишется в процессы команды и станет их естественным отражением. Чтобы дописать любой из таск-менеджеров до наших требований, пришлось бы переписать 40%-50% чужого кода, что показалось нам более сложной задачей, чем создать свой трекер с нуля.

А ещё хотелось писать продукт под процессы, а не подстраивать процессы под готовый продукт, как бы он хорош не был.

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

Мы внедрили «внутренний комментарий», который виден разработчикам, но не виден клиентам. Это позволило учитывать время, которое разработчик потратил на задачу, но которое не должно быть выставлено в счёт клиенту. Мы — ответственные разработчики, свои ошибки исправляем за свой счёт, но всё время, потраченное разработчиком на задачу, должно быть ему оплачено.

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

Написали отдельный личный кабинет клиента, который заточен на простой и удобной постановке и контроле задач. У него нет гибкости интерфейса разработчика, но он прост и интуитивно понятен в работе.

Сделали уведомления о срочных задачах в телеграм-бота чтобы не пропускать самое важное и реагировать на такие задачи моментально.

А затем мы немного «причесали» и внешний вид трекера. Сейчас он тоже не идеален, однако работать с ним стало намного приятнее.

Чили.Деск — это не только управление задачами, его функционал выходит за пределы классического таск-менеджера.

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

На основе финансовых отчётов выставляются счета клиентам и считается зарплата разработчикам.

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

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

И да, и нет. Несколько раз возникала мысль о том, чтобы превратить Чили.Деск в SaaS сервис, но он настолько заточен под наши особенности, что внедрить его в другой компании можно только вместе с внедрением таких же процессов, как и у нас.

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

А вот для нас Чили.Деск — продукт если не идеальный, то максимально близкий к этому. Меняя процесс разработки, мы сразу задумываемся о том, как это изменение автоматизировать в нашем трекере.

Потерять задачу от клиента? Для нас это почти невероятное событие. Затянуть с закрытием задачи? Не получится, ибо такие тикеты попадают в «красную зону», что видно всей команде, кто-нибудь обязательно спросит что случилось. Ошибиться с расчётом сдельной части зарплаты? Перекрёстная проверка просто не оставит на это шансов.

На данный момент у нас чуть больше 500 реализованных задач по Чили.Деск, на которые мы потратили около тысячи часов разработки, и ещё около 60-ти задач в очереди на внедрение. Условия, в которых мы работаем, меняются, и мы подстраиваем наши инструменты под них.

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

Но, может быть, мы действительно изобрели «велосипед»?