MVP is not a draft! Right?

What is MVP?

MVP (minimum viable product - minimum viable product) is a product that is developed with maximum savings of money and resources, as a rule, with the sole purpose of testing hypotheses. The hypothesis, as a rule, is the necessity and / or usefulness of this product.

MVP in no way means a “draft version”, made in a hurry, which after completion will be thrown away and written from scratch.

If you are convinced of the opposite, then you definitely should stop, reconsider the development priorities and read this article. It is necessary to reduce the functionality of the product, but in no case do not try to do everything at once, in an insane rush, losing important parts of the functionality and leaving behind a string of bugs. It is necessary to determine exactly which functionality is basic and which is not used in most cases.

In this article I will talk about our personal experience in creating MVP and at the end I will provide a list of useful tips that you can use in your development.

Personal experience of creating MVP

As a rule, if you create MVP, then you are limited in time and human resources. So, for example, we had to create a “minimal” project for about three months, one frontend developer and one backend developer at the start. Later, two more backend developers joined. But in any case, these are small human resources. Therefore, the first and main step is to define the main functionality, without which this application does not make sense, then the key action to be carried out.

At the start of the creation of the product, we had a description of the product with absolutely everyone. The product was developed for internal use in the company, so customers were part-time and future users. On the one hand, this simplified the task, because it was possible to carry out constant communication and collect feedback during the development process. But on the other hand, this hinders the process of simplifying the product, since There are many items “we would like to like this.” Therefore, it was necessary to balance at each stage ... According to statistics, only 12% of all existing application functionality are always used. In our situation, it was very convenient to prioritize parts of the hotelkeys with the usual question “how much is this necessary functionality?” And select only the most expected ones in the MVP list.

As for the technical side of the development, you need to immediately understand which elements should be discarded. The biggest and most common mistake of developers is that mpv is a “draft”. This is not true! In the future, with the successful testing of the hypothesis, it would be great to simply continue the development of the current product, rather than throwing all the money spent on developing the current version of the product into the wind. Therefore, you should not be skeptical, for example, to cover the MVP tests.

What we did not refuse:

• Coverage backend-parts;
• Front lint check and unit test usage;
• Tester, if resources allow;
• Documentation;
• Review code;
• Technical retro and refactoring;
• Design.

Refactoring

That which you definitely should not refuse. When creating a minimum product, it is very important that it is flexible, scalable and ready to develop in any direction. Therefore, if it becomes obvious that some part of the application is not flexible or potentially incapable of scaling, then it is worth stopping and correcting the situation, because in the future this may turn out to be deplorable.

Code Style and Lints

It would seem that this can be missed, but no. The emphasis on code style is more appropriate than ever where speed is important. Because at any stage of development it may be possible to connect additional resources in the form of people. The maximum speed for a new developer to enter the context is our main goal. This also includes the availability of documentation. The appearance of a new person in the team should speed up development, not slow down. It can slow down due to the large number of questions that it has about the code and the application as a whole. Therefore, as well as technical, and architectural moments should immediately be entered in the documentation.

Design

Extremely controversial point in the development was the need for design. In reality, it would be extremely foolish to expect design development before starting product development — sometimes it may take longer to develop a design than is allocated for the entire development. But at the same time it is worth remembering that it is very important to make a product that they want to use. It will be lucky if developers have an extremely rare ability to do “beautifully”, but in reality this is not always the case.

One of the important arguments, after which we nevertheless came to the conclusion that design is needed, is the acceleration of development. A design that appears, perhaps out of time, still significantly accelerates development and removes some of the workload from developers. Which, in turn, can devote more time directly to the development and architecture of the application. Well, if the resources allocated to MVP allow you to add to the design team. In our case, we did not have our own designer, but there was a person who was engaged in several projects, and devoted some of his time to ours. This kind of savings too. .

What we still refused

Processes

The processes are what we really donated. Building processes is always a costly action. Of course, we had elementary ones: setting tasks, sprints, focused on performing the integral part of the functional, attempts to evaluate tasks. But in reality, everything was getting out of control, since it was always necessary to be as flexible as possible: somewhere, the task could be simplified, and somewhere, it was necessary to modify the functionality that was missed or misinterpreted. Nevertheless, we have always set small benchmarks for ourselves in the form of the nearest deadlines with an understanding of what should be ready for this moment.

What else can speed up MVP development?

