Что важнее — простота инструмента или безграничные возможности его настройки?

Специфика работы располагает к общению с достаточно большим количеством компаний и команд, разрабатывающих программного обеспечение.

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

Это, можно сказать, статистика, и хочется на ее примере показать одну примечательную вещь — подавляющее большинство таких команд испытывают недовольство теми настройками jira, которые у них есть — всегда хочется что-то подкрутить (например, добавить новое поле на форму), и часто это оказывается обузой при дальнейшей работе над проектом.


В чем суть проблемы: самое главное преимущество jira — это возможность ее настройки: формы, состояния, воркфлоу, фильтры.

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

• Усложняются формы и воркфлоу задач, соответственно усложняется и работа с самой системой
• Новые настройки, например поля формы, оказавшись вскоре после создания неиспользуемыми, превращаются в мусор, захламляющий и без того перегруженный интерфейс
• Поскольку процесс настройки jira очень нетривиален, для него требуется специально обученный человек — обычно он не покупается на рынке, а выращивается из своих — через годы и сломанные жизни настройки соседних проектов

Знакомая ситуация? Думаю, для тех кому хоть раз приходилось пользоваться этим инструментом, да.

Но если внимательно присмотреться к действительно необходимым потребностям большинства (за редким исключением) проектов в плане таск- и баг-трекинга, все оказывается чрезвычайно просто — достаточно самых простых настроек.

При разработке системы управления проектами DEVPROM, мы руководствовались принципом «чем проще, тем понятнее, лучше и удобнее»:

• Не стали придумывать сложную модель секьюрити — достаточно разбиения прав доступа по жестко определенным ролям пользователей (Заказчик, Разработчик, Аналитик, ПМ и т.п.)
• Задача и Ошибка у нас имеют одинаковый воркфлоу, потому что по сути они не отличаются
• Состояния задач только действительно необходимые: Добавлена, Утверждена, Запланирована, В работе, Выполнена, Закрыта и Отложена

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

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

Инструмент как помощник, а не как дополнительное препятствие на пути к успеху.