Kind of off topic but some people are really bad at writing jira tickets.
“Show the user a list of projects [eof]”
Ok but like, only their projects, right? Do they need to be ordered? Searchable? Paginated? Only active ones or soft deleted ones, too? Do you just need the name or do you need metadata too?
Somehow product doesn’t love my stance of “if it’s not on the ticket or in a sop, the behavior is undefined and you get what you get” stance.
The problem is that requirements refinement has been unceremoniously dumped in your lap. The failure here is organizational; maybe you have a design person involved, maybe devs are expected to do this. Either way, your job now also includes communications.
One strategy I’ve used is to draw a low-fi example of what they’re going to get - Figma is great at this these days. Then I add it to the issue and push the whole thing back for early approval in order to suss out these finer points.
Not to come off as misanthropic here, but many people are hot garbage at describing what’s in their head. Most of the time, it’s all abstract concepts up there until you start asking the real questions. They really do need a whole-ass conversation to sharpen that mental image. Or in this case, what they want that feature to look like. Incidentally, this is also the reason why therapy is a thing, and why it takes people years to make sense of themselves, and that outcome is usually far more crucial than anything we’re doing at the keyboard.
Dealing with this at the moment - in an org that’s been pretty lax at writing anything down about what and why as far as internal software goes, trying (with support from C-suite) to get people to actually write up any amount of detail in their requests is like pulling teeth.
I tend to take that position as well; if it’s not defined, I get to define it. If I ask for feedback or review and get silence, that means you approve.
If it’s someone else’s job to design things, then that’s a pretty terrible specification. But depending on your role, it’s common enough for there to be one person who designs and builds a feature like “User projects dashboard”, and the job is to decide what’s important based on the product. Especially with smaller companies.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
Kind of off topic but some people are really bad at writing jira tickets.
“Show the user a list of projects [eof]”
Ok but like, only their projects, right? Do they need to be ordered? Searchable? Paginated? Only active ones or soft deleted ones, too? Do you just need the name or do you need metadata too?
Somehow product doesn’t love my stance of “if it’s not on the ticket or in a sop, the behavior is undefined and you get what you get” stance.
If you think it’s fine to show a list of a variable length without it being sortable, searchable, and pagineable, that’d be on you.
Reminds me of this gem: https://lizengland.com/blog/2014/04/the-door-problem/
The problem is that requirements refinement has been unceremoniously dumped in your lap. The failure here is organizational; maybe you have a design person involved, maybe devs are expected to do this. Either way, your job now also includes communications.
One strategy I’ve used is to draw a low-fi example of what they’re going to get - Figma is great at this these days. Then I add it to the issue and push the whole thing back for early approval in order to suss out these finer points.
Not to come off as misanthropic here, but many people are hot garbage at describing what’s in their head. Most of the time, it’s all abstract concepts up there until you start asking the real questions. They really do need a whole-ass conversation to sharpen that mental image. Or in this case, what they want that feature to look like. Incidentally, this is also the reason why therapy is a thing, and why it takes people years to make sense of themselves, and that outcome is usually far more crucial than anything we’re doing at the keyboard.
Dealing with this at the moment - in an org that’s been pretty lax at writing anything down about what and why as far as internal software goes, trying (with support from C-suite) to get people to actually write up any amount of detail in their requests is like pulling teeth.
I tend to take that position as well; if it’s not defined, I get to define it. If I ask for feedback or review and get silence, that means you approve.
If it’s someone else’s job to design things, then that’s a pretty terrible specification. But depending on your role, it’s common enough for there to be one person who designs and builds a feature like “User projects dashboard”, and the job is to decide what’s important based on the product. Especially with smaller companies.
This is me, writing jiras for myself.
Being in IT communicating must be really hard.