GovTech-də sürət yeni innovasiyadır: İRİA-da Specification-Driven Development yanaşması ilə məhsul inkişafını necə dəyişdik

Dövlət xidmətlərinin rəqəmsallaşdırılmasında ən böyük çağırışlardan biri artıq yalnız texnologiyanın seçilməsi deyil.

Əsas sual budur:

Vətəndaşa real dəyər yaradan rəqəmsal xidməti nə qədər sürətli, keyfiyyətli və dayanıqlı şəkildə təqdim edə bilərik?

GovTech mühitində bu sual daha böyük əhəmiyyət daşıyır. Çünki burada development sürətinin arxasında sadəcə məhsulun “go-live” olması dayanmır. Söhbət vətəndaşın dövlət xidmətinə çıxışının sürətindən, dövlət qurumları arasında inteqrasiyanın çevikliyindən və yeni xidmətlərin təkrar istifadə oluna bilən rəqəmsal infrastruktur üzərində daha sürətli qurulmasından gedir.

Ölkə başçısının 2026-2028-ci illər üçün rəqəmsallaşmanın sürətləndirilməsi strategiyasına uyğun olaraq, bu çeviklik məhz GovTech arxitekturasının təməl dəyərlərindən olan “Once-Only” (məlumatın vətəndaşdan yalnız bir dəfə soruşulması və ilkin mənbədən əldə edilməsi) prinsipi üzərində qurulur. Məlumatlar ilkin mənbədən təhlükəsiz şəkildə çağırıldıqda, həm bürokratik ləngimələr sıfıra enir, həm də inkişaf (development) komandaları üçün innovativ xidmətləri daha sürətlə ərsəyə gətirmək imkanı yaranır.

İnnovasiya və Rəqəmsal İnkişaf Agentliyində mygov-un inkişaf yolunda qarşılaşdığımız əsas çağırışlardan biri məhz bu idi.

e-Sosial mobil tətbiqində mövcud olan xidmət və funksionallıqların hamısını mygov ekosisteminə inteqrasiyası qarşısında klassik development yanaşması bizim üçün kifayət qədər effektiv deyildi.

Zaman bizə qarşı oynayırdı. Çox qısa bir zamanda e-Sosial mobil tətbiqində olan xidmət və funksionallıqları mygov-a inteqrasiya etməli idik. Biznes Analitika şöbəsinin Baş Biznes Analitiki Rüfət Hüseynovun təşəbbüsü ilə SDLC prosesində dəyişiklik etmək qərarına gəldik.

Ənənəvi modeldə Business Analysis tamamlanır, daha sonra texniki dizayn və development başlayırdı. Front-end və Back-end komandaları isə müəyyən mərhələlərdə bir-birinin nəticəsini gözləməli olurdu.

Bu isə development prosesində dependency, gözləmə müddəti, yenidən işləmə və kommunikasiya xərcləri yaradırdı.

Biz yanaşmanı dəyişdik.

Məqsədimiz sadəcə daha sürətli işləmək deyil, sürəti sistemli şəkildə dizayn etmək idi.

Bunun üçün development modelimizi specification-driven yanaşmaya doğru transformasiya etdik.

Burada əsas prinsip sadədir:

Koddan əvvəl specification.

Yəni development prosesində əsas istinad nöqtəsi yalnız yazılmış “BA sənədi” deyil, əvvəlcədən razılaşdırılmış və strukturlaşdırılmış specification olur. Müasir specification-driven yanaşmalarda specification “source of truth” kimi çıxış edir və implementation həmin əvvəlcədən müəyyənləşdirilmiş kontrakt əsasında formalaşır.

Bu dəyişiklik mygov-da bir neçə bir-birini tamamlayan texniki və proses komponentinin formalaşmasına gətirib çıxardı.

1. API-First: development-dan əvvəl kontrakt

Ən fundamental dəyişikliklərdən biri API-First yanaşması oldu.

Artıq API-ni yalnız Back-end development tamamlandıqdan sonra dokumentləşdirdiyimiz artefakt kimi deyil, development prosesinin başlanğıcında dizayn etdiyimiz əsas məhsul komponenti kimi yanaşırıq.

OpenAPI specification vasitəsilə endpoint-lər, request və response strukturları, parametrlər, error response-lar və digər API davranışları əvvəlcədən müəyyənləşdirilir.

Bu yanaşma texniki komandalara development başlamamışdan əvvəl eyni kontrakt ətrafında işləmək imkanı verir.

API-first və design-first yanaşmalarının əsas üstünlüklərindən biri də məhz budur: API implementation-dan əvvəl dizayn edilir və bu dizayn komandalar üçün vahid “single source of truth” rolunu oynayır.

