MVP for 7 weeks. How it was
When I gathered the guys and said that we need to have time to make the MVP (minimum viable product) of the new service by May 31, they looked at each other and said: "This is impossible." And now, after almost 7 weeks of development, each of us can proudly say: "We did it!"
This article is a continuation of the material “ How not to make a“ poop ”? Personal experience in creating a product ”, where I described the stages of research and design of a product. Now I would like to share my personal experience and tell us how we managed to realize the project, which was very heavy at first glance, in time, which we had to sacrifice and show you what we ended up with.
There are a lot of “gray” ordinary things around us. Take a look! Furniture, clothes, cars, appliances and even your pen. What do you really like about it? What fascinates you? What attracts attention? I really like beautiful, well-made and thoughtful things. This could be a Bosh mixer, a SKODA Octavia trunk, or a picture of The Tower of Babel (Peter Bruegel the Elder, 1563g). Well, not the beauty?
')
And then, when you create a new product from scratch, your imagination beats you with a key like an artist, you are taken and placed in the framework of MVP. MVP translates as “minimally viable product” and implies some simple prototype that will allow you to test the viability of an idea in practice. About the ideality of speech is not. Is it possible? It turns out - you can. These are the very few tricks that allowed us to find a compromise between deadlines, MVP and our ideas about the ideal.
1. We "hammered" on infrastructure . It often happens when a new project starts with a new office, and not with a working prototype. Therefore, for the entire project, we did only the minimum set of infrastructure tasks that was “blood-from-nose” necessary. For example, until recently we didn’t even have a server for a project, it appeared only at the 5th iteration. Prior to this, the whole project was done by the guys on the locale. A test store for our service, where we first launched the solution “outside”, we did on a free platform in 5 minutes, although at first we thought about the option of fully deploying one of the CMS on our server.
As a result, a whole bunch of tasks “for later” have accumulated, and such that we even had to classify them. They are morally under pressure to this day, but the guys managed to find a balance between the development of the “facade” and the “framework” of our product. Here is a small part of them:
2. Think more, do less. The first thought that occurred to me at the very beginning of the project: “Guys! What are we sitting, let's code, otherwise we will not have time! ”But practice shows that the fewer lines of code will be written, the better. We really spent a lot of time on research and technology selection, on communication within the team. Such costs more than paid off in subsequent productivity and time savings. And in order to increase the efficiency of communication, at the first 3 iterations I had to move to our Bryansk development office and come to Demo and Sprint Planing every Friday for subsequent iterations.
3. First, we switched to weekly iterations . It was immediately clear that we would have to greatly change our existing approach to development, since the release of a new product and the support / development of the old were fundamentally different. When there is great uncertainty, the results need to be obtained as quickly as possible. Made? Show me In addition, weekly iterations are easier to plan, especially if the tasks are highly interconnected.
4. "Nafig" - has become our favorite phrase. From the system, we threw almost everything except the key chips of our product. They left only those opportunities that would allow testing hypotheses or without which the product could not be used in principle. But what was left is done well! A simple example. Our service has the functionality of sending follow-up letters to customers a few days after the purchase of goods. Here is how we reasoned and cut off the possibilities:
5. The simpler the better. Remaining after pruning opportunities, we tried to implement as simply and efficiently as possible. For example, we have simplified the ability to customize the appearance of the reviews widget to just one parameter - the color of the button and elements. And the first implementations at our clients have shown that this is enough!
We also tried not to do secondary. If some functionality does not lead us directly to the goal of making the MVP by May 31, then we simply did not do it. For example, we implemented the ability to recover the password only in iteration 6, when it became clear that we can afford it. If we did not have time, we would leave it as it is. If there were doubts about the usefulness or expediency of the implementation of something - my answer immediately "Nafig."
Our MVP is somewhat different from the initial one we planned to do at the stage of cutting layouts at UserStory. The red line in the photo below shows the US, which we planned to do, and the blue one - what happened in the end. In live poke stick our MVP can be on this test stand .
The team consisted of 3 professional developers + 1 Product Owner. During the project, one of the developers went on vacation for 1 week. There is no dedicated designer, like the layout designer, in the team. To speed up the development used purchased layout. At night and on weekends they did not work, but during working hours they worked hard.
The whole team received a lot of emotions and excellent experience in developing MVP of a new product. We have learned a lot and there is still much to do. I hope our experience will be useful to you and if you have questions, I will be glad to answer in the comments.
This article is a continuation of the material “ How not to make a“ poop ”? Personal experience in creating a product ”, where I described the stages of research and design of a product. Now I would like to share my personal experience and tell us how we managed to realize the project, which was very heavy at first glance, in time, which we had to sacrifice and show you what we ended up with.
Some lyrics about quality and MVP
There are a lot of “gray” ordinary things around us. Take a look! Furniture, clothes, cars, appliances and even your pen. What do you really like about it? What fascinates you? What attracts attention? I really like beautiful, well-made and thoughtful things. This could be a Bosh mixer, a SKODA Octavia trunk, or a picture of The Tower of Babel (Peter Bruegel the Elder, 1563g). Well, not the beauty?
')
And then, when you create a new product from scratch, your imagination beats you with a key like an artist, you are taken and placed in the framework of MVP. MVP translates as “minimally viable product” and implies some simple prototype that will allow you to test the viability of an idea in practice. About the ideality of speech is not. Is it possible? It turns out - you can. These are the very few tricks that allowed us to find a compromise between deadlines, MVP and our ideas about the ideal.
What have we done?
1. We "hammered" on infrastructure . It often happens when a new project starts with a new office, and not with a working prototype. Therefore, for the entire project, we did only the minimum set of infrastructure tasks that was “blood-from-nose” necessary. For example, until recently we didn’t even have a server for a project, it appeared only at the 5th iteration. Prior to this, the whole project was done by the guys on the locale. A test store for our service, where we first launched the solution “outside”, we did on a free platform in 5 minutes, although at first we thought about the option of fully deploying one of the CMS on our server.
As a result, a whole bunch of tasks “for later” have accumulated, and such that we even had to classify them. They are morally under pressure to this day, but the guys managed to find a balance between the development of the “facade” and the “framework” of our product. Here is a small part of them:
2. Think more, do less. The first thought that occurred to me at the very beginning of the project: “Guys! What are we sitting, let's code, otherwise we will not have time! ”But practice shows that the fewer lines of code will be written, the better. We really spent a lot of time on research and technology selection, on communication within the team. Such costs more than paid off in subsequent productivity and time savings. And in order to increase the efficiency of communication, at the first 3 iterations I had to move to our Bryansk development office and come to Demo and Sprint Planing every Friday for subsequent iterations.
3. First, we switched to weekly iterations . It was immediately clear that we would have to greatly change our existing approach to development, since the release of a new product and the support / development of the old were fundamentally different. When there is great uncertainty, the results need to be obtained as quickly as possible. Made? Show me In addition, weekly iterations are easier to plan, especially if the tasks are highly interconnected.
4. "Nafig" - has become our favorite phrase. From the system, we threw almost everything except the key chips of our product. They left only those opportunities that would allow testing hypotheses or without which the product could not be used in principle. But what was left is done well! A simple example. Our service has the functionality of sending follow-up letters to customers a few days after the purchase of goods. Here is how we reasoned and cut off the possibilities:
The ability to change the subject and text of the letteris nafig, since the default option is good enough and units will actually change something.The ability to specify the name and email of the senderis nafig, since not many buyers will pay attention to the email of the sender and even fewer customers of the service will set up this email.The possibility of complete customization of the letter templateis nafig, since the experience of the current project showed that less than 1% of clients are engaged in this. Moreover, our template is professionally designed and adapted for different devices and email clients.- The possibility of branding (easy) - left to shop shoppers are not afraid.
- The ability to set the period for sending letters is left, as stores from different product categories should send email with different delays.
5. The simpler the better. Remaining after pruning opportunities, we tried to implement as simply and efficiently as possible. For example, we have simplified the ability to customize the appearance of the reviews widget to just one parameter - the color of the button and elements. And the first implementations at our clients have shown that this is enough!
We also tried not to do secondary. If some functionality does not lead us directly to the goal of making the MVP by May 31, then we simply did not do it. For example, we implemented the ability to recover the password only in iteration 6, when it became clear that we can afford it. If we did not have time, we would leave it as it is. If there were doubts about the usefulness or expediency of the implementation of something - my answer immediately "Nafig."
Results
Our MVP is somewhat different from the initial one we planned to do at the stage of cutting layouts at UserStory. The red line in the photo below shows the US, which we planned to do, and the blue one - what happened in the end. In live poke stick our MVP can be on this test stand .
The team consisted of 3 professional developers + 1 Product Owner. During the project, one of the developers went on vacation for 1 week. There is no dedicated designer, like the layout designer, in the team. To speed up the development used purchased layout. At night and on weekends they did not work, but during working hours they worked hard.
The whole team received a lot of emotions and excellent experience in developing MVP of a new product. We have learned a lot and there is still much to do. I hope our experience will be useful to you and if you have questions, I will be glad to answer in the comments.
Source: https://habr.com/ru/post/224291/
All Articles