UX, duomenų, administravimo, mobilaus srauto, paleidimo ar perdavimo rizikos blokuoja paleidimą, tačiau produktą gali būti verta išsaugoti.
Produkto taisymas ir MVP gelbėjimas.
Esamiems produktams, kurie beveik veikia, bet vis tiek kelia riziką: neaiškus srautas, silpnas mobilus UX, nutrūkęs paleidimo planas, trūkstamas administravimas, nestabilūs duomenys arba neaiškus kito kūrimo sprendimas.
Klientas turėtų pamatyti, ką galima pataisyti, kas išlieka rizikinga ir kada perkurti tampa sąžiningesniu sprendimu.
Naudokite 4 000–10 000 EUR tik tada, kai išsaugomas kelias yra aiškesnis nei naujas kūrimas nuo nulio.
Jei architektūra, duomenys ar paleidimo planas yra nesaugūs, nustokite lopyti ir parašykite perkurimo ribą.
Naudokite tai, kai paleidimas blokuojamas dėl UX, duomenų, administravimo dalies, mobilaus srauto ar perdavimo rizikos.
Pirmiausia taisykite, kai naudingą kelią pavyks išsaugoti greičiau, nei viską perkurti.
Palyginkite savo nutrūkusį kelią su darbo srauto, vaidmens, paleidimo ir nuosavybės rizika.
Pirmame atsakyme turėtų būti nurodyta, ką taisyti, ko vengti ir kada perkurti yra sąžininga.
taisymo gyvybingumo santrauka
Įrodykite, ką galima išgelbėti prieš parduodant rekonstrukciją.
Sugedus MVP paprastai reikia sprendimo dar prieš naują kodų bazę. Produkto taisymas turėtų atskleisti naudingą branduolį, surikiuoti paleidimo blokatorius ir parodyti perkurimo ribą prieš išleidžiant daugiau.
- Naudinga pagrindinė patikra Nurodykite naudotojo kelią, verslo logiką, duomenis ir elgseną, kuri turėtų atlaikyti taisymą.
- Paleidimo blokavimo rangas Atskirkite tikrus blokatorius nuo užduočių sąrašo triukšmo: UX, autentifikavimo, duomenų, administravimo, mobilaus srauto, diegimo arba palaikymo.
- Mažas taisymo gabalas Pataisykite mažiausią kelią, kuris įrodo, kad paleidimas gali judėti į priekį, neapsimetant, kad visos problemos vienodai svarbios.
- Sąžininga perkurimo riba Perkurimą įvardykite tik tada, kai architektūra, duomenų modelis arba paleidimo planas negali saugiai panešti produkto.
Raskite blokatorius
- UX srautas, kuris praranda naudotojus prieš atlikdamas naudingą veiksmą.
- Autentifikavimo, duomenų arba administravimo spragos, dėl kurių palaikymas apsunkinamas.
- Mobiliojo telefono išdėstymo problemos ir paleidimo blokavimo trintis.
- Diegimo ir perdavimo neapibrėžtumas.
Taisymas prieš perkurimą
Visiškas perkurimas ne visada yra profesionalus žingsnis. Jei pagrindinį produktą galima išsaugoti, pirmasis tikslas yra izoliuoti riziką ir išleisti naudingą versiją.
Išvalyti kitą versiją
- Prioritetinis taisymo žemėlapis.
- Tiksliniai kritinio produkto kelio pataisymai.
- Paleidimo ir patvirtinimo pastabos.
- Kitos versijos rekomendacija.
Esamas MVP, kuriam reikia greito aiškumo
Puikiai tinka, kai produktas jau yra ir įkūrėjui reikia praktiško techninio savininko, kuris pašalintų trintį, o ne naują pristatymą.
Kam tai skirta
Steigėjai, turintys esamą MVP, gyvą prototipą arba paveldėtą produktą, kur naudingą branduolį gali būti verta išsaugoti prieš perkurimą.
Įtraukta
- Blokatorių auditas UX, autentifikavimo, duomenų, administravimo ir paleidimo kelyje.
- Sutelktas taisymas į kritinį naudotojo ar operatoriaus srautą.
- Patvirtinimo pastabos, sprendimas paleisti ir kitos versijos žemėlapis.
Neįtraukta
- Aklas perkurimas prieš suprantant esamą produktą.
- Didelis pertvarkymas, kuris neatblokuoja produkto kelio.
- Kiekvieno atsilikimo elemento taisymas prieš priimant sprendimą išleisti.
Sprendimo kriterijus
Taisymas tęsiamas tik tuo atveju, jei kritinis kelias gali tapti saugesnis greičiau nei perkurimas. Priešingu atveju sąžiningas atsakymas yra perkurimo riba.
Perdavimas
Steigėjas išeina žinodamas, kas buvo sutvarkyta, kas lieka rizikinga, ko dar nereikėtų liesti ir kas pateisintų kitą kūrimą.
Kodėl neperkurti iš karto?
Perkurimas gali būti teisingas atsakymas, bet tik po to, kai perskaitomas dabartinis produktas. Jei naudingą kelią galima sutvarkyti greičiau, klientas išsaugo daugiau biudžeto ir daugiau sužino.
Ką daryti, jei kodas per silpnas?
Tada taisymo eigoje tai turi greitai pasimatyti: ką galima išsaugoti, ką reikia pakeisti ir kokia riba perkurimą padarytų saugesnį nei lopymą.
Kaip tai padeda paleisti?
Darbo tikslas pirmiausia yra paleidimo blokatoriai: pažeistas naudotojo kelias, mobilus UX, autentifikavimo / duomenų / administravimo spragos, diegimo rizika, palaikymo matomumas ir žinomos gedimo būsenos.
Kokie blokai tinka?
Netinka, kai nėra prieigos prie produkto, nėra aiškaus savininko, nėra kritinio kelio arba užduočių sąrašas reikalauja taisyti viską prieš pirmą paleidimo sprendimą.
Sprendimo riba
Taisymas prasideda nuo sprendimo, ką reikia taisyti, kas gali palaukti ir ar esamas produktas vertas taisymo prieš rekomenduojant jį perkurti.
Rizika tvarkoma
Esama MVP rizika dažniausiai slepiasi nutrūkusiuose naudotojo keliuose, silpname mobiliame UX, nestabiliuose duomenyse, trūkstamame administravime, paleidimo blokatoriuose ir neaiškioje nuosavybėje.
Pristatymo įrodymas
Įrodymas turėtų būti matomas kaip pataisytas kritinis kelias, blokatorių sąrašas, patvirtinimo pastabos, sprendimas paleisti ir kitos versijos rekomendacija.
Ką gauna klientas
Klientas turėtų išeiti žinodamas, kas buvo pataisyta, kas išlieka rizikinga, kaip paleisti produktą ir kada iš tikrųjų būtų pateisinamas atnaujinimas.
taisymo klausimai
Sutvarkykite kelią prieš finansuodami perkurimą.
Kruopštus taisymo sprendimas turėtų apsaugoti naudingą branduolį ir atskleisti, kada perkurimas yra sąžiningesnis kelias.
Ką įrodo produkto taisymas prieš perkurimą?
Produkto taisymas turėtų įrodyti, ar dabartinis produktas turi naudingą branduolį, kurie paleidimo blokatoriai svarbiausi, ką galima saugiai pataisyti dabar ir kur perkurimo riba tampa sąžiningu atsakymu.
Kada produkto taisymas yra geriau nei perstatymas?
Taisymas yra geresnis, kai esamas produktas turi naudingą branduolį, o paleidimo blokatorius yra aiški UX, autentifikavimo, duomenų, administravimo, mobilaus srauto, paleidimo ar perdavimo problema.
Kokios prieigos reikia norint priimti taisymo sprendimą?
Naudinga prieiga paprastai apima produkto kelią, saugyklą arba kūrimo būseną, žinomą gedimą, sprendimo savininką ir aiškų kritinį srautą, kurį reikia patikrinti pirmiausia.
Ką daryti, jei kodas turėtų būti pakeistas?
Tada taisymo eiga turi greitai parodyti, ką verta išsaugoti, ir apibrėžti perkurimo ribą, o ne slėpti išlaidas lopymuose.
Kas turėtų būti aišku po produkto taisymo?
Klientas turėtų žinoti, kas buvo pataisyta, kas išlieka rizikinga, kaip valdyti produktą ir kas pateisintų kitą kūrimą ar perkurimą.
kitas signalas
Siųsti taisymo santrauką
Atsiųskite sulūžusį kelią.
Pasidalykite tuo, kas egzistuoja, kas neveikia, kas tuo naudojasi, ką pirmiausia reikia pataisyti ir kokie įrodymai pateisintų taisymo išlaidas.