Pradėsiu nuo pokšto apie kariuomenę. Vadas duoda įsakymą Stroybato karių kuopai: „Kasame nuo tvoros iki saulėlydžio! Panaši situacija gali susidaryti ir kūrėjams. Kiekvienas komandos narys gali paklausti: „Kada baigsis? Iš tiesų, darbas šioje srityje gali tęstis ilgą laiką. Kuriant programinę įrangą ir svetainių dizainą būtina žinoti klientą tenkinantį lygį.
Visuotinai priimta, kad tik projekto vadovas turi žinoti visus projekto duomenis. Kita vertus, gali būti konfliktinė situacija jeigu projekto vadovo ir užsakovo nuomonė apie galutinį projektą skirsis. Ir dar viena situacija, jei projektų vadovas, turintis supratimą apie baigiamąjį plėtros projekto etapą, nepatenkintas atlyginimu ir rytoj pereis į kitą darbą?
Techninė užduotis(TOR) yra oficialus dokumentas, reglamentuojantis visus svetainės ar programinės įrangos produkto dizaino kūrimo etapus. Klaidinga manyti, kad tai ilgas kliento sąlygų išvardijimas. Iš TK tikimasi, kad bus aiškiai ir glaustai aprašytos kūrimo detalės ir kaip turėtų atrodyti galutinis produktas. Nereikėtų to painioti su sutartimi, kurioje nurodoma šalių atsakomybė, tarpusavio atsiskaitymai ir kiti organizaciniai klausimai.
Techninė užduotis interneto svetainės dizaino kūrimui turi būti parengtas nesvarbu, kokio dydžio projektas būtų. Problema slypi ne dydyje, o skirtinguose rangovo ir užsakovo požiūriuose į galutinį įvairių to paties proceso aspektų rezultatą. Nesutarus dėl visų smulkmenų, gali būti sugaištos pastangos, laikas ir pinigai. Sugadinta reputacija ir geri santykiai.
Todėl pasistengsime atskleisti visą techninių specifikacijų rašymo išmintį svetainės dizaino kūrimui. Dizaineriui svarbu nerašyti krūvos storų popierių šūsnių, bet svarbus rezultatas – profesionaliai sukurta svetainė. Gerai parašytos svetainės plėtros sąlygos atspindės dėmesingą požiūrį į visus projekto dalyvius ir parodys plėtros kryptį interneto svetainių kūrimas.
Taip pat verta prisiminti, kad TK turi nemažai apribojimų. Pirmiausia kalbėsime apie techninių specifikacijų sudarymą naudojant kaskadinį metodą, tačiau kitais atvejais naudojami kiti metodai. Antra, reikėtų atskirti TOR projektavimą dideliems portalams ir TOR mažo biudžeto svetainėms. Skirtumas yra dokumentų dydis. Kuo didesnė apimtis, tuo didesnė ir nuobodesnė bus plėtra, didelės apimties TOR, skirta svetainės dizaino kūrimui, bus daug formalumų. Tačiau TOR dydis labiau priklauso nuo projekto kūrimo sudėtingumo, o ne nuo jo dydžio.
Į kokius klausimus turėtų teisingai atsakyti gerai parašyta techninė užduotis? Svetainės dizaino kūrimo užduotys yra itin svarbios tokiems projekto dalyviams kaip projekto vadovas, kūrėjai ir užsakovai. Pagrindiniai svetainės vartotojai bus būsimos svetainės klientai ir lankytojai. Remiantis tuo, techninėse sąlygose būtina išsamiai nurodyti asmenis, kurie naudosis svetaine. Tai gali būti įmonės darbuotojai ir kiti lankytojai. Tokios detalės yra svarbios, nes jose yra svarbi informacija, kuri gali sudaryti reikalavimus kuriant svetainės dizainą.
Kokie yra svetainės dizaino kūrimo etapai? Tai jau minėjome aukščiau. Darbo užduotyse labai detaliai pasirašytas visas darbo su projektu procesas. Toks žingsnis – itin reikalinga priemonė. Kadangi nėra vienos kūrimo metodikos, TOR privaloma surašyti visus pagrindinius kūrimo taškus ir kiekvieną iš jų detaliai aprašyti. Kuo baigsis klientas? Svetainės dizaino kūrimas prasideda nuo techninės užduoties ir ja baigiasi. Kiekvieną techninės užduoties punktą reikia aptarti kartu su užsakovu, viską patikrinti, išsiaiškinti. ToR yra atlikto darbo įrodymas.
Ko reikia norint pradėti kurti svetainės dizainą? Kartais šis klausimas ištraukiamas atskirame dokumente, pavyzdžiui, sutartyje. Tačiau rengiant TK tai taip pat svarbu. Atsakymas į šį klausimą priklauso nuo to, kiek specialistų galima įtraukti, kokias programas naudoti ir pan.
Pirmoje dalyje ir ToR įvade aprašomi formalumai ir įprastos frazės. Ši dokumento dalis keičiasi tik kartkartėmis ir tik kai kuriose vietose. Kaip ir daugumoje dokumentų, bendrojoje dalyje rašoma informacija apie užsakovą ir rangovą, jų rekvizitai, teisiniai duomenys ir dokumento statusas. Jei ką nors praleidote šioje dalyje, nieko tokio, nes pagrindinė tokio plano informacija bus nurodyta sutartyje.
1. Patalpų remonto darbų (toliau – darbai) vieta, sąlygos ir terminai:
1.1. Darbo vieta:
Negyvenamosios patalpos Nr.50, esančios 5-ame pastato aukšte adresu:
1.2. Darbo sąlygos:
Darbai turi būti atliekami pagal šią Patalpų remonto darbų atlikimo techninę užduotį (toliau – Techninė užduotis). Darbų eigą kontroliuoja Klientas. Išjungti inžinerinės sistemos, tinklai ar atskiros jų atkarpos atliekamos tik iš anksto susitarus su Užsakovu ir Turto valdymo skyriumi ir žemės išteklių Tverės miesto administracija.
Darbai atliekami pagal Lokalinę patalpų remonto darbų atlikimo sąmatą (datos sutarties priedas Nr. (toliau – Sutartis)).
1.3. Apsisukimo laikas:
Rangovas įsipareigoja pradėti darbus po to, kai šalys pasirašo šią sutartį ne vėliau kaip kitą dieną po patalpų remonto lokalinės sąmatos suderinimo su Tverės miesto administracijos Turto valdymo ir žemės išteklių skyriumi. , atlikti visus darbus ir perduoti jų rezultatą Užsakovui ne vėliau kaip per 30 (trisdešimt) kalendorinių dienų nuo darbų pradžios.
2. Bendrosios darbų charakteristikos:
Negyvenamųjų patalpų Nr.50, esančių pastato adresu: (toliau – patalpos) 5 aukšte, remonto darbų atlikimas.
3. Reikalavimai darbų kokybei ir saugai:
3.1 Kokybės reikalavimai, Techninės specifikacijos darbų atlikimo ir kitus rodiklius, susijusius su atliekamų darbų atitikties Užsakovo poreikiams nustatymu, nustato galiojantys Statybos reglamentai ir taisyklės (toliau – SNiP), statybos taisyklių rinkiniai (toliau – SP), žinybinis statybos kodeksus(toliau VSN), sanitarines taisykles ir normas (toliau SanPiN), valstybiniai standartai(toliau – GOST), specifikacijas(toliau TU), normos priešgaisrinė sauga(toliau – NPB), taisyklės priešgaisrinė sauga(toliau – PPB), elektros instaliacijos įrengimo taisyklėmis (toliau – PUE) ir kitais norminiais dokumentais.
Darbų atlikimo metu privaloma laikytis teritorijoje galiojančių technologijų ir darbo metodų, aplinkosaugos, sanitarinių ir higienos, priešgaisrinių ir kitų normų reikalavimų. Rusijos Federacija:
Statybos normos ir taisyklės SNiP „Darbo sauga statybose“;
Federalinis įstatymas -FZ „Pastatų ir konstrukcijų saugos techninės taisyklės“;
Federalinis įstatymas -FZ „Dėl priešgaisrinės saugos“;
Statybos normos ir taisyklės SNiP "Pastatų ir statinių priešgaisrinė sauga";
Priešgaisrinės saugos standartai NPB 244-97 „Statybinės medžiagos. Dekoratyvinės apdailos ir apdailos medžiagos. Grindų dangos medžiagos. stogo danga, hidroizoliacija ir termoizoliacinės medžiagos. Priešgaisrinės saugos rodikliai.
Federalinis įstatymas -FZ "Techninės taisyklės dėl priešgaisrinės saugos reikalavimų".
3.2. Atsitiktinės mirties arba netyčinio sugadinimo pavojus negyvenamoms patalpoms atliekant darbus iki užsakovo priėmimo, tenka Rangovui.
4. Reikalavimai darbo organizavimui:
4.1. Darbai turi būti atliekami darbo dienomis: pirmadienį, antradienį, trečiadienį, ketvirtadienį 09.00-18.00, penktadienį 09.00-16.45. Darbo organizavimas šeštadienį vykdomas iš anksto susitarus su Užsakovu nuo 09.00 iki 16.00 val.
4.2. Rangovas privalo savo jėgomis ir priemonėmis užtikrinti darbų atlikimą iš savo medžiagų. Medžiagų sudėtis nurodyta Patalpų remonto darbų atlikimo Lokalinėje sąmatoje (Sutarties priedas Nr. 1).
4.3. Tik kvalifikuoti specialistai, turintys atitinkamą kategoriją pagal nustatytą reguliavimo teisinis veikia statybos srityje. Neleidžiama pritraukti nerezidentų ir užsienio specialistų be tinkamos registracijos ir leidimo pritraukti užsienio darbo jėgą, kai tokias pareigas nustato galiojantis Rusijos Federacijos teisės aktai.
4.4. Tinkama medžiagų, įrangos apsauga, statybinė įranga ir kitą Rangovo turtą darbų atlikimo laikotarpiui turi pateikti Rangovas.
5. Reikalavimai medžiagoms ir įrangai
5.1. Darbams atlikti naudojamų medžiagų ir įrangos kokybė ir sauga turi atitikti privalomuosius techninių reglamentų reikalavimus, valstybinius elektros, mechaninės ir priešgaisrinės saugos standartus, akustiką, pramoninių radijo trukdžių lygį, atsparumą elektromagnetiniams trukdžiams ir higienos reikalavimus, sanitariniai standartai ir taisykles bei būti patvirtintos atitikties deklaracijomis, atitikties sertifikatais ir sanitarinėmis bei epidemiologinėmis išvadomis.
5.2. Visos medžiagos turi turėti atitinkamus sertifikatus, sanitarines ir epidemiologines išvadas, techninių duomenų lapus ir kiti jų kokybę patvirtinantys dokumentai. Šių pažymų kopijas ir pan., Užsakovui reikia pateikti ne vėliau kaip prieš dvi kalendorines dienas iki darbų, atliekamų naudojant šias medžiagas ir įrangą, pradžios.
6. Reikalavimai apdailos darbams
6.1. Patalpų paruošimas laikymui remonto darbai(nenaudojamų ortakių išmontavimas, metalines konstrukcijas , vandentiekio vamzdžiai, sandarinant nenaudojamus išmetimo kanalus sienose).
6.2. sienų apdaila gipso kartono, su technologinių nišų įrenginiu pagal geografiniai žemėlapiai, vaizdo kameros, garso stiprinimo technika. Vamzdžių stelažų įtaisas besiūlių vaizdo plokščių išdėstymui ir tvirtinimui.
Sumontuotas gipso kartonas prieš klijavimą turi būti nušlifuotas. Gruntuoti reikia prieš šlifavimą ir po šlifavimo. Naudokite giliai įsiskverbiantį gruntą. Klijuojant neaustiniais tapetais, kuriuos reikia dažyti vandeniniais dažais, tapetų tekstūrą ir dažų spalvą derinti su Užsakovu.
6.3. Pakabinamų lubų montavimas.
Patalpų luboms naudokite - pakabinamas lubas "Armstrong" ir lubų plyteles "Baikal".
6.4. Grindų remontas.
Išmontuoti nuo grindų seną linoleumą ir cokolį, įrengti technologinius kanalus ir liukus sumontuotai įrangai prijungti. Išlyginkite cementiniu lygintuvu. Gulėk laminatas klasė ne žemesnė kaip 32, spalva "Bukas", spalva derinama su Užsakovu. Cokolis turi būti plastikinis, "Buko" spalvos su kabeliniais kanalais. Grindų danga neturi turėti defektų, grindys turi būti lygios, be matomų tarpų, nelygumų.
6.5. Tarptautinių pertvarų įtaisas.
Pertvaros turi būti iš gipso kartono, su garso izoliacija ir stumdomais stiklo paketais valdymo patalpoje, gruntuoti prieš užpildant ir po šlifavimo giluminio įsiskverbimo gruntu. Klijavimas neaustiniais tapetais dažymui vandeniniais dažais, tapetų tekstūra ir dažų spalva derinama su Užsakovu. Įrengti įėjimo duris ir duris gretimose patalpose pagal susitarimą su Užsakovu.
6.6. Išmontuoti senas palangių varčias, medines palangių lentas, montuoti langų blokus iš dviejų kamerų PVC stiklo paketų, plastikinių palangių lentų.
Dvigubo stiklo langų spalva yra balta. Langai turi turėti atidaromų dalių ne mažiau kaip 1/3 ploto. Langų angos turi būti komplektuojamos su žaliuzėmis ir roletais, spalva derinama su Užsakovu. Palangės – plastikinės, ne mažesnės kaip 50 cm gylio.
6.7. Kosmetinis centrinio šildymo baterijų remontas.
Temperatūros reguliatorių montavimas. Gipso kartono ekranų montavimas su ventiliacija grotelės. Gruntavimas turi būti atliktas prieš tai glaistymas o po šlifavimo gilaus įsiskverbimo gruntu. Klijavimas neaustiniais tapetais dažymui vandeniniais dažais, tapetų tekstūra ir dažų spalva derinama su Užsakovu.
7. Reikalavimai elektros darbams
7.1. Atlikti elektros darbus pagal Schemą elektros instaliacija(Užduoties 9 punktas).
7.2. Gamyboje elektros darbai vadovaukitės SNiP 3.05.06-85 „Elektros prietaisai“ reikalavimais. Kištukinius lizdus įrengti įrengtuose kabelių kanaluose ne mažesniu kaip 0,5 m atstumu nuo grindų lygio, išorinis tvirtinimas.
7.3. Sumontuokite elektros skirstomąjį skydą (ES) su instaliacija 9 grandinės pertraukikliai(automatinė degalinių tinklo apsauga ).
7.4. Norėdami apšviesti ir apšviesti nišas kortelėmis, naudokite energiją taupančias ekologiškas lempas.
7.5. Visus elektros kabelius tiesti atvirai palei sienas kabelių kanaluose, virš pakabinamų lubų nedegiame, gofruotame vamzdyje, elektros kabelius kloti grindyse metaliniuose vamzdžiuose arba metaliniuose profiliuose. Numatyti technologinius liukus kabelių tiesimui.
7.6. Prijunkite vartotojų maitinimo laidus prie sumontuotos skirstomosios skydo su automatiniais jungikliais, nutieskite maitinimo kabelį ir prijunkite prie skirstomasis skydas centrinis biuras (41 kambarys) per grandinės pertraukiklį.
7.7. padas kabelių maršrutai nustatyti darbų atlikimo metu.
7.8. Montuojant naudokite kabelį su PVC izoliacija variniais laidais nedegiame PVC apvalkale, pagamintą pagal GOST 22483 „Laidūs variniai laidai kabeliams, laidams ir laidams. Pagrindiniai parametrai. Techniniai reikalavimai“. Kištukiniai lizdai turi atitikti Europos standartą. Visos medžiagos ir įranga turi turėti sertifikatus, techninius pasus ir kitus kokybę liudijančius dokumentus, atitikti PUE reikalavimus, SNiP ir PPB. Visos medžiagos turi būti naujos ir pagamintos ne vėliau kaip iki 2012 m. I ketv.
8. Reikalavimai darbo kokybės užtikrinimo laikotarpiui
Atliktų darbų kokybės užtikrinimo laikotarpis, atsižvelgiant į panaudotas medžiagas, turėtų būti 36 mėnesiai 100% nuo atliktų darbų priėmimo akto (forma KS-2) pasirašymo dienos. Per garantinis laikotarpis Rangovas privalo savo lėšomis pašalinti visus pagal Sutartį atliktų darbų rezultato trūkumus per ne ilgesnį kaip 15 (penkiolika) kalendorinių dienų laikotarpį nuo Užsakovo reikalavimo dienos.
9. Sujungimo schema.
Galiu prisiminti stebėtinai mažai medžiagos apie svetainių ir programų dizainą rusų kalba, parašytą rusakalbių autorių. Tai palengvina daugiausia į eksportą orientuota plėtra (ofšoras) ir masinės patirties kuriant informacinius produktus trūkumas mūsų šalyje.
Tikiuosi, kad šis straipsnis bus naudingas tiems kūrėjams ir IT vadovams, kurie susidūrė su aukštos kokybės dokumentų, skirtų svetainės kūrimui, sudarymo problema. Dokumentai, kurie, be sugadinto popieriaus, bent kažkaip praverstų.
įvadinis
Kodėl reikia parengti svetainės techninę užduotį (TOR)?
Kad ir kokią kūrimo metodiką naudotumėte ir kokio dydžio būtų jūsų svetainė, bet kuriuo atveju susidursite su klausimu: „O kai baigsime darbą, kaip suprasime, kad tikrai jį baigėme? Kuriant programinę įrangą ir bet kurią svetainę, dažna problema yra ta, kad niekas nemato galutinio taško. Viena vertus, galime teigti, kad projekto vadovas turi turėti galutinę projekto viziją. Tačiau ką daryti, jei galutinis produktas atitinka vadovo įvaizdį, bet neatitinka kliento lūkesčių? O jeigu projekto metu pasikeis 3 vadovai?
Parkinsono devyniasdešimt devyniasdešimties dėsnio pasekmė:
Pirmieji 90% kodo užima 90% kūrimo laiko. Likę 10% kodo užima antrus 90% kūrimo laiko.
Iš A. Cooper knygos „Psichiatrijos ligoninė pacientų rankose“.
ToR nėra tik reikalavimų sąrašas, tai yra dokumentas. Jeigu sutartis reglamentuoja organizacinių ir finansinių santykių eigą, tai TOR – kūrimo procesą ir galutinį rezultatą.
Šiuo atveju nesvarbu, ar svetainė sukurta didelė, ar maža. Lūkesčių nesutapimo problema gali iškilti nepriklausomai nuo išleistų pinigų sumos, tik pasekmės gali būti skirtingos.
Apie ką šis straipsnis.
Šis straipsnis yra apie tai, kas gali būti naudinga rašant svetainės technines specifikacijas, taip pat apie tai, ką tikrai būtų pageidautina padaryti. Bet šis straipsnis ne apie tai, kaip rašyti projekto dokumentacija. Galiausiai pagrindinė dizainerio užduotis yra ne parašyti puikų dokumentą, o sukurti svetainę. Geras dokumentas yra tik požiūrio ir pagarbos visiems kūrimo dalyviams atspindys.
Pridėsiu keletą apribojimų.
Kai kalbu apie techninių specifikacijų rašymą, turiu omenyje, žinoma, krioklio kūrimo metodiką. Esant kitoms galimybėms (pavyzdžiui, ekstremalus programavimas) rengiami kiti dokumentai ir dažnai pagal kitus principus. Tai vienas.
Verta atskirti TK mažoms ir didelėms svetainėms. Tai du. Skirtumai tarp mažų ir didelių projektų yra ne išvesties dokumento apimtyje, o jų kūrimo procese. Jei projekto komandoje yra tik 4 žmonės, visi seniai pažįstami, galime manyti, kad formalizmo nėra. Jei kūrime dalyvauja keli „skyriai“, o projekto komandą sudaro daugiau nei 10 (iki begalybės) darbuotojų, tai tik procesas gali valdyti šią minią. Procesas sukelia formalizavimą, o formalizmas palieka pėdsaką dokumentacijos formate.
Tiesą sakant, dokumentų storis labiau priklauso nuo proceso sudėtingumo nei nuo projekto dydžio.
Mes eisime sunkiausiu keliu.
TK atsako į klausimus
TK iš pradžių sukurta keliems plėtros dalyviams:
- Projektų rengėjai (dizainerai ir programuotojai).
- Projekto vadovas.
- Klientas.
- Biurokratai (jie gali nedalyvauti projekte, bet su jais taip pat reikia pasiskaityti).
Žvelgiant į minėtas dalyvių grupes, galima daryti prielaidą, kad TOR pirmiausia turėtų atsakyti į jų klausimus. Idealiu atveju visa priešprojektinė dokumentacija kaskados metodu yra sukurta taip, kad kūrimo procese būtų pašalinti klausimai.
Taigi, į kokius klausimus atsako TK?
Kam skirta svetainė ir kodėl?
Svetainė sukurta Klientui ir jo klientams. Tai yra nusistovėję būsimo projekto vartotojai.
Geriausias pasirinkimas būtų, jei techninėse sąlygose apibūdintumėte visus svetainės vartotojus, tiek vidinius, tiek išorinius. Šis aprašymas gali apimti rinkodaros, demografinius, socialinius duomenis, potencialių vartotojų tikslus ir uždavinius, jų reikalavimus būsimai svetainei.
Kaip bus sprendžiamos kliento ir vartotojų užduotys?
Tiesą sakant, jei neatsakysite į šį klausimą, techninių specifikacijų rašymas gali būti pripažintas popierizmu. Tai esminis ir reikšmingas klausimas. Jai gali būti skirtas atskiras straipsnis, todėl kol kas plačiau nekalbėsime.
Kaip bus kuriamas projektas?
Kaip jau rašiau aukščiau, TOR (o gal atskirame dokumente) kartais aprašo projekto kūrimo procesą. Tai tikrai būtina, jei atsižvelgsime į tai, kad svetainė gali būti vystoma pagal kūrimo metodiką, kuri skiriasi nuo įmonėje priimtos plėtros metodikos, kuri, kaip taisyklė, nėra aprašyta jokiame dokumente. Galite kankinti save svajonėmis apie ISO standartizaciją tiek laiko, kiek norite, bet ką parodyti kruopščiam klientui?
Pagal GOST yra numatytas atskiras skyrius „Sistemos kūrimo etapai“. Šiame skyriuje negalite per daug išsamiai aprašyti proceso ir įdiegti gaires.
Kokia bus produkcija?
TK pradeda plėtrą ir ją užbaigia.
Idealiu atveju turėtumėte kartu su klientu pereiti visus TOR punktus, patikrinti gautą sistemą ir po savaitės pasakyti: „Uh. Atrodo, kad viskas padaryta“.
"TOR yra atlikto darbo patikrinimo priemonė." – tokia frazė parašyta daugelio mano TK įžangoje.
Ko reikia tolimesniam projekto paleidimui?
Tai klausimas, į kurį klientas turėtų gauti gerą atsakymą. Tai jau yra konsultavimas, tačiau kai kuriais atvejais tai turi būti atlikta projektavimo procese. Būtina planuoti darbų skaičių, reikalingą programinę ir techninę įrangą ir kt.
Iš ko susideda TK?
Aš išėjau visa valanda sprendimų priėmimas: apibūdinkite TK sudėtį konkrečios aiškios struktūros forma arba tiesiog pakalbėkite apie tai, kas ten turėtų būti. Žvelgdamas į visus savo TOR, padariau išvadą, kad šio dokumento struktūra taip dažnai keitėsi priklausomai nuo daugybės veiksnių, kurie aiškiai nurodant struktūrą būtų tarsi blogas patarimas renkantis kostiumą. Įsivaizduokite, kad jums liepta ką nors apsirengti vakarui, net nežinant, kur eini.
Bendra informacija
Pirmoje ToR dalyje yra įvadas ir Bendra informacija apie dokumentą ir projektą kaip visumą. Įvadas turi būti parašytas vieną kartą ir visam gyvenimui. Paprastai ten rašomos tokios abstrakčios frazės, kad kiekviename naujame projekte reikia pataisyti tik porą žodžių.
Bendra informacija apima:
- Informacija apie užsakovą ir atlikėją.
Kiekvienoje pusėje būtinai nurodykite atsakingus asmenis. Nurodomi dokumentai, kurių pagrindu vykdoma plėtra. Paprastai toks dokumentas yra sutartis. Dabartinio dokumento būsena ir privatumas. - Projekto užduotis.
Nurodoma: kam bus naudojamas gautas produktas. - Kūrybos tikslai ir uždaviniai, kuriuos turi išspręsti išteklius.
Viena vertus, tai gana trumpas skyrius, bet pagal įmantrumo svarbą užima pirmą vietą. Jei tikslai ir uždaviniai nėra aiškūs ir neišmatuojami, gali būti gana sunku jų laikytis. - Projekto auditorijos aprašymas.
Svarbi informacija kuriant geras ir teisingas svetaines. Akivaizdu, kad informaciją apie auditoriją reikia ne tik teisingai rinkti, bet dar svarbiau mokėti šia informacija pasinaudoti.
Auditorijos aprašyme turi būti ne tik rinkodaros specialistų labai mėgstama informacija (demografija, poreikiai, segmentavimas ir kt.), bet ir informacija, kuri bus naudinga dizaineriams ir planuotojams: kokias užduotis sprendžia vartotojas, kokie jo tikslai. darbas su svetaine, kas traukia. Alanas Cooperis rekomenduoja svetainės auditoriją apibūdinti ne kaip beveidę masę, o išskirti personažus – apibūdinti konkrečių žmonių kolektyvinį įvaizdį. - Terminai ir apibrėžimai.
Dideliame dokumente galėsite naudoti daugybę terminų ir slengo posakių, kuriuos retai supranta rinkodaros specialistai ar vyresnieji vadovai. Jie gali skaityti šį dokumentą, todėl geriausia pateikti jiems skirtų apibrėžimų sąrašą. Neglosiju savęs viltimi, kad šis sąrašas bent kartą gyvenime buvo perskaitytas, bet visada galiu juo remtis.
Įvadinėje bendrojoje dokumento dalyje pateikiama informacija apie tai, nuo ko pradėjome projektuodami. Žinoma, apklausiant kliento specialistus informacijos susikaupia eilės tvarka daugiau, tačiau niekam neįdomu ją skaityti.
Ši informacija renkama kaip projekto dalis.
Projekto apimtis
Jei nutolsite nuo savo namo ir apsisukę pažiūrėsite į jį, tada iš tolo negalėsite atskirti konstrukcijos detalių. Langus gali suskaičiuoti, bet nesuvoki iš kokios medžiagos jie pagaminti, gali grožėtis architektūra (žinoma, ne kiekvienu namu „susigrosi“), bet apie jo principus galima tik spėlioti. statybos, nematysite butų vidų ar nubraižyto žodžio ant įėjimo durų.
Projekto apimtis yra maždaug tokia pati. Perskaitę šį skyrių kiekvienas turėtų įsivaizduoti, kas bus gauta kūrimo procese, tačiau visiškai nesigilinant į smulkmenas. Rašote, kad svetainėje veiks „vartotojo registracija“, bet nerašote kaip tiksliai veiks, kokius laukus vartotojas turės užpildyti.
Karkasinis dizaino lygis bet kuriuo atveju vyksta per bet kurį projektą, todėl nebus nereikalinga jo užsirašyti. Be to, didieji bosai tiek iš kūrėjų, tiek iš kliento pusės nemėgsta ilgai skaityti, bet mėgsta žinoti viską, kas vyksta. Šis skyrius turėtų būti parašytas ir jiems.
Projekto apimtys yra parašytos scenarijų forma, kaip vartotojai sąveikauja su svetaine, ir apibūdina bendrą funkcionalumą bei sąveiką su sąsaja.
Informacijos architektūra ir sąsaja
Skyrius, skirtas svetainių informacinei architektūrai (IA), nėra standartizuotas jokiu žinomu standartu (autorius dar nėra susipažinęs su tokiais standartais). Bet kiekvienas, kuris sukūrė svetaines, supranta, kad IA yra beveik pagrindinis dalykas, kurį reikia žinoti kuriant svetainę. PV nustatys, kaip svetainė atrodys ir veiks su vartotojais.
Norėdami apibūdinti IA, turėsite aprašyti iš viršaus į apačią:
- Svetainės struktūra. Tai vadinamieji aukšto lygio prototipai.
- Puslapių šablonai. Žemo lygio prototipai, tiesiogiai apibūdinantys svetainės sąsają.
- Turinio aprašymas. Lentelinis kiekvieno svetainės puslapio turinio aprašymas.
Svetainės struktūra
Svetainės žemėlapis sudarytas grafiškai vienu iš gerai žinomų užrašų: Visio arba Garrett. Patariu nubraižyti svetainės schemą, nes tokiu atveju gauta struktūra yra vizualiausia ir patogiausia tolesniam naudojimui. Viena vertus, gali atrodyti, kad svetainės schemą sudaryti sąrašo pavidalu būtų daug lengviau, bet kai pats pagalvoji apie skirtingų svetainės sričių sąsajas, nori nenori pradedi piešti kvadratus ant popieriaus. .
Buvo parašyti ištisi straipsniai apie tai, kaip galite nubrėžti svetainės struktūrą naudodami žymėjimus naudojant Visio, todėl mes apie tai nesigilinsime. Tačiau straipsniai parašyti anglų kalba, bet jūs galite lengvai juos naudoti.
Nepamirškite kiekvienam atskiram svetainės schemos puslapiui priskirti numerį. To reikės turinio aprašymo etape.
Naudingi patarimai kuriant svetainės schemą:
- Negailėkite vietos. Pabandykite išdėstyti blokus taip, kad jie būtų atskirti vienas nuo kito. Tai padės geriau skaityti žemėlapį.
- Nesusitraukite. Iš principo galima skaityti 4 dydžiu atspausdintą tekstą, bet tai jau yra neapykantos priežastis.
- Sulygiuokite puslapių „kvadratus“ vienas kito atžvilgiu, išlyginkite juos linijomis. Tai pagerins puslapio įdėjimo lygių suvokimą.
- Neperžengk linijų. Stenkitės vengti daugybės ryšių linijų sankryžų. Jei jie susikerta, jie turi „peršokti“ vienas per kitą. Tie, kurie universitete užsiėmė funkcinių diagramų braižymu, mane supras.
- Pasirašykite kortelę. Pasirašykite pačią kortelę, taip pat atskirus blokus. Dėl to vėliau bus mažiau painiavos.
- Dažnai išsaugokite failą. Triukšminga, bet jums tiesiog reikia tai atsiminti. Nebūtina dar kartą priminti „Visio“ programos kūrėjų artimųjų, tiesą sakant, jie dėl nieko nekalti.
Svetainės schemą dažniausiai dedu į skyrių Programos. Paprastai jis yra toks didelis, kad tampa nerealu jį įdėti į TK vidurį.
Puslapių šablonai
Svetainės schemos lygiu kiekvienas puslapis yra tik „kvadratas“ ant popieriaus lapo. Dizaineriui, maketuotojui ir programuotojui to nepakanka norint sukurti svetainę. Taip pat turite žinoti informacijos blokų ir funkcijų buvimą ir vietą svetainės puslapiuose. Todėl pereiname prie svetainių šablonų. Idealiu atveju kiekvienas langelis turėtų būti detalizuotas iki kiekvieno atskiro puslapio išdėstymo. Tai svetainės prototipų kūrimas. Prototipų kūrimo naudojimas priklauso nuo kūrimo įmonėje priimtos darbo schemos, tačiau verta pripažinti, kad tai klientui tampa itin brangu.
Kad būtų paprasčiau, yra keletas svetainės sąsajos šablonų, aprašytų po svetainės žemėlapiu.
Šablonų aprašymas susideda iš 3 dalių:
- Šablonų sąrašas. Nurodomi pagrindiniai puslapių tipai ir aprašomas jų naudojimas.
- Tipiškas šablonas. Pagrindiniai blokai. Siekiant sumažinti informacijos pasikartojimą, aprašomi pagrindiniai puslapių blokai.
- Kiekvieno šablono aprašymas pagal sąrašą. Šablonai braižomi bet kuriame grafikos pakete (Adobe Illustrator, Adobe InDesign, MS Visio ir kt.), o vėliau papildomi trumpu aprašymu.
Rezervacija: svetainės sąsajos šablonų nereikėtų painioti su šablonais programinės įrangos sistemoje, kurioje veiks svetainė. Sąsajos šablonai apibūdina standartinių puslapių skaičių, kurio pakanka svetainės dizainui.
Sklaidos iš TOR pavyzdys su sąsajos šablono (wireframe) aprašymu.Turinio aprašymas
Ilgiausia ir nuobodžiausia darbo dalis. Turinio aprašyme turi būti pateiktas visų svetainės puslapių sąrašas, tiksliai nurodant kiekviename puslapyje esantį tekstą, paveikslėlius ir pan. Taip pat nurodoma, kuris šablonas naudojamas šiam puslapiui (žr. aukščiau). Tam rekomenduoju naudoti skaičiuoklę.
Rašant TOR ne visada įmanoma tiksliai žinoti, koks turinys bus svetainėje: tikslus informacijos puslapių skaičius, grafinės informacijos išdėstymas, todėl nemanykite, kad šį skyrių pateikiamas tiksliausias aprašymas. Dažnai taip nėra. Bet jei šiame etape apibūdinsite reikiamą turinį, remdamasis juo projekto vadovas galės sudaryti turinio pristatymo planą ir įvertinti, kiek šios informacijos bus įtraukta į svetainę. Klientas visada prieš akis turės sąrašą, ką jam reikia paruošti ir redaguoti.
Geras turinio aprašymas yra raktas į planuojamą darbą svetainės paleidimo ir informacijos įvedimo etape.
Funkcinis
Svetainės funkcionalumo aprašymas techninėse sąlygose yra vienas iš pagrindinių skyrių. Tai ypač pasakytina apie svetaines, kuriose dirba daug programinės įrangos: elektroninė prekyba, internetinės paslaugos ir kt.
Gerą funkcinio aprašymo pavyzdį pateikia GOST. Apibūdinant svetainėje sukurtų programų funkcionalumą, rekomenduoju laikytis standarto. Reikėtų aprašyti: bendra sistema, bendras posistemių ir modulių funkcionalumas, posistemių ir modulių tarpusavio ryšys ir, galiausiai, visų modulių, turinčių daugiau ar mažiau funkcijų, sąrašas. Išsamus aprašymas jų darbas. Kiekvienam moduliui turi būti aprašyti programoje sukurti ar naudojami objektai.
Taip pat galite aprašyti duomenų bazės struktūrą, preliminarius darbo algoritmus, tačiau pati techninė užduotis to nereikalauja. Remiantis GOST, tokios detalės turėtų būti aprašytos kituose dokumentuose: projektuose ir techniniuose projektuose.
Kartais kuriant dideles svetaines tenka ilgai sėdėti, kad apibūdintum visas išorinės ir vidinės svetainės dalių funkcionalumą. Kai kurie kūrėjai prieštarauja tokioms smulkmenoms. Jie mano, kad funkcionalumas turi būti aprašytas paviršutiniškai, kad „klientas suprastų“. Visiška nesąmonė! Iš patirties galiu pasakyti, kad nėra jokių nereikalingų detalių. Iškilus problemoms projekte, abiejų pusių projektų vadovai tampa retais laiškų valgytojais! Jie korektuoja TK aukštyn ir žemyn, bandydami įrodyti savo bylą. Todėl, jei TOR funkcionalumas yra išdėstytas bendrai, klientas vis tiek privers jį daryti tai, ko jam reikia.
Reikalavimai
Atskiras skyrius turėtų būti skirtas projekto arba aplinkosaugos projekto reikalavimams. Reikalavimai, kuriuos galima aprašyti svetainės techninėse sąlygose:
- Techniniai reikalavimai sistemai;
- Reikalavimai personalui;
- Patikimumo reikalavimai;
- Ergonomikos ir techninės estetikos reikalavimai;
- Informacijos apsaugos nuo neteisėtos prieigos reikalavimai;
- Informacijos saugos reikalavimai nelaimingų atsitikimų atveju;
- Reikalavimai užstato rūšims;
- Programinės įrangos reikalavimai;
- Reikalavimai informacinei pagalbai;
- Reikalavimai techninėms priemonėms;
Taip pat gali būti keletas specifinių reikalavimų.
Visi reikalavimai turi būti aiškiai suformuluoti ir stenkitės nieko nepamiršti iš savo projekto plėtros aspektų.
Žinoma, mažuose projektuose nebūtina surašyti visų aukščiau išvardintų reikalavimų. Taigi, pavyzdžiui, dažnai svetainėje apskritai nėra darbuotojų, todėl tokios skiltys praleidžiamos.
Kita
Projekto valdymo procese galite pastebėti, kad pasitaiko situacijų, kurios peržengia techninės užduoties ribas. Galbūt ką nors praleidote arba susidarė ekstremali situacija, kurios anksčiau negalėjote numatyti. Visa tai padės toliau tobulinti dokumentą, įnešti į jį naujos informacijos, kuri padės jį panaudoti bendraujant su klientu ir išspręsti problemas.
Kas toliau?
TOR buvo sudarytas, pasirašytas ir pradėtas naudoti. Kas toliau? Ar darbas su juo baigiasi šiame etape? Nr.
Projektas ne visada vyksta iš anksto suplanuotu keliu. Stengiamės kažką tobulinti, keisti, dažnai keičiasi klientų reikalavimai. Techninė užduotis yra dokumentas, o ne planšetinis kompiuteris. Keičiantis reikalavimams projektui, turėtų keistis ir techninė užduotis. Paprastai tai daroma su papildomais dokumentais su pakeitimų sąrašu. Natūralu, kad jie sudaromi tik tada, kai tai tikrai būtina, praktiškai tai retai.
Taip pat turėtumėte būti pasirengę, kad giliai išnagrinėdami technines specifikacijas, visi plėtros dalyviai, dirbdami su projektu, ras klaidų. Klaidų skaičius dideliame dokumente yra tiesiogiai proporcingas jo ilgiui ir atvirkščiai proporcingas jo rašymo laikui. Nes laiko nuolat trūksta, reikia tikėtis, kad TOR atsiras klaidų.
Sausoje medžiagoje
Šį straipsnį parašiau daugiau nei prieš metus. Praėjo gana daug laiko ir per tą laiką neparašiau nei vieno didelio TK. Bet dar kartą perskaičiusi pateiktą informaciją, sutikau su viskuo, kas čia parašyta. Taigi gerame svetainės TK turėtų būti:
- Bendra informacija apie dokumentą ir jo autorius;
- Svetainės tikslai ir uždaviniai;
- Svetainės vartotojų aprašymas, jų tikslai ir uždaviniai;
- Projekto apimtis;
- Svetainės informacinė architektūra (IA): svetainės schema, šablonai, sąsajos aprašymas;
- Svetainės turinio aprašymas;
- Svetainės funkcionalumo aprašymas;
- Proceso ir etapų aprašymas, jei reikia;
- Visų rūšių reikalavimų sąrašas kuriant svetainę ir tikrinant gautus darbus.
Tikiuosi, kad informacija bus naudinga daugeliui skaitytojų.
Naudingos nuorodos
- GOST 34.602-89.
Jurijus Šiljajevas
Jurijus Šiljajevas, Minskas. interneto svetainės dizaineris, konsultantas. „Artics Internet Solutions“ Minsko biuro direktorius.