Elmi-tədqiqat institutunda ventilyasiyanın modernləşdirilməsi üçün texniki şərtlər. Tədqiqat obyektində ventilyasiyanın modernləşdirilməsi üçün texniki şərtlər Saxlama serverinin modifikasiyası üçün texniki şərtlər

Texniki spesifikasiya nə üçün lazımdır?

Proqramçı üçün texniki spesifikasiyalar nümunəsi

Əgər “məhsul tələbləri sənədi” sorğusu ilə xarici saytlardan keçsəniz, texniki spesifikasiyaların (TOR, PRD) öldüyü barədə yaradıcı və inandırıcı məqalələr tapa bilərsiniz. Bununla qismən razılaşmaq məcburiyyətindəyik - məhsulu sıfırdan hazırlayarkən prototipləmə, bəzən çox qeyri-peşəkar olan müştəri qeydlərinin həcmindən daha maraqlı və effektiv görünür. Bununla belə, əgər əsas sistemin yekunlaşdırılmasından danışırıqsa, o zaman işlər tamam başqa cərəyan alır. Biz həm modifikasiyalar, həm də fərdi inkişafla qarşılaşırıq, ona görə də aşpaz bizə yalan danışmırsa, texniki spesifikasiyalar it yeyən itdir. Ümumiyyətlə, bu gün satın alınan və quraşdırılmış işləri yekunlaşdırmaq üçün yazılmış klassik texniki tapşırıqlardan danışırıq proqram təminatı. Bir sözlə, ağrılı şeylər haqqında.

Qarşılıqlı təsir aspektləri

Resurslar- tələblərin həyata keçirilməsi prosesində istifadə edilməli olan insanlar, maşınlar, avadanlıqlar, inkişaf mühiti, vaxt və pul. Resurslar texniki spesifikasiyaların təsdiqi mərhələsində aydın planlaşdırma və qiymətləndirmə tələb edir. Müştəri tərəfindən düzgün prioritetləşdirmə və satıcı tərəfindən əmək resurslarının bölüşdürülməsi, buraxılmış müddətlərin qarşısını almağa və digər riskləri minimuma endirməyə imkan verir.

İmkanlar- bir sözlə, satıcının (ifaçının) əslində edə biləcəyi budur. RegionSoft CRM nümunəmizə baxaq. Müştəri sistemi satın alır və modifikasiya üçün texniki şərt tərtib edir: vebsayt ilə inteqrasiya yaratmaq və CRM-də hadisələri onlayn mağazanın sifariş nömrəsinə bağlamaq lazımdır. Bu, real tələbdir, bunu etmək üçün bizim resursumuz və imkanımız var. Siz həmçinin CRM-ə vebsayt məzmununun idarə edilməsi sistemi olan CMS-i hazırlamalı və əlavə etməlisiniz. Teorik olaraq, biz bunu edə bilərik, amma bunu ucuz etmək imkanımız yoxdur və müştərinin tapşırığa insan və vaxt resurslarını ayırmağımız üçün bizə kifayət qədər pul ödəmək imkanı yoxdur. Nəticədə, müştəri bu tələbdən imtina edir - və onun həqiqətən CMS-ə ehtiyacı yoxdur, hər şey qaydasındadır. Ancaq sonradan TK-nın "həsisliyi" haqqında.

Məhdudiyyətlər- texniki spesifikasiyalar üzrə tapşırıqların yerinə yetirilməsini çətinləşdirən və ya qeyri-mümkün edən maneələr toplusu: büdcə, texnologiya yığını, lisenziyalaşdırma problemləri, qanunvericilik qadağaları, aparat konfiqurasiyaları və s.

Beləliklə, bütün dörd mahiyyət bir-biri ilə sıx bağlıdır və bütövlükdə layihənin uğurunu müəyyən edir. Hər bir elementə nəzər salaq və texniki spesifikasiyalar üzərində işləyərkən yadda saxlanmalı olan kritik məqamları vurğulamağa çalışaq.

Tələblərin toplanması və təhlili

Heç kim şirkətinizi sizdən və işçilərinizdən yaxşı tanıya bilməz. Bu o deməkdir ki, tələblərin toplanması və təhlili yalnız sizin vəzifənizdir, burada satıcı kömək edə və istiqamətləndirə bilər, lakin heç bir halda prosesə müdaxilə etmir. Bu cür tətbiqlər haqqında tərtibatçıdan soruşun, nə axtarmaq lazım olduğunu öyrənin və işə başlayın. Yeri gəlmişkən, yaxşı bir köməkçi, ixtisaslaşdırılmış mövzunu yaxşı bilən, proqram təminatının arxitekturası haqqında təxmini təsəvvürü olan və inkişaf prosesi ilə tanış olan işçiniz ola bilər - o, analitik və daxili ekspert kimi çıxış edə bilər. texniki spesifikasiyaların yaradılması prosesi və satıcı ilə əlaqə.

Çox var sadə dövrə tələblərin toplanması.

1. CRM-dən istifadə edəcək şöbələrdən menecerlərdən və təcrübəli mütəxəssislərdən ibarət işçi qrupu yaradın. Seçmək istədiyiniz həll haqqında bizə məlumat verin, demo versiyasına girişi təmin edin.
2. İşçi qrupunun üzvləri işçilərə məlumat ötürməli və onlardan təkliflərini almalıdırlar yeni proqram tamamilə sərbəst formada. İşçilərdən biri heç vaxt belə bir proqram təminatı ilə qarşılaşmayıbsa və gələcək istifadə haqqında danışmağa hazır deyilsə, ondan dövri vəzifələrini təsvir etməyi xahiş etməlisiniz, bu universal bir yanaşmadır.
3. Daha sonra hər bir departament CRM-də nəyin olmadığını və ya ölçmədiyini müəyyənləşdirir və məlumatları birləşdirir.
4. İşçi qrupu toplanmış tələbləri təhlil edir, kəsişmələri yoxlayır və aradan qaldırır. Məsələn, tez-tez satış şöbəsi və marketinq şöbəsi eyni hesabatı sifariş edir, lakin tələblər sahələr və obyektlər üçün fərqli adlara malik ola bilər, baxmayaraq ki, onların arxasındakı məlumatlar eynidir. Buna görə də vahid formaya gəlməliyik.
5. İşçi qrupu tələblərin siyahısını yaradır və prioritetləri müəyyən edir. Bu mərhələdə siz satıcını cəlb edə bilərsiniz, çünki o, resurslara cavabdehdir. Məsələn, RegionSoft CRM üçün fərdi hesabat yaratmağı xahiş edə və ya saytla inteqrasiya sifariş edə bilərsiniz. Bunlar tamamilə fərqli son tarixləri olan vəzifələrdir, burada prioritet çox vacibdir.

Texniki spesifikasiyanın anatomiyası

• İdentifikasiya - tələblərin müəyyən edilməsi, həll edilməli olan problemlərin tapılması.
• Təhlil - tələblərin təhlili, əsas ehtiyacların müəyyən edilməsi, ümumiləşdirmə.
• Uyğunlaşma - CRM imkanları və mövcud biznes prosesləri kontekstində tələblərin qiymətləndirilməsi.
• Sənədləşmə - rəsmi və Ətraflı Təsviri tələblər, texniki şərtlərin təsdiqi.
• Təchizatçı (inkişafçı) ilə əlaqə - tərtib edilmiş texniki spesifikasiyalara uyğun olaraq təkmilləşdirmələrlə bağlı satıcı ilə təkrarlanan qarşılıqlı əlaqə.
• Tətbiq, lazımi funksionallıq yaratmaq üçün satıcının işidir. Satıcı daim müştəri ilə əlaqə saxlasa, daha yaxşıdır - bu şəkildə son məhsul müştərinin vizyonuna ən çox uyğunlaşacaqdır.
• Test - modifikasiyaya və texniki xüsusiyyətlərə uyğunluğu və dəyişikliklərlə sistemin işləkliyini müəyyən etmək üçün satıcının işçiləri, müştərinin daxili ekspertləri və son istifadəçiləri tərəfindən funksionallığın yoxlanılması.

Biznes səviyyəsi- mürəkkəb və prioritet vəzifələrin həll olunduğu ən qlobal səviyyə. Bu səviyyəyə inteqrasiya, iş proseslərinin təkmilləşdirilməsi və modelləşdirilməsi, yeni funksional modulların hazırlanması daxildir. Bir qayda olaraq, bu, ciddi məsləhətləşmələr və yaxınlıq ilə resurs tələb edən bir inkişafdır birlikdə işləmək müştəri ilə. Məsələn, bir vaxtlar RegionSoft CRM-də belə xüsusi dəyişikliklər anbar uçotu, kassa aparatı və istehsal idi. Tədricən dəyişikliklər buraxılışa daxil edildi və daha sonra topdan, pərakəndə mağazalar və hipermarketlər üçün yeni məhsul yaratmağa imkan verdi - RegionSoft Retail.

İstifadəçi və ya istifadəçi qrupu səviyyəsi. Bu səviyyədə mövcud interfeysi təkmilləşdirmək üçün tapşırıqlar həyata keçirilir. Məsələn, istifadəçi müştərinin üzərinə keçərkən sonuncu sifarişin nömrəsi və statusu olan pəncərənin və ya məlumatların xüsusi qruplaşdırılması ilə fərdi hesabatın görünməsini istəyə bilər. Bu səviyyədə təkmilləşdirmələr daha az vaxt tələb edir, lakin onların çoxu ola bilər - məsələn, marketinq, logistika və texniki dəstək.

