Mitä räätälöity sovellus oikeasti maksaa: rehellinen ja läpinäkyvä erittely

Kysy kolmelta toimistolta, mitä räätälöity sovellus maksaa, ja saat kolme lukua, joilla ei ole edes yhteistä numeroa. Yksi sanoo neljä tuhatta, toinen neljäkymmentä, kolmas sanoo hiljaa, että riippuu, ja varaa toisen palaverin. Kukaan heistä ei varsinaisesti valehtele — mutta kukaan ei kerro sitä, mitä sinun oikeasti pitäisi tietää: mihin raha menee ja miksi juuri sinun sovelluksesi asettuu sinne, minne se asettuu. Avataan siis konepelti.

Olen kirjoittanut enemmän sovellustarjouksia kuin osaan laskea, yrityksille yhden hengen rakennusalan toiminimestä alueelliseen ketjuun. Yleisin reaktio hintaan ei ole järkytys loppusummasta — vaan hämmennys vaihteluvälistä. Miten sama kolmen sanan toimeksianto (”varaussovellus”) tuottaa arvioita, jotka eroavat kymmenkertaisesti? Rehellinen vastaus on, että ”varaussovellus” ei ole toimeksianto. Se on toive. Hinta piilee sadassa pienessä päätöksessä sen alla.

Tämä teksti on se erittely, jonka toivoisin jokaisella yrittäjällä olleen ennen ensimmäistä puhelua kehittäjän kanssa. Ei täytettä, ei pelottelua, ei lisämyyntiä. Vain todelliset kustannuskomponentit, asiat jotka huomaamatta tuplaavat budjetin, ja muutama rehellinen tapa käyttää vähemmän rahaa päätymättä johonkin, mitä kadut.

Miksi kaksi tarjousta ”samasta sovelluksesta” eroavat kymmenkertaisesti

Ohjelmisto ei ole tuote, jonka nappaat hyllyltä — se on työtä, mitattuna osaavien ihmisten tunneissa. Joten räätälöidyn sovelluksen hinta on pohjimmiltaan vain laajuus × tuntihinta × riski. Kaikki muu on alaviite näihin kolmeen. Kun kaksi tarjousta poikkeaa rajusti, jokin näistä kolmesta luvusta luetaan hyvin eri tavalla — eikä sitä yleensä ole sanottu ääneen.

Laajuus on se ilmeinen. ”Varaussovellus” voi tarkoittaa yhtä ruutua, jolta asiakas valitsee ajan — tai se voi tarkoittaa henkilöstön kalentereita, maksuja, muistutuksia, asiakaskirjautumista, hallintapaneelia, hyvityksiä ja raporttia, jonka yrittäjä lukee maanantaina. Samat kolme sanaa, kymmenkertainen työ. Halpa tarjous olettaa usein pienen version; kallis olettaa hiljaa sen ison. Kumpikaan ei kysynyt, kumpaa tarkoitit.

Sitten on riski, se osa jota kukaan ei halua hinnoitella. Epämääräinen toimeksianto, asiakas joka ei ole päättänyt mitä haluaa, integraatio narisevaan vanhaan järjestelmään — nämä eivät vain lisää tunteja, ne lisäävät epävarmuutta. Kokeneet tiimit varaavat puskuria epävarmuuteen, koska ovat polttaneet näppinsä siihen. Halvempi tarjous ei usein ole hinnoitellut riskiä lainkaan, mikä on juuri syy siihen, että se joskus paisuu puolessavälissä.

Mihin raha oikeasti menee

Kun ihmiset kuvittelevat sovelluskehitystä, he kuvittelevat koodaamista. Koodaus on todellista, mutta se on harvoin edes puolet laskusta. Räätälöity sovellus on lähempänä pienen talon rakentamista kuin asiakirjan kirjoittamista — näkyvän osan ympärillä on suunnittelua, putkitöitä, tarkastusta ja paperityötä. Näin tyypillinen budjetti jakautuu, kun otetaan kaikki huomioon.

Kaksi asiaa tässä taulukossa yleensä yllättää. Ensinnäkin se, kuinka suuri osa budjetista tapahtuu ennen kuin riviäkään ominaisuuskoodia on kirjoitettu — kartoitus ja suunnittelu eivät ole ylellisyyttä, vaan halvin paikka korjata virhe. Ruudun muuttaminen luonnoksessa maksaa minuutteja; sen muuttaminen rakentamisen jälkeen maksaa päiviä. Toiseksi se, kuinka todellinen testausrivi on. Sen ohittaminen ei säästä rahaa, se vain siirtää kustannuksen julkaisuviikkoosi, korkojen kera.

Kartoitus ja suunnittelu: se osa jonka kaikki haluavat ohittaa

