Proqram dəstəyi müqaviləsi: təhvildən sonra nə olur?

Proqram təhvil verildi, hamı əl sıxdı, layihə bağlandı — bəs sabah sistemdə xəta çıxsa, kim düzəldəcək? Proqram texniki dəstək müqaviləsi məhz bu sualın cavabıdır. Bu yazıda zəmanətlə dəstəyin fərqini, SLA-nın nə olduğunu və müqavilədə mütləq yazılmalı bəndləri praktik şəkildə izah edirik.

Çox biznes sahibi proqramı sifariş edəndə bütün diqqətini bir sualda cəmləyir: "Nə vaxt hazır olacaq?" Amma təcrübə göstərir ki, əsl münasibət proqram təhvil veriləndə bitmir — başlayır. Sistem canlıya çıxandan sonra istifadəçilər real datalarla işləyir, gözlənilməz ssenarilər üzə çıxır, server yüklənir, inteqrasiya olunmuş xidmətlər öz API-larını dəyişir. Bütün bunları kimsə izləməli və həll etməlidir. Proqram texniki dəstək müqaviləsi məhz bu "kimsə"nin kim olduğunu, nəyə görə məsuliyyət daşıdığını və nə qədər sürətlə reaksiya verməli olduğunu yazılı şəkildə müəyyən edən sənəddir. Bu yazıda həmin müqavilənin içini bənd-bənd açacağıq.

Proqram təhvil verildikdən sonra dəstək niyə vacibdir?

Proqram canlı orqanizm kimidir: ətraf mühiti dəyişdikcə ona qulluq lazımdır. Proqram təhvil verildikdən sonra dəstək olmasa, ilk aylarda hər şey qaydasında görünə bilər — amma zaman keçdikcə problemlər yığılır:

• Ətraf mühit dəyişir. Brauzerlər, əməliyyat sistemləri, telefonlar yenilənir. Dünən işləyən interfeys sabah yeni versiyada qəribə görünə bilər.
• İnteqrasiyalar köhnəlir. Proqramın qoşulduğu ödəniş sistemi, SMS provayderi və ya sosial şəbəkə API-si öz qaydalarını dəyişəndə sənin sistemin də uyğunlaşdırılmalıdır.
• Data böyüyür. Min sətirlə sürətli işləyən sorğu yüz min sətirdə yavaşıya bilər. Bunu vaxtında optimallaşdıran biri olmalıdır.
• Təhlükəsizlik boşluqları üzə çıxır. İstifadə olunan kitabxanalarda zəifliklər tapılır və yamaqlar tətbiq edilməlidir.

Bakıda və ümumən Azərbaycanda hələ də çox layihə "təhvil ver, unut" modeli ilə gedir. Sonra isə biznes sahibi sistem dayananda kimə zəng edəcəyini bilmir. Dəstək müqaviləsi bu qeyri-müəyyənliyi aradan qaldırır.

Texniki dəstək nəyi əhatə edir?

"Dəstək" sözü müqavilədə konkretləşdirilməsə, hər tərəf onu öz xeyrinə şərh edəcək. Ona görə texniki dəstək nəyi əhatə edir sualının cavabı müqavilədə maddə-maddə yazılmalıdır. Standart dəstək paketi adətən bunları əhatə edir:

• Xəta düzəlişi (bug fix): mövcud funksionallıqda aşkarlanan səhvlərin aradan qaldırılması.
• Monitorinq: sistemin işlək olub-olmadığının izlənməsi, dayanma hallarında xəbərdarlıq.
• Yeniləmələr: kitabxana və framework versiyalarının, təhlükəsizlik yamaqlarının tətbiqi.
• Ehtiyat nüsxələr (backup): datanın müntəzəm yedəklənməsi və lazım olanda bərpası.
• Konsultasiya: istifadəçi suallarına cavab, kiçik konfiqurasiya dəyişiklikləri.

