Тут такое дело: многие интуитивно представляют, что MVP (Minimal Viable Product) — это наименьшая жизнеспособная часть большого, финального продукта. Можно сделать MVP, а можно сделать всё. Есть известная картинка с двумя пирамидками про то, чем является и не является MVP. Она, честное слово, чудесная, но она тоже делает маленькое грязное дело — поддерживает иллюзию, что есть финальный продукт (100 %), а есть MVP — его урезанная версия, небольшой сектор, который помогает что-нибудь там проверить.
Это заблуждение охотно принимается мозгом, потому что ему привычнее иметь дела с конечным и обозримым.
Это фальшивая система координат. Если принять её, то действительно получается, что MVP — компромисс. Как выглядит запуск проекта в этой системе? Вы можете совсем не тратить ресурсы на разработку, но тогда не получите результат. Это одна крайность. А ещё вы можете потратить относительно много ресурсов и сделать полноценный продукт, но если гипотеза окажется ошибочной — то и потеряете много. Вот вторая крайность. Получается, что делая MVP, вы вынуждены потратить часть ресурсов в обмен на часть рисков и часть результата (но если всё будет хорошо, то на самую важную и показательную). Кажется, тут заложен компромисс. Пока не сделаешь всё целиком, разве можно надёжно проверить гипотезу?
Но это всё полная ерунда, потому что не бывает никакого «готового» или «полноценного» продукта, в противовес MVP. Это упрощение, появившееся ради психологического комфорта и чтобы треугольные диаграммки было проще рисовать. Завтра у вас может быть и новая гипотеза, и новые способы её проверки, а «готов» ваш продукт не будет никогда. Сергей Брин и Ларри Пейдж не сказали в 1997 году: «Ну ладно, мы придумали поисковик и запустили готовую версию, больше нам делать нечего».
Если в проекте вы испытываете некую гипотезу, то смешно думать, что поработав побольше, вы «проверите её точно». С чего бы это? Вы владеете такими безупречными способами проверки, серьёзно? А ничего, что и гипотезу, и нужную для её проверки работу вы выдумали сами, полагаясь на свои представления о мире и текущий гормональный фон? Мне кажется, лучше как можно быстрее выпустить проект в свет и видеть, как его проверяет сама жизнь, чем строить модели в собственном воображении и надеяться, что вы с ними не сильно промахнулись.
Закрепим. Обычно не существует никакого противопоставления между запуском MVP и подходом «разработать сразу всё» — потому что нельзя разработать всё. Так что весь вопрос в том, когда вы решите, что вашу рабочую гипотезу уже можно проверять. MVP — это не часть продукта, а сам продут в начале своего пути. Чем раньше он увидит свет, тем быстрее вы получите обратную связь и примете полезные решения. Против MVP выступает не воображаемый «финальный продукт», а бессмысленный идеализм.
Работу над продуктом я себе представляю не как пирамидку с картинки, а как параллельные беговые дорожки (Functional, Reliable, Usable… — все те же самые). Черта «MVP» может проходить в 10 метрах от старта. Черта «Это уже не стыдно показать» — в 20 метрах. Черта «Вот такой я представлял себе финальную версию, когда начинал» будет проходить в 50 метрах от старта, но пока вы бежите к ней, окажется, что она расположена в тупичке, а дорожка поворачивает в сторону и проходит мимо, потому что ваши предположения в начале были наивны. Передавайте привет тем, кто зажмурившись бежит к этой черте, понадеявшись на первоначальный план и боясь его проверять и улучшать :–)
P. S. На мысли про MVP мня натолкнул твит (https://twitter.com/antiflasher/status/722897463602843650), который написал Антон Ловчиков. Что на самом деле имел в виду Антон — я не знаю, поэтому это не совсем ответ, а мысли на тему. Спасибо за повод, Антон!
Это заблуждение охотно принимается мозгом, потому что ему привычнее иметь дела с конечным и обозримым.
Это фальшивая система координат. Если принять её, то действительно получается, что MVP — компромисс. Как выглядит запуск проекта в этой системе? Вы можете совсем не тратить ресурсы на разработку, но тогда не получите результат. Это одна крайность. А ещё вы можете потратить относительно много ресурсов и сделать полноценный продукт, но если гипотеза окажется ошибочной — то и потеряете много. Вот вторая крайность. Получается, что делая MVP, вы вынуждены потратить часть ресурсов в обмен на часть рисков и часть результата (но если всё будет хорошо, то на самую важную и показательную). Кажется, тут заложен компромисс. Пока не сделаешь всё целиком, разве можно надёжно проверить гипотезу?
Но это всё полная ерунда, потому что не бывает никакого «готового» или «полноценного» продукта, в противовес MVP. Это упрощение, появившееся ради психологического комфорта и чтобы треугольные диаграммки было проще рисовать. Завтра у вас может быть и новая гипотеза, и новые способы её проверки, а «готов» ваш продукт не будет никогда. Сергей Брин и Ларри Пейдж не сказали в 1997 году: «Ну ладно, мы придумали поисковик и запустили готовую версию, больше нам делать нечего».
Если в проекте вы испытываете некую гипотезу, то смешно думать, что поработав побольше, вы «проверите её точно». С чего бы это? Вы владеете такими безупречными способами проверки, серьёзно? А ничего, что и гипотезу, и нужную для её проверки работу вы выдумали сами, полагаясь на свои представления о мире и текущий гормональный фон? Мне кажется, лучше как можно быстрее выпустить проект в свет и видеть, как его проверяет сама жизнь, чем строить модели в собственном воображении и надеяться, что вы с ними не сильно промахнулись.
Закрепим. Обычно не существует никакого противопоставления между запуском MVP и подходом «разработать сразу всё» — потому что нельзя разработать всё. Так что весь вопрос в том, когда вы решите, что вашу рабочую гипотезу уже можно проверять. MVP — это не часть продукта, а сам продут в начале своего пути. Чем раньше он увидит свет, тем быстрее вы получите обратную связь и примете полезные решения. Против MVP выступает не воображаемый «финальный продукт», а бессмысленный идеализм.
Работу над продуктом я себе представляю не как пирамидку с картинки, а как параллельные беговые дорожки (Functional, Reliable, Usable… — все те же самые). Черта «MVP» может проходить в 10 метрах от старта. Черта «Это уже не стыдно показать» — в 20 метрах. Черта «Вот такой я представлял себе финальную версию, когда начинал» будет проходить в 50 метрах от старта, но пока вы бежите к ней, окажется, что она расположена в тупичке, а дорожка поворачивает в сторону и проходит мимо, потому что ваши предположения в начале были наивны. Передавайте привет тем, кто зажмурившись бежит к этой черте, понадеявшись на первоначальный план и боясь его проверять и улучшать :–)
P. S. На мысли про MVP мня натолкнул твит (https://twitter.com/antiflasher/status/722897463602843650), который написал Антон Ловчиков. Что на самом деле имел в виду Антон — я не знаю, поэтому это не совсем ответ, а мысли на тему. Спасибо за повод, Антон!
Here's the thing: many intuitively imagine that MVP (Minimal Viable Product) is the smallest viable part of a large, final product. You can do MVP, but you can do everything. There is a famous picture with two pyramids about what MVP is and is not. She, honestly, is wonderful, but she also does a little dirty work - it supports the illusion that there is a final product (100%), and there is MVP - its stripped-down version, a small sector that helps to check something there.
This error is readily accepted by the brain, because it is more familiar to him to deal with the finite and the foreseeable.
This is a fake coordinate system. If you accept it, then it really turns out that MVP is a compromise. What does the project launch look like on this system? You may not spend resources on development at all, but then you will not get the result. This is one extreme. You can also spend relatively many resources and make a full-fledged product, but if the hypothesis turns out to be erroneous, then you will lose a lot. Here is the second extreme. It turns out that doing MVP, you are forced to spend part of the resources in exchange for part of the risks and part of the result (but if everything goes well, then for the most important and significant). There seems to be a compromise. Until you do the whole thing, how can you reliably test the hypothesis?
But this is all complete nonsense, because there is no “ready-made" or "full-fledged" product, as opposed to MVP. This is a simplification that appeared for the sake of psychological comfort and to make triangular diagrams easier to draw. Tomorrow you may have a new hypothesis and new ways to test it, and your product will never be “ready”. Sergey Brin and Larry Page did not say in 1997: “Well then, we came up with a search engine and launched a ready-made version, we have nothing more to do.”
If you are experiencing a certain hypothesis in a project, then it’s ridiculous to think that having worked more, you “check it for sure”. Why's that? Do you have such flawless verification methods, really? But did you come up with the hypothesis and the work necessary to verify it yourself, relying on your ideas about the world and the current hormonal background? It seems to me that it is better to release the project as soon as possible and see how life itself checks it, than to build models in your own imagination and hope that you have not missed a lot with them.
Fasten. Usually, there is no opposition between launching MVP and the “develop everything at once” approach - because you cannot develop everything. So the whole question is when you decide that your working hypothesis can already be verified. MVP is not part of the product, but the product itself at the beginning of its journey. The sooner he sees the light, the faster you will receive feedback and make useful decisions. MVP is opposed not by an imaginary “final product”, but by senseless idealism.
I imagine the work on the product not as a pyramid from the picture, but as parallel treadmills (Functional, Reliable, Usable ... - all the same). The MVP line can be 10 meters from the start. The line “It is no longer a shame to show” is 20 meters away. The line “This is how I imagined the final version when I started” will take place 50 meters from the start, but while you run to it, it turns out that it is located in a dead end, and the track turns to the side and passes by, because your assumptions are at the beginning were naive. Say hello to those who squint run to this line, relying on the original plan and being afraid to check and improve it :–)
P. S. I was prompted by the tweet (https://twitter.com/antiflasher/status/722897463602843650), written by Anton Lovchikov, about MVP. What Anton really meant - I do not know, so this is not quite the answer, but thoughts on the topic. Thanks for the reason, Anton!
This error is readily accepted by the brain, because it is more familiar to him to deal with the finite and the foreseeable.
This is a fake coordinate system. If you accept it, then it really turns out that MVP is a compromise. What does the project launch look like on this system? You may not spend resources on development at all, but then you will not get the result. This is one extreme. You can also spend relatively many resources and make a full-fledged product, but if the hypothesis turns out to be erroneous, then you will lose a lot. Here is the second extreme. It turns out that doing MVP, you are forced to spend part of the resources in exchange for part of the risks and part of the result (but if everything goes well, then for the most important and significant). There seems to be a compromise. Until you do the whole thing, how can you reliably test the hypothesis?
But this is all complete nonsense, because there is no “ready-made" or "full-fledged" product, as opposed to MVP. This is a simplification that appeared for the sake of psychological comfort and to make triangular diagrams easier to draw. Tomorrow you may have a new hypothesis and new ways to test it, and your product will never be “ready”. Sergey Brin and Larry Page did not say in 1997: “Well then, we came up with a search engine and launched a ready-made version, we have nothing more to do.”
If you are experiencing a certain hypothesis in a project, then it’s ridiculous to think that having worked more, you “check it for sure”. Why's that? Do you have such flawless verification methods, really? But did you come up with the hypothesis and the work necessary to verify it yourself, relying on your ideas about the world and the current hormonal background? It seems to me that it is better to release the project as soon as possible and see how life itself checks it, than to build models in your own imagination and hope that you have not missed a lot with them.
Fasten. Usually, there is no opposition between launching MVP and the “develop everything at once” approach - because you cannot develop everything. So the whole question is when you decide that your working hypothesis can already be verified. MVP is not part of the product, but the product itself at the beginning of its journey. The sooner he sees the light, the faster you will receive feedback and make useful decisions. MVP is opposed not by an imaginary “final product”, but by senseless idealism.
I imagine the work on the product not as a pyramid from the picture, but as parallel treadmills (Functional, Reliable, Usable ... - all the same). The MVP line can be 10 meters from the start. The line “It is no longer a shame to show” is 20 meters away. The line “This is how I imagined the final version when I started” will take place 50 meters from the start, but while you run to it, it turns out that it is located in a dead end, and the track turns to the side and passes by, because your assumptions are at the beginning were naive. Say hello to those who squint run to this line, relying on the original plan and being afraid to check and improve it :–)
P. S. I was prompted by the tweet (https://twitter.com/antiflasher/status/722897463602843650), written by Anton Lovchikov, about MVP. What Anton really meant - I do not know, so this is not quite the answer, but thoughts on the topic. Thanks for the reason, Anton!
У записи 3 лайков,
0 репостов.
0 репостов.
Эту запись оставил(а) на своей стене Никита Иванов
