Palkkaanko kehittäjän vai rakennatko tekoälyllä? Näin päätät

Rakenna tekoälyllä, kun tarvitset ensimmäisen version nopeasti, sovellus koostuu pääosin lomakkeista, listoista, paneeleista ja sivuista, ja olet valmis oppimaan testaamalla itse. Palkkaa kehittäjä, kun sovellus käsittelee rahaa tai arkaluonteisia tietoja suuressa mittakaavassa, nojaa monimutkaisiin integraatioihin tai on jo liiketoiminta, jota ei voi rikkoa. Monille paras vastaus on molemmat: rakenna ensimmäinen versio tekoälyllä, osoita että ihmiset haluavat sitä, ja tuo sitten kehittäjä tarkistamaan ja laajentamaan sitä.

Mitä kukin vaihtoehto todella antaa

Emme tarkoituksella ilmoita tässä hintoja tai palkkoja: ne vaihtelevat paljon maassa, kokemuksessa ja projektissa, eikä yksikään luku antaisi oikeaa kuvaa. Hanki sen sijaan kaksi tai kolme tarjousta samasta kirjallisesta laajuudesta. Paljonko sovelluksen rakentaminen maksaa erittelee hintaan vaikuttavat tekijät.

Milloin tekoälyllä rakentaminen on parempi valinta

• Testaat ideaa. Tavoitteena on oppia, haluaako joku sitä, ei täydellistä koodia. Katso miten sovellusidea validoidaan.
• Sovellus on pääosin CRUD-tyyppinen. Luo, lue, päivitä, poista: lomakkeet, listat, tietueet, paneelit. Tekoälysovellusrakentajat hoitavat nämä hyvin.
• Iteroit paljon. Mielen muuttaminen maksaa yhden kehotteen, ei muutospyyntöä.
• Kyse on sisäisestä työkalusta. Pieni, tunnettu käyttäjäkunta antaa anteeksi karheuden ja kertoo, mikä on vialla.
• Budjetti on tiukka. Mieluummin käytät rahaa käyttäjien hankintaan kuin rakentamiseen.
• Haluat ymmärtää tuotteesi. Rakentaminen itse opettaa, missä monimutkaisuus todella on.

Se vaatii sinulta selkeitä kuvauksia, kärsivällisyyttä testata jokainen muutos ja rehellisyyttä siitä, milloin olet oman osaamisesi ulkopuolella.

Milloin kehittäjän palkkaaminen on parempi valinta

• Maksut, rahan siirrot tai taloustiedot vakiomaksua laajemmin.
• Arkaluonteiset tiedot, kuten terveystiedot, lasten tiedot tai henkilötunnukset, joissa virheillä on oikeudellisia seurauksia.
• Monimutkaiset integraatiot vanhoihin järjestelmiin, epätavallisiin rajapintoihin tai dataan, jonka on pysyttävä täsmällisesti synkronassa.
• Suorituskyky ja skaalautuvuus: raskaat reaaliaikaominaisuudet, suuret datamäärät, paljon liikennettä.
• Natiivit mobiilisovellukset App Storeen ja Google Play -kauppaan, jos responsiivinen verkkosovellus ei riitä.
• Sovellus on jo liiketoimintasi. Maksavat asiakkaat tekevät katkoista ja tietojen menetyksistä kalliita.
• Sinulla ei ole aikaa. Tekoälyllä rakentaminen vie silti tuntikausia huomiotasi; jos et voi antaa sitä, maksa jollekulle, joka voi.

Hybridireitti: rakenna tekoälyllä, sitten palkkaa

Tämä on yhä yleisempää, ja se on usein järkevin reitti:

1. Kirjoita muistiin, mitä rakennat. Lyhyt speksi parantaa kaikkea sen jälkeen. Miten PRD kirjoitetaan tekoälyn avulla sisältää pohjan.
2. Rakenna ensimmäinen versio tekoälyllä. Pidä se pienenä: yksi kulku, joka todistaa idean.
3. Vie se oikeiden käyttäjien eteen. Opi, mikä on tärkeää, ennen kuin käytät lisää rahaa.
4. Vie koodi ulos tai yhdistä se GitHubiin. Kehittäjä tarvitsee oikean koodin, ei kuvakaappauksia.
5. Palkkaa ensin kehittäjä katselmoimaan. Kiinteä, pieni tehtävä: tarkista tietoturva, datan käsittely ja rakenne sekä listaa, mitä hän muuttaisi.
6. Päätä hänen havaintojensa perusteella. Vahvista ja laajenna olemassa olevaa koodia tai rakenna uudelleen ne osat, jotka eivät skaalaudu.

Katselmointivaihe on tärkeä. Se on matalan riskin tapa arvioida kehittäjän työtä ennen kuin sitoudut lisää, ja se kertoo rehellisesti, kuinka vankka tekoälyllä rakennettu versiosi on. Miten tekoälyprototyyppi viedään tuotantoon kertoo, mihin yleensä kannattaa kiinnittää huomiota.

Jos palkkaat: näin teet sen hyvin

Valmistele ennen kuin puhut kenellekään

