Samdyti kūrėją ar kurti su DI? Kaip nuspręsti

Kurkite su DI, kai reikia greitai pirmosios versijos, programėlė daugiausia susideda iš formų, sąrašų, skydelių ir puslapių, ir esate pasiruošę mokytis išbandydami ją patys. Samdykite kūrėją, kai programėlė tvarko pinigus ar jautrius duomenis dideliu mastu, priklauso nuo sudėtingų integracijų arba yra verslas, kurio negalima sugadinti. Daugeliui žmonių geriausias atsakymas – abu: pirmąją versiją sukurkite su DI, įrodykite, kad žmonės ją nori, ir tada pasitelkite kūrėją ją peržiūrėti ir plėsti.

Ką iš tikrųjų duoda kiekvienas variantas

	Kurti su DI programėlių kūrimo įrankiu	Samdyti laisvai samdomą kūrėją	Samdyti agentūrą	Samdyti darbuotoją kūrėją
Greitis iki pirmosios versijos	Greičiausia – dažnai tą pačią dieną paprastoms programėlėms	Dienos iki savaičių	Savaitės iki mėnesių	Priklauso nuo įdarbinimo laiko
Pradinė kaina	Mažiausia – prenumerata ir jūsų laikas	Vidutinė	Didžiausia	Atlyginimas ir įdarbinimo sąnaudos
Jūsų reikiamas laikas	Daug – esate produkto vadovas ir testuotojas	Vidutiniškai – brifingas ir peržiūra	Mažiau – jie valdo projektą	Vidutiniškai – valdymas ir prioritetų nustatymas
Sprendimai dėl architektūros ir saugumo	Apsiriboja tuo, ko prašote ir tikrinate	Priklauso nuo žmogaus	Paprastai komanda su peržiūra	Auga kartu su jūsų produktu
Nuolatiniai pakeitimai	Jūs, bet kada	Mokama už kiekvieną pakeitimą ar abonementu	Mokama už kiekvieną pakeitimą ar abonementu	Įskaityta
Geriausia tinka	MVP, vidiniams įrankiams, svetainėms, prototipams	Aiškiai apibrėžtiems projektams, esamos programėlės plėtimui	Didesniems darbams su dizainu, QA ir projekto valdymu	Produktui, kuris yra jūsų verslo esmė

Čia sąmoningai necituojame įkainių ar atlyginimų: jie labai skiriasi pagal šalį, patirtį ir projektą, o bet koks vienas skaičius klaidintų. Vietoje to gaukite du ar tris pasiūlymus pagal tą patį rašytinį aprašymą. Kiek kainuoja programėlės kūrimas išskaido, kas lemia kainą.

Kada geresnis pasirinkimas – kurti su DI

Testuojate idėją. Tikslas – sužinoti, ar kas nors ją nori, o ne tobulas kodas. Žr. kaip patvirtinti programėlės idėją.
Programėlė daugiausia CRUD. Kurti, skaityti, atnaujinti, trinti: formos, sąrašai, įrašai, skydeliai. DI kūrimo įrankiai tai tvarko gerai.
Daug iteruosite. Persigalvoti kainuoja užklausą, o ne pakeitimo prašymą.
Tai vidinis įrankis. Mažai ir žinomai auditorijai nešlifuoti kraštai nėra problema, o ji pasakys, kas negerai.
Biudžetas ribotas. Geriau išleisti vartotojų pritraukimui, nei programėlės kūrimui.
Norite suprasti savo produktą. Pačiam kuriant matote, kur iš tikrųjų slypi sudėtingumas.

Tai reikalauja iš jūsų: aiškių aprašymų, kantrybės testuojant kiekvieną pakeitimą ir sąžiningumo, kada jau nesate kompetentingi.

Kada geresnis pasirinkimas – samdyti kūrėją

Mokėjimai, pinigų judėjimas ar finansiniai įrašai – viršijantys standartinį atsiskaitymą.
Jautrūs duomenys – sveikata, vaikų duomenys, valstybės asmens dokumentų numeriai – kai klaidos turi teisinių pasekmių.
Sudėtingos integracijos su senesnėmis sistemomis, neįprastomis API ar duomenimis, kurie turi būti tiksliai sinchronizuoti.
Našumas ir mastas – sunkios realaus laiko funkcijos, dideli duomenų apdorojimai, daug srauto.
Natyvios mobiliosios programėlės App Store ir Google Play, jei reaguojanti žiniatinklio programėlė neužtenka.
Programėlė jau yra jūsų verslas. Mokantys klientai daro prastovą ir duomenų praradimą brangiais.
Neturite laiko. Kūrimas su DI vis tiek reikalauja valandų jūsų dėmesio; jei negalite jų skirti, samdykite ką nors, kas gali.

