CULTURE

Working methodologies in SaaS companies

When your goal is to become the best Revenue Management System on the market, you must organise a working system that is efficient and scalable across all departments.

By Vanessa Hernández, Product Analyst at Beonprice

After the publication of our previous article on the main results of 2020 in the technology department of Beonprice, you are probably wondering how we have achieved these figures and what is our working methodology. The reason for this new article is to describe each step on our way to becoming the best Revenue Management System on the market.

The technology department at Beonprice

Our Technology department, although it is made up of a close-knit team that works to achieve a common goal, is structured in two main blocks: the product team and the development team. Both teams follow the Agile working methodology, which follows 4 principles:

1. Individuals and interactions over processes and tools

2. Software running on extensive documentation

3. Collaboration with the customer on contractual negotiation

4. Response to change over following a plan

With this in mind, we follow the Scrum framework, which is composed of sprints (periods of one or two weeks) during which teams carry out pre-planned tasks, always with a deliverable in mind.

From the product team we ensure that:

1. We provide added value with our solution, always keeping our focus on understanding the problem and the needs of hoteliers (Revenue managers).

2. We are competitive in the market by designing attractive, effective, quality and just-in-time solutions for our clients.

3. We define the high level of functionality and quality to maintain the optimal functioning of the system.

To do this, once we have collected the needs of our customers, analysed the problem they are facing and prioritised our Roadmap, we plan the Sprint Planning. During our sprint we carry out the necessary tasks to ensure the proper functioning of the projects to come, while we carry out the necessary continuous validations of the functionalities that have already been delivered.

Work methodologies in the Product dpt

For the projects that have been prioritised for further development, Product dpt prepares the requirements document, which includes not only the what but also the why. Thus, this document follows a structure as follows:

· Using our Lean Canvas template adapted to our internal needs, we include the definition of terms, definition of the problem the client is facing, the value proposition the project will bring, the competitive advantage it will provide, the metrics to be measured once the project is completed, and the interdepartmental dependencies. This helps us to have a complete summary that we can share not only with the development team, but also with stakeholders, sales teams and Customer Excellence.

· Prototype: During the specification process, a prototype is prepared so that the development team knows what the purpose of the project in question is. In the case of new functionality, we generate interactive prototypes using design tools, which help to explain the proposed solution more effectively. In the case of proprietary algorithm projects, this prototype usually includes the necessary calculations and expected output.

· Job Stories: Unlike many other companies that use User Stories, at Beonprice we decided to use Intercom’s methodology through Job Stories (when…, I want to…, so I can…) which are more focused on the situation and motivation rather than the person and the action. This helped our technical team to better understand the behaviour of the request as the needs among our users are very similar.

· Acceptance criteria: In order to write these acceptance criteria in a language that both teams (product and development) understand, we used the BDD (Behaviour Driven Development) method, which describes the behaviour of the software. This method also helps us to automate the validation tests once the development is finished.

· Flowchart: In the case of an algorithm project, this diagram is fundamental for the understanding and development of the algorithm. It helps us to define the input and output data that must be applied to achieve the expected result of the project in question.

Once the requirements document is ready, we have sessions with the developers prior to their sprint planning to validate that the documentation will be complete, and to minimise any questions that may arise during development. This also helps us to get feedback and add any new requirements, if necessary.

The development team

At the same time, we have our techies in the development team, which, like the product team, organises its sprints according to the tasks necessary for the development of each project. At the beginning of the sprint we establish what the deliverable should be by the end of the sprint, based on the prioritised roadmap and requirements documents coming from the product team.

These development teams are separated into squads, each working on different tasks and projects. This helps us to ensure the speed we require. During the sprint, in addition to sprint development, we maintain a level of code testing of at least 80% of the code for new projects. This is known as TDD (Test-driven development), which includes BDD behavioural testing, and ensures data quality.

Once the project is developed, we move on to the validation phase, both internally in the development team and in the product team. With this validation, we confirm that the development meets the requirements, and in turn the pull requests are prepared: a squad other than the one that has developed the project in question analyses and validates the code.

As we can see, we not only test projects, but we also subjectively assess the development of the code.

The importance of working together with other departments

As far as the development team is concerned, we must not forget the most important pillar we have in technology, our data, and its integration. For this we have our colleagues in Integrations who ensure at all times the integration of Beonprice with the necessary sources that may involve obtaining the data, as long as they allow us to maintain our good quality.

So far we have mentioned the methodology we use at Beonprice for project development, but not everything stops there; as you can see, at Beonprice we don’t get bored! Thanks to the help of our colleagues in the Engagement team, we have our case studies. Case studies are, as the name suggests, special cases that need to be analysed in detail, either because the result of the algorithm may require explanation, or because it is not reacting under some casuistry that has not been previously identified. These are of great importance, not only for the improvement of our algorithm, but also for the improvement of potential functionalities for future projects.

I hope this article has clarified your doubts regarding how we achieve the figures shown in the previous article, we know that there is always room for improvement in the work methodology, and from Beonprice we keep our minds open to everything that leads to improvement and increased productivity.

Go to Top