41–50 of 78 posts
Of course, it can be used to implement inconvenient, useless processes as well.
Management has a concrete problem they want to solve: "Their motivation is to be able to track what the dev team is doing and keep a log of the activities, with the end goal being to be able to qualify this work as Capex." So if you really don't want JIRA then offer an alternative that will meet those requirements. Management may still say "just use JIRA". Before pushing back on this have a think about the cost/benef…
Given you are a tech lead, this is the time to take ownership, create a Jira project and tailor its setup to your team needs.
Also, and this goes unsaid because Jira isn't new, the product has gone through many iterations of evolution and it's now a very nice UX. We use it for Kanban, Epics, Releases and the metrics help us visualize in an instant how efficient our team is.
If you give Jira a fair chance, you won't be disappointed.
The status quo of issue tracking on your team is not scalable. And it's entirely reasonable that management should have a way to track your work. You are a small team in a big company and you're going to end up using whatever issue tracker everyone else uses.
You say that your team works better than others in the company. Tell management how your team's processes have resulted in high productivity and suggest improvements that other teams can benefit from. If using Jira hurts your team's productivity, find a way to quantify that -- ideally in terms of how the capex is higher than it needs to be because developers are wasting their time.
Recommend small, incremental changes rather than remodeling the entire system, and get other engineering teams on board with your proposals -- if the processes are bad, other teams are likely to want change too.
I don't have dislike Jira that much, and quite frankly I think it does it job and doesn't get in the way that much.
I have to say that my team is larger than your, so maybe (maybe?) if you're only five developers then Jira might introduce a bit of process overhead? Or maybe once you have some process in place scaling to more developers will get easier?
It seems to me that the problem here is how you look at things: who brought your company clearly wants to scale you up. Imho you should see this Jira introduction as an opportunity for better scaling rather than a threat.
One little side note: if your company has been acquired then all the games are over (and I hope you made a shitload o money in the acquisition). Don't get too much in the way o management, otherwise it'll be just easier to get rid of you than to deal with you.
My two cents, I hope my options help.
https://bitrix24.com https://bitrix24.eu https://bitrix24.com.br https://bitrix24.in https://bitrix24.de etc.
There are a couple things that are really good about Bitrix24. It's kind of like Jira+Confluence+Hipchat+Trello in one, but much easier use. Second, you have an option to choose between cloud and on-premise, just like with Jira.
Above a certain scale you kind of need an issue tracker, but when you're serving it instead of it serving you, it's the implementor's fault, not yours.
One of the reasons Jira comes up so much is that it's so customizable that it will merrily allow you to construct the most Byzantine nonsensical workflow you can think of, and fairly quickly too. It's not Jira's fault that someone told it to do so.
It really sounds like they couldn't find a manager capable of handling both teams, so they're going to throw technology at the problem instead of investing in their people to grow them into the position. It might work if they are willing to pivot quickly based on user feedback instead of just dropping New Process on you, but it's always slower to manage that way instead of just hiring a competent manager.