You're probably getting downvotes because you said "ticket."
Which speaks to another problem with most large company cultures: ticket shoveling. In a healthy company, every ticket should receive one of three outcomes.
(1) I can fix this, I work the ticket to completion, then request verification it's resolved.
(2) I cannot fix this, but I know someone who can. I add context if needed, forward it to the appropriate person, and stay appraised of it and available until it's completed.
(3) I cannot fix this, and nobody I know of can. I list out reasons why this cannot be fixed, and give any information I might have about alternative contacts who might(!) be able to help, and close the ticket.
In most companies, and I think this has been exacerbated by outsourced IT and contractual resolution SLAs, until everyone's internalized it as the way they and everyone else should act, you get something like this.
(1) Is work. This is to be avoided at all cost.
(2) I blindly forward a ticket on to anyone else who looks remotely responsible, to get it out of my queue, and then wash my hands of the entire matter and forget it ever existed. I certainly don't follow up or add context.
(3) I close the ticket without providing any reason why, or information I have about someone who might know something I don't, who could help.
A reliable metric I've come up with for measuring corporate and/or team disfunction is to count how many circuits a worst-case ticket can receive (where a circuit is: originator -> some number of teams -> originator/loop). My record is 3, before someone noticed.
I would like to add another interesting pattern that get exercised when a ticket is work, and forwarding will make it bounce back. You forward only to your IT support team one by one. And each member attempts to waste as much of the requester's time as possible. Each time waster is creative, but usually it consists of minimal efforts in asking question taking maximal effort to answer. Good chance the requester will give up on that ticket before the full team went at it, and would gladly agree to get that closed as remediated. Better live with a problem than a bigger one.
I think this is true too, but I don't blame folks.
I recently started a position which is the first time I ever worked as a non-freelancer. Previously I always wrote documentation for myself and my clients in self contained Markdown files.
But at this new place they use a combination of Confluence and Google Docs for any type of docs that don't necessarily belong in a repo's readme file (like ancillary topics, general knowledge and guides). It's not easy to find stuff unless you already know where to look. Confluence's full text search is also pretty lackluster.
Turns out keeping documentation and knowledge up to date when you're dealing with a handful of folks isn't easy. Especially if you factor in everyone contributing their own docs with their own writing style and patterns. It makes for a pretty inconsistent feel.
> "In my experience, people don't read documents."
I think this is worth calling out for its own discussion. Along with the traditional use of "RTFM" meaning "go away and stop bothering me", any amount of dysfunction in a sytem or company can be tolerated as long as someone has written about it in a document somewhere.
Poor design? Buggy implementation? Complex configuration? Poor defaults? Missing features with inconvenient workarounds? Arduous processes? All fine as long as it's been documented. And any comments about voluminous documentation and "I couldn't find it" become point-scoring "I know where the needle is in the documentation haystack so I win".
And as a user or customer, the last thing I want when facing your system being complex and unintuitive is a mountain of documentation to go with it. That adds insult to injury - you couldn't make a good system and you've made more work for me on top. How often have any of you read some good documentation about the internal workings of a system and left feeling intrigued and surprised and impressed? Occasionally, right? And how often have you trawled through documentation saying things like "to change the username field, simply log into our admin website, click accounts, click usernames, click customize, then download the XML customization file from the available template files, make the necessary changes, and simply raise a support ticket for us to install the new file" ? A poorly designed feature with an awkward process, with parts where detail matters (content of the file) left for guesswork, but at least it's all documented.
I want my intuition (experience) to carry me almost seamlessly through your system, and if it has a short amount of clear documentation which helps me then I'm OK with that. If you want me to commit to trawling through books worth of content to learn things which are your own proprietary lock-in buzzwords around Rube Goldberg kludge designs, I'm not as OK with that.
There's a conflict in what you say. If people don't read documents and will ask when they need something, why invest in creating heavy tickets filled with the text they don't want?
My team (and many XP teams) gets by just fine organizing things with cards that have a modest number of words on them (5-10, normally). When we need something, we ask. It works fine for us. We're a distributed team that has never met in person. But it also works fine for in-person teams: https://williampietri.com/writing/2015/the-big-board/
I called it ticket, you can call it card. I did not say it to be heavy. But should also contain enough info to get started or at least point to the right person.
What you are describing is definitely heavier than what I'm describing.
And I disagree it should contain those things. In the XP tradition story cards (which are conceptually different than tickets, but I'm fine with either term) are tokens for conversations. The more documentation you add, the more it drives people away from conversation. As you say, when people need something, they'll ask. And I think that's a strength, not a weakness.
When they need something they will ask.
A meeting should always have an outcome in the form of actionable work;just create tickets and assign them to people.
The ticket should capture all the necessary information to work on it. If a document is needed, it should be linked to the ticket.
As for developers, scripts, tools, automation works better than a boring, soon to be outdated document.