Bu, GovTech üçün xüsusilə vacibdir.

Çünki dövlət ekosistemində dövlət informasiya sistemlərinin bir-biri ilə danışması artıq əlavə funksiya deyil — rəqəmsal dövlət arxitekturasının əsas elementlərindən biridir. Dövlət API standartlarının tətbiqi müxtəlif platforma və xidmətlər arasında daha yaxşı interoperability və daha səmərəli delivery üçün istifadə olunur.

2. Stoplight: API-ni sadəcə dokumentasiya deyil, development artefaktına çevirmək

Qurduğumuz bu modelin texniki komponentlərindən biri Stoplight oldu.

Stoplight üzərindən API design və OpenAPI specification-larını mərkəzləşdirərək API-lərin necə işləyəcəyini implementation-dan əvvəl müəyyənləşdiririk.

Burada əsas dəyişiklik “documentation” anlayışına baxışımızda oldu.

Dokumentasiya development prosesinin özünün bir hissəsidir.

API specification həm Business Analyst, həm Product, həm Front-end, həm Back-end, həm QA, həm də digər texniki rollar üçün ümumi istinad nöqtəsinə çevrilir.

Stoplight-ın design-first yanaşması OpenAPI specification əsasında API-lərin əvvəlcədən dizayn edilməsinə, mock servislərdən istifadə etməklə implementation-dan əvvəl test edilməsinə və Front-end ilə Back-end komandalarının paralel işləməsinə imkan verir.

Bu bizim development modelimizdə çox fundamental dəyişiklik yaratdı.

3. Front-end və Back-end artıq bir-birini gözləmir

Əvvəlki modeldə Front-end komandası Back-end API-nin hazır olmasını gözləməli olurdu.

Bu isə xüsusilə inteqrasiya yönümlü məhsullarda delivery müddətinə birbaşa təsir edirdi.

İndi isə API contract əvvəlcədən müəyyənləşdirildiyi üçün komandalar paralel şəkildə işləyə bilirlər.

Sadələşdirilmiş şəkildə proses artıq belə görünür:

1. Business Requirement
2. Business Analysis & Specification
3. API Design / OpenAPI Contract
4. Front-end Development + Back-end Development + QA hazırlığı
5. Integration & Validation

Bu modeldə komandaların işə başlama nöqtəsi “Back-end hazır oldu” deyil.

“Contract hazır və razılaşdırılıb” olur.

Məhz burada development sürətində əsas sıçrayış baş verir.

Çünki komandanın sürəti artıq yalnız coding speed ilə yox, dependency-lərin idarə olunma səviyyəsi ilə müəyyənləşir.

4. Business Analyst-in rolunu dəyişdik

Bu transformasiyada mənim üçün ən vacib mövzulardan biri Business Analyst rolunun transformasiyasıdır.

Müasir BA yalnız biznes requirement-lərini toplayan və sənəd hazırlayan şəxs deyil.

BA məhsulun həm biznes, həm proses, həm də texniki sərhədlərinin formalaşmasında iştirak edir.

Bizim yanaşmamızda BA development başlamamışdan əvvəl mümkün qədər çox qeyri-müəyyənliyi aradan qaldırmalıdır:

• biznes qaydaları;
• use case-lər;
• acceptance criteria;
• proses axınları;
• data strukturları;
• inteqrasiya tələbləri;
• API contract;
• error scenario-lar;
• edge case-lər;
• digər sistemlərdən asılılıqlar.

Başqa sözlə:

BA-nın əsas məqsədi developer-ə daha çox sənəd vermək deyil. Developer-in cavabsız sual sayını azaltmaqdır.

Bu fərq çox vacibdir.

Çünki yaxşı Business Analysis development başlamazdan əvvəl yaranan qeyri-müəyyənliyi azaldırsa, development zamanı yaranan rework də azalır.

5. Business Analysis + AI

Transformasiyanın növbəti mərhələsi isə Business Analysis prosesinə Süni İntellektin inteqrasiyası oldu.

AI-dan istifadədə məqsəd BA-i əvəz etmək deyil.

Məqsəd analitikin vaxtını sənəd yazmaqdan daha yüksək dəyər yaradan fəaliyyətlərə yönəltməkdir.

AI əsaslı yanaşmalardan istifadə etməklə requirement-lərin strukturlaşdırılması, ilkin analiz, sənədlərin hazırlanması, mümkün boşluqların müəyyənləşdirilməsi, müxtəlif artefaktlar arasında consistency check və digər təkrarlanan analitik fəaliyyətləri sürətləndirmək mümkündür.

Bu, BA rolunu “documentation-centric” modeldən daha çox decision-centric modelə yaxınlaşdırır.