Funksionallıq səviyyəsi. Onu əvvəlkindən ayırmaq çox vaxt çətindir, burada formal meyar işləyir - təkmilləşmə interfeysdə nəyisə göstərmək səviyyəsində deyil, sistem məntiqini yekunlaşdırmaq səviyyəsindədir. Buraya müxtəlif çeşidləmə, söhbət inteqrasiyası və telefoniya imkanları üçün tələblər daxil ola bilər.

Xidmət səviyyəsi- əslində, bu səviyyənin tələbləri düzəlişləri olan yeni quruluşlara ilk daxil edilməlidir. Bunlar sistemin cavab sürəti, yüksək yük altında işləmə və təhlükəsizliklə bağlı vəzifələrdir. IN ideal Satıcıda belə dəyişikliklər olmamalıdır - korporativ proqram təminatı yavaşlamamalı, məlumatları itirməməli, formaları yıxmamalı və eyni səviyyəli giriş hüquqlarını yaymamalıdır. Ancaq bir tələb ortaya çıxsa və bu, müştərinin şəxsi paranoyası və ya tərəfdəki problemlərlə əlaqəli deyilsə aparat, buna xüsusi diqqət yetirməyə dəyər.

Texnologiya səviyyəsi- siyahıda sonuncu, lakin əhəmiyyətinə və mürəkkəbliyinə görə qalanları qabaqlayır. Bunlar platforma ilə bağlı müştəri tələbləri ola bilər, əməliyyat sistemi və ya cihazlar. Məsələn, MacOS üçün qurmaq sorğusu. Bu cür tələblər tədricən buraxılışlara çevrilsə, əla olar, lakin onlar üçün düzəlişlərin olması vacibdir. Biz MacOS üçün RegionSoft CRM qurduq və əlavə etdik uzaqdan giriş mobil versiya üçün nadir, lakin mövcud sorğunun müvəqqəti həlli kimi TRM texnologiyasından istifadə.

Texniki spesifikasiyanın anatomiyası sadədir, ən azı skelet şəklindədir. Texniki spesifikasiyanın məcburi hissələri müştəriyə problemə diqqət yetirməyə və tapşırığı düzgün tərtib etməyə, podratçıya isə ondan nə istədiklərini başa düşməyə kömək edir. Yeri gəlmişkən, anlayış haqqında. Təbii ki, yazının əvvəlində biznes məsləhətçilərini sinif olaraq inkar edərək bir az yalan danışdıq. Məsələ burasındadır: hər bir satıcı bir neçə ildir ki, bazarda işləyir (biz bir günlük CRM-lərdən danışmırıq), hətta onilliklərdir, bu da demək olar ki, hər bir sənayedə bir sıra işlərin olması deməkdir. Müvafiq olaraq, mühəndislər, proqramçılar və satış işçiləri hər bir şirkət növündə tətbiqin xüsusiyyətləri ilə tanış olurlar. Ancaq yenə də, işinizə xüsusi diqqət yetirmək vacibdir.

Kimin üçün? Bu bölmədə, təkmilləşdirmənin son istifadəçisi kimin olacağını, hansı vəzifələrin həll edilməsinin planlaşdırıldığını və hansı tezliklə təsvir etməlisiniz.

Sizə bir misal deyim. Bir şirkət CRM tətbiq edirdi və kifayət qədər böyük məlumat toplusu üzərində işləməli idi (ayda bir neçə on milyonlarla qeyd, gündə bir neçə yüz min qeyd). Satış departamentinin rəhbəri bu qeydlərin “gündəlik” tezlikdə yüklənməsi ilə bağlı hesabat tələb etdi. Təbii ki, yüzlərlə istifadəçinin eyni vaxtda işlədiyi belə bir hesabat sistemi yüklədi - prosesi optimallaşdırmaq üçün həllər tapıldı. Artıq iş zamanı məlum oldu ki, satıcı onu təhlükəsiz oynayıb və hesabata yalnız ayın sonunda ehtiyacı var və sonra onu gecə qrafiki ilə işlətmək olar. Söz yox ki, vaxt və pul boşa getdi.

Nə üçün? Təkmilləşdirmə ehtiyacının əsaslandırılması və onun iş prosesində yeri. Bu məqam daha çox müştərinin özü üçün lazımdır, lakin satıcının başqa hansı proseslərə təsir edəcəyini bilməsi də faydalıdır. Bəzən bu, alternativ bir həll tapmağa kömək edir.

Nə etməlidir?Ən informativ blok - sistemdən tələbləri və gözləntiləri təsvir edir. Və burada baş verən mirvarilər, möcüzələr və toqquşmalar baş verir ki, onlar başorqa göndərmək düzgündür və bu, həyatı çox çətinləşdirir. Yalnız bir səbəb var - istifadəçi nə istədiyini, nə etmək lazım olduğunu bilmir. Başqa bir kiçik alt səbəb var - istifadəçi tələbləri formalaşdıra bilmir. Və burada tərtibatçının vəzifəsi (əgər varsa, işçi qrupunun, analitikin) ehtiyacı düzgün formalaşdırmaq, müvafiq tələbi seçmək və tapşırığı sistemin iş kontekstinə uyğunlaşdırmaqdır. Eyni blokda gözlənilən nəticəni qeyd etməlisiniz.

Spesifikasiya parametrləri- son tarixlər, icra mərhələləri, bütün tərəflərin məsuliyyəti, zəruri əlaqələr və s. Əslində, bu, sənədi texniki spesifikasiya edən vacib rəsmi şeylər toplusudur. İnkişaf zamanı çoxsaylı dəyişikliklərin qarşısını almaq üçün texniki tapşırıqlar tərəflər tərəfindən razılaşdırılmalı və imzalanmalıdır (onlar hələ də baş verəcək, lakin daha az dərəcədə).

İdeal olaraq, texniki spesifikasiya satıcının fəal iştirakı ilə tərtib edilir və onun nəticəsi təxminən aşağıdakı quruluşdur:

1. Hər bir mexanizm və hər bir funksionallıq tələbinin təsviri
2. Bu funksiyanın həyata keçirilməsinin təsviri
3. Hər bir mərhələ üçün işin dəyəri ayrıca
4. Bu texniki spesifikasiya üçün işin ümumi dəyəri
5. İşin mərhələlərə bölünməsi və prioritetləri göstərən vaxt çərçivələri
6. Quraşdırma şərtlərinin təsviri və dəyişikliklərin sınaqdan keçirilməsi
7. Texniki tapşırıqların və digər şərtlərin tam xarakteri ilə bağlı qeyd-şərtlər

Bir tərtibatçının göz yaşları ilə yazılmış 10 qayda

Texniki spesifikasiya acgöz olmamalıdır.Çox vaxt biznes öz imkanlarını çox qiymətləndirir və ya “hər şeyi bir anda” əldə etmək istəyir. Bu yanaşma nə maliyyə, nə də biznes baxımından əsaslandırılmır. Satıcı, bir qayda olaraq, bir neçə həftə ərzində mövcud deyil (RegionSoft vəziyyətində - 15 il) və bir müddət sonra, həqiqətən, CRM-də nəyin çatışmadığını başa düşdüyünüz zaman onunla əlaqə saxlaya bilərsiniz.

Dünəndən sözün əsl mənasında artıqlığın parlaq nümunəsi: müştəri tanınmış birindən ERP alıb. rus şirkəti, mühasibat işlədiyi üçün bu satıcının ERP-nin yaxşı olacağını düşünür. ERP təkcə özlüyündə çox yaxşı deyil, həm də biznes üçün çox yararsız olduğu ortaya çıxdı. Amma RegionSoft CRM ilə anbar uçotu və istehsal üçün əlverişlidir. Bir həll var: ERP-ni unudun, ağlayın, 1C mühasibat uçotunu yeni CRM ilə birləşdirin və rahat tətbiqdən həzz alın. Ancaq boş yerə xərclənən pula yazıq! Və müştəri CRM-i ERP ilə inteqrasiya etməyi tələb edir. Biz bunu etmədik, amma niyə belə israfçılıq, niyə iki nisbətən oxşar sistem?

Texniki tapşırıqlar real və əldə edilə bilən olmalıdır- həm tələblər, həm də müddətlər baxımından. Burada satıcının fikrini dinləmək vacibdir, çünki o, bu və ya digər işə nə qədər vaxt sərf olunacağını dəqiq bilir. İnanın, tərtibatçı üçün vaxt itirmək və son tarixləri artırmaq sərfəli deyil - onun nüfuzuna zərbə vurmamaq üçün mümkün qədər çox layihə tamamlamaq və bunu yaxşı etmək faydalıdır. Realizmə gəlincə, CRM-i kollayder idarəetmə sistemi səviyyəsinə yüksəltmək üçün müraciətlərdən qaçmaq asandır: siz tələblərə həqiqətən nəyin lazım olduğunu daxil etməlisiniz. Bu an və yaxın gələcəkdə.

Məsələn, RegionSoft CRM masa üstü proqramıdır, bizim brauzer müştərimiz yoxdur. Bizdən bir şirkət üçün veb proqram yaratmağı xahiş etmək mənasızdır, bu, böyük bir inkişafdır, hazırda davam edir və bir şirkət üçün mümkün inkişaf deyil. Xeyr, əlbəttə ki, hər şeyin öz qiyməti var, amma yenə də - ümumi vəziyyətdə tələbi yerinə yetirmək mümkün deyil.

Bu, fərdi inkişaf haqqında danışarkən və tətbiqin ideyası və məntiqinin kökündən dəyişdirildiyi vəziyyətlə qarışdırılmamalıdır; əslində, "özünüz üçün" yeni proqram təminatının yaradılması sponsorluq edilir. Amma bu başqa hekayədir.

