What is more important - the simplicity of the tool or the unlimited possibilities of its settings?

The specifics of the work is conducive to communicating with a sufficiently large number of companies and teams developing software.

Many of them use jira as a bug tracker, and moreover, as a project management tool, even trying to build work with requirements in the form of file attachments to tasks.

This, you can say, is statistics, and I want to show one noteworthy thing on its example - the vast majority of such teams are dissatisfied with the jira settings that they have - you always want to tweak something (for example, add a new field to the form), and often this is a burden on further work on the project.


What is the essence of the problem: the most important advantage of jira is the ability to customize it: forms, states, workflow, filters.

This, oddly enough, is at the same time its biggest drawback - psychologically, if the tool has settings, they must be set up. The following problems follow from this:

• The forms and workflow of tasks are getting more complicated, and the work with the system itself is becoming more complicated
• New settings, for example form fields, which soon become unused soon after creation, turn into garbage, cluttering up an already overloaded interface
• Since the jira setup process is very non-trivial, it requires a specially trained person - usually it is not bought on the market, but is grown from its own - after years and broken lives setting up neighboring projects

Common situation? I think for those who at least once had to use this tool, yes.

But if you look closely at the really necessary needs of most (with rare exceptions) projects in terms of task and bug tracking, everything turns out to be extremely simple - the simplest settings are enough.

When developing the DEVPROM project management system , we were guided by the principle "the simpler, the more understandable, the better and more convenient":

• We didn’t come up with a complex security model - it’s enough to divide access rights into rigidly defined user roles (Customer, Developer, Analyst, PM, etc.)
• The Task and the Error we have have the same workflow, because in fact they do not differ
• Task states are only really necessary: ​​Added, Approved, Scheduled, In Work, Completed, Closed, and Postponed

This allows you to cover 80% of the needs of all modern projects, and the remaining 20% ​​to be left at the mercy of the monsters configurations that are necessary for either extremely formal customers or the same project managers. Because the team does not need this at all.

And most importantly - when using a simple tool, you have more time to focus on the main thing - on the development of your project.

The tool as an assistant, and not as an additional obstacle to success.