Hibridinis kelias: kurti su DI, tada samdyti

Tai vis dažniau pasitaikantis ir dažnai protingiausias kelias:

Užsirašykite, ką kuriate. Trumpa specifikacija pagerina viską, kas vyksta po to. Kaip parašyti produkto reikalavimų dokumentą su DI pateikia šabloną.
Sukurkite pirmąją versiją su DI. Laikykite ją mažą: vienas srautas, kuris įrodo idėją.
Parodykite ją tikriems vartotojams. Sužinokite, kas svarbu, prieš leisdami daugiau.
Eksportuokite kodą arba prijunkite jį prie GitHub. Kūrėjui reikia tikro kodo, o ne ekrano nuotraukų.
Pirmiausia samdykite kūrėją peržiūrai. Fiksuota, maža užduotis: peržiūrėti saugumą, duomenų tvarkymą ir struktūrą bei išvardyti, ką jie pakeistų.
Nuspręskite pagal jų išvadas. Sustiprinkite ir plėskite esamą kodą arba perkurkite dalis, kurios neatlaikys mastelio.

Peržiūros žingsnis svarbus. Tai mažos rizikos būdas įvertinti kūrėjo darbą prieš įsipareigojant daugiau, ir sąžiningai parodo, kiek tvirta jūsų DI sukurta versija. Kaip DI prototipą perkelti į gamybą aprašo, kas paprastai reikalauja dėmesio.

Jei samdote: kaip tai padaryti gerai

Pasiruoškite prieš kalbėdami su bet kuo

Rašytinis aprašymas: vartotojai, pagrindinės funkcijos, kas neįeina į apimtį, duomenys, leidimai.
Programėlių pavyzdžiai, kurie jums patinka, ir kodėl.
Apytikslis biudžeto intervalas ir terminas.
Jūsų veikiantis prototipas, jei turite – jis dažnai aiškesnis nei bet koks dokumentas.

Ką patikrinti

Atitinkami darbai, kuriuos galite peržiūrėti. Veikiančios programėlės, ne tik ekrano nuotraukos.
Kaip jie bendrauja. Ar uždavinėja gerus klausimus apie jūsų vartotojus, ar tik apie technologijas?
Rašytinė sąmata, pririšta prie apimties, su tuo, kas nutinka, kai apimtis keičiasi.
Nuosavybė. Sutartyje turi būti nurodyta, kad kodas priklauso jums, o paskyros (talpinimas, domenas, duomenų bazė, mokėjimų tiekėjas) yra įregistruotos jūsų vardu.
Perdavimas. Dokumentacija, prieiga prie saugyklos ir kaip paleisti programėlę be jų.
Po paleidimo. Kas taiso klaidas, kiek laiko ir už kiek.

Pradėkite mažai

Maža apmokama bandomoji užduotis – peržiūra, viena funkcija, klaidos taisymas – pasako daugiau nei bet koks pokalbis. Tai teisingiau abiem pusėms nei didelis fiksuotos kainos projektas su nepažįstamu žmogumi.

Jei kuriate su DI: kaip tai padaryti gerai

Aprašykite produktą, o ne kodą. Vartotojai, srautai, duomenys, leidimai. Žr. kaip rašyti užklausas DI programėlių kūrimo įrankiams.
Vienas pakeitimas vienu metu, išbandytas prieš kitą.
Naudokite kontrolinius taškus, kad blogą pakeitimą būtų galima atšaukti.
Rimtai žiūrėkite į saugumą: prisijungimas prie kiekvieno privataus puslapio, vartotojai mato tik savo duomenis, paslaptys – ne kode.
Palikite išėjimo galimybę. Pasirinkite įrankį, leidžiantį eksportuoti kodą ar sinchronizuoti jį su Git saugykla, kad kūrėjas vėliau galėtų jį perimti.
Žinokite savo ribas. Jei tą patį pataisymą prašėte tris kartus ir jis vis dar sugedęs, gal laikas, kad į tai pažiūrėtų kūrėjas.

Įspėjimo ženklai abiejuose keliuose

Kai kurie signalai rodo, kad pasirinktas kelias neveikia.

Kūrimas su DI neveikia, jei…

Ta pati klaida grįžta po kelių bandymų ją ištaisyti.
Negalite nustatyti, ar tai saugu. Nežinote, kas gali matyti kokius duomenis, ir negalite patikrinti.
Kiekvienas pakeitimas sugadina ką nors kita. Programėlė išaugo taip, kaip niekas nenumatė.
Daugiau laiko leidžiate taisymui, nei mokymuisi iš vartotojų. Kurti greitai reikėjo mokytis; jei tai nutrūko, persvarstykite.

