Hogyan bérelj fel szabadúszó fejlesztőt

A legtöbb sikertelen fejlesztési projektet nem rosszul kódolták. Rosszul specifikálták, rossz jel alapján vettek fel embereket, és olyan hiányosan adták át, hogy a következő fejlesztőnek elölről kellett kezdenie. A technikai rész ritkán az, ahol a pénz eltűnik.

Ez jó hír egy nem technikai vásárló számára, mert azt jelenti, hogy a legfontosabb döntéseket te is meghozhatod. Nem kell valaki JavaScript tudását felmérned ahhoz, hogy jól válassz. Képesnek kell lenned pontosan leírni a problémát, felismerni a releváns bizonyítékokat, olyan kérdéseket feltenni, amikre nehéz blöffölni, és ragaszkodni egy olyan átadáshoz, ami után nálad maradnak a kulcsok. Ez az útmutató mind a négyet végigvezeti.

Döntsd el, mit építesz valójában

Kezdd az eredménnyel, ne a technológiával. Szükségem van egy alkalmazásra” nem egy brief; az ügyfeleknek foglalniuk és fizetniük kell egy időpontot a telefonjukon, és látnom kell a holnapi foglalásokat egy listában” az. A második verzióra lehet árajánlatot kérni, tesztelni és vitatkozni róla. Az elsőre nem.

Mielőtt bárkivel beszélnél, írj le négy dolgot:

• Az elvégzendő munkaMit kellene tudnia egy felhasználónak megtenni, amit ma még nem tud. Egy mondat képességenként, a felhasználó nyelvén, nem technikai nyelven.
• A kötelező elemekAz a néhány dolog, ami nélkül az építés értelmetlen. Ha a listád hatnál több elemet tartalmaz, az egy kívánságlista, nem egy specifikáció.
• Mi létezik márJelenlegi oldal, tárhely, domain, fizetési szolgáltató, CRM, táblázatok. Minden integráció munka, és a be nem jelentett integrációk azok, ahol a becslések elromlanak.
• Ki tartja karbanA szoftver nem vásárlás, hanem elkötelezettség. Döntsd el most, hogy megtartod-e a fejlesztőt, felveszel-e valaki mást, vagy magad kezeled.

Egy hasznos elv: az első verziót a legkisebb, valóban hasznos dologként írd le. Minden más egy második listára kerül. A fejlesztők az első listára adnak árajánlatot; a második listát akkor finanszírozod, ha az első már bevételt termel.

Milyen fejlesztőre van szükséged

A fejlesztő” tucatnyi különálló szakmát takar, amelyek nem felcserélhetők. A rossz kiválasztása a leggyakoribb és legdrágább kategóriahiba ebben a folyamatban.

• Front-endAmit a felhasználó lát és érint: elrendezés, interakció, reszponzivitás, hozzáférhetőség. Újratervezéshez, marketing oldalhoz vagy egy meglévő rendszer új felületéhez bérelj fel. Lásd front-end fejlesztő szabadúszók.
• Back-endAdatok, logika, API-k, hitelesítés, fizetések. Akkor bérelj, ha az érték abban rejlik, ami a gomb megnyomása után történik. Lásd back-end fejlesztő szabadúszók.
• Full-stackMindkettő, működőképes szinten. A legtöbb kis építéshez ez a megfelelő választás, mert két specialista közötti koordináció többe kerül, mint amennyit megtakarít kis méretben.
• CMS és platformWordPress, Shopify, Webflow és hasonlók. Ha az igényedet egy meglévő platform kielégíti, egy egyedi fejlesztő felvétele a rendszer újraépítésére pénzkidobás. Lásd WordPress fejlesztés és Shopify fejlesztés.
• MobilNatív iOS vagy Android, vagy cross-platform. Egy valóban más diszciplína, mint a web, saját alkalmazásbolt-felülvizsgálati és kiadási korlátozásokkal. Lásd mobilalkalmazás-fejlesztés.
• Karbantartás és javításokHibakeresés, frissítések, teljesítmény, biztonság. Gyakran a legértékesebb felvétel, és az, amit a vásárlók a leghosszabb ideig halogatnak. Lásd weboldal karbantartás.

