How a feature is born?

A SaaS solution like Regiondo is always developing and improving functions to meet the current needs of the market. Different niches of the activity market require different functions and modifications. Customers often request new features or the changing legal situation requires them. What might look easy from a personal perspective bears many hidden straps and goes much deeper than expected.

So, how long does it take to develop a new feature for your booking solution? This is what we’ll cover today.

Do you know what SaaS – Software as a Service – means? Take a look at our blog article about SaaS vs. On-Premise!

 

Example of a development process

01. Idea

On top of the pyramid is the idea or requirement for a new feature or even an upgrade of an existing one. It can be collected from legal requirements, customers or the product department. Since there are multiple requests at a time, they must be prioritized because the number of programmers is not infinite either. So the feature priority also has an impact on the time of development.

As we develop an all-in-one solution for the leisure industry, we collect requests for new features from customers before they are developed and evaluate their potential impact. This way, we ensure that individual (loud) customer requests are not preferred, but are geared to the needs of the market.

02. Specifications

Let’s say our request has reached Priority #1.

Now, someone has to write a ticket for the developers. The ticket writer could be from the Customer Success Team or Product Management. This ticket has to contain all the instructions and specifications a developer needs to code the new feature. It’s not only the approximate functionality, but it is also the exact functionality with all details and interdependencies.

Some functions have a huge impact on lots of other functions so this step of the process can take a huge amount of work and time for the ticket creator. 

Also, one requirement can result in more subtickets. When the new feature affects different parts of the system there should be different tickets for each new task.

Also, the ticket could be based just on an idea. This means the creator has to figure out how to get the expected result just before all the interdependencies are figured out.

In order to be more confident with a new feature, a dummy is created, which is tested internally and with selected customers in order to receive early feedback on the planned feature.

To avoid a long development process, we are trying to reduce new features to a logical minimum of complexity. It is easier and more efficient to extend an existing function than building a new one with huge complexity. The needed amount of time and dimension of risk are very high for complex features and there is also no feedback in between.

Most of the time we involve the stakeholder who suggested the feature to bring their input and ensure that different points of view are included in the process. After that, there are two options:

  1. The stakeholder agrees with the specification.
  2. The stakeholder does not agree and the specification needs to be revised.

 03. Development

So, after the requirement / Idea has a ticket with a specification, the development starts!

We continue because everyone agreed on the outcome. The ticket is now with the developer.

Depending on the ticket, the time required varies. After the code is created, a second developer takes a look over the code to avoid logical mistakes before it can affect something.

Once the code is reviewed, the ticket goes to the tester. To make sure that testing processes won’t damage the current version of the booking solution, we are using testing environments. So if there are bugs (issues with new or existing functionality), we can fix them before releasing the new feature.

 04. Testing and collecting feedback

The tester collects potential bugs and tests different scenarios (there are always a lot of different ones to test to make sure that all of them are working fine).

After the first testing session in the first environment, there is a second one to make sure that the new function works smoothly.

When there is no bug left on both testing environments, the function is ready to go live!

Normally, everything works fine but the tester also checks the live version just in case.

Now that the feature is live and all customers can use it, we’re starting to collect feedback on it. This feedback will result in new updates for this feature or bugs that were previously unknown.

Why could bugs even happen when a new function is live following different testing environments?

The reason is the diversity of the leisure industry. The users of Regiondo have found countless ways to present their leisure offers in their ticket shops and there are countless scenarios associated with this, which can never be tested in advance.

Quality takes time

As you can see, we have a comprehensive quality check before we introduce new features. This, of course, requires time and manpower.

So if you expect a new function, forgive us for longer development times or functions that need to be reworked. This is part of a complex system like Regiondo. We do our best every day to provide you with the best functions as quickly as possible.

Regiondo is continuously working on new features and extensions. Take a look at our new features and updates 🙂

 

About Alexander Bechte
Alex is Regiondo's Product Marketing Manager and passionate about traveling and digitalization. He is from Hamburg and studied tourism management in Munich. His aim is to inform you about the product side of Regiondo to improve your business!
All posts by Alexander Bechte

Leave a Reply

Your email address will not be published. Required fields are marked *