"Jos et ole nolostunut tuotteesi ensimmäisestä versiosta, olet lanseerannut liian myöhään." - Reid Hoffman Me Splitsillä noudatamme tätä lähestymistapaa ohjelmistojen rakentamiseen: laita se toimimaan → tee siitä oikea → nopea. Järjestyksellä on merkitystä. Tässä on mitä olemme oppineet toimittamisesta kussakin vaiheessa:

Laita se toimimaan = toimiva prototyyppi. Sen pitäisi olla karkeaa. Sen pitäisi olla nyrki. Tuo se nopeasti käyttäjien eteen. Kuinka rajoitamme MVP:tä: 1) Listaa kaikki, mikä mielestämme voisi olla tärkeää tai merkityksellistä projektin kannalta. 2) Mikä on *ehdoton vähimmäismäärä* tästä luettelosta, jonka voimme viimeistellä ja saada toimivan prototyypin?

Tee se oikein = korjaa kaikki rikkinäiset terät. Siirry tähän vaiheeseen selkeillä signaaleilla markkinoilta: johdonmukainen palaute, kasvava käyttö ilmeisistä puutteista huolimatta. Nyt olet ansainnut oikeuden sijoittaa enemmän resursseja.

Tee siitä nopea = optimoi suorituskyky. Rehellisesti sanottuna opimme vielä tästä vaiheesta. Suurin osa Teamsista on tällä hetkellä "tee se oikein" -tilassa 🤷 ♂️ Mutta tässä on inspiraatio, joka ajaa meitä:

Miksi tämä lähestymistapa toimii: Sekvensointi on strategiaa. Se, mitä opit tänään, muokkaa sitä, mitä rakennat huomenna. Hyppää eteenpäin, niin sinulla ei ole tietoja, joita tarvitaan ongelmien ratkaisemiseen oikein. Toiminta tuottaa tietoa. Mutta *tarkoituksellinen* toiminta tuottaa *hyödyllisempää* tietoa.

Ansa yrittää saada sen kuntoon samaan aikaan, kun saat sen toimimaan. EI. "Anna itsellesi lupa lähettää jotain, jonka tiedät olevan väärin." - @wminshew