Прекарах кариерата си в Силициевата долина, потънал дълбоко в нейната жизнена предприемаческа култура. Всяко стартиране е на вълнуващо и често опасно пътуване в неизследвана територия и аз съм предприемал това пътуване няколко пъти ― като софтуерен инженер, инженерен мениджър, технически директор, основател и разработчик на свободна практика. Много от продуктите, които изградих, достигнаха до аудитории на хиляди хора ―, а някои и до милиони.
Според моя опит един от най-мощните инструменти в инструментариума от Силициевата долина е способността да се балансират скоростта и дълбочината при пускане на нови продукти. Бестселър на Ерик Рийс Lean Startup кодира тази философия в концепцията за минимално жизнеспособен продукт (MVP).
Една от основните причини понятието за MVP да се разраства през последните години е безпрецедентната скорост и мащаб, с които вече можем да получим и да действаме по обратна връзка с клиентите. През 2009 г. моята игра за iPhone Slingshot Cowboy беше изтеглена от милиони хора в рамките на една седмица от пускането й и бързо работеше чак до върха на класациите (достигаше позиция # 1 за безплатна игра няколко пъти през целия си живот) . Голяма част от този успех може да е бил късмет, но ако не събрах бързи отзиви и не приложих основните принципи на MVP рано, нямаше да мога да поддържам този импулс дълго.
Постните принципи се свеждат до това да можете бързо да итерирате, да сте умни да изразходвате енергията и ресурсите си и да сте пъргави, фокусирани и отворени. Но ние вярваме, че приложимостта на тази методология не е ограничена до стартиращи ― екипи в големи предприятия, които могат да увеличат максимално своя темп на иновации чрез създаване на успешни MVP.
Постигането на баланс между скорост и качество е един от най-важните двигатели на иновациите за организации от всякакъв размер. Докато ръководите разработването на собствения си минимално жизнеспособен продукт, ето нашите стратегии, за да помогнем за поддържането на баланс между тези две основни съставки.
Ако вашият продукт не е жизнеспособен, усилията за развитие на вашия екип са напразни. За успешното създаване на минимално жизнеспособен продукт се нуждаете от ранна вътрешна обратна връзка, за да го дефинирате широко, непрекъсната обратна връзка, за да го оформите правилно, и инструменти като A / B тестване, за да продължи да процъфтява.
Получаването на отрицателни отзиви от потребителите за вашия MVP може да бъде толкова обезсърчително, че се чувствате принудени да прекратите проекта. Иноваторите могат да избегнат този опустошителен удар, като поискат ранни мнения от заинтересованите страни с дълбоко разбиране на пространството, много преди да обмислят MVP. Още по-добре е, ако имате опитни съветници, които могат да ви помогнат да определите MVP на етапа на концепцията.
Когато екип за иновации има обещаваща идея, може да се изкуши да скрие създаването на MVP в тайна: „Ние сме в стелт режим, все още не можем да ви разкажем много за това.“ Това може да си струва в някои случаи, но като цяло получаването на обратна връзка е по-важно. Ако смятате, че вашият продукт представлява наистина оригинално изобретение, винаги можете да подадете временен патент.
Дори ако се смятате за мечтател във вашата индустрия или сектор, вашите най-добри съдии са вашите потребители и те могат да докажат, че грешите в много неща. Събирането на обратна връзка с потребителския опит и проследяването на поведението на потребителите са сред най-важните цели на MVP.
Въведете анализ. Събирането на изчерпателни данни е ключът към постигането на една от основните цели на вашето MVP― „потвърдено обучение“, процес, в който човек се учи, като изпробва първоначална идея и я измери, за да потвърди (или обезсили) ефекта. Това не означава, че искате да проследявате всичко за UX евентуално можете ―, вместо да бъдете затрупани с обеми необработени данни, идентифицирайте показателите, които са най-важни.
A / B тестовете се превърнаха в основен елемент на предприятието, когато става въпрос за усъвършенстване на продукта. Винаги, когато трябва да изберете измежду алтернативно поведение на продукта, A / B тестването е начин да го направите в реално време, без да се налага да пускате нова версия.
Например, ако вашият продукт е игра, може да искате да изпробвате различни настройки на играта и след това да разгледате анализа си, за да установите коя комбинация влияе положително на вашите ключови показатели: по-дълга игра, по-добре лепкавост и т. н. Точно това направих за повечето от игрите си: всеки аспект на геймплея се контролираше от настройка, която можех да променя в реално време. Тази форма на валидирано обучение ми помогна да определя оптималната комбинация от настройки за моя целеви пазар.
За по-нататъшно четене Стивън Доу от Станфорд изследва варианти на тази концепция в Как практиките за прототипиране влияят върху резултатите от дизайна .
Колкото и оригинална да изглежда идеята ви, бъдете сигурни, че някой вече се е сетил за нея. Ако вашият минимален жизнеспособен продукт отговаря на навременни и неотложни нужди на клиентите, има вероятност, докато приключите, и вашият конкурент да получи сцепление. Стабилността е важна ― както подчертава следващият раздел ―, но е добре да променяте MVP от време на време, като черпите вдъхновение от конкурентите и измествате фокуса, за да подчертаете характеристиките, които са вашето конкурентно предимство.
Намирането на баланс между „минимален“ и „жизнеспособен“ е интуитивно умение и това, което ще трябва да упражнявате многократно, особено ако пазарът се промени, преди да изпратите MVP.
След като сте определили жизнеспособен продукт, който отговаря на ясната нужда от целевия Ви пазар, от съществено значение е да стесните фокуса на вашия екип.
MVP е като матрьошка: Вътре винаги има по-малък MVP. Определението на продукта се състои в намирането на най-практичния минимум, в зависимост от вашите цели.
Ако вашият продукт е насочен към потребителя, започнете с телени рамки ― това е първият ви, най-съкровен MVP. Следващата „кукла“ около нея може да бъде „манекен за щракване“, интерактивна демонстрация, която не прави нищо реално, но ви позволява да я видите на целевата платформа и да получите първото си изживяване с потребителския поток.
След като сте доволни от това прототип , започнете да изработвате по-голямата кукла, слоят, който започва да предоставя реална стойност на потребителите. На този етап можете да изберете да започнете да разглеждате основните функции. Долната линия: ясно дефинирайте мини-етапите, не прескачайте напред и се уверете, че сте изпълнили собствените си критерии, преди да продължите напред.
Това е вярно за MVP, което вашето предприятие първоначално предлага на пазара, но минималният жизнеспособен манталитет също трябва да продължи през целия жизнен цикъл на вашия продукт. Помислете за всяка нова версия като за по-голям MVP ―, когато добавяте нов слой нови функции, уверете се, че тя приляга плътно на предишната, като направите най-малкото промени, необходими за постигане на жизнеспособна нова версия.
Намирането на баланс между „минимум“ и „жизнеспособност“ е интуитивно умение и това, което ще трябва да упражнявате многократно.
Независимо дали най-гласовитите ви заинтересовани страни са във вашето предприятие или външни клиенти, би било добре да бъдат информирани за опасностите от пълзене на функции и да потиснат желанията си да добавят нови „задължителни неща“ в последния момент.
Без отметка, тенденцията да се отклонявате от определения минимум ще изтощи морала. Гордият момент, когато разработчиците завършат свързването на всички компоненти, става антиклиматичен. Постоянно движещите се цели подхранват нестабилността на продукта.
Особено в предприятието, процесът на изграждане на успешни MVP ще се възползва от изпълнителните спонсори, които напомнят на своите колеги и други заинтересовани страни ― толкова често, колкото е необходимо ―, че „Трябва да спрем сега и да изтласкаме тази функция. Може да не ви изглежда достатъчно добре, но ще бъде много по-лошо, ако е счупено. ' Като изпълнителен директор, вашата работа е да буферирате разработчиците от външни влияния, като давате пример в рамките на вашата работна култура да се придържате към приоритетите.
И обратно, разработчиците на софтуер и техните мениджъри трябва да оценят крайните срокове и да запазят своите перфекционистки стремежи под контрол . Ето един често срещан сценарий: „Тази част от кода изглежда грозна, тази наистина е неефективна; трябва да почистим и преработим. '
Разработчиците може да са прави да кажат това, но техните мениджъри все пак трябва да се оттеглят. Като технически ръководител може да се радвате на вниманието им към детайлите и да искате да действате по него. Но това е въпрос на време ― имайте предвид важното съобразяване с изпращането и получаването на обратна връзка и вместо това направете бележка за критични проблеми, които не са важни за мисията, като ги почистите в следващата итерация.
Успехът на вашия продукт зависи изцяло от динамиката на пазара, на който предстои да навлезете. Но където и да начертаете линията за дефиниция на продукта за вашия MVP, ние предлагаме две допълнителни практически тактики, които успешните предприятия използват, за да изпратят своите MVP.
Във възможно най-голяма степен иновационните екипи не трябва да преоткриват колелото, когато създават MVP. Винаги можете да замените компоненти на трети страни по-късно с нещо, разработено вътрешно, когато времето е подходящо. Срамът от неоригиналността отдавна е отминал: Сега това е обичайна практика и много от градивните елементи са с отворен код и могат да се персонализират.
Например, ако вашият продукт включва комуникация в реално време, има отлични решения на трети страни, които са лесни за интегриране и включват ключови функции като персонализируеми потребителски интерфейси, комуникационна инфраструктура и криптиране. По същия начин, ако създавате приложение, постигането на професионален външен вид с бързи анимации и преходи може да не изисква вътрешен дизайнер ― разработчиците ви могат да спестят време с компоненти на трети страни.
Вярно е, че няколко решения на трети страни някога ще се впишат идеално във вашите случаи на употреба. Но те не трябва да ― все още. Докато ви позволяват да изпратите продукт, който може да потвърди бъдещите инвестиции в персонализирани решения, вие все още напред.
Първият ви разработчик трябва да бъде първокласен. Не започвайте с стажанти: инвестирайте в талант от самото начало. Това може да звучи като противоречие на основната предпоставка на метода „постно“, но „евтино“ не е непременно „постно“. Въпреки че дори корпоративните бюджети могат да бъдат ограничени, почасовата ставка на разработчика е само един от компонентите на разходите - времето за разработка нараства обратно пропорционално на почасовата ставка. Умножете двете заедно и вашето предимство по отношение на разходите вече е изчезнало.
Добавете времето, което отделяте за наставничество и преследване на бъгове, които първоначално не би трябвало да са там. Помислете за режийните разходи за всеки изгубен ден: офис площи, заплати на други служители, такси за сървъри и др. Фактор за нематериалните активи като алтернативните разходи, ако пристигнете твърде късно на пазара.
Правейки математиката, разбирате, че ще бъде много по-добре да наемете един „скъп“ и опитен разработчик, който да произведе MVP срещу куп младши. Младите разработчици могат да дойдат по-късно, след като основата на вашия продукт бъде изградена и можете да започнете да мислите за оптимизиране на дългосрочните разходи.
Ето пример от реалния живот. Един мой приятел предприемач искаше да добави няколко привидно тривиални функции към своя MVP. Той имаше един много опитен разработчик в екипа, който даваше страхотни резултати при $ 120 / час. Мислейки, че следващите функции могат да бъдат по-евтини, приятелят ми нае стажант на $ 30 / час.
Стажантът завърши четири дни по-късно. При бегъл преглед функциите изглеждаха работещи и приятелят ми премина към следващия етап. Опитният разработчик отново се включи и осъзна, че не само кодът се проваля в някои ъглови случаи, но и не може да се поддържа напред. Така той прекара цял ден в пренаписването му.
Четири дни работа на стажант ($ 960) плюс един ден за пренаписване ($ 960) = $ 1920. Ако опитният разработчик беше работил по функцията на първо място, това щеше да бъде направено точно за една пета от времето и да струва по-малко от половината пари, дори без да се вземат предвид други разходи.
Съвършенството все още не е целта, но има риск от прекомерно коригиране спрямо качеството ― можете напълно да дискредитирате продукта си, като пуснете нещо, което се срива наляво и надясно, неполирано, тромаво и просто неизползваемо. В резултат на това може да не получите втори шанс.
Тук сме засегнали само няколко аспекта от развитието на MVP. Но дори и с изчерпателно ръководство, процесът винаги ще има повече, отколкото сте вярвали, повече работа, отколкото сте предвидили, и повече предизвикателства, отколкото сте очаквали.
В един момент трябва да изтеглите чертата и да изнесете продукта си в света. Това е най-смразяващият и вълнуващ момент и няма точна наука за него. Трябва да се доверите на чувството си за червата, но спазването на постните принципи в процеса ще ви помогне да усъвършенствате инстинктите си и да улесните това решаващо решение. И след като достигнете този първи крайъгълен камък на положителната обратна връзка и имате доверие във вашата визия, можете да започнете да се придвижвате все по-навътре, в дълбочина, към продукта на мечтите си.