Әзірлеуге мердігерді қалай таңдау керек

Орындаушыны таңдаудағы қателік сметаның кез келген жолынан қымбатқа түседі. Мерзімнің бұзылуы — жіберіп алынған маусым, ал басқа командаға беру мүмкін емес код — нөлден қайта жазу деген сөз. Әдетте бірінші қарайтын портфолио мен баға болашақ жоба туралы ең аз айтады.

Әзірлеуге мердігерді жүйелі түрде қалай таңдау керектігін талдайық: іздеу алдында не дайындау керек, қашан фрилансер жарайды, ал қашан студия қажет, қандай 12 тармақты тексеру керек, шартта нені бекіту керек және қандай белгілер алғашқы кездесудің өзінде сақтандыруы тиіс.

Неден бастау керек: мердігерден бұрын міндет

Міндеттің сипаттамасынсыз орындаушыларды салыстыру пайдасыз: әрқайсысы өнімнің өз нұсқасын бағалайды, ал бағалар бірнеше есе ерекшеленеді. Сұраныстарды жібермес бұрын кемінде 2–4 беттік қысқа ТТ дайындаңыз:

• өнімнің мақсаты және табыс метрикасы;
• пайдаланушы рөлдері және негізгі сценарийлер;
• бірінші нұсқаның міндетті функциялары;
• интеграциялар (CRM, 1С, төлемдер, қойма);
• деректер мен орналастыруға қойылатын талаптар;
• бюджет ауқымы және өнім қажет болатын мерзім.

4–6 үміткерге жіберілген бірдей ТТ таңдауды болжаудан салыстыруға айналдырады. Қадамдық құрылым мен мысал — әзірлеуге техникалық тапсырманы қалай құруға болады мақаласында.

Фрилансер ме, әлде әзірлеу студиясы ма

«Фрилансер ме, әлде әзірлеу студиясы ма» деген сұрақ сапа туралы емес — жеке мамандардың арасында мықты инженерлер көп. Ол тәуекелдер мен міндеттің ауқымы туралы.

Көптеген компания үшін тиімді нұсқа: студия MVP жасап, архитектураны құрады, содан кейін өнім кодпен және құжаттамамен бірге ішкі командаға беріледі. Бұл тек беру басынан бастап жоспарланған жағдайда ғана жұмыс істейді — бұл туралы төменде.

Чек-лист: орындаушыны таңдауға арналған 12 тармақ

Бұл тізім платформаға арналған әзірлеу студиясын немесе ботқа жеке әзірлеушіні қалай таңдау керектігін шешкенде бірдей пайдалы. Әр тармақты «иә / ішінара / жоқ» шкаласы бойынша белгілеңіз.

1. Тиісті кейстер. «Әдемі суреттер» емес, күрделілігі ұқсас жобалар: рөлдер, интеграциялар, жүктеме. Тек скриншоттарды емес, жұмыс істеп тұрған өнімді көрсетуді сұраңыз.
2. Жобаны жасайтын адамдар. Архитектураны нақты кім жүргізеді, кодты кім жазады, сізде әзірлеушілермен тікелей байланыс бола ма, әлде тек менеджермен бе.
3. Процесс. Демо қаншалықты жиі, тесттік стенд бар ма, тапсырмалар тақтасы қай жерде көрінеді. Қалыпты жауап — апта сайын демо және алғашқы апталардан бастап стенд.
4. Сізге қойылатын сұрақтар. Мықты мердігер бизнес пен метрикалар туралы көп ыңғайсыз сұрақ қояды. Егер бағалау бір сағаттан кейін бірде-бір сұрақсыз келсе — бұл басқа нәрсенің бағасы.
5. Бағалау құрылымы. Смета кезеңдер мен функцияларға бөлінген, болжамдар мен тәуекелдер көрінеді, «кілтімен тапсыру» деген бір сан емес.
6. Кодқа құқық. Шартта нәтижеге айрықша құқықтар сізге өтетіні тікелей көрсетілген, ал репозиторий сіздің аккаунтыңызда орналасқан.
7. Орналастыру. Өнім сіздің серверлеріңізде немесе сіздің бұлтыңызда іске қосылады, домендер мен қолжетімділіктер сіздің атыңызға рәсімделген.
8. Қауіпсіздік. Құпиялар мен қолжетімділіктер қалай сақталады, продакшенге кімнің қолжетімділігі бар, дербес деректер 152-ФЗ (Ресейдің дербес деректер туралы заңы) бойынша қалай өңделеді.
9. Код сапасы. Код-ревью, автотесттер, CI/CD, қателер мониторингі бар ма. Код үзіндісін көрсетуді немесе сіздің сарапшыңызбен техникалық қоңырау өткізуді сұраңыз.
10. Құжаттама және беру. Нәтижесінде не аласыз: архитектура сипаттамасы, орналастыру нұсқаулығы, қолжетімділіктер, команданы оқыту.
11. Іске қосылғаннан кейінгі қолдау. SLA бар ма: сыни қатеге әрекет ету уақыты, жұмыс сағаттары, пысықтау сағатының құны.
12. Ұсынымдар. Бір-екі бұрынғы клиентпен сөйлесу мүмкіндігі — жоғарыда аталғанның бәрін тексерудің ең жақсы тәсілі.

Егер үміткер 6, 7 және 10-тармақтар бойынша «жоқ» жинаса, қалғаны маңызды емес дерлік: тіпті жақсы өнім де бір командамен қарым-қатынастың тұтқынына айналады.

Кодқа құқық және өнім қайда орналасады

