Автор оригинала: Chris.
Эта глава из моей предстоящей книги «От одного до нуля» (Появиться с ностархом 2021) учит вас известной но все еще недооцененной идеей. Идея состоит в том, чтобы создать минимальный жизнеспособный продукт (в короткие сроки: MVP), чтобы проверить и подтвердить свои гипотезы, не потеряв много времени в реализации. В частности, вы узнаете, как применить идею радикальной снижения сложности в цикле разработки программного обеспечения при создании значения через программное обеспечение.
Стелс-режим программирования
Если вы похожи на меня, вы знаете, что можно назвать «режимом стелса» программирования (см. Рисунок 4-1). Многие программисты падают жертвам к нему, и это происходит следующим образом: вы придумаете замечательное представление о компьютерной программе, которая изменит мир – с возможностью стать следующим Google. Скажем, вы обнаружили, что все больше и больше людей начинают кодировать, и вы хотите служить тем, что создавая поисковую систему, улучшенную машиной, улучшенную машиной для обнаружения кода. Звучит здорово? Вы так думаете – и вы начинаете с энтузиазмом кодировать на своей идее несколько ночей подряд.
Рисунок 4-1: Стелс-режим программирования.
Но эта стратегия работает? Вот вероятный результат следующего режима программирования скрытности:
Вы быстро разрабатываете прототип, но он не выглядит правильно. Итак, вы погрузитесь в дизайн и оптимизируете дизайн. Затем вы попробуйте поисковую систему, и результаты рекомендаций не имеют отношения к многим условиям поиска. Например, при поиске «Quicksort» вы получаете фрагмент кода Mergesort “с комментарием "# Это быстро сортирует список" Отказ Итак, вы продолжаете настраивать модели. Но каждый раз, когда вы улучшаете результаты для одного ключевого слова, вы создаете новые проблемы для других результатов поиска. Вы никогда не всегда довольны результатом, и вы не чувствуете, что вы можете представить свою дерьмовую поисковую систему кода в мир по трем причинам. Во-первых, никто не найдет это полезным. Во-вторых, первые пользователи создадут негативную рекламу вокруг вашего сайта, потому что оно не чувствует себя профессиональным и полированным. И в-третьих, если конкуренты видят вашу плохо реализуемую концепцию, они будут украсть его и реализовать его лучше. Эти удручающие мысли заставляют вас потерять веру и мотивацию, и ваш прогресс в приложении значительно падает.
Давайте проанализируем, что может и пойдет не так во внутреннем режиме программирования, показанного на рисунке 4-2.
Рисунок 4-2: Общие подводные камни в стелс-режиме программирования
Ловушки
Существует много распространенных ловушек в стелс-режиме программирования. Вот четыре из более распространенных:
- Потеря мотивации : Пока вы в стелс-режиме, никто не может видеть вас. Никто не знает о отличном инструменте, который вы реализуете. Вы один с вашей идеей, и сомнения будут регулярно всплывать. Может быть, вы достаточно сильны, чтобы изначально противостоять сомнениям, в то время как ваш первоначальный энтузиазм для проекта достаточно большой. Но чем дольше вы будете работать над своим проектом, тем больше сомнений придут больше сомнений. Ваша подсознание лениво и ищет причины не делать работу. Вы можете найти аналогичный инструмент. Или вы можете даже сомневаться в том, что ваш инструмент будет полезен в первую очередь. Вы можете начать верить, что это не может быть сделано. Если бы только один ранний усыновленный ваш инструмент предоставил вам некоторые обнадеживающие слова, вы, вероятно, остались мотивированы. Но, как вы в стелс-режиме, никто не собирается побудить вас продолжать работать. И да, никто не платит за вашу работу. Вы должны воровать время от своих друзей, своих детей, вашей жены. Только меньшинство людей будут поддерживать такой психологический источник. Большинство просто проиграют мотивацию – чем дольше стелс, тем меньше мотивация для работы над проектом.
- Отвлечься: Даже если вам удастся оставаться мотивированным на работу над проектом в течение длительного периода без каких-либо реальных отзывов – есть еще один мощный враг: ваши ежедневные отвлекающие факторы. Вы не живете в вакууме. Вы работаете на своей дневной работе, вы проводите время с семьей и друзьями, а другие идеи будут выходить на ваш разум. Сегодня ваше внимание является редким грузом, ищенным многими устройствами и услугами. Пока вы работаете над одним проектом, у вас будут идеи для других проектов, а эффект Grass-Greener наткнутся: многие другие проекты кажутся намного более привлекательными! Требуется очень дисциплинированный человек, чтобы управлять этими отвлекающими факторами, защищать свое рабочее время и оставаться сосредоточенным на одном проекте, пока они не достигли завершения.
- Занимает дольше: Другой мощный враг неверное планирование. Скажите, что вы изначально планируете, что проект занимает один месяц, если вы работаете над ним на два часа каждый день. Это 60 часов по оценкам рабочего времени. Потерянная мотивация и отвлекающие факторы, вероятно, приведут вам в среднем только один час каждый день, поэтому он уже удваивает продолжительность проекта. Однако другие факторы несут ответственность за недооценку продолжительности проекта: неожиданные события и ошибки занимают гораздо больше времени, чем ожидалось. Вы должны узнать новые вещи, чтобы закончить проект – и обучение требует времени. Особенно, когда вы смешиваете время обучения, отвечая на сообщения смартфона и уведомления, электронные письма и телефонные звонки. Трудно оценить, сколько времени обучения вам нужно правильно. И даже если вы уже знаете все, что вам нужно знать, чтобы закончить проект, вы, вероятно, столкнулись с непредвиденными проблемами или ошибками в вашем коде. Или другие функции могут появиться в ваш разум, который требует реализована. Бесконечное количество факторов увеличит вашу ожидаемую продолжительность проекта, и едва ли это уменьшит. Но становится хуже: если ваш проект занимает больше, чем ожидается, вы потеряете еще больше мотивации, и вы столкнетесь с еще более отвлекающими факторами, вызывающими отрицательную спираль к провалу проекта.
- Доставка слишком мало значения: Скажите, что вам удается преодолеть фазы низкой мотивации. Вы узнаете, что вам нужно, оставаться сосредоточенным и избегать любого отвлечения до тех пор, пока его нужно, чтобы закончить код. Вы, наконец, запускаете свой проект, и ничего не происходит. Только горстка пользователей даже проверяет ваш проект, и они не энтузиасты об этом. Наиболее вероятным результатом любого программного обеспечения является молчание – отсутствие положительной или отрицательной обратной связи. Вы будете задуматься, почему никто не писал с некоторыми конструктивными или даже разрушительными отзывами. Никто не заботится. Есть много причин для этого. Общая причина состоит в том, что ваш продукт не доставляет конкретную ценность, которые требуют пользователей. Почти невозможно найти так называемый рынок продукта – подходит в первый выстрел. Ну, даже если вы нашли бы товар-рынок, и пользователи, как правило, ценят ваше программное обеспечение, у вас еще нет маркетинговой машины для его продажи. Если 5% ваших посетителей купит продукт, вы можете считать его огромным успехом. Тем не менее, скорость преобразования 5% означает, что 19 человек из 20 человек не будут покупать продукт! Вы ожидали, что запуск миллиона долларов? Вряд ли так; Ваше программное обеспечение продается одному человеку в первые 20 дней, ведущих к конечным доходам 97 долларов. И вы потратили сотни часов, реализующих его. Отключается результатами, вы быстро отказываетесь от идеи создания собственного программного обеспечения и продолжаете работать на свой босс.
Вероятность провала высока в режиме укрытия программирования. У нас есть негативная цикла обратной связи: если вы спотыкаетесь из-за каких-либо обсуждаемых причин, проект кода принесет больше дольше, и вы потеряете еще больше мотивации, что увеличивает ваши шансы на камнем. Не стоит недооценивать силу этой негативной петли обратной связи. Каждый программист знает это очень хорошо, и поэтому многие кодовые проекты никогда не видят света дня. Так много времени, усилий, ценность теряется из-за этого. Индивидуальные и даже команды программистов могут проводить годы своих жизней, работающих в стелс-режиме программирования, только чтобы потерпеть неудачу или узнать, что никто не хочет своего программного продукта.
Искажение реальности
Вы бы подумали, что если программисты тратит так много времени, работая над программным проектом, они, по крайней мере, знают, что их пользователи найдут конечный продукт ценным. Но это не так. Когда они потоплены в стелс-режиме программирования, программисты не получают отзывов от реального мира – опасная ситуация. Они начинают отходить от реальности, работая над функциями, которые никто не просил, или никто не будет использовать.
Вы можете спросить: как это может случиться? Причина проста: ваши предположения делают это так. Если вы работаете над любым проектом, у вас есть куча допущений, таких как кто пользователи будут, что они зарабатывают на жизнь, какие проблемы они сталкиваются, или как часто они будут использовать ваш продукт. Несколько лет назад, когда я создал свое приложение Finxter.com, чтобы помочь пользователям изучить Python, решение номинальных головоломок, я предположил, что большинство пользователей являются учащиеся компьютерных наук, потому что я был один (реальность: большинство пользователей не являются компьютерными учеными). Я предположил, что люди придут, когда я выпустил приложение (реальность: никто не пришел изначально). Я предположил, что люди будут делиться своими успехами на Finxter через свои учетные записи в социальных сетях (реальность: только крошечное меньшинство людей поделились своими рядами кодирования). Я предположил, что люди представит свои собственные головоломки кода (реальность: от сотен тысяч пользователей, только несколько представленные головоломки кода). Я предположил, что люди хотели, чтобы люди хотели модный дизайн с цветами и изображениями (реальностью: простой продуманный дизайн приводит к улучшению поведения использования). Все эти предположения приводят к решению конкретных решений. Реализация каждой особенности – даже те, которые никто не хотел, было стоить мне десятки, иногда сотни часов. Если я знал лучше, я мог бы проверить эти предположения, прежде чем тратить много времени, работающих над ними. Я мог бы попросить обратные связи и приоритеты, реализующие функции, оцениваемые высоко занятыми пользователями. Вместо этого я провел один год в стелс-режиме для разработки прототипа со слишком многими функциями, чтобы проверить некоторые из этих гипотез или предположений.
Сложность – производительность убийца
Есть еще одна проблема состелковым режимом программирования: ненужная сложность. Скажите, что вы реализуете программный продукт, состоящий из четырех функций (см. Рисунок 4-3). Вам повезло – рынок принял его. Вы провели значительное время, реализующие эти четыре особенности, и вы принимаете положительный отзыв в качестве арматуры для всех четырех функций. Все будущие выпуски программного обеспечения будет содержать эти четыре особенности, в дополнение к будущим функциям, которые вы добавите в программный продукт.
Рисунок 4-3: Ценный программный продукт, состоящий из четырех функций
Однако, выпуская пакет из четырех функций сразу, вы не знаете, принял ли рынок, примет любое подмножество функций (см. Рисунок 4-4).
Рисунок 4-4: Какие подмножества функций были бы приняты рынком?
Функция 1 может быть совершенно неактуальна – даже если вам потребовалось больше всего времени для реализации. В то же время особенность 4 может быть очень ценной особенностью, которую требования рынка. Существует 2N различные комбинации пакетов программного продукта из N функций. Как вы можете знать, что является ценностью, и которое является отходом, если вы отпустите их как функции пучков?
Затраты на реализацию неправильных функций уже высоки. Тем не менее, выделение пучков объектов приводит к совокупным затратам на поддержание ненужных функций для всех будущих версий продукта. Почему? Есть много причин:
- Каждая строка кода замедляется ваше понимание полного проекта. Вам нужно больше времени, чтобы «загрузить» весь проект в вашем уме, Чем больше функций вы реализуете.
- Каждая функция может представить новую ошибку в вашем проекте. Подумайте об этом таким образом: данная функция разбила все вашу кодовую базу с определенной вероятностью.
- Каждая строка кода заставляет проект открывать, загружать и компилировать медленнее. Это маленькая, но определенная стоимость, которая поставляется с каждой новой линией кода.
- При реализации функции N вы должны перейти на все предыдущие функции 1, 2, …, N-1 и убедитесь, что функция n не вмешивается в их функциональность.
- Каждая новая функция приводит к появлению новых (единичных) тестов, которые должны компилировать и запустить, прежде чем вы сможете выпустить следующую версию кода.
- Каждая дополнительная функция делает его более сложной для нового кодера, чтобы понять кодовую базу, что увеличивает время обучения новым кодерам, которые присоединяются к растущему проекту.
Это не исчерпывающий список, но вы получаете точку зрения. Если каждая особенность повышает ваши будущие затраты на реализацию X процентами, поддержание ненужных функций может привести к порядкам разницы величин в кодировке производительности. Вы не можете позволить себе систематически сохранять ненужные функции в ваших кодовых проектах!
Итак, вы можете спросить: Как вы преодолеете все эти проблемы? Если стелс-режим программирования вряд ли будет преуспеть, то что такое?
Минимальный жизнеспособный продукт – выпуск рано и часто
Решение простое – довольно буквально. Подумайте о том, как вы можете упростить программное обеспечение, как вы можете избавиться от всех функций, кроме одного, и как вы можете построить минимальный жизнеспособный продукт, который достигнет такую же проверку ваших гипотез, что и «полная» реализация ваших идей. Только если вы знаете, какие функции принимают рынок – и какие гипотезы верны – должны ли вы добавить больше функций и более сложность. Но на всех стоит избегать сложности. Сформулируйте явную гипотезу, такую как пользователи, пользующиеся решающимися головоломками Python – и создайте продукт, который подтверждает только эту гипотезу. Удалите все функции, которые не помогут вам подтвердить эту гипотезу. В конце концов, если пользователи не любят решать головоломки Python, почему даже продолжайте реализовывать сайт Finxter.com? Что было бы минимально жизнеспособным продуктом для Finxter? Ну, я подумал об этом, и я бы сказал, что это была бы простая учетная запись Instagram, которая разделяет коду головоломки и проверяет, наслаждается ли их сообщество Python. Вместо того, чтобы проводить один год, написание приложения Finxter без проверки, я должен был потратить несколько недель или даже несколько месяцев, разделяющих головоломки в социальной сети. Затем я должен был взять учащихся от взаимодействия с сообществом и построить второй MVP (первый, который является счет в социальных сетях) с чуть более функциональностью. Постепенно я построил приложение Finxter в доли времени и с долей ненужных функций, которые я реализовал и снова удалил в болезненном процессе выяснения, какие особенности ценны и которые являются отходами. Урок построения минимального жизнеспособного продукта, отделенного от всех ненужных особенностей, является то, что я изучил трудный путь.
Рисунок 4-5 набросает этот золотой стандарт разработки программного обеспечения и создания продукта. Во-первых, вы найдете товар-рынок – соответствует итеративно запущению минимальных жизнеспособных продуктов, пока пользователи не будут этого не любить. Законные запуска MVPS со временем встроят интерес и позволяют включить отзывы пользователя для постепенного улучшения основной идеи вашего программного обеспечения. Как только вы достигли подгонки на рынке продукта, вы добавляете новые функции – один за раз. Только если функция может доказать, что улучшает ключевые пользовательские метрики, оно остается в продукте.
Рисунок 4-5: Две фазы разработки программного обеспечения: (1) Найти товар-рынок – соответствует итеративному созданию MVP и наращивание процентов со временем. (2) Масштабирование путем добавления и проверки новых функций через тщательно разработанные разделенные тесты.
Термин минимальный жизнеспособный продукт (MVP) был придуман Фрэнк Робинсон в 2001 году. Eric Ries популяризировал термин в его самую продаваемую книгу. С тех пор концепция была проверена тысячами очень успешных компаний в области программного обеспечения (и за ее пределами). Известным примером является Dropbox Company в миллиард долларов. Вместо того, чтобы тратить много времени и усилий на непроверенную идею для реализации сложной функциональности DropBox синхронизации структур папок в облако – это требует плотной интеграции в разных операционных системах и тщательную реализацию концепций распределенных систем перекрестных систем, таких как синхронизация реплики – Учредители проверили идею простым видео продуктом, даже если продукт, о котором они сделали видео, даже не существовало в то время. Бесчисленные итерации, следящие на вершине подтвержденного MVP Dropbox, чтобы добавить более полезные функции в основной проект, который упрощает жизнь своих пользователей.
Концепция MVP.
Давайте быть более глубоким взглядом на концепцию MVP Далее, пожалуйста?
Минимальный жизнеспособный продукт в программном смысле является код, который разделяется из всех функций, чтобы сосредоточиться на основной функциональности. Для Finxter это было бы аккаунт в социальных сетях, сосредоточенные вокруг кода головоломки. После этого проверки прошло успешно, следующий MVP был бы простым приложением, которое ничего не делает, кроме настоящего кода головоломки. Вы будете последовательно добавлять новые функции, такие как методы выбора видео и выбора головоломки, расширение функциональности MVP на основе пользовательских нуждений и отзывов к ранним усынарителям. Для Dropbox первый MVP был видео-и после успешной проверки, второй MVP был создан зданием на понимание клиента с первого MVP (например, папка хранения облака для Windows, но не более). Для нашего примера поисковой системы кода MVP может стать совместно используемым видеоизображением через платные рекламные каналы. Я знаю, что вы хотите начать кодировать сразу в поисковой системе – но не делайте этого, пока у вас нет четкой концепции, которая дифференцируется из других поисковых систем кода, и у вас есть четкий план о том, как сосредоточиться. Работая над вашей концепцией MVP, прежде чем погрузиться в код, вы не только спасете много времени, но вы остаетесь достаточно ловким, чтобы найти товар-рынок. Даже минимальная форма вашего программного обеспечения уже будет удовлетворить потребности и желания вашего рынка, если вы найдете товар-рынок. Рынок сигнализирует о том, что они любят и ценят ваш продукт, и люди говорят друг другу о вашем программном продукте. Да, вы можете достичь продукта-рынка, поставившись с простым, хорошо продуманным MVP-и по итеративному строительству и переработке вашего MVPS. Термин для описания этой стратегии поиска правильного продукта через серию MVPS называется быстрым прототипом. Вместо того, чтобы проводить один год, чтобы подготовить свой большой одноразовый запуск, вы запускаете 12 прототипов за 12 месяцев. Каждый прототип основан на участиях от предыдущих запуска, и каждый предназначен для того, чтобы принести вам максимальное обучение в минимальное время и с минимальными усилиями. Вы выпускаете рано и часто!
Продукт-рынок
Одной из представлений создания ваших MVPS, чтобы найти товар-рынок, основана на теории о том, что ранние усыновления вашего продукта более прощают, чем общий рынок. Те люди любят новые и незаконченные продукты, потому что это заставляет их чувствовать себя особенными – они являются частью новой и развивающейся технологии. Они ценят продукцию более на основе их потенциала, чем фактическая реализация. В конце концов, они идентифицируют, будучи ранним усыновлением, поэтому они должны принимать полубунутые продукты. Это то, что вы их предоставляете: грубые, схематичные продукты с отличной историей о том, что может быть этот продукт. Вы уменьшаете функциональность, иногда даже поддельные существование определенной особенности. Джефф Безос, основатель Амазонки, изначально подделал, чтобы иметь отдельные книги на складе, чтобы удовлетворить своих клиентов и начать обучение. Когда люди заказали эти книги, он купил их вручную из своей местной книги издателя и отправил их своим клиентам. Истинное MVP-мышление!
Столбы MVP.
Если вы создаете свое первое программное обеспечение на основе MVP-мышления, рассмотрим эти четыре стойки: функциональность, дизайн, надежность и удобство использования. [1]
- Функциональность : Продукт обеспечивает четко сформулированную функцию для пользователя, и это делает это хорошо. Функция не должна быть обеспечена большой экономической эффективностью. Если вы продали бот чата, который был на самом деле вы общаетесь с пользователем самостоятельно, вы до сих пор предоставляете функциональность высококачественного чата пользователю, даже если вы не разобрались, как предоставить эту функциональность экономически осуществимым способом Отказ
- Дизайн : Продукт хорошо спроектирован и сосредоточен, и он поддерживает ценное предложение продукта. Это одна из распространенных ошибок в генерации MVP – вы создаете плохо разработанный веб-сайт MVP и удивляетесь, почему вы никогда не достигаете подготовки к рынку продукта. Дизайн может быть простым, но он должен поддерживать ценное предложение. Подумайте, что поиск Google – они, безусловно, не потратили много усилий на дизайн при выпуске своей первой версии поисковой системы. Тем не менее, дизайн был хорошо подходит для продукта, который они предложили: бесплатный поиск.
- Надежность : Только потому, что продукт должен быть минимальным; Это не значит, что это может быть ненадежным. Обязательно напишите тестовые случаи и проверьте все функции в своем режиме строго. В противном случае ваши учащиеся из MVP будут разбавлены отрицательным пользовательским опытом, который исходит от плохой надежности. Помните: вы хотите максимизировать обучение минимальным усилиям. Но если ваш программный продукт полон ошибок – как вы можете узнать что-нибудь из отзывов пользователей? Негативные эмоции могут все прийти от сообщений об ошибках, появившись в их веб-браузерах.
- Удобство использования : MVP прост в использовании. Функциональность четко сочтена, и дизайн поддерживает его. Пользователям не нужно много времени. Выяснение, что делать или на каких кнопках нажать. MVP отзывчивается и достаточно быстро, чтобы допустить свободные взаимодействия. Обычно проще добиться превосходной удобства использования с целенаправленным, минималистичным продуктом, потому что страница с одной кнопкой и одним входным полем просты в использовании. Опять же, первоначальный прототип поисковой системы Google Search настолько способен, что это продолжалось более двух десятилетий.
Большой MVP хорошо спроектирован, имеет отличную функциональность (с точки зрения пользователя), надежна и хорошо проверена и обеспечивает хорошую удобство использования. Это не дерьмовый продукт, который не общается и обеспечивает уникальную ценность. Многие люди часто неправильно понимают эту характеристику MVPS: они ошибочно предполагают, что MVP обеспечивает небольшое значение, плохое удобство использования или ленивый дизайн. Тем не менее, минималистка знает, что пониженное усилие происходит от строгого внимания на одной основной функциональности, а не от ленивого создания продукта. Для Dropbox было легче создать потрясающее видео, чем для реализации потрясающего сервиса. MVP был высококачественным продуктом с большой функциональностью, дизайном, надежностью и удобством использования. Было только проще осуществить эти столбы в видео, чем в программном продукте!
Преимущества
Преимущества дизайна программного обеспечения MVP-ориентированного MVP являются коллектором. Вы можете проверить свои гипотезы как можно дешевле. Иногда вы можете избежать написания кода в течение длительного времени – и даже если вам нужно написать код, вы минимизируете объем работы, прежде чем собирать реальную обратную связь. Это не только дает вам подсказки, на которых функции обеспечивают наилучшее значение для ваших пользователей, но также снижает отходы и предоставляет вам быстрое обучение и четкую стратегию для непрерывного улучшения. Вам нужен гораздо меньше времени для записи кода и нахождение ошибок – и если вы сделаете, вы узнаете, что эта деятельность очень цена для ваших пользователей. Любая новая особенность, которую вы отправляете пользователям, предоставляют мгновенную отзыву, а непрерывный прогресс удерживает вас, и ваша команда мотивирована для проверки функции после функции. Это резко сводит к минимуму риски, которые вы подвержены воздействию в стелс-режиме программирования. Кроме того, вы уменьшаете расходы на техническое обслуживание в будущем, потому что это уменьшает сложность вашей кодовой базы с помощью длинного выстрела, и все будущие функции будут проще и меньше ошибок. Вы сделаете более быстрый прогресс, и реализация будет проще в течение всего срока службы вашего программного обеспечения – что удерживает вас в мотивированном состоянии и на пути к успеху. Последнее, но не в последнюю очередь, вы будете доставлять продукты быстрее, заработайте деньги от вашего программного обеспечения быстрее и создайте свой бренд более предсказуемым, более надежным образом.
Разделение тестирования
Последний этап процесса создания программного обеспечения является разделение тестирования: вы не просто запускаете продукт пользовательской базе и надеюсь, что это обеспечивает значение. Вместо этого вы запускаете новый продукт с новой функцией до фракции ваших пользователей (например, 50%) и соблюдаете неявную и явную ответ. Только если вам нравится то, что вы видите, например, среднее время, затрачиваемое на вашем сайте, увеличивается – вы храните функцию. В противном случае вы отклоните его и остаетесь с более простым продуктом без функции. Это жертва, потому что вы проводите много времени и энергии, развивая функцию. Тем не менее, это для большего хорошего, потому что ваш продукт останется максимально простым, и вы остаетесь проворным, гибким и эффективным при разработке новых функций в будущем – без багажа старых функций, которые никто не нуждается. Используя Split Tests, вы участвуете в разработке программного обеспечения для обработки данных. Если ваш тест успешен, вы отправите больше ценности для большего количества людей. Вы добавляете одну функцию в то время, если добавить эту функцию, приводит к вашему видению – вы на пути к прогрессу с дополнительными улучшениями, делая меньше.
Низкие фрукты и быстрый жадный прогресс
Рисунок 4-6: два разных способа создания программного обеспечения, реализуя набор функций: (хорошее) первые функции низкого усилия высокого значения; (Плохое) низкое значение, высокосимальные особенности
На рисунке 4-6 показаны два разных способа приближения к программному проекту. Данный является фиксированным набором функций – горизонтальная длина функции определяет продолжительность времени реализации функции, а вертикальная длина определяет значение, которое функция доставляет пользователю. Теперь вы можете либо расставлять приоритеты к высокому значению, функциям с низким усилием или приоритеты от низкого значения, высокосимающихся функций. Первые приводят к быстрому прогрессу в начале этапа проекта. Последнее приводит к быстрому прогрессу в конце этапа проекта. Теоретически, оба приводят к тому же, получающему программному продукту, обеспечивающему одинаковое значение для пользователей. Тем не менее, жизнь – это то, что произойдет, если вы планируете – это поиграет по-разному: команда, которая приоритет приоритет от низкой ценности, высокосимающиеся функции не будут получать никаких поощрений или отзывов от реального мира в течение длительного периода. Мотивация капель, прогресс приходит в остановку, проект, скорее всего, умрет. Команда, которая приостанавливающая приоритеты высокой ценности, функции с низким усилием разрабатывает значительный импульс к большему количеству ценности, быстро получает отзывы пользователя и гораздо более склонны толкать проект до завершения. Они также могут решить пропустить низкое значение, высокосимальные функции в целом, заменяют их новыми функциями высокого значения, полученные из обратной связи ранних приемных. Удивительно, как далеко вы можете поехать, пожинающую только низкие фрукты!
Ваша идея особенная? Вы можете не понравиться правду
Общие контраргументы против быстрого прототипирования, а также для бессмысленного режима программирования состоит в том, что люди предполагают, что их идея настолько особенная и уникальная, что если они выпускают его в сырой форме, как минимальный жизнеспособный продукт, он будет украден большим и более мощным компаниям – Это реализовать его лучше. Честно говоря, это такой плохой способ мышления. Идеи дешевы; Исполнение – король. Любая заданная идея вряд ли будет уникальной. Есть миллиарды людей с триллионами идей в своих коллективных умах. И вы можете быть уверены, что ваша идея уже думала о другом человеке. Идеи там, и никто не может остановить их распространение. Вместо того, чтобы уменьшить конкуренцию, тот факт, что вы участвуете в стелс-режиме программирования, могут даже поощрять других работать над идеей, потому что они предполагают, что вы, как вы, что никто больше не думал об этом. Для достижения идеи добиться успеха, вам нужно ли подталкивать его в реальность. Если вы быстро продвинулись несколько лет, человек, который преуспел, будет преуспеть, будет тем, кто предпринял быстрые и решительные действия, которые выпустили ранние и часто включили обратную связь от реальных пользователей и постепенно улучшили свое программное обеспечение, создавая наказание на импульс предыдущих релизов. Сохраняя идею «секрет», если вы сможете достичь этого в первую очередь, – просто ограничил бы его потенциал роста и уменьшает его шансы на успех, потому что его нельзя отполировать динамическое исполнение и отзывов реального мира.
Резюме
Представьте себе ваш конечный продукт и подумайте о необходимости ваших пользователей, прежде чем писать любую строку кода. Работайте на своем MVP и сделайте ее ценным, хорошо продуманным, отзывчивым и полезным. Удалите все функции, но те, которые абсолютно необходимы для максимизации ваших учащихся. Сосредоточиться на одной вещи за раз. Затем быстро выпустите MVP и часто улучшайте его со временем, постепенно тестируя и добавляя больше функций. Меньше – больше! Потратьте больше времени, думая о следующей функции, чтобы реализовать, чем фактически реализует каждую функцию. Каждая особенность несет не только прямую, но и косвенные затраты на реализацию для всех функций, которые должны прийти в будущем. Используйте разделение тестирования для проверки ответа на два варианта продукта одновременно и быстро отказаться от особенностей, которые не приводят к улучшению ваших ключевых пользовательских метрик, таких как удержание, время на странице или действий. Это приводит к более целостному подходу к бизнес-признанию, что разработка программного обеспечения является только одним шагом во всем процессе создания продуктов и стоимости доставки.
В следующей главе вы узнаете, почему и как писать чистый и простой код – но помните: не писать ненужный код – самый верный способ чистить и простой код!
[1] Дальше чтение: https://pixelfield.co.uk/blog/mvp-what-is-it-and-why-is-it-crucial-for-your-business/
Куда пойти отсюда
Вы хотите развивать навыки Хорошо округлый Python Professional То же оплачивается в процессе? Станьте питоном фрилансером и закажите свою книгу Оставляя крысиную гонку с Python На Amazon ( Kindle/Print )!
Работая в качестве исследователя в распределенных системах, доктор Кристиан Майер нашел свою любовь к учению студентов компьютерных наук.
Чтобы помочь студентам достичь более высоких уровней успеха Python, он основал сайт программирования образования Finxter.com Отказ Он автор популярной книги программирования Python одноклассники (Nostarch 2020), Coauthor of Кофе-брейк Python Серия самооставленных книг, энтузиаста компьютерных наук, Фрилансера и владелец одного из лучших 10 крупнейших Питон блоги по всему миру.
Его страсти пишут, чтение и кодирование. Но его величайшая страсть состоит в том, чтобы служить стремлению кодер через Finxter и помогать им повысить свои навыки. Вы можете присоединиться к его бесплатной академии электронной почты здесь.
Оригинал: “https://blog.finxter.com/minimum-viable-product-mvp-in-software-development-or-why-stealth-sucks/”