[HN Gopher] Ticket Monkey
___________________________________________________________________
Ticket Monkey
Author : zug_zug
Score : 38 points
Date : 2021-08-04 15:14 UTC (2 days ago)
(HTM) web link (blog.alexrohde.com)
(TXT) w3m dump (blog.alexrohde.com)
| 0xFACEFEED wrote:
| My issue with ticketing systems is similar to most issues I have
| with this industry: cognitive dissonance.
|
| On the one hand, companies ask me to put all this work into my
| tickets. Fill out this field, fill out that field, link to this
| thing, organize it this way... etc.
|
| On the other hand, the company puts NEAR ZERO real effort into
| making this experience easy and efficient.
|
| I've seen it happen most often with companies that flip-flop
| between defining themselves as a "start-up" but in the same
| breath talk about their worldwide enterprise presence. Of course
| they have 500+ employees. Sometimes thousands. They like to put
| on their startup hat when refusing to pay money for things and
| they like to put on their large scale enterprise hat when
| instituting ticket requirement policies.
| truffdog wrote:
| And then you discover that no one ever reads any of the
| tickets.
| nanidin wrote:
| I worked under a director whose resume padding for the job was
| going to be switching from JIRA to Salesforce for tickets. JIRA
| worked well for engineers and QA, but management wasn't getting
| the types of reports they wanted. Reportedly. Our JIRA
| implementation had evolved over several years and we had 50-100
| people familiar with it and happy with it.
|
| When we started down the path toward Salesforce-ification, it
| involved lots of bulleted feature lists. Maybe 1-2 wireframes.
| Then this was handed to contractors who implemented it exactly
| as written without an eye towards usability. Simple things like
| saving a ticket with some fields blank or unknown we're not
| supported and made the entire ticketing process miserable.
|
| I eventually stepped in as the voice of the "customer",
| customer in this case being fellow engineers and support staff.
| I eventually left the company before the final implementation,
| but even by then no one prioritized usability and design.
| blowski wrote:
| That's not cognitive dissonance. It's just the tendency of
| human ambition to outstrip action because of myriad reasons -
| lack of expertise normally being the root cause. It's the same
| reason my shed is filled with expensive tools I've used once.
| meowface wrote:
| Don't make me context switch between being an engineer/designer
| and being a bureaucrat. That's all I ask. (Okay, not all. It'd
| also be nice to have ticketing/project management software that
| isn't super ugly, clunky, and slow.)
| cobertos wrote:
| There's definitely something to having face-to-face interactions.
| When I worked IT, I loved coming upon someone's problem,
| diagnosing and fixing it there, and making their day. I just am
| not able to do that behind a ticket system. Though sometimes I
| _like_ the predictability and transactionality of fixing a ticket
| too...
|
| Neither situation (informal issue passing via word of mouth, or a
| ticket system) even work close to 100%. A lot gets lost in
| translation. Maybe we just need less layers and more engaged
| engineers? People who care? Though hard to genuinely find.
| l0b0 wrote:
| Ticketing (really, work tracking) needs to be adapted to each
| organisation. This is of course not a complete list, but some
| patterns I've seen:
|
| - In a three-developer startup a ticketing system might very well
| be just needless busywork. You probably have plenty of urgent
| things to disprove so that you can iterate as fast as possible.
| Put them on a whiteboard, and make sure everyone is on the same
| page about what you're building every day.
|
| - In an organisation where the tickets may live longer than
| someone's tenure a formal ticketing system may be necessary, if
| only to make sure long-term ideas are not lost or forgotten.
|
| - In an organisation with more than four developers working on
| the same thing long term you probably need tickets just
|
| - A lot of managers unfortunately don't realise how time-
| consuming and soul-crushingly boring it is to fill in every
| single field in an "advanced" ticketing system, like priority
| (just order things in the backlog!), severity (should be part of
| priority, not its own field), cost (ditto), deadline (ditto),
| sprint # (ditto dammit!), reported by (should be recorded
| automatically), and tags (who actually thinks those are accurate
| across the board and have the same meaning to everyone?). These
| orgs don't need an advanced ticketing system, but use them
| because they are more enterprise-y and that feels good to middle
| managers who care about visibility rather than productivity.
|
| - Huge orgs which have lots of geographically distributed
| developers working on the same thing definitely need an advanced
| ticketing system, if only so different people aren't doing the
| same work in parallel.
| blowski wrote:
| There is a tendency for humans to want to systematise everything.
| We organise our bookshelves, write precise cooking recipes, track
| exercise routines. It brings comfort in chaos because it feels
| like there's a plan.
|
| And the only thing less effective than an organisation with a
| plan is an organisation without a plan.
|
| The problem with plans is when we become bound to them, following
| them slavishly, failing to review them and update them based on
| new knowledge.
|
| That's when tickets are awful. You're doing a ticket because
| somebody you don't know raised it for reasons you don't know at
| some point in the past. Having "delivered" the ticket, you've no
| idea whether you've made any impact on anybody's life, so
| everything feels like a waste of time.
|
| When tickets are done well, they are related closely to the
| impact they're supposed to deliver, and represent a conversation
| about everything we've learned about that expected impact.
| hdhjebebeb wrote:
| Tickets by themselves are a symptom of a good process and not the
| end goal. If you don't know where tickets come from, why they
| exist, or when to do them, then the whole process is nonsense.
|
| I've seen this repeatedly at places where they want developers to
| track what they're doing, but they don't have any product
| function to populate the backlog, groom it or prioritize tasks.
| It's basically anarchy but the devs just document what they felt
| like doing. Of course developers come to resent this system
| because nobody wants to read their diary - everyone else wants to
| know how close things are to being done. But because the whole
| project hasn't been scoped and broken down, it's impossible to
| get that knowledge from a snapshot of what people have been
| doing.
| davidw wrote:
| Not sure if the tickets are really the problem. I've used them
| both in places that are soulless and places I've loved, because
| they're an effective tool for tracking a lot of things happening.
|
| Maybe it's just that smaller places more focused on getting stuff
| done in a hurry are more fun for some people.
| one_off_comment wrote:
| I think you're on to something.
|
| I do find it interesting that I've noticed many product
| managers use ticket systems to track and reference work and
| changes, while programmers use version control systems to do
| something very similar. These two systems often link to each
| other via hyperlinks in ticket systems and ticket numbers in
| commit messages. The most coupled systems like git and Github
| Issues are still at arm's length to one another. Even Fossil
| (to the best of my knowledge) considers tickets and source
| commits/branches/etc to be separate entities. Maybe there's
| something worth looking into there that integrates the concepts
| more than just links and hooks.
|
| The bigger issue IMHO is that rush of endorphins when I
| complete a ticket. It's more fulfilling to me when I can
| quantify my productivity, and tickets allow me to do that. But
| that combines with the idea that your work = your worth, which
| is completely untrue. That's the core issue that I'm still
| trying to work on for myself.
| oliv__ wrote:
| _> But that combines with the idea that your work = your
| worth, which is completely untrue_
|
| I don't think it's either objectively true or false, but if
| you find it true for yourself, then it most definitely is
| true. There are few things more satisfying in life than
| interesting work done well
| yobert wrote:
| The strategy that has made me most happy is to divide my work
| time almost in half. Half is regulated, doing tickets, choosing
| the high priority long term work, documenting, and moving
| milestones. The other half, I always work on the most recently
| requested thing of me, or really whatever sounds fun, no matter
| how small or stupid it is, and I don't guilt myself over it. It
| has worked really well!
___________________________________________________________________
(page generated 2021-08-06 23:00 UTC)