Ļaujiet man sākt ar joku par armiju. Komandieris dod pavēli Stroibatas karavīru rotai: "Mēs rokam no žoga līdz saulrietam!" Līdzīga situācija var rasties izstrādātājiem. Ikviens komandas loceklis varētu jautāt: "Kad ir beigas?" Patiešām, darbs šajā jomā var turpināties ilgu laiku. Programmatūras izstrādē un mājas lapas dizaina izstrādē ir jāzina līmenis, kas apmierina klientu.
Ir vispārpieņemts, ka tikai projekta vadītājam ir jāzina visi projekta dati. No otras puses, var būt konfliktsituācija ja atšķirsies projekta vadītāja un pasūtītāja viedoklis par gala projektu. Un vēl viena situācija, ja projektu vadītājs, kuram ir izpratne par attīstības projekta beigu posmu, nav apmierināts ar algu un rīt pāriet uz citu darbu?
Tehniskais uzdevums(TOR) ir oficiāls dokuments, kas regulē visus vietnes vai programmatūras produkta dizaina izstrādes posmus. Ir nepareizi uzskatīt, ka tas ir garš klienta nosacījumu uzskaitījums. No TK ir paredzēts, ka tas būs skaidrs un kodolīgs par radīšanas detaļām un gala produktam. To nevajadzētu jaukt ar līgumu, kurā ir noteiktas pušu atbildības detaļas, savstarpējie norēķini un citi organizatoriski jautājumi.
Tehniskais uzdevums mājas lapas dizaina izstrādei ir jāizstrādā neatkarīgi no projekta apjoma. Problēma slēpjas nevis apjomā, bet gan dažādos uzskatos par viena un tā paša procesa dažādu aspektu gala rezultātu starp darbuzņēmēju un pasūtītāju. Nespēja vienoties par visām detaļām var beigties ar liekām pūlēm, laiku un naudu. Bojāta reputācija un labas attiecības.
Tāpēc mēs centīsimies atklāt visas tehnisko specifikāciju rakstīšanas gudrības mājas lapas dizaina izstrādei. Dizaineram ir svarīgi nerakstīt kaudzi ar biezām papīru kaudzēm, bet svarīgs ir rezultāts - profesionāli izveidota mājaslapa. Labi uzrakstīts darba uzdevums vietnes attīstībai atspoguļos uzmanīgu attieksmi pret visiem projekta dalībniekiem un parādīs attīstības virzienu web izstrāde.
Ir arī vērts atcerēties, ka TK ir vairāki ierobežojumi. Pirmkārt, mēs runāsim par tehnisko specifikāciju apkopošanu, izmantojot kaskādes metodi, bet citos gadījumos tiek izmantotas citas metodes. Otrkārt, ir jānošķir TOR projektēšana lieliem portāliem un TOR mazbudžeta vietnēm. Atšķirība ir dokumentu izmērā. Jo lielāks apjoms, jo lielāka un garlaicīgāka būs izstrāde, liela apjoma TOR vietņu dizaina izstrādei būs daudz formalitāšu. Taču TOR lielums vairāk ir atkarīgs no projekta izstrādes sarežģītības, nevis no tā lieluma.
Uz kādiem jautājumiem pareizi jāatbild labi uzrakstītam tehniskajam uzdevumam? Vietnes dizaina izstrādes darba uzdevumi ir īpaši svarīgi tādiem projekta dalībniekiem kā projekta vadītājs, izstrādātāji un klienti. Vietnes galvenie lietotāji būs topošās vietnes klienti un apmeklētāji. Pamatojoties uz to, darba uzdevumā ir detalizēti jānorāda tie, kas izmantos vietni. Tas var būt uzņēmuma darbinieki un citi apmeklētāji. Šādas detaļas ir svarīgas, jo tās satur svarīgu informāciju, kas var veidot prasības vietnes dizaina izstrādei.
Kādi ir mājas lapas dizaina izstrādes posmi? Mēs to jau minējām iepriekš. Darba uzdevumā viss darba process pie projekta ir parakstīts ļoti detalizēti. Šāds solis ir ārkārtīgi nepieciešams pasākums. Tā kā nav vienotas izstrādes metodikas, TOR ir obligāti jāizraksta visi galvenie izstrādes punkti un sīki jāapraksta katrs no tiem. Ar ko klients beigsies? Mājas lapas dizaina izstrāde sākas ar tehnisku uzdevumu un beidzas ar to. Kopā ar klientu jāpārrunā katrs tehniskā uzdevuma punkts, viss jāpārbauda, jānoskaidro. ToR ir paveiktā darba pierādījums.
Kas ir nepieciešams, lai sāktu izstrādāt mājas lapas dizainu? Dažreiz šis jautājums tiek izņemts atsevišķā dokumentā, piemēram, līgumā. Bet TK sagatavošanai arī tam ir nozīme. Atbilde uz šo jautājumu ir atkarīga no tā, cik speciālistu var piesaistīt, kādas programmas izmantot utt.
Pirmajā daļā un darba uzdevuma ievadā ir aprakstītas formalitātes un izplatītas frāzes. Šī dokumenta daļa mainās tikai ik pa laikam un tikai atsevišķās vietās. Tāpat kā lielākajā daļā dokumentu, vispārīgajā daļā viņi raksta informāciju par pasūtītāju un darbuzņēmēju, viņu rekvizītus, juridiskos datus un dokumenta statusu. Ja šajā daļā kaut ko palaidat garām, tas ir labi, jo šāda plāna pamatinformācija būs līgumā.
1. Telpu remonta darbu (turpmāk – darbi) vieta, nosacījumi un termiņi:
1.1. Darba vieta:
Nedzīvojamās telpas Nr.50, kas atrodas ēkas 5.stāvā pēc adreses:
1.2. Darba noteikumi:
Darbi jāveic saskaņā ar šo telpu remonta darbu veikšanas nolikumu (turpmāk – Nolikums). Darba gaitu kontrolē Pasūtītājs. Izslēgt inženiertehniskās sistēmas, tīklus vai to atsevišķus posmus veic tikai iepriekš vienojoties ar Pasūtītāju un Īpašuma apsaimniekošanas nodaļu un zemes resursi Tveras pilsētas administrācija.
Darbi tiek veikti saskaņā ar Vietējo tāmi telpu remonta darbu veikšanai (Līguma Nr. datētais pielikums (turpmāk tekstā Līgums)).
1.3. Apgrozījuma laiks:
Būvuzņēmējs apņemas uzsākt darbu veikšanu pēc šī Līguma parakstīšanas starp pusēm ne vēlāk kā nākamajā dienā pēc telpu remonta lokālās tāmes saskaņošanas ar Tveras pilsētas administrācijas Īpašumu apsaimniekošanas un zemes resursu departamentu. , pabeigt visus darbus un nodot to rezultātu Pasūtītājam ne vēlāk kā 30 (trīsdesmit) kalendāro dienu laikā no darbu uzsākšanas dienas.
2. Darbu vispārīgās īpašības:
Nedzīvojamo telpu Nr.50, kas atrodas ēkas 5.stāvā pēc adreses: (turpmāk – telpas), remonta darbu veikšana.
3. Prasības darba kvalitātei un drošībai:
3.1. Kvalitātes prasības, tehniskās specifikācijas darbu un citus rādītājus, kas saistīti ar veikto darbu atbilstības noteikšanu Pasūtītāja vajadzībām, nosaka spēkā esošie Būvnoteikumi un noteikumi (turpmāk tekstā SNiP), būvniecības noteikumu kopumi (turpmāk tekstā SP), departamentu būvnormatīvi(turpmāk VSN), sanitārajiem noteikumiem un normām (turpmāk SanPiN), valsts standarti(turpmāk tekstā GOST), specifikācijas(turpmāk TU), normas uguns drošība(turpmāk – NPB), noteikumiem uguns drošība(turpmāk – PPB), elektroietaišu uzstādīšanas noteikumus (turpmāk – PUE) un citus normatīvos dokumentus.
Darbu veikšanas laikā obligāti jāievēro teritorijā spēkā esošās tehnoloģijas un darba metodes, vides, sanitāro un higiēnas, ugunsdrošības un citu standartu prasības. Krievijas Federācija:
Būvniecības normas un noteikumi SNiP "Darba drošība būvniecībā";
Federālais likums -FZ "Tehniskie noteikumi par ēku un būvju drošību";
Federālais likums -FZ "Par ugunsdrošību";
Būvniecības normas un noteikumi SNiP "Ēku un būvju ugunsdrošība";
Ugunsdrošības standarti NPB 244-97 “Būvmateriāli. Dekoratīvie apdares un apdares materiāli. Grīdas seguma materiāli. jumta segums, hidroizolācija un siltumizolācijas materiāli. Ugunsdrošības rādītāji.
Federālais likums -FZ "Tehniskie noteikumi par ugunsdrošības prasībām".
3.2. Nejaušas nāves vai nejaušu bojājumu risks nedzīvojamās telpas veicot darbu līdz Pasūtītāja pieņemšanai, to sedz Izpildītājs.
4. Prasības darba organizācijai:
4.1. Darbs jāveic darba dienās: pirmdien, otrdien, trešdien, ceturtdien no 09.00 līdz 18.00, piektdien no 09.00 līdz 16.45. Darba organizēšana sestdienā tiek veikta pēc iepriekšējas vienošanās ar Pasūtītāju no 09.00 līdz 16.00.
4.2. Izpildītājam ir pienākums nodrošināt darbu veikšanu no saviem materiāliem, saviem spēkiem un līdzekļiem. Materiālu sastāvs ir norādīts Vietējā tāmē telpu remonta darbu veikšanai (Līguma pielikums Nr.1).
4.3. Tikai kvalificēti speciālisti ar atbilstošu kategoriju saskaņā ar noteikto regulējošā juridiskā darbojas būvniecības jomā. Nav atļauts piesaistīt nerezidentus un ārvalstu speciālistus bez atbilstošas reģistrācijas un atļaujas piesaistīt ārvalstu darbaspēku, ja šādus pienākumus nosaka spēkā esošie Krievijas Federācijas tiesību akti.
4.4. Pareiza materiālu, aprīkojuma aizsardzība, celtniecības tehnika un cita Izpildītāja manta uz darbu izpildes laiku jānodrošina Izpildītājam.
5. Prasības materiāliem un iekārtām
5.1. Darbu veikšanai izmantoto materiālu un iekārtu kvalitātei un drošībai jāatbilst obligātajām tehnisko noteikumu prasībām, valsts elektriskās, mehāniskās un ugunsdrošības standartiem, akustikai, rūpniecisko radiotraucējumu līmenim, izturībai pret elektromagnētiskajiem traucējumiem un higiēnas prasības, sanitārajiem standartiem un noteikumiem un jāapstiprina ar atbilstības deklarācijām, atbilstības sertifikātiem un sanitārajiem un epidemioloģiskiem secinājumiem.
5.2. Visiem materiāliem jābūt atbilstošiem sertifikātiem, sanitārajiem un epidemioloģiskiem secinājumiem, tehniskajām pasēm un citiem to kvalitāti apliecinošiem dokumentiem. Šo sertifikātu kopijas u.c. ir jāiesniedz Pasūtītājam ne vēlāk kā divas kalendārās dienas pirms darbu uzsākšanas, kas tiek veikti, izmantojot šos materiālus un iekārtas.
6. Prasības apdares darbiem
6.1. Telpu sagatavošana turēšanai remontdarbi(neizmantoto gaisa vadu demontāža, metāla konstrukcijas , santehnikas caurules, noblīvējot neizmantotos izplūdes kanālus sienās).
6.2. sienu apšuvums drywall, ar tehnoloģisko nišu ierīci zem ģeogrāfiskās kartes, video kameras, audio pastiprināšanas tehnika. Cauruļu statīvu ierīce bezšuvju video paneļa novietošanai un nostiprināšanai.
Uzstādītā drywall pirms līmēšanas ir jānoslīpē. Gruntēšana jāveic pirms slīpēšanas un pēc slīpēšanas. Izmantojiet dziļas iespiešanās grunti. Līmēšana ar neaustām tapetēm, kuras krāsot ar ūdens bāzes krāsu, tapešu faktūra un krāsas krāsa jāsaskaņo ar Pasūtītāju.
6.3. Piekaramo griestu uzstādīšana.
Telpu griestiem izmantot - piekaramie griesti "Armstrong" un griestu flīzes "Baikal".
6.4. Grīdas remonts.
Demontēt no grīdas veco linoleju un cokolu, ierīkot tehnoloģiskos kanālus un lūkas uzstādīto iekārtu pieslēgšanai. Izlīdziniet ar cementa klonu. Lieciet lamināts klase ne zemāka par 32, krāsa "Dižskābardis", krāsa jāsaskaņo ar Pasūtītāju. Cokolam jābūt plastmasas, krāsa "dižskābardis" ar kabeļu kanāliem. Grīdas segumam nevajadzētu būt ar defektiem, grīdām jābūt gludām, bez redzamām spraugām, nelīdzenumiem.
6.5. Starptelpu starpsienu ierīce.
Starpsienām jābūt no ģipškartona, ar skaņas izolāciju un bīdāmiem stikla pakešu logiem vadības telpā, gruntēšana jāveic pirms špaktelēšanas un pēc slīpēšanas ar dziļi iespiešanās grunti. Līmēšana ar neaustu tapešu krāsošanai ar ūdens bāzes krāsu, tapešu faktūra un krāsas krāsa jāsaskaņo ar Pasūtītāju. Uzstādiet ieejas durvis un durvis blakus telpās pēc vienošanās ar Pasūtītāju.
6.6. Demontēt vecās logu vērtnes, koka palodžu dēļus, uzstādīt logu blokus no divkameru PVC pakešu logiem, plastmasas palodžu dēļiem.
Pakešu logu krāsa ir balta. Logiem jābūt atveramām daļām vismaz 1/3 no laukuma. Logu ailēm jābūt aprīkotām ar žalūzijām un rullo žalūzijām, krāsa tiek saskaņota ar Pasūtītāju. Palodzes - plastmasas, vismaz 50 cm dziļas.
6.7. Centrālapkures bateriju kosmētiskais remonts.
Temperatūras regulatoru uzstādīšana. Ģipškartona ekrānu uzstādīšana, kas aprīkoti ar ventilācija režģi. Gruntēšana jāveic pirms tam špaktelēšana un pēc slīpēšanas ar dziļas iespiešanās grunti. Līmēšana ar neaustu tapešu krāsošanai ar ūdens bāzes krāsu, tapešu faktūra un krāsas krāsa jāsaskaņo ar Pasūtītāju.
7. Prasības elektriskajiem darbiem
7.1. Veikt elektriskos darbus saskaņā ar shēmu elektroinstalācija(Nolikuma 9. punkts).
7.2. Ražošanā elektriskie darbi vadieties pēc SNiP 3.05.06-85 "Elektriskās ierīces" prasībām. Uzstādiet kontaktligzdas uzstādītajos kabeļu kanālos vismaz 0,5 m attālumā no grīdas līmeņa, ārējais stiprinājums.
7.3. Uzstādiet elektrisko sadales skapi (ES) ar uzstādīšanu 9 automātiskie slēdži(automātiska degvielas uzpildes staciju tīkla aizsardzība ).
7.4. Lai apgaismotu un apgaismotu nišas ar kartēm, izmantojiet enerģiju taupošas videi draudzīgas lampas.
7.5. Visus elektrības kabeļus izvelciet atklāti gar sienām kabeļu kanālos, virs piekārtajiem griestiem nedegošā, gofrētā caurulē, elektrības kabeļus ielieciet grīdā metāla caurulēs vai metāla profilos. Nodrošiniet tehnoloģiskās lūkas kabeļu ieguldīšanai.
7.6. Pievienojiet patērētāju barošanas kabeļus uzstādītajam sadales skapim, kas aprīkots ar automātiskiem slēdžiem, novietojiet strāvas kabeli un pievienojiet to sadales skapis centrālais birojs (telpas numurs 41) caur ķēdes pārtraucēju.
7.7. pakete kabeļu maršruti jānosaka darba pabeigšanas brīdī.
7.8. Uzstādīšanas laikā izmantojiet kabeli ar PVC izolāciju vara vadītājiem nedegošā PVC apvalkā, kas ražots saskaņā ar GOST 22483 “Vadītspējīgi vara vadītāji kabeļiem, vadiem un auklām. Galvenie parametri. Tehniskās prasības". Kontaktligzdām jāatbilst Eiropas standartam. Visiem materiāliem un iekārtām jābūt sertifikātiem, tehniskajām pasēm un citiem to kvalitāti apliecinošiem dokumentiem, jāatbilst PUE prasībām, SNiP un PPB. Visiem materiāliem jābūt jauniem un ražotiem ne vēlāk kā 2012. gada 1. ceturksnī.
8. Prasības darba kvalitātes nodrošināšanas periodam
Veiktā darba kvalitātes nodrošināšanas periodam, ņemot vērā izmantotos materiālus, jābūt 36 mēnešiem 100% apmērā no veiktā darba pieņemšanas akta (veidlapa KS-2) parakstīšanas dienas. Laikā garantijas periods Izpildītājam ir pienākums par saviem līdzekļiem novērst jebkādas nepilnības Līguma ietvaros veiktā darba rezultātā ne ilgāk kā 15 (piecpadsmit) kalendāro dienu laikā no Pasūtītāja pieprasījuma dienas.
9. Elektroinstalācijas shēma.
Es varu atcerēties pārsteidzoši maz materiālu par vietņu un programmu dizainu krievu valodā, ko rakstījuši krievvalodīgie autori. To veicina pārsvarā uz eksportu orientētā attīstība (ofšori) un masveida pieredzes trūkums informācijas produktu veidošanā mūsu valstī.
Es ceru, ka šis raksts būs noderīgs tiem izstrādātājiem un IT vadītājiem, kuri ir saskārušies ar augstas kvalitātes dokumentu apkopošanas problēmu vietnes izstrādei. Dokumenti, kas papildus bojātam papīram vismaz kaut kā noderētu.
ievada
Kāpēc izstrādāt vietnes tehnisko uzdevumu (TOR)?
Neatkarīgi no tā, kādu izstrādes metodiku jūs izmantojat un kāda izmēra ir jūsu vietne, jūs jebkurā gadījumā saskarsities ar jautājumu: "Un, kad mēs pabeigsim darbu, kā mēs sapratīsim, ka mēs to patiešām esam pabeiguši?" Gan programmatūras, gan jebkuras vietnes izstrādē izplatīta problēma ir tā, ka neviens neredz beigu punktu. No vienas puses, mēs varam teikt, ka projekta vadītājam ir jābūt galīgajam projekta redzējumam. Bet ko darīt, ja gala produkts atbilst vadītāja tēlam, bet neatbilst klienta cerībām? Un ja projekta laikā mainās 3 vadītāji?
Parkinsona deviņdesmit deviņdesmit likuma sekas:
Pirmie 90% koda aizņem 90% izstrādes laika. Atlikušie 10% koda aizņem otros 90% izstrādes laika.
No A. Kūpera grāmatas "Psihiatriskā slimnīca pacientu rokās".
ToR nav tikai prasību saraksts, tas ir dokuments. Ja līgums regulē organizatorisko un finansiālo attiecību procesu, tad TOR regulē izstrādes procesu un gala rezultātu.
Šajā gadījumā nav nozīmes tam, vai vietne ir izveidota liela vai maza. Cerību nesakritības problēma var rasties neatkarīgi no iztērētās naudas summas, tikai sekas var būt dažādas.
Par ko ir šis raksts.
Šis raksts ir par to, kas var noderēt vietnes tehnisko specifikāciju rakstīšanas procesā, kā arī par to, ko noteikti būtu vēlams darīt. Bet šis raksts nav par to, kā rakstīt projekta dokumentācija. Galu galā dizainera galvenais uzdevums ir nevis uzrakstīt foršu dokumentu, bet gan izveidot vietni. Labs dokuments ir tikai pieejas un cieņas atspoguļojums visiem izstrādes dalībniekiem.
Es pievienošu dažus ierobežojumus.
Vienmēr, kad es runāju par tehnisko specifikāciju rakstīšanu, es domāju, protams, ūdenskrituma izstrādes metodiku. Citu iespēju gadījumā (piemēram, ekstrēma programmēšana) tiek sastādīti citi dokumenti un bieži vien pēc citiem principiem. Šis ir viens.
Ir vērts atdalīt TK mazām un lielām vietnēm. Šie ir divi. Atšķirības starp mazajiem un lielajiem projektiem ir nevis izvaddokumenta apjomā, bet gan to izstrādes procesā. Ja projekta komandā ir tikai 4 cilvēki, visi viens otru pazīst jau ilgu laiku, tad varam pieņemt, ka formālisma nav. Ja izstrādē ir iesaistītas vairākas “nodaļas” un projekta komandā ir vairāk nekā 10 (līdz bezgalībai) darbinieki, tad šo baru var vadīt tikai process. Process rada formalizāciju, un formālisms atstāj savas pēdas dokumentācijas formātā.
Faktiski dokumentu biezums ir vairāk atkarīgs no procesa sarežģītības, nevis no projekta apjoma.
Mēs iesim visgrūtāko ceļu.
TK atbild uz jautājumiem
TK sākotnēji ir izveidots vairākiem attīstības dalībniekiem:
- Projektu izstrādātāji (dizaineri un programmētāji).
- Projektu menedžeris.
- Klients.
- Birokrāti (tie var nepiedalīties projektā, bet ar viņiem arī jārēķinās).
Atskatoties uz iepriekš minētajām dalībnieku grupām, var pieņemt, ka TOR vispirms ir jāatbild uz viņu jautājumiem. Ideālā gadījumā visa pirmsprojekta dokumentācija kaskādes metodē tiek veidota tā, lai izstrādes procesā tiktu noņemti jautājumi.
Tātad, uz kādiem jautājumiem atbild TK?
Kam šī vietne ir paredzēta un kāpēc?
Vietne ir izveidota Klientam un viņa klientiem. Tie ir topošā projekta iedibinātie lietotāji.
Labākais risinājums būtu, ja darba uzdevumā jūs aprakstītu visus vietnes lietotājus, gan iekšējos, gan ārējos. Šis apraksts var ietvert mārketinga, demogrāfiskos, sociālos datus, potenciālo lietotāju mērķus un uzdevumus, viņu prasības topošajai vietnei.
Kā tiks atrisināti klienta un lietotāju uzdevumi?
Faktiski, ja jūs neatbildat uz šo jautājumu, tad tehnisko specifikāciju rakstīšana var tikt atzīta par papīra darbu. Tas ir būtisks un būtisks jautājums. Tam var veltīt atsevišķu rakstu, tāpēc pagaidām sīkāk nekavēsimies.
Kā tiks izveidots projekts?
Kā jau rakstīju iepriekš, TOR (vai varbūt atsevišķs dokuments) dažkārt apraksta projekta izstrādes procesu. Tas ir absolūti nepieciešams, ja ņemam vērā, ka vietni var izstrādāt pēc izstrādes metodikas, kas atšķiras no uzņēmumā pieņemtās izstrādes metodikas, kas, kā likums, nav aprakstīta nevienā dokumentā. Var mocīt sevi ar sapņiem par ISO standartizāciju tik ilgi, cik vien tīk, bet ko parādīt sīkumainam klientam?
Saskaņā ar GOST ir paredzēta atsevišķa sadaļa “Sistēmas izstrādes posmi”. Šajā sadaļā jūs nevarat aprakstīt procesu pārāk detalizēti un instalēt atskaites punktus.
Kāds būs iznākums?
TK sāk attīstību un pieliek tai punktu.
Ideālā gadījumā kopā ar klientu vajadzētu iziet cauri visiem TOR punktiem, pārbaudīt saņemtajā sistēmā un pēc nedēļas pateikt: “Uh. Šķiet, ka viss ir izdarīts."
"TOR ir līdzeklis veiktā darba pārbaudei." - tāda frāze ir rakstīta daudzu manu TK ievadā.
Kas nepieciešams turpmākai projekta uzsākšanai?
Šis ir jautājums, uz kuru klientam ir jāsaņem labā atbilde. Tas jau ir konsultācijas, bet dažos gadījumos tas ir jāveic projektēšanas procesā. Ir nepieciešams plānot darbu skaitu, nepieciešamo programmatūru un aparatūru utt.
No kā sastāv TK?
ES esmu aizgājis visu stundu lēmumu pieņemšana: aprakstiet TK sastāvu konkrētas skaidras struktūras veidā vai vienkārši runājiet par to, kam tur vajadzētu būt. Atskatoties uz visiem saviem TOR, es nonācu pie secinājuma, ka šī dokumenta struktūra ir tik bieži mainījusies atkarībā no vairākiem faktoriem, kas skaidri norādītu uz struktūru būtu kā slikts padoms uzvalka izvēlē. Iedomājieties, ka jums liek kaut ko uzvilkt vakarā, pat nezinot, kurp dodaties.
Galvenā informācija
Darba uzdevuma pirmajā daļā ir ievads un Galvenā informācija par dokumentu un projektu kopumā. Ievads jāraksta vienreiz un uz mūžu. Parasti tur ir rakstītas tik abstraktas frāzes, ka katrā jaunā projektā ir nepieciešams izlabot tikai dažus vārdus.
Vispārīgā informācija ietver:
- Informācija par pasūtītāju un izpildītāju.
Katrā pusē noteikti norādiet atbildīgās personas. Ir norādīti dokumenti, uz kuru pamata tiek veikta izstrāde. Parasti šāds dokuments ir līgums. Pašreizējā dokumenta statuss un privātums. - Projekta uzdevums.
Norāda: kādam nolūkam tiks izmantots iegūtais produkts. - Radīšanas mērķi un uzdevumi, kas resursam jāatrisina.
No vienas puses, šī ir diezgan īsa sadaļa, taču pēc izstrādes svarīguma tā ieņem pirmo vietu. Ja mērķi un uzdevumi nav skaidri un nav izmērāmi, var būt diezgan grūti tos ievērot. - Projekta auditorijas apraksts.
Kritiska informācija labu un pareizu vietņu izstrādei. Skaidrs, ka informācija par auditoriju ir ne tikai pareizi jāsavāc, bet vēl svarīgāk ir prast šo informāciju izmantot.
Auditorijas aprakstā jāiekļauj ne tikai informācija, ko mārketinga speciālisti tik ļoti mīl (demogrāfija, vajadzības, segmentācija utt.), bet arī informācija, kas noderēs dizaineriem un plānotājiem: kādus uzdevumus lietotājs risina, kādi ir viņa mērķi. darbs ar vietni, kas piesaista. Alans Kūpers iesaka vietnes auditoriju raksturot nevis kā masu bez sejas, bet gan izcelt personāžus – lai raksturotu konkrētu cilvēku kolektīvo tēlu. - Termini un definīcijas.
Lielajā dokumentā jūs varēsiet izmantot milzīgu skaitu terminu un slenga izteicienu, ko reti saprot mārketinga speciālisti vai augstākā līmeņa vadītāji. Viņi var lasīt šo dokumentu, tāpēc vislabāk ir nodrošināt viņiem definīciju sarakstu. Es neglaimoju sev ar cerību, ka šis saraksts kaut reizi mūžā ir izlasīts, taču vienmēr varu atsaukties uz to.
Dokumenta ievada vispārīgajā daļā ir informācija par to, ar ko mēs sākām projektēšanu. Protams, klienta speciālistu iztaujāšanas procesā informācija uzkrājas par lielumu vairāk, taču nevienam nav interese to lasīt.
Šī informācija tiek apkopota projekta ietvaros.
Projekta apjoms
Ja jūs attālināsieties no savas mājas un, pagriežoties, paskatieties uz to, tad no attāluma jūs nevarēsit atšķirt konstrukcijas detaļas. Logus var saskaitīt, bet nevar saprast, no kāda materiāla tie ir izgatavoti, var apbrīnot arhitektūru (protams, nevar “apbrīnot” katru māju), bet par tās principiem var tikai nojaust. būvniecībā, nevarēs redzēt ne dzīvokļu iekšpusi, ne uzskrāpēto vārdu uz ieejas durvīm.
Projekta apjoms ir aptuveni tāds pats. Izlasot šo nodaļu, ikvienam vajadzētu iedomāties, kas tiks iegūts izstrādes procesā, taču nemaz neiedziļinoties detaļās. Jūs rakstāt, ka vietnē darbosies “lietotāja reģistrācija”, bet nerakstiet, kā tieši tā darbosies, vai kādi lauki lietotājam būs jāaizpilda.
Dizaina pamatlīmenis jebkurā gadījumā iet cauri jebkuram projektam, tāpēc nebūs lieki to pierakstīt. Turklāt lielajiem priekšniekiem gan no izstrādātāju, gan pasūtītāja puses nepatīk ilgi lasīt, bet viņiem patīk būt lietas kursā par visu, kas notiek. Šī sadaļa būtu jāraksta arī viņiem.
Projektu darbības jomas ir rakstītas scenāriju veidā par to, kā lietotāji mijiedarbojas ar vietni, un apraksta vispārējo funkcionalitāti un mijiedarbību ar saskarni.
Informācijas arhitektūra un saskarne
Vietņu informācijas arhitektūrai (IA) veltītā sadaļa nav standartizēta ne ar vienu zināmu standartu (autore ar šādiem standartiem vēl nav pazīstama). Bet ikviens, kurš ir izstrādājis tīmekļa vietnes, saprot, ka IA ir gandrīz galvenais, kas jums jāzina, lai izstrādātu vietni. IN noteiks, kā vietne izskatīsies un darbosies ar lietotājiem.
Lai aprakstītu IA, jums būs jāapraksta no augšas uz leju:
- Vietnes struktūra. Tie ir tā sauktie augsta līmeņa prototipi.
- Lapu veidnes. Zema līmeņa prototipi, kas tieši apraksta vietnes saskarni.
- Satura apraksts. Katras vietnes lapas satura tabulas apraksts.
Vietnes struktūra
Vietnes karte ir veidota grafiski vienā no labi zināmajiem apzīmējumiem: Visio vai Garrett. Iesaku uzzīmēt vietnes karti, jo šajā gadījumā iegūtā struktūra ir vizuālākā un ērtākā turpmākai lietošanai. No vienas puses, var šķist, ka vietnes karti saraksta veidā būtu daudz vieglāk uzrakstīt, taču, pats domājot par saitēm starp dažādām vietnes daļām, jūs negribot sākat zīmēt kvadrātus uz papīra. .
Ir rakstīti veseli raksti par to, kā jūs varat uzzīmēt vietnes struktūru, izmantojot apzīmējumus, izmantojot Visio, tāpēc mēs pie tā nekavēsimies. Raksti tomēr ir rakstīti angļu valodā, taču tos var viegli izmantot.
Neaizmirstiet piešķirt numuru katrai atsevišķai vietnes kartes lapai. Tas būs nepieciešams satura apraksta posmā.
Noderīgi padomi vietnes kartes zīmēšanai:
- Netaupiet vietu. Mēģiniet sakārtot blokus tā, lai tie būtu atdalīti viens no otra. Tas uzlabos kartes lasāmību.
- Nesamazinies. Principā 4 izmērā drukāto tekstu var lasīt, bet tas jau ir pamats naidam.
- Izlīdziniet lapu "kvadrātus" vienu pret otru, sarindojot tos līnijās. Tas uzlabos uztveri par lapu ligzdošanas līmeņiem.
- Nepārkāpjiet līnijas. Centieties izvairīties no daudziem sakaru līniju krustojumiem. Ja tie krustojas, tiem ir "jāpārlec" vienam pāri. Tie, kas universitātē nodarbojās ar funkcionālo diagrammu zīmēšanu, mani sapratīs.
- Parakstiet karti. Parakstiet pašu karti, kā arī atsevišķus blokus. Tas vēlāk padarīs to mazāk mulsinošu.
- Bieži saglabājiet failu. Neparasti, bet jums tas vienkārši jāatceras. Nav nepieciešams vēlreiz atsaukt Visio programmas izstrādātāju radiniekus, patiesībā viņi ne pie kā nav vainīgi.
Es parasti ievietoju vietnes karti sadaļā Lietojumprogrammas. Parasti tas ir tik liels, ka kļūst nereāli to novietot TK vidū.
Lapu veidnes
Vietnes kartes līmenī katra lapa mums ir tikai “kvadrāts” uz papīra lapas. Dizaineram, maketētājam un programmētājam ar to nepietiek, lai izstrādātu vietni. Jums arī jāzina informācijas bloku un funkciju klātbūtne un atrašanās vieta vietnes lapās. Tāpēc mēs pārejam pie vietņu veidnēm. Ideālā gadījumā katrs lodziņš būtu detalizēts līdz katras atsevišķās lapas izkārtojumam. Šī ir vietnes prototipēšana. Prototipu izmantošana ir atkarīga no pieņemtās darba shēmas izstrādes uzņēmumā, taču ir vērts atzīt, ka tas klientam kļūst ārkārtīgi dārgs.
Lai vienkāršotu, ir vairākas vietnes saskarnes veidnes, kas ir aprakstītas pēc vietnes kartes.
Veidņu apraksts sastāv no 3 daļām:
- Veidņu saraksts. Ir noteikti galvenie lapu veidi un aprakstīts to lietojums.
- Tipiska veidne. Galvenie bloki. Galvenie lapu bloki ir aprakstīti, lai samazinātu informācijas atkārtošanos.
- Katras veidnes apraksts saskaņā ar sarakstu. Veidnes tiek zīmētas jebkurā grafikas pakotnē (Adobe Illustrator, Adobe InDesign, MS Visio u.c.), un pēc tam tiek papildinātas ar īsu aprakstu.
Rezervācija: vietnes saskarnes veidnes nedrīkst jaukt ar veidnēm programmatūras sistēmā, kurā vietne darbosies. Interfeisa veidnes apraksta standarta lapu skaitu, kas ir pietiekams vietnes noformējumam.
Izplatības piemērs no TOR ar interfeisa veidnes (vadu rāmja) aprakstu.Satura apraksts
Garākā un garlaicīgākā darba daļa. Satura aprakstā jāiekļauj visu vietnes lapu saraksts, precīzi norādot katrā lapā ievietoto tekstu, attēlus utt. Tas arī norāda, kura veidne tiek izmantota šai lapai (skatiet iepriekš). Šim nolūkam iesaku izmantot izklājlapu.
TOR rakstīšanas laikā ne vienmēr ir iespējams droši zināt, kāds saturs būs vietnē: precīzs informācijas lapu skaits, grafiskās informācijas izvietojums, tāpēc nedomājiet, ka šajā sadaļā ir sniegts visprecīzākais apraksts. Bieži vien tas tā nav. Bet, ja šajā posmā aprakstīsiet nepieciešamo saturu, tad, pamatojoties uz to, projekta vadītājs varēs sastādīt satura piegādes plānu un novērtēt šīs informācijas apjomu, kas jāiekļauj vietnē. Klientam vienmēr acu priekšā būs saraksts ar to, kas viņam jāsagatavo un jārediģē.
Labs satura apraksts ir galvenais plānotais darbs vietnes palaišanas un informācijas ievadīšanas posmā.
Funkcionāls
Vietnes funkcionalitātes apraksts darba uzdevumā ir viena no galvenajām sadaļām. Tas jo īpaši attiecas uz vietnēm ar lielu programmatūras darba procentu: e-komercija, tiešsaistes pakalpojumi utt.
Labu funkcionālā apraksta piemēru sniedz GOST. Es iesaku pieturēties pie standarta, aprakstot vietnes ietvaros izstrādāto programmu funkcionalitāti. Jāapraksta: vispārējā sistēma, apakšsistēmu un moduļu vispārējā funkcionalitāte, apakšsistēmu un moduļu savstarpējās attiecības un, visbeidzot, visu to moduļu funkciju uzskaitījums, kuriem ir vairāk vai mazāk Detalizēts apraksts viņu darbs. Katram modulim ir jāapraksta objekti, kas tiek izveidoti vai izmantoti programmā.
Var aprakstīt arī datubāzes struktūru, priekšdarbu algoritmus, bet pats darba uzdevums to neprasa. Saskaņā ar GOST šādas detaļas jāapraksta turpmākajos dokumentos: projektā un tehniskajos projektos.
Dažreiz, izstrādājot lielas vietnes, jums ir ilgi jāsēž, lai aprakstītu visas vietnes ārējo un iekšējo daļu funkcionalitāti. Daži izstrādātāji ir pret šādām detaļām. Viņi uzskata, ka funkcionalitāte jāapraksta virspusēji, lai “klients saprastu”. Pilnīgas muļķības! Pēc pieredzes varu teikt, ka nav nevienas liekas detaļas. Problēmu gadījumā projektā abu pušu projektu vadītāji kļūst par retajiem burtu ēdājiem! Viņi laboja TK augšup un lejup, cenšoties pierādīt savu lietu. Tāpēc, ja TOR funkcionalitāte ir izklāstīta vispārīgi, klients tik un tā piespiedīs viņu darīt to, kas viņam nepieciešams.
Prasības
Atsevišķa sadaļa jāvelta prasībām projektam vai projektam attiecībā uz vidi. Prasības, kuras var aprakstīt vietnes darba uzdevumā:
- Tehniskās prasības sistēmai;
- Prasības personālam;
- Uzticamības prasības;
- Prasības ergonomikai un tehniskajai estētikai;
- Prasības informācijas aizsardzībai pret nesankcionētu piekļuvi;
- Prasības informācijas drošībai negadījumu gadījumā;
- Prasības nodrošinājuma veidiem;
- Programmatūras prasības;
- Prasības informācijas atbalstam;
- Prasības tehniskajiem līdzekļiem;
Var būt arī vairākas īpašas prasības.
Visām prasībām jābūt skaidri formulētām un jācenšas neaizmirst neko no sava projekta attīstības aspektiem.
Protams, mazos projektos nav nepieciešams pierakstīt visas iepriekš minētās prasības. Tā, piemēram, bieži vien mājaslapā vispār nav darbinieku, tāpēc šādas sadaļas tiek izlaistas.
Cits
Projektu vadības procesā var pamanīt, ka rodas situācijas, kas pārsniedz darba uzdevuma robežas. Varbūt jūs kaut ko palaidāt garām vai radās ārkārtas situācija, kuru iepriekš nevarējāt paredzēt. Tas viss palīdzēs tālāk attīstīt dokumentu, ienesot tajā jaunu informāciju, kas palīdzēs to izmantot saziņā ar klientu un atrisināt problēmas.
Ko tālāk?
TOR tika sastādīts, parakstīts un pieņemts darbā. Ko tālāk? Vai darbs ar viņu šajā posmā beidzas? Nē.
Ne vienmēr projekts norit pa iepriekš izplānotu ceļu. Mēs cenšamies kaut ko uzlabot, mainīt, bieži mainās klientu prasības. Darba uzdevums ir dokuments, nevis planšetdators. Mainoties prasībām projektam, būtu jāmainās arī darba uzdevumam. Parasti to dara ar papildu dokumentiem ar izmaiņu sarakstu. Dabiski, ka tie tiek apkopoti tikai tad, ja tas patiešām ir nepieciešams, praksē tas notiek reti.
Tāpat jābūt gatavam tam, ka padziļinātas tehnisko specifikāciju izpētes procesā kļūdas atradīs visi izstrādes dalībnieki, strādājot pie projekta. Kļūdu skaits lielā dokumentā ir tieši proporcionāls tā garumam un apgriezti proporcionāls laikam, kas pavadīts tā rakstīšanai. Jo laika pastāvīgi trūkst, jārēķinās, ka TOR radīsies kļūdas.
Sausā vielā
Es uzrakstīju šo rakstu pirms vairāk nekā gada. Ir pagājis diezgan daudz laika, un pa šo laiku neesmu uzrakstījis nevienu lielu TK. Bet, vēlreiz pārlasot sniegto informāciju, es piekritu visam, kas šeit rakstīts. Tātad labam vietnes TK jābūt:
- Vispārīga informācija par dokumentu un tā autoriem;
- Vietnes mērķi un uzdevumi;
- Vietnes lietotāju apraksts, viņu mērķi un uzdevumi;
- Projekta apjoms;
- Vietnes informācijas arhitektūra (IA): vietnes karte, veidnes, saskarnes apraksts;
- vietnes satura apraksts;
- Vietnes funkcionalitātes apraksts;
- Procesa apraksts un atskaites punkti, ja nepieciešams;
- Visu veidu prasību saraksts, izstrādājot vietni un pārbaudot saņemto darbu.
Ceru, ka informācija būs noderīga plašam lasītāju lokam.
Noderīgas saites
- GOST 34.602-89.
Jurijs Šilajevs
Jurijs Šiljajevs, Minska. vietņu dizainers, konsultants. Artics Internet Solutions Minskas biroja direktors.