Texniki tapşırıqlar ətraflı şəkildə göstərilməlidir. Gələcək layihənin bütün əhəmiyyətli detallarını göstərmək lazımdır: proqramın istifadə tezliyindən interfeys üçün istəklərə qədər. Tələblər nə qədər təfərrüatlı olarsa, tətbiq və sınaq bir o qədər asan və sürətli olar. Müəyyən bir sənayedə (tibb, sığorta, banklar) işləyirsinizsə, xüsusilə təfərrüata diqqət yetirməyə dəyər - biznes və proqram arasında qarşılıqlı əlaqənin nüanslarının ətraflı təqdimatı satıcının tapşırığı başa düşməsini və sistemi tez bir zamanda uyğunlaşdırmasını təmin edəcəkdir. sizin şirkət.

Rəqəm formatlarına, sahə adlarına, açılan siyahıların mövcudluğuna və ya olmamasına, düymələrin və göstərişlərin davranışına və məlumat növlərinə diqqət yetirdiyinizə əmin olun. Müştəri CRM əməliyyatının məntiqinə daxil edilməli olan öz düsturlarından istifadə edərsə ( məsələn, diler bonuslarının hesablanması), bu düsturlar onların təyinatının və hesablama məntiqinin tam izahı ilə yazılmalıdır.

Texniki spesifikasiya birmənalı və dəqiq olmalıdır. Qeyri-müəyyən formulasiyalar, icra variantları, qeyri-müəyyən tələblər - bütün bunlar dalana aparan yoldur. Belə olur ki, müştəri yaxşı niyyətlə texniki spesifikasiyada sistemin davranışı üçün yaxın, lakin ekvivalent olmayan bir neçə variant yazır. Bu vəziyyətdə o, proqramçıya kömək etdiyinə, sövq etdiyinə əmindir, amma əslində cəhənnəmə aparan yol yaxşı niyyətlərlə döşənir, tərtibatçı tam olaraq nəyin lazım olduğunu başa düşməlidir və bunu əsas götürərək özü seçəcəkdir. sistemin xüsusiyyətləri və istifadə olunan texnologiyalar yığını haqqında.

Texniki spesifikasiya insan dilində yazılmalıdır. Və bu vacibdir, yox, VACİB. Dil problemlərinin layihənin icrasında gecikmələrə səbəb olduğu iki vəziyyəti qeyd edəcəyəm.

1. Müştəri texniki savadını nümayiş etdirməyə çalışır və "təqvimdə bir pəncərə görünməlidir" əvəzinə "təqvimin gövdəsinə zəng hadisələrinə reaksiya vermək qabiliyyəti ilə işarəsi olan bir pəncərə tətbiq edin ..." kimi konstruksiyalar hazırlayır. burada tapşırığı tamamlanmış kimi qeyd edə bilərsiniz." Əgər sizin və ya daxili ekspertinizin texniki mətnlər yazmaq bacarığı yoxdursa, Google-a müraciət etməyin - adi sözlərlə yazın, biz onları başa düşürük.

   Texniki tapşırıqlar şikayətlər kitabı olmamalıdır. Problemi təsvir etmədən həll etməli, şriftlərə diqqət yetirməli və tələbləri təsvir etməyi unutmalısınız. Texniki spesifikasiya yalnız problemin özünü deyil, həm də onun dərketmə səviyyəsində həllini ehtiva etməlidir - onda tərtibatçı onu kod səviyyəsində həll edəcəkdir. Müqayisə et “Satış departamenti yaxşı planlaşdırmır, saylarını itirir, artıq bir ildir ki, mübarizə aparırıq” Və "Məhsul qrupları üzrə bölünmüş aylıq planlaşdırılmış və faktiki satışların dəyərlərini saxlayacaq bir hesabat yaratmaq lazımdır".

   Texniki tapşırıqlar gələcəyə baxmağı bacarmalıdır. Düzdür, yox, arxasında duran insanlar. İş proseslərində dəyişikliklərin tezliklə baş verəcəyi məlumdursa, dəyişikliklərə iki dəfə pul ödəməmək üçün bu nəzərə alınmalıdır.

   Texniki tapşırıqlar bürokratik olmamalıdır.Əgər siz bu sənədi nə vaxtsa tərtib etmisinizsə, yəqin ki, bürokratiyaya sürüklənmək, giriş sözləri, sərt ifadələr əlavə etmək və hər bir bəndi Cinayət Məcəlləsinin bir maddəsi kimi təsvir etmək şirnikləndiricisindən qaçmağın nə qədər çətin olduğunu yəqin ki, hiss etmisiniz (pozuntuya görə hər kəs üçün cəza nəzərdə tutulmalıdır. ). Bürokratik tərtibatlar texniki spesifikasiyaların yaradılması məqsədlərinin natamam başa düşülməsini maskalayır. Satıcının məsuliyyəti müqavilədə göstərilib, büdcə də orada yazılıb. Bu nöqtələri texniki xüsusiyyətlərə köçürməməlisiniz.

   Texniki tapşırıqlar texniki şərtlər olmalıdır. Paradoksal səslənir, lakin biz tez-tez texniki spesifikasiyalar əvəzinə məktubları, şikayətləri, müqavilələri, CRM üçün yeni yazılmış təlimatları və ya iclas protokollarını oxuyuruq. Təbii ki, belə bir sənədlə işləmək mümkün deyil. Forma və məzmunun üstündə qalmaq üçün köhnə məktəb hiyləsindən istifadə edin: terminə sözbəsöz baxın. Texniki vasitələr modifikasiyanı, texnologiyanı diktə edir və proqram təminatını dəyişdirərək problemin həllinə yönəlir. Proqram təminatı kontekstində bu barədə danışmalıyıq. Tapşırıq məsləhət, məsləhət və ya ilkin qiymətləndirmə olmadan sual, problem qoymaq deməkdir. Sadəcə problemin ifadəsi.

   Əmrlər bitdi, indi məzəmmət

   Sadalanan qaydalara əlavə olaraq, danışmağa dəyər bir neçə şey daha var. Söhbət məqsədlərdən, planlardan və gözləntilərdən gedir - layihəni uğurlu edən bütün elementlər və satıcı ilə müştəri arasında dostluq münasibətləri.

   Texniki şərtləri tez yazmaq lazımdır, hətta proseslərin avtomatlaşdırılması vəzifəsi ilə qarşılaşsanız belə mobil operator və ya böyük bir hipermarket. Bunun səbəbi texnologiyaların böyük sürətlə inkişaf etməsi və hətta tətbiq etdiyiniz sistemin altı ay və ya bir il ərzində böyük buraxılışdan (və ya bəzən iki) sağ çıxa bilməsi və yeni funksionallıq əldə etməsi ilə bağlıdır. Dəyişikliklərə ehtiyacı yenidən nəzərdən keçirməli və prosesə yenidən başlamalısınız.

   

   
   Nəhayət, texniki tapşırığı bitirmək üçün vaxt tapdı. Ancaq təəssüf ki, onu həyata keçirmək üçün heç bir tərtibatçı qalmayıb.

   Müştəri yığından və texniki məhdudiyyətlərdən xəbərsizdir. Və bilməməlidir - bu satıcının vəzifəsidir, texniki şərtləri tərtib etdikdən sonra işi qiymətləndirən odur. Müştəri texnologiyaya baş vurmamalı və hər vergüldə satıcının bu və ya digər şeyi edə biləcəyini soruşmamalıdır. Hərtərəfli texniki spesifikasiya hazırlayın və tərtibatçı uyğun bir arxitektura seçəcək - çox vaxt düşündüyünüzdən daha yaxşıdır.

   Büdcənizi qiymətləndirin və xoşagəlməz sürprizlərdən qaçın- demək olar ki, bir nömrəli birgə tapşırıq. Satıcını itələməməli və ondan işin təxmini qiymətləndirilməsini tələb etməməlisiniz (yaxşı, ən azı təqribən, gözlənilməz, lakin başqalarında olduğu kimi, bu tip layihələrdə, amma təcrübədən, yaxşı, daxili xəta marjası). Büdcənin tam qiymətləndirilməsi yalnız texniki tapşırıqların oxunmasından, təhlilindən və yekun təsdiqindən sonra mümkündür. Tərtibatçınız fərqli davranırsa, düzəlişin ən azı iki dəfə baha olacağına hazır olun.

   Dəyişikliklərə və genişlənmələrə olan obyektiv ehtiyac əsasında- Yuxarıda yazdım ki, tərtibatçı yoxa çıxmır və istənilən vaxt tələblərinizə uyğun olaraq dəyişiklik və əlavələr etməyə hazırdır. Buna görə də, dərhal xəyallarınızın CRM/ERP-ni yaratmağa çalışmayın, satıcıdan “Mən qəhvə içəndə hər şey işləyir” düyməsini tələb etməyin - sistemdə işləyin, sizin üçün tənqidi şərhləri müəyyənləşdirin və tələbləri toplamağa və rəsm çəkməyə başlayın. texniki spesifikasiyalar.

   Texniki tapşırıqlar haqqında sonsuz yaza bilərsiniz, bu, təkcə memlar və nağılların deyil, həm də baş ağrılarının əsl generatorudur. Prioritetlər və dizayn qaydaları haqqında, texniki spesifikasiyaları qeyri-insani edən QOST 1989, bir az daha yaxşı olan IEEE standartları, onları tamamlayan prototiplər və texniki spesifikasiyalar haqqında danışa bilərsiniz. Ancaq sonda özümü bir, ən vacib qayda ilə məhdudlaşdırmaq istərdim: texniki spesifikasiya qanunun aliliyi deyil, QOST deyil və dogma deyil, ona görə də onu təkmilləşdirə bilirsinizsə, təkmilləşdirin, sadələşdirə bilsəniz, təkmilləşdirin. bunu sadələşdirin, əgər zərif şəkildə edə bilirsinizsə və hamının xoşuna gəlsinsə, bunu edin. Əminəm ki, bundan sonra heç kim texniki şərtlərə burnunu soxub orada yazılmayıb deməyəcək. Və ya demək olar ki, heç kim.

   Dekabr ayı ərzində biz RegionSoft CRM və bütün öz proqram təminatımıza endirimlər edirik. Dekabrın 1-dən dekabrın 15-dək - 15% və hissə-hissə və kirayə üçün kəskin şərtlər. Bizdə -70% və -90% yoxdur, çünki biz lisenziyaların qiymətini iqtisadi cəhətdən əsaslandırırıq və onu gözdən salmırıq.

   Yaxşı, əgər sizə CRM sisteminə ehtiyacınız varsa (dəyişiklikli və ya modifikasiyasız), onda gedin saytımız, CRM, onun üstünlükləri və digər korporativ proqram təminatı haqqında çox şey var.

   Bəli, biz həmişə CRM və digər məhsulları satmağa, CRM-i dəyişdirməyə və satmağa, proqram təminatı satmağa və istifadəçiləri öyrətməyə hazır olan tərəfdaşlar axtarırıq. Gəlir bölgüsü ədalətli və tərəfdaş üçün faydalıdır. Biz sizə göstərəcəyik, sizə danışacağıq, sizə öyrədəcəyik. -a yazın [email protected]

   Slaydlar, slaydlar. Komikslər http://www.modernanalyst.com/ və Pinterest-dən götürülmüşdür. Əgər daha yaxşı tərcümə olarsa, onu posta əlavə etməkdən məmnun olarıq.

