Shaxsiy kabinet va portallar: ishlab chiqishda nima muhim

Shaxsiy kabinet allaqachon shunchaki "profil sahifasi" bo'lishdan to'xtagan. Bugun bu mijoz, hamkor yoki xodimning ish joyi bo'lib, undan pul, hujjatlar va shaxsiy ma'lumotlar o'tadi. Kabinet arxitekturasidagi xato landing sahifadagi xatodan qimmatroq turadi: bu yerda konversiya emas, balki ishonch, ba'zan esa qonun buziladi. Quyida OneDev jamoasi kabinet yoki korporativ portal loyihalashda birinchi navbatda nimalarga e'tibor berishini keltiramiz.

Rollar va ruxsatlar: poydevor, "keyin" sozlanadigan narsa emas

Eng keng tarqalgan xato — ekranlardan boshlab, rollar modelini oxirida ulashdir. Natijada "admin hamma narsani qila oladi", qolganlarga esa ruxsatlar qo'lda va tartibsiz beriladigan tizim chiqadi. Yarim yildan so'ng buxgalterda integratsiya sozlamalariga nega ruxsat borligini hech kim eslay olmaydi.

To'g'ri yo'l — rollarni qat'iy "lavozimlar" orqali emas, balki ruxsatlar (permissions) orqali oldindan tavsiflashdir. Rol — bu amallar va obyektlarga ruxsatlar to'plami. Shunda yangi lavozimni kodni qayta yozmasdan, tayyor bo'laklardan yig'asiz.

• RBAC (rollarga asoslangan ruxsat) B2B kabinetlarning 90 foizini qoplaydi: operator, menejer, buxgalter, egasi.
• ABAC / scoping ruxsat ma'lumotlarga bog'liq bo'lganda kerak: "menejer faqat o'z filialini ko'radi", "hamkor faqat o'z mijozlarini".
• Ko'p akkaunt va delegatlash: bir kishi bir nechta tashkilotda ishlaydi, egasi huquqlarni o'rinbosariga topshiradi.

Kabinet UX: tezlik va bashoratlilik go'zallikdan muhimroq

Kabinetdan har kuni va uzoq vaqt foydalaniladi — bu birinchi taassurot uchun vitrina emas. Bu yerda "voy" emas, balki insonning vazifani minimal bosishda bajarishi va tugmani bosishdan qo'rqmasligi qadrlanadi.

Amaliyotda biz e'tibor beradigan jihatlar:

• Tushunarli navigatsiya va holat. Foydalanuvchi qayerdaligini, nima yuklanayotganini, nima saqlanganini va nima yo'qligini doim ko'rishi kerak.
• Bo'sh holatlar va onboarding. Yangi mijoz nima qilishni bilmasdan bo'sh ekranga qaramasligi kerak.
• Insoniy xatolar. "Error 500" emas, balki nima bo'lgani va nima qilish kerakligi. Ayniqsa to'lovlar va hujjat yuklashda.
• Ro'yxatlar unumdorligi. Minglab qatorlar — bu sahifalash, serverdagi filtr va kesh, frontda hammasini yuklab filtrlash emas.
• Mobil va til. O'zbekistonda kabinet ko'pincha telefondan ochiladi, interfeys esa kamida ikki-uch tilda kerak (o'zbekcha, ruscha, English). Lokalizatsiya darhol yo'lga qo'yiladi.

Integratsiyalar: kabinet kamdan-kam o'zicha yashaydi

Portal deyarli har doim boshqa tizimlar bilan bog'langan tugun bo'ladi. O'zbekiston bozori uchun odatiy integratsiyalar to'plami shunday ko'rinadi:

• To'lovlar: Payme, Click, Uzum, banklar ekvayringi. Veb-xuklarni to'g'ri qayta ishlash va statuslarni solishtirish muhim, frontdan kelgan bitta javobga ishonmaslik kerak.
• Hujjat aylanmasi va soliqlar: Didox, EHF, buxgalteriya uchun eksportlar.
• Identifikatsiya: OneID, SMS-provayderlar (Eskiz, Play Mobile), zarur bo'lsa — JSHSHIR bo'yicha tekshirish.
• Ichki tizimlar: 1C, CRM, ERP, ombor va logistika servislari.

Integratsiyalarning asosiy qoidasi — izolyatsiya. Tashqi servis sekinlashishi, javob formatini o'zgartirishi yoki vaqtincha ishlamasligi mumkin. Kabinet u bilan birga qulamasligi kerak. Bu navbatlar, qayta urinishlar, taymautlar va to'lov amallarining idempotentligini anglatadi — toki ikki marta kelgan veb-xuk pulni ikki marta yechib olmasin.

Xavfsizlik: shaxsiy ma'lumotlar va pul bir joyda

Kabinet sezgir narsalarni jamlaydi: kontaktlar, hujjatlar, to'lov ma'lumotlari, ba'zan — uchinchi shaxslar ma'lumotlari. Asosiy, ammo majburiy choralar to'plami:

• Autentifikatsiya. Ishonchli sessiyalar, brute-force'dan himoya, pul va sozlamalarga ruxsati bor rollar uchun ixtiyoriy ikki faktorli kirish.
• Har so'rovda avtorizatsiya. Huquqlarni tekshirish backendda har bir amal bo'yicha bo'lishi kerak, "frontda tugmani yashirdik" emas. Yashirin tugma — himoya emas.
• Ijarachilar o'rtasida ma'lumotlar izolyatsiyasi. Ko'p akkauntli portallarda eng xavfli baglar — bir mijoz to'g'ridan-to'g'ri havola yoki ID almashtirish orqali begona ma'lumotlarni ko'rgani. Bu MB so'rovlari darajasida tekshiriladi.
• Shifrlash va sirlarni saqlash. Tokenlar va kalitlar kodda yoki git'da emas, himoyalangan saqlovda. Trafik — faqat HTTPS orqali.
• Ma'lumotlarni minimallashtirish. Ortiqcha narsani yig'maslik va saqlamaslik; saqlanmagan narsa sizib chiqolmaydi.

Audit va kuzatuvchanlik: nima bo'layotganini ko'rish

Kabinetda pul va hujjatlar aylanganda ertami-kechmi "kim va qachon buni qildi" degan savol paydo bo'ladi. Amallar jurnali bo'lmasa javob bo'lmaydi, mijoz yoki xodim bilan nizo esa so'zga qarshi so'zga aylanadi.

• Amallar jurnali (audit log): kim, nimani, qachon, qaysi qurilmadan o'zgartirgani. Ayniqsa to'lovlar, ruxsatlar va rekvizitlarni o'zgartirish uchun.
• Yozuvlar o'zgarmasligi: loglarni kabinetning o'zidan tahrirlash mumkin emas — aks holda ular dalil kuchini yo'qotadi.
• Monitoring va ogohlantirishlar: xatolar, to'lovlardagi rad etishlar ko'payishi, integratsiyalar ishlamasligi — buni jahli chiqqan mijozdan emas, tizimdan bilgan yaxshiroq.
• Mahsulot metrikalari: nima haqiqatan ishlatiladi, qayerda tiqilib qoladi. Bu taxminlar emas, kabinetni rivojlantirish uchun asos.

Audit — bu qo'llab-quvvatlash qulayligi hamdir: mijoz "to'lovim o'tmadi" deb yozganda, log bo'yicha aynan nima buzilgani taxminlarsiz va uzoq yozishmalarsiz ko'rinadi.