The thing that kills me about Jira is the inconsistency I experience between projects. Everybody sets it up differently, and work based off entirely different views and contexts. It is exhausting and there's always too much friction. Maybe managers love it cause they got more time to waste on tools like Jira than us engineers, but if I have to spend more than 5 minutes figuring out how to progress forward my ticket, you've screwed up.
One really awful thing about Jira: If you create a state for a ticket, and then clone it for a new project, and then update the labels of those states, you're now screwing over the original project because all those states will be updated too.
I think it should take approximately 5 seconds for an engineer to progress their tickets. And generally speaking, engineers shouldn't be cloning tickets in Jira without training first (even then I would discourage it, but I don't have enough context). Jira isn't user friendly but neither is C++. Once people experience a well run Jira shop (I think most people have just never seen it because in my experience it's shockingly rare) they realize it's actually useful. The problem is the people in charge of Jira usually suck. And that's a much harder problem to fix.
Or perhaps the problem is that Jira gives people too much rope to hang themselves with.
It should not be possible to make the experience of users sub-par by 'holding it wrong', and it should not take months or years to learn to use a project management tool IMO - the project should be over by then! Tools like Jira should get out of the way, not get in the way of the real work.
This is like complaining that C (or assembly, or VHDL) is too complicated, and we should all use easier languages like Java, Python, and Ruby.
>It should not be possible to make the experience of users sub-par by 'holding it wrong', and it should not take months or years to learn to use a project management tool IMO - the project should be over by then!
It should not be possible for engineers to do this, which is why the Jira admins should be to blame for setting up a shitty Jira environment. And how long it takes to learn Jira is irrelevant to engineers because you're never supposed to have to learn Jira beyond "move your tickets to done when you're done." How long should it take to learn C++, or Kubernetes, or TensorRT? Do we say those are all a waste of time as well because engineers need to set aside time learning a new language/technology/tool in order to help them do their jobs?
> Tools like Jira should get out of the way, not get in the way of the real work.
I agree. The problem is it sounds like you're assuming I think engineers should learn Jira. Engineers should not spend more than a few minutes a day "dealing" with Jira, on average (ideally no more than 30 seconds, but that's a bit optimistic at a real company). If you spend more than a few minutes a day struggling with Jira, you should bitch to whoever is in charge of Jira. But if you really believe that 15 minutes a week of your time in order for the organization to function at much high levels is a waste of your efforts, then perhaps you should set out to redefine project management. I assure you, there is a shitload of money to be made if you think you can do it better.
This doesn't reflect my experience at all as a developer in small teams.
I spend quite a lot of time in the issue tracker - it is one of the main ways (along with email and conversations) that I interact with other team members and track work in the team. I can't imagine any situation where developers would spend just 15 minutes a week in an issue tracker and be able to do their job effectively, even junior devs should be spending more time than that responding to feedback and explaining what they have done, scope changes, what to test etc etc.
Creating software is not all writing code - much of it is thinking and interacting with other people, before you even start writing code, and then iterating fast on what you have written, gathering feedback along the way. An issue tracker is one of the tools used to do that.
So the tools are important, and Jira gets almost everything wrong in my view.
> Jira gets almost everything wrong in my view.
What specifically would you like to be different?
I can accept this. But I've chosen to be a programmer - project management tools are a necessary evil, not something I enjoy. Expecting me to put in the effort to master it they way I do my primary tools is doomed to frustration.
I dont' expect end users to program...and I'm the end user of Jira.
custom workflows can add automated state management and notifications where appropriate for your dev practices without restricting what you can do. then a little light process on top (who does what with issues in which states, i.e., assuming ownership by the team) glues it all together.
If you can market yourself as a simpler and faster way for agile teams to run projects, and deliver on that, then you'll probably get some decent traction with SMBs and work your way up from that. Make teams feel like they'll be agile by using Zepel.
Great work and good luck!
For example, in Confluence, there's a nested structure: Pages exist in spaces. Pages can have more restrictive permissions than the space they're in, so you can have a space with pages anyone can edit and pages only a select few can edit. Now for the annoying part: It's possible to have permissions to edit a page in a space without permissions to view pages in that space. Does the special permission override the general? Does it, Hell! Of course not! That set of permissions is useless, in that it doesn't allow you to do a damned thing!
It would be great if Atlassian packaged a sudo plugin with their software, so you could see what a given user could see and figure out what's going wrong. It would be great if Atlassian packaged an auditor in with their software to, at the very least, alert you to useless permission combinations. I know the first would infringe on one or more paid plugins, so that's not going to happen, but I don't think anyone has anything which solves the second problem.
Indeed it can be projected directly on a wall screen to see a kanban board in real-time with customizable details.
Also with easy plugin system, it can extend to integrate with other system in company to automate various processes or customize to once liking.
We use LXD container and launching is as easy as:
$lxc launch your-pm-1.0 yourpm1
JIRA (and confluence) are the slowest web apps I’ve had the pleasure of using. Simple navigation takes seconds when bouncing through pages. Accidentally clicking the wrong issue is physically painful. When I think JIRA I think glossy silver spinners.
We self host Jira and it's not slow for us.
It often takes more than 2000ms to switch views (e.g. just to switch from looking at an issue to the board showing list of issues in the current sprint for my team). Sometimes, 5000ms plus.
It's so slow that I've noticed everybody does what I do, namely ⌘-click all links so that they open in a new tab. That way you don't "lose" what you are currently looking at, and have to endure another 2000ms load time just to see it again.
Everybody's JIRA window has like 40 tabs open by the end of the day.
One result of this, beyond being irritated, is that meaningful bug discussion never happens on the ticket comment threads, the way it used to with GitHub Issues, or the way it would happen if JIRA was as fast as a normal app (like, say, GitHub Issues). The discussion is all on Slack now, completely separated from the issue tracker and super hard to find when you need it.
I occasionally manage to paste a few Slack links into JIRA bug comments, since I already have that tab open and I know nobody else will.
We didn't love the feature set and UI of GitHub Issues, either. (Hence the sadly failed search for a new tool that resulted in JIRA.)
But it wasn't slow, so people did actually use it. I don't think we have a features/UI problem with JIRA. If it was fast, I think people would use it about the same as they did GitHub Issues.
But it is slow, so engineers use it very minimally: create an issue (which is usually done via our Slack chatbot, because using the JIRA UI is so annoyingly slow that somebody wrote a bot to automate that), put the issue into a sprint, and then close an issue when it is finally done. Those are the 3 operations we do.
I think the project manager people are OK with JIRA, because they mainly use it to generate fairly complex reports that admittedly are pretty useful to see how we did in the past iteration compared to our goals. That is SUPER SUPER slow too, but they don't mind as much because it's a bi-weekly thing they do, not something they do over and over throughout the day.
I think JIRA has a variety of other usability problems, but the deadly slowness outweighs all of them combined. We still "use" JIRA in the sense that it's the system we use to track bugs. But we don't actually use it much at all — because it's slow.
Most of the time I work alone or with 1-2 people. We would look for free options anyway. Because it's free, I get hooked up and then I stay with the tool for bigger projects.
Looks very appealing. I'll definitely try this for my next project!
Given JIRA's ubiquity, I would strongly recommend that you build an integration that allows you to sync tickets from JIRA -> Zepel, so people can get the benefits of the Zepel interface without having to duplicate their work. (Unless this is already there, but I didn't see it on the website).
Nonetheless, we have found that JIRA can scale nicely from simple to more complex workflows if you take the time to set it up/customize the workflows. But a "Feature Oriented" view that allows me to easily track progress on concurrently progressing streams of work (larger than a single epic) is sorely missing. We tried to come by with Portfolio and Structure for JIRA (both are plugins) but they feel somewhat awkward to use as they require tons of clicks for simple things.
Zepel looks like a great idea. However, JIRA is already so embedded in our workflow (thanks to bitbucket integration, ticket bots/plugins etc.)... I'd love to have something like "Github Projects" which sits on top of my normal GH issues but allows me to roll them up. Concourse for example is a nice example of using this effectively: https://github.com/concourse/concourse/projects
Anyone have a recommendation for a tool/plugin that can do this?
I build WP sites for a local design agency (my client) who designs the theme for their client. I have 2-3 subcontractors that I work with to build these sites.
Building the site needs to be managed like a "project". Once launched, I want to give my client AND their client the ability to create tickets for any post-launch issues. I need these users to be "siloed" into organizations so that they can't see bug trackers for other clients. I need my subcontractors to be able to see tickets from projects they're approved to see.
I want the ability to create tickets via e-mail, sometimes from my client, other times directly from their client.
JIRA + Service Desk seems to give me everything I want, but the admin menus for their "classic" templates (i.e. Service Desk) are daunting. Lots of settings that (IMO) should be "global" are instead per-project. The only way to share these settings is to clone an existing project.
We've got ~12 sites that we're managing, and to make a "tweak" to one setting means having to go tweak that same setting 11 more times.
Is there any system smaller/simpler than JIRA that meets these needs?
That said, if you're using the service desk stuff from Jira I might stay with it. I understand the pain of having to administer Jira and how it creates project-specific EVERYTHING on the backend (workflows, et al.) but it's great for end users and it's super flexible.
Let me know what you think (I'm the developer)
Because I work with an agency, I'm typically billing my client, who then bills their client (plus markup). Obviously we don't want their client to see what I charged them. Is it possible to "hide" the billing for certain users?
The major selling point / complaint of Jira seems to be that it's too customizable. They're all different, and a bad manager can make your particular Jira instance unusable.
Is this one as customizable? Or is it inflexible? Or does it automatically "adapt" somehow? Does it assume that all teams work in the same way? I can't figure out what tradeoff it's making here.
The "JIRA Alternative" page says:
> "Because when you’re just a week away from shipping your feature, you should be tracking your entire feature. Not user stories and tasks."
which makes it sound like Zepel just picked a workflow. It "adapts" to you by assuming you already work in exactly the way it was designed.
We switched from JIRA to youTrack and it was one of our best business decisions recently. It is not perfect, but we will switch again, only if a really superior tool arrives and when it is maintained with some larger company that we know will not go away anytime soon.
BTW. Zepel looks very sleek.
Obviously there's a market for this as I think people are still chasing potential efficiency gains in making tools that are easy/fast/effective in organizing work, but as a product leader I don't see anything here that compels me to leave Github.
To Zepel team: I think you are off to a great start. Personally, I would like to see more information about the Github integration on your marketing pages. Since I don't know the Github integration details (or couldn't find them), make it feel like I am using Github Issues when I commit code on the command-line just like Clubhouse has.
Feedback: I feel something is off with: Signup for free <b>OR</b> Signup using Google. Do you charge when I signup with Google?
I'm immediately seeing two pain points, though:
1. A lot of the text fields seem to have a nasty habit of jumping the cursor back to the beginning of the text, thus causing me to accidentally enter things "islike th". This is a sure sign that y'all are probably overthinking/overengineering the text inputs :) Also, not having a visual indicator of whether or not a text field actually saved is absurdly annoying, especially when the text I enter doesn't get saved when I close a given screen...
2. Just because I'm entering something as a work item doesn't mean I'm actually the requestor of that item. Being entirely unable to change the requestor to something arbitrary eradicates one of my prospective use cases for this. I'd assume that if there were multiple users setup in Zepel I'd be able to choose them, but I don't want to have to setup end-users with Zepel logins just so that I can track who's bugging me about a particular feature or bug.
Looks promising, though. Certainly a lot more intuitive than JIRA.
I've just tried Zepel out by importing my current project off Trello (loved that this feature was available) so here's some things that threw me off:
- I'd like an easy way to move multiple cards from one board list into another cause I can't multi-select or drag-select. Organising a freshly imported project is a hassle without this.
- When creating a new feature I couldn't find a way to drag existing tasks/cards into it but as far as I could see I'd have to create new ones.
- I would expect tags to auto-complete when adding them to a card but it didn't seem to work.
Generally it seems to work well if one is populating a new project from scratch but cleaning up an imported project would require a little more thought and additional features cause the barrier to entry for users of existing products seems rather high.
Keep up the good work!
Agreed, the post-import experience has a lot of room for improvement and we are constantly iterating on it.
By MS's own admission it's way too complicated, so much so that they've now made the "Basic" workflow (which looks a lot like Jira) the default.
We believe JIRA and most other project management tools have evolved from the core use case of issue tracking. While they might be great for tracking issues and ad hoc work items, when it comes to product development, bug tracking is only a part of the equation.
We believe 2 key aspects make product/feature development different.
- Unlike bug tracking, a feature needs to be conceptualized and the form-based interface of these tools make it ridiculously difficult to spec out the requirements for a feature.
- Shipping a feature involves multiple disciplines and rarely follows a single fixed workflow.
Our approach to solving these two problems is,
- A text editor like interface that lets you specify your features and making it super simple to change or update items.
- Multiple boards per project to capture every discipline and the flexibility to move items across these boards as per your use case.
We believe its painfully hard for product teams to plan and ship features using JIRA and that's why we have created Zepel.
It's got bells and whistles to spare, including several kitchen sinks, which can make it a bit daunting to configure. But you can configure it to suit your needs, instead of having to conform to some harebrained workflow someone else decided was Good Enough.
What I really hate is that, even after all these years, it doesn't come with a good planning tool. Portfolio is terrible. I've evaluated several Gantt plugins, which were all terrible. A closely related problem is the missing calendar integration. Atlassian has a calendar plugin for Confluence (wiki), which makes zero sense to me. In my world, issue tracking and planning go hand in hand. And you can't plan shit without a calendar. Surely I'm not the only one who feels that way?
Edit: while I'm out praising Jira, have you seen their SDK? You can roll your own Jira plugin in 15 minutes. Bam. Frictionless. Engineers hate it? Those are some weird engineers.
Currently, you’re not competing against JIRA, but rather Asana, Basecamp, Trello, etc for customers. While not rational, a large part of their appeal is they look nothing like JIRA, which can’t be said for you.
BTW... out of curiosity.... how long did it take you to create this and with how many people?
I wonder if it's suitable for your use case? And if not, what I'd need to add for it to be something you'd use
Outlook integration would be nice as well. We used a simple jira plugin that would copy contents of email and make a task for a specific project.
just read through your license and it looks like buyers will be allowed to hack it to their liking +1