Hi. I worry that this sort of tool does not benefit engineering very much; in my experience, Jira and other time-management tools are used to allow product ownership and management to request ever-sillier features, while penalizing engineers who do not make themselves legible with constant status updates.
When designing Tara, how did you account for the power differential between the employees who will be using Tara to record their daily work and the managers who will be using Tara to supervise said employees?
So one thing we're working hard to do- is minimize the status updates required. For example- we built a simple home/dashboard where statuses can be updated with one click and individuals can focus on their priority tasks during the sprint.
We feel strongly about minimizing the amount of time spent wading through tickets and updating statuses. Currently working on a few other ideas/features that are related to status changes based on source control. Stay tuned.
As for power differential, the question is how do you instill a sense of camaraderie in individual engineers, and enable managers to load sprints with actual team data vs subjective measures. We're still working on improving this front - but so far - our "home" feature has been liked by both engineers and engineering managers.
Could you explain more? Tara sounds extremely like Jira, both in form and function. The original poster (who is pointedly not answering my question, probably because it is painful and embarrassing) used "alternative to Jira" in the original submission. Other top-level comment threads are directly comparing Tara to Jira. How would you distinguish them?
Painful and embarrassing is whenever I try to ride a bike.
A few quick thoughts on this:
- Jira started out as an issue tracker to monitor issues and tasks - it really wasn't built to handle software projects or the SDLC from the get go.
-Setting up insights and reporting can be a pain. And you need to be familiar with all the jargon (epics, stories, burn-down charts). Overall, it's a ton of cognitive overload.
-I used to just manage my issues on Github vs spending time configuring Jira. I only used Jira when the corporate overloads demanded it.
Here's the take on Tara vs Jira.
- We're zero to low config. There are entire 60 minute videos on youtube on how to setup sprints on Jira. On Tara, it's one click. We're really focusing on minimal functionality maximum impact in terms of matrix, and seeing how we can continue to be low config as we make the platform more powerful.
- Insights are ready and built- in with no setup. Once your github is connected, you can view commits and PRs by sprints
- We shipped our first smart indicator- it basically looks at your past few sprints (x>1 when x is no. of sprints) and tells you if your sprint has been overloaded. We're planning on shipping more smart indicators that make suggestions around effort, etc.
When designing Tara, how did you account for the power differential between the employees who will be using Tara to record their daily work and the managers who will be using Tara to supervise said employees?