Vai pieņemt darbā izstrādātāju vai veidot ar MI? Kā izlemt

Veidojiet ar MI, kad vajag ātri pirmo versiju, lietotne galvenokārt sastāv no veidlapām, sarakstiem, paneļiem un lapām, un esat gatavs mācīties, to pārbaudot pats. Pieņemiet darbā izstrādātāju, kad lietotne lielā apjomā apstrādā naudu vai sensitīvus datus, paļaujas uz sarežģītām integrācijām vai jau ir bizness, kas nevar atļauties sabojāties. Daudziem labākā atbilde ir abas: veidojiet pirmo versiju ar MI, pierādiet, ka cilvēki to vēlas, un tad piesaistiet izstrādātāju, lai to pārskatītu un paplašinātu.

Ko katra iespēja patiesībā dod

Šeit apzinājies neminam likmes vai algas: tās ļoti atšķiras atkarībā no valsts, pieredzes un projekta, un jebkurš viens skaitlis maldinātu. Labāk saņemiet divus vai trīs piedāvājumus pret vienu un to pašu rakstisku darba apjomu. Cik maksā lietotnes izveide izskaidro, kas nosaka cenu.

Kad veidot ar MI ir labākā izvēle

• Testējat ideju. Mērķis ir uzzināt, vai kāds to vēlas, nevis ideāls kods. Skatiet kā validēt lietotnes ideju.
• Lietotne galvenokārt ir CRUD. Izveidot, lasīt, atjaunināt, dzēst: veidlapas, saraksti, ieraksti, paneļi. MI veidotāji šos labi apstrādā.
• Daudz iterēsiet. Mainīt domas maksā vienu uzvedni, nevis izmaiņu pieprasījumu.
• Tas ir iekšējs rīks. Neliela, zināma auditorija piedod raupjas malas un pastāsta, kas nav kārtībā.
• Budžets ir ierobežots. Labāk tērēt lietotāju piesaistei nekā veidošanai.
• Vēlaties saprast savu produktu. Ja to veidojat pats, redzat, kur patiesībā ir sarežģītība.

Tas no jums prasa: skaidrus aprakstus, pacietību, testējot katru izmaiņu, un godīgumu, kad jūs nezināt, ko darāt.

Kad izstrādātāja pieņemšana darbā ir labākā izvēle

• Maksājumi, naudas pārvedumi vai finanšu ieraksti ārpus standarta norēķina.
• Sensitīvi dati — veselība, bērnu dati, valsts identifikatori — kur kļūdām ir juridiskas sekas.
• Sarežģītas integrācijas ar vecām sistēmām, neparastām API vai datiem, kuriem jāpaliek precīzi sinhronizētiem.
• Veiktspēja un mērogs — smagas reāllaika funkcijas, lielu datu apstrāde, liela trafika.
• Vietējas mobilās lietotnes App Store un Google Play, ja reaģējoša tīmekļa lietotne nepietiks.
• Lietotne jau ir jūsu bizness. Maksājoši klienti padara dīkstāvi un datu zudumu dārgu.
• Jums nav laika. Veidošana ar MI joprojām prasa stundas jūsu uzmanības; ja nevarat tās dot, samaksājiet kādam, kas var.

Hibrīdais ceļš: veidot ar MI, tad pieņemt darbā

Tas kļūst arvien izplatītāk un bieži ir saprātīgākais ceļš:

1. Pierakstiet, ko veidojat. Īsa specifikācija padara visu pēc tam labāku. Kā rakstīt PRD ar MI ietver sagatavi.
2. Veidojiet pirmo versiju ar MI. Turiet to mazu: vienu plūsmu, kas pierāda ideju.
3. Parādiet to reāliem lietotājiem. Uzziniet, kas ir svarīgs, pirms tērējat vairāk.
4. Eksportējiet kodu vai savienojiet to ar GitHub. Izstrādātājam vajag reālo kodu, nevis ekrānuzņēmumus.
5. Vispirms pieņemiet izstrādātāju pārskatīšanai. Fiksēts, mazs uzdevums: pārskatīt drošību, datu apstrādi un struktūru un uzskaitīt, ko viņš mainītu.
6. Lemiet pēc viņa secinājumiem. Nostipriniet un paplašiniet esošo kodu vai pārbūvējiet daļas, kas neizturēs mērogu.

Pārskatīšanas solis ir svarīgs. Tas ir zema riska veids, kā novērtēt izstrādātāja darbu, pirms apņematies vairāk, un godīgi parāda, cik stabila ir jūsu ar MI veidotā versija. Kā ar MI prototipu nogādāt ražošanā aptver to, kam parasti jāpievērš uzmanība.

Ja pieņemat darbā: kā to izdarīt labi

Sagatavojieties pirms sarunas ar kādu