Dəstəyə adətən daxil olmayan işlər isə bunlardır: yeni modul yazılması, dizaynın kökündən dəyişdirilməsi, üçüncü tərəf sistemlərlə yeni inteqrasiyalar, istifadəçi səhvindən yaranan data itkisinin əl ilə bərpası. Bu sərhəd müqavilədə aydın çəkilməlidir ki, sonradan "bu da dəstəyə daxildir" mübahisəsi yaranmasın.

Zəmanət müddəti ilə dəstək fərqi nədir?

Bu iki anlayış tez-tez qarışdırılır, halbuki fərqlidirlər. Zəmanət müddəti ilə dəstək fərqi belədir:

• Zəmanət — layihə müqaviləsinin bir hissəsidir və adətən pulsuzdur. Təhvildən sonra müəyyən müddət ərzində (praktikada bir neçə aydan bir ilə qədər razılaşdırılır) aşkarlanan və texniki tapşırıqda yazılmış funksionallığa aid xətalar podratçı tərəfindən ödənişsiz düzəldilir. Zəmanət yalnız "sifariş edilən amma düzgün işləməyən" şeyləri əhatə edir.
• Dəstək — ayrıca, davamlı xidmətdir. Zəmanət bitəndən sonra da (və ya onunla paralel) sistemin sağlamlığını qorumaq üçün bağlanır: monitorinq, yeniləmə, backup, konsultasiya, təcili müdaxilə. Dəstək adətən aylıq abunə formatında olur və qiyməti layihədən asılıdır.

Sadə düstur: zəmanət keçmişə baxır ("vəd edilən işləyirmi?"), dəstək gələcəyə baxır ("sabah da işləyəcəkmi?"). Yalnız zəmanətlə kifayətlənmək — maşını sığortasız sürməyə bənzəyir.

Proqramda xəta çıxanda kim düzəldir və nə qədər vaxta?

Proqramda xəta çıxanda kim düzəldir sualının cavabı müqavilə olmayanda "heç kim" olur. Müqavilə olanda isə cavab konkretdir: dəstək təminatçısı, razılaşdırılmış müddət ərzində. Burada iki mühüm anlayış var:

Cavab müddəti — SLA nədir?

Cavab müddəti SLA nədir deyə soruşursansa: SLA (Service Level Agreement — xidmət səviyyəsi razılaşması) təminatçının problemə nə qədər sürətlə reaksiya verəcəyini və nə vaxta həll edəcəyini rəsmiləşdirən bənddir. Yaxşı SLA-da iki ayrı müddət yazılır:

• Reaksiya müddəti: müraciətin qəbul edilib işə götürülməsinə qədər keçən vaxt.
• Həll müddəti: problemin aradan qaldırılmasına qədər keçən vaxt.

Prioritet dərəcələri

Hər xəta eyni ağırlıqda deyil. SLA-da problemlər adətən dərəcələnir:

1. Kritik: sistem tam dayanıb, heç kim işləyə bilmir — ən qısa reaksiya tələb olunur.
2. Yüksək: əsas funksiya işləmir, amma sistem ayaqdadır.
3. Orta: problem var, amma dolayı yolla iş görmək mümkündür.
4. Aşağı: kosmetik qüsur, təkmilləşdirmə təklifi.

Hər dərəcə üçün ayrıca müddət yazılmalıdır. "Ən qısa zamanda baxarıq" ifadəsi SLA deyil — konkret saat və gün rəqəmləri olmalıdır. AI Media-da biz dəstək xidmətini 7/24 rejimdə qururuq və müştərilərimizə aimedia.az üzərindən çatdırdığımız hər sistemdə SLA şərtlərini əvvəlcədən yazılı razılaşdırırıq.

Yeni funksiya əlavəsi dəstəyə daxildirmi?

Ən çox mübahisə doğuran sual budur. Qısa cavab: adətən yox. Yeni funksiya əlavəsi dəstəyə daxildirmi sualının ədalətli həlli belədir:

• Xəta düzəlişi — mövcud funksiyanın nəzərdə tutulduğu kimi işləməməsi — dəstəyə daxildir.
• Yeni funksiya — əvvəl olmayan imkanın əlavə edilməsi (yeni hesabat, yeni modul, yeni inteqrasiya) — ayrıca qiymətləndirilən inkişaf (development) işidir.