Ha tényleg nem tudod megmondani, melyikre van szükséged, az maga egy kis, olcsó, jól meghatározott feladat: fizess egy tapasztalt fejlesztőnek egy rövid egyeztetésért, mielőtt bármit is megrendelnél.

A technológia kiválasztása a személy előtt

Nem kell kiválasztanod a nyelvet. Egy döntést azonban meg kell hoznod: platform vagy egyedi. Ennek van a legnagyobb hatása a teljes költségedre, mint bármely más választásnak ebben az útmutatóban.

Egy platform alapú építés – WordPress, Shopify, Webflow, egy no-code eszköz – azt jelenti, hogy a szoftver nagy része már létezik, és te a konfigurációért, a tervezésért és a rád jellemző részekért fizetsz. Gyorsabb, olcsóbb és könnyebben átadható a következő személynek, mert több ezer fejlesztő ismeri. A korlát az, hogy a platform feltételezésein belül élsz.

Az egyedi építés azt jelenti, hogy a szoftvert neked írják. Pontosan illeszkedik, és többször annyiba kerül a létrehozása és karbantartása, mert csak az ismeri, aki írta, amíg le nem dokumentálja. Az egyedi a helyes válasz, ha az, amit csinálsz, maga a termék; rossz válasz egy bemutató oldalhoz vagy egy standard üzlethez.

Két gyakorlati szabály. Először is, ha egy mainstream platform kielégíti az igényeid nyolcvan százalékát, kezdd ott, és fizess a hiányzó húszért. Másodszor, bármit is választanak, kérdezd meg, miért – egy fejlesztő, aki nem tudja elmagyarázni a választást az igényeid szempontjából, azt választja, amit szeret, nem azt, amire szükséged van. Ha egy teljes weboldal építését fontolgatod, a weboldal költség útmutatónk bemutatja a sávokat.

Rövid, árajánlatkérésre alkalmas fejlesztői leírás írása

Egy jó műszaki leírás rövid és konkrét. Nem azt mondja meg a fejlesztőnek, hogyan építse meg, hanem azt, hogy mi legyen igaz, amikor elkészült.

• A probléma, egy bekezdésben. Mi történik most, és miért nem elfogadható.
• A felhasználói történetek. Ügyfélként tudok… azért, hogy…”. Öt-tizenöt ilyen már egy valós specifikáció.
• Az integrációk. Nevezzen meg minden külső rendszert név szerint, beleértve azokat is, amelyeket triviálisnak tart.
• Amit Ön biztosít. Szöveg, képek, tervek, bejelentkezési adatok, tesztadatok. A be nem jelentett hiányosságok számlázható órákká válnak.
• Korlátok. Határidő, költségvetési tartomány, kötelező tárhely, teljesítendő megfelelőségi előírások.
• A kész definíciója. Hol telepítve, hogyan tesztelve, milyen szinten dokumentálva, mivel átadva.

Adjon meg egy költségvetési tartományt. A vevők visszatartják, remélve, hogy alacsonyabb árajánlatot kapnak; a gyakorlatban ez csak a rossz méretű javaslatokat eredményezi, és egy levelezési kört elveszít, mire rájön. Útmutatónk a nagyszerű javaslatokat eredményező projektleírás írásához egy teljesebb sablont tartalmaz, és a órabér vs. fix ár elmagyarázza, hogy melyik árazási modellt kéri a leírása.

Rövid lista összeállítása

Célozzon meg három-öt jelöltet. Kevesebb esetén nincs összehasonlítás; több esetén egyiket sem fogja megfelelően értékelni.

