Veb layihənin təhvili yalnız saytın internetdə açılması deyil. Biznes sahibi məzmunu idarə edə, lazım olan girişləri tapa və problem zamanı kimin nə etdiyini anlaya bilməlidir. Proqramın hazır olması ilə onun müstəqil istifadəyə verilməsi əlaqəli, amma ayrı nəticələrdir.
Təhvil şərtlərini başlanğıcda texniki tapşırıqda göstərmək sonradan gözləntilərin toqquşmasını azaldır. Kod, dizayn, məzmun, server və xarici xidmətlərin sahiblik sərhədləri aydın olmalıdır.
Qəbul real işlə yoxlanılır
Əsas ssenariləri siyahıya alın: yeni məzmun yaratmaq, layihəni redaktə etmək, formadan müraciət almaq və ya sifarişin vəziyyətini dəyişmək. Hər biri istifadəçinin görəcəyi nəticə ilə yazılmalıdır. «Admin işləyir» ifadəsi hansı əməliyyatın qəbul edildiyini göstərmir.
İzahlı nümunə: redaktor iki dildə məqalə yaradır, qaralama saxlayır, baxış edir və sonra dərc edir. Bu şərti ssenaridə həm mətnin saxlanması, həm ictimai görünüş, həm də qaralamanın gizliliyi yoxlanılır. Müştərinin özünün bunu etməsi təlimin də nə dərəcədə anlaşıldığını göstərir.
Giriş və hesabların siyahısı
Domen, hosting, server, administrator hesabı və xarici xidmətlər fərqli girişlərdir. Hansının biznesə aid olduğu və hansının xidmət göstərən tərəfin idarəsində qaldığı yazılmalıdır. Girişi bir mesajda göndərmək hesabın sahiblik və bərpa qaydasını tam müəyyən etmir.
- Domen və DNS idarəsi.
- Server və ya hosting paneli.
- Saytın idarəetmə paneli.
- Analitika və axtarış hesabları.
- E-poçt və inteqrasiya xidmətləri.
- Girişin bərpasına məsul əlaqə.
Şifrələr açıq sənəd və ictimai kod deposunda saxlanmamalıdır. Təhvil zamanı lazım olan sirlərin təhlükəsiz ötürülməsi və əvvəlki müvəqqəti girişlərin bağlanması razılaşdırılır. Tərəflərin gələcəkdə kimə nə icazə verəcəyini anlaması vacibdir.
Kod və texniki sənəd
Mənbə kodu ilə işləyən saytın faylları fərqli paketlər ola bilər. Təhvilə hansı mənbənin daxil olduğu, asılılıqlar, quraşdırma və yeniləmə addımları yazılmalıdır. Gizli açarlar və real verilənlər bazası adi ictimai mənbə paketinə daxil edilməməlidir.
Qısa sənəd belə faydalıdır: proqramın tələbləri, konfiqurasiya yerləri, məlumat bazasının yeri, fayl yükləmələri və sınaq addımları. Bu, gələcəkdə başqa texniki əməkdaşın layihəni başa düşməsinə kömək edir. Mövcud PHP layihəsində dəstək ehtiyacı varsa, PHP/Laravel dəstəyi mövzusunu nəzərdən keçirin.
Ehtiyat nüsxə və bərpa
Nüsxəyə verilənlər bazası ilə yanaşı yüklənmiş media və lazımi konfiqurasiya da aid ola bilər. Hansı hissənin necə saxlandığı məlum olmalıdır. Kodun nüsxəsi məzmun bazasını, bazanın nüsxəsi isə media fayllarını avtomatik əvəz etmir.
Bərpa sınağı ayrıca mərhələdir. Nüsxədən başqa mühitdə açılan layihədə məzmun və fayllar yoxlanılır. İstifadəçinin «nüsxə var» cavabından daha çox nə vaxt və necə bərpa edilə biləcəyini bilməsi lazımdır. Qəbul edilən məlumat itkisi və bərpa müddəti tərəflər arasında ayrıca razılaşdırılır.
Xəta düzəlişi ilə yeni funksiyanı ayırın
Razılaşdırılmış funksiyanın səhv işləməsi ilə yeni tələbin əlavə olunması fərqli işdir. Dəstək qaydasında bu fərq nümunələrlə izah edilməlidir. Məsələn, mövcud formanın məlumatı saxlamaması xəta ola bilər; həmin formaya yeni təsdiq mərhələsi əlavə etmək əhatə dəyişikliyidir.
Problem bildirişində səhifə, addımlar, gözlənilən nəticə və faktiki nəticə faydalıdır. Şəxsi məlumat və şifrəni ümumi ekran görüntüsünə daxil etməmək lazımdır. Dəstək üçün konkret əlaqə və cavab qaydası əvvəl müəyyən ediləndə müraciətlər daha anlaşılan olur.
Yayımdan sonrakı yoxlama
- Domen və HTTPS keçidləri.
- Əsas səhifələr və mobil görünüş.
- Formanın uğurlu və səhv ssenariləri.
- İctimai və məxfi səhifələrin görünüşü.
- İnteqrasiya və bildirişlərin vəziyyəti.
- Sitemap və vacib köhnə ünvanların keçidləri.
Yeni sayta keçiddə texniki SEO və xarici əlaqələr ayrıca yoxlanılır. Gündəlik texniki izləmə ilə kontent yenilənməsi eyni xidmət deyil; ehtiyac varsa hər ikisi ayrıca planlaşdırılır.
Nümunə: müddəti bitən xarici xidmət
Saytın kodu işlək qalır, amma bağlı xarici xidmətin abunəsi və ya açarı dəyişir. Bu şərti vəziyyətdə problem mənbə kodunun silinməsi ilə eyni deyil. Hesabın sahibi, yenilənməyə məsul şəxs və bağlantının vəziyyəti əvvəl məlum olmalıdır.
Təhvil siyahısında xarici xidmətin adı, məqsədi və hesabın biznesə aid olub-olmaması göstərilə bilər. Gizli dəyərlər həmin ümumi siyahıya açıq yazılmır. Əsas funksiyanın həmin xidmət olmadan necə davranacağı da sınaqdan keçirilir.
- Hesabın bərpa və yeniləmə məsulunu müəyyən edin.
- İnteqrasiya işləməyəndə forma və ya iş axınına baxın.
- İstifadəçinin anlaşılan məlumat aldığını yoxlayın.
- Əlaqə açarının dəyişdirilmə qaydasını sənədləşdirin.
Bu yanaşma bütün gələcək problemləri əvvəlcədən bilmək deyil. Məqsəd sahibi məlum olmayan hesab və qeyri-müəyyən dəstək sərhədi yaratmamaqdır. Təhvilin yaxşı tamamlanması gələcəkdə işi davam etdirən tərəfə də aydın başlanğıc verir.
Tez verilən suallar
Sayt işləyirsə, sənəd lazımdırmı?
Bəli, xüsusilə giriş, nüsxə və yeniləmə qaydaları gələcək istifadənin hissəsidir. Sənədin həcmi layihəyə uyğun ola bilər.
Dəstək müddəti bitəndə sayt dayanırmı?
Bu, hosting və xidmətlərin şərtindən asılıdır. Kod, server və xarici abunələrin müddətləri bir-birindən ayrılmalıdır.
166 Logistics CV-də formalar, bildirişlər və korporativ e-poçt əlaqəsi ilə qeyd olunan layihədir. Belə əlaqəli hissələri olan işlərdə texniki dəstək planı tətbiqin öz funksiyaları qədər aydın hazırlanmalıdır.