Amma sərhəd hər zaman qara-ağ deyil. Məsələn, mövcud hesabata bir sütun əlavə etmək dəstəkdirmi, yoxsa yeni funksiyadır? Bunu həll etmək üçün bir çox müqavilədə aylıq "inkişaf saatı" limiti yazılır: dəstək paketinə hər ay müəyyən saat həcmində kiçik təkmilləşdirmə daxil edilir, ondan artığı ayrıca qiymətləndirilir. Bu model həm sifarişçini xırda dəyişikliklər üçün hər dəfə danışıqdan azad edir, həm də podratçını sonsuz pulsuz işdən qoruyur. Hansı modelin sənə uyğun olduğunu xidmətlərimiz səhifəsində təsvir etdiyimiz yanaşma ilə müqayisə edə bilərsən.

Server və hosting kimin üzərindədir?

Server və hosting kimin üzərindədir sualı təhvil günü yox, müqavilə imzalananda cavablandırılmalıdır. Üç geniş yayılmış model var:

1. Server sifarişçinin adınadır, idarəetmə podratçıda

Ən balanslı model. Hosting hesabı, domen və server sənin adına açılır — yəni aktivlər sənindir. Amma quraşdırma, yeniləmə, monitorinq və təhlükəsizlik podratçının məsuliyyətindədir. Podratçı dəyişsə belə, server əlində qalır.

2. Hər şey podratçının infrastrukturundadır

Rahatdır, amma asılılıq yaradır: münasibət pozulsa, datana çıxışın podratçının xoş niyyətindən asılı olur. Bu modeli seçirsənsə, müqavilədə mütləq datanın istənilən vaxt tam ixracı (export) hüququ yazılmalıdır.

3. Hər şey sifarişçinin komandasındadır

Öz İT komandası olan şirkətlər üçün uyğundur. Podratçı yalnız tətbiq səviyyəsində dəstək verir, server əməliyyatları daxili komandada qalır. Kiçik biznes üçün bu, əlavə yük deməkdir.

Hansı model olursa olsun, müqavilədə server xərclərinin (hosting, domen, SSL, üçüncü tərəf servislər) kim tərəfindən ödənildiyi ayrıca sətirlə göstərilməlidir. Məhsullarımız — məsələn, e-konveyer.aimedia.az istehsalat nəzarət sistemi və ya erp.aimedia.az onlayn ERP — bulud əsaslı işlədiyi üçün müştəri server dərdi çəkmir: infrastruktur, yeniləmə və backup bizim tərəfimizdə qalır.

Mənbə kodu kimə məxsusdur və podratçı dəyişəndə proqrama nə olur?

Bu iki sual bir-biri ilə birbaşa bağlıdır. Mənbə kodu kimə məxsusdur sualının cavabı müqavilədə yoxdursa, defolt vəziyyət çox vaxt sifarişçinin əleyhinədir: kod podratçının serverində qalır, sən yalnız işləyən sistemin "istifadəçisi" olursan.

Podratçı dəyişəndə proqrama nə olur? Ssenarilər kod sahibliyindən asılıdır:

• Kod və sənədlər səndədirsə: yeni komanda layihəni götürür, öyrənir və davam etdirir. Keçid ağrılı olsa da mümkündür.
• Kod podratçıdadırsa: yeni komanda sıfırdan yazmalı ola bilər — bu isə vaxt, büdcə və data köçürmə riski deməkdir.

Ona görə müqavilədə bu bəndlər olmalıdır: sifariş əsasında yazılan kodun əmlak hüquqlarının tam ödənişdən sonra sifarişçiyə keçməsi; kodun git repozitoriyasına sifarişçinin çıxışı; texniki sənədlərin (arxitektura təsviri, quraşdırma təlimatı, API sənədi) təhvil paketi kimi verilməsi; müqavilə bitəndə "təhvil-təslim" prosedurunun (handover) təsviri. Qeyd: hazır məhsul (SaaS) modelində məntiq fərqlidir — orada kodu yox, xidməti alırsan və əsas qorunmalı hüquq datanın ixracıdır.

Dəstəksiz proqramın riskləri: real ssenarilər