Kartoituksessa muutat ”varaussovelluksen” täsmälliseksi listaksi ruutuja ja sääntöjä. Se tuntuu yleiskustannukselta, koska mitään ei vielä rakenneta. Mutta jokainen tunti täällä säästää useita myöhemmin, koska täällä epäselvyys tapetaan sen ollessa vielä halpaa. Tiimi, joka antaa sinulle hinnan ilman kartoitusvaihetta, joko arvaa tai aikoo laskuttaa kartoituksesta myöhemmin eri nimellä.

Ydinkehitys: näkyvä moottori

Tämä on se koodi, joka saa ideasi toimimaan — ruudut joita ihmiset napauttavat, niiden takana oleva logiikka ja tietokanta, joka hiljaa muistaa kaiken. Se on suurin yksittäinen viipale, ja se skaalautuu lähes suoraan laajuuden mukaan. Jokainen lisäämäsi ominaisuus on lisää rakennettavaa, lisää testattavaa ja lisää ylläpidettävää ikuisesti. Tämä on se rivi, jolla ”eikö olisikin kiva, jos” muuttuu nopeasti kalliiksi.

Integraatiot: petollisen kallis osa

Sovelluksesi yhdistäminen muihin järjestelmiin — korttimaksun ottaminen, tekstiviestimuistutuksen lähettäminen, kalenterin synkronointi, tietojen hakeminen jo käyttämästäsi kirjanpito-ohjelmistosta — näyttää pieneltä ominaisuuslistalla ja painaa yllättävän paljon laskussa. Jokainen yhteys on oma pieni projektinsa, omine kummallisuuksineen ja vikatiloineen. Yksi hyvin käyttäytyvä maksuintegraatio on ihan ok. Viisi sotkuista integraatiota ikääntyvään sisäiseen järjestelmään on se paikka, jonne budjetit menevät kuolemaan.

Kustannukset, joita kukaan ei laita tarjoukseen

Tässä moni yrittäjä saa ikävän yllätyksen kahdentoista kuukauden kohdalla. Rakentaminen on kertaluku; sovellus ei ole kertaluonteinen asia. Ohjelmisto on elävää — puhelimet päivittyvät, säännöt muuttuvat, yrityksesi kasvaa — ja elävää asiaa pitää ruokkia. Allekirjoittamasi tarjous on syntymän hinta, ei omistamisen hinta.

Mikään tästä ei ole huijausta tai piiloansa — se on vain se osa, joka ei mahdu siististi yhden sivun tarjoukseen, joten heikommat kumppanit jättävät sen pois näyttääkseen halvemmilta. Hyvä kertoo siitä etukäteen, vaikka se saa ensimmäisen luvun näyttämään suuremmalta. Kysy suoraan: mitä tämän pyörittäminen maksaa minulle vuoden ajan julkaisun jälkeen? Vastauksen laatu kertoo paljon siitä, kenen kanssa olet tekemisissä.

Mikä huomaamatta tuplaa hinnan

Jotkin asiat lisäävät kustannusta suhteessa tuomaansa arvoon — ihan oikein. Toiset lisäävät kustannusta täysin suhteettomasti, yleensä siksi miten työ on rakennettu eikä siksi mitä sovellus tekee. Nämä ovat ne vivut, jotka kannattaa ymmärtää, koska muutama niistä on täysin sinun hallinnassasi.

• Kaksi alustaa yhden sijaan. Natiivi iPhone-sovellus ja natiivi Android-sovellus ovat karkeasti kaksi rakennusta. Monialustatyökalut tai verkkosovellus voivat kutistaa sen takaisin kohti yhtä. Tämä yksi valinta voi siirtää loppusummaa enemmän kuin mikään ominaisuus.
• Räätälöity suunnittelu järkevien oletusten sijaan. Pikselintarkka, täysin räätälöity käyttöliittymä maksaa oikeaa rahaa suunnitella ja rakentaa. Siisti, perinteinen, hyväksi todettuja malleja käyttävä on nopeampi, halvempi ja usein asiakkaille helpompi käyttää.
• Mielen muuttaminen rakentamisen alettua. Päätökset ovat halpoja fläppitaululla ja kalliita koodissa. Yleisin budjetin ylitys ei ole huono arviointi — vaan laajuus, joka jatkoi kasvuaan, koska mitään ei lyöty lukkoon.
• Reaaliaikaisuus, offline tai raskas data. ”Sen pitää toimia ilman signaalia” tai ”päivitysten täytyy näkyä kaikille välittömästi” ovat järkeviä pyyntöjä, jotka hiljaa moninkertaistavat alla olevan insinöörityön.
• Integrointi johonkin vanhaan ja dokumentoimattomaan. Moderniin, hyvin rakennettuun järjestelmään yhdistäminen on rutiinia. Viisitoistavuotiaaseen, dokumentoimattomaan sisäiseen työkaluun yhdistäminen on arkeologiaa — ja se laskutetaan tunnilta.

Todellinen esimerkki: 60 000 euron tarjous, josta tuli 14 000 euron sovellus

