Yaxşı texniki tapşırıq layihədə hansı nəticənin gözlənildiyini başa düşməyə kömək edir. Başlanğıc sənədin mürəkkəb terminlərlə dolu olması lazım deyil. Biznesin məqsədi, istifadəçinin işi və təhvil zamanı yoxlanacaq davranış aydın yazılsa, müzakirə daha konkret başlayır. Sənəd inkişaf etdikcə suallar və qərarlar da görünən yerdə saxlanılır.
Birinci hissə: biznes və məqsəd
Şirkət nə edir, kimə xidmət göstərir və yeni sayt hansı ehtiyacı qarşılamalıdır? «Müasir sayt istəyirəm» ifadəsini real məqsədlə tamamlayın: xidmətləri izah etmək, uyğun müraciət toplamaq, məhsul sifarişi qəbul etmək və ya material dərc etmək.
Bir əsas nəticəni seçmək vacibdir. Bir neçə auditoriya varsa, onların fərqli suallarını yazın. Korporativ satınalma edən şəxslə fərdi alıcının lazım olan məlumatı eyni olmaya bilər. Hər auditoriyanın növbəti addımını ayrıca düşünün.
İkinci hissə: səhifə xəritəsi
Ana səhifə, xidmətlər, layihələr, yazılar və əlaqə kimi bölmələri sadalayın. Sonra hər birinin daxilində nə olacağını yazın. «Xidmətlər» ümumi siyahıdırmı, hər xidmətin ayrıca səhifəsi varmı və oradan necə müraciət ediləcək?
Mövcud sayt yenilənirsə, qorunmalı səhifələri və köhnə URL-ləri qeyd edin. Məzmunun birləşdirilməsi və silinməsi texniki yönləndirmələrlə birlikdə planlaşdırılmalıdır. Əhəmiyyətli ünvanlar siyahısı yeni strukturun yoxlanmasını asanlaşdırır.
Üçüncü hissə: istifadəçi ssenariləri
Funksiyanı yalnız adlandırmaq əvəzinə onun işini təsvir edin. «Əlaqə forması» üçün ssenari belə yazıla bilər: istifadəçi adını, e-poçtunu və mesajını daxil edir; məlumat düzgün olduqda müraciət saxlanır; ona təsdiq göstərilir; idarəçi qeydi paneldə görür.
Sonra istisnaları əlavə edin: e-poçt yanlışdırsa, məcburi sahə boşdursa və ya eyni düymə təkrar basılırsa nə baş verir? Bu təsvir test zamanı görülən nəticəni gözlənilən davranışla müqayisə etməyə imkan verir.
Dördüncü hissə: admin və məzmun
- Kim panelə daxil olur və hansı bölmələri dəyişir?
- Yeni qeyd yaratmaq, redaktə, baxış və silmə lazımdırmı?
- Qaralama və dərc statusu necə işləyir?
- Hansı sahələr iki dildədir?
- Şəkil, fayl və SEO məlumatları kim tərəfindən əlavə olunur?
İlkin məzmunun hazırlanmasını ayrıca bölmə edin. Mətn, loqo, şəkil və tərcümələrin sahibi, hazır olma vaxtı və təsdiq edən şəxs göstərilsin. Hazır olmayan material layihənin planında görünməlidir.
Beşinci hissə: inteqrasiya və texniki mühit
Mövcud CRM, anbar, ödəniş və başqa xidmətlərlə əlaqələri sadalayın. Hər biri üçün hansı məlumatın keçəcəyini və xidmətin sənədinin olub-olmadığını bildirin. Gizli açarları texniki tapşırığın açıq hissəsinə yazmaq əvəzinə təhlükəsiz ötürmə yolu müəyyən edin.
Domen, hosting və digər hesabların sahibini qeyd etmək təhvil prosesini aydınlaşdırır. Tətbiqin hansı mühitdə işləyəcəyi, məlumatın ehtiyat nüsxəsi və sonrakı texniki dəstək də razılaşdırılır.
Altıncı hissə: qəbul meyarları
«Hər şey işləsin» ifadəsini yoxlana bilən siyahıya çevirin. Məsələn: razılaşdırılmış səhifələr açılır, formanın uğurlu və səhv ssenariləri yoxlanır, dil dəyişməsi uyğun səhifəyə aparır, admin dəyişiklikləri saytda görünür. Mobil görünüş üçün hansı ekranların və əsas proseslərin yoxlanacağı göstərilsin.
Qəbul meyarı layihənin həqiqi tələbinə bağlı olmalıdır. Hər sayt üçün eyni sayda funksiya və ya eyni dizayn qaydası seçmək faydalı deyil. Əsas məqsəd razılaşdırılmış nəticəni tərəflərin eyni şəkildə anlamasıdır.
İlk müzakirəyə göndərə biləcəyiniz qısa forma
- Biznes və auditoriya.
- Saytın əsas məqsədi.
- Səhifələr və vacib istifadəçi ssenariləri.
- Dillər və hazır materiallar.
- Admin istifadəçiləri və məzmun idarəsi.
- İnteqrasiyalar və mövcud sistemlər.
- Məcburi tarix və ilk versiyanın sərhədi.
- Qəbul və təhvil gözləntiləri.
Dizayn nümunəsini necə izah etməli?
Bəyəndiyiniz saytın keçidini göndərmək faydalıdır, amma hansı hissənin sizə uyğun gəldiyini də yazın. Rəng, naviqasiya, layihə kartları və mətnin təqdimatı ayrı seçimlərdir. Nümunədən hansı istifadəçi problemini həll etmək istədiyinizi göstərmək dizayn müzakirəsini konkretləşdirir.
Şirkət materialları və hüquqları müəyyənləşdirilsin: loqo, şrift, foto və illüstrasiyaların istifadəsinə dair mənbə bilinməlidir. Dizaynı telefon ekranında oxunaqlılıq, düymələrin əlçatanlığı və formaların aydınlığı ilə birlikdə qiymətləndirin. Vizual üslub saytın real məzmununa tətbiq ediləndə daha dəqiq görünür.
Dəyişiklik sorğusunu ayrıca qeyd edin
Hazırlıq zamanı yeni ehtiyac çıxması normaldır. Sorğuda hansı davranışın dəyişəcəyi, hansı səhifəyə təsir etdiyi və bunun ilk versiya üçün məcburi olub-olmadığı yazılsın. Sonra texniki təsir və müddət qiymətləndirilir. Belə qeyd əvvəlki razılaşma ilə yeni istəyi qarışdırmadan qərar verməyə kömək edir.
Məsələn, sadə əlaqə formasını CRM-ə məlumat göndərən axına çevirmək əlavə texniki iş tələb edə bilər. Bunun üçün API imkanları, məlumat sahələri və xəta ssenariləri dəqiqləşdirilir. Mövcud biznes qaydalarını eyni panelə toplamaq istəyi isə CRM/ERP tələbləri kimi ayrıca təsvir oluna bilər.
Sənədin aktual versiyası
Razılaşdırılan dəyişiklikləri tarix və qısa izahla eyni sənəddə saxlamaq faydalıdır. Kim tərəfindən təsdiqləndiyi və hansı mərhələdə tətbiq olunacağı göstərilsin. Qəbul zamanı tərəflər eyni aktual siyahıya baxdıqda, mübahisəli qeydləri konkret davranışa görə müzakirə etmək asanlaşır.
Bu siyahını ilkin məlumatla doldurub əlaqə formasından göndərə bilərsiniz. Açıq qalan sualları müzakirə zamanı dəqiqləşdirərik. Xidmətin tərkibi haqqında veb sayt hazırlanması bölməsində, qiymətləndirmə amilləri haqqında isə saytın qiyməti barədə məqalədə oxuya bilərsiniz.