• Kirjallinen laajuus: käyttäjät, ydinominaisuudet, mikä on rajauksen ulkopuolella, data, oikeudet.
• Esimerkkejä sovelluksista, joista pidät, ja miksi.
• Karkea budjettihaarukka ja aikataulu.
• Toimiva prototyyppi, jos sinulla on sellainen; se on usein selkeämpi kuin mikään dokumentti.

Mitä tarkistaa

• Aiempaa työtä, jota voit käyttää. Käytössä olevia sovelluksia, ei pelkkiä kuvakaappauksia.
• Miten he viestivät. Kysyvätkö he hyviä kysymyksiä käyttäjistäsi vai pelkästään teknologiasta?
• Kirjallinen arvio, joka on sidottu laajuuteen, ja tieto siitä, mitä tapahtuu, kun laajuus muuttuu.
• Omistajuus. Sopimuksen pitää kertoa, että omistat koodin, ja tilit (hosting, domain, tietokanta, maksupalvelu) ovat nimissäsi.
• Luovutus. Dokumentaatio, pääsy repositorioon ja ohjeet sovelluksen ajamiseen ilman heitä.
• Julkaisun jälkeen. Kuka korjaa bugeja, kuinka kauan ja mihin hintaan.

Aloita pienesti

Pieni maksullinen kokeilutehtävä (katselmointi, yksi ominaisuus, bugikorjaus) kertoo enemmän kuin mikään haastattelu. Se on oikeudenmukaisempi molemmille osapuolille kuin suuri kiinteän hinnan projekti tuntemattoman kanssa.

Jos rakennat tekoälyllä: näin teet sen hyvin

• Kuvaile tuote, älä koodia. Käyttäjät, kulut, data, oikeudet. Katso miten kehotteita kirjoitetaan tekoälysovellusrakentajille.
• Yksi muutos kerrallaan, testattuna ennen seuraavaa.
• Käytä tallennuspisteitä, jotta huonon muutoksen voi perua.
• Ota tietoturva vakavasti: kirjautuminen jokaiselle yksityiselle sivulle, käyttäjät näkevät vain omat tietonsa, salaisuudet poissa koodista.
• Pidä poistumistie auki. Valitse työkalu, jolla voit viedä koodin ulos tai synkronoida sen Git-repoon, jotta kehittäjä voi jatkaa myöhemmin.
• Tunne rajasi. Jos olet pyytänyt saman korjauksen kolme kertaa ja se on yhä rikki, on aika pyytää kehittäjän silmiä katsomaan.

Varoitusmerkit kummallakin reitillä

Jotkin merkit kertovat, ettei valitsemasi reitti toimi.

Tekoälyllä rakentaminen ei toimi, jos…

• Sama bugi palaa, vaikka olet yrittänyt korjata sen useita kertoja.
• Et pysty sanomaan, onko se turvallinen. Et tiedä, kuka näkee mitäkin dataa, etkä pysty tarkistamaan sitä.
• Jokainen muutos rikkoo jotain muuta. Sovellus on kasvanut tavoilla, joita kukaan ei suunnitellut.
• Käytät enemmän aikaa korjaamiseen kuin oppimiseen käyttäjistä. Nopean rakentamisen tarkoitus oli oppia; jos se on loppunut, harkitse uudelleen.

Mikään näistä ei tarkoita aloittamista alusta. Yleensä se tarkoittaa, että on aika pyytää kehittäjää katselmoimaan, mitä sinulla on.

Palkkaaminen ei toimi, jos…

• Et näe edistymistä. Ei toimivaa versiota, jota voi klikata, sovitun ensimmäisen virstanpylvään jälkeen.
• Arviot kasvavat koko ajan ilman, että laajuus on muuttunut.
• Tilit ja koodi eivät ole nimissäsi. Korjaa tämä heti, mitä muuta tapahtuukin.
• Et ymmärrä, mistä maksat, ja kysymyksiin tulee epämääräisiä vastauksia.

Hyvä kehittäjä näyttää työnsä mielellään varhain, selittää kompromissit selkeästi ja varmistaa, että voisit jatkaa ilman häntä.

Pikaopas päätökseen

Ensimmäisen version rakentaminen Mythexillä

Mythex on tekoälysovellusrakentaja reittiin ”rakenna itse ensin”: kuvailet sovelluksen, se kirjoittaa ja ajaa koodin elävässä esikatselussa, lisää tietokannan tarvittaessa ja julkaisee oikeaan osoitteeseen. Se rakentaa mobiiliystävällisiä verkkosovelluksia, ja Pro-tasolla ne voi kääriä Android- ja iPhone-sovelluksiksi Google Playta ja TestFlightia varten. Kun olet valmis tuomaan kehittäjän mukaan, Pro-tasolla voit viedä projektin ulos tai synkronoida sen omaan GitHub-repoosi (GitHub ja vienti), ja täysi koodieditori mahdollistaa sen, että kehittäjä voi työskennellä suoraan projektissa. Katso hinnoittelusivu, mitä kukin tilaus sisältää.

Kysymykset