Evolution of Technology: How does a new functionality arise?

2018-08-29T17:33:30+00:00 29 August|

By Leo Masri, Product Manager

Within the cycle of life of Toolbox products, there is a crucial stage, which is the addition of new features to the platforms, or the improvement of existing functionalities. Every new feature represents a specific development that impacts the product, which is why it is essential that analysis and estimations are performed, specific resources are assigned, and that said development goes through the tests and quality controls of the areas involved.

At Toolbox, we aim to always be at the forefront with high-end technology. This is why this topic becomes fundamental: it is what promotes the constant evolution of our products. We have new releases of products every week, while our Sales, Product, and Implementation and Support teams, who have a fluent communication with clients, are constantly considering different suggestions for improvement. By marketing our software as a service, from the Cloud, updates arrive in a seamless and transparent way to users. Updates are performed during the least concurred hours of the platforms, and do not require the installation of patches or new local versions for operation.

The kickoff

That start point of a new functionality may be a demand from the client, or a suggestion from a member of the Sales, Development or Product teams, and may even come from the Legal team, since a new regulation may have an impact on an existing functionality or demand new abilities. The initiative can also emerge from the observation of other similar products in the market, or from access to new tools and resources that make viable projects that were previously not profitable or were very complex to execute.

When a proposal of improvement or new functionality arrives, the analysis process begins. The first thing to be observed is whether said functionality adds value to the product. In other words, if the modifications or additions are useful for every client, even if the requirement was submitted by one of them.

If we’re talking about a particular requirement from only one client, which won’t be as useful to the rest, it is possible that this does not become a new functionality. From Toolbox, we assist clients providing all the necessary information for the development to be made. This will allow them to enrich their products without having to modify our platform. The specific requirements for reporting are one example of these particular cases. In this case, we make sure that the product’s API provides the information that the clients need and how to obtain it and add it to their own software.

If the functionality becomes interesting for several users, we analyze cost and benefits. During this second analysis, we work with the Architecture and Development teams to know how many man-hours have to be invested on this development. We need to answer whether the new functionality will meet the minimum profitability requirements regarding the investment made. Sometimes the benefits do not justify promoting this new development, despite the convenience of including a new functionality. In other cases, on some occasions (for example, before and during a World Cup), the work teams do not have time to face new projects that are not related to that conjuncture. In that case, the project will stay on the agenda, for a future re-evaluation.

The development and deployment machinery

Some areas within Development work based on the KANBAN methodology, with backlogs (or list of tasks) that are prioritized and weekly updated. The backlog of the product development areas is prioritized and updated from Product management. This is performed during backlog grooming meetings, every Friday morning, where Product and Development participate.

Next is Development, testing, and product quality assurance. After these stages have been successfully completed, if it is a technical addition (something that the client does not see on the first display, such as an API modification or a way to make a process more efficient), it is reviewed by Architecture. After the successful completion of this step, it is then modified and goes into production. If not, as might happen in the case of a visual interface change, an acceptance test is performed, and it goes to Implementation and Support.

Our priority is always the platform’s stability. We proactively monitor the performance of the platform to make sure it works properly with every modification or addition. If performance shows an error, we immediately perform a deployment rollback to analyze the problem and solve it without it interfering with the clients’ operation.

BACK