Nė vienas iš šių dalykų nereiškia, kad reikia pradėti iš naujo. Dažniausiai tai reiškia, kad laikas kūrėjui peržiūrėti, ką turite.

Samdymas neveikia, jei…

Negalite matyti progreso. Po pirmojo sutarto etapo nėra veikiančios versijos, kurią galėtumėte išbandyti.
Sąmatos nuolat auga be apimties pasikeitimo.
Paskyros ir kodas nėra jūsų vardu. Tai ištaisykite nedelsdami, kas bebūtų.
Nesuprantate, už ką mokate, o į klausimus gaunate neaiškius atsakymus.

Geras kūrėjas mielai anksti rodo darbą, paprasta kalba paaiškina kompromisus ir užtikrina, kad galėtumėte tęsti be jo.

Greitas sprendimo vadovas

Jūsų situacija	Siūlomas kelias
Testuojate idėją, nėra biudžeto kūrėjui	Kurti su DI
Vidinis įrankis jūsų komandai	Kurti su DI; kūrėjo peržiūra, jei laikomi jautrūs duomenys
Rinkodaros svetainė ar portfelis	Kurti su DI arba svetainių kūrimo įrankiu
SaaS MVP, kad rastumėte pirmuosius mokančius klientus	Kurti su DI, tada kūrėjo peržiūra prieš plėtimą
Tvarko mokėjimus, sveikatos ar finansinius įrašus dideliu mastu	Samdyti kūrėją (DI vis tiek gali pagreitinti jo darbą)
Reikalinga natyvi iOS/Android programėlė	Samdyti kūrėją arba įrankį, palaikantį natyvius kūrinius
Esamas produktas su klientais, reikia didelių pakeitimų	Samdyti kūrėją
Neturite laiko patys testuoti ir iteruoti	Samdyti

Pirmosios versijos kūrimas su Mythex

Mythex yra DI programėlių kūrimo įrankis keliui „pirmiausia pasidaryk pats“: aprašote programėlę, ji rašo ir paleidžia kodą gyvoje peržiūroje, prireikus prideda duomenų bazę ir publikuoja į tikrą URL. Ji kuria žiniatinklio programėles, veikiančias telefonuose, o Pro plane gali jas apgaubti kaip Android ir iPhone programėles, skirtas Google Play ir TestFlight. Kai būsite pasiruošę pasitelkti kūrėją, Pro plane galite eksportuoti projektą arba sinchronizuoti jį su savo GitHub saugykla (GitHub ir eksportas), o pilnas kodo redaktorius reiškia, kad kūrėjas gali dirbti tiesiogiai projekte. Ką įtraukia kiekvienas planas, žr. kainų puslapyje.

Klausimai

Ar DI gali pakeisti kūrėją?

Daugeliui pirmųjų versijų – svetainėms, vidiniams įrankiams, skydeliams, paprastiems SaaS MVP – DI programėlių kūrimo įrankiai leidžia ne kūrėjams sukurti veikiančią programinę įrangą. Jie nepakeičia kūrėjo sprendimų apie architektūrą, saugumą, našumą ir sudėtingas integracijas, kurie tampa svarbesni, kai programėlė auga.

Ar turėčiau kurti savo MVP su DI, o kūrėją samdyti vėliau?

Dažnai – taip. Pirmąją versiją sukūrus su DI, idėją galima pigiai išbandyti su tikrais vartotojais. Jei ji veikia ir auga, kūrėjas gali ją peržiūrėti, sustiprinti ir plėsti – tik jei galite eksportuoti kodą arba jis yra Git saugykloje.

Ko ieškoti samdant kūrėją?

Atitinkamų ankstesnių darbų, kuriuos galite peržiūrėti, aiškaus bendravimo, rašytinės sąmatos, pririštos prie apimties, susitarimo, kad kodas ir paskyros priklauso jums, ir plano, kas vyksta po paleidimo. Prieš pasirašydami didelį projektą, pradėkite nuo mažos apmokamos užduoties.

Kada tikrai verta samdyti kūrėją?

Kai programėlė apdoroja mokėjimus didelėmis apimtimis, jautrius asmens ar sveikatos duomenis, sudėtingas integracijas, griežtą atitiktį reikalavimams ar didelį srautą – arba kai programėlė jau uždirba pinigus, o prastova yra brangi. Kūrėjas taip pat verta saugumo peržiūros prieš paleidimą.