Mən tez-tez səhifə prototiplərini əlavə edirəm ki, müştəri saytının necə görünəcəyini başa düşsün. Sonra layout dizayneri üçün ayrıca bir tapşırıq tərtib edirəm - işində kömək edəcək texniki detallar və izahatlarla.

Tapşırıq nə qədər mürəkkəb olsa, texniki spesifikasiya bir o qədər ətraflı olmalıdır. Böyük layihələrdə iştirak edəndə 30 səhifə uzunluğunda texniki spesifikasiyalar gördüm.

Quram Sipki, Udix Media rəqəmsal studiyasının yaradıcısı

Müştəriyə ilk növbədə texniki spesifikasiyalar lazımdır - belə ki, o, öz veb-saytının necə olacağını və pulun nəyə xərclənəcəyini başa düşsün. Bir şey səhv olarsa, o, texniki şərtlərə müraciət edə və onun yenidən düzəldilməsini xahiş edə bilər.

Texniki spesifikasiya layihə rəhbəri tərəfindən müştəri ilə əlaqə saxladıqdan və tapşırığı dizaynerlə müzakirə etdikdən sonra tərtib edilir.

Böyük müştərilər tez-tez hər düyməni təsvir edən çox ətraflı texniki spesifikasiyalar tələb edirlər. Kiçik şirkətlər isə əksinə, vasvası 100 səhifəlik sənədləri sevmirlər.

Veb saytın təkmilləşdirilməsi üçün texniki tapşırıq nümunəsi

Ümumi məlumat

Avtomatlaşdırılmış sistemin adı

"AS Sbyt"

Müştəri

icraçı

İş üçün əsas

Sistemin yaradılması üzrə işlərin başlaması və bitməsi üçün planlaşdırılan tarixlər

İşə başlama: 01.09.2010

İşin başa çatması: 31.12.2010

Sistemin yaradılmasının məqsədi və məqsədləri

Sistemin məqsədi

İnkişaf mərhələsindədir avtomatlaşdırılmış sistem müəssisə satış proseslərinin avtomatlaşdırılması üçün nəzərdə tutulmuşdur.

Sistemin yaradılmasının məqsədləri

Avtomatlaşdırılmış sistemin yaradılmasının məqsədləri

"AS Sbyt" in inkişafının məqsədləri bunlardır:

1. 3. Avtomatlaşdırma obyektinin xüsusiyyətləri

3.1 Müəssisənin biznes prosesləri

3.1. 1 İş prosesi "Müqavilə bağlamaq"

Bu, sizin qalxanınıza çevriləcək; bu sənəddə, əgər bir şey olarsa, barmağınızı vicdansız bir tərtibatçıya göstərə və saytınızın buna uyğunlaşdırılmasını tələb edə bilərsiniz.

Texniki tapşırıq(qısacası, “TOR”) gələcək vebsaytınız üçün tələbləri mümkün qədər ətraflı və birmənalı şəkildə əks etdirən sənəddir.

Veb sayt dəqiq texniki şərtlər əsasında yaradılmışdır. Nə qədər təfərrüatlı və birmənalı olsa, yeni saytınız gözləntilərinizi bir o qədər çox qarşılayacaq.

Veb saytın yaradılması üçün texniki tapşırıqlar - qanun kimi şərhlərə və uyğunsuzluğa yol verməməlidir.

Tərtibatçı texniki spesifikasiyalarda göstərilməyən hər şeyi öz istəyi ilə edir.

· Administrator üçün təlimat;

· Məzmun Meneceri Bələdçisi;

· Quraşdırma təlimatı;

· Proqramçının Bələdçisi.

2.20. Rusiya Federasiyası Prokurorluğu yanında İstintaq Komitəsinin mütəxəssisləri üçün təlimlərin təşkili və keçirilməsi

Aşağıdakı təlim tələbləri tətbiq olunur:

· Podratçı İstintaq Komitəsinin əməkdaşları üçün prokurorluqda təlim keçməlidir Rusiya Federasiyası 10 nəfərdən çox olmayan.

· Təlim rus dilində aparılmalıdır.

· Təlim binaları Sifarişçi tərəfindən təmin edilir.

· Təlimin yeri və vaxtı Sifarişçi ilə razılaşdırılmalıdır.

Təlim Sistemin bütün funksiyaları üzrə aparılmalıdır.

Təlimin bir hissəsi olaraq, Rusiya Federasiyası Prokurorluğu yanında İstintaq Komitəsinin Saytlar Halqasının bir pilot saytının məlumat məzmununu həyata keçirmək lazımdır.

3.

Veb saytın təkmilləşdirilməsi üçün nümunə texniki spesifikasiyalar

Əhəmiyyətli

İcra prosesi zamanı Podratçı İcra Cədvəli çərçivəsində Sifarişçiyə yardım göstərməlidir.

6.1.11. Sifarişçinin personalının icraya zəif hazırlanması və proqram təminatının uğurla həyata keçirilməsi üçün Podratçı tərəfindən əlavə yardıma ehtiyac olduğu halda, məlumat və məsləhət işlərinin verilməsi üçün müqavilə qiymətlərinin razılaşdırılması üçün əlavə protokol tərtib edilməlidir.

6.2 “SATIŞ” AS tapşırıqlarının sonrakı dəstəklənməsi proseduru.

TOR əlavə tələbləri həyata keçirmək üçün işin mürəkkəbliyini və dəyərini göstərməlidir.

6.2.2. Podratçı proqram təminatı dəstəyi üçün telefon qaynar xəttini saxlamağı öhdəsinə götürür.

Qarşılıqlı təsir aspektləri Texniki spesifikasiyanın yaradılması prosesini tədqiq etməyə başlamazdan əvvəl, layihəyə başlayarkən podratçı və sifarişçinin düşdüyü dördbucaqdan danışaq. Tələblər- həyata keçirilməli olan müştəri və ya proses sahibi tərəfindən təsvir edilən sistemin arzu olunan davranışı. Bir qayda olaraq, tələblər iş təcrübəsi və proqramın düzgün davranışının başa düşülməsi əsasında formalaşır.

Bu, tərtibatçı (satıcı) üçün əsas məlumatdır, lakin tələblərin toplanması mərhələsində ən çox toqquşma, səhv, lazımsız sorğular və s. yaranır.

Resurslar- tələblərin həyata keçirilməsi prosesində istifadə edilməli olan insanlar, maşınlar, avadanlıqlar, inkişaf mühiti, vaxt və pul. Resurslar texniki spesifikasiyaların təsdiqi mərhələsində aydın planlaşdırma və qiymətləndirmə tələb edir.

Buraya müxtəlif çeşidləmə, söhbət inteqrasiyası və telefoniya imkanları üçün tələblər daxil ola bilər.

Xidmət səviyyəsi- əslində, bu səviyyənin tələbləri düzəlişləri olan yeni quruluşlara ilk daxil edilməlidir. Bunlar sistemin cavab sürəti, yüksək yük altında işləmə və təhlükəsizliklə bağlı vəzifələrdir.

Diqqət

İdeal olaraq, satıcıda belə dəyişikliklər olmamalıdır - korporativ proqram təminatı yavaşlamamalı, məlumatları itirməməli, formaları yıxmamalı və eyni səviyyəli giriş hüquqlarını yaymamalıdır. Ancaq bir tələb yaranarsa və bu, müştərinin şəxsi paranoyası və ya aparat tərəfindəki problemlərlə əlaqəli deyilsə, ona daha çox diqqət yetirməyə dəyər.

Texnologiya səviyyəsi- siyahıda sonuncu, lakin əhəmiyyətinə və mürəkkəbliyinə görə qalanları qabaqlayır.

Microsoft World və ya Microsoft Excel.

Şəxsən biz açılış səhifəsini hazırlayarkən xüsusi proqram məhsullarından istifadə edirik.

Onların köməyi ilə siz tez və asanlıqla hətta mürəkkəb saytlar üçün layihələr yarada bilərsiniz - məsələn, Balsamiq. Bununla belə, bütün prototipi necə hazırlayacağımız məqalədə artıq təsvir edilmişdir.

Mövzu haqqında: Veb sayt prototipi: yaradılması, alətlər və proqramlar.

