3 ms·

> you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem" This is an interesting perspective but perhaps crosses

• raffraffraff 4y ago
  Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle. After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets. Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!" All that from taking the ITIL course seriously. If you're going to hack the system, understand it