Két irányból lehet keresni. Kezdje a munkával, ha a feladata jól meghatározott, és valami konkrétat szeretne vásárolni – böngésszen fix áras hirdetéseket a weboldalfejlesztés, szoftverfejlesztés vagy webalkalmazások kategóriában, vagy piactér szerint a webdesign, WordPress fejlesztők, mobilalkalmazás-fejlesztés vagy Shopify szakértők között.

Kezdje a személlyel, ha a munka megbeszélést igényel. Böngésszen fejlesztőket szakterület vagy eszköz szerint – React, WordPress, PHP, Python vagy Webflow – vagy tegye közzé a leírást, és várja a javaslatokat. A Zinn Hubon ingyenes a projekt közzététele, és irányíthatja egy adott területre, például weboldalfejlesztésre, back-end fejlesztésre vagy mobilalkalmazás-fejlesztésre.

Szűrje erősen a relevanciára, és enyhén minden másra. Egy fejlesztő, aki három, az Önéhez hasonló dolgot szállított, szinte mindig jobb, mint az, akinek kétszer annyi tapasztalata van egy másik területen.

Hogyan olvassunk egy fejlesztői portfóliót

Nem tudja ellenőrizni valaki kódját, és nem is kell. Egy portfólió mégis sokat elárul, ha tudja, mit kell nézni.

• Nyissa meg az élő linkeket. Egy képernyőfelvétel semmit sem bizonyít. Töltse be az oldalt a telefonján, használja, törje össze. Ami ma elromlott, azt elromlottként hagyták jóvá.
• Keressen az Önéhez hasonló problémákat. Nem ugyanazt az iparágat – ugyanazt a formát. Egy foglalási folyamat foglalási folyamat, akár hajvágást, akár helikoptert ad el.
• Ellenőrizze, mit csináltak. Csapatprojekteknél kérdezze meg, mely részek voltak az övék. Az én dolgoztam rajta” jelenthet sokat vagy nagyon keveset.
• Tesztelje le az alapokat maga. Gyorsan betöltődik az oldal? Működik telefonon? Használhatók a űrlapok billentyűzettel? Ezek olyan szakmai jelek, amelyeket egy nem műszaki vásárló is tökéletesen el tud olvasni.
• Olvassa el a véleményeket, mint bizonyítékot. Egy ragyogó vélemény zaj. Sok véleményben megjelenő minta, különösen a kommunikációról és a határidőkről, jelzés. A Zinn Hubon a véleményekhez megerősített vásárlás szükséges.
• Kérdezze meg, mi romlott el. A meséljen egy rosszul sikerült projektről” kérdésre a legerősebb válasz egy konkrét, hízelgő, jól elemzett történet. Nincs olyan fejlesztő, akinek csak zökkenőmentes projektjei lennének.

Ennek szisztematikus változatához tekintse át a 12 lépéses szabadúszó ellenőrzőlistánkat.

Kérdések, mielőtt felveszel valakit

A cél nem az, hogy bárkit is csapdába ejtsünk. Hanem az, hogy meghalljuk, hogyan gondolkodik valaki, amikor a válasz nincs begyakorolva.

• Magyarázzon el egy korábbi építéstMeséljen el egyet ezek közül a projektek közül, és azokat a kompromisszumokat, amelyeket kötött.” Egy jó fejlesztő megnevez valamit, amit úgy döntött, hogy nem tesz meg, és miért. A zsargon kompromisszumok nélkül figyelmeztető jel.
• Mi aggasztja ittKérdezze meg, mi a legkockázatosabb része a leírásának. Aki azt mondja, hogy semmi, egyszerű”, az nem olvasta el rendesen.
• Mi hiányzikMire lenne szüksége tőlem, amit nem biztosítottam?” Az erős jelöltek azonnal és részletesen válaszolnak erre.
• Hogyan fogom látni a haladástEgy staging link, heti frissítés, megosztott tábla. Bármilyen válasz rendben van; a válasz hiánya nem.
• Mi történik az indítás utánHibajavítási időszak, támogatási feltételek, dokumentáció. Ezt még a kezdés előtt egyeztesse, ne akkor, amikor valami elromlik.
• Ki a kód tulajdonosaKérdezze meg közvetlenül. A válasz az kell, hogy Ön legyen, átadáskor, írásban, beleértve mindent, ami a futtatásához szükséges.