Layihədən əvvəl dizayn tərtibatçı ilə birlikdə edilə bilər və ya tamamilə onun çiyinlərinə köçürülə bilər.
Əsas odur ki, unutmayın, sonra hər iki tərəf tərəfindən razılaşdırılır və imzalanır.

TOR TƏRKİBİ ÜÇÜN HAYAT HAKLARI

Bu məqamlar həm brifinqin doldurulmasına, həm də texniki şərtlərin tərtib edilməsinə eyni dərəcədə aiddir.

Onlarda sizə bir veb sayt üçün texniki spesifikasiyalar tərtib etmək və bir sahibkarın onsuz da çətin həyatını asanlaşdırmaq üçün kiçik fəndlər söyləyəcəyəm:

1.

Müştəri ilə ifaçının bir-birini düzgün başa düşdüyünə əmin olun”.

Texniki tapşırıqda keyfiyyətli sifətlər olmamalıdır: gözəl, etibarlı, müasir. Onları aydın başa düşmək mümkün deyil. Hər kəsin öz gözəllik və müasirlik anlayışı var.

Bax. Kimsə bu dizaynın gözəl olduğunu düşündü və veb saytında istifadə etməyə icazə verdi:

Eyni şey, özlüyündə heç bir məna daşımayan qeyri-müəyyən formalarda baş verir:

• Müştəri saytı bəyənməlidir. Bəs onun əhvalı pisdirsə?
• Sayt rahat olmalıdır. Bunun mənası nədi? Nə üçün əlverişlidir?
• Sayt ağır yüklərə tab gətirməlidir. 10 min ziyarətçi? Yoxsa 10 milyon?
• Yüksək keyfiyyətli ekspert məzmunu. Yaxşı, fikri başa düşürsən.

Mətndə qeyri-müəyyənlikləri yoxlayın. Əgər varsa, yenidən yazın.

Bir veb sayt (aka açılış səhifəsi) sifariş etmək qərarına gəldinizmi? Təcrübə göstərir ki, bu o qədər də sadə deyil. Hazır veb-saytını görən yüzlərlə müştəri bunun onlara uyğun olmadığını aşkar edir: dizayn səhvdir, tərtibat axsaqdır, mətnlər səhvdir, bir sıra lazımsız funksiyalar əlavə edilib.

Bu cür nəticələrin qarşısını almaq üçün veb saytın inkişafı üçün texniki spesifikasiyalar lazımdır.

MƏNƏ LAZIMDIR?!

Saytı kimin idarə edəcəyinin heç bir əhəmiyyəti yoxdur - siz özünüz, qohumunuz, təvazökar əmək haqqı üçün frilanserlər, böyük miqdarda pul üçün ixtisaslaşmış şirkət...

Saytın texniki xüsusiyyətləri olmalıdır.

Məsələn, RegionSoft CRM üçün fərdi hesabat yaratmağı xahiş edə və ya saytla inteqrasiya sifariş edə bilərsiniz. Bunlar tamamilə fərqli son tarixləri olan vəzifələrdir, burada prioritet çox vacibdir.Tələblər toplandıqdan, təhlil edildikdən və işçilər və rəhbərliklə razılaşdırıldıqdan sonra texniki spesifikasiya yaratmağa başlaya bilərsiniz.
Formanı satıcıdan soruşa və ya özünüz yarada bilərsiniz - hər halda, bir neçə dəmirli qaydalar var ki, onlara riayət etmək sizi və CRM təchizatçınızın baş ağrısından xilas edəcək.

Texniki spesifikasiyanın anatomiyası

Texniki spesifikasiyanın yaradılması prosesi haqqında danışsaq, bir neçə mərhələ var. Onların ardıcıl keçidi müştərini istənilən təkmilləşdirməyə aparır.
Budurlar.

Burada satıcının fikrini dinləmək vacibdir, çünki o, bu və ya digər işə nə qədər vaxt sərf olunacağını dəqiq bilir. İnanın, tərtibatçı üçün vaxt itirmək və son tarixləri artırmaq sərfəli deyil - onun nüfuzuna zərbə vurmamaq üçün mümkün qədər çox layihə tamamlamaq və bunu yaxşı etmək faydalıdır.

Realizmə gəlincə, CRM-i kollayder idarəetmə sistemi səviyyəsinə yüksəltmək üçün müraciətlərdən qaçınmaq sadədir: tələblərə hazırda və yaxın gələcəkdə həqiqətən lazım olanları daxil etməlisiniz.

Məsələn, RegionSoft CRM masa üstü proqramıdır, bizim brauzer müştərimiz yoxdur. Bizdən bir şirkət üçün veb proqram yaratmağı xahiş etmək mənasızdır, bu, böyük bir inkişafdır, hazırda davam edir və bir şirkət üçün mümkün inkişaf deyil.

İnformasiya sisteminin tam və qısa adları

Sistemin tam adı Rusiya Federasiyası Prokurorluğu yanında İstintaq Komitəsinin rəsmi saytıdır.

Sistemin qısa adı “SKP Site”, “System”, “Site”dir.

1.2. Sistem müştərisinin adı və onun təfərrüatları

Adı: Rusiya Federasiyası Prokurorluğu yanında İstintaq Komitəsi

Məkan:

Məlumat

Moskva, Texniki prospekt, bina 2

Faktiki ünvan: A

Müştəri ilə əlaqə saxlayan şəxs:

