IT-loyiha uchun texnik topshiriq — bo‘lg‘usi tizim nimani bajarishi, qanday cheklovlarda ishlashi va qaysi belgilar bo‘yicha ish qabul qilinishini tasvirlaydigan hujjat. Yaxshi texnik topshiriqni istak ro‘yxati sifatida emas, tekshirib bo‘ladigan talablar to‘plami sifatida yozadi: shu hujjat bo‘yicha turli pudratchilar bir xil hajmni baholaydi, qabul esa oldindan kelishilgan mezonlar bo‘yicha o‘tadi.
Qisqacha
Texnik topshiriq — biznes vazifasini tizimga qo‘yiladigan talablar va qabul qoidalari bilan bog‘laydigan loyihaning asosiy hujjati. Uni qo‘shni hujjatlar bilan chalkashtiradilar, garchi ularni turli odamlar va turli paytda yozsa ham.
| Hujjat | Odatda kim yozadi | Ichida nima bor | Qachon kerak |
|---|---|---|---|
| Brif | Buyurtmachi | Biznes so‘zlaridagi vazifa: ishlashga nima xalaqit beradi, nimaga erishmoqchimiz, byudjet doirasi | Eng boshida, pudratchilar bilan suhbatdan oldin |
| Texnik topshiriq | Analitik buyurtmachi bilan birga | Maqsadlar, chegaralar, jarayonlar, funksional va nofunksional talablar, integratsiyalar, qabul mezonlari | Narxni baholash va shartnoma imzolashdan oldin |
| Dasturiy ta’minotga talablar spetsifikatsiyasi (SRS) | Ijrochi tomonidan analitik | Mahsulotga batafsil talablar: ssenariylar, ekran holatlari, xatoliklarni qayta ishlash, hisob-kitob qoidalari | Ishlab chiqish ichida, texnik topshiriqni tafsiflaydi |
| Ishlar spetsifikatsiyasi (SOW) | Loyiha menejeri va yurist | Ishlar tarkibi, bosqichlar, har bosqich natijasi, javobgarlik va to‘lov tartibi | Shartnomaga ilova sifatida |
Bu hujjatlarning nomlari turli kompaniyalarda farq qiladi, shuning uchun shartnomada bo‘limlar ro‘yxati va nima kelishilgan versiya hisoblanishi yoziladi. Umumiy rama ISO/IEC/IEEE 29148:2018 standartida tasvirlangan: u talablar bilan ishlash jarayonlarini va talab yaroqli hisoblanadigan belgilarni belgilaydi.
Bo‘limlar to‘plami nima ishlab chiqilayotganiga deyarli bog‘liq emas — CRM, portal yoki mobil ilova: tarkib o‘zgaradi, tuzilma emas. Quyidagi jadval — hujjatning ishchi mundarijasi.
| Bo‘lim | Nima yozish kerak | Misol |
|---|---|---|
| Loyiha maqsadi | Tizim biznesning qaysi vazifasini hal qiladi va u hal qilinganini nimadan bilib bo‘ladi | Oylik hisobotni yig‘ish vaqtini qisqartirish: hozir ma’lumotlar uchta tizimdan qo‘lda yig‘iladi |
| Chegaralar | Loyihaga nima kiradi va nima kirmaydi — ikkinchisi birinchisidan muhimroq | Ombor va xaridlar kiradi, ish haqi hisob-kitobi buxgalteriya dasturida qoladi |
| Joriy jarayonlar | Ish hozir qanday tuzilgan: kim nima qiladi, ma’lumotlar qayerdan olinadi, qolda kiritish qayerda bor | Murojaatdan jo‘natishgacha bo‘lgan buyurtma qabul qilish sxemasi, barcha ishtirokchilar bilan |
| Rollar va huquqlar | Tizimdan kim foydalanadi va har bir rolga nima ochiq | Omborchi qoldiqlarni ko‘radi, lekin tannarx va xarid narxlarini ko‘rmaydi |
| Funksional talablar | Tizim nima qiladi, har bandda bitta tekshirib bo‘ladigan talab | Tizim taqsimlash qoidasi bo‘yicha arizaga mas’ul tayinlaydi va uni xabardor qiladi |
| Nofunksional talablar | Yuklama, tezlik, mavjudlik, xavfsizlik, interfeys tillari, qurilmalar | Bir vaqtda 50 tagacha foydalanuvchi ishlaydi, interfeys rus va o‘zbek tillarida |
| Integratsiyalar | Nima bilan ma’lumot almashadi, qaysi tomonga, qanchalik tez-tez va kim haqiqat manbai | Qoldiqlar hisob tizimidan soatiga bir marta keladi, ular bo‘yicha asosiy manba — ombor |
| Ma’lumotlar va ularning joylashuvi | Nima saqlanadi, qancha, baza va nusxalar fizik qayerda yotadi | Mijozlarning shaxsiy ma’lumotlari: tarkibi, saqlash muddati, joylashuv maydonchasi |
| Ma’lumotlarni ko‘chirish | Eski tizimlardan nima, qanday shaklda va qaysi sanaga ko‘chiriladi | Ishga tushirish sanasidagi ma’lumotnomalar va qoldiqlar, oldingi ikki yillik buyurtmalar tarixi |
| Qabul mezonlari | Qaysi tekshiruvlar ish bajarilganini tasdiqlaydi | Yigirma buyurtma arizadan jo‘natishgacha bazada qo‘lda tuzatishlarsiz o‘tadi |
| Buyurtmachida nima qoladi | Manba kod, hujjatlar, kirishlar, natijaga huquqlar | Kod kompaniya repozitoriyasida, foydalanuvchilar uchun ko‘rsatmalar, serverlarga kirishlar |
Joriy jarayonlar bo‘limini matn bilan emas, sxema bilan chizish qulayroq: OMG konsorsiumining BPMN 2.0 kabi umumqabul qilingan notatsiyadagi sxemani ham rahbar, ham dasturchi o‘qiy oladi. Ma’lumotlar joylashuvini ham oldindan belgilab qo‘yish kerak: O‘zbekiston ichida majburiy saqlash biometrik va genetik ma’lumotlarga hamda aloqa abonentlari ma’lumotlariga tegishli — bu shaxsga oid ma’lumotlar to‘g‘risidagi qonunning 27-1-moddasi, qolgan ma’lumotlarni esa o‘sha moddaning shartlariga rioya qilgan holda chet elda saqlash mumkin.
Talab ikki xil tushunilmasa va tekshirib bo‘lsa — yaroqli. ISO/IEC/IEEE 29148 standarti yaxshi talab belgilari qatorida zarurlik, bir ma’nolilik, yagonalik, bajarilishi mumkinlik va tekshirilishini sanaydi — ya’ni bitta talab bitta narsani tasvirlaydi va uni tekshirish usuli tushunarli bo‘ladi.
| Yomon | Nega ishlamaydi | Yaxshi |
|---|---|---|
| Qulay interfeys | Tekshirib bo‘lmaydi va soatlarda baholab bo‘lmaydi | Buyurtma rasmiylashtirish to‘rttadan ortiq ekranni egallamaydi va oynalar orasida almashishni talab qilmaydi |
| Tizim tez ishlashi kerak | Na raqam, na uni o‘lchaydigan shartlar bor | 50 ta bir vaqtda ishlayotgan foydalanuvchida 10 000 ta buyurtma ro‘yxati 2 soniyada ochiladi |
| Hisob tizimi bilan integratsiya | Nima uzatilishi, qaysi tomonga va qanchalik tez-tez ekani aytilmagan | Omborlar bo‘yicha qoldiqlar hisob tizimidan soatiga bir marta uzatiladi; almashishda xatolik bo‘lsa mas’ul xabardor qilinadi |
| Sotuvlar bo‘yicha hisobotlar | Aynan qaysilari va kimga kerakligi noma’lum | Kanal bo‘yicha filtri va jadvalga chiqarilishi bilan «menejerlar bo‘yicha tushum» hisoboti |
| Tizim o‘sishni ko‘tarishi kerak | O‘sish ko‘zda tutilgan deb hisoblanadigan chegara yo‘q | Tizim arxitekturani almashtirmay 200 foydalanuvchi va buyurtmalar sonining uch barobar o‘sishiga mo‘ljallangan |
Har bir talab raqamlanadi: raqamlarga keyin bahoda, ishlar rejasida va qabul aktida havola qilinadi. «va», «yoki», «zarur bo‘lsa» so‘zlarini o‘z ichiga olgan talab odatda ikki yoki uchga bo‘linadi — ularni darhol ajratgan ma’qul.
Qabul mezoni — natijasi taraflar kayfiyatiga bog‘liq bo‘lmagan tekshiruv tavsifi. U bo‘lmasa, loyiha tayyorligi haqidagi nizo hujjat emas, ishontirish bilan hal qilinadi.
Misol «Bizga CRM kerak» ta’rifi na bahoga, na qabulga yaramaydi. Ishlaydigan variant shunday ko‘rinadi: «Telegram’dan, saytdan va telefondan kelgan barcha arizalar manbasi ko‘rsatilgan holda bitta tizimga tushadi; rahbar istalgan kun uchun voronkani ko‘radi; qabulda uchala kanaldan 20 ta arizani tekshiramiz».
Xatolar loyihadan loyihaga takrorlanadi, va deyarli barchasi hujjat kompaniya ishini tushunmasdan yozilgani sababli paydo bo‘ladi.
Uch variant bor, va har birining o‘z narxi va o‘z xavfi bor. Tanlov ichkarida talablarni tasvirlay oladigan odam bor-yo‘qligiga va xato narxiga bog‘liq.
Muhim Syntra Systems — ishlab chiquvchi, shuning uchun o‘z manfaatimizni darhol aytamiz. Topshiriqda allaqachon sotib olingan tizimlarni sozlash va qoidalarni o‘zgartirish bilan, dasturlashsiz yopiladigan qismni alohida belgilaymiz, hujjatni esa tahrirlanadigan holda beramiz — u bilan istalgan pudratchiga borish mumkin.
Tayyorlash hujjatdan emas, kompaniya ishini tahlil qilishdan boshlanadi: aks holda talablar jarayonni emas, jarayon haqidagi tasavvurni tasvirlaydi.
Tayyorlash qancha vaqt olishi jarayonlar, tizimlar va ishtirokchilar soniga bog‘liq, shuning uchun hajm tekshiruvdan keyin baholanadi. Infratuzilmani tahlil qilish — alohida ish, u IT-infratuzilma auditi haqidagi maqolada va IT-konsalting qanday tuzilgan haqidagi maqolada tasvirlangan.
Hujjatni bahoga jo‘natishdan oldin, ro‘yxat bo‘yicha o‘ting. Bajarilmagan har bir band — kelajakdagi qo‘shimcha kelishuv.
Barcha pudratchilar hujjatning bir xil versiyasini olganini tekshiring. Aks holda takliflar solishtirib bo‘lmaydigan bo‘lib qoladi, tanlov esa orqasida turli hajmdagi ish turgan summalarni solishtirishga aylanadi.
Batafsil texnik topshiriq soha tushunarli va barqaror bo‘lgan joyda yaxshi ishlaydi: hisob, hujjat aylanishi, integratsiyalar, mavjud jarayonni tizimga ko‘chirish. Qiymati foydalanuvchilarda tekshiriladigan mahsulotlarda esa yomonroq ishlaydi.
Moslashuvchan yondashuvlar talablar o‘zgarib turishidan to‘g‘ridan-to‘g‘ri kelib chiqadi: Agile tamoyillari kech bosqichlarda ham talab o‘zgarishini qarshi olishni va ishlaydigan mahsulotni ilgarilashning asosiy o‘lchovi deb hisoblashni taklif qiladi. Shundan boshqa asboblar ham kelib chiqadi — vazifalar ro‘yxati (backlog), foydalanuvchi hikoyalari, sprintlar bo‘yicha qabul.
Amalda yondashuvlar birlashtiriladi. Rama topshiriq maqsadlarni, chegaralarni, nofunksional talablarni, integratsiyalarni va qabul qoidalarini belgilaydi — kamdan-kam o‘zgaradigan narsani. Funksiyalar tafsiloti backlogda yashaydi, hajm o‘zgarishlari esa kelishilgan tartibdan o‘tadi: baho, buyurtmachi qarori, reja tuzatilishi.
Bizda saytda narxi bo‘lgan alohida «texnik topshiriq tayyorlash» xizmati yo‘q: tekshiruv va topshiriq — ishlab chiqishning birinchi bosqichi, hajm esa chegaralar aniqlangandan keyin hisoblanadi. ERP loyihalarida bosqich ishlar tarkibida to‘g‘ridan-to‘g‘ri tasvirlangan: jarayonlarni, hujjat aylanishini va qaror qabul qilish nuqtalarini tasvirlaymiz, ma’lumotlar modelini loyihalaymiz, topshiriq tayyorlaymiz va bosqichlarni kelishamiz — narxlar ERP-tizimlar sahifasida.
Pudratchilar takliflarini solishtirishni o‘z xizmatimiz deb atamaymiz: unda biz manfaatdor tomonmiz. Bu vazifa uchun alohida asbob bor — IT Caravan qanday paydo bo‘lgani haqidagi maqolada aytib bergan ijrochilar katalogi.
Biz tekshiruvdan boshlaymiz va baholash hamda qabul qilish mumkin bo‘lgan hujjat bilan yakunlaymiz: maqsadlar, chegaralar, jarayonlar, raqamlangan talablar, integratsiyalar, qabul mezonlari va bosqichlar rejasi. Topshiriq sxemalar bilan birga buyurtmachida tahrirlanadigan holda qoladi.
Vazifangizni muhokama qilamiz
Nima qilish kerakligini yozing — muddat va narxni baholab, yechim taklif qilamiz.
Kichik dorabotka uchun — ha, vazifa tavsifi va tayyorlik mezoni yetarli. Sezilarli pulga tushadigan loyiha uchun topshiriqsiz na pudratchilar takliflarini solishtirib bo‘ladi, na ishni yopib bo‘ladi: qabulda taraflar aynan nima buyurtma qilinganini har xil tushunib qoladi.
Normasi yo‘q: hajm jarayonlar, rollar va integratsiyalar soniga bog‘liq. Yomon hujjatning belgisi hajmi emas, balki qabulda hech kim tekshirmaydigan bo‘limlar. Talabni tekshirib bo‘lmasa, u necha bet ekaniga qaramay qiymat qo‘shmaydi.
Texnik topshiriq biznes vazifasini talablar va qabul qoidalari bilan bog‘laydi va shartnomadan oldin yoziladi. SRS — dasturiy mahsulotga qo‘yiladigan talablarning batafsil spetsifikatsiyasi: ssenariylar, ekran holatlari, xatoliklarni qayta ishlash. Uni odatda ijrochi jamoasi ishlab chiqish ichida tayyorlaydi.
Bu shartnoma masalasi. Natijaga bo‘lgan huquqlarni, manba kodini, hujjatlarni va kirishlarni topshirish sharti ishlar boshlanishidan oldin yoziladi va ular buyurtmachiga qachon o‘tishi ko‘rsatiladi. Bu shartnomada bo‘lmasa, nizoni sizning kutganingiz emas, umumiy qoidalar bo‘yicha hal qilishga to‘g‘ri keladi.
Uning rama qismi kerak: maqsadlar, chegaralar, nofunksional talablar, integratsiyalar va qabul qoidalari. Funksiyalar tafsiloti backlogda yashaydi va ish davomida aniqlashtiriladi. Hujjatdan butunlay voz kechish xavfli — aks holda loyiha tugaganini tasdiqlaydigan hech narsa qolmaydi.
To‘laydi buyurtmachi, va bu normal amaliyot: hujjat unda qoladi va istalgan pudratchi bilan suhbatga yaroqli bo‘ladi. Agar topshiriqni bo‘lg‘usi ijrochi bepul tayyorlasa, uning qiymati baribir loyiha smetasiga tushadi — faqat sezilmagan holda va hujjatni olib ketish huquqisiz.
Istalgan talabni oling va uni qanday tekshirishingizni hamda buni kim qilishini so‘rang. Har bir bandda javob bo‘lsa, hujjatda loyiha chegaralari va qabul tartibi tasvirlangan bo‘lsa — topshiriq ishlaydi. Javoblar bo‘lmasa, loyihani topshirishda nizo muqarrar.
