Գործընթաց · 8 րոպե ընթերցանություն
Ինչպե՞ս ընտրել մշակման կապալառու
12 կետից բաղկացած ստուգաթերթ ստուդիա կամ թիմ ընտրելու համար՝ պորտֆոլիո, գործընթաց, կոդի իրավունքներ, որտեղ է տեղակայվում արտադրանքը, անվտանգություն, պայմանագիր և SLA։ Գումարած կարմիր դրոշներ և հարցեր առաջին հանդիպմանը։
Հրապարակվել է՝ Թարմացվել է՝ Հեղինակ՝ B2B-Lab թիմ
Կատարողի ընտրության սխալն ավելի թանկ է նստում, քան նախահաշվի ցանկացած տող։ Խափանված ժամկետը բաց թողնված սեզոն է, իսկ կոդը, որը հնարավոր չէ փոխանցել այլ թիմի, նշանակում է ամեն ինչ զրոյից վերաշարադրել։ Ընդ որում պորտֆոլիոն և գինը, որոնց սովորաբար առաջինն են նայում, ապագա նախագծի մասին ամենաքիչն են ասում։
Կքննարկենք, թե ինչպես համակարգված ընտրել մշակման կապալառու՝ ինչ պատրաստել որոնումից առաջ, երբ կհամապատասխանի ֆրիլանսերը, իսկ երբ է պետք ստուդիա, որ 12 կետերը ստուգել, ինչ ամրագրել պայմանագրում և որ ազդանշանները պետք է զգուշացնեն դեռ առաջին հանդիպմանը։
Որտեղից սկսել՝ խնդիրը կապալառուից առաջ
Կատարողներին համեմատելն առանց խնդրի նկարագրության անօգուտ է․ յուրաքանչյուրը կգնահատի արտադրանքի իր տարբերակը, և գները կտարբերվեն մի քանի անգամ։ Հարցումներ ուղարկելուց առաջ պատրաստեք գոնե կարճ տեխնիկական առաջադրանք՝ 2–4 էջ․
- արտադրանքի նպատակը և հաջողության չափանիշը․
- օգտատերերի դերերը և հիմնական սցենարները․
- առաջին տարբերակի պարտադիր գործառույթները․
- ինտեգրացիաներ (CRM, 1C, վճարումներ, պահեստ)․
- տվյալների և տեղակայման պահանջներ․
- բյուջեի միջակայքը և ժամկետը, երբ արտադրանքը պետք է պատրաստ լինի։
Միևնույն տեխնիկական առաջադրանքը, որն ուղարկվել է 4–6 թեկնածուի, ընտրությունը գուշակությունից վերածում է համեմատության։ Քայլ առ քայլ կառուցվածքը և օրինակը՝ ինչպես կազմել մշակման տեխնիկական առաջադրանք հոդվածում։
Ֆրիլանսե՞ր, թե՞ մշակման ստուդիա
«Ֆրիլանսե՞ր, թե՞ մշակման ստուդիա» հարցը որակի մասին չէ․ անհատ մասնագետների մեջ շատ ուժեղ ինժեներներ կան։ Այն ռիսկերի և խնդրի մասշտաբի մասին է։
| Չափանիշ | Ֆրիլանսեր | Ստուդիա | Հաստիքային թիմ |
|---|---|---|---|
| Հարմար է | Փոքր խնդիրների, լրամշակումների, պարզ բոտի կամ լենդինգի համար | Ամբողջ արտադրանքի համար՝ դիզայն, բեքենդ, ֆրոնտենդ, բջջային, DevOps | Երբ արտադրանքը բիզնեսի միջուկն է տարիներով |
| Մեկնարկի արագություն | Արագ | 1–2 շաբաթ՝ խորացման համար | Ամիսներ՝ աշխատանքի ընդունման համար |
| «Դուրս ընկնելու» ռիսկ | Բարձր՝ հիվանդություն, այլ նախագիծ | Ցածր՝ թիմի ներսում փոխարինող կա | Միջին՝ կադրերի հոսունություն |
| Իրավասություններ | Սովորաբար մեկ-երկու դեր | Ամբողջական ցիկլ | Կախված է աշխատանքի ընդունումից |
| Պատասխանատվություն | Հաճախ առանց պայմանագրի և երաշխիքների | Պայմանագիր, փուլեր, SLA | Աշխատանքային պայմանագիր, բայց արտադրանքի ռիսկերը ձեզ վրա են |
| Արժեք | Ցածր դրույքաչափ | Բարձր դրույքաչափ, կառավարման ավելի քիչ ծախսեր ձեր կողմից | Աշխատավարձի ֆոնդ + հարկեր + կառավարում |
Շատ ընկերությունների համար գործնական տարբերակ՝ ստուդիան պատրաստում է MVP-ն և կառուցում ճարտարապետությունը, իսկ հետո արտադրանքը կոդի և փաստաթղթերի հետ միասին փոխանցվում է ներքին թիմին։ Սա աշխատում է միայն այն դեպքում, եթե փոխանցումը նախատեսված է եղել հենց սկզբից․ այդ մասին՝ ստորև։
Ստուգաթերթ՝ 12 կետ կատարող ընտրելու համար
Այս ցանկը հավասարապես օգտակար է, անկախ նրանից՝ որոշում եք, թե ինչպես ընտրել մշակման ստուդիա պլատֆորմի համար, թե անհատ ծրագրավորող բոտի համար։ Յուրաքանչյուր կետ նշեք «այո / մասամբ / ոչ» սանդղակով։
- Համապատասխան քեյսեր։ Ոչ թե «գեղեցիկ նկարներ», այլ նմանատիպ բարդության նախագծեր՝ դերեր, ինտեգրացիաներ, ծանրաբեռնվածություն։ Խնդրեք ցույց տալ գործող արտադրանք, ոչ միայն սքրինշոթներ։
- Մարդիկ, ովքեր կանեն նախագիծը։ Ով կոնկրետ է վարում ճարտարապետությունը, ով է գրում կոդը, արդյոք ուղիղ կապ կունենաք ծրագրավորողների հետ, թե միայն մենեջերի։
- Գործընթաց։ Որքան հաճախ են դեմոները, կա՞ արդյոք թեստային միջավայր, որտեղ է երևում առաջադրանքների տախտակը։ Նորմալ պատասխան՝ դեմո ամեն շաբաթ և թեստային միջավայր առաջին շաբաթներից։
- Հարցեր ձեզ։ Ուժեղ կապալառուն շատ անհարմար հարցեր է տալիս բիզնեսի և չափանիշների մասին։ Եթե գնահատականը ուղարկել են մեկ ժամից առանց որևէ հարցի, դա այլ բանի գնահատական է։
- Գնահատման կառուցվածք։ Նախահաշիվը բաժանված է փուլերի և գործառույթների, երևում են ենթադրություններն ու ռիսկերը, այլ ոչ թե մեկ թիվ «բանալին ձեռքին»։
- Կոդի իրավունքներ։ Պայմանագրում ուղղակիորեն նշված է, որ արդյունքի բացառիկ իրավունքները անցնում են ձեզ, իսկ ռեպոզիտորիան գտնվում է ձեր հաշվում։
- Տեղակայում։ Արտադրանքը տեղակայվում է ձեր սերվերներում կամ ձեր ամպում, դոմեններն ու մուտքերը ձևակերպված են ձեր անունով։
- Անվտանգություն։ Ինչպես են պահվում գաղտնիքներն ու մուտքերը, ով ունի մուտք պրոդակշն, ինչպես են մշակվում անձնական տվյալները 152-FZ-ի (Ռուսաստանի անձնական տվյալների մասին օրենքի) համաձայն։
- Կոդի որակ։ Կա՞ն արդյոք կոդ-ռևյու, ավտոթեստեր, CI/CD, սխալների մոնիթորինգ։ Խնդրեք ցույց տալ կոդի հատված կամ անցկացնել տեխնիկական զանգ ձեր փորձագետի հետ։
- Փաստաթղթեր և հանձնում։ Ինչ կստանաք վերջում՝ ճարտարապետության նկարագրություն, տեղակայման հրահանգ, մուտքեր, թիմի ուսուցում։
- Աջակցություն գործարկումից հետո։ Կա՞ արդյոք SLA՝ կրիտիկական սխալի արձագանքման ժամանակ, աշխատանքային ժամեր, լրամշակումների մեկ ժամի արժեք։
- Երաշխավորություններ։ Մեկ-երկու նախկին հաճախորդի հետ զրուցելու հնարավորությունը վերը թվարկված ամեն ինչ ստուգելու լավագույն միջոցն է։
Եթե թեկնածուն 6-րդ, 7-րդ և 10-րդ կետերով «ոչ» է ստանում, մնացածը գրեթե կարևոր չէ․ նույնիսկ լավ արտադրանքը կդառնա մեկ թիմի հետ հարաբերությունների պատանդ։
Կոդի իրավունքները և որտեղ է տեղակայվում արտադրանքը
Սա ամենաթերագնահատված բաժինն է։ Տիպիկ պատմություն՝ արտադրանքն աշխատում է, բայց տեղակայված է կապալառուի սերվերում, դոմենը գրանցված է նրա աշխատակցի անունով, իսկ ռեպոզիտորիա դուք չունեք։ Նման իրավիճակում թիմի փոփոխությունը վերածվում է բանակցությունների։
Ինչ ամրագրել
- Ծրագրային կոդի և դիզայնի բացառիկ իրավունքի օտարում ձեր օգտին՝ ակտերով, փուլ առ փուլ կամ նախագծի ավարտին։
- Օգտագործվող երրորդ կողմի բաղադրիչների և դրանց լիցենզիաների ցանկ․ «վարակիչ» լիցենզիաներով open source գրադարանները կարող են սահմանափակել առևտրային օգտագործումը։
- Ռեպոզիտորիան (GitHub, GitLab կամ ձեր սեփականը) ստեղծված է ձեր ընկերության հաշվում, կապալառուն աշխատում է դրանում որպես հրավիրված մասնակից։
- Ամպը, սերվերները, դոմենները, ծրագրավորողի հաշիվները App Store-ում և Google Play-ում, վճարային կաբինետները ձևակերպված են ձեր իրավաբանական անձի անունով։
- Հանձնումը ներառում է փաստաթղթեր, միջավայրի փոփոխականներ, ենթակառուցվածքի սխեմա և տեղակայման հրահանգ։
Պայմանագիր, վճարում և SLA
Վճարման մոդելն ազդում է երկու կողմերի վարքագծի վրա։ Երկու հիմնական սխեմա․
| Մոդել | Ինչպես է աշխատում | Երբ է հարմար |
|---|---|---|
| Ֆիքսված գին | Ծավալը ամրագրված է տեխնիկական առաջադրանքում, վճարումը՝ փուլերով ընդունումից հետո | Հասկանալի խնդիր՝ բոտ, կայք, MVP գործառույթների խիստ ցանկով |
| Time & Materials | Փաստացի ծախսված ժամերի վճարում ըստ սպրինտների | Արտադրանքի զարգացում, անորոշ պահանջներ, երկարատև նախագծեր |
Երկու դեպքում էլ վճարումը կապեք ստուգելի արդյունքների հետ՝ փուլն ընդունված է, սցենարներն անցնում են թեստային միջավայրում, կոդը ձեր ռեպոզիտորիայում է։ Ամբողջ նախագծի հարյուր տոկոս կանխավճարը վատ գաղափար է ցանկացած մոդելի դեպքում։
Ընդունում և երաշխիք
Նշեք, թե ինչպես է ընդունվում յուրաքանչյուր փուլ՝ տեխնիկական առաջադրանքի սցենարների ստուգաթերթով, թեստային միջավայրում, դիտողությունների ֆիքսված ժամկետով (օրինակ՝ 5 աշխատանքային օր)։ Առանձին պայմանավորվեք գործարկումից հետո երաշխիքային ժամկետի մասին՝ սովորաբար մեկից երեք ամիս, որի ընթացքում կապալառուն անվճար ուղղում է պատրաստված գործառույթների սխալները։ Կարևոր է տարբերել սխալը («վճարման կոճակը չի աշխատում Safari-ում») և նոր պահանջը («եկեք ավելացնենք մասնավճարով վճարում»)․ երկրորդը վճարվում է որպես ծավալի փոփոխություն։
Աջակցություն ըստ SLA-ի
Աջակցության SLA-ն սովորաբար նկարագրում է՝ միջադեպերի դասերը (կրիտիկական, լուրջ, մանր), յուրաքանչյուրի արձագանքման և վերականգնման ժամանակը, աշխատանքային ժամերը (աշխատանքային ժամանակ կամ 24/7), էսկալացիայի եղանակը և աջակցությունից դուրս լրամշակումների արժեքը։
Կարմիր դրոշներ առաջին հանդիպմանը
- Գնահատական առանց հարցերի և առանց մշակման՝ «կանենք 2 շաբաթում», դեռ չհասկանալով խնդիրը։
- Գինը 2–3 անգամ ցածր է մնացած թեկնածուներից նույն տեխնիկական առաջադրանքի համար՝ առանց բացատրելու, թե ինչի հաշվին։
- Գործող արտադրանքներ ցույց տալուց կամ գոնե մեկ հաճախորդի կոնտակտ տալուց հրաժարում։
- «Կոդը փոխանցում ենք ամբողջական վճարումից հետո», «հոսթինգը միայն մեզ մոտ», «դոմենը մեր անունով կձևակերպենք, այդպես ավելի հարմար է»։
- Հանդիպումներին ծրագրավորողներից ոչ ոք չի մասնակցում, միայն վաճառքի մենեջերը։
- Նույն ստեկը ցանկացած խնդրի համար՝ և՛ բոտի, և՛ մարքեթփլեյսի, և՛ AI համակարգի համար առաջարկում են նույնը։
- Պատասխան չկա «ի՞նչ կլինի, եթե մեկ տարի անց ուզենանք փոխել կապալառուին» հարցին։
Ինչպես ընտրել վեբ ստուդիա՝ հարցեր հանդիպման համար
Եթե մտածում եք, թե ինչպես ընտրել վեբ ստուդիա կայքի կամ վեբ-հավելվածի համար, ընդհանուր ստուգաթերթին ավելացրեք հատուկ հարցեր․
- Ինչպիսի՞ն են ձեր վերջին կայքերի արագության ցուցանիշները։ Կարելի է ստուգել PageSpeed Insights-ում հենց հանդիպման ժամանակ։
- Ինչպե՞ս եք նախատեսում տեխնիկական SEO-ն՝ միկրոնշագրում, sitemap, կանոնիկ հասցեներ, արագություն։
- Ո՞ր CMS-ն է, և որքանո՞վ է հարմար փոխել բովանդակությունն առանց ծրագրավորողի։
- Ինչպե՞ս է կազմակերպված վերլուծությունը՝ նպատակներ, իրադարձություններ, կապ CRM-ի հետ։
- Ի՞նչ է ներառված աջակցության մեջ, և որքա՞ն արժե լրամշակումների մեկ ժամը գործարկումից հետո։
Բյուջեների ուղենիշները կօգնեն անիրատեսական առաջարկները զտել դեռ հանդիպումներից առաջ․ տեղեկատու գները հավաքված են որքան արժե կայքի մշակումը հոդվածում և մշակման գների էջում։ Թե ինչ է սովորաբար ներառում կայքի աշխատանքների ծավալը՝ նախատիպից մինչև հոսթինգ և վերլուծություն, երևում է կայքերի և վեբ-հավելվածների մշակման էջի օրինակով։
Թափանցիկության համար՝ մեր սեփական մոտեցումը, որով մեզ նույնպես կարելի է ստուգել այս ստուգաթերթով․ կոդը, ռեպոզիտորիաները, սերվերները և դոմենները պատկանում են հաճախորդին, արտադրանքը տեղակայվում է ձեր սերվերներում կամ ձեր ամպում և հանձնվում է աշխատող վիճակում՝ փաստաթղթերով, դուք ուղիղ կապ ունեք ծրագրավորողների հետ և շաբաթական դեմոներ։ Թիմի մասին ավելին՝ B2B-Lab ստուդիայի մասին էջում, աշխատանքների օրինակները՝ քեյսերի բաժնում։
Հարցեր և պատասխաններ
Ո՞րն է ավելի լավ մշակման համար՝ ֆրիլանսե՞րը, թե՞ ստուդիան։
Ֆրիլանսերը հարմար է փոքր խնդիրների և լրամշակումների համար, որտեղ մեկ մարդու դուրս ընկնելու ռիսկը կրիտիկական չէ։ Ամբողջ արտադրանքի համար՝ դիզայնով, բեքենդով, բջջային հավելվածներով և աջակցությամբ, ավելի հուսալի է ստուդիան՝ պայմանագրով, փուլերով և SLA-ով։
Ինչպե՞ս ստուգել կապալառուին մինչև պայմանագիր ստորագրելը։
Խնդրեք ցույց տալ նմանատիպ բարդության գործող արտադրանքներ, զրուցեք մեկ-երկու նախկին հաճախորդի հետ և տեխնիկական զանգ անցկացրեք այն ծրագրավորողների հետ, ովքեր կանեն ձեր նախագիծը։ Լավ նշան է ձեր բիզնեսի մասին բազմաթիվ ճշտող հարցերը։
Ո՞ւմ պետք է պատկանի կոդը մշակումից հետո։
Պատվիրատուին։ Պայմանագրում արժե ուղղակիորեն նշել բացառիկ իրավունքի օտարումը, իսկ ռեպոզիտորիան, սերվերները, դոմենները և սթորերի հաշիվները հենց սկզբից ձևակերպել պատվիրատուի ընկերության անունով։
Ինչո՞ւ են տարբեր կապալառուների գնահատականներն այդքան տարբերվում։
Ամենից հաճախ այն պատճառով, որ յուրաքանչյուրը գնահատում է խնդրի իր մեկնաբանությունը։ Դերերով, սցենարներով և ինտեգրացիաներով միևնույն տեխնիկական առաջադրանքը, որն ուղարկվել է բոլոր թեկնածուներին, գնահատականները դարձնում է համադրելի։
Քանի՞ կապալառու արժե դիտարկել։
Սովորաբար բավական է 4–6 թեկնածու գնահատականների հարցման փուլում և 2–3՝ մանրամասն հանդիպումների փուլում։ Ավելին ձգձգում է ընտրությունը, պակասը թույլ չի տալիս հասկանալ գների շուկայական մակարդակը։