Back in the days of Rapid Application Development, Microsoft Visual Basic & ASP were the tools of choice for a lot of developers including me.
The user called on the phone, emailed or spoke to you in the hall about what changes they needed. For those of us who didn't know any better we usually did what they asked. There was no record of the request and no history of the exchange.
Today, things move super fast. And coding enhancements have to keep up. However, I have discovered that ALL user requests should be documented and recorded in a ticketing system.
Typically the user contacts the Help Desk with their one or two sentence request. The ticket then gets forwarded to a department where it sits in the queue. At first glance the request may have well been written in hieroglyphics because the nugget of request is nowhere to be found.
At that time, it's up to the developer to contact the user and figure out exactly what they really want. The ticket should get updated to record the request. Some shops use the SDLC process to enforce requirements and hold the user's feet to the fire. After specs are formally gathered into the document, the users typically signs off on the request.
I find that users still like to email/phone in their request. When that happens I like to enter a ticket in and assign the user so an email gets generated to all parties involved.
While developing the report/software, more clarification is needed and emails are exchanged between user and developer. I like to add the gist of the conversation to the ticket for audit purposes.
In addition, when I manage the queue, I like to go through all the tickets assigned to the reporting team and document where we stand on each item. That way I can print a quick report to bring to a meeting to discuss current status with peers/customers.
Only when a customer agrees should the ticket be closed. A lot of times the eager developer closes the ticket premature and the user gets annoyed.
I like to tell people "I'm in the ticket closing business." It seems odd but that's basically the truth. I told one of my customer's this and he replied, "I'm in the ticket creating business."
What are the benefits of the ticketing system. More reports. You can now dissect who requested what when, how long it takes, heavy users, and the list goes on and on. I recently created a report which got sent to 122 users asking them to close all their tickets as they went into the black hole of ticketing and were not updated for a long time.
The trick is to effectively manage the queue and not let anything exceed 180 days. Obviously things out of our control cause delays. However, if you document the ticket, anyone at anytime can go through the ticket and see where the hold ups occurred.
When a ticket enters our queue, I review, estimate the difficulty, see what resources I have available, juggle the priorities and assign the report. About half the time I end up writing the report myself as we have limited resources and never ending requests. We also have some reports that have greater complexity and I tend to work on those.
I think by having some level of order, IT people can now manage the chaos that once existed.
Few words of advice, don't call the help desk if your Doritos got stuck in the vending machine or if the Twitter site is moving slow. Also, don't place a "wake up call for 3pm" with the help desk or ask if the 900# access has been blocked!!
I signed up for the Hortonworks Certified Associate exam last Thursday. Figured if I sign up, I'd have to take the test. And if I tak...
Saw a post today on Twitter, " Microsoft releases CNTK, its open source deep learning toolkit, on GitHub " This is big news. Be...
It seems like open source applications are the mainstream today. So many new products delivered through Aache foundation. Some do this. S...