Working for the same company over many years has its good and bad side. On the positive side, you get to see how a small group of people grows and transforms into an amazing business endeavour. How talented individuals through collaboration and genuine caring, enable customers succeed online. Moreover, you involve with multiple roles and functions, and also you gain the confidence to unblock others with your decision making.
On the other side, you get to receive many “sfaliares” (literally smacks in the face in Greek) and lose your sanity over all those non-existent processes that you so desperately need to be productive and efficient in a growing environment. And as you grow, you often find yourself losing a lot of time in creating such processes, although you learn from it. One of those processes in our case was reporting a bug!
Where do bugs come from?
Our Support team is one of the main sources of feedback and the first to know if something fails to work as prescribed by having a direct access to customers. Back then we didn’t have a QA team, and as much as embarrassed I might feel today, it is a fact that by having thousands and thousands of customers, when something went wrong (not a matter of “if”), the Support team was the first to hear about it. (Still feel embarrassed).
So, the normal thing to do was to encourage the support team to send bugs to developers, product questions and ideas to the product department (I was the only PM back then with the co founders) and finally visual issues to marketing. That should be easy right? Not it wasn’t.
Bugstorm is coming!
Nobody saw it coming in the beginning. It started by me copying and pasting the same responses to different people, and by forwarding bugs to developers: “This is not a feature, it’s a bug!”. “This is not a customer request, it’s a bug”. We also had popular responses from developers mentioning that “This is not a bug, it’s a feature!” But that’s a classic 🙂
People also started copying me in emails sent to developers, asking them to “do” stuff, not describing an issue. Eventually, bugs started to become requests for information or suggestions. At the same time, developers had to follow up multiple times to understand what or where was the bug, and whether a request was a bug in the first place! At some point, after a multiple exchange of emails between support and a developer desperately trying to understand what the heck was going on, we all kinda… went from radical candids to being obnoxious aggressive!
The birth of a bug form!
The bug form was the first step towards the creation of a process to submit decent bug reports. The first thing we did , was to ban direct emails to developers. To replace that, I created a Google form (eventually they found a better way) with very specific questions. Looking back now, I might exaggerated a bit by actually creating a “bug interrogation form”! Thankfully, later they found a much better way to organise all this! Take a look:
Supporter :
Project :
Customer Username :
Product :
Product Type :
What happened? (what is the problem) :
Reproduce the problem step by step :
How should it work normally but didn’t!
And we put it to work! I was so proud I initiated a process that would eventually save time and put smiles on people’s faces! Very soon, we adopted and meticulously followed this process and everyone worked happily ever after… a developer has never said!
It’s not a feature it’s a bug!
Reporting a bug became a clear process, but still bugs continued getting mixed up with features and other issues. Why?
Not taking things for granted is not micro-management. However, to be able to take things for granted it requires for people to speak the same language. Speaking the same language leads to quick understanding, trust and productive communication. And that is why this form failed. Because, what is a bug exactly?
While for developers and product managers it’s super clear what a bug is, for support agents, accounting and even marketing that is not the case. Especially when the company is not a SaaS or a startup and in contrary it offers multiple products and add-ons through different platforms with their own features and functionality. This is a lot of work!
You need lots of experience and knowledge with every product to always get it right. And let’s be honest, all companies have bugs. The ways to handle them is to both resolve existing ones in an efficient way and minimise future ones with better code and QA. But, that is only if you actually know what a bug is! So, after lots of discussions and debates and an amusing (not) “interrogation bug form”, we went back to defining what a bug is.
The definition of a bug!
That it exactly how I started the document explaining the process of reporting a bug. I was kind of frustrated then but today I smile when I think of the way I found to let the frustration out. The definition of a bug, really? 😀 And I made everyone read it! Poor people 🙂
Bug: A software error, mistake, defect, failure, or damage on our system / site, which produces an erroneous or unexpected result. Most bugs result from errors in code or design.
Then my audacity continued, by outlining the steps to follow before sending a bug form to developers.
STEPS TO FOLLOW BEFORE CONTACTING OUR DEVELOPERS.
- We check if we are the only ones facing this issue. Talk to a colleague.
- Search our team’s manual for guidance. Are there similar cases mentioned or possible solutions that solve our customer’s problem?
- If we receive from customers twice (or 3 times) the exact same problem about a product or feature, we send the form and copy also the Product Manager.
- We define a bug as critical when it affects the appearance or availability of our websites, or our customers live websites, and in this case we also copy the PM.
- If something is related to the design or content of our online presence then we contact first our Marketing dpt.
- Code related bugs are directly sent to developers
Then, I continued the document with a user guide for the bug form and explaining the reasons why we do it this way, finishing with a table of the responsible Manager and developer for each service. If that is not OCD then I don’t know what it is 🙂
Sum Up
Always observe, learn and act. Make sure you speak the same language, do not micro -manage, definitely insist on a well-defined process. You don’t have to be too sophisticated about it, sometimes you just need to start and then the right people will take over the make the right iterations.