Գործընթաց · 9 րոպե ընթերցանություն
Ինչպե՞ս կազմել տեխնիկական առաջադրանք մշակման համար
Բոտի, կայքի կամ հավելվածի տեխնիկական առաջադրանքի կառուցվածքը՝ նպատակներ, դերեր, սցենարներ, ինտեգրացիաներ և ոչ ֆունկցիոնալ պահանջներ։ 9 բաժնից ձևանմուշ, կայքի օրինակ և տիպային սխալներ։
Հրապարակվել է՝ Թարմացվել է՝ Հեղինակ՝ B2B-Lab թիմ
Լավ տեխնիկական առաջադրանքը խնայում է ոչ թե էջեր, այլ փող․ դրա հիման վրա կապալառուն նշում է գին, որը մեկ ամիս անց «չի լողա», իսկ դուք ընդունում եք աշխատանքը հասկանալի չափանիշներով։ Վատ առաջադրանքը կա՛մ երեք տող է՝ «պետք է կայք, ինչպես մրցակիցներինը», կա՛մ 80 էջ պահանջներ, որոնք ոչ ոք մինչև վերջ չի կարդացել։
Ստորև՝ գործնական ուղեցույց, թե ինչպես կազմել տեխնիկական առաջադրանք բոտի, կայքի, հավելվածի կամ հարթակի համար, նույնիսկ եթե տեխնիկական մասնագետ չեք։ Կքննարկենք կառուցվածքը, ցույց կտանք իրական ձևաչափով առաջադրանքի հատված, կթվարկենք այն սխալները, որոնք ամենից հաճախ հանգեցնում են վերամշակումների, և կպատմենք, թե ինչպես ստանալ նախնական գնահատական առանց երկար նամակագրության։
Ինչի՞ համար է պետք տեխնիկական առաջադրանքը, և ինչո՞վ է այն տարբերվում բրիֆից
Բրիֆը պատասխանում է «ինչ բիզնես է, և ինչ խնդիր» հարցին։ Տեխնիկական առաջադրանքը պատասխանում է «կոնկրետ ինչ պետք է ստացվի, և ինչպես կհասկանանք, որ այն պատրաստ է» հարցին։ Բրիֆը լրացնում են կես ժամում, իսկ առաջադրանքը հավաքում են մի քանի օրից մինչև մի երկու շաբաթ՝ կախված արտադրանքի մասշտաբից։
Տեխնիկական առաջադրանքն ունի երեք գործնական գործառույթ․
- Գնահատում։ Առանց դերերի, սցենարների և ինտեգրացիաների ցանկի ցանկացած գին գուշակություն է։ Նույն «կայքի» գնահատականների 3–5 անգամ տարբերությունը տարբեր կապալառուների մոտ սովորաբար բացատրվում է նրանով, որ յուրաքանչյուրը պատկերացրել է իր կայքը։
- Պայմանավորվածություն։ Առաջադրանքն ամրագրում է աշխատանքների ծավալը։ Այն ամենը, ինչ դրանում չի մտել, ծավալի փոփոխություն է, որը քննարկվում է առանձին, այլ ոչ թե «դե սա ակնհայտ է»։
- Ընդունում։ Յուրաքանչյուր պահանջ պետք է ստուգելի լինի․ «հայտի ձևը տվյալներն ուղարկում է CRM 5 վայրկյանում» կարելի է ստուգել, «հարմար ձև»՝ ոչ։
Փոքր խնդիրների համար՝ պարզ բոտ կամ լենդինգ, բավական է 2–4 էջանոց կարճ առաջադրանք։ Հարթակի կամ բջջային հավելվածի համար փաստաթուղթը հասնում է 15–40 էջի, և այն սովորաբար լրամշակում են կապալառուի հետ միասին՝ նախատիպի փուլում։
Մշակման տեխնիկական առաջադրանքի ձևանմուշ՝ 9 պարտադիր բաժին
Մշակման տեխնիկական առաջադրանքի այս ձևանմուշը հարմար է ցանկացած թվային արտադրանքի համար՝ Telegram-բոտ, կայք, Mini App, բջջային հավելված կամ մարքեթփլեյս։ Բաժինները կարելի է կրճատել, բայց ոչ դուրս նետել․ դատարկ բաժինն ավելի լավ է, քան մոռացվածը։
| Բաժին | Ինչ կա դրանում | Ձևակերպման օրինակ |
|---|---|---|
| 1. Նպատակ և մետրիկաներ | Բիզնես-խնդիրը, որը լուծում է արտադրանքը, և ինչպես չափել հաջողությունը | Նվազեցնել օպերատորների ծանրաբեռնվածությունը՝ դիմումների 60%-ը փակում է բոտն առանց մարդու |
| 2. Լսարան և դերեր | Ով է օգտվում արտադրանքից, և ում ինչ իրավունքներ ունի | Հաճախորդ, մենեջեր, ադմինիստրատոր․ մենեջերը տեսնում է միայն իր հայտերը |
| 3. Օգտատիրոջ սցենարներ | Հիմնական գործողությունների քայլ առ քայլ ճանապարհներ | Հաճախորդն ընտրում է ծառայությունը → ամսաթիվը → վճարում է → ստանում հաստատում |
| 4. Ֆունկցիաներ | Ֆունկցիաների ցանկ՝ առաջնահերթություններով | Must՝ կատալոգ, զամբյուղ, վճարում։ Could՝ պրոմոկոդեր |
| 5. Ինտեգրացիաներ | Ինչ համակարգերի հետ փոխանակել տվյալներ, և որ ուղղությամբ | Պատվերները գնում են 1C, կարգավիճակները վերադառնում են անձնական էջ |
| 6. Հարթակներ և դիզայն | Որտեղ է աշխատում արտադրանքը, կա՞ բրենդբուք և մակետներ | Վեբ + iOS + Android, ֆիրմային ոճ կա, մակետներ չկան |
| 7. Տվյալներ և անվտանգություն | Անձնական տվյալներ, պահպանում, հասանելիություններ, տեղակայում | Անձնական տվյալներ՝ ըստ 152-FZ-ի, սերվերներ ՌԴ-ում, աշխատակիցների մուտք 2FA-ով |
| 8. Ոչ ֆունկցիոնալ պահանջներ | Բեռնվածություն, արագություն, հասանելիություն, բրաուզերների աջակցություն | Մինչև 500 միաժամանակյա օգտատեր, էջը բեռնվում է մինչև 2 վ-ում |
| 9. Սահմանափակումներ և ընդունում | Բյուջե, ժամկետներ, փուլեր, հանձնման չափանիշներ | MVP-ի գործարկում մինչև դեկտեմբերի 1-ը, ընդունում՝ սցենարների չեկ-լիստով |
Եթե արտադրանքը բարդ է, ավելացրեք բառարան (ինչն եք անվանում «պատվեր», «գործարք», «հաճախորդ») և հավելվածներ՝ փաստաթղթերի օրինակներ, արտահանումներ ընթացիկ համակարգերից, մրցակիցների սքրինշոթներ՝ «դուր է գալիս» և «դուր չի գալիս» նշումներով։
Ինչպե՞ս գրել մշակման տեխնիկական առաջադրանք՝ սցենարներ ֆունկցիաների ցանկի փոխարեն
Գլխավոր սխալն արտադրանքը էկրանների և կոճակների հավաքածուի տեսքով նկարագրելն է։ Մշակողի համար ավելի կարևոր է հասկանալ, թե ով, ինչու և ինչ հաջորդականությամբ է կատարում գործողությունները։ Ուստի, եթե փորձում եք հասկանալ, թե ինչպես գրել մշակման առաջադրանք այնպես, որ այն բոլորը նույն կերպ հասկանան, սկսեք սցենարներից։
Օգտատիրոջ պատմության բանաձևը
Օգտագործեք պարզ ձևանմուշ՝ «Որպես [դեր]՝ ես ուզում եմ [գործողություն], որպեսզի [արդյունք]»։ Օրինակ՝ «Որպես մենեջեր՝ ես ուզում եմ Telegram-ում ծանուցում ստանալ նոր հայտի մասին, որպեսզի 15 րոպեի ընթացքում կապվեմ հաճախորդի հետ»։
Ընդունման չափանիշներ յուրաքանչյուր պատմության համար
Յուրաքանչյուր պատմությանն ավելացրեք 2–5 ստուգելի պայման։ Վերևի օրինակի համար․
- ծանուցումը գալիս է ձևն ուղարկելուց ոչ ուշ, քան 10 վայրկյան հետո․
- ծանուցման մեջ կան անունը, հեռախոսը, ընտրված ծառայությունը և հայտի աղբյուրը (UTM-պիտակ)․
- «Վերցնել աշխատանքի» կոճակը փոխում է հայտի կարգավիճակը և թաքցնում այն մյուս մենեջերներից․
- եթե մենեջերը 15 րոպեում չի պատասխանել, ծանուցումը ստանում է ղեկավարը։
Այսպես են գրվում պահանջներ, որոնցով կարելի է և՛ գնահատել աշխատանքը, և՛ ընդունել այն։ Բոտերի և Mini App-ի համար սա հատկապես կարևոր է․ այնտեղ տրամաբանությունն ապրում է երկխոսության մեջ, և առանց սցենարների կապալառուն ստիպված է լրացնել բացերը ենթադրություններով։ Մանրամասն այն մասին, թե ինչպես ենք նախագծում վիճակների քարտեզները՝ Telegram-բոտերի մշակման էջում։
Առաջնահերթություններ՝ MoSCoW
Նշեք յուրաքանչյուր ֆունկցիա՝ Must (առանց դրա արտադրանքը չի գործարկվում), Should (պետք է, բայց կարելի է մեկ ամիս անց), Could (լավ կլիներ ունենալ), Won't (հաստատ ոչ այս տարբերակում)։ Այս նշումը արտադրանքի առաջին տարբերակի հիմքն է․ ինչպես ընտրել ֆունկցիաները գործարկման համար, մանրամասն քննարկել ենք MVP-ի մշակման մասին հոդվածում։
Ոչ ֆունկցիոնալ պահանջներ, որոնց մասին մոռանում են
Ֆունկցիաները նկարագրում են, թե ինչ է անում արտադրանքը։ Ոչ ֆունկցիոնալ պահանջները՝ թե ինչպես է այն դա անում։ Հենց դրանք են ամենից հաճախ ի հայտ գալիս գործարկումից հետո և ամենաթանկն են արժենում, եթե դրանց մասին նախապես չեն պայմանավորվել։
- Բեռնվածություն՝ քանի օգտատեր է սպասվում առաջին ամսում և մեկ տարի անց, կա՞ն արդյոք գագաթնակետեր (վաճառքներ, առաքումներ)։
- Արագություն՝ էջերի բեռնման և բոտի պատասխանի թիրախային ժամանակը․ կայքերի համար՝ ուղենիշ ըստ Core Web Vitals-ի։
- Հասանելիություն՝ թույլատրելի պարապուրդի ժամանակը, պե՞տք են արդյոք մոնիթորինգ և հերթապահություն։
- Անվտանգություն՝ ինչ տվյալներ ենք պահում, ով ունի դրանց հասանելիություն, պե՞տք է արդյոք երկգործոն նույնականացում, գործողությունների մատյան։
- Անձնական տվյալներ՝ մշակում ըստ 152-FZ-ի (Ռուսաստանի անձնական տվյալների մասին օրենք), պահպանման տեղայնացում ՌԴ-ում, համաձայնություններ և գաղտնիության քաղաքականություն։
- Տեղակայում՝ ձեր ամպը, սեփական սերվերները կամ փակ միջավայր՝ առանց ինտերնետ հասանելիության։
- Աջակցություն՝ բրաուզերներ, iOS-ի և Android-ի տարբերակներ, ինտերֆեյսի լեզուներ, մատչելիություն տեսողության խնդիրներ ունեցող մարդկանց համար։
- Հանձնում՝ փաստաթղթեր, հասանելիություններ, ռեպոզիտորիա ձեր հաշվի վրա, տեղակայման հրահանգ։
Կայքի տեխնիկական առաջադրանքի օրինակ
Ստորև՝ արտադրական ընկերության կայքի տեխնիկական առաջադրանքի կրճատ օրինակ։ Այն տեղավորվում է երկու էջում և արդեն թույլ է տալիս ստանալ ճշգրիտ գնահատական։
- Նպատակ՝ ստանալ սարքավորումների հաշվարկի հայտեր B2B-հաճախորդներից․ ուղենիշ՝ ամսական 40 որակավորված հայտ գործարկումից 3 ամիս անց։
- Լսարան՝ ձեռնարկությունների ինժեներներ և մատակարարման մասնագետներ, 70%-ը մուտք են գործում դեսքթոփից։
- Դերեր՝ այցելու․ կոնտենտ-մենեջեր (խմբագրում է կատալոգը և նորությունները)․ ադմինիստրատոր (հասանելիություններ, կարգավորումներ)։
- Կառուցվածք՝ գլխավոր էջ, 6 կատեգորիայից և ~120 դիրքից կատալոգ, ապրանքի քարտ՝ PDF-սպեցիֆիկացիայով, քեյսեր, ընկերության մասին, կոնտակտներ, բլոգ։
- Հիմնական սցենար՝ այցելուն ֆիլտրով գտնում է դիրքը → բացում է քարտը → սեղմում «Հարցնել առևտրային առաջարկ» → լրացնում 4 դաշտից ձևը → հայտը գնում է Bitrix24 և վաճառքի բաժնի Telegram։
- Ինտեգրացիաներ՝ Bitrix24 (լիդի ստեղծում), Yandex Metrica՝ նպատակներով, կատալոգի արտահանում 1C-ից օրը մեկ անգամ։
- Դիզայն՝ բրենդբուք կա, պետք են UX-նախատիպ և ադապտիվ տարբերակ բջջայինների համար։
- Ոչ ֆունկցիոնալ պահանջներ՝ էջի բեռնում մինչև 2 վայրկյան 4G-ով, տեխնիկական SEO և միկրոնշագրում, հոստինգ ՌԴ-ում։
- Ընդունում՝ 5-րդ կետի բոլոր սցենարներն անցնում են թեստային միջավայրում, ձևերը հասնում են CRM, Lighthouse Performance՝ 90-ից։
Ուշադրություն դարձրեք․ այստեղ չկան «ժամանակակից», «հարմար» և «վաճառող» բառերը։ Փոխարենը կան թվեր, դերեր, սցենար և չափանիշներ։ Նման փաստաթղթով կապալառուները նշում են համեմատելի գներ, իսկ դուք համեմատում եք առաջարկներ, այլ ոչ թե երևակայություններ։ Թե ինչպիսի կայքեր և վեբ-հավելվածներ ենք պատրաստում, և ինչից է բաղկացած աշխատանքը, կարող եք տեսնել կայքերի մշակման բաժնում։
Տեխնիկական առաջադրանքի հաճախակի սխալները և ինչպես խուսափել դրանցից
| Սխալ | Ինչի է հանգեցնում | Ինչպես ուղղել |
|---|---|---|
| «Ինչպես Avito-ում, միայն ավելի լավ» | Գնահատական 1 մլն-ից մինչև 30 մլն․ բոլորը տարբեր բան են պատկերացրել | Դուրս գրեք ռեֆերենսի 3–5 կոնկրետ ֆունկցիա, որոնք ձեզ պետք են |
| Չկան դերեր և իրավունքներ | Հասանելիության տրամաբանության վերամշակում գործարկումից հետո | «Դեր × գործողություն» աղյուսակ՝ մեկ էջի վրա |
| Ինտեգրացիաներ՝ «ընթացքում կպարզենք» | Ժամկետների տեղաշարժ շաբաթներով, եթե համակարգը API չունի | Նախապես ստուգել, կա՞ արդյոք API, և ով կտա հասանելիություն |
| Ամեն ինչ Must առաջնահերթությամբ | Առաջին տարբերակի բյուջեն աճում է 2–3 անգամ | MoSCoW նշում և ազնիվ ընտրություն գործարկման համար |
| Չկան ընդունման չափանիշներ | Վեճեր հանձնման ժամանակ, անվերջ լրամշակումներ | 2–5 ստուգելի պայման յուրաքանչյուր սցենարի համար |
| Առաջադրանքը գրվում է միայնակ | Բաց են թողնված վաճառքի, աջակցության, հաշվապահության պահանջները | Հարցազրույց ընկերության ներսում յուրաքանչյուր ապագա օգտատիրոջ հետ |
Եվս մեկ թակարդ՝ փորձել նկարագրել ամեն ինչ մինչև վերջին կոճակը դեռ նախատիպից առաջ։ Ինտերֆեյսի մանրամասներն ավելի արագ և էժան են լուծվում սեղմելի նախատիպի վրա՝ տեսնում եք էկրանները, սեղմում, փոխում։ Տեխնիկական առաջադրանքը սահմանում է շրջանակը, նախատիպը լցնում է այն։
Առցանց հարցաթերթիկ՝ տեխնիկական առաջադրանք առանց դատարկ թերթի
Ամենադժվարը սկսելն է։ Ուստի կայքում կա տեխնիկական առաջադրանք կազմելու առցանց հարցաթերթիկ․ այն վերևի կառուցվածքը վերածում է հարցերի հաջորդականության՝ հուշումներով և պատասխանների տարբերակներով։ Զրոյից գրել պետք չէ․ կետերի մեծ մասն ընտրվում է կոճակներով։ Հարցաթերթիկը բաղկացած է 7 բաժնից․
- Ձեր մասին՝ կոնտակտներ, ընկերություն, ձեր դերը նախագծում։
- Արտադրանքի մասին՝ արտադրանքի տեսակ, նպատակ, փուլ, ընթացիկ ստեկ, ռեֆերենսներ և հղումներ փաստաթղթերին։
- Օգտատերեր և դերեր՝ լսարան, դերեր, մասշտաբ, աշխարհագրություն, օգտատիրոջ խնդիր։
- Ֆունկցիոնալություն՝ ֆունկցիաներ, պարտադիր նվազագույն, վճարումներ, ինտեգրացիաներ։
- Հարթակներ և դիզայն՝ որտեղ է աշխատում արտադրանքը, դիզայն, բրենդինգ, կոնտենտ։
- Տվյալներ, AI և անվտանգություն՝ պե՞տք է արդյոք AI, տվյալների միգրացիա, անվտանգության և տեղակայման պահանջներ։
- Բյուջե, ժամկետներ և գործընթաց՝ բյուջե, վերջնաժամկետ և դրա պատճառը, աջակցություն, ձեր մասնակցությունը։
Ուղարկելուց անմիջապես հետո ստանում եք նախնական գնահատական։ Այն տեղեկատվական է․ ճշգրիտ արժեքը նշում ենք ձեզ հետ միասին տեխնիկական առաջադրանքը մշակելուց հետո։ Բոլոր ուղղությունների գնային ուղենիշները հավաքված են մշակման գների էջում։
Հարցեր և պատասխաններ
Ո՞վ պետք է կազմի տեխնիկական առաջադրանքը՝ պատվիրատո՞ւն, թե՞ կատարողը։
Նպատակները, լսարանը, սցենարները և սահմանափակումները ձևակերպում է պատվիրատուն, քանի որ նա գիտի բիզնեսը։ Տեխնիկական բաժինները՝ ճարտարապետությունը, ինտեգրացիաները, ոչ ֆունկցիոնալ պահանջները, ավելի հարմար է լրամշակել կատարողի հետ միասին՝ մշակման փուլում։
Քանի՞ էջ պետք է լինի տեխնիկական առաջադրանքում։
Բոտի կամ լենդինգի համար բավական է 2–4 էջը, կատալոգով և ինտեգրացիաներով կայքի համար՝ 5–10-ը, հարթակի կամ բջջային հավելվածի համար՝ 15–40-ը։ Կարևորը ոչ թե ծավալն է, այլ այն, որ յուրաքանչյուր պահանջ հնարավոր լինի ստուգել։
Հնարավո՞ր է սկսել մշակումն առանց տեխնիկական առաջադրանքի։
Հնարավոր է, եթե աշխատանքն ընթանում է կարճ սպրինտներով՝ շաբաթական ցուցադրություններով և փաստացի վճարմամբ։ Բայց ֆիքսված գնի և ժամկետների համար առանց առաջադրանքի հնարավոր չէ․ առանց դրա գնահատականը մնում է գուշակություն։
Ի՞նչ անել, եթե պահանջները փոխվել են ընթացքում։
Փոփոխությունները ամրագրել գրավոր՝ ինչ է ավելանում, ինչ է հանվում, ինչպես է դա ազդում ժամկետների և բյուջեի վրա։ Լավ պրակտիկա է փոփոխությունների առանձին ռեեստրը, որը համաձայնեցնում են երկու կողմերը։
Ինչո՞վ է տեխնիկական առաջադրանքը տարբերվում բրիֆից։
Բրիֆը նկարագրում է բիզնեսը և խնդիրը ընդհանուր գծերով և անհրաժեշտ է առաջին գնահատման համար։ Տեխնիկական առաջադրանքը մանրամասն ամրագրում է դերերը, սցենարները, ֆունկցիաները, ինտեգրացիաները և ընդունման չափանիշները և դառնում պայմանագրի մաս։