Problem in some teams are the respective audiences for the commit activity v. the ticket activity.
The people who will engage on commit activity tend to have a greater common ground and sensibilities. Likely have to document your work and do code reviews as the code gets into the codebase and other such activity.
However, on the ticket side you are likely to get people involved that are really obnoxious to contend with. Things like:
Getting caught up in arguments over sizing where the argument takes more of your time than doing the request
Having to explain to someone who shouldn’t care why the ticket was opened in the first place despite all the real stakeholders knowing immediately that it makes sense.
Work getting prioritized or descoped due to some political infighting rather than actual business need
Putting extra work to unwind completed work due to some miscommunication on planning and a project manager wanting to punish a marketing person for failing to properly get their request through the process
Walking an issue through the process to completion involves having to iterate through 7 states, with about 16 mandatory fields that are editable/not editable depending on which state and sometimes the process is stuck due to not having permission because of some bureaucratic nonsense that runs counter to everyone’s real world understanding.
In a company with armies of project managers the ticket side is the side of dread even if the technical code side is relatively sane.
Haha, i’d write a thousand pages of documentation before entering ticket hell.
I fact I do put a lot of information into the ticket - they still won’t read it though and i’ll have to repeat myself 15 times to 5 different people.
The solution to this problem. . .
I have no idea, but I’m sure they’ll appoint another delivery manager who will get hired by the ones who already know fuck-all to know less than them.
I’ve found that the few managers who want documentation, get documentation, and the others who want tickets and “story points”, get tickets and fictional bullshit - in general.___
is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)
Problem in some teams are the respective audiences for the commit activity v. the ticket activity.
The people who will engage on commit activity tend to have a greater common ground and sensibilities. Likely have to document your work and do code reviews as the code gets into the codebase and other such activity.
However, on the ticket side you are likely to get people involved that are really obnoxious to contend with. Things like:
In a company with armies of project managers the ticket side is the side of dread even if the technical code side is relatively sane.
Haha, i’d write a thousand pages of documentation before entering ticket hell. I fact I do put a lot of information into the ticket - they still won’t read it though and i’ll have to repeat myself 15 times to 5 different people.
The solution to this problem. . . I have no idea, but I’m sure they’ll appoint another delivery manager who will get hired by the ones who already know fuck-all to know less than them.
I’ve found that the few managers who want documentation, get documentation, and the others who want tickets and “story points”, get tickets and fictional bullshit - in general.___
Don’t know about solving, but at least can see the signs:
is that they have to create a support ticket with you, that you then put in progress, and you walk them through your documentation, and then log your time spent onto that ticket. (/s)
The asteroid would have wiped us out before you guys finished this long ass conversation
Let’s put a story point estimation on that. Then we can extrapolate time range and risk.