This material will be useful to anyone who has decided to move towards the digitalization of their business and is deciding what to do and how to avoid mistakes. And also for those who have experience but who want to improve their approaches by understanding how to use their app to help their clients better than existing services do.
If you already have a great idea and all you need is to successfully implement it, then the following interview with someone who has extensive experience in the development of both complex systems and small and successful startups will be useful to you. Paul Belevich has led the development of projects such as World of Tanks, Master of Orion, and QA Supermarket self-service.
Q: Paul, in your opinion, what makes a perfect application?
A: I would start with two simple, but very important points: the ideal application is an application that has an interesting idea at its core and which correctly carries out the tasks assigned to it.
When starting a project, I always start by answering the basic questions: What do you want to give to people? Who is your audience? What do they need, and how will the uniqueness of what you want to do be expressed? It could be related to something local, important for people from your region, or for a specific interest or specific group of people who your application can help. Very often we come across amazing ideas that facilitate or improve some aspect of life. We are happy to help with such projects.
At the idea stage, in 99% of cases, projects are thought out very in very rough, general terms, and are shattered immediately when clarifying questions about implementation are asked. So the first thing to do if you think you might not be tech-savvy enough is to find a tech person. Once in the development phase of an idea, a technical person can immediately see the pitfalls that may arise. And the closer the interaction between these people, that is, the owner of the idea and his technical representative (CTO), the closer you can get to achieving the goal of making a great app. Ignoring this condition often leads to the disappointment of the passionate idea owner in the end. Figuratively speaking, by relying solely on their own strengths and a team of experienced developers, they often end up with a steamboat instead of a yacht. In order for the conversation between the business owner and the developers to be in the same language and to exercise competent control, you need the so-called voice of the customer. It’s very important that the tech person knows everything that is going on and interacts with the developers. He listens to their arguments and makes decisions that are beneficial to the business. Otherwise, a person could order a social network but get a primitive dating site, instead. It’s very important to describe details before getting estimates when looking for a remote team, for example. After all, companies will most likely make offers for a product that is not at all like you intended, but in the absence of other introductory information, they rely on something simple or standard. As a result, the work order as described in the contract will be officially executed, but the customer runs the risk of getting something that is either not exactly, or not at all, what he wanted. Or, if something is changed during the development process, you will significantly exceed your budget and time frame. Sometimes, unfortunately, that’s enough for the application to never be published.
Q: Let’s talk more about the technical person in a project. Who are they and what is their role?
A: First, let’s divide the roles:
· The Stakeholder – understands what functions the product should have and what business case it should correspond to.
· The Product owner – Presents the product’s behavior in as much detail as possible.
· The Technology owner (CTO) – knows how the product can be implemented technically.
Usually, for small projects (startups) in the beginning, the Stakeholder is also the sponsor (or attracts the funding), and the product owner and technology owner are often the same person. Sometimes, at the very beginning of a project, this person can also take on some code development. The most important thing is that this is the person who will be helping you make a lot of decisions: from technological solutions to the language in which the application will be written, to platforms, to team selection, to whether or not to use cloud services, when to start testing, and much more. Most of these decisions (especially if, to save money, you do not make a working prototype (MVP) will determine the future of your app. Developing an MVP can help attract funding and avoid some of the risks, but not all of them. You also need to understand that in the vast majority of cases, all the MVP code gets thrown out and development starts from scratch.
Again, all these decisions should be made not by the Stakeholder or idea owner, but by the technology owner, with whom you are on the same side. After all, every technical solution entails budgetary and organizational changes. For example, developing an application in NodeJS has different associated costs than developing in PHP (PHP is cheaper). But if for implementation you need asynchronous solutions, then the priorities of developing in PHP to save money and the high cost of a development team on NodeJS will immediately switch places (because PHP for asynchronous solutions requires much more development time).
Your CTO should understand the idea so well so that they apply the most modern development technologies and select the shortest path for its implementation. Because sometimes development teams offer what they call an ideal solution, but it happens to be exactly those competencies and resources which they have and not those which would be the best fit for your project.
How to initiate APP development
Q: So are we saying that the first stage is a tight coupling of the Technology / Product owner and the Stakeholder?
A: Yes. These people should sit down at the table, come up with and write down in as much detail as possible everything that they expect from the application. Because, speaking from experience, this is what will decide which implementation route will be chosen. An experienced technology owner at this stage is quite capable of roughly understanding the scope of the work and the required funds. Meaning it will affect the subsequent budgeting and the search for a team or a partner. Even if it’s part of developing your own business which you finance from within and for which you make the organizational decisions. The more accurately the product owner can draw out the details of the Idea Owner’s application, the more correct the rest of the work will be, and the more accurate the budget.
Sometimes, by the way, at this stage, it becomes clear that it’s better to abandon your own development and use some ready-made solution on the market if they satisfy your tasks. And I think that’s good too.
To sum up: the future of your project depends directly on how well your planning is made a reality.
Q: What then is the second stage, if it becomes obvious that you need to start the development?
A: If you have made a detailed description of the project, as I mentioned earlier, then you can find people (quite often a remote team, nowadays) who meet your project’s needs based on the parameters you have defined. The Technology owner (CTO) must be involved in deciding which team to choose.
I won’t go into too much detail right now about the development stage, since there are various approaches to it. I would like to note the most important part: a good product owner, working closely with the idea owner via regular meetings with the team (their frequency is especially important when using Scrum or Agile) will easily find solutions to emerging issues, will be able to introduce new ideas and carry out their implementation. And then, with a high degree of probability, you will be able to see your idea come to life on your device.
Q: Does this mean that the app is ready?
A: No. And it shouldn’t see the light of day in such a state. It is very important to understand that the team of programmers who developed the application, and even you, will never be able to release the perfect app without professional specialized testing. And this testing should be started as early as possible, meaning as soon as the application has some kind of user interface. Testers have more experience with what can be done wrong with an application and how to break your app. Testing labs usually also have special equipment and other testing tools (even when using device farms).
Many people think that QA is redundant; that you can just skip this step or take care of it on your own (the so-called “friends and family” testing), and that you shouldn’t spend money on it. I will tell you right away that this is a fundamentally erroneous opinion that can lead to the collapse of the project. Yet some people still hold a misconception about automated tests – that they should either be free or extremely cheap. And that automated testing is enough to start running an application. Developers often say that they have good code and everything is working. But believe me, as soon as an app is in the hands of someone who knows nothing about it, they will immediately press the wrong button at the wrong time and the app will stop working. Bugs will yield an error. Need I even say what a user will do with such an app during the first few minutes after installing it? Maybe that’s why, according to statistics, 61% of apps fail. Test engineers know that on average, even the best developers have one bug for every 25 lines of code. Even after they have run their code through unit tests as they work.
Good automated solutions like Selenium finally are very expensive tools that your engineers can adjust for a specific application. And still, it can find only those problems for which it was programmed to search for. I won’t even get into how taxing it is to sort the results. Automated test solutions make sense both economically and technically when making and configuring a ready-made working project and you are planning how you are going to develop the project further (regular updates, etc.) That’s why I like to emphasize that it’s not the best solution to spend your money on when you’re just starting out.
Why are preparation and professional testing really important
Q: In your strategy for creating the perfect application, why do you devote so much effort specifically to planning and testing instead of coding issues?
A: Because these are the very things that are almost always overlooked when it comes to failed projects. The creators put all their effort into the software coding itself and run into failure. As a result of ignoring quality planning and testing, many good ideas, unfortunately, die before they’re ever really born. And it’s a shame.
By creating products that have become successful on the market, our team has come to understand that sustainable projects need a good separate testing laboratory. The competition is fierce and an app doesn’t get a second chance to make a good first impression. So I’m very glad that I get to share my experience and knowledge.
To support many great ideas and beginnings, to help small and medium-sized businesses and studios introduce products of excellent quality, we have figured out how to remove everything that puts a lot of strain on the testing budget on its way to you, leaving just what small applications had been lacking the whole time – the ability to utilize a state-of-the-art test laboratory with certified QA engineers. Using the Self-Serve approach, you can take advantage of our laboratory, with its accompanying tools, to bring your project to perfection. It includes a transparent workflow and the Bug Tracking System (BTS) built into the dashboard along with the Agile Board, and it has online tracking of all the error descriptions and failures in your app. Our engineers enter this data into the BTS. It’s an opportunity to not waste time and, if necessary, for your developers to work side-by-side with our team of testers.
Most importantly, the product owner receives all the risk descriptions and arguments at the project acceptance stage, which should and can be immediately eliminated by the developers. In the end, you are very likely to have an ideal application at your disposal, which naturally means more happy customers. I’m sure you’re on the right path!
My warm regards to all who are doing good things,