• Rakstisks darba apjoms: lietotāji, galvenās funkcijas, kas nav iekļauts, dati, atļaujas.
• Lietotņu piemēri, kas jums patīk, un kāpēc.
• Aptuvens budžeta diapazons un termiņš.
• Jūsu darbojošs prototips, ja tāds ir — tas bieži ir skaidrāks par jebkuru dokumentu.

Ko pārbaudīt

• Attiecīgs darbs, ko varat izmantot. Dzīvas lietotnes, nevis tikai ekrānuzņēmumi.
• Kā viņi sazinās. Vai viņi uzdod labus jautājumus par jūsu lietotājiem, vai tikai par tehnoloģijām?
• Rakstisks cenu piedāvājums, kas saistīts ar darba apjomu, ar to, kas notiek, ja darba apjoms mainās.
• Īpašumtiesības. Līgumā jābūt norādītam, ka kods pieder jums, un konti (hosting, domēns, datubāze, maksājumu pakalpojumu sniedzējs) ir uz jūsu vārda.
• Nodošana. Dokumentācija, piekļuve repozitorijam un tas, kā palaist lietotni bez viņiem.
• Pēc palaišanas. Kas labo kļūdas, cik ilgi un par kādu cenu.

Sāciet nelielu

Neliels apmaksāts izmēģinājuma uzdevums — pārskatīšana, viena funkcija, kļūdas labojums — pastāsta vairāk nekā jebkura intervija. Tas ir godīgāks abām pusēm nekā liels fiksētas cenas projekts ar svešinieku.

Ja veidojat ar MI: kā to izdarīt labi

• Aprakstiet produktu, nevis kodu. Lietotāji, plūsmas, dati, atļaujas. Skatiet kā rakstīt uzvednes MI lietotņu veidotājiem.
• Viena izmaiņa vienlaikus, pārbaudot pirms nākamās.
• Izmantojiet kontrolpunktus, lai slikta izmaiņa varētu tikt atcelta.
• Ņemiet drošību nopietni: pieteikšanās katrā privātā lapā, lietotāji redz tikai savus datus, noslēpumi ārpus koda.
• Atstājiet izeju atvērtu. Izvēlieties rīku, kas ļauj eksportēt kodu vai sinhronizēt to ar Git repozitoriju, lai izstrādātājs vēlāk to varētu pārņemt.
• Zinājiet savas robežas. Ja esat lūdzis to pašu labojumu trīs reizes un tas joprojām nedarbojas, varbūt ir laiks izstrādātāja skatienam.

Brīdinājuma zīmes jebkurā ceļā

Dažas pazīmes parāda, ka izvēlētais ceļš nedarbojas.

Veidošana ar MI nedarbojas, ja…

• Tā pati kļūda atgriežas pēc vairākiem mēģinājumiem to labot.
• Nevarat pateikt, vai tā ir droša. Nezināt, kas redz kādus datus, un nevarat to pārbaudīt.
• Katra izmaiņa kaut ko salauž. Lietotne ir izaugusi veidos, ko neviens nebija plānojis.
• Vairāk laika tērējat labošanai nekā mācīšanās no lietotājiem. Ātrās veidošanas mērķis bija mācīties; ja tas apstājies, pārdomājiet.

Neviens no šiem nenozīmē sākt no nulles. Parasti tas nozīmē, ka ir laiks izstrādātājam pārskatīt to, kas jums ir.

Pieņemšana darbā nedarbojas, ja…

• Jūs nevarat redzēt progresu. Nav darbojošas versijas, ko pārlūkot pēc pirmā vienotā posma.
• Tāmes turpina augt bez darba apjoma izmaiņām.
• Konti un kods nav uz jūsu vārda. Labojiet to nekavējoties, lai kas arī notiktu.
• Nesaprotat, par ko maksājat, un uz jautājumiem saņemat neskaidras atbildes.

Labs izstrādātājs labprāt agri parāda darbu, skaidri izskaidro kompromisus un nodrošina, ka varētu turpināt bez viņa.

Ātrs lēmumu ceļvedis

Pirmās versijas veidošana ar Mythex

Mythex ir MI lietotņu veidotājs ceļam "vispirms veido pats": jūs aprakstāt lietotni, tas raksta un palaiž kodu tiešraides priekšskatījumā, pēc vajadzības pievieno datubāzi un publicē uz reālu URL. Tas veido tīmekļa lietotnes, kas darbojas tālruņos, un Pro plānā var tās ietīt kā Android un iPhone lietotnes Google Play un TestFlight vajadzībām. Kad esat gatavs piesaistīt izstrādātāju, Pro ļauj eksportēt projektu vai sinhronizēt to ar savu GitHub repozitoriju (GitHub un eksports), un pilnais koda redaktors nozīmē, ka izstrādātājs var strādāt tieši projektā. Skatiet cenu lapu, lai uzzinātu, ko iekļauj katrs plāns.

Jautājumi