Бұл — ең бағаланбаған бөлім. Әдеттегі жағдай: өнім жұмыс істейді, бірақ мердігердің серверінде орналасқан, домен оның қызметкерінің атына тіркелген, ал сізде репозиторий жоқ. Мұндай жағдайда команданы ауыстыру келіссөзге айналады.

Нені бекіту керек

• Бағдарламалық код пен дизайнға айрықша құқықтың сіздің пайдаңызға иеліктен шығарылуы — актілер бойынша, кезең-кезеңімен немесе жоба қорытындысы бойынша.
• Пайдаланылатын үшінші тарап компоненттерінің және олардың лицензияларының тізбесі: «жұқпалы» лицензиялары бар open source-кітапханалар коммерциялық пайдалануды шектеуі мүмкін.
• Репозиторий (GitHub, GitLab немесе өзіңіздікі) сіздің компанияңыздың аккаунтында құрылған, мердігер онда шақырылған қатысушы ретінде жұмыс істейді.
• Бұлт, серверлер, домендер, App Store және Google Play-дегі әзірлеуші аккаунттары, төлем кабинеттері — сіздің заңды тұлғаңызға рәсімделген.
• Беру құжаттаманы, орта айнымалыларын, инфрақұрылым сызбасын және орналастыру нұсқаулығын қамтиды.

Шарт, төлем және SLA

Төлем моделі екі тараптың да мінез-құлқына әсер етеді. Екі негізгі схема:

Екі жағдайда да төлемді тексеруге болатын нәтижелерге байлаңыз: кезең қабылданды, сценарийлер тесттік стендте өтеді, код сіздің репозиторийіңізде. Бүкіл жобаға жүз пайыз алдын ала төлем — кез келген модельде жаман идея.

Қабылдау және кепілдік

Әр кезеңнің қалай қабылданатынын жазыңыз: ТТ-дағы сценарийлер чек-листі бойынша, тесттік стендте, ескертулерге белгіленген мерзіммен (мысалы, 5 жұмыс күні). Іске қосылғаннан кейінгі кепілдік кезеңін бөлек келісіңіз — әдетте бір айдан үш айға дейін, — бұл кезеңде мердігер жасалған функционалдағы қателерді тегін түзетеді. Қатені («төлем батырмасы Safari-де жұмыс істемейді») жаңа талаптан («бөліп төлеуді қосайық») ажырату маңызды: екіншісі көлемнің өзгерісі ретінде төленеді.

SLA бойынша қолдау

Қолдауға арналған SLA әдетте мыналарды сипаттайды: инцидент кластары (сыни, елеулі, ұсақ), әрқайсысы үшін әрекет ету және қалпына келтіру уақыты, жұмыс сағаттары (жұмыс уақыты немесе 24/7), эскалация тәсілі және қолдаудан тыс пысықтаулардың құны.

Алғашқы кездесудегі қызыл жалаушалар

• Сұрақсыз және пысықтаусыз бағалау — міндетті әлі түсінбей тұрып «2 аптада жасаймыз».
• Бір ТТ бойынша баға басқа үміткерлерден 2–3 есе төмен, бірақ неліктен екені түсіндірілмейді.
• Жұмыс істеп тұрған өнімдерді көрсетуден немесе кемінде бір клиенттің байланысын беруден бас тарту.
• «Кодты толық төлемнен кейін береміз», «хостинг тек бізде», «доменді өзімізге рәсімдейміз, солай ыңғайлы».
• Кездесулерге әзірлеушілердің ешқайсысы қатыспайды — тек сату менеджері.
• Кез келген міндетке бірдей стек: ботқа да, маркетплейске де, AI-жүйеге де бір нәрсені ұсынады.
• «Бір жылдан кейін мердігерді ауыстырғымыз келсе не болады» деген сұраққа жауап жоқ.

Веб-студияны қалай таңдауға болады: кездесуге арналған сұрақтар

Егер сайт немесе веб-қосымша үшін веб-студияны қалай таңдау керектігін ойласаңыз, жалпы чек-листке арнайы сұрақтарды қосыңыз:

1. Соңғы сайттарыңыздың жылдамдық көрсеткіштері қандай? Оны кездесудің өзінде PageSpeed Insights арқылы тексеруге болады.
2. Техникалық SEO-ны қалай қарастырасыз: микросызба, sitemap, канондық мекенжайлар, жылдамдық?
3. Қандай CMS және контентті әзірлеушісіз өзгерту қаншалықты ыңғайлы?
4. Аналитика қалай құрылған: мақсаттар, оқиғалар, CRM-мен байланыс?
5. Қолдауға не кіреді және іске қосылғаннан кейін пысықтау сағаты қанша тұрады?

Бюджет бағдарлары шынайы емес ұсыныстарды кездесулерге дейін-ақ сүзіп тастауға көмектеседі: анықтамалық бағалар сайт әзірлеу қанша тұрады мақаласында және әзірлеу бағалары бетінде жинақталған. Сайт бойынша жұмыс көлеміне әдетте не кіретіні — прототиптен хостинг пен аналитикаға дейін — сайттар мен веб-қосымшалар әзірлеу бетінің мысалында көрінеді.

Ашықтық үшін — біздің өз тәсіліміз, бізді де осы чек-лист бойынша тексеруге болады: код, репозиторийлер, серверлер мен домендер клиентке тиесілі, өнім сіздің серверлеріңізде немесе сіздің бұлтыңызда іске қосылып, құжаттамамен бірге жұмыс істейтін күйде беріледі; сізде әзірлеушілерге тікелей қолжетімділік және апта сайынғы демо бар. Команда туралы толығырақ — B2B-Lab студиясы туралы бетінде, жұмыс мысалдары — кейстер бөлімінде.