Տեխնիկական առաջադրանքը շատ կարևոր փաստաթուղթ է․ այն ծրագրային ապահովման մատակարարներին ու պետական մարմինների համապատասխան թիմերին տրամադրում է կարևոր տեղեկատվություն նոր ստեղծվող թվային ծառայության մասին:

Մրցութային փաստաթղթերի կազմման շրջանակներում անհրաժեշտ է հետևել ստորև ներկայացված առաջարկներին, որոնք կօգնեն տեխնիկական առաջադրանքը կազմել հնարավորինս համապարփակ և ճկուն, ինչն էլ իր հերթին կնպաստի օգտատերերի համար առավելագույնս արդյունավետ ծառայությունների ստեղծմանը։

1. Ընդգծեք այն վերջնարդյունքը, որը ստանալու է օգտատերը

Հասկանալի կերպով բացատրեք, թե ինչ ծառայություններ կամ վերջնարդյունք է ապահովելու նոր ստեղծվող հարթակն օգտատերերի համար։ Դա կարող եք իրականացնել «օգտատերերի պատմության (“User Story”)» ձևաչափով, օրինակ՝

«Որպես ձեռնարկատեր՝ ես պետք է առցանց, արագ և հեշտ գրանցեմ իմ կազմակերպությունը, որպեսզի կարողանամ աշխատել»:

2. Խուսափեք լայնամասշտաբ մոտեցումից

Գուցե գայթակղիչ լինի լայնամասշտաբ (large portal) այնպիսի լուծման մշակումը, որը կարող է ներգրավել մի ոլորտի բազմաթիվ ծառայություններ: Այնուամենայնիվ դա կարող է հանգեցնել տեխնիկական առավել բարդ լուծումների և ավելի ցածր որակի, քանի որ ծրագրային մատակարարները ստիպված կլինեն բազմաթիվ ծառայությունների վերջնաժամկետներ պահպանել։

Առաջարկում ենք՝

  • ստեղծել այնպիսի տեխնիկական բնութագրեր, որոնք կվերաբերեն 1-ից 5 ծառայության: Ծառայությունները պետք է լինեն փոխկապակցված և նույն ոլորտից,
  • բազմաթիվ ծառայությունների ձեռքբերումը չկապել միևնույն մատակարարի հետ՝ այդպիսով ստեղծելով կախվածություն նրանից։   

3. Նշեք ծառայությունների հետ կապված մանրամասներն ու սահմանափակումները

Կարող են լինել հատուկ կարիքներ կամ սահմանափակումներ, որոնք ծրագրային ապահովման մատակարարը պետք է հաշվի առնի։ Օրինակ՝ ապահովել, որ ծառայությունն աշխատի որևէ տեխնոլոգիայով կամ հասանելի լինի որոշակի ժամանակահատվածում և այլն։

Այս բոլոր մանրամասները դուք պետք է կցեք օգտատերերի կարիքներին և այն վերջնարդյունքին, որ ցանկանում եք տրամադրել՝ սահմանելով դրանց առաջնահերթությունները։

4. Ժամանակ հատկացրեք հետազոտություններին

Տեխնիկական առաջադրանքը  կարևոր ուղեցույց է, սակայն պետք է նկատի ունենալ, որ իրադրությունն ու կարիքները կարող են փոփոխվել: Նախագծի ճկունության ապահովման նպատակով առաջարկում ենք՝ 

  • հետազոտություններն իրականացնել նախագծի սկզբնական փուլում: Դրանք կարող են լինել  4-6 շաբաթ տևողությամբ աշխատանք մատակարարի հետ՝ օգտատերերին հետազոտելու և պահանջները ձևակերպելու նպատակով,
  • նախագծի ժամանակացույցում ներառել կարճաժամկետ դադարի կետեր, ինչը թույլ կտա պարբերաբար գնահատել աշխատանքների ներկա կարգավիճակը և հետագա զարգացումները՝ անհրաժեշտության դեպքում խզելով պայմանագիրը, եթե, օրինակ, պահանջներում զգալի փոփոխություններ են տեղի ունեցել: 

5. Կազմեք իրատեսական ժամանակացույցներ

Կարող են լինել քաղաքական կամ այլ բնույթի սահմանափակումներ, որոնց պարագայում ծառայությունը կոնկրետ ժամանակահատվածում պետք է հասանելի լինի: Թեև սա կարևոր է, այնուամենայնիվ չափազանց հավակնոտ ժամանակացույցները կարող են ավելի երկարաժամկետ խնդիրների հանգեցնել, ինչպիսիք են՝ 

  • ցածրորակ աշխատանքը ոչ իրատեսական վերջնաժամկետների պատճառով,
  • սուղ ժամկետներով պայմանավորված՝ ծրագրային ապահովման պոտենցիալ մատակարարների մասնակցության իրավունքի սահմանափակումը։

Ծառայությունների ստեղծման վերջնաժամկետներ սահմանելիս առաջարկում ենք հաշվի առնել հետևյալ գործոնները.

  • որքանո՞վ է հասկանալի օգատատիրոջ պահանջը, որը դուք փորձում եք լուծել,
  • արդյոք նախագծի թիրախում ներառվա՞ծ են նաև հատուկ կարիքներ ունեցող անձանց խմբերը, ինչպիսիք են հաշմանդամություն ունեցողները,
  • կա՞ արդյոք նույնանման նախագծի նախադեպ, և որքա՞ն է այն տևել, 
  • կարո՞ղ են արդյոք ծառայության որոշ հատվածներ ավելի շուտ հրապարակվել:  


Միջազգային փորձը ցույց է տալիս, որ ծառայության ամբողջական ստեղծման միջին տևողությունը 8-14 ամիս է: Իսկ թվային ծառայությունների ձեռքբերման տեխնիկական բնութագրերի կազմման աշխատանքներում Հայաստանի տեղեկատվական համակարգերի գործակալության թիմը պատրաստ է աջակցելու․ կապ հաստատեք մեզ հետ էլ․ փոստի հետևյալ հասցեով՝ info@isaa.am: