Proqram təminatını təhvil alarkən nəyi yoxlamalısınız?

Proqram təminatının təhvil verilməsi zamanı sizə bir keçid və administrator parolu göndərilir. Panel açılır, məlumat görünür, əsas düymələr işləyir. Bəs sabah başqa komanda dəstək göstərəndə həmin proqramı yenidən işə sala, məlumatları bərpa edə və dəyişiklik edə biləcəkmi?

Bu sual yalnız podratçını dəyişmək istəyən şirkətlərə aid deyil. Hazırlayan əməkdaş əlçatmaz olanda, serverdə problem yarananda və ya biznes yeni funksiya istəyəndə də eyni sual ortaya çıxır. Təhvilin məqsədi gündəlik işi davam etdirmək üçün lazım olan nəzarəti, məlumatı və sənədləri biznesə verməkdir.

Aşağıdakı siyahını sifariş mərhələsində razılaşdırmaq daha rahatdır. Artıq hazır proqramı qəbul edirsinizsə, onu açıq qalan işlərin siyahısına çevirə bilərsiniz. Hər bəndin qarşısında məsul şəxs, göstəriləcək nəticə və çatışmayan hissə yazılsın. Bu, hüquqi müqaviləni əvəz edən sənəd deyil; qəbul görüşünü konkretləşdirən iş alətidir.

1. İşləyən versiya ilə verilən kod eyni olmalıdır

“Kod sizindir” cümləsi faylların göndərildiyini bildirə bilər, amma həmin fayllardan canlı proqramın hazırlandığını göstərmir. Təhvil görüşündə hansı versiyanın işlədiyini və onun kodda hansı nöqtəyə uyğun gəldiyini soruşun. Hər texniki detalı bilməyiniz lazım deyil; dəstək göstərəcək mütəxəssis bu əlaqəni izləyə bilməlidir.

Kod saxlanılan yerə biznesin öz hesabından girişini yoxlayın. Yalnız ekran paylaşımında göstərilən qovluq və ya keçmiş əməkdaşın şəxsi hesabındakı icazə davamlı nəzarət deyil. Hansı hesabın sahib olduğu, kimin dəyişiklik edə bildiyi və əlavə girişin kim tərəfindən veriləcəyi aydın olsun.

GitHub istifadə edilirsə, platformanın repozitoriya köçürmə qaydaları ayrıca əməliyyat və şərtlər təsvir edir. Kod üzərində işləmək icazəsi ilə repozitoriyanı başqa sahibə köçürmək eyni addım deyil. Təhvildə hansı variantın tamamlandığını qeyd edin; eyni qaydanı başqa platformaya avtomatik tətbiq etməyin.

2. Hesab siyahısı parol siyahısından daha faydalıdır

Proqramın arxasında server, məlumat bazası, domen, e-poçt xidməti, bildiriş və başqa provayderlər ola bilər. Hər biri üçün platformanı, biznes sahibini, məsul əməkdaşı, ödəniş tərəfini və bərpa yolunu yazın. Bu sənəddə parol və gizli açarların özünü saxlamayın; onların təhlükəsiz şəkildə harada idarə edildiyini göstərin.

Şirkətin hesabına yalnız bir şəxsin şəxsi telefonundan giriş mümkündürsə, həmin şəxs işdən ayrılarkən problem yarana bilər. Giriş bərpasının biznesin nəzarətində olduğunu yoxlayın. Eyni zamanda bütün parolları bütün əməkdaşlara paylamaq da çıxış yolu deyil: gündəlik iş üçün lazım olan səlahiyyətlə hesab sahibliyini ayırın.

GitHub-un giriş üsulları barədə sənədi müxtəlif giriş mexanizmlərini ayırır. Bir giriş işləyirsə, bunun bütün texniki bağlantıların işlədiyi mənasına gəlmədiyini nəzərə alın. Məqsəd təhlükəsizlik addımlarını keçmək deyil, biznesin normal giriş və bərpa imkanını yoxlamaqdır.

3. Mobil tətbiqdə mağaza hesabı ayrıca yoxlanır

Mobil tətbiq sizə aid adla görünə bilər, amma mağazadakı nəşriyyat hesabı başqa tərəfin nəzarətində qala bilər. Hansı hesabın yeni versiya göndərə bildiyini, mağaza məktublarının kimə gəldiyini və əlaqə məlumatlarının kim tərəfindən idarə edildiyini göstərin.

Apple tətbiq köçürməsini ayrıca proses kimi sənədləşdirir. Google Play-in köçürmə izahında də uyğunluq və əlaqəli xidmətlərin yoxlanması tələb olunur. Tətbiqi mağazada görmək bu proseslərin tamamlandığını sübut etmir. Köçürmə lazımdırsa, mövcud tətbiqin şərtlərini yoxlayıb addımları ayrıca planlaşdırın.

Bu bəndə imza materialları və əlaqəli bildiriş, analitika kimi xidmətlərin məsuliyyəti də daxildir. Onları açıq sənədə yığmaq əvəzinə təhlükəsiz təhvil və saxlanma qaydasını razılaşdırın. Mağaza hesabının kimə məxsus olduğu ilə tətbiqin hazır kitabxanalarının lisenziyaları da ayrı məsələlərdir.

4. Məlumatı çıxarmaqla bərpa etmək ayrı nəticələrdir

CRM-dən müştəri siyahısını çıxara bilmək faydalıdır, amma bir CSV faylı proqramın bütün vəziyyətini saxlamaya bilər. Müraciətlər arasındakı əlaqələr, əlavə sənədlər, tarixçə və istifadəçi rolları başqa yerdə qala bilər. Hansı məlumatların ixrac olunduğunu və hansılarının daxil olmadığını soruşun.

Təhvil üçün tövsiyə olunan iki ayrı yoxlama var. Birincisi, seçilmiş məlumat dəstinin oxunaqlı formatda çıxarılması və biznesin onu istifadə edə bilməsidir. İkincisi, ehtiyat nüsxədən ayrılmış sınaq mühitinə bərpa və əsas əməliyyatın yoxlanmasıdır. Bunlardan biri digərini əvəz etmir.

Canlı məlumatı sınaq üçün təsadüfi noutbuka köçürməyin. Məsul şəxslər icazəli və qorunan mühiti seçsin, müştəri məlumatını yalnız zəruri həcmdə istifadə etsin. Qəbul sənədinə bütün məlumatı əlavə etmək əvəzinə yoxlanmış nəticəni, tarixi və əhatəni yazın.

5. Yeni komanda proqramı sənədlə başlada bilməlidir

Təhvil paketində proqramın necə hazırlanıb işə salındığı, hansı xarici xidmətlərə bağlı olduğu və gündəlik əməliyyatların necə aparıldığı izah olunsun. “Quraşdırma qaydası” yalnız köhnə əməkdaşın yadında qalan addımlara söykənməsin.

Qəbul zamanı dəstək göstərəcək başqa bir mütəxəssis sənədə əsasən ayrılmış mühitdə başlama qaydasını yoxlaya bilər. Bu yoxlama canlı proqramı söndürmək və ya müştəri məlumatını dəyişmək tələb etməməlidir. Məqsəd verilən sənədin işlək olduğunu görməkdir.

Əgər sistem yalnız hazır SaaS məhsulunun uyğunlaşdırılmasıdırsa, vendorun proqram kodunun təhvili gözlənilmir. O halda biznes hesabı, konfiqurasiya, məlumat ixracı və lisenziya şərtləri üzrə nə alınacağını yazın. Hazır CRM ilə özəl sistem arasındakı fərq bu qərarı sifarişdən əvvəl verməyə kömək edir.

6. Qəbul sınağı işin özünü göstərməlidir

Təsəvvür edin ki, servis şirkəti üçün müraciət idarəetmə proqramı sifariş olunub. Bu, nümunədir, real müştəri layihəsinin nəticəsi deyil. Əməkdaş müraciət yaradır, rəhbər onu icraçıya təyin edir, icraçı işi tamamlayır, məsul şəxs tarixçəni görür. Qəbul sınağı bu axını göstərməlidir.

Sonra istisnanı yoxlayın: yanlış məlumat daxil edilib, fayl yüklənmir və ya icraçı başqa əməkdaşın işinə baxmağa çalışır. Gözlənən nəticəni əvvəlcədən yazın. Yalnız uğurlu ekran görüntüsü icazələrin, məlumatların və xəta hallarının düzgün işlədiyini göstərmir.

Hər tələb üçün “yoxlanıb”, “açıq qalıb” və “bu mərhələyə daxil deyil” kimi aydın qeyd aparın. Yeni istəyi köhnə xətayla qarışdırmayın. Sonradan əlavə olunan funksiya layihənin əvvəldən razılaşdırılmış təhvil ölçüsünü səssizcə dəyişməməlidir.

7. Dəstək və əlavə işin sərhədi yazılı qalsın

Xəta düzəlişi, yeni funksiya, provayder dəyişikliyi və sistemin gündəlik idarə edilməsi fərqli işlərdir. Hansı kanaldan müraciət ediləcəyini, nə qədər tez cavab gözlənildiyini və işin kim tərəfindən təsdiqlənəcəyini razılaşdırın. Cavab müddətini problemin həll müddəti kimi təqdim etməyin.

Təhvil sənədində açıq xətalar, müvəqqəti həllər və istifadəyə qoyulan məhdudiyyətlər görünməlidir. Gizlədilmiş natamam işlərlə qəbul edilmiş ilk versiya eyni vəziyyət deyil. Davamlı baxımın niyə ayrıca iş olduğu barədə izahı dəstək büdcəsini planlaşdırarkən istifadə edə bilərsiniz.

Qəbul görüşünə aparacağınız qısa siyahı

• İşləyən versiya və ona uyğun kod qeydi göstərildi.
• Biznesin hesab sahibliyi, girişləri və bərpa yolları yoxlandı.
• Məlumat ixracının əhatəsi və bərpa sınağının nəticəsi qeyd edildi.
• Başlama və gündəlik istifadə sənədi başqa şəxs tərəfindən yoxlandı.
• Əsas iş axını və razılaşdırılmış istisnalar sınaqdan keçdi.
• Açıq qalan işlər, dəstək sərhədi və məsul şəxslər yazıldı.

Yeni veb tətbiq və xüsusi iş sistemi və ya mobil tətbiq sifariş edirsinizsə, bu nəticələri təklif mərhələsində danışın. Mövcud proqramı təhvil almaq istəyirsinizsə, ilk addım əlçatan kod, hesab və sənədlərin siyahısını çıxarmaqdır. Layihənizi PixelLabs-a təsvir edin; iş həcmini və təhvil zamanı nəyi yoxlayacağınızı əvvəlcədən dəqiqləşdirək.