Dəstəksiz proqramın riskləri nəzəri deyil — praktikada ən çox rast gəlinən ssenarilər bunlardır:

• Səssiz dayanma: sistem gecə dayanır, monitorinq yoxdur, problemi səhər müştərilər aşkar edir.
• Backup illüziyası: hamı backup olduğunu düşünür, amma heç kim onu yoxlamayıb; data itəndə bərpa mümkün olmur.
• Köhnəlmiş asılılıqlar: illərlə yenilənməyən kitabxanalar təhlükəsizlik boşluğuna çevrilir.
• İtmiş bilik: sistemi yazan developer gedib, sənəd yoxdur, heç kim koda toxunmağa cəsarət etmir.
• İnteqrasiya qırılması: qoşulduğun xarici servis API-sini dəyişir və proqramın bir hissəsi xəbərsiz işləməz olur.

Bu risklərin hamısı idarə oluna biləndir — sadəcə kiminsə məsuliyyətində olmalıdır. Dəstək müqaviləsinin dəyəri məhz budur: risklərin sahibi olur.

Dəstək müqaviləsində nələr yazılmalıdır? Yoxlama siyahısı

Yekun olaraq, dəstək müqaviləsində nələr yazılmalıdır sualına tam siyahı ilə cavab verək. İmzalamazdan əvvəl bu bəndlərin hər birinin yerində olduğunu yoxla:

1. Xidmətin əhatəsi: nə daxildir, nə daxil deyil — konkret siyahı ilə.
2. SLA: prioritet dərəcələri, hər dərəcə üçün reaksiya və həll müddətləri.
3. Əlaqə kanalı: müraciətlərin hara göndərildiyi (tiket sistemi, telefon, mesaj) və iş saatları (yoxsa 7/24?).
4. Zəmanət şərtləri: zəmanət müddəti, nəyi əhatə etdiyi və dəstəkdən fərqi.
5. Yeni funksiya qaydası: kiçik təkmilləşdirmə limiti və böyük işlərin qiymətləndirmə proseduru.
6. Server və hosting: infrastrukturun kimin adına olduğu, xərclərin bölgüsü, giriş məlumatlarının saxlanması.
7. Backup siyasəti: tezlik, saxlanma müddəti, bərpa testi.
8. Mənbə kodu və sənədlər: sahiblik, repozitoriyaya çıxış, sənədləşmə öhdəliyi.
9. Təhvil-təslim proseduru: müqavilə bitəndə və ya podratçı dəyişəndə nəyin, hansı formatda, nə müddətə təhvil verildiyi.
10. Məxfilik və data qorunması: podratçının sənin datana münasibətdə öhdəlikləri.
11. Ödəniş modeli: aylıq abunə, saatlıq və ya qarışıq — məbləğ layihədən asılıdır, amma model aydın olmalıdır.
12. Ləğv şərtləri: hər iki tərəfin müqaviləni hansı xəbərdarlıq müddəti ilə dayandıra biləcəyi.

Bu siyahı ilə silahlanmış sifarişçi ilə podratçı arasında münasibət daha sağlam qurulur — çünki heç nə "sözlə" qalmır.

Sistemin sabahını bu gün sığortala

Proqram təhvil günü bitmir, başlayır — və onun uzunömürlülüyü yazılı, ölçülə bilən dəstək öhdəliklərindən asılıdır. AI Media Bakıda fəaliyyət göstərən texnologiya şirkəti kimi çatbotdan tutmuş ERP və şirkətə özəl proqrama qədər qurduğumuz hər sistemi 7/24 dəstəklə təhvil veririk: SLA, backup, monitorinq və sənədləşmə standart paketimizin hissəsidir. Mövcud sistemin dəstəksiz qalıbsa və ya yeni layihə planlaşdırırsansa, bizimlə əlaqə saxla — pulsuz konsultasiyada sistemini birlikdə qiymətləndirək və sənə uyğun dəstək modelini müəyyən edək. Zəng üçün: +994 50 250 00 74. Paketlər barədə ümumi məlumatı qiymət səhifəsində tapa bilərsən.