Tech is no longer a secluded department, tucked away in its corner of the building and hidden from the rest of the organization. As IT and programming departments move to the forefront of business strategies, developers and engineers must now communicate complex technical ideas to people who lack a technical background.
The communication skills required to present knowledge-specific information to "non-techies" are increasingly important. It is more than just developers giving a presentation to the marketing department. People from all disciplines must explain industry details to stakeholders who may not understand the jargon.
If you’re currently struggling with communication between the tech and business side, our post may help you figure it out. It will also suggest a few techniques which can help you handle errors in production if your client is non-technical.
What are software bugs?
A software bug is a flaw, error, or fault in a programme. This error causes the application to behave unexpectedly or unintendedly, such as crashing or returning invalid results.
We deal with software bugs all the time as software developers. We all know what one is when we see one, right? But what exactly is a software bug? Because we spend so much time preventing, identifying and correcting bugs, examining, defining, and naming the various parts of a bug has a lot of value. This process enables developers to use more precise language and reasoning in our debugging approach. It may be able to reduce the amount of effort required for debugging. It may assist software companies such as ours to decide how to plan our processes and procedures, allowing us to be more effective at creating bug-free software.
What Causes Software Bugs?
Have you heard of software testing defects? Yes, those that annoy software users and degrade app performance. Numerous types of software bugs occur during the software development process. This article defines a bug in software testing, goes over the most common types of software bugs, and explains why bug testing is an essential part of software development.
Can bugs be features?
Bugs can sometimes appear to be features and vice versa. It may result in bugs becoming a part of a product. Sarah and her team deliver the most recent version of Product XYZ. They anticipate that it will function in a specific manner. But when it goes live, something doesn't work correctly. Customers, however, are unaware that there is a bug. They adore it. They believe it was fated to be this way. So Sarah accepts it and refers to it as a feature. If users dislike it, the bug remains a bug. And Sarah has to take action.
How to talk to non-technical people?
Here are a few tips on how to talk to non-software development departments.
Understand the point of information
Before delivering your presentation, go over each point you plan to make and ask yourself, "What does this give the listener?" When the audience understands how a topic relates to their lives, it becomes more digestible. Coworkers, for example, are unlikely to appreciate the intricacies of coding changes required to integrate a new payment function into the current system. They will understand a simple statement explaining that users will be able to request refunds more efficiently, relieving the accounting department of stress.
Give detailed context
Focus on the why rather than the how-to avoid going too far down a technical rabbit hole where no one else is looking. The how is the detailed, technical specifics that could confuse an average listener. The why refers to the larger context and significance of the shared information.
Consider it similar to reading an architect's blueprints. Most people do not understand how to interpret all of the lines, angles, and numbers, so an architect would be wasting their time explaining how they measured the spacing. The context and impact are essential to the recipients of these blueprints.
Meet them where they are
We've all heard the saying, "Treat others the way you want to be treated." Instead of expecting people to meet your expectations, apply the platinum rule and adjust to their comfort level. Before creating your technical presentation, consider where your audience is coming from. Do they have a college education? Do they work in a creative field? How much IT experience do they have? It will provide you with a home base for direction, allowing you to pull yourself back if you get too deep into a topic and cater to the listener's needs.
Use visuals
Some concepts are difficult to express. You can spend half the meeting going over the audience's heads as you try to explain the functional differences between your company's iOS app and web app versions. You can also put some images on the screen to illustrate your point quickly. Consider that your peers will most likely have different learning styles. Some people may be auditory and thus better able to follow the conversation. Visual learners who hear something technical and new may struggle to grasp the concept. Including images and illustrations can help clarify details that might otherwise overlook.
Don't assume
It is difficult to predict someone's literacy on a subject outside of their area of expertise. Speaking in technical terms can isolate people who are unfamiliar with the subject matter. Instead of using specialized words, use a more exact synonym, define before someone asks, and use analogies to illustrate topics.
These tips will help you remember the average non-technical listener. Using a few of them can elevate and make accessible any industry-specific topic to the general public. Conversations with coworkers from other departments will flow more smoothly as ideas are fluidly shared. It can increase efficiency and make people feel more connected to the overall business direction.
How to find, report and handle bugs with a non-technical client?
In this article, I'd like to suggest a few techniques for dealing with production errors if your client is non-technical. Of course, the best way to deal with errors is to avoid them in the first place. We can try to achieve this by creating a reliable test suite, conducting code reviews, and performing quality assurance. Here are some bugs that report and handled with a non-technical client.
Finding bugs
The best way to handle errors is, of course, to prevent them from occurring. We can try to achieve that by writing reliable test suite, code reviews, and QA.
An excellent idea that you can implement in your project is adding an error tracking system to your application (for instance, Honeybadger or Airbrake). Service like this notifies you immediately after something wrong happened in your application. It allows you to act faster as opposed to waiting for the client’s bug report. An error tracking system provides you with a stack trace, together with the details about the request and environment that triggered the error. Usually, it is everything you need in order to quickly debug your problem.
Unfortunately, not every type of errors can be found that way. A feature that “works” but was not implemented according to the client specification is one example. This type of errors is usually reported by the client. In an ideal world, bugs like this should never left the staging environment but unfortunately, it sometimes happens. This brings us to the next point:
Reporting bugs
In order to save your time (and the client’s money), it is wise to educate your client how the errors should be reported. I suggest to ask your client to always provide you with those three things:
- a screenshot
- an URL where the error occurred
- a description of what happened or what should have happened but didn’t
That information should go directly to your ticketing system (for instance, Trello, Pivotal Tracker, Jira) and be reported as a bug. A good practice is to send a link to the ticket on a dedicated channel on a collaboration hub (for example Slack or HipChat).
Another thing that has to be explained to the client is the urgency of an error. Most errors should be fixed as fast as possible, but some bugs like, for example, a typo in the description can wait till the next morning. On the other hand, showstoppers as a cart price being wrongly calculated should be fixed immediately.
Handling bugs
As I mentioned before, all bugs should go directly to your ticketing system and therefore, they should be treated as regular tasks. What it means is that each error:
- should be prioritized
- has to be assigned to someone
- has to be resolved (obviously) with adding a regression test
- has to be reviewed
- QAed
- has to be deployed
Of course, if a quick fix is needed, you can speed up this process, but after the bug is fixed, it is wise to go back and do everything the right way.
As a team leader, you should also take care of the client. You should explain what happened and why. Estimate the possibility of a new occurrence, and suggest the way of fixing the bug. You should also provide the client with a time box in which the fix will be ready on production.
Summary
To avoid problems, you should always use the best practices in your projects. However, if some errors slip through your test suite, code reviews, QA, and staging testing, make sure you handle them properly. Remember that it is your responsibility to assist your client and educate him on the processes and best practices. In the long run, your efforts will be rewarded.
And if you’re looking for an experienced custom software development company that will communicate with you in a clear and easy-to-understand way about all the details of building software, don’t hesitate to reach out to Selleo.