Telefon: (4, (4;

E-poçt ünvanı

1.3. Sistemin yaradıldığı sənədlərin siyahısı

___ ___________ 2010-cu il tarixli ________________ nömrəli dövlət müqaviləsi

1.4.

Müqaviləyə uyğun olaraq müəyyən edilir.

2. Sistem tələbləri

2.1.

ödəniş tarixi

Ödəniş nömrəsi

Ödəniş sistemindəki ödəniş nömrəsi

Ödəniş məbləği

1. Məlumat ötürmə fayl xətlərini seçin
2. Məlumat ötürmə faylının sətirləri arasında dövrə vurmağa başlayın
3. Məlumat ötürmə fayl xəttini oxuyun
4. Müqavilə kodunu məlumat ötürmə faylı xəttindən alın
5. Müvafiq elementi "Qarşı tərəf müqavilələri" kataloqunda kodla tapın; element tapılmadıqda, "Kodla razılaşma tapılmadı ..." mesajını göstərin.
6. Element tapılarsa, dəyərlər cədvəlinə bir sətir əlavə edin, burada: "Müqavilə" - tapılan element, "Tarix" - "Data_plat", "Ödəniş nömrəsi" - "Nomer_plat", "Məbləğ" - "Summa_plat"
7. Məlumat ötürmə faylının son sətrini aldıqdan sonra dövrü bitirin
8. Dəyər cədvəlinin hər sətri üçün “Vəsaitlərin alınması üçün ödəniş tapşırığı” sənədi yaradın.

Veb saytının dizaynı üçün qısa məlumat doldurarkən və ya texniki tapşırıqlar tərtib edərkən, orada heç bir boşluq buraxmayın.

Anlamalısınız ki, "İnkişafçının təqdiri ilə" "Mən istədiyimi edirəm" və ya "Müəyyən edilməyən hər şey ifaçının təqdiri ilə edilir" deməkdir. Və mənə inanın, bu, sadəcə bir boşluq deyil, tərtibatçı üçün Avropaya açılan bütöv bir pəncərədir.

Və təbii ki, bu həmişə baş vermir.

Səlahiyyətli bir mütəxəssislə qarşılaşsanız, nəticədən narahat olmaq lazım deyil.

Ancaq burada başqa bir problem ortaya çıxır: o, əslində bunu düzgün edə bilər, ancaq bunu sırf subyektiv olaraq bəyənməyəcəksiniz. Və hər şey bir çox tərtibatçıya məlum olan zarafatdakı kimi olacaq:

ƏSAS ŞEYLƏR HAQQINDA QISA

Veb sayt və ya açılış səhifəsi yaratmaq üçün texniki şərtləri tərtib etmək və razılaşdırmaq üçün sərf etdiyiniz vaxta görə peşman olmayacaqsınız.

Axı, bu, prosesdə yaranan fikir ayrılıqlarını izləmək və həll etmək üçün ən yaxşı vasitənizdir.

Müəyyən bir rayonu kliklədiyiniz zaman o, bu rayonun mətn təsviri olan səhifəyə keçməlidir.

· “Sədr bloqu” bloku- mövzunun adı və dərc olunma tarixi şəklində bloqda yaradılmış ən son üç mövzunun siyahısı olmalıdır. Mövzunun adı kliklədikdə sizi bu mövzunu təsvir edən bloq səhifəsinə aparan bir keçid olacaq. Bu blokda ayrılmadan oynaya bilən video da olmalıdır ana səhifə. Videoda verilmiş video şəklinə şərhlərin sayını əks etdirən "Şərhlər" linki olmalıdır. “Şərhlər” linki təqdim edilmiş videoya şərhlərin olduğu bloq səhifəsinə aparmalıdır.

Altbilgidə axtarış qutusu, müəllif hüquqları məlumatı və s. olmalıdır.

2.3.

Qısa məzmun, dizayn, texniki imkanlar Gələcək saytınız.

Təbii ki, hər iki tərəfin imzaladığı müfəssəl brifinq texniki tapşırığı əvəz edə bilər.

Axı, bu, praktiki olaraq eyni şeydir, yeganə fərq odur ki, brifinq sizin görmə qabiliyyətinizdir, texniki spesifikasiya isə qısa və tərtibatçının öz şərhlərinə əsaslanan yekun sənəddir.

Müəyyən məqamlar çətinlik yaradırsa, o zaman tərtibatçıya “Bu nə deməkdir?”, “Bu, saytımın işinə necə təsir edəcək?” kimi suallar verməkdən çəkinməyin, çünki bütün tərtibatçılar sizinlə eyni şeyi başa düşmürlər.

ya " sütununda əlavə informasiya“Sualların cavablarına daxil edilməyən bütün istəklərinizi mütləq qeyd edin.

Bu sütun yoxdursa, sadəcə olaraq onları brifinqin sonuna əlavə edin.

VK, Google, Facebook.

3.2.2 V şəxsi hesab sifarişlər bölməsində promo kodu əlavə etmək üçün sahə əlavə edin.

3.2.3 İstifadəçinin parolun bərpası sorğusundan sonra aldığı səhifənin əvəzinə (məsələn, name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=) səhifə yaradın (məsələn, name.com/login/forgot) /change_password=yes&lang =ru&USER_CHECKWORD=) saytın məzmununu göstərəcək, “Qeydiyyatdan sonra e-poçt” sahəsi, nəzarət xətti, yeni parol, parolun təsdiqi və məlumat göndərmə düyməsi olacaq.

3.2.4 Səbətə əşyalar əlavə edilərkən, əşyanın səbətə əlavə edildiyini bildirən mesaj göstərilməlidir.

3.2.5 Yeni istifadəçinin qeydiyyatı zamanı parolun təhlükəsizlik parametrlərinə uyğun gəlmədiyini göstərən mesaj çıxışını əlavə edin.

"_" ______________ 2010

Tədricən dəyişikliklər buraxılışa daxil edildi və daha sonra topdan, pərakəndə mağazalar və hipermarketlər üçün yeni məhsul yaratmağa imkan verdi - RegionSoft Retail.

İstifadəçi və ya istifadəçi qrupu səviyyəsi. Bu səviyyədə mövcud interfeysi təkmilləşdirmək üçün tapşırıqlar həyata keçirilir. Məsələn, istifadəçi müştərinin üzərinə keçərkən sonuncu sifarişin nömrəsi və statusu olan pəncərənin və ya məlumatların xüsusi qruplaşdırılması ilə fərdi hesabatın görünməsini istəyə bilər.

Bu səviyyədə yenidən işləmək daha az vaxt tələb edir, lakin onların çoxu ola bilər - məsələn, marketinq, logistika və texniki dəstək şöbələrindən bir neçə tələb.

Funksionallıq səviyyəsi. Onu əvvəlkindən ayırmaq çox vaxt çətindir, burada formal meyar işləyir - təkmilləşmə interfeysdə nəyisə göstərmək səviyyəsində deyil, sistem məntiqini yekunlaşdırmaq səviyyəsindədir.

Əgər sıyıq deyirsə, bəlkə qaçıb arxaya baxmamalısan.

• İfaçının vicdansızlığından sığortalayın. Sayt hazır olduqda, texniki şərtlərə uyğun olaraq yoxlanıla bilər. Hər hansı uyğunsuzluqlar varmı? Tərtibatçı onları düzəltməyə borcludur. Əgər rəsmi əməkdaşlıq edirsinizsə və müqavilə bağlamısınızsa, hətta məhkəmə yolu ilə bunu məcbur edə bilərsiniz.
• İfaçıların dəyişdirilməsini sadələşdirin.Əgər müştəri və tərtibatçı mübahisə edib qaçıbsa, saytın yaradılması çox vaxt apara bilər. Ətraflı texniki spesifikasiya olduqda, onu yeni komandaya keçirmək olar - onlar işə dəfələrlə daha tez qoşulacaqlar.
• Mürəkkəb bir məhsulun hazırlanmasının dəyərini öyrənin. Mürəkkəb bir veb xidmətinin hazırlanmasının dəqiq vaxtını və dəyərini dərhal qiymətləndirmək mümkün deyil. Əvvəlcə xidmətin necə işləyəcəyini və hansı funksiyalara sahib olacağını başa düşməlisiniz.

Kök girişi, öz IP ünvanlarınız, portlarınız, filtrləmə qaydaları və marşrutlaşdırma cədvəlləri var.

Google PageSpeed ​​Insights pulsuz xidmət istifadəçinin brauzerində səhifənin göstərilməsini sürətləndirmək üçün vebsaytlar üçün tövsiyələr (https://developers.google.com/speed/pagespeed/insights/).

Axtarış motorunun optimallaşdırılması (və ya SEO) xüsusi istifadəçi istəkləri üçün axtarış sistemlərinin nəticələrində saytın mövqeyini artırmaq üçün daxili və xarici optimallaşdırma üçün tədbirlər toplusudur.

Xarici veb-saytın optimallaşdırılması veb-saytın qeydiyyatdan keçməsidir Axtarış motorları, promosyon sosial şəbəkələrdə, digər resurslardan irəli sürülən sayta keçidlər cəlb etməklə linkin qurulması, banner reklamı, kontekstli reklam.

Daxili saytın optimallaşdırılması mətnin, URL-lərin optimallaşdırılması, sayt strukturunun redaktəsi, əlaqələndirilməsi, server cavablarının yoxlanılmasıdır.

Mövcud materiallar Sevimli saytlarınıza keçidlər, həmçinin bukletlər, jurnallar, fotoşəkillər - nə olursa olsun və ya bəlkə də hazır brend kitabınız var. Ayrı bir arxiv kimi əlavə olunur. Minimum ayırdetmə və displey qurğuları Bu paraqrafda sayta hansı cihazlardan baxmaq niyyətində olduğunuzu göstərin - fərdi kompüterlər, noutbuklar, smartfonlar... 19-dan 27 düymədək kompüter monitorları; 15,6 ilə 17,3 düym arasında olan noutbuklar; 3,5 ilə 6 düym arasında smartfonlar; 7 ilə 12 düym arasında tabletlər lazımdırmı mobil versiya? Bəli FUNKSİONAL TƏLƏBLƏR Təxmini modul dəsti (istifadəçilər üçün) Bu bölmədə bütün funksionallıq, saytda görmək istədiyiniz.

Bu, alış-veriş səbəti, müxtəlif parametrlərə əsaslanan kataloq filtrləri, onlayn sifariş vermək, sorğu buraxmaq ola bilər. geri zəng, xəbər bülleteni və hər hansı digər seçimlərə abunə olun Kataloq filtrləri qiymətə, əlifba sırasına, istehsalçıya görə.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EХHJя(gTT┬Pb╟▌╤└u╟╛#╜┘al+Ka Kqяk3╜┘al+Ka Kqяk3┈└┐┕i┕i ts╜IWA▓BOьvOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:╜┘al+KaXG[ b:╜┘al+KaXG[ b:╜┌u⤜ ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛#╜┘al+KaXG[╜┘al+KaXG[┕:b╟▌╜┕b #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:╜┘al+KaXG[ b:bVzhb╬XuFy ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NлkZ ⌡ ⌡ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх═с┬├6ыСыиЪr V├6ыСыиЪ╖E═rV╖B ┬ 7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s_2╫J) OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Mörfi qanununu xatırlayırsınız? Səhv başa düşülə bilsəniz, şübhəsiz ki, səhv başa düşüləcəksiniz. Bu, təkcə insanlar arasında ünsiyyətdə deyil, veb-saytların yaradılmasında da belədir. Müştəri ikinci Facebook istədi, lakin gənc it yetişdiriciləri üçün bir forum aldı. Tərtibatçı müştərinin nə istədiyini təxmin etmədi - vaxtını boşa xərclədi.

Bu təlimatda mən sizə texniki tapşırıqda nəyi və nə üçün yazmağınız lazım olduğunu söyləyəcəyəm. Eyni zamanda, texniki spesifikasiyaların yaradılması boş vaxta çevrilməməsi üçün necə yazmamağı sizə göstərəcəyəm.

Məqalə faydalı olacaq:

• Veb saytın yaradılmasında iştirak edən hər kəs üçün: tərtibatçılar, dizaynerlər, tərtibatçılar.
• Layihə menecerləri.
• Rəqəmsal studiyaların rəhbərləri.
• Veb saytın hazırlanmasını sifariş etməyi planlaşdıran sahibkarlar.

Materialı faydalı etmək üçün bir neçə tərtibatçıdan, dizaynerdən, layihə menecerindən və rəqəmsal studiyaların sahiblərindən şərhlər topladım. Ən dəyərlilərini məqalənin sonuna əlavə etdim. Gedək öyrənək.

Texniki spesifikasiya nədir və nə üçün lazımdır?

Texniki spesifikasiya sayt üçün tələbləri müəyyən edən sənəddir. Bu tələblər nə qədər aydın və təfərrüatlı olarsa, prosesin bütün iştirakçıları bunun necə olması lazım olduğunu bir o qədər yaxşı başa düşürlər. Bu o deməkdir ki, hər kəsin nəticədən razı qalma şansı artır.

Texniki spesifikasiyanın əsas məqsədi müştəri və podratçının bir-birini düzgün başa düşməsinə əmin olmaqdır.

Texniki spesifikasiyalar bir çox üstünlüklərə malikdir. Hər tərəf üçün fərqlidir.

Müştəri üçün üstünlüklər:

• Nəyə görə pul ödədiyini və saytın necə olacağını anlayın. Dərhal strukturu görə bilərsiniz, nəyin və necə işləyəcəyini anlaya bilərsiniz. Hər şeyin sizə uyğun olub olmadığını anlayın. Əks təqdirdə, inkişaf başlamazdan əvvəl onu dəyişdirmək problem deyil.
• İfaçının bacarıqlarına baxın.Əgər texniki tapşırıqlar aydın və dəqiqdirsə, tərtibatçıya inam artır. Əgər sıyıq deyirsə, bəlkə qaçıb arxaya baxmamalısan.
• İfaçının vicdansızlığından sığortalayın. Sayt hazır olduqda, texniki şərtlərə uyğun olaraq yoxlanıla bilər. Hər hansı uyğunsuzluqlar varmı? Tərtibatçı onları düzəltməyə borcludur. Əgər rəsmi əməkdaşlıq edirsinizsə və müqavilə bağlamısınızsa, hətta məhkəmə yolu ilə bunu məcbur edə bilərsiniz.
• İfaçıların dəyişdirilməsini sadələşdirin.Əgər müştəri və tərtibatçı mübahisə edib qaçıbsa, saytın yaradılması çox vaxt apara bilər. Ətraflı texniki spesifikasiya olduqda, onu yeni komandaya keçirmək olar - onlar işə dəfələrlə daha tez qoşulacaqlar.
• Mürəkkəb bir məhsulun hazırlanmasının dəyərini öyrənin. Mürəkkəb bir veb xidmətinin hazırlanmasının dəqiq vaxtını və dəyərini dərhal qiymətləndirmək mümkün deyil. Əvvəlcə xidmətin necə işləyəcəyini və hansı funksiyalara sahib olacağını başa düşməlisiniz. Bunun üçün texniki şərtləri hazırlamalısınız.

İfaçı üçün üstünlüklər:

• Müştərinin nə istədiyini anlayın. Müştəriyə onlarla sual verilir, nümunələr göstərilir və həll yolları təklif olunur. Sonra hər şeyi bir sənədə yazıb razılaşırlar. Hər şey qaydasındadırsa - hurray, düzgün başa düşdün.
• Müştərinin qəfil istəklərindən özünüzü sığortalayın. Bəzən tapşırığı yarıda dəyişmək istəyən müştərilərlə rastlaşırsınız. Əgər siz razılaşmısınızsa və texniki tapşırıqlara imza atmısınızsa, bundan qorxmursunuz. Bir şey olarsa, hətta məhkəmə də sizin tərəfinizdə olacaq.
• Bacarıqlarınızı göstərin. Yaxşı hazırlanmış texniki spesifikasiya müştəriyə tərtibatçıların təcrübəsini göstərəcəkdir. Şirkət veb saytın hazırlanmasında sizə etibar edib-etməməkdən şübhələnirsə, şübhələr çox güman ki, aradan qalxacaq.
• Pul qazanmaq üçün. Bəzi studiyalar və tərtibatçılar ayrıca xidmət kimi texniki şərtlərin hazırlanmasını təklif edirlər.

• İnkişaf prosesini asanlaşdırın və sürətləndirin. Yaxşı texniki spesifikasiya saytın strukturunu, hər səhifədə lazımi funksiyaları və elementləri göstərir. Bütün tələblər artıq gözünüzün qabağında olduqda, kodu tərtib etmək və yazmaq qalır.

İndi bütün bu funksiyaları yerinə yetirən yaxşı texniki spesifikasiyanın necə yaradılacağını anlayaq.

Texniki tapşırıqlar ifaçı tərəfindən tərtib edilir

Ümumiyyətlə, hər kəs texniki şərtləri tərtib edə bilər. "Bizə stomatoloji klinika üçün vizit kartı veb-saytı lazımdır" - bu artıq texniki tapşırıqdır. Bəs o öz funksiyalarını yerinə yetirəcəkmi? Çətinliklə.

Yaxşı texniki spesifikasiya həmişə icraçı tərəfindən hazırlanır: layihə meneceri və ya tərtibatçı. Aydındır ki, veb tərtibatçısı veb saytların yaradılmasını kafe və ya stomatoloji klinika sahibindən daha çox başa düşür. Buna görə də o, layihəni təsvir etməli olacaq.

Bu o demək deyil ki, müştəri yox olur və ən sonunda görünür: "Zbs, mən təsdiq edirəm". O, həmçinin prosesdə iştirak etməlidir:

Əlbəttə ki, müştəri texniki xüsusiyyətlərin öz versiyasını eskiz edə bilər. Bəlkə də bu, son texniki şərtlərin yaradılması prosesini sürətləndirəcək. Və ya bəlkə də nəticə gizli şəkildə zibil qutusuna atılacaq zibil olacaq.

Aydın və dəqiq yazın

Bu tövsiyə texniki tapşırığın əsas məqsədindən irəli gəlir - "Müştəri və podratçının bir-birini düzgün başa düşdüyünə əmin olun."

Texniki tapşırıqda keyfiyyətli sifətlər olmamalıdır: gözəl, etibarlı, müasir. Onları aydın başa düşmək mümkün deyil. Hər kəsin öz gözəllik və müasirlik anlayışı var.

Bax. Kimsə bu dizaynın gözəl olduğunu düşündü və veb saytında istifadə etməyə icazə verdi:

Eyni şey, özlüyündə heç bir məna daşımayan qeyri-müəyyən formalarda baş verir:

• Müştəri saytı bəyənməlidir. Bəs onun əhvalı pisdirsə?
• Sayt rahat olmalıdır. Bunun mənası nədi? Nə üçün əlverişlidir?
• Sayt ağır yüklərə tab gətirməlidir. 10 min ziyarətçi? Yoxsa 10 milyon?
• Yüksək keyfiyyətli ekspert məzmunu. Yaxşı, fikri başa düşürsən.

Mətndə qeyri-müəyyənlikləri yoxlayın. Əgər varsa, yenidən yazın. Sözləriniz aydın və dəqiq olmalıdır:

• Sayt tez yüklənməlidir → Saytdakı istənilən səhifənin Google PageSpeed ​​​​Insights-da 80-dən çox xal olmalıdır.
• Ağır yüklər → eyni zamanda 50 min ziyarətçi.
• Əsas səhifədə məqalələrin siyahısı göstərilir → Əsas səhifədə son dərc olunmuş 6 məqalənin siyahısı göstərilir.
• Minimalist istifadəçi dostu abunə interfeysi → “E-poçtunuzu buraxın” sahəsi və “Abunə ol” düyməsi → *çəkilmiş eskiz*.

Sözləri sıraladıq, strukturu nəzərdən keçirək.

Zəhmət olmasa ümumi məlumat verin

Bütün komanda üzvləri şirkətin nə etdiyini və hədəf auditoriyasının kim olduğunu düzgün başa düşməlidirlər. Heç kimin çaşqın olmaması üçün bunu texniki tapşırıqların əvvəlində yazmaq daha yaxşıdır.

Bloq əvəzinə onlayn mağaza ilə nəticələnməmək üçün saytın məqsədini göstərməyə və onun funksionallığını qısaca təsvir etməyə dəyər.

Çətin şərtləri izah edin

Texniki tapşırıqların birinci qaydası ondan ibarətdir ki, o, nəzərdə tutulduğu hər kəs üçün başa düşülən olmalıdır. Əgər uşaq oyuncaq mağazasının sahibi olan müştərinizin başa düşə bilməyəcəyi terminlərdən istifadə edəcəksinizsə, mütləq izah edin. Aydın dildə, Vikipediyadan kopyala-yapışdırmayın.

Alətləri və hostinq tələblərini təsvir edin

Təsəvvür edin ki, 2 ay ərzində gözəl vebsayt yaratmısınız. Hər bir mərhələ müştəri ilə razılaşdırıldı - o, sevindi. İndi işi təhvil verməyin vaxtıdır. İdarəetmə panelini göstərirsiniz və müştəri qışqırır: “Bu nədir? Modex?! Düşündüm ki, bunu WordPress-də edəcəksən!”

Belə problemlərin qarşısını almaq üçün istifadə olunan alətləri, mühərrikləri və kitabxanaları təsvir edin. Eyni zamanda, hostinq tələblərinizi göstərin. Heç vaxt bilmirsiniz, bunu PHP-də edəcəksiniz - və müştərinin .NET-də serveri var.

Saytın fəaliyyəti üçün tələbləri sadalayın

Sayt bütün mövcud brauzerlərdə və bütün növ cihazlarda işləməlidir. Bəli, bu, hər hansı bir tərtibatçı və istənilən müştəri üçün aydındır. Ancaq müştərini pis niyyətlə görülən işdən qorumaq üçün yazmaq daha yaxşıdır.

Saytın yükləmə sürəti, yükləmə müqaviməti, haker hücumlarından qorunma və buna bənzər tələbləri buraya yazın.

Saytın strukturunu müəyyənləşdirin

Dizaynı və tərtibatı çəkməyə başlamazdan əvvəl saytın strukturunu müştəri ilə razılaşdırmalısınız.

Müştəri ilə danışın və ona nə lazım olduğunu öyrənin. Tərtibatçıları, SEO mütəxəssislərini, marketoloqları, baş redaktorları toplayın və saytda hansı səhifələrin lazım olduğuna qərar verin. Onların bir-birinə necə bağlanacağını, hansından keçə biləcəyinizi düşünün.

Strukturu siyahı ilə göstərə, blok diaqram çəkə bilərsiniz. İstədiyiniz kimi.

Bu, saytda işləməyin ən vacib mərhələlərindən biridir. Struktur təməldir. Uğursuz olarsa, sayt əyri çıxacaq.

Hər səhifədə nə olacağını izah edin

Müştəri hər bir səhifənin nə üçün lazım olduğunu və orada hansı elementlərin olacağını başa düşməlidir. Bunu göstərməyin iki yolu var.

Prototip- daha vizual və birmənalı şəkildə. Podratçı hər bir səhifənin eskizlərini çəkir və onları texniki tapşırıqlara əlavə edir. Müştəri gələcək veb-saytının interfeysinin necə olacağını görür və nəyi bəyəndiyini və nəyin dəyişdirilməli olduğunu söyləyir.

Elementlərin sadalanması- prototipə tənbəl alternativ. Sadəcə səhifədə hansı blokların olması lazım olduğunu və nə etdiklərini yazın.

Saytdan istifadə üçün ssenariləri təsvir edin

Bir növ qeyri-standart interfeys edirsinizsə, sadəcə strukturu və səhifənin kiçik şəkillərini göstərmək kifayət deyil. Bütün icra komandasının və müştərinin ziyarətçilərin saytdan necə istifadə edəcəyini başa düşməsi vacibdir. Bunun üçün skriptlər əladır. Ssenari diaqramı çox sadədir:

• İstifadəçi hərəkəti.
• Saytın cavabı.
• Nəticə.

Əlbəttə ki, standart bir vizit kartı və ya açılış səhifəsi hazırlayırsınızsa, skriptlər yazmağa ehtiyac yoxdur. Amma saytda bəzi interaktiv xidmətlər varsa, bu, çox arzuolunandır.

Vikipediyada istifadə halları haqqında ətraflı oxuyun.

Məzmun üçün kimin məsuliyyət daşıdığını müəyyənləşdirin

Bəzi tərtibatçılar dərhal məzmunlu veb sayt yaradırlar. Digərləri balıq yerləşdirir. Digərləri mətnlər yaza bilər, lakin əlavə ödənişlə. Sahildə bununla razılaşın və texniki göstərişdə hansı məzmunu hazırlamalı olduğunuzu yazın.

Mətnlərin keyfiyyətini qiymətləndirmək üçün obyektiv meyarlar irəli sürmək olduqca çətindir. “Hədəf auditoriyası üçün faydalı olan yüksək keyfiyyətli, maraqlı və satılan məzmun”dan başqa heç nə yazmamaq daha yaxşıdır. Zibildir, heç kimə lazım deyil.

Bütün məzmunun unikal olması lazım olduğunu qeyd etmək faydalıdır. Müştəri üçün vicdansız ifaçılardan başqa bir qorunma.

Dizaynı təsvir edin (mümkünsə)

Mətndə olduğu kimi, veb-sayt dizaynını qiymətləndirmək üçün də obyektiv meyarlar irəli sürmək çətindir. Əgər siz və müştəri rəng sxemi üzərində razılaşmısınızsa, onu yazın. Əgər onun şriftlərin göstərildiyi brend kitabı varsa, onları da göstərin.

Gözəl və müasir dizayn haqqında yazmağa ehtiyac yoxdur. Bu heç nə demək deyil, gücü yoxdur və ümumiyyətlə uf.

Nəticə əvəzinə: texniki tapşırığın strukturu

Texniki şərtlərin strukturu müxtəlif vəzifələr üçün fərqli olacaq. Yeni sosial şəbəkə və yerkökü topdan satışı üçün açılış səhifəsi üçün eyni texniki spesifikasiyalar etmək axmaqlıqdır. Ancaq ümumiyyətlə bu bölmələrə ehtiyacınız var:

• Şirkət və hədəf auditoriyası, saytın məqsəd və vəzifələri haqqında məlumat.
• Müştəri üçün aydın olmayan terminlərin lüğəti.
• Saytın tərtibatı və istismarı üçün texniki tələblər.
• İstifadə olunan texnologiyaların təsviri və hostinq tələblərinin siyahısı.
• Ətraflı sayt quruluşu.
• Səhifələrin prototipləri və ya onlarda olmalı olan elementlərin təsvirləri.
• Qeyri-standart interfeysdən istifadə üçün ssenarilər (isteğe bağlı).
• Tərtibatçının hazırladığı məzmunun siyahısı.
• Dizayn tələbləri (isteğe bağlı).

• Proqram Tələbləri Spesifikasiyasının tərtibi qaydaları. SRS texniki spesifikasiyaların təkamülündə növbəti addımdır. Böyük və mürəkkəb layihələr üçün lazımdır.
• Proqram təminatının inkişafı üçün texniki şərtlərin standartları və şablonları. Müxtəlif GOST-ların təsvirləri və texniki spesifikasiyalar yaratmaq üçün metodologiyalar.

Yazdığım hissənin sonu budur. Ancaq başqa biri var - bələdçinin hazırlanmasında kömək edən mütəxəssislərin şərhləri. Oxuyun, o da maraqlıdır.

Tərtibatçı Şərhləri

Texniki spesifikasiyaları necə yaratdıqlarını öyrənmək üçün bir neçə tərtibatçı ilə danışdım. Mikrofonu onlara verirəm.

Müştəriyə ilk növbədə texniki spesifikasiyalar lazımdır - belə ki, o, öz veb-saytının necə olacağını və pulun nəyə xərclənəcəyini başa düşsün. Bir şey səhv olarsa, o, texniki şərtlərə müraciət edə və onun yenidən düzəldilməsini xahiş edə bilər.

Texniki spesifikasiya layihə rəhbəri tərəfindən müştəri ilə əlaqə saxladıqdan və tapşırığı dizaynerlə müzakirə etdikdən sonra tərtib edilir.

Böyük müştərilər tez-tez hər düyməni təsvir edən çox ətraflı texniki spesifikasiyalar tələb edirlər. Kiçik şirkətlər isə əksinə, vasvası 100 səhifəlik sənədləri sevmirlər. Bu uzun oxunur və vacib bir şeyi qaçırmaq asandır. Daha tez-tez biz 10-15 səhifəlik qısa texniki spesifikasiyalar edirik.

Göstəririk:

• Şirkət haqqında məlumat və saytın məqsədi.
• Dizayn, rəng sxemi üçün tələblər.
• İstifadə olunan texnologiyalar və CMS.
• Məzmunu kim istehsal edir - biz və ya müştəri.
• Saytın strukturu hər səhifəyə qədər.
• Hər səhifənin təsviri. Biz prototiplər hazırlamırıq, lakin səhifədə hansı elementlərin olması və necə işləməsi lazım olduğunu müəyyənləşdiririk.

Son 2 bölmə ən önəmlidir. Onlar saytın necə olacağını və necə işləyəcəyini başa düşməyə imkan verənlərdir.

Çox vacib bir məqam - yalnız tərtibatçılara istinad şərtlərini vermək və hər şeyi yaxşı edəcəklərinə ümid etmək olmaz. Texniki spesifikasiya sayt üçün tələblərin siyahısıdır, rabitəni əvəz edə bilməz. Hər bir komanda üzvünün ümumi məqsədi başa düşdüyünə və sadəcə tapşırıqları yerinə yetirmədiyinə əmin olmaq vacibdir. Bir şey aydın deyilsə, izah etmək, müzakirə etmək, ətraflı şərhlər vermək lazımdır.

Həyatda tez-tez olur ki, insan gündəlik işlərdə belə nə istədiyini izah edə bilmir. Proqramçıya “istəklərinizi” izah etməyə gəldikdə, insan sadəcə olaraq stupora düşür.

İdeal olaraq, texniki şərtlər müştəri tərəfindən tərtib edilməlidir - yalnız o, nəyə ehtiyacı olduğunu bilir. Ancaq praktikada, müştərinin 1C sahəsində aşağı səriştəsi səbəbindən bunu tez-tez podratçı etməli olur. Müştəri öz ehtiyaclarını şifahi şəkildə bildirir, proqramçı (məsləhətçi) isə bunu yazılı şəkildə bildirir.

Niyə texniki xüsusiyyətlərə ehtiyacınız var?

İstənilən, ideal olaraq, texniki spesifikasiyalar ilə müşayiət olunmalıdır. Bu, birincisi, tapşırığın, son tarixlərin və icra üsulunun dəqiq tərifidir. İkincisi, bu bir sənəddir ki, onun köməyi ilə gələcəkdə bütün mübahisəli məsələlər həll olunur. Texniki spesifikasiyalar yazıb-yazmamaq, əlbəttə ki, sizin işinizdir; şəxsən mənim üçün texniki spesifikasiyalar işimi və müştəri ilə ünsiyyətimi asanlaşdırır.

1C-də 267 video dərsi pulsuz əldə edin:

Texniki tapşırıqda nə olmalıdır?

Bunlar. tapşırıqda aşağıdakılar olmalıdır:

• hədəf— bu spesifikasiyanı həyata keçirməklə həll edəcəyimiz problem;
• təsviri— qarşıdan gələn təkmilləşdirmələrin xülasəsi;
• həyata keçirmə üsulu— məqsədin həlli üsullarının ətraflı təsviri. Bu zaman proqramçının dilində tapşırığın bütün nüanslarını təsvir etmək lazımdır: biz hansı tapşırıqları yaradırıq/redaktə edirik, interfeys necə olmalıdır və s. Əgər "proqramçı dilində" danışmırsınızsa, amma "bir şey eşitmisinizsə", texniki dildə yazmağa çalışmamaq daha yaxşıdır - olduqca əyləncəli olur. Təsvir birmənalı olmalı və suallar yaratmamalıdır. O, həmçinin başqa sahədə oxşar həllin tətbiqi nümunəsini ehtiva edə bilər;
• performansın qiymətləndirilməsi- çox vacib bir məqam, əmək xərclərinin təsviri.

Texniki şərtlərin yazılması üçün dövlət standartları da var - GOST. Praktikada onlar nadir hallarda istifadə olunur, lakin bəzən müştəri bunu israr edir.

Təcrübəyə görə, işi təhvil verərkən çox vaxt “biz sənə dedik...” kimi vəziyyətlər yaranır ki, bu da o qədər də xoş deyil və çox vaxt bütün işi yenidən yerinə yetirməli olursan. Buna görə də, yaxşı yazılmış texniki spesifikasiya hər iki tərəfin həyatını xeyli asanlaşdırır.

1C üçün texniki şərtlərin nümunələri və nümunələri

İnternetdə sərbəst tapdığım kiçik bir seçim. Ən sadə və ən əlçatan olandan başlayaraq olduqca mürəkkəb sənədlərə qədər.