Dasturiy ta'minot ishlab chiqish uchun texnik topshiriqni qanday tuzish kerak

Texnik topshiriq nima uchun kerak

Texnik topshiriq (TT) — bu buyurtmachining g'oyasini mahsulotga qo'yiladigan tekshirib bo'ladigan talablar to'plamiga aylantiruvchi hujjat. Usiz tomonlar deyarli har doim loyihani turlicha tushunadi: buyurtmachi miyasida bir manzarani saqlaydi, ijrochi boshqasini quradi, taqdimotda esa kutilgan funksiyaning yarmi "nazarda tutilgan", lekin hech qayerda qayd etilmagani ma'lum bo'ladi.

O'zbekiston bozorida bu ayniqsa og'riqli. Ishlab chiqish buyurtmalarining katta qismi o'z IT-bo'limiga ega bo'lmagan kompaniyalardan keladi: savdo, logistika, xususiy klinikalar, ta'lim markazlari, fintex-startaplar. Ular o'z biznesini yaxshi biladi, lekin dasturga talablarni shakllantira olmaydi. Natijada "og'zaki" kelishadi, keyin esa Payme va Click integratsiyasi dastlabki smetaga kirganmi yoki yo'qmi deb bahslashadi.

TT bir vaqtning o'zida uch vazifani hal qiladi: ishlar hajmini (demak byudjetni ham) qayd etadi, qabul mezonlarini beradi va ikkala tomonni yuridik jihatdan himoya qiladi. Bu shartnomaga ilova bo'lib, kelishmovchilik bo'lganda unga murojaat qilish mumkin.

TT tuzilmasida nima bo'lishi kerak

Yaxshi TT qalin bo'lishi shart emas. U to'liq va aniq bo'lishi kerak. Minimal ishchi tarkibi quyidagicha:

• Loyiha maqsadi va konteksti. Qanday biznes-vazifani hal qilyapmiz, foydalanuvchilar kim, muvaffaqiyat nima hisoblanadi. Busiz ijrochi oqilona muqobillarni taklif qila olmaydi.
• Rollar va kirish huquqlari. Administrator, operator, mijoz kim, ularning har biriga nima ruxsat etiladi va nima taqiqlanadi.
• Funksional talablar. Ekranlar va ssenariylar tavsifi: bosilganda nima sodir bo'ladi, qaysi maydonlar majburiy, qanday tekshiruvlar. Eng yaxshisi — foydalanuvchi ssenariylari ko'rinishida.
• Nofunksional talablar. Yuklama, javob tezligi, xavfsizlik, interfeys tillari (O'zbekiston uchun deyarli har doim o'zbek, rus, ko'pincha ingliz), xosting talablari.
• Integratsiyalar. To'lov tizimlari (Payme, Click, Uzum), SMS-shlyuzlar (Eskiz, Play Mobile), 1С, Soliq/EHF, Telegram. API versiyalari va ruxsatlarni kim beradi — ko'rsating.
• Dizayn va brendbuk. Tayyor maketlar, firma uslubi bormi yoki bu ham ishlar tarkibiga kiradimi.
• Bosqichlar, muddatlar va qabul mezonlari. Har bir bosqichning tayyor natijasi nima hisoblanadi.

Texnik topshiriqni kim yozadi

Keng tarqalgan adashuv: "TTni dasturchi yozishi kerak". Amalda javobgarlik bo'linadi. Biznes tomoni nima va nima uchun degan savolga javob beradi, texnik tomon — qanday deganiga.

Ideal variant: buyurtmachi biznes-talablarni (maqsadlar, jarayonlar, cheklovlar) tayyorlaydi, ijrochining tahlilchisi yoki loyiha menejeri esa ularni ekranlar, ssenariylar va integratsiyalar bilan texnik topshiriqqa aylantiradi. So'ngra hujjat imzodan oldin buyurtmachi bilan kelishiladi.

Agar buyurtmachida ichki ekspertiza bo'lmasa, TTni alohida pullik xizmat sifatida — asosiy ishlab chiqishdan oldin alohida kichik bosqich sifatida buyurtma qilish oqilona. Bu tayyor mahsulotni qayta ishlashdan arzonroq va boshqa ijrochilarga narxlarni solishtirish uchun borish mumkin bo'lgan hujjat beradi.

Texnik topshiriqlardagi tez-tez uchraydigan xatolar

Yillar davomida bir xil muammolar takrorlanadi:

• Noaniq ifodalar. "Qulay interfeys", "tez ishlash", "zamonaviy dizayn" — bu talab emas, ularni tekshirib bo'lmaydi. O'lchanadigan ifoda bilan almashtiring: "1000 yozuvdan iborat ro'yxat 2 soniyagacha ochiladi".
• Salbiy ssenariylar yo'qligi. Faqat ideal yo'l tasvirlangan, to'lov xatosi, buyurtma bekori, dublikat bo'lganda nima qilish kerakligi aytilmagan. Aynan shu yerda buglar va qo'shimcha ishlarning aksariyati tug'iladi.
• Ustuvorliklar yo'q. Hamma narsa "juda muhim" bo'lganda, byudjet va muddatlar portlaydi. Majburiy (MVP) va istalganga ajrating.
• Mahalliy sharoitlarni e'tiborsiz qoldirish. Ko'p tillilik, mahalliy to'lov tizimlari xususiyatlari, Soliq uchun EHF va hisobot unutilgan. Bu oxirida chiqib, muddatlarni buzadi.
• Versiyalashsiz TT. Talablar o'zgaradi — bu normal. Lekin o'zgarishlar yozma ravishda qo'shimcha sifatida qayd etilishi kerak, aks holda qo'shimcha to'lov haqida bahs muqarrar.

Natijani TT bo'yicha qanday qabul qilish kerak

Qabul qilish — bu "qaradim, ishlayotganga o'xshaydi" emas. Bu tayyor mahsulotni TTdagi mezonlar bilan solishtirish. U tinch o'tishi uchun qabul mezonlarini oldindan, hujjatni kelishish bosqichidayoq yozib qo'yish kerak.

Qabul qilishning ishchi tartibi:

• Ijrochi versiyani buyurtmachi kira oladigan test stendiga joylaydi.
• Buyurtmachi TTdagi ssenariylar bo'yicha o'tadi — har bir band bo'yicha "qabul qilindi / izoh" deb qayd etadi.
• Izohlar buglarga (TTga mos kelmaslik — ijrochi smeta doirasida tuzatadi) va yangi istaklarga (talablar o'zgarishi — qo'shimcha to'lov sifatida rasmiylashtiriladi) bo'linadi.
• Buglar yopilgandan so'ng bosqich bo'yicha dalolatnoma imzolanadi.

Aynan shuning uchun TT ikkala tomon uchun ham foydali. Buyurtmachi "oxirigacha qilinmadi"dan himoyalangan, ijrochi esa kengayib boruvchi kutilmalar ostidagi cheksiz bepul tuzatishlardan.