Yəni BA daha az vaxtını mexaniki işə, daha çox vaxtını problemə, biznes qaydasına, istifadəçi ehtiyacına və məhsul qərarlarına ayırır.

AI-nin sürətli inkişafı fonunda specification-driven yanaşmanın aktuallığı da artır. Son dövrdə aparılan araşdırmalarda specification-ların AI-assisted development üçün daha etibarlı və idarəolunan giriş nöqtəsi kimi istifadə olunması ayrıca müzakirə edilir.

6. Əslində biz nəyi dəyişdik?

Kənardan baxanda bütün bunlar ayrı-ayrı texnologiyalar və metodologiyalar kimi görünə bilər:

• Specification-Driven Development
• API-First
• OpenAPI
• Stoplight
• Parallel Development
• AI-assisted Business Analysis

Amma bizim üçün bunlar ayrı təşəbbüslər deyil.

Bunlar vahid bir Digital Product Delivery Model təşkil edir.

Bu modeldə hər bir mərhələ növbəti mərhələnin başlamasını gözləmir.

Əksinə, düzgün specification və contract-lar vasitəsilə komandalar mümkün qədər paralel işləyir.

Beləliklə, development prosesində əsas məqsəd artıq “komandanı daha çox işlətmək” yox, komandanın bir-birini gözlədiyi vaxtı azaltmaqdır.

7. 5X sürət hədəfinin arxasında nə dayanır?

mygov-da qarşımıza qoyduğumuz 5X development speed hədəfi sadəcə “daha çox task bağlamaq” məqsədi deyildi.

Bu, delivery modelinin yenidən düşünülməsi idi.

Çünki 5X sürət əldə etmək üçün yalnız developer komandasına “daha sürətli olun” demək kifayət deyil.

Əgər requirement gec gəlirsə, API contract hazır deyilsə, Front-end Back-end-i gözləyirsə, QA test üçün development-in tamamlanmasını gözləyirsə və qərarlar müxtəlif mərhələlərdə gecikirsə, development sürətini təkcə komanda gücünü artırmaqla 5X etmək mümkün deyil.

Buna görə biz sürəti proses səviyyəsində optimallaşdırdıq.

• Dependency-ləri azaltdıq.
• Specification-ları önə çəkdik.
• API-ni development-dan əvvəl dizayn etdik.
• Front-end və Back-end-in paralel işləməsi üçün texniki kontrakt yaratdıq.
• Business Analysis prosesini AI ilə gücləndirdik.
• Və bütün bunları vahid delivery modelində birləşdirdik.

8. GovTech baxımından əsas nəticə

Burada ən vacib məsələ development komandasının nə qədər sürətli kod yazması deyil.

Əsas məsələ dövlət xidmətinin vətəndaşa nə qədər tez çatmasıdır.

Bir dövlət xidmətinin bir platformaya inteqrasiyasını həftələrlə və ya aylarla gözləmək əvəzinə, həmin xidməti daha qısa delivery cycle ilə vətəndaş üçün əlçatan etmək GovTech-in əsas dəyərlərindən biridir.

Bu səbəbdən mən GovTech-də sürəti ayrıca engineering metric kimi yox, citizen value metric kimi görürəm.

Faster development → Faster integration → Faster service delivery → Faster public value.

Nəticə

Bu transformasiyanın bizə verdiyi ən böyük dərs texniki deyil.

Sürət insanları daha çox işlətməklə deyil, sistemin insanları daha az gözlətməsi ilə yaranır.

Yaxşı development komandası vacibdir.

Güclü arxitektura vacibdir.

Senior səviyyəli Business Analyst-lər vacibdir.

Amma bütün bunları bir-biri ilə əlaqələndirən proses olmadıqda komandanın potensialı tam istifadə olunmur.

İRİA-da qurmağa çalışdığımız model məhz budur:

• Specification ilə düşünmək.
• API ilə əvvəlcədən razılaşmaq.
• Komandaları paralel işlətmək.
• AI ilə analitikanı gücləndirmək.
• Və bütün bunları vətəndaşa daha sürətli dəyər çatdırmaq üçün etmək.

Məncə, GovTech-in növbəti mərhələsində rəqabət artıq yalnız “kim daha yaxşı texnologiyaya sahibdir?” sualı üzərindən getməyəcək.

Əsas sual belə olacaq:

Kim daha yaxşı digital delivery system qurub?

Çünki gələcəyin dövlət məhsullarını yalnız yaxşı texnologiya deyil, yaxşı arxitektura + yaxşı proses + yaxşı analitika + AI + güclü komandalar quracaq.

Və ən əsası:

GovTech-də sürət sadəcə engineering üstünlüyü deyil. Sürət vətəndaşa yaradılan dəyərin özüdür.