Muutamia yksityiskohtia on muutettu yksityisyyden vuoksi, mutta tämän muoto on totta ja täysin tyypillinen. Alueellinen palveluyritys — ajattele tusinaa kenttätyöntekijää ja kiireinen toimisto — tuli luoksemme turhautuneena. He halusivat räätälöidyn sovelluksen, jolla asiakkaat voisivat varata töitä, seurata edistymistä ja maksaa. He olivat jo saaneet muualta tarjouksen noin 60 000 eurosta plus tukeva kuukausimaksu, ja se oli karkottanut heidät koko ideasta lähes vuodeksi.

Kun oikeasti kartoitimme, mitä he tarvitsivat — emme sitä mistä heille oli tarjottu — kuva näytti hyvin erilaiselta. Ensimmäinen tarjous oli olettanut kaksi täysin natiivia sovellusta, räätälöidyn suunnittelun tyhjästä, reaaliaikaisen tehtävienjakojärjestelmän ja räätälöidyn hallinta-alustan korvaamaan työkalut, jotka heillä jo oli ja joihin he olivat hiljaa tyytyväisiä. Se oli teknisesti täysin hyvä sovellus. Se oli myös vastaus kysymykseen, jota he eivät olleet esittäneet.

Mitä me oikeasti teimme

Vietimme ensimmäiset istunnot pelkkään kartoitukseen — purkaen toiveen osiin ”liiketoiminta hajoaa ilman tätä” vastaan ”tuo olisi mukava joskus”. Pakolliset asiat olivat kapeampia kuin kukaan odotti: siisti tapa asiakkaille pyytää ja seurata työtä, automaattiset muistutukset ja verkkomaksu. Reaaliaikainen tehtävienjako ja räätälöity taustatoimisto osoittautuivat ratkaisuiksi ongelmiin, jotka heidän olemassa oleva ohjelmistonsa jo hoiti hyvin.

1. 1
   Karsimme laajuuden todelliseen työhön

   Pudotimme ominaisuudet, jotka ratkaisivat ongelmia joita heillä ei ollut, ja pidimme tiiviin listan, jota ilman liiketoiminta ei aidosti pyörisi.
2. 2
   Valitsimme yhden monialustarakennuksen

   Kahden erillisen natiivisovelluksen sijaan yksi monialustasovellus kattoi sekä iPhonen että Androidin — puolittaen suunnilleen ydinkehityksen.
3. 3
   Käytimme hyväksi todettuja suunnittelumalleja

   Siisti, perinteinen käyttöliittymä räätälöidyn sijaan. Asiakkaiden oli helpompi käyttää sitä, ja se nipisti viikkoja aikataulusta.
4. 4
   Yhdistimme, emme korvanneet

   Liitimme sovelluksen toimisto-ohjelmistoon, josta he jo maksoivat, sen uudelleenrakentamisen sijaan. Kallis ’räätälöity hallinta-alusta’ yksinkertaisesti katosi laajuudesta.

Tuloksena oli noin 14 000 euron rakennus, tuotannossa muutamassa kuukaudessa, käyttökuluilla jotka he pystyivät ennustamaan. Se ei ole yhtä laajalle leviävä kuin 60 000 euron versio — eikä sen tarvitse olla. Se tekee sen työn, joka liiketoiminnalla oikeasti oli. Vuotta myöhemmin he ovat lisänneet kaksi pientä ominaisuutta päälle, maksettuna rahalla jonka ensimmäinen versio heille säästi. Siinä koko kaava: aloita todellisesta työstä, ansaitse lisät tuloksilla.

Miten pitää kustannus järkevänä leikkaamatta nurkkia

Räätälöityyn sovellukseen vähemmän käyttäminen ei tarkoita tuntihinnan tinkaamista alas tai halvimman löytyvän tiimin metsästystä. Niin päädyt maksamaan kahdesti. Kyse on harkitsevuudesta laajuuden, järjestyksen ja päätösten kanssa — niiden kolmen asian, jotka aidosti siirtävät lukua. Tässä asuvat todelliset säästöt.

Ensinnäkin, rakenna pienin versio, joka on oikeasti hyödyllinen, ja kasvata sitä sitten. Keskittynyt ensijulkaisu, joka tekee yhden asian hyvin, vie sinut tuotantoon nopeammin, maksaa murto-osan kaiken-yhdessä-unelmasta ja — ratkaisevasti — opettaa sinulle mitä rakentaa seuraavaksi oikeilta asiakkailta arvausten sijaan. Toiseksi, tee päätöksesi ennen kuin rakentaminen alkaa; päättämättömyys on kalleinta, mitä voit projektiin tuoda. Kolmanneksi, yhdistä siihen mitä jo omistat toimivien työkalujen korvaamisen sijaan, ja rakenna jotain uudelleen vain kun se aidosti jarruttaa sinua.

Yleisiä kysymyksiä