Already ready developments. At the stage of creating the MVP, you definitely should not develop your libraries and plugins. The maximum part of those should be taken from the outside and refer to Open Source. Perhaps some parts of the functionality have already been developed in other products of your company or earlier in your pleasure. This also applies to components. Well, if your company already has a single UI Kit that you can use. As a result: the acceleration of development and the unified style of the company's products out of the box. I described the experience of using a single UI Kit in the company in this article .

Direct communication of development and customers

Many developers do not like to communicate and communicate in life, not to communicate with customers. But communication really has great potential in speeding up development. In our experience, there was a lot of situation when customers implicitly imposed some kind of technical solution to which they had become accustomed or invented themselves. But, having found out the real goal, knowing about the goals of the product, the possibilities of the current application and the already implemented functionality, the developer can propose a solution that at the same time helps to solve the customer’s task and save the lion's share of time.

To be a team, not a recruitment of specialists

Increased level of communication in a team will help to quickly come to an optimal solution. For example, we constantly communicated directly to Frontend and Backend, sitting down at the negotiating table and deciding on which side one or another logic would be implemented, who would determine the format of contracts and what data would really be needed in the API. It is very important that each part of the development can respond quickly to requests from the other part, so as not to block the development as a whole.

Motivation of the team and developers personally

Creating MVP can sometimes be stressful and cause a lot of controversial moments in which hot and sometimes difficult disputes can arise. It is very important that in such situations someone acts as a catalyst and does not allow the team to lose motivation and team spirit. As a rule, it is the responsibility of the head of the current development, but it often happens that he simply has no time, or worse, simply doesn’t care. Do not underestimate how this affects the speed of development. A united and motivated team communicates better and will willingly linger in the evening before the deadline of their will and desire.

Clear responsibility sharing: both roles and design

With regards to the development, we had an agreement that exactly accelerated the process. Namely, all the necessary API and back requirements were expected from the front, and the requirements for the front came from joint communications with customers and technologist’s resumes. So if something was missing from the backend in the API, the responsibility for this lay on the frontend part, no matter how strange it might seem. But this was our internal agreement. With regard to contracts, there was an agreement that the final decision was always behind the back, and with front there was always a proposal and the necessary data. Such internal agreement on who is responsible for specific parts of the application and development, significantly speeds up the development process itself, and helps to avoid controversial issues.

When communication goes directly between development and customers, it is worth determining at the outset who leads the meetings and what plan everyone follows, who exactly assumes the role of analyst (if this is not available) and who offers the final solution. In our team, the roles were “spread out” throughout the team and there is nothing wrong with that, but a clearly not definitive final responsibility is really a problem. It can turn into “twice-salty soup, because of two cooks in the kitchen” and “a forgotten child in kindergarten”. The distribution of responsibility in the team again should be done by the head of the current development.

Synchronization of product understanding

At the beginning of product development, it is very important to build a plan for building an application architecture and collectively discuss this with the team - this is what we did before each complex part of the application. Description of the development architecture, a series of discussions, and we get a ready-made plan. The front, and back, and design, and even the analyst were guided by such documentation simultaneously. So we always had a common understanding of the application, and we did not waste time trying to adapt to each other. The simplest example: we had a difficult work with data and table view. Each key of this table could have its own presentation. Before doing the design, or the frontend part, or the logic on the back, or organizing the data in the database, it was very important to synchronize the understanding of all these parts into a single picture and come to an agreement on names and terms. With this, the general glossary also helped us. It would seem a trifle, but it really simplifies communication. As a consequence - the acceleration of development. It's great when the analyst and designer understand what a component is; front and back call the same data with the same name; Customers and development call the same part of the functionality with the same name.

We summarize:

• You should not abandon the control style code, test coverage, design and refactoring.
• Create a product with the fact that it will grow and scale. Always keep it in your head.
• It is possible and necessary to use ready-made developments, if any.
• Direct communication between the development and the customer can significantly speed up the development.
• Do not underestimate the importance of team spirit and team motivation.
• Clearly assign responsibility in roles and in development at the very start.
• Very important in “fast” development is the same understanding of the product and the synchronization of understanding.

MVP is not equal to “draft”!

I really liked the illustration that I attached at the beginning of the article. It is well displayed the essence of the development, where at each stage we have a workable and useful product. Further, it only improves and is supplemented with new functionality, and no functionality is developed, which in itself has no meaning and is not integral.

In this short article I shared our experience in creating the MVP and some tips that I highlighted for myself from the work done. At the moment, MVP has successfully passed the hypothesis confirmation stage, and its further development is expected without discarding the already developed part.

Thank you for reading my article to the end. Leave useful MVP tips from your personal experience in the comments and ask questions if you have any.