Как появился Quevell

За это время основатель Quevell прошел путь от системного администратора до руководителя корпоративного IT в международной финтех-компании. В последние годы он отвечал за команду из 15 специалистов, около 50 сервисов и 130 интеграций, обеспечивающих работу 1500 сотрудников в 30 странах.

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

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

Так появился Quevell.

Принципы, заложенные в продукт

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

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

Автоматизация должна быть предсказуемой. Правила можно проверить на реальных данных без сохранения изменений. Результат проверки показывает, какие действия были бы выполнены.

Данные принадлежат компании. Quevell поддерживает экспорт задач, вложений и страниц базы знаний в открытых форматах.

Эти принципы заложены в архитектуру продукта и определяют его дальнейшее развитие.

Подход к разработке

Quevell разрабатывается с обязательной проверкой изменений на нескольких уровнях.

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

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

Архитектурные решения документируются вместе с их обоснованием. Это позволяет сохранять причины принятых решений и пересматривать их без потери истории.

За развитие продукта, технические решения и приемку изменений отвечает его основатель.