Smashing Bugs

 As I wrote about last week, I have a project that went live.  While I am really excited about this, I am now dealing with the downside – bugs and additional desired functionality that was never brought up while developing the specifications.

 

Bugs 

To be fair, not all of the issues are really bugs, some are just a matter of users using the system in unintended ways.  As a system analyst and the designer of the project, I am also trying to shield the developers from the multitude of user noise, gain an understanding of the problem, and relaying this information to the developers.  For me, this is a great way to learn how the users are using the system and helps me understand what other enhancements might be beneficial in streamlining the work and removing waste from the value stream.

 

The first report that we received was that a user couldn’t save their input because the entire page wasn’t loading.  As we are handling transactions for multiple employers and the line number request system is only needed for one employer, I was somewhat surprised to get a report from a user for the employer that does not need to have account numbers assigned.  I submitted a ticket and spoke with the developer.  It turns out that there was a bug in the code.  Somewhat simplified, the front end got to the point where is was displaying the data for a line number and the back end said, “I don’t know what you are talking about.”  The front end said, “That’s okay, I have all of eternity to wait…” and so it did.  According to the developer, this was an easy resolution but it came up again a few days later.  Crossing my fingers that it is fixed, even thought I didn’t code it, I am the face of the enhancement.

 

The second report that came up was due to a user being unable to save data.  This was definitely a user error as the user had the transaction set to void when she was attempting to save the data.  The system doesn’t like this status and refused to go along with the user’s request.  I don’t know if this issue was pre-existing or part of the new code.  Regardless, it seems to me that the user should get a warning or error message in this scenario and I have added it to the future enhancements list, ranking it right up there and probably trying to incorporate it into our data validation project.  As data validation has been started, we may wait for the next iteration of that project to include a message for that error as well as a similar error where the same datum was left as null.

 

Of course, there is the issue that was directly my fault, I take full responsibility for picking the wrong field for a data validation point.  I try to make my projects as ready to code as I can for our developers.  This includes detailed diagrams, telling them which fields in the database to reference or write.  One critical piece of information is displayed in two different areas.  It turns out that the area that I picked isn’t always populated, making it worse, the other area that this information exists in isn’t always populated, either, but it is a critical piece of data as a line can’t be assigned without one.  As it is only a binary, y/n, flag, we may just add the ability to select if the data isn’t available in the requisition.  It is an important lesson for me to validate the fields better than I did with this example.

 

Then we come to my favorite two issues.  The lack of a batch process and the lack of emails for the recruiting team to track their process with.  As it turns out, nobody said anything about the need to be able to request lines as a batch.  It is a well-known need, but it didn’t come up at all while we were doing our needs analysis and workflow documentation but it happened, a recruiter sent me a message with 30 reqs.  She wanted to know if she had to request each one individually or if she could just email the list to the transactions team that processes the line requests.  I had to remind her that the purpose of the project was to eliminate the emails due to the volume of emails and the amount of missing information.  She wasn’t pleased but I did offer to devise a method for this to be addressed in a future release.

 

My other favorite issue was from the same individual.  She said that she relies on the email communications to track when thing were requested and when they were completed.  She specifically cited the value of the time/date stamp on the email.  For me, this is an easy fix, let’s produce a report.  I explained to the user that we have audit logs in the system and I could easily develop a report for her and have that set up in the system so that she can pull it on demand.  We worked together to figure out what the most pressing information was and developed a prototype.  She was okay with the sample and I am now waiting for her okay to publish the report in the system.  Alternatively, if she requests me to pull the report for her again, I will just have it published in the system.

 

While none of these were major issues, they are inconveniences for the users and my goal and intent is to make things easier for all users involved.  While the teams that I am working with are very supportive of what I am trying to do, I hate that we can’t simply release such an enhancement without the issues.  I am sure that, as I get better at what I do, we will get better at publishing projects that do not have these issues.   We should find out soon because another project that I am working on will have it’s first phase go live next week and we can cycle the bug reporting challenges all over again.