Tesztelje, mielőtt elkötelezi magát

A vevő számára elérhető legolcsóbb biztosítás egy kis fizetett munka egy nagy előtt. Nem egy fizetetlen próba, amit a jó szabadúszók elutasítanak, és ami semmit sem árul el arról, hogyan viselkedik valaki, amikor pénzről van szó – egy valós, kis, fizetett feladat.

Egy jó tesztfeladat reprezentatív, önálló és egy ülésben elvégezhető: javítson ki egy konkrét hibát, tegyen egy oldalt reszponzívvá, adjon hozzá egy űrlapot és kösse be, javítson egy lassú oldalt. Amit valójában értékel, az nem a kód. Hanem az, hogy feltett-e tisztázó kérdést a kezdés előtt, hogy azt szállította-e, amit kértek, nem pedig azt, amit ő preferált, hogy elmagyarázta-e, mit csinált, és hogy az általa megadott időkeret az volt-e, amit Ön kapott.

A Zinn Hubon a természetes formátum egy Micro Zinn – egy fix áras feladat $5, $10, $15 vagy $20 áron. Böngésszen a hibajavítások és kisebb kódolási feladatok vagy a weboldal hibajavítások és finomhangolások között, vagy kezdjen egy árral a $20 Micro Zinns segítségével. Útmutatónk a szabadúszó teszteléséről, mielőtt elkötelezi magát lefedi, hogyan kell felépíteni és megítélni a tesztet.

Mennyibe kerül és hogyan kell fizetni

A fejlesztési árak jobban változnak, mint bármely más szabadúszó kategóriában, mert a munka is változatosabb. Az alábbiak a teljes munkára vonatkozó tipikus piaci sávok, nem a Zinn Hub árai, és minden szabadúszó maga határozza meg az árait.

• Kis feladat

  200 alatt

  Hibajavítás, bővítménykonfliktus, űrlap, sebességoptimalizálás, egy kis funkció egy meglévő építésen. Legjobb fix áras feladatként megvásárolni.

• Standard építés

  $500–$2,000

  Platform alapú oldal vagy bolt: téma konfiguráció, több oldalsablon, űrlapok, alapvető integrációk, indítás.

• Haladó

  $2,000–$8,000

  Egyedi funkcionalitás, fiókok és bejelentkezések, fizetések, harmadik féltől származó integrációk, vagy egyedi tervezés a nulláról megvalósítva.

• Alkalmazás

  $8,000+

  Egy valódi szoftvertermék: többszereplős rendszerek, irányítópultok, mobilalkalmazások, bármi, ami értelmes háttérlogikával és folyamatos mérnöki munkával jár.

A költségek a hatókör, a komplexitás és a tapasztalat függvényében változnak. Használja a sávokat az árajánlat ellenőrzésére, nem pedig tarifaként – ha egy szám két sávval eltér attól, ahová a briefje tartozik, az a különbség megéri a beszélgetést.

A Zinn Hubon minden Zinn ára a Zinner által van meghatározva, a vásárlók nem fizetnek platformdíjat, és minden ár USD-ben van megadva, hozzávetőlegesen feltüntetve a saját pénznemében. A megrendelés egyetlen teljes összegként kerül kifizetésre és védelmére; nincs szakaszos vagy mérföldkő alapú kifizetés, így a fázisos építés külön megrendelésként vagy a projekt briefben külön árazott fázisként kerül megállapodásra. Válasszon Platform Protected Zinnert, és a fizetését a Zinn Hub tartja, amíg a megrendelés be nem fejeződik; bármilyen visszatérítés teljes egészében, USD-ben kerül jóváírásra a Zinn Walletjében. Azok a Zinners, akik saját PayPal vagy Stripe fiókjukat csatlakoztatják, közvetlenül a fizetéskor kapják meg a pénzt.

