Internetinių projektų vystytojai čia kaip kokie odontologai. Pats neišmanydamas jų darbo niuansų, gali nelabai suprasti, ar kokybiškai padarė, kiek plombos laikys, kas padaryta „viduje”. Bet yra keli baziniai klausimai, kurie gali padėti atsirinkti specialistą tinkamai (neinant į visokius specializuotus niuansus):
Ar turi rekomendacijų?
Pabendraukite su klientais, kurie turi su jais bendrus projektus 5 ar daugiau metų. Kaip bendradarbiavo, kaip sprendė problemas, ar buvo ilgai neisšprendžiamų problemų ir kaip su jomis buvo tvarkomasi? Kiek ilgai „važiavo“ sukurta el.parduotuvė be esminių atnaujinimų? Ar dažnai keitėsi atsakingi asmenys ir kaip buvo valdomi šie pokyčiai?
Kokia komandos sudėtis?
Kiek laiko dirba kartu, ar turi skirtingų krypčių specialistų (programuotojų, testuotojų, UI/UX dizainerių ir pan.). Kas konkrečiai dirbs prie projekto, ir ar tai dirbantys įmonėje žmonės, ar samdomi iš išorės tam tikriems darbams.
Ar supranta jūsų verslą, ne tik technologijas.
Jei žmogus klausia: „Kokius verslo tikslus turite? Koks pirkinių krepšelio vidurkis ir kur didžiausias atmetimas?“ – laikykit stipriai. Jis jau galvoja kaip jūs. Ir atvirkščiai: jeigu pirmas klausimas „Kokią programinės kalbos versiją norėtumėte naudoti?“ ženklas, kad konsultanto požiūrio čia gausite mažai, labiau vykdytojo.
Ar moka „neperprogramuoti“?
Geras programuotojas ne tas, kuris viską rašo nuo nulio, o tas, kuris prireikus gali pasakyti: „paieškokime būdų, kaip galime pernaudoti jau egzistuojantį funkcionalumą“. Dažnai tam pačiam tikslui pasiekti yra daug būdų: sukurti naują funkcionalumą, koreguoti esamą pritaikant prie poreikių, įdiegti dar vieną įskiepį ar biblioteką. Vieni patogesni programuotojams, kiti draugiškesni kliento piniginei. Geriausi yra tokie, kurie sprendimą pasiūlo pagal jūsų verslo ar projekto poreikius.
Ar nepersūdo funkcionalumo?
Tai, kad kurdami nemokamai pridiegs daug visokių modulių ar funkcionalumų anaiptol nėra privalumas. Kiekviena programinio kodo eilutė turi savo kainą: įtaką greitaveikai, sistemos lankstumui, atsiranda priklausomybės nuo trečiųjų šalių ir pan. Mažesnę kodo bazė turinčius projektus lengviau ir pigiau palaikyti. O 5 metų perspektyvoje susidaro nemažos sumos. Čia kaip su daiktų pertekliumi namuose. Geriau ne turėti kuo daugiau, o turėti tai, ko reikia ir kuo reguliariai naudositės.
Ar klausia apie ateities poreikius?
Kuriant projektą nebūtina įgyvendinti iš karto penkmečio plano, bet apie ateities ketinimus pravartu žinoti iš anksto. Pavyzdžiui, jeigu dabar darote produktų importą iš vieno duomenų šaltinio ir planuojate, kad bus antras – apie tai informuokite.
Ar gali pasakyti „ne“?
Skamba gal keistai, bet jei žmogus tik linkčioja – blogai. Stiprūs specialistai moka prireikus pasiginčyti. Konstruktyviai. Kitaip viena diena bus situacija, kai galvos linkčiojimas virs fraze „bet gi jūs patys taip norėjote“
Ar pildo projekto dokumentaciją.
Kaip minimum – bent jau sudėtingesnėms dalims (pvz. integracijos). Tvarkinga projekto dokumentacija ilgesniu periodu sutaupys daug laiko keičiantis žmonėms. Didins ir projekto vertę. Kodėl tai svarbu esu rašęs čia.
Ar įvertina orientacinius svetainės palaikymo ir plėtros kaštus ateityje.
Tai labai svarbu, nes cost-of-owneship kaštai visam svetainės gyvavimo ciklui gali gerokai viršyti jos pradinio paleidimo sąmatą. Kartais net daugiau nei 3 kartus, jei pamatas buvo padarytas kuo pigiau. Geriausia, kai tas, kas kūrė projektą jį ir palaiko. Būtinai aptarkite šį klausimą.
Susidomėjote? Aptarkime jūsų projektą
Paskambinkite ar parašykite el. laišką ir mes suplanuosime susitikimą kurio metu aptarsime jūsų projektą ir mūsų idėjas jums.