Stupidity is...
Jan. 6th, 2006 10:26 am![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
the-s-guy.livejournal.com posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
techrecoveryI've always thought that managers who make up stupid procedures and policies about the way I should do my job should be made to suffer.
That in mind, I have embraced the latest stupidity with open arms and a disturbingly enthusiastic grin.
Our ticket logs are already required to have the following in them:
1) A step-by-step log of what we did to resolve the problem
2) A pick-list of close codes (often completely useless) saying what we did to resolve the problem
Now we have to add to the log a one-line summary of what we did to resolve the problem. These summaries must be prefixed by a standard text string, allowing them to be skimmed and collated into a report for the manager who had this oh-so-BRILLIANT idea in the first place.
However, they forgot to implement standards for the actual content of the strings.
My resolution strings now contain a list of all the manager-caused, in-house screwups which led to the reported problem being a problem in the first place. Anyone reading the report (and apparently it is one of those few reports which actually DOES get read) will find a litany of damnation against the manager who asked for these redundant, timewasting methods of slowing down the Helpdesk.
A minor but still vocal component will be pointing the finger at the in-house project 'managers' responsible for software which has been spitting out errors for the better part of a decade. These have caused tens of thousands of unnecessary support calls while they themselves remain blithely aloof from the constant screams of rage and demands for fixes.
Stupidity is allowing the staff you're screwing over direct write access to a segment of your reports.
That in mind, I have embraced the latest stupidity with open arms and a disturbingly enthusiastic grin.
Our ticket logs are already required to have the following in them:
1) A step-by-step log of what we did to resolve the problem
2) A pick-list of close codes (often completely useless) saying what we did to resolve the problem
Now we have to add to the log a one-line summary of what we did to resolve the problem. These summaries must be prefixed by a standard text string, allowing them to be skimmed and collated into a report for the manager who had this oh-so-BRILLIANT idea in the first place.
However, they forgot to implement standards for the actual content of the strings.
My resolution strings now contain a list of all the manager-caused, in-house screwups which led to the reported problem being a problem in the first place. Anyone reading the report (and apparently it is one of those few reports which actually DOES get read) will find a litany of damnation against the manager who asked for these redundant, timewasting methods of slowing down the Helpdesk.
A minor but still vocal component will be pointing the finger at the in-house project 'managers' responsible for software which has been spitting out errors for the better part of a decade. These have caused tens of thousands of unnecessary support calls while they themselves remain blithely aloof from the constant screams of rage and demands for fixes.
Stupidity is allowing the staff you're screwing over direct write access to a segment of your reports.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2006-01-06 12:15 am (UTC)no subject
Date: 2006-01-06 12:17 am (UTC)But encouraging people to throw bricks through the windows when you aren't looking isn't good for corporate security :).
no subject
Date: 2006-01-06 12:29 am (UTC)no subject
Date: 2006-01-06 02:53 am (UTC)no subject
Date: 2006-01-06 05:32 am (UTC)no subject
Date: 2006-01-06 10:43 am (UTC)Or ASCII art of Goatse.