Tulajdonjog, hozzáférés és átadás

Ez az a rész, amit a vásárlók kihagynak, és később megbánnak. Mielőtt a munka elkezdődik, mindent írásban rögzítsenek, mert a szállítás után már nincs befolyásuk.

• Fiókok az Ön nevére. A domain, a tárhely és bármely harmadik féltől származó szolgáltatás az Ön nevére legyen regisztrálva, a fejlesztő felhasználóként hozzáadva. Soha ne fordítva.
• Kód tulajdonjoga a szállításkor. Egyértelműen rögzítse, hogy a végső fizetéskor a munka az Öné, használhatja, módosíthatja és máshová viheti. Kérdezzen rá minden harmadik féltől származó komponensre, amelyeknek saját licence van.
• Adattár hozzáférés. Még ha soha nem is nyitja meg, képesnek kell lennie arra, hogy átadja a következő fejlesztőnek.
• Hitelesítő adatok, mindegyik. Admin bejelentkezések, API kulcsok, adatbázis hozzáférés, telepítési hozzáférés – átadva és működőképesnek megerősítve a végső fizetés előtt.
• Dokumentáció. Egy rövid írásos jegyzet arról, hogyan kell telepíteni, hol találhatók a dolgok, és mit kell tenni, ha elromlik. Egy oldal is elég; a semmi nem az.
• Hibajavítási időszak. Egy meghatározott időszak az indítás után, amelyben az eredeti hibákat extra költség nélkül javítják. Harminc nap egy gyakori, ésszerű kérés.

A szerzői jogi és licencelési feltételek országonként és szerződésenként eltérőek, ezért ezt általános útmutatásnak tekintse, nem jogi tanácsnak, és kérjen szakmai tanácsot minden kereskedelmileg jelentős ügyben.

Fejlesztési projekteket tönkretevő hibák

• Felvétel, mielőtt a brief létezik. Minden óra, amit a specifikációra fordítanak, több órát takarít meg az építésben és az átalakításban. Semmi más ezen a listán nem számít annyit.
• Csak az ár alapján választani. A legalacsonyabb árajánlat gyakran az, amelyik a legkevésbé értette meg, és a különbség változtatási kérésekként jelentkezik.
• Hatókör csendes bővítése. A kis kérések az építés során okozzák, hogy a fix árak vitává válnak. Csoportosítsa őket, árazza be őket, döntsön róluk.
• Nincs tesztkörnyezet. A munka felülvizsgálata csak akkor, amikor már élő, az, ahogyan a hibás webhelyet az ügyfelek fedezik fel Ön helyett.
• A mobil ellenőrzés kihagyása. Látogatóinak többsége telefonon van. Ne hagyjon jóvá semmit, amit nem nyitott meg egy telefonon.
• Az átadás a végére hagyása. A hozzáférés és a tulajdonjog megállapodásának pillanata az első commit előtt van, nem az utolsó számla során.
• Nincs karbantartási terv. A szoftver elavul. Költségvetés frissítésekre, biztonsági mentésekre és biztonságra az első naptól kezdve, vagy fizessen a későbbi mentésért.
• A figyelmeztető jelek figyelmen kívül hagyása. A homályos válaszok, a kis határidők elmulasztása és a platformon kívüli fizetésre való nyomás mind szerepelnek a gyakori szabadúszó csalások című útmutatónkban.

Ha még mindig azon gondolkodik, hogy a szabadúszó-e a megfelelő út, a szabadúszó vs ügynökség őszintén összehasonlítja a kettőt egy kisvállalkozás építéséhez.