MVP
Noen har et godt poeng her. Det vi har mest bruk for er «å feile fort». Hvis det ikke er liv laga, ta livet av rotta. Forsøk det vanskeligste først. Ikke lag bedre og
bedre prototyper mens du utsetter det virkelige problemet. Det som kan ta livet av produktet ditt til slutt.
Det som verre er, er at en MVP kan forsterke følelsen din av at dette kommer til å bli et storartet produkt, og du vil kanskje begynne å prelansere det basert på at mange funksjoner allerede er på plass. Man får en prematur release uten å ha testet de største usikkerhetene.
En gang for mange, mange (ja, mange) år siden var jeg prosjektleder for den første skikkelige VR boresimulatoren i oljeindustrien. Vi var omtrent ferdige. Mange, mange tusen programmeringstimer var gått med, og vi lå an til å møte deadline og budsjett. All testing fungerte som en drøm, Men så skulle vi plukke opp et rør med pipehandleren og levere det over til top-driven…… Det var der hunden lå begravet. Vi hadde surfet på medgangsbølgen av hvor fint maskinene oppførte seg på VR-lerretet. Og ikke tatt hensyn til det som var risky; å jobbe med animerte modeller som overførte objekter seg imellom. Fra den dagen vi oppdaget det til vi faktisk var ferdige, gikk det med like mange programmeringstimer som vi hadde brukt til da 🙁
Jepp – jeg har vært der. Been there, done that.
Så kanskje MVP er en blindvei? Do it the RAT-way.
Les hele artikkelen til Hackhernoon her.