TK sagatavošana. Darba uzdevumi: likumdošanas prasības un labākā prakse

Projekta apjoma noteikšana, tehnisko specifikāciju izstrāde

Šajā sadaļā īsi apskatīts attīstības jautājums darba uzdevums(turpmāk TK). Pirmkārt, tiek dota TK definīcija, aprakstītas TK priekšrocības gan pasūtītājam, gan darbuzņēmējam, kā arī uzskaitītas galvenās TK funkcijas. Tālāk tiek apskatīta TK būtība, atklāta TK struktūra un saturs, kā arī sniegti TK uzbūves piemēri. Noslēgumā tiek atzīmētas inovatīvo projektu TOR iezīmes.

Tā kā inovatīvā projekta tehnisko specifikāciju izstrādes uzdevumi, kam ir savas īpatnības, principā paliek tādi paši kā jebkuru tehnisko specifikāciju izstrādē, vispirms tika izskatīts jautājums par tehnisko specifikāciju izstrādi kopumā.

Definīcija

Jāatzīmē, ka pašlaik nav standartizētas novatoriska projekta darba uzdevuma definīcijas. Pašreizējā valsts standartu datubāzē ir trīs ar TK saistīti standarti. Visi no tiem pieder informācijas tehnoloģiju jomai:

GOST 19.201-78. viena sistēma programmatūras dokumentācija. Tehniskais uzdevums. Prasības saturam un dizainam.

GOST 25123-82. Skaitļošanas mašīnas un datu apstrādes sistēmas. Tehniskais uzdevums. Būvniecības, prezentācijas un projektēšanas kārtība.

GOST 34.602-89. Informāciju tehnoloģijas. Standartu komplekts automatizētām sistēmām. Darba uzdevumi izveidei automatizēta sistēma.

Piemēram, "GOST 19.201-78. Vienota programmu dokumentācijas sistēma. Tehniskais uzdevums. Prasības saturam un dizainam” dota šāda TOR definīcija: “Automatizētās sistēmas darba uzdevums ir atbilstoši apstiprināts dokuments, kas definē automatizētas sistēmas izstrādei nepieciešamos mērķus, prasības un pamatsākotnējos datus un satur provizorisku ekonomiskās efektivitātes novērtējums.

Tajā teikts, ka TK ļauj:

izpildītājam - izprast uzdevuma būtību, parādīt pasūtītājam topošā produkta, programmatūras produkta vai automatizētās sistēmas "tehnisko izskatu";

klients – apzināties, kas viņam tieši vajadzīgs;

abas puses - prezentēt gatavo produkciju;

izpildītājam - plānot projekta īstenošanu un strādāt saskaņā ar plānu;

pasūtītājam - pieprasīt no izpildītāja, lai prece atbilstu visiem TOR noteiktajiem nosacījumiem;

darbuzņēmējam - atteikties veikt TOR nenoteiktus darbus;

pasūtītājam un darbuzņēmējam - veikt gatavās produkcijas punktu pa punktam pārbaudi (pieņemšanas testēšana - veikšana testiem);

izvairieties no kļūdām, kas saistītas ar mainīgajām prasībām (visos izveides posmos un posmos, izņemot testiem).

Tādējādi darba uzdevums ir dokuments, kas satur prasību kopumu un ļauj gan izstrādātājam, gan pasūtītājam prezentēt galaproduktu un pēc tam pārbaudīt atbilstību prasībām.

Jo detalizētāks ir TOR, jo mazāk strīdu starp klientu un izstrādātāju radīsies pieņemšanas pārbaužu laikā.

TK veic četras galvenās funkcijas:

Juridisks. TK ir juridisks dokuments, un kā pieteikums ir iekļauts līgumā starp pasūtītāju un darbuzņēmēju.

Organizatoriskā. Ar TK palīdzību jūs varat racionalizēt turpmāko darbu, pārvērst to par uzdevumu rindu (shēmu) un netērēt spēkus nevajadzīgām darbībām.

Informatīvs. Labi uzrakstīts TOR var būt labs informācijas avots, kas nepieciešams projekta pabeigšanai. TK strukturēšana ļauj iegūt informāciju, kas patiešām interesē, visvieglāk uztveramā formā un tādā apjomā, kāds nepieciešams darba pabeigšanai.

Komunikabls. Detalizēts TOR palīdz darbuzņēmējam labāk izprast pasūtītāja vajadzības un veikt darbu, kas atbilst visām viņa gaumēm. Tas arī atvieglo projekta apstiprināšanas procesu.

TK būtība

Darbs pie TOR nozīmē, ka ir paredzēts kāda uzdevuma risinājums, un tas soli pa solim ir aprakstīts šajā dokumentā. TK var izstrādāt jebkam: tehnoloģiju, jauna materiāla, ierīces, mājas lapas, programmas, standarta izveidei, pasākuma īstenošanai utt.

Projekta īstenošanas gaitā iegūtie gala rezultāti var būt materiāli (materiāli, process, tehnoloģija), organizatoriski (norma, standarts), zinātniski, tehniski un zinātniski un metodoloģiski (projekta dokumentācija, pētījuma ziņojums, izglītības programma), nemateriāli ( patenti, monogrāfijas, raksti) un citās formās.

TK būtība ir sekmīga uzdevuma izpilde. Jo labāk un labāk tiks sastādīts TOR, jo efektīvāk tiks izpildīts uzdevums. Turklāt tas nav atkarīgs no tā mēroga. Nepareiza TOR sagatavošana var radīt sekas, piemēram, rezultāta neparedzamība, darbs netiks veikts tā, kā tas būtu jādara pasūtītājam, vai netiks veikts vispār. Darba pasūtītājs nesaņems to, ko vēlējies un viņam ir tiesības par padarīto darbu nesamaksāt.

Darbs pie TK ir grūts un atbildīgs posms, jo daudzi dati vēl nav zināmi. Projekta panākumi, pēc ekspertu domām, par 50-70% ir atkarīgi no TOR attīstības posma kvalificētas īstenošanas.

Parasti pirms tehnisko specifikāciju izstrādes stadijas tiek veikta priekšmeta izpēte, aprēķini un modelēšana.

Atbildīgs darbs pie TK ļaus tā izstrādātājiem redzēt uzdevuma izpildes scenāriju. Skaidri izprotiet savas stiprās un vājās puses, kā izdzīvot uzdevuma izpildes procesu. Noteikt kritērijus, noteikt rādītājus, raksturlielumus, summas, novērtēt resursus.

TK tiek saskaņots ar pasūtītāju vai izstrādāts kopīgi.

Neskatoties uz tā nozīmīgumu, TK saturu un struktūru praktiski nereglamentē normatīvie dokumenti.

Parasti klients nosaka mērķi (kā viņš to saprot) un resursu ierobežojumus (laiks, nauda). Izpildītāja uzdevums, pirmkārt, ir pārtulkot prasības mācību priekšmeta valodā, pēc iespējas pilnīgāk un prasmīgāk formulēt uzdevumu, pamatot tā risināšanas nepieciešamību, izprast un precizēt sākotnējos datus. Uzdevuma saturā jāiekļauj informācija par to funkciju mērķiem un izpildi, kas īsteno noteiktas vajadzības, kuras vienmēr ir saistītas ar noteiktu prasību apmierināšanu.

Darbs ar prasībām ir pakļauts vadībai. Neskaidras prasības rada nenoteiktību visos darba dalībniekos, jo ļauj dažādi interpretēt prasības un neļaus objektīvi novērtēt izstrādājamā produkta kvalitāti.

Veidojot prasību sistēmu, jāanalizē pasūtītāja un izstrādātāja rīcībā esošo resursu pieejamība: finanšu, ražošanas, cilvēku, pagaidu, kā arī jāņem vērā uzraudzības un licencēšanas iestāžu prasības, piemēram, , projektējot tehnoloģiskos kompleksus (ražojumus). Visbiežāk kontrolē Rostekhnadzor, Rosstandart, Rospotrebnadzor, Rosprirodnadzor uc reģionālās struktūras.

Tālāk ir sniegti TK struktūras piemēri no dažādiem avotiem.

Piemēram, TK var saturēt sadaļas:

TK priekšmets;

veicamā darba mērķis;

ziņošanas prasības;

darba organizācijas kārtība;

Piemērs no iepriekš minētā GOST 19.201-78.

ievads;

attīstības pamatojums;

attīstības mērķis;

prasības programmai vai programmatūras produktam;

prasības programmatūras dokumentācijai;

tehniskie un ekonomiskie rādītāji;

attīstības stadijas un stadijas;

kontroles un pieņemšanas kārtība;

darba uzdevumā atļauts iekļaut pieteikumus.

Šis TOR piemērs konsultāciju pakalpojumu sniegšanai

vispārīgie noteikumi;

darba mērķis;

kvalifikācijas prasības kandidātiem.

TOR piemērs pētnieciskā darba "Koncepcijas, attīstības stratēģijas un priekšizpētes izstrāde tehnoloģiju un inovāciju parka izveidei Permas pilsētā" (turpmāk P&A) īstenošanai

pamats pētījumiem

izpildītājs un līdzizpildītāji

1. pētniecības uzdevumi

   sākotnējie dati

   pamatprasības pētījumu veikšanai

   pētījumu īstenošanas kalendārais plāns

   pētījuma rezultātu paredzētā izmantošana

   pētījuma rezultātu piegādes un pieņemšanas kārtību

P&A TP veidnes struktūras piemērs

Pamats darbam

Izpildītājs

Darba noteikumi

Darba mērķis

R&D rezultāti

Produkti izstrādes stadijā

Tehniskās prasības

Galvenie parametri, kas jāsasniedz darba rezultātā:

Projektēšanas pamatprasības (ja tādas ir)

Prasības pēc nodrošinājuma veidiem (ja piemērojams)

Prasības standartizācijai, unifikācijai, savietojamībai ar pārošanās objektiem un savstarpējai aizvietojamībai.

Prasības cilvēku dzīvības un veselības drošības un vides aizsardzības nodrošināšanai

Uzticamības prasības (ja tādas ir)

Prasības attiecībā uz uzticamību un izturību.

Ergonomikas un tehniskās estētikas prasības (ja piemērojamas)

Prasības ekspluatācijai, izmantojamībai un apkopei (ja piemērojams)

Noturības prasības (ja piemērojamas)

Veiktspējas prasības (ja tādas ir)

Sertifikācijas prasības

Citas prasības un īpašās prasības pa nozarēm

Prasības patenta tīrībai un patentspējai

Dokumentācijas prasības

Darbu pieņemšanas kārtība.

Tādējādi, analizējot struktūru dotajos piemēros, var atzīmēt, ka TK struktūru un saturu nosaka veicamais uzdevums.

Novatoriska projekta tehnisko specifikāciju izstrādes iezīmes

Inovatīvi projekti ir unikāli notikumi, jo tie ir saistīti ar zinātnisku un tehnisko ideju pārtapšanu jaunos vai uzlabotos produktos, kā arī jaunos vai pilnveidotos tehnoloģiskos procesos, ko izmanto praktiskajā darbībā, vai jaunās pieejās sociālajiem pakalpojumiem. Ir jādara kaut kas, kas nekad agrāk nav darīts. Un pagātnes pieredze var sniegt tikai ierobežotu norādi par to, ko sagaidīt. Tāpēc inovatīviem projektiem ir augsta nenoteiktības un riska pakāpe, un tā ir to īpatnība.

Inovatīvā projekta izstrādes mērķis ir rast risinājumus, lai iegūtu iecerēto projekta gala ideju un radītu uzdevumu un aktivitāšu kopumu, ko šī inovatīvā projekta īstenošanai sasaistīs laiks, resursi un izpildītāji. Jebkurš inovatīvs projekts tā īstenošanas laikā iziet noteiktu ceļu: no idejas izstrādes fāzes līdz idejas neatbilstības fāzei. Tehnisko specifikāciju izstrādes stadija attiecas uz inovatīva projekta sākuma stadiju.

Inovatīvā projektā, veidojot pilnībā jauns produkts ir grūti iepriekš plānot visus parametrus, tāpēc tiek piedāvāts izmantot dinamisku paplašinātu TOR, kas galvenokārt ir aprakstošs.

Pirmais solis pēc jaunas produkta idejas ģenerēšanas ir prasību katalogs, kas var ietvert klientu prasības, tirgus segmentāciju jaunajam produktam, normas, standartus, vispārējos mērķus (tirgus daļa, izmaksas), laiku līdz tirgum, dzīves ciklu, kopējo risku. novērtējums.

Prasību katalogā norādītie rādītāji ir norādīti dokumentā, ko sauc par paplašināto darba uzdevumu.

Ja prasību katalogs ir sastādīts “klientu valodā”, tad paplašinātais TOR ir “uzņēmuma valodā”. Paplašinātajā TPR jāiekļauj papildus tradicionālajām pozīcijām (darba apjoms, atskaites, sākotnējie dati, parametru prasības utt.) un daži projekta biznesa plāna elementi (paredzamā cenu politika, plānotā tirgus daļa, plānotais apgrozījums utt. .) .

Tā kā prasību katalogs tiek veidots no klienta skatpunkta, tad arī prasību kataloga rakstīšanas valoda tiek izvēlēta klientam saprotama (bez konkrētām tehniskām detaļām). Prasību katalogā ir atspoguļoti uzņēmuma priekšlikumi, reaģējot uz klientu vajadzībām.

Paplašinātais TOR var ietvert:

1. Projekta apraksts

2. Projekta tirgus un ekonomiskie mērķi

3. Laika parametri

4. Tehniskie parametri

5. Ražošanas parametri

8. Prasības dizainam un ergonomikai

9. Standarti un noteikumi

Tādējādi paplašinātā TOR sastādīšanas galvenais uzdevums ir apkopot vispilnīgāko informāciju par izstrādājamo produktu, kas tiek ņemta vērā plānošanā.

Paplašinātā TOR informācija ir sīkāk precizēta saistībā ar produkta struktūru, kas ir visu to komponentu saraksts, kas veidos projekta rezultātu. Projekta rezultātu struktūras plānā ir visas veidojamā produkta sastāvdaļas, bloki, mezgli.

Svarīgākie TOR elementi ir: darba mērķis, rezultātu apjoms, darba saturs, tā īstenošanas programma, tehniskie, ekonomiskie un citi rādītāji, prasības darbam, līmenis un metode. tās īstenošanas, darba rezultātus, sagaidāmo rezultātu zinātnisko, zinātnisko, tehnisko un praktisko vērtību; rezultātu paredzētā izmantošana un atskaites materiālu veids, pasniegšanas forma.

Apsveriet TK vietu struktūrā inovāciju process organizācijā(inovācijas organizācijā) saskaņā ar .

Sākotnēji tiek izstrādāta inovācijas koncepcija. Pirms tam notiek izpētes posms (organizācijas aptauja, darbības rādītāju izvēle tās gaidāmajai inovācijas darbībai, inovāciju ieviešanai nepieciešamo aktivitāšu saraksta pamatojums). Izveidotās izstrādes komandas inovācijas koncepcija izvēršas inovatīvā projekta izstrādes uzdevumā (TOR), kurā jāietver visi pamatojumi, sākotnējie iestatījumi un parametri, kas nepieciešami turpmākai projektēšanai.

Pamatojoties uz inovatīvā projekta izstrādes uzdevumu, tiek sastādīts detalizēts rīcības plāns atsevišķu uzdevumu izstrādei un risināšanai, kā arī to izpildes uzraudzībai (kontrolpunkti pa termiņiem, kontrolējamo parametru saraksts, kontroles kritēriji). utt.). Faktiski darba uzdevums, rīcības plāns ir pamats inovatīva projekta izstrādei.

Projekta saturs ir plānoto aktivitāšu apraksts un nolikums, resursu optimālas izmantošanas aprēķini, sagaidāmo īstenošanas rezultātu novērtējums, novests līdz kvantitatīvām vērtībām. Inovatīva projekta pamatā ir tā organizatoriskā un finansiālā daļa. Tam seko projekta adaptācijas un īstenošanas posmi un projekta rezultātu analīze.

Kad TOR kā dokuments ir apstiprināts, tiek veikta darba plānošana pie projekta.

No autora: Kā rakstīt mājas lapas izstrādes darba uzdevums? Tēma ir diezgan plaša, un viena raksta ietvaros ir grūti to 100% izjaukt (ja vispār iespējams). Bet vispārīgos noteikumus, kas jāņem vērā, kam jāpievērš uzmanība, sastādot TOR, es centīšos šajā rakstā izklāstīt pietiekami detalizēti.

Tātad, TK

Darba uzdevumi ir sastādīti vietnes izstrādātājam. Uz TK ir jāatsaucas, sastādot līgumu starp pasūtītāju un izpildītāju. Jānosaka abu pušu atbildība par TPR punktu un nosacījumu nepildīšanu vai nepareizu izpildi. Bet pats galvenais (manuprāt), kam tiek radīta TK, ir priekš vietnes izstrādes procesa paātrināšana.

Analizēsim šo piemēru:

Pieņemsim, ka jums ir nepieciešams kalendārs kaut kur jūsu vietnes malā. Tas likās sīkums. Bet, jo vairāk aprakstīsit šī kalendāra funkcionalitāti, jo ātrāk iegūsit rezultātu.

Es šeit nedaudz paskaidrošu. Kalendārs ir atšķirīgs. Ir kalendārs, kas vienkārši parāda skaitļus pašreizējā mēneša nedēļas dienām. Ir kalendārs ar iespēju ritināt pa mēnešiem. Ir kalendārs ar iespēju šķirstīt mēnešus un gadus.

Pieņemsim, ka jums ir nepieciešama jaunākā kalendāra versija (ar iespēju ritināt mēnešus un gadus) ar izceltu pašreizējo datumu. Jūs norādījāt TOR: "sānjoslā ir nepieciešams kalendārs." Klients izveido jūsu vietā pirmo kalendāra versiju (vienkārši parāda skaitļus pa kārtējā mēneša nedēļas dienām).

Kas mums ir. Darbuzņēmējs pabeidza TK vienumu, bet jūs gribējāt pavisam citu kalendāru. Šķiet, ka viss ir saskaņā ar TOR, neviens nav vainīgs, nav nonācis konfliktā, bet galvenais ir zaudēts laiks un nauda.

Šis ir tikai banāla kalendāra piemērs.

Un ja ir jāpārtaisa kas nopietnāks, kura apstrāde aizņem vairāk nekā pusi dienas, kā tas ir kalendārā? Un jums nav vietnes, un klients ar jums jaucas, lai gan viņš varētu pabeigt jūsu projektu un sākt jaunu.

Tāpēc, nekā vairāk Ja aprakstīsit katra vietnes moduļa funkcionalitāti, jo ātrāk iegūsit rezultātu. Par to vajadzētu interesēties abām pusēm.

No kādiem priekšmetiem parasti sastāv TOR?

Iedomāsimies, ka esat kāda uzņēmuma vai firmas īpašnieks. Jūsu uzņēmums nodarbojas ar jebkura produkta ražošanu un tā ieviešanu. Jums ir pircēji. Jūs sadarbojaties ar pārdevējiem (veikali un interneta veikali), servisa centriem, preču patērētājiem. Vai arī jūs veidojat vietni šādam uzņēmumam un jums ir jāuzraksta tehniskā specifikācija.

Neatkarīgi no tā, kādu lomu jūs ieņemat, vispirms ir jāizpēta organizācijas struktūra, ar ko tā nodarbojas, nomenklatūra, īpašības un vispār viss, kas saistīts ar produktu un uzņēmumu. Tas, cik dziļi klients iedziļinās uzņēmumā notiekošā būtībā, ir atkarīgs no tā, kas notiks vietnē. Tāpēc uzdevums šeit ir abpusējs: klientam par uzņēmumu ir jāstāsta pēc iespējas detalizētāk, un izpildītājam rūpīgi jāsaprot notiekošā būtība.

Pat ja jūs pats uzrakstāt tehniskās specifikācijas uzņēmumam, kas veidos vietni, nav slikti to visu novērtēt uz papīra.

Pāriesim pie punktiem.

Vietnes apraksts

Šeit var pāris teikumos uzrakstīt par uzņēmumu, ar ko tas nodarbojas. Dariet kaut ko līdzīgu ievadam.

kam - vietnes mērķauditorija:

• potenciālie pircēji
• preču pārdevēji (veikali, interneta veikali)
• servisa centri
• partneri (firmas)
• produktu patērētāji (tie, kas jau ir iegādājušies)

Kāpēc jums ir nepieciešama vietne:

• Lai uzlabotu uzņēmuma tēlu
• Lai palielinātu pārdošanas apjomu
• Klientu ērtībām

Vietnes veids:

• Korporatīvs
• Mājas lapa – vizītkarte
• Interneta veikals

Valodu versijas:

• Angļu
• krievu valoda

Vietnei ir jāatrisina dažas problēmas. Attiecīgi mēs virzāmies tālāk atbilstoši vietnes mērķiem un uzdevumiem.

Vietnes mērķi un uzdevumi

Šajā TOR sadaļā mēs ejam cauri visai mērķauditorijai un aprakstām uzdevumu klāstu, kas vietnei viņiem būtu jāatrisina.

Potenciālie produktu pircēji.

Mērķis: lai piesaistītu vairāk pircēju un pārliecinātu tos veikt pirmo pirkumu, palīdziet izdarīt izvēli.

Problēmas ir jārisina:

Sniegt kvalitatīvu, visaptverošu informāciju par produktiem, papildu pakalpojumiem, garantijām, servisu, atlases metodēm.

• Iesniedziet informāciju par veikaliem
• Iesniedziet mazumtirdzniecības informāciju

Nodrošiniet iespēju uzdot jautājumu, organizējot uzņēmuma speciālistu tiešsaistes konsultācijas potenciālajiem pircējiem par preču izvēli, iegādi.

Tādējādi mēs ejam cauri visai mērķauditorijai. Ja sekojat mūsu vietnei, mēs aprakstām mērķus un uzdevumus produktu pārdevējiem (veikali, interneta veikali), servisa centriem, partneriem (uzņēmumiem), produktu patērētājiem. Tas ir, kas vietnei būtu jādara īpaši katram no tiem.

Tagad mēs uzskaitām vietnes moduļus.

Vietnes funkcionalitāte

Lai uzskaitītu vietnes funkcionalitāti, jums jāizlemj, kas tai nepieciešams:

• Vai jums ir nepieciešami jaunumi vietnē
• Vai jums ir nepieciešams reklāmu bloks?
• Vai ir nepieciešama reģistrācija
• Vai man ir nepieciešama privāta vietnes sadaļa (tikai reģistrētiem lietotājiem)
• Vai jums ir nepieciešama atsauksmju veidlapa?
• Vai man ir nepieciešams pasta skripts
• utt. utt.

Pēc tam, kad tas viss ir aprakstīts, mēs nonākam pie vissvarīgākā un interesantākā. Protams, visi iepriekš paveiktie darbi ir ļoti svarīgi, bet tagad tas kļūst vēl "karstāks".

Vietnes funkcionalitātes apraksts

Šobrīd mēs zinām, kam vietne ir paredzēta, kādi mērķi un uzdevumi tai jāizpilda, tās papildu funkcionalitāte.

Ir pienācis laiks, kad visa savāktā informācija jāienes sistēmā un skaisti jāievieto vietnē. Lai to atvieglotu un neizgudrotu riteni no jauna, varat apskatīt līdzīgu tēmu vietnes. Mācieties kaut ko no viņiem, skatiet un pārbaudiet to funkcionalitāti un mēģiniet uzlabot to, kas jūsu vietnē šķita neērts. Principā jūs varat apskatīt līdzīgu tēmu vietnes (un, ja jums nav pieredzes, tad jums tas pat ir nepieciešams) pašā TOR apkopošanas sākumā.

Es iesaku sākt ar izvēlnes vienumiem. Tam ir jāattēlo vietnes galvenās lapas un jāpārliecinās, ka katrs apmeklētājs ātri atrod informāciju par sevi. Un apmeklētāji ir mūsu mērķauditorija. Izvēlnē būs daudz vienumu, tāpēc tā būs nolaižamā saraksta veidā.

Vispirms jums jāpastāsta par uzņēmumu. Var būt lapas par uzņēmumu, uzņēmuma vēsturi, kontaktiem, atsauksmēm.

Protams, ir jābūt izvēlnes vienumam "produkti" ar apakšpozīcijām " Produktu katalogs”, “izlaidumi”, “produktu apskati”.

Kopumā es ceru, ka ir skaidrs, kā gleznot. Es iepazīstināšu ar mūsu vietnes iespējamās izvēlnes galīgo versiju:

Par uzņēmumu

• uzņēmuma vēsture
• kontaktpersonas
• atsauksmes

Jaunumi

• attīstību
• krājums
• jauns uz vietas

Produkti

• Produktu katalogs
• izlaidumi
• produktu atsauksmes

apkalpošana

• servisa nodaļa
• garantijas serviss
• pēcgarantijas serviss

Patērētājs

• pirkšana un piegāde
• izmantot
• par pakalpojumu

Veikali un interneta veikali

• produktu fotogrāfijas
• Bieži uzdotie jautājumi

Servisa centri

• Kā kļūt par servisa centru
• Bieži uzdotie jautājumi

Partneri

• uzaicinājumu uz sadarbību
• bieži uzdotie jautājumi

Mēs izdomājām ēdienkarti. Tagad jums jāapraksta, kas būs katrā lapā un kā tas viss darbojas kopumā. Turklāt norādiet aptuvenu vietnes izkārtojumu. To var uzzīmēt uz papīra ar zīmuli, skenēt un piestiprināt pie TK. Vienīgais, ko teikšu – neierobežojiet dizainera iztēli, ieskicējiet to visvispārīgākajā formā.

Šī daļa mainās atkarībā no tā, kā vēlaties, lai jūsu lapa izskatītos. Varbūt nevajag tik daudz baneru augšpusē, varbūt augšpusē jānorāda kontakti (adrese, tālrunis, fakss), varbūt ikonu veidā “vietnes karte”, “mājas”, “kontakti”. Varbūt jums nav vajadzīgas ziņas kreisajā pusē, bet kreisajā pusē rāda “akcijas un izlaidumi”.

Tagad galvenais ir aprakstīt darba loģiku.

Darbības loģika

Es aprakstīšu, pamatojoties uz iepriekš redzamo attēlu.

Vietnes augšdaļa paliek nemainīga katrā vietnes lapā. Ziņu plūsma ir redzama tikai mājas lapa. Kreisajā pusē esošajās sekundārajās lapās mēs parādām tās preces izvēlnes apakšpunktus, kurā pašlaik atrodamies (piemēram, ja atrodamies lapā "serviss", tad mēs rādām saites uz "garantijas serviss", "pasts". -garantijas serviss"). Attiecīgi šo saišu pārejas ved uz attiecīgajām lapām. Šeit zem apakšvienumiem kreisajā pusē tiek parādīti dati saziņai ar tiešsaistes konsultantiem (Skype, ICQ). Bloķēt reklāmas un izlaidumi paliek katrā lapā. Vietnes kājene tiek rādīta vienādi katrā lapā.

Apmēram tā ir aprakstīta vispārējā darba loģika.

Tagad mēs detalizēti aprakstam katru bloku. Piemēram, "Ziņu plūsma".

"Ziņu plūsma" no 10 Jaunākās ziņas. Katrai ziņai ir jāsastāv no ziņas nosaukuma, publicēšanas datuma, īsa ziņas sākuma (4-5 rindiņas) un saites "lasīt visu". Noklikšķinot uz saites "lasīt pilnībā", mēs nonākam ziņu lapā. Galvenā satura vietā tiek parādītas ziņas, kas tika trāpītas. Tas ietver arī ziņas nosaukumu, publicēšanas datumu. Kreisajā pusē tiek parādīta arī ziņu plūsma. Iepriekšējo mēnešu un gadu ziņas tiek arhivētas. Tas ir, zem pašreizējā mēneša ziņām mēs parādām "arhīvu par (šādu un tādu mēnesi vai gadu)". Noklikšķinot uz saites "arhīvs par (piemēram, mēnesis vai gads)", tiek parādīts atbilstošā mēneša/gada ziņu saraksts.

Šādi mēs aprakstām katra bloka darbību. Neaizmirsīsim par gadījumu ar kalendāru. Un pats galvenais, jums ir nepieciešams krāsot produktu kataloga darbu. Šeit es jums dodu uzdevumu: mēģiniet izdomāt un aprakstīt, kā katalogs darbosies. Nosūtiet savas iespējas pa e-pastu. Mēs publicēsim labāko.

Kam vēl vajadzētu būt? Būtu jauki norādīt saderību.

Saderība

Šajā punktā mēs norādām, kuras operētājsistēmas un kurās pārlūkprogrammās vietnei vajadzētu izskatīties vienlīdz labi. Kādā variantā, kādā valodā jāraksta. Kāda CMS tiek izmantota. Ir vērts norādīt, ja jūs patiešām saprotat, par ko jūs runājat.

Ja jums nav šo jautājumu, vienkārši norādiet pārlūkprogrammas, kurās vietne ir jāparāda pareizi. Pārējā gadījumā paļaujieties uz izpildītāja sirdsapziņu.

Secinājums

Šajā rakstā es nemēģināju parādīt, ka TK ir sastādīts šādi un nekas cits. Dariet to, un jums nebūs problēmu. Kvalitatīva TOR sastādīšana vairāk ir pieredzes jautājums. Pirmajā pārī ne visiem izdosies sastādīt kompetentu TK.

Šajā rakstā es gribēju parādīt principus, pēc kuriem tiek veidots darba uzdevums, galvenos punktus, kuriem ir vērts pievērst uzmanību. Cik man tas izdevās, es ceru mācīties no jūsu komentāriem.

Un neaizmirstiet izaicinājumu!

Man bieži jautā: "Kā izstrādāt tehnisko uzdevumu automatizētai sistēmai?". Līdzīga tēma tiek pastāvīgi apspriesta dažādos forumos. Šis jautājums ir tik plašs, ka uz to nav iespējams atbildēt īsumā. Tāpēc es nolēmu uzrakstīt garu rakstu par šo tēmu.

• Pirmajā daļā " Tehnisko specifikāciju izstrāde. Kas tas ir, kāpēc tas ir vajadzīgs, ar ko sākt un kā tam vajadzētu izskatīties? Mēģināšu detalizēti atbildēt uz tēmas jautājumiem, apsvēršu Darba uzdevuma struktūru un mērķi, kā arī sniegšu dažus ieteikumus prasību formulēšanā.
• Otrā daļa" Tehnisko specifikāciju izstrāde. Kā formulēt prasības? tiks pilnībā veltīts prasību noteikšanai un formulēšanai informācijas sistēma.

Vispirms jums ir jāizdomā, kāds jautājums patiešām interesē tos, kuri jautā: "Kā izstrādāt tehnisko uzdevumu?" Fakts ir tāds, ka pieeja tehnisko specifikāciju izstrādei būs ļoti atkarīga no mērķiem, kādiem tas tiek darīts, kā arī no tā, kas to izmantos. Par kādiem variantiem es runāju?

• Komerciālā organizācija nolēma ieviest automatizētu sistēmu. Tam nav sava IT servisa, un tā nolēma darīt: Ieinteresētajai personai ir jāizstrādā Nolikums un jānodod izstrādei trešās puses organizācijai;
• Komerciālā organizācija nolēma ieviest automatizētu sistēmu. Tam ir savs IT pakalpojums. Mēs nolēmām to darīt: izstrādāt Nolikumu, pēc tam saskaņot to starp IT dienestu un ieinteresētajām pusēm un ieviest to pašu spēkiem;
• Valsts struktūra nolēma uzsākt IT projektu. Šeit viss ir tik dubļains, daudz formalitāšu, atsitienu, griezumu utt.. Šajā rakstā šo variantu neizskatīšu.

• IT uzņēmums nodarbojas ar automatizētu sistēmu izstrādes un/vai ieviešanas pakalpojumiem. Šis ir visgrūtākais gadījums, jo jums ir jāstrādā dažādos apstākļos:

  • Klientam ir savi speciālisti ar saviem uzskatiem, un viņiem ir noteiktas specifiskas prasības Darba uzdevumam;
  • Darba uzdevumi ir izstrādāti mūsu pašu izstrādātājiem (klientam vienalga);
  • Darba uzdevums ir izstrādāts nodošanai darbuzņēmējam (t.i. programmētāju grupai, kas ir ārpus uzņēmuma personāla, vai individuālam speciālistam);
  • Starp uzņēmumiem un klientu rodas nesaprašanās par iegūto rezultātu, un uzņēmums atkal un atkal uzdod jautājumu: “Kā būtu jāizstrādā darba uzdevums?”. Pēdējais gadījums var šķist paradokss, taču tā ir taisnība.
  • Iespējamas arī citas, mazāk izplatītas iespējas;

Es domāju, ka tagad lasītājam vajadzētu uzdot jautājumus:

• Kāpēc darba uzdevumu nevar vienmēr izstrādāt vienādi?;
• Vai ir kādi standarti, metodes, ieteikumi? Kur tās dabūt?
• Kam būtu jāizstrādā darba uzdevumi? Vai šai personai ir jābūt īpašām zināšanām?
• Kā saprast, vai darba uzdevums ir labi uzrakstīts vai nē?
• Uz kā rēķina tas jāattīsta, un vai tas vispār ir vajadzīgs?

Šis saraksts varētu būt bezgalīgs. Es runāju tik pārliecinoši, jo 15 gadus nodarbojos ar profesionālas programmatūras izstrādi, un jautājums par darba uzdevumiem parādās jebkurā izstrādes komandā, ar kuru man ir jāsadarbojas. Iemesli tam ir dažādi. Paceļot tēmu par Darba uzdevuma izstrādi, labi apzinos, ka nevarēšu to 100% pasniegt visiem tēmas interesentiem. Bet, es mēģināšu, kā saka, "salikt visu pa plauktiņiem". Tie, kas jau ir iepazinušies ar maniem rakstiem, zina, ka es neizmantoju citu cilvēku darbu "copy-paste", nepārdruku citu cilvēku grāmatas, necitēju vairāku lappušu standartus un citus dokumentus, kurus jūs pats varat atrast internetā, nododot tās savām izcilajām domām. Pietiek meklētājā ierakstīt "Kā izstrādāt darba uzdevumu" un jūs varēsiet izlasīt daudz interesanta, bet, diemžēl, atkārtota daudzas reizes. Parasti tie, kam patīk būt gudriem forumos (galu galā mēģiniet meklēt!), paši nekad nav izstrādājuši saprātīgus darba uzdevumus un pastāvīgi citē GOST ieteikumus šajā jautājumā. Un tiem, kas patiešām nopietni nodarbojas ar šo jautājumu, parasti nav laika sēdēt forumos. Starp citu, mēs arī runāsim par GOST. Sava darba gadu laikā esmu redzējis daudzus tehniskās dokumentācijas variantus, ko sastādījuši gan individuāli speciālisti, gan izcilas komandas un konsultāciju uzņēmumi. Reizēm nodarbojos arī ar šādām aktivitātēm: atvēlu laiku sev un meklēju informāciju par sev interesējošo tēmu no neparastiem avotiem (tāda maza inteliģence). Rezultātā man bija jāredz dokumentācija par tādiem monstriem kā Gazprom, Krievijas dzelzceļš un daudziem citiem interesantiem uzņēmumiem. Protams, ievēroju konfidencialitātes politiku, neskatoties uz to, ka šie dokumenti pie manis nonāk no publiskiem avotiem vai konsultantu bezatbildības (tie izkaisa informāciju pa internetu). Tāpēc uzreiz saku: es nedalos ar konfidenciālu informāciju, kas pieder citiem uzņēmumiem, neatkarīgi no rašanās avotiem (profesionālā ētika).

Kas ir tehniskais uzdevums?

Pirmā lieta, ko mēs tagad darīsim, ir noskaidrot, kāda veida dzīvnieks tas ir, “Uzdevumu noteikumi”.

Jā, tiešām ir GOST un standarti, kuros tiek mēģināts regulēt šo darbības daļu (programmatūras izstrāde). Kādreiz visi šie GOST bija aktuāli un aktīvi izmantoti. Tagad ir dažādi viedokļi par šo dokumentu atbilstību. Daži apgalvo, ka GOST izstrādāja ļoti tālredzīgi cilvēki un tie joprojām ir aktuāli. Citi saka, ka tie ir bezcerīgi novecojuši. Varbūt kāds tagad domāja, ka patiesība ir kaut kur pa vidu. Es atbildētu ar Gētes vārdiem: “Saka, ka starp diviem pretējiem viedokļiem slēpjas patiesība. Nekādā gadījumā! Starp viņiem ir problēma." Tātad starp šiem viedokļiem nav patiesības. Jo GOST neatklāj mūsdienu attīstības praktiskās problēmas, un tie, kas tos kritizē, nepiedāvā alternatīvas (specifiskas un sistēmiskas).

Ņemiet vērā, ka GOST nepārprotami pat nedod definīciju, tikai saka: “AES TOR ir galvenais dokuments, kas nosaka prasības un procedūru automatizētas sistēmas izveidošanai (izstrādei vai modernizācijai - turpmākai izveidei), saskaņā ar ar kuru tiek veikta AES attīstība un pieņemšana ekspluatācijā."

Ja kādam rodas jautājums, par kādiem GOST es runāju, tad šeit tie ir:

• GOST 2.114-95 Vienota sistēma projektēšanas dokumentācijai. Specifikācijas;
• GOST 19.201-78 Vienota programmu dokumentācijas sistēma. Tehniskais uzdevums. Prasības saturam un dizainam;
• GOST 34.602-89 Informācijas tehnoloģijas. Standartu komplekts automatizētām sistēmām. Darba uzdevumi automatizētas sistēmas izveidei.

Vikipēdijā ir sniegta daudz labāka definīcija (patiesība par TK kopumā, un ne tikai programmatūrai): " Tehniskais uzdevums ir dizaina dokumenta oriģināls tehnisks objektu. Tehniskais uzdevums nosaka izstrādājamā objekta galveno mērķi, tā tehniskos un taktiskos un tehniskos raksturojumus, kvalitātes rādītājus un tehniskās un ekonomiskās prasības, norādījumus nepieciešamo dokumentācijas (dizaina, tehnoloģiskā, programmatūras u.c.) veidošanas posmu pabeigšanai un tās sastāvu, kā kā arī īpašas prasības. Uzdevums kā avota dokuments kaut kā jauna radīšanai pastāv visās darbības jomās, kas atšķiras pēc nosaukuma, satura, izpildes secības utt. (piemēram, projektēšanas uzdevums būvniecībā, kaujas uzdevums, mājasdarbs, līgums par literārs darbs utt.). e.)"

Un tātad, kā izriet no definīcijas, darba uzdevuma galvenais mērķis ir formulēt prasības izstrādājamajam objektam, mūsu gadījumā – automatizētai sistēmai.

Tas ir galvenais, bet vienīgais. Laiks uzņemties pašu galveno: visu salikt "pa plauktiņiem", kā solīts.

Kas jums jāzina par prasībām? Ir skaidri jāsaprot, ka visas prasības ir jāsadala pēc veida un īpašībām. Tagad mēs uzzināsim, kā to izdarīt. Lai atdalītu prasības pēc veida, GOST mums vienkārši palīdzēs. Tur sniegtais prasību veidu saraksts ir labs piemērs tam, kāda veida prasības būtu jāņem vērā. Piemēram:

• funkcionalitātes prasības;
• Prasības drošībai un piekļuves tiesībām;
• Prasības personāla kvalifikācijai;
• …. utt. Par tiem varat izlasīt minētajā GOST (un tālāk es tos apskatīšu arī nedaudz sīkāk).

Es domāju, ka jums ir skaidrs, ka labi formulētas funkcionalitātes prasības ir veiksmīgas darba uzdevuma atslēgas. Tieši šīs prasības ir veltītas lielākajai daļai darbu un metožu, par kuriem es runāju. Funkcionalitātes prasības ir 90% no darba uzdevuma izstrādes sarežģītības. Viss pārējais bieži vien ir "maskēšanās", kas tiek likts uz šīm prasībām. Ja prasības formulētas slikti, tad lai arī kādu skaistu kamuflāžu uzliktu, veiksmīgs projekts nedarbosies. Jā, formāli visas prasības būs izpildītas (saskaņā ar GOST J), TOR ir izstrādāts, apstiprināts un parakstīts, par to ir saņemta nauda. Nu ko? Un tad sākas jautrība: ko darīt? Ja tas ir projekts par Valsts pasūtījumu, tad nekādu problēmu nav - ir tāds budžets, ka nevienā kabatā neietilps, viss noskaidrosies realizācijas procesā (ja tāds būs). Tieši tādā veidā tiek izzāģēta lielākā daļa projektu uz valsts pasūtījuma budžetu (izdedzināja “TK”, apvienoja desmitus miljonus, bet nesāka projektu. Visas formalitātes tika nokārtotas, vainīgo nebija, jauns auto pie mājas. Skaistums!). Bet mēs runājam par komercorganizācijām, kur tiek skaitīta nauda, ​​un rezultāts ir cits. Tāpēc tiksim galā ar galveno, kā attīstīties noderīgi un funkcionējoši darba uzdevumi.

Es teicu par prasību veidiem, bet kā ar īpašumiem? Ja prasību veidi var būt dažādi (atkarībā no projekta mērķiem), tad ar īpašībām viss ir vienkāršāk, ir 3 no tiem:

1. Prasībai jābūt saprotams;
2. Prasībai jābūt betons;
3. Prasībai jābūt pārbaudīts;

Turklāt pēdējais īpašums nav iespējams bez diviem iepriekšējiem, t.i. ir sava veida "lakmusa papīrs". Ja prasības rezultātu nevar pārbaudīt, tad tas vai nu nav skaidrs, vai nav konkrēts. Padomā par to. Šīs trīs prasību īpašības ir prasmes un profesionalitāte. Patiesībā viss ir ļoti vienkārši. Kad tu to izdomāsi.

Šo stāstu par to, kas ir darba uzdevums, varētu pabeigt un pāriet uz galveno: kā formulēt prasības. Bet tas viss nav tik ātri. Ir vēl viens ārkārtīgi svarīgs punkts:

• kādā valodā (izpratnes sarežģītības ziņā) jāraksta darba uzdevums?
• Vai tajā jāapraksta dažādu funkciju specifikācija, algoritmi, datu tipi un citas tehniskas lietas?
• Un kas ir tehniskais dizains, kas, starp citu, ir minēts arī GOST, un kā tas ir saistīts ar darba uzdevumu?

Atbildēs uz šiem jautājumiem ir kāda ļoti mānīga lieta. Tāpēc bieži rodas strīdi par nepieciešamo prasību detalizācijas pietiekamību vai neesamību, par dokumenta saprotamību no Pasūtītāja un Izpildītāju puses, par dublēšanos, prezentācijas formātu utt. Un kur ir robeža starp darba uzdevumu un tehnisko projektu?

Tehniskais uzdevums ir uz prasībām balstīts dokuments, kas formulēts Klientam saprotamā (parastā, pazīstamā) valodā. Šajā gadījumā var un vajag lietot Pasūtītājam saprotamu nozares terminoloģiju. Tehniskās realizācijas īpatnībām nevajadzētu būt nekādiem ierobežojumiem. Tie. TK stadijā principā nav nozīmes, kurā platformā šīs prasības tiks ieviestas. Lai gan ir izņēmumi. Ja mēs runājam par sistēmas ieviešanu, kuras pamatā ir esošs programmatūras produkts, tad šāda saistīšana var notikt, bet tikai ekrāna formu, atskaites formu utt. biznesa analītiķis. Un noteikti ne programmētājs (ja vien viņš šīs lomas neapvieno, tas notiek). Tie. šai personai jārunā ar Klientu viņa biznesa valodā.

Tehniskais projekts ir dokuments, kas paredzēts Darba uzdevumā formulēto prasību tehniskai īstenošanai. Tikai šajā dokumentā ir aprakstītas datu struktūras, trigeri un saglabātās procedūras, algoritmi un citas lietas, kas būs nepieciešamas tehniskie speciālisti. Pasūtītājam vispār nav nepieciešams tajā iedziļināties (viņš var nesaprast šādus terminus). To dara tehniskais projekts Sistēmas arhitekts(Šeit šīs lomas kombinācija ar programmētāju ir diezgan normāla). Precīzāk sakot, AO speciālistu grupa arhitekta vadībā. Jo lielāks projekts, jo vairāk cilvēku strādā pie darba uzdevuma.

Kas mums ir praksē? Smieklīgi skatīties, kad direktoru virza apstiprināšanai nolikumā, kas ir pārpildīts ar tehnisko terminoloģiju, datu tipu un to vērtību aprakstiem, datu bāzes struktūru utt. Viņš, protams, cenšas saprast, jo tas ir nepieciešams apgalvot, cenšoties starp rindām atrast pazīstamus vārdus un nepazaudēt ķēdes biznesa prasības. Kas, pazīstama situācija? Un kā tas beidzas? Parasti šādi TOR tiek apstiprināti, pēc tam ieviesti, un 80% gadījumu tad tas nemaz neatbilst veiktā darba faktam, jo daudzas lietas viņi nolēma mainīt, pārtaisīt, pārpratuši, nepareizi domājuši utt. utt. Un tad sākas nodošanas sērija. “Bet šeit tas nav tā, kā mums tas ir vajadzīgs”, bet “tas mums nederēs”, “tas ir pārāk sarežģīti”, “tas ir neērti” utt. Pazīstams?! Tāpēc es zinu, ka man vajadzēja savlaicīgi aizpildīt izciļņus.

Tātad, kas mums ir praksē? Bet praksē mums ir neskaidra robeža starp darba uzdevumu un tehnisko projektu. Tas dažādos veidos peld starp TK un TP. Un tas ir slikti. Un tā izrādās tāpēc, ka attīstības kultūra ir kļuvusi vāja. Daļēji tas ir saistīts ar speciālistu kompetenci, daļēji ar vēlmi samazināt budžetu un termiņus (galu galā dokumentācija aizņem daudz laika - tas ir fakts). Ir vēl viens būtisks faktors, kas ietekmē Tehniskā projekta kā atsevišķa dokumenta izmantošanu: ātrās izstrādes rīku, kā arī izstrādes metodoloģiju strauja attīstība. Bet tas ir atsevišķs stāsts, par to es teikšu dažus vārdus zemāk.

Vēl viens mazs, bet svarīgs punkts. Dažkārt Darba uzdevums tiek saukts par nelielu prasību daļu, vienkāršu un saprotamu. Piemēram, lai precizētu objekta meklēšanu saskaņā ar dažiem nosacījumiem, pievienojiet atskaitei kolonnu utt. Šāda pieeja ir diezgan pamatota, kāpēc sarežģīt dzīvi. Bet to izmanto nevis lielos projektos, bet gan nelielos uzlabojumos. Es teiktu, ka tas ir tuvāk programmatūras produkta uzturēšanai. Šajā gadījumā Darba uzdevumā var aprakstīt arī konkrētu tehnisko risinājumu prasības īstenošanai. Piemēram, “Veikt tādas un tādas izmaiņas algoritmā”, norādot konkrētu procedūru un konkrētas izmaiņas programmētājam. Tas ir gadījums, kad robeža starp nolikumu un tehniskajiem projektiem ir pilnībā dzēsta, jo nav ekonomiskas iespējas uzpūst papīrus tur, kur tas nav vajadzīgs, un tiek izveidots noderīgs dokuments. Un tas ir pareizi.

Vai jums tiešām ir nepieciešama tehniskā specifikācija? Kā ar inženierprojektu?

Vai esmu pārkarsusi? Vai tas vispār ir iespējams bez darba uzdevums? Iedomājieties varbūt (precīzāk, tas notiek), un šai pieejai ir daudz sekotāju, un to skaits pieaug. Parasti pēc jauno speciālistu lasīšanas grāmatas par Scrum, Agile un citām straujas attīstības tehnoloģijām. Patiesībā šīs ir brīnišķīgas tehnoloģijas, un tās darbojas, tikai tās burtiski nesaka "nav nepieciešams veikt tehniskus uzdevumus". Saka “papīru minimums”, īpaši nevajadzīgi, tuvāk Klientam, konkrētāk un ātrāki rezultāti. Bet neviens prasību fiksēšanu neatcēla, un tur tas ir skaidri pateikts. Tieši tur prasības tiek noteiktas, pamatojoties uz trim brīnišķīgajām īpašībām, par kurām es runāju iepriekš. Vienkārši dažu cilvēku apziņa ir sakārtota tā, ka, ja kaut ko var vienkāršot, tad vienkāršosim līdz pilnīgai prombūtnei. Kā teica Einšteins " Padariet to pēc iespējas vienkāršāku, bet ne vienkāršāku." . Zelta vārdi iet kopā ar visu. Tā ka Tehniskais uzdevums nepieciešams, pretējā gadījumā jūs neredzēsit veiksmīgu projektu. Cits jautājums, kā sacerēt un ko tur iekļaut. Ņemot vērā straujo metodoloģiju attīstību, jums jākoncentrējas tikai uz prasībām, un visu “maskēšanu” var atmest. Būtībā es tam piekrītu.

Kā ar tehnisko projektu? Šis dokuments ir ļoti noderīgs un nav zaudējis savu aktualitāti. Turklāt bieži vien bez tā vienkārši nav iespējams iztikt. It īpaši, ja runa ir par ārpakalpojumu izstrādes darbu, t.i. pēc ārpakalpojuma principa. Ja tas netiks izdarīts, pastāv risks uzzināt daudz par to, kā sistēmai, kuru jūs domājat, vajadzētu izskatīties. Vai klientam viņš ir jāiepazīst? Ja viņš grib, kāpēc ne, bet nevajag uzstāt un apstiprināt šo dokumentu, tas tikai atturēs un traucēs strādāt. Ir gandrīz neiespējami izveidot sistēmu līdz mazākajai detaļai. Šajā gadījumā jums būs nepārtraukti jāveic izmaiņas Tehniskajā projektā, kas aizņem daudz laika. Un, ja organizācija ir stipri birokratizēta, tad vispār atstāj visus nervus. Tieši šāda dizaina samazināšana tiek apspriesta mūsdienu straujās attīstības metodoloģijās, par kurām minēju iepriekš. Starp citu, tie visi ir balstīti uz klasisko XP (extreme programming) pieeju, kas jau ir aptuveni 20 gadus veca. Tāpēc sastādiet kvalitatīvu, Pasūtītājam saprotamu Nolikumu un izmantojiet Tehnisko projektu kā iekšējo dokumentu sistēmas arhitekta un programmētāju attiecībām.

Interesanta detaļa par tehnisko dizainu: daži izstrādes rīki, kas sakārtoti pēc priekšmetu orientācijas principa (piemēram, 1C un tamlīdzīgi), liecina, ka projektēšana (ar to domāta dokumentācijas process) ir nepieciešama tikai patiešām sarežģītās jomās, kur nepieciešama mijiedarbība starp veselām apakšsistēmām. Vienkāršākajā gadījumā, piemēram, lai izveidotu uzziņu grāmatu, dokumentu, pietiek tikai ar pareizi formulētām biznesa prasībām. Par to liecina šīs platformas biznesa stratēģija speciālistu sagatavošanas ziņā. Ja paskatās Eksāmena biļete speciālists (tā viņu sauc, nevis “programmētājs”), tad redzēsi, ka ir tikai biznesa prasības, un kā tās ieviest programmēšanas valodā ir speciālista uzdevums. Tie. tā uzdevuma daļa, kuras risināšanai paredzēts Tehniskais projekts, speciālistam ir jāatrisina “galvā” (runājam par vidējas sarežģītības uzdevumiem), un šeit un tagad, ievērojot noteiktus izstrādes un projektēšanas standartus, kas atkal ir izveidojis uzņēmums 1C savai platformai. Tādējādi no diviem speciālistiem, kuru darba rezultāts izskatās vienāds, viens var nokārtot eksāmenu, bet otrs nevar, jo. rupji pārkāpti attīstības standarti. Tas ir, acīmredzot tiek pieņemts, ka speciālistiem ir jābūt tādai kvalifikācijai, lai viņi paši varētu izstrādāt tipiskus uzdevumus, neiesaistot sistēmu arhitektus. Un šī pieeja darbojas.

Turpināsim jautājuma izpēti: "Kādas prasības jāiekļauj darba uzdevumā?"

Prasību formulēšana informācijas sistēmai. Darba uzdevuma struktūra

Uzreiz liksim skaidrībā: runāsim par informācijas sistēmas prasību formulēšanu, t.i. pieņemot, ka biznesa prasību izstrādes, biznesa procesu formalizēšanas un visi iepriekšējie konsultāciju darbi jau ir pabeigti. Protams, šajā posmā var veikt dažus uzlabojumus, bet tikai precizējumus. Pats automatizācijas projekts neatrisina biznesa problēmu — paturiet to prātā. Šī ir aksioma. Nez kāpēc daži vadītāji mēģina to atspēkot, uzskatot, ka, ja viņi nopirks programmu, tad kārtība iestāsies haotiskā biznesā. Bet galu galā aksioma ir aksioma, kurai nav nepieciešami pierādījumi.

Tāpat kā jebkuras darbības gadījumā, prasību formulēšanu var (un vajadzētu) iedalīt posmos. Visam savs laiks. Tas ir smags intelektuāls darbs. Un, ja pret to izturēsies ar nepietiekamu uzmanību, tad rezultāts būs atbilstošs. Pēc ekspertu aplēsēm, darba uzdevuma izstrādes izmaksas var būt 30-50%. Es esmu tādās pašās domās. Lai gan 50 varbūt ir par daudz. Galu galā darba uzdevums nav pēdējais dokuments, kas jāizstrādā. Galu galā ir jābūt arī tehniskajam projektam. Šīs atšķirības ir saistītas ar dažādām automatizācijas platformām, pieejām un tehnoloģijām, ko projektu komandas izmanto izstrādes laikā. Piemēram, ja mēs runājam par attīstību tādā klasiskā valodā kā C ++, tad bez detalizētas tehniskais projektsšeit nepietiek. Ja mēs runājam par sistēmas ieviešanu 1C platformā, tad situācija ar dizainu ir nedaudz atšķirīga, kā mēs redzējām iepriekš (lai gan, izstrādājot sistēmu no nulles, tā ir izstrādāta saskaņā ar klasisko shēmu).

Lai gan prasību formulēšana ir galvenā daļa darba uzdevums, un dažos gadījumos tā kļūst par vienīgo noteikumu sadaļu, jums vajadzētu pievērst uzmanību tam, ka šis ir svarīgs dokuments, un tas ir attiecīgi jāsagatavo. Kur sākt? Pirmkārt, jums jāsāk ar saturu. Izveidojiet saturu un pēc tam sāciet to atritināt. Personīgi es daru tā: vispirms izklāstu saturu, aprakstu mērķus, visu ievadinformāciju, un tad uzņemos galveno daļu - prasību formulēšanu. Kāpēc ne otrādi? Nezinu, man tā ir ērtāk. Pirmkārt, šī ir daudz mazāka laika daļa (salīdzinot ar prasībām), otrkārt, aprakstot visu ievadinformāciju, jūs noskaņojaties uz galveno. Nu kam patīk. Laika gaitā jūs izstrādāsit savu darba uzdevuma veidni. Sākumā es iesaku ņemt par saturu tieši to, kas aprakstīts GOST. Tas ir lieliski piemērots saturam! Pēc tam mēs ņemam un sākam aprakstīt katru sadaļu, neaizmirstot ieteikumus par šādām trim īpašībām: saprotamība, specifiskums un pārbaudāmība. Kāpēc es to tik ļoti uzstāju? Vairāk par to nākamajā sadaļā. Un tagad es ierosinu ar visu taktiku iziet cauri tiem TK punktiem, kas ir ieteikti GOST.

1. Galvenā informācija;
2. sistēmas izveides (attīstīšanas) mērķis un mērķi;
3. automatizācijas objektu raksturojums;
4. Sistēmas prasības;
5. sistēmas izveides darba sastāvs un saturs;
6. sistēmas kontroles un pieņemšanas kārtība;
7. prasības darba sastāvam un saturam, lai sagatavotu automatizācijas objektu sistēmas nodošanai ekspluatācijā;
8. Dokumentācijas prasības;
9. Attīstības avoti.

Kopā, 9 sadaļas, no kurām katra arī sadalīta apakšsadaļās. Paņemsim tos kārtībā. Ērtības labad katrai precei visu izklāstīšu tabulas veidā.

1. sadaļa. Vispārīga informācija.

Ieteikumi saskaņā ar GOST
Sistēmas un tās simbola pilns nosaukums;	Šeit viss ir skaidrs: mēs rakstām, kā sistēma tiks saukta, tās īsais nosaukums
līguma šifrs vai šifrs (numurs);	Tas nav būtiski, bet vajadzības gadījumā varat norādīt.
sistēmas izstrādātāja un pasūtītāja (lietotāja) uzņēmumu (asociāciju) nosaukums un rekvizīti;	norādiet, kas (kādas organizācijas) strādās pie projekta. Varat arī norādīt viņu lomas.Šo sadaļu var izdzēst pavisam (diezgan formāli).
dokumentu saraksts, kuru pamatā ir sistēma, kuru un kad šie dokumenti tika apstiprināti;	Noderīga informācija. Šeit jānorāda normatīvā un atsauces dokumentācija, kas jums tika sniegta, lai iepazītos ar noteiktu prasību daļu
plānotie datumi, lai sāktu un pabeigtu darbu pie sistēmas izveidošanas;	Laika vēlmes. Dažreiz viņi par to raksta TOR, bet biežāk šādas lietas ir aprakstītas darba līgumos
informācija par darba finansēšanas avotiem un procedūru;	Līdzīgi, tāpat kā iepriekšējā rindkopā par laiku. Vairāk atbilstoši valdības rīkojumiem (valsts darbiniekiem)
kārtība, kādā tiek formalizēti un iesniegti klientam darba rezultāti pie sistēmas (tās daļu) izveides, atsevišķu līdzekļu (aparatūras, programmatūras, informācijas) un programmatūras un aparatūras (programmatūras un metodisko) kompleksu izgatavošanas un regulēšanas. sistēma.	Es neredzu vajadzību šim punktam, tk. prasības dokumentācijai tiek veidotas atsevišķi, un papildus tam ir vesela atsevišķa sistēmas sadaļa "Kontroles un pieņemšanas kārtība".

2. sadaļa. Sistēmas radīšanas (attīstības) mērķi un mērķi.

Ieteikumi saskaņā ar GOST	Ko ar to darīt praksē
Sistēmas mērķis	No vienas puses, tikšanās ir vienkārša. Bet es gribētu būt precīzs. Ja rakstāt kaut ko līdzīgu “augstas kvalitātes noliktavas uzskaites automatizācija uzņēmumā X”, tad pēc tā pabeigšanas rezultātu var apspriest ilgi, pat neskatoties uz prasību labo formulējumu. Jo Klients vienmēr var teikt, ka viņš pēc kvalitātes domāja kaut ko citu. Kopumā nervi var daudz sabojāt viens otru, bet kāpēc? Labāk uzreiz rakstīt apmēram šādi: "Sistēma ir izstrādāta, lai uzņēmumā X uzturētu noliktavas uzskaiti saskaņā ar prasībām, kas noteiktas šajā darba uzdevumā."
Sistēmas izveides mērķi	Mērķi noteikti ir svarīga sadaļa. Ja mēs to ieslēdzam, tad mums jāspēj formulēt šos mērķus. Ja jums ir grūtības ar mērķu formulēšanu, tad labāk ir pilnībā izslēgt šo sadaļu. Neveiksmīga mērķa piemērs: "Pārliecinieties, ka vadītājs veic ātru dokumentu." Kas ir ātrs? Pēc tam to var pierādīt bezgalīgi. Ja tas ir svarīgi, tad labāk ir pārformulēt šo mērķi šādi: "Pārdošanas menedžerim jāspēj izsniegt dokumentu" Preču pārdošana "100 rindiņas 10 minūtēs." Šāds mērķis var parādīties, ja, piemēram, vadītājs šobrīd tam velta aptuveni stundu, kas šim uzņēmumam ir par daudz un viņam tas ir svarīgi. Šajā formulējumā mērķis jau krustojas ar prasībām, kas ir diezgan dabiski, jo. Paplašinot mērķu koku (t.i., sadalot tos mazākos saistītos mērķos), mēs jau vērsīsimies prasībām. Tāpēc jums nevajadzētu aizvest prom.

Kopumā spēja noteikt mērķus, formulēt tos, veidot mērķu koku ir pilnīgi atsevišķa tēma. Atcerieties galveno: ja jūs zināt, kā - rakstiet, ja neesat pārliecināts - vispār nerakstiet. Kas notiek, ja nenosakāt mērķus? Jūs strādāsit atbilstoši prasībām, tas bieži tiek praktizēts.

3. sadaļa. Automatizācijas objektu raksturlielumi.

4. iedaļa Sistēmas prasības

Gost deciphers šādu prasību saraksts:

• prasības sistēmas struktūrai un darbībai;
• prasības sistēmas personāla skaitam un kvalifikācijai un tās darba režīmam;
• galamērķa rādītāji;
• uzticamības prasības;
• drošības prasības;
• ergonomikas un tehniskās estētikas prasības;
• pārvietojamības prasības mobilajām ierīcēm AS;
• prasības sistēmas komponentu darbībai, apkopei, remontam un uzglabāšanai;
• prasības informācijas aizsardzībai pret nesankcionētu piekļuvi;
• prasības informācijas drošībai negadījumu gadījumā;
• prasības aizsardzībai no ārējās ietekmes ietekmes;
• Prasības patentu tīrībai;
• standartizācijas un unifikācijas prasības;

Neskatoties uz to, ka galvenā, protams, būs sadaļa ar īpašām prasībām (funkcionāla), šajā sadaļā var būt arī liela nozīme (un vairumā gadījumu tā arī ir). Kas var būt svarīgs un noderīgs:

• Kvalifikācijas prasības. Iespējams, ka izstrādātajai sistēmai būs nepieciešama speciālistu pārkvalifikācija. Tie var būt gan nākotnes sistēmas lietotāji, gan IT speciālisti, kas būs nepieciešami tās atbalstam. Nepietiekama uzmanība šim jautājumam bieži attīstās par problēmām. Ja esošo personāla kvalifikācija ir nepārprotami nepietiekama, labāk ir izrakstīt prasības apmācību organizēšana, apmācību programma, termiņi utt.
• Prasības informācijas aizsardzībai no neatļautas piekļuves.Šeit nav komentāru. Tieši tās ir prasības piekļuves kontrolei datiem. Ja šādas prasības ir plānotas, tad tās ir jāraksta atsevišķi, pēc iespējas detalizētāk pēc tādiem pašiem noteikumiem kā funkcionālās prasības (saprotamība, konkrētība, pārbaudāmība). Tāpēc šīs prasības var iekļaut sadaļā ar funkcionālām prasībām.
• standartizācijas prasības. Ja ir kādi izstrādes standarti, kas ir attiecināmi uz projektu, tos var iekļaut prasībās. Parasti šādas prasības ierosina Klienta IT dienests. Piemēram, uzņēmumam 1C ir prasības programmas koda izstrādei, interfeisa dizainam utt .;
• Prasības sistēmas uzbūvei un funkcionēšanai.Šeit var aprakstīt prasības sistēmu integrācijai savā starpā, sniegts vispārīgās arhitektūras apraksts. Biežāk integrācijas prasības tiek izdalītas kopumā atsevišķā sadaļā vai pat atsevišķā darba uzdevumā, jo šīs prasības var būt diezgan sarežģītas.

Visas pārējās prasības ir mazāk svarīgas, un tās var izlaist. Manuprāt, tie tikai padara dokumentāciju smagāku un praktiski noder maz. Un ergonomikas prasības ir ļoti grūti aprakstīt vispārīgu prasību veidā, labāk tās pārnest uz funkcionālajām. Piemēram, var formulēt prasību "Iegūt informāciju par preces cenu, nospiežot tikai vienu pogu". Manuprāt, tas joprojām ir tuvāk īpašām funkcionālām prasībām, kaut arī tas attiecas uz ergonomiku. Prasības attiecībā uz funkcijām (uzdevumiem), ko šeit veic sistēma, tā ir pati galvenā un galvenā punkts, kas noteiks panākumus. Pat ja viss pārējais tiek darīts perfekti un šī sadaļa ir "3", tad projekta rezultāts labākajā gadījumā būs "3", vai pat projekts neizdosies. Tie ir tie, par kuriem mēs sīkāk runāsim otrajā rakstā, kas tiks iekļauts adresātu saraksta 5. izdevumā. Tieši līdz šim brīdim ir spēkā "trīs prasību īpašību noteikums", par kuru es runāju. Prasības drošības veidiem

GOST izšķir šādus veidus:

• Matemātiskā
• informatīvs
• Valodas
• Programmatūra
• Tehnisks
• Metroloģisks
• Organizatoriskā
• metodisks
• un citi…

No pirmā acu uzmetiena var šķist, ka šīs prasības nav svarīgas. Tas attiecas uz lielāko daļu projektu. Bet ne vienmēr. Kad aprakstīt šīs prasības:

• Nav pieņemts lēmums par to, kura valodas (vai platformas) attīstība notiks;
• Uz sistēmu attiecas daudzvalodu interfeisa prasības (piemēram, krievu / angļu valoda)
• Sistēmas darbībai ir jāizveido atsevišķa vienība vai jānodarbina jauni darbinieki;
• Lai sistēma darbotos, klientam ir jāveic izmaiņas darba metodēs, un šīs izmaiņas ir jānorāda un jāplāno;
• Tiek uzskatīts, ka integrācija ar kādu aprīkojumu un tai tiek piemērotas prasības (piemēram, sertifikācija, saderība utt.)
• Ir iespējamas citas situācijas, tas viss ir atkarīgs no projekta īpašajiem mērķiem.

5. sadaļa. Sistēmas izveidošanas darba sastāvs un saturs

6. iedaļa. Sistēmas kontroles un pieņemšanas procedūra

Vispārīgās prasības darbu pieņemšanai pa posmiem (iesaistīto uzņēmumu un organizāciju saraksts, vieta un laiks), pieņemšanas dokumentācijas saskaņošanas un apstiprināšanas kārtība; Stingri iesaku uzņemties atbildību par darbu nodošanas un sistēmas pārbaudes kārtību. Tam ir paredzētas pārbaudāmās prasības, taču pat ar pārbaudāmo prasību esamību sistēmas piegādes laikā var nepietikt, ja nav skaidri noteikta darbu pieņemšanas un nodošanas kārtība. Piemēram, kopīgs slazds: sistēma tiek veikta, tā ir pilnībā funkcionāla, bet klients kaut kādu iemeslu dēļ nav gatavs tajā strādāt. Šie iemesli var būt kādi: vienreiz mērķi ir mainījušies, kāds atmest utt. Un viņš saka: "Tā kā mēs vēl nestrādājam jaunajā sistēmā, mēs nevaram būt pārliecināti, ka tā darbojas." Tāpēc iemācieties pareizi noteikt darba posmus, veidus, kā pārbaudīt šo posmu rezultātus. Turklāt šādām metodēm klientam vajadzētu būt skaidrām jau pašā sākumā. Ja tie ir fiksēti darba uzdevuma līmenī, tad vienmēr varat sazināties ar viņiem, ja nepieciešams, un pabeigt darbu ar pārsūtīšanu.

7. sadaļa. Prasības par darba sastāvu un saturu, lai sagatavotu automatizācijas objektu sistēmai darbībai

Var būt kādi citi noteikumi par informāciju, ko pieņem uzņēmums (vai plānots). Piemēram, informācija par līgumu agrāk tika ievadīta teksta rindiņā patvaļīgā formā, bet tagad numurs tiek prasīts atsevišķi, datums atsevišķi utt. Šādu apstākļu var būt daudz. Dažus no tiem var uztvert ar personāla pretestību, tāpēc visus šādus gadījumus labāk reģistrēt datu ievades kārtības prasību līmenī Izmaiņas, kas jāveic automatizācijas objektā

Nosacījumu radīšana automatizācijas objekta funkcionēšanai, pie kuriem tiek garantēta izveidotās sistēmas atbilstība TOR ietvertajām prasībām Jebkādas izmaiņas, kas varētu būt nepieciešamas. Piemēram, uzņēmumam nav vietējais tīkls, novecojusi datoru flote, uz kura sistēma nedarbosies.

Iespējams, ka uz papīra tika apstrādāta kāda nepieciešamā informācija, un tagad tā ir jāievada sistēmā. Ja tas nav izdarīts, tad kāds modulis nedarbosies utt.

Varbūt kaut kas ir vienkāršots, bet tagad tas ir jāņem vērā sīkāk, tāpēc kādam ir jāvāc informācija pēc noteiktiem noteikumiem.

Šis saraksts var būt garš, apskatiet Jūsu projekta konkrēto gadījumu Sistēmas funkcionēšanai nepieciešamo nodaļu un dienestu izveide;

Personāla un personāla apmācības termiņi un procedūras mēs to jau esam apsprieduši jau iepriekš. Varbūt sistēma tiek izstrādāta jaunai struktūrai vai aktivitātes veidam, kas iepriekš nebija. Ja nav piemērota personāla un pat apmācīta, sistēma nedarbosies, neatkarīgi no tā, cik kompetenti tā nav būvēta.

8. iedaļa Dokumentācijas prasības

Apsveriet, kā tiks prezentēti lietotāju rokasgrāmatas.

Varbūt klients ir pieņēmis korporatīvos standartus, tāpēc jums jāsazinās ar viņiem.

Dokumentācijas prasību ignorēšana ļoti bieži rada visnegaidītākās sekas uz projektiem. Piemēram, viss ir izdarīts un viss darbojas. Lietotāji arī zina, kā strādāt. Mēs vispār nerunājām par dokumentāciju un nerunājām. Un pēkšņi, kad darbs tiek nodots, viens no Pasūtītāja augstākajiem vadītājiem, kurš pat nepiedalījās projektā, bet piedalās darbu pieņemšanā, jautā: "Kur ir lietošanas instrukcijas?" Un viņš sāk pārliecināt jūs, ka, domājams, nav jāvienojas par lietotāju rokasgrāmatu pieejamību, šī “pati par sevi”. Un tas arī ir, viņš nevēlas uzņemties jūsu darbu. Uz kuru rēķina jūs izstrādāsit vadlīnijas? Uz šī āķa jau ir iekritušas daudzas komandas.

9. sadaļa Attīstības avoti

Tāpēc labāk atsaukties vienkārši uz aptaujas ziņojumu, galveno personu prasībām.

Tātad, mēs esam izskatījuši visas sadaļas, kuras var iekļaut darba uzdevumā. “Var”, nevis “jābūt” tieši tāpēc, ka jebkurš dokuments ir jāizstrādā, lai sasniegtu rezultātu. Tāpēc, ja jums ir skaidrs, ka kāda atsevišķa sadaļa jūs netuvinās rezultātam, tad jums tas nav vajadzīgs un jums nav jātērē laiks tam.

Bet bez galvenā: funkcionālajām prasībām neviens kompetenti darba uzdevums nav pilnīgs. Gribu atzīmēt, ka praksē ar šādiem Darba uzdevumiem nākas saskarties, un kā! Ir figūriņas, kas spēs atšķaidīt ūdeņus visās sadaļās, aprakstiet Vispārīgās prasības vispārīgi runājot, un dokuments izrādās ļoti smags, un tajā ir daudz gudru vārdu, un tas var patikt pat Klientam (t.i., viņš to apstiprinās). Bet pie tā var nebūt iespējams strādāt, t.i. tam ir maz praktiskas pielietošanas. Vairumā gadījumu šādi dokumenti dzimst, kad ir nepieciešams iegūt daudz naudas tieši darba uzdevumam, turklāt tas jādara ātri un bez iedziļināšanās detaļās. Un īpaši, ja zināms, ka tālāk lietas netiks, vai to darīs pavisam citi cilvēki. Vispār jau tikai budžeta, īpaši valsts, attīstībai.

Otrajā rakstā mēs runāsim tikai par 4. sadaļu “Sistēmas prasības”, un konkrēti formulēsim prasības skaidrības, specifiskuma un pārbaudāmības labad.

Kāpēc prasībām jābūt skaidrām, konkrētām un pārbaudāmām.

Jo prakse rāda: sākumā lielākā daļa tehnisko specifikāciju, ko izstrādā speciālisti, vai nu izrādās nepieprasītas (neatbilst realitātei), vai arī kļūst par problēmu tam, kam tās būtu jāievieš, jo Klients sāk manipulēt ar nekonkrētiem noteikumiem un prasībām. Sniegšu dažus piemērus, ar kādām frāzēm saskāros, pie kā tas noveda, un tad mēģināšu sniegt ieteikumus, kā no šādām problēmām izvairīties.

Vai tā ir pārbaudāma prasība? Šķiet, ka tā ir vienkārša lieta, bet kā to pārbaudīt, ja nav specifikas?

Kā to varētu pārformulēt: "Dokumentā norādītā izmaksu summa jāsadala visām šajā dokumentā norādītajām precēm proporcionāli šo preču pašizmaksai." Tas bija skaidri un konkrēti. Kā pārbaudīt, arī nav grūti.

Ergonomika Programmai vajadzētu būt lietotājam draudzīgam interfeisam.Ja godīgi, man pašam nācās vienreiz parakstīties uz šo formulējumu - tad nebija nekādu problēmu skaitīt. Protams, šādiem formulējumiem nevajadzētu būt. Nav ne specifikas, ne iespēju pārbaudīt šo prasību. Lai gan, protams, saprotami (subjektīvi). Šeit nav iespējams pārformulēt nekādā veidā, ir nepieciešams detalizēti aprakstīt katru “ērtības” elementu, jo Klients uz to uzstāj. Piemēram:

• Rindas dokumentam jāpievieno gan nospiežot pogu "Pievienot", gan nospiežot taustiņus "ievietot", kā arī lietotājam ievadot daļu no nosaukuma;
• Apskatot preču sarakstu, jābūt iespējai meklēt pēc nosaukuma, svītrkoda un izstrādājuma;
• utt.

Piekļuves tiesību diferencēšana Piekļuvei peļņas datiem jābūt pieejamai tikai finanšu direktoram Vai sapratāt? Gandrīz. Tiesa, peļņa ir dažāda, jāprecizē.Konkrēti? Protams, nē. Kā tas izskatās ieviešanā? Ja runājam par bruto peļņu, tad ir jāierobežo piekļuve datiem par pirkuma izmaksām, jo. pretējā gadījumā bruto peļņu ir viegli aprēķināt, jo dati par pārdošanas izmaksām ir zināmi plašam cilvēku lokam. Runājot par piekļuves tiesībām, jums jābūt ļoti uzmanīgiem. Un, ja pārdošanas vadītājus motivē bruto peļņa, tad arī šīs prasības ir pretrunā viena otrai, jo. Vadītāji to nekad nevarēs pārbaudīt. Ja jau iekļaujam šādu prasību, tad ir jānorāda konkrētas atskaites un sistēmas objekti, kuros norādīt, kurai datu daļai jābūt pieejamai noteiktām personu kategorijām. Un izskatīt katru šādu gadījumu atsevišķi Produktivitāte Pārdošanas atskaite jāģenerē 1 minūtē Jā, es saprotu. Un ir pat noteikts laika ierobežojums: 1 minūte. Bet nav zināms, kāda veida detalizācija ir paredzēta šajā gadījumā: katrai precei, preču grupām, klientiem vai kaut kam citam?vairāk par 1 minūti, ar nosacījumu, ka preču skaits atlasē nepārsniedz 5000 rindiņas.

Es ceru, ka ideja ir skaidra. Ja ir konkrēti jautājumi, rakstiet, centīšos palīdzēt.

Uz darba uzdevums Bija vairāk specifiku, ir daudz ieteikumu. Ir pat vārdu saraksts, kurus nav ieteicams izmantot darba uzdevumā. K. Vigers par šo interesanti raksta savā grāmatā “Programmatūras prasību izstrāde”. Šeit ir visinteresantākie un vienkāršākie, manuprāt, ieteikumi:

• Nelietojiet vārdus, kuriem ir daudz sinonīmu. Vajadzības gadījumā labāk ir skaidri sniegt terminu definīciju darba uzdevumu noteikumu un definīciju sadaļā.
• Jums jācenšas nelietot garus teikumus;
• Ja prasība jums šķiet pārāk vispārīga, tai jābūt detalizētai mazākām, bet īpašām prasībām;
• Izmantojiet vairāk diagrammu, grafikus, tabulas, zīmējumus - šādā veidā informācija tiek uztverta daudz vieglāk;
• Jāizvairās no šādiem vārdiem: “efektīvi”, “atbilstoši”, “vienkārši”, “saprotams”, “ātrs”, “elastīgs”, “uzlabots”, “optimāls”, “caurspīdīgs”, “ilgtspējīgs”, “pietiekams”, “pietiekams” , “Draudzīgs”, “viegli” utt. Sarakstu var turpināt, bet es domāju, ka ideja ir skaidra (mēģiniet to turpināt pats).

Viss, kas ir uzrakstīts iepriekš, ir svarīga informācija, bet ne vissvarīgākā. Kā jūs atceraties, raksta sākumā es to saucu par terminu “maskēšanās”, jo. Vissvarīgākais, kas veidos vismaz 90% laika un sarežģītības, strādājot pie dokumenta, ir prasību identificēšana un formulēšana. Un informācijai par prasībām joprojām jāspēj savākt, strukturēt un formulēt. Starp citu, tas ir daudz kopīgs starp uzņēmumu apsekojumu un turpmāko biznesa procesu aprakstu. Bet ir arī svarīgas atšķirības. Viena no šīm galvenajām atšķirībām ir nākotnes sistēmas prototipa veidošanas posma klātbūtne vai kā to sauc arī par “informācijas sistēmas modeļiem”.

Nākamajā rakstā mēs runāsim tikai par prasību identificēšanas metodēm, kā arī apsvērsim to, kas ir kopīgs starp informācijas sistēmas prasību apkopošanas darbu un informācijas apkopošanu, lai aprakstītu biznesa procesus.

Darba veidi, apkopojot grāmatvedības sistēmas prasības un informāciju biznesa procesu aprakstīšanai. 2. daļa

Šajā daļā mēs runāsim par to, kā organizēt darba stadiju prasību vākšanas jomā, par to, kas tai būtu jāsastāv un kādi rīki var tikt izmantoti. Es atkārtoju, ka šie darbi stadiju ziņā ir ļoti līdzīgi uzņēmuma aptaujai, lai aprakstītu biznesa procesus.

Kā parasti dzīvē:

Kā tas darbojas lielākajā daļā projektu
	Kā tas notiek
	Ir skaidrs, ka prieks ir iemesls, it īpaši, ja projekts ir liels, tajā nav nekā slikta! Galvenais nav pārāk ilgi priecāties, aizkavējot faktiskā darba sākumu, no šī brīža laika gaitā notiks savādāk.
	Parasti šis process aprobežojas ar vairākām tikšanās reizēm ar vadību, pēc tam ar nodaļu vadītājiem. Nofiksējot dažus Klienta “mudinājumus”, tie tiek fiksēti vispārīgu formulējumu veidā. Dažreiz tam tiek pievienota pieejamā dokumentācija (kāds savulaik mēģināja veikt eksāmenu, dokumentus saskaņā ar esošajiem noteikumiem, izmantotajām ziņojumu formām). Pārsteidzoši, ka pēc tam lielākā daļa automatizācijas sistēmu ieviesēju ar prieku iesaucas: “Jā, mūsu sistēmai ir tas viss! Nu, nedaudz kniebiens un viss darbosies. Uz jautājumu, vai ir nepieciešams apspriest, kā lietām vajadzētu darboties (vai kā konkrēts process) Izmantojot gala lietotājus, atbilde parasti ir nē. Tiek izteikts viedoklis, ka vadītājs saviem padotajiem visu zina. Bet velti... Aiz tā slēpjas daudz slazdu un šķēršļu, un darbu piegāde var pārvērsties par maratonu pa šķēršļu joslu. Kā jūs zināt, ir ierasts skriet maratonu uz līdzena ceļa, un skriešana ar šķēršļiem ir iespējama tikai nelielos attālumos (jūs, iespējams, to neveicat).
Darba rezultātu dokumentācija	Pēc tam sākas rezultātu dokumentēšana atkarībā no darba mērķiem: Ja nepieciešams izstrādāt darba uzdevumu, konsultants sāk izplatīt saņemto informāciju pēc sagatavotā dokumenta veidnes, lai tā izskatītos skaista un galvenā prasības ir fiksētas (tās, kuras izskan no vadības, pretējā gadījumā viņi var neapstiprināt). Saprotot, ka praksē šāds Nolikums netiek īpaši izmantots un viss ir jāizdomā “ejot ceļā”, viņš par galveno Nolikuma mērķi izvirza minimālo saskaņošanas un apstiprināšanas laiku. Un, ja iespējams, informācija aptuvenai turpmākā darba izmaksu aprēķiniem (starp citu, tas ir arī svarīgi). Ja vēlaties aprakstīt biznesa procesus. Savādi, bet bieži vien visas iepriekšējās darbības izskatās tāpat kā darba uzdevuma izstrādes gadījumā. Vienīgā atšķirība ir dokumentācijā. Šeit ir iespējamas iespējas: konsultanti apraksta procesu ar patvaļīgiem vārdiem vai izmanto jebkādus biznesa procesu aprakstīšanas noteikumus (apzīmējumus). Pirmajā gadījumā šāds dokuments izrādās pārsteidzoši līdzīgs Darba uzdevumam. Gadās pat tā, ka, nomainot titullapu, jūs neredzēsiet nekādu atšķirību. formāla apraksta noteikumu ievērošana.Diemžēl abi varianti nav tie visvairāk labākā prakse, jo ir vairāk formalitāte un nedod lielu labumu.

Kāpēc pastāv šāda prakse, kā aprakstīts iepriekš? Atzīšos, ka nezinu. Neviens nejautā, neviens nezina. Tajā pašā laikā situācija nemainās ļoti strauji, lai gan par šo tēmu nemitīgi tiek runāts, notiek pieredzes apmaiņa, rakstītas grāmatas... Man šķiet, ka viens no iemesliem ir attiecīgās izglītības zemā kvalitāte. To var ietekmēt arī tas, ka daudzi speciālisti vispār nāk no citiem uzņēmumiem un visu saprot praksē, t.i. viņu pieredzi veido vide, kurā viņi atrodas. Arī augstskolu attieksme un nevēlēšanās būt tuvāk realitātei ir vispārzināms fakts, taču dažkārt viņu nostāja mani pārsteidz. Piemēram, man bija gadījums, kad maģistrants, talantīgs speciālists gribēja uzrakstīt diplomdarbu uz platformas 1C (laba nozares attīstība), bet katedrā viņai teica, ka neatkarīgi no tēmas tas nebūs iespējams. rēķināties ar atzīmi “teicami”, jo 1C nav nopietna sistēma. Šeit runa nav par šāda viedokļa nopietnību un objektivitāti, bet gan par to, ka primitīvs uzdevums klasiskajā programmēšanas valodā uzreiz tika uzskatīts par “izcila” vērtējuma cienīgu.

Mēģināsim piešķirt iepriekš apspriestajam procesam sistemātiskāku pieeju. Kā tad viņš varētu izskatīties?

Kā redzat, process beidzas ar jautājumu, jo pie tā darbs ne tuvu nav beidzies, un tad sāksies grūtākais un praktiskākais - tieši tas, kas noteiks iegūtā rezultāta pielietojamību. īsta dzīve. Tieši tas noteiks iepriekšējā darba likteni: vai nu tas nonāks skapī (plauktā vai kur citur), vai arī būs vērtīgs informācijas avots. Un vēl labāk, ja tas kļūst par paraugu turpmākajiem projektiem.

Gribu uzsvērt, ka līdz pēdējam solim diagrammā (kur ir jautājums) vispārējais informācijas vākšanas princips par uzņēmuma darbību izskatās vienāds, neatkarīgi no tā, ko plānots darīt nākotnē, aprakstīt biznesa procesus vai ieviest automatizēta sistēma. Jā, pati darbību secība ir tāda pati, taču dažos no tiem izmantotie rīki var atšķirties. Mēs noteikti apsvērsim šo brīdi, kad pētīsim atsevišķu posmu metodes un rīkus. Mēs to detalizēti darīsim atsevišķos rakstos, bet tagad mēs apsvērsim tikai vissvarīgāko. Turpmākie soļi atšķirsies un tos noteiks tas, kas ir nepieciešams no projekta: aprakstiet biznesa procesus vai ieviesiet grāmatvedības sistēmu.

Apskatīsim, kā jūs varat pārkārtot pieeju informācijas vākšanai par uzņēmuma darbību.

Kā tas var notikt ar kompetentāku darba organizāciju
	Kā tas notiek
Lēmums pieņemts, projekts būs!	Te nekas nemainās attiecībā uz pirmo variantu, emocijas neviens nav atcēlis
Mēs tikāmies ar vadītājiem, apkopojām informāciju par viņu redzējumu par rezultātu.	Šis solis arī paliek, un tam ir liela nozīme. Taču pirmās tikšanās (vai vairākas tikšanās) ar vadītājiem un īpašniekiem galvenais mērķis ir iepazīšanās. Iepazīšanās pirmām kārtām ar cilvēkiem un uzņēmumu. Šādās kopsapulcēs formulētie mērķi un vēlmes var būt ļoti dažādi, arī fantastiski. Tie visi, protams, tiks uzklausīti, bet ne tas, ka tie tiks īstenoti. Ar dziļāku iedziļināšanos uzņēmuma biznesā parādīsies citi mērķi, kā arī tiks noraidīti iepriekšējie. Ar to es domāju, ka no priekšsapulcēm nav iespējams noformulēt skaidrus mērķus, tas viss būs rūpīgi jāizpēta, šādās sanāksmēs ir nepieciešams ieskicēt visus īpašnieku un augstāko amatpersonu vēstījumus, lai vēlāk varētu atgriezties pie tiem. un apspriest, kad ir savākts pietiekami daudz informācijas. Pat šķietami vienkārša prasība var izrādīties nerealizējama vai ļoti darbietilpīga.
Darba grupas veidošana no Pasūtītāja un Izpildītāja, lomu sadale	Ir jāizlemj, kurš strādās pie projekta gan no Pasūtītāja, gan Izpildītāja puses. Neskatoties uz šī posma šķietamo vienkāršību, tam ir ļoti svarīga loma. Ja nepārprotami nenorādīsit, kurš par ko ir atbildīgs, jūs riskējat radīt neskaidrības darba izpildes laikā. Ja no savas puses vienmēr varat norādīt lomas savā komandā, tad Klientam ar to var rasties problēmas. Kam jāpievērš uzmanība: Pasūtītāja darba grupā obligāti jābūt tiem cilvēkiem, kuri nākotnē vismaz kaut kādā veidā ietekmēs rezultāta pieņemšanu. Ja pieņemam situāciju, ka, nododot darbu, pievienosies Pasūtītāja darbinieki, kuri nav piedalījušies mērķu veidošanas un prasību noteikšanas darbā, tad problēmas ir garantētas. Iespējama pat tik absurda situācija,ka viss, izrādās, nav izdarīts kā prasīts.Savā praksē ar šādu situāciju esmu saskārusies ne reizi vien.Tāpēc sevi var pasargāt, ja atrunā un dokumentē, ka neviens, izņemot darbu pieņemšanā un piegādē var piedalīties Pasūtītāja darba grupa. Un pats labākais, to noteikt līguma nosacījumos (līgumā vai projekta hartā). Atceros, bija tāds gadījums: vienā lielā projektā dibinātājs nolēma pievienoties procesam (nezinu kāpēc, kļuva garlaicīgi skatīties) un apmeklēja vienu no darba sanāksmēm, kur tika izskatīts jautājums par rēķinu ģenerēšanu klientiem. apspriests. Viņš bija pārsteigts, uzzinot, ka pārdošanas vadītājs izsniedz klientam rēķinu. Viņaprāt, grāmatvedim ir jāizraksta rēķins, un nekas cits. Bet patiesībā grāmatvedei vispār nebija ne jausmas, kas ir uz spēles, un vadītājs nevarēja iedomāties, kā tā var strādāt, ja par katru kontu skrien pie grāmatveža. Rezultātā mēs zaudējām daudz laika, taču nekas nemainījās, rēķinu joprojām izrakstīja pārvaldnieks. Un dibinātājs palika pie sava viedokļa, bet procesā vairs neiejaucās. Tajā pašā posmā vēlams izstrādāt Projektu hartu, kurā ir noteiktas dalībnieku lomas, komunikācijas kārtība, atskaites noteikumi un sastāvs, kā arī viss pārējais, kas būtu jāieraksta hartā. Projekta hartas izstrāde atkal ir atsevišķs jautājums.
Apmācīt projekta komandu darba metodēs un instrumentos, vienojoties par darba noteikumiem, dokumentācijas veidiem un sastāvu	Pirmkārt, projekta komandai ir jāizskaidro viss, kas rakstīts hartā, kā tas tiks pielietots praksē. Otrkārt, Pasūtītāja projekta komanda ir jāapmāca par darba metodēm, kuras jūs gatavojaties izmantot visos turpmākajos posmos. Ir lietderīgi apspriest dokumentu formātus, kas tiks izmantoti, apsvērt paraugus. Ja tiks piemēroti kādi modeļu vai biznesa procesu aprakstīšanas noteikumi, tad arī šie noteikumi ir jāapspriež, lai tie būtu saprotami.
Anketa	Aptaujas posms ļauj salīdzinoši ātri iegūt diezgan ticamu informācijas šķēli par uzņēmumu. Šādas informācijas kvalitāti noteiks trīs faktori: Pirmkārt, kā jūs apmācījāt klienta projekta komandu. Viņiem skaidri jāsaprot, kā notiek aptaujas process, un jāspēj nodot informāciju visiem dalībniekiem. Pati anketas forma. Anketām jābūt saprotamām. Vēlams, lai būtu anketu aizpildīšanas instrukcija. Vēl labāk, ja ir pildījuma piemērs. Dalībnieku saraksts. Ir nepieciešams izvēlēties pareizo dalībnieku sastāvu. Ja aprobežosimies tikai ar vadītājiem, nebūs iespējams savākt ticamu informāciju. Iesaku anketā iekļaut visus, kas būs gala rezultātu lietotāji. Piemēram, ja mēs runājam par automatizētas sistēmas ieviešanu, tad ir vērts iekļaut visus, kas būs lietotāji. Ir reizes, kad no 10 viena amata darbiniekiem ir tāds, kurš veic kādu īpašu funkciju, par kuru neviens no atlikušajiem 9 nezina (piemēram, sagatavo speciālu atskaiti vadībai). Ja mēs runājam par tālāku pienākumu pārdali vai amatu aprakstu izstrādi, jums vajadzētu rīkoties tāpat. Es vēršu jūsu uzmanību uz to, ka iztaujāšanas metode turpmākai automatizētas sistēmas ieviešanai vai biznesa procesu aprakstam pareizajā gadījumā ir atšķirīga. Protams, anketu struktūra var būt vienāda, taču tas nav labākais risinājums. Kad mēs aprakstam biznesa procesus, anketām parasti ir vispārīgāks raksturs, jo nav precīzi zināms, ar ko nāksies saskarties. Ja mēs runājam par konkrētas automatizētas sistēmas ieviešanu, tad labāk ir izveidot anketas, kurās ņemtas vērā šīs sistēmas īpašības. Izmantojot šo pieeju, jūs varat nekavējoties noteikt visas sistēmas vājās vietas, kas nav piemērotas šim uzņēmumam. Parasti gatavu sistēmu ieviešanas metodes nodrošina šādu anketu pieejamību. Šādas anketas var izstrādāt vai nu atsevišķām grāmatvedības jomām (piemēram, pasūtījumu uzskaite, pārdošana, cenu noteikšana), vai arī konkrētiem amatiem (piemēram, finanšu direktors). Jautājumu sastāvs ir aptuveni vienāds.
Aptaujas	Aptauja ir mutiska intervija ar speciālistiem, lai noskaidrotu atsevišķu procesu īpatnības. Aptauja ir jāorganizē tā, lai tā neizskatītos tikai pēc "tikšanās-sarunas", bet gan organizētāka. Lai to izdarītu, ir nepieciešams sagatavot tā saukto aptaujas plānu. Tajā varat iekļaut tās anketas daļas, kas jums rada jautājumus, ir pretrunā ar citu anketu informāciju vai arī informācija ir sniegta virspusēji. Vēlams pievienot jautājumus un tikai no personīgās pieredzes.Atbildēm jābūt ieskicētām bez kļūmēm. Ideālā gadījumā, ja vienojaties par audio ierakstu. Tajā pašā posmā ir jāuzrauga par darbplūsmu sniegtās informācijas pilnīgums (gan primāro dokumentu formas, gan dažādi ziņojumi)
Galveno biznesa procesu vai automatizācijas jomu identificēšana	Pēc anketas un aptaujas var pamatoti uzskatīt, ka ir pietiekami daudz informācijas, lai izdarītu secinājumus par galveno biznesa procesu sadalījumu. Faktiski jau tagad ir iespējams izcelt ne tikai galvenos biznesa procesus, bet gandrīz visu (ja dalībnieku sastāvs tika izvēlēts pareizi). Jautājums par biznesa procesu identificēšanu ir pilnīgi atsevišķs un nebūt ne vienkāršs temats. Mācīšanās šeit ir sarežģīta, un to galvenokārt veido pieredze. No atlasītajiem biznesa procesiem ir jāsastāda saraksts (klasifikators). Pēc tam varēs izlemt, kuras no tām izpētīt dziļāk, kuras nē, kā arī noteikt prioritātes.
Sistēmas galveno prasību formulēšana, mērķi, projekta panākumu kritēriji, procesi detalizētai izpētei	Līdz šim posmam jāsavāc visa primārā informācija par uzņēmuma darbību, jāsastāda biznesa procesu saraksts. Tagad ir pienācis laiks atgriezties pie mērķiem, precizēt tos, ja nepieciešams, pārrunāt ar uzņēmuma pirmajām personām. Formulējot mērķus, jāņem vērā konkrēti rādītāji, kurus sasniedzot, projektu uzskatīsim par veiksmīgu. Ja mēs runājam par automatizētas sistēmas ieviešanu, tad atsevišķā sarakstā var izcelt galveno lietotāju prasības sistēmai. Es to daru atsevišķas tabulas veidā, kur visas prasības ir sagrupētas pa apakšsistēmām, katrai prasībai ir norādīts prasības autors, formulējums un prioritāte. Šo informāciju var izmantot sistēmas izvēršanas plāna sastādīšanai (atsevišķu apakšsistēmu ieviešanas secība), kā arī priekšlikumiem sistēmas tālākai attīstībai (ja pašreizējā projektā nav paredzēts ieviest atsevišķas apakšsistēmas). Ja nepieciešams aprakstīt biznesa procesus, tiek pieņemti lēmumi par tiem procesiem, kuri ir jāizpēta sīkāk.

Tātad mēs nonācām pie jautājuma "Kas tālāk?". Tālāk atsevišķi aplūkosim biznesa procesu aprakstīšanas un darba uzdevuma izstrādes uzdevumus. Nav nejaušība, ka es šos uzdevumus izskatu paralēli. Starp viņiem patiešām ir daudz kopīga, ko es vēlos demonstrēt. Pirmkārt, apsveriet darba secību, aprakstot biznesa procesus.

	Ko un kā darīt
Biznesa procesa izvēle	No vispārējā biznesa procesu saraksta, kas iegūts iepriekšējos posmos, mēs izceļam vienu (pēc prioritātes) par detalizēts pētījums. Pēc tam mēs darām to pašu ar pārējo.
Detalizēta biznesa procesa izpēte	Izvēlēto biznesa procesu pakļaujam detalizētai izpētei: analizējam saņemtos primāros dokumentus, atskaites un programmas procesā izmantoto to struktūru, dažādus failus (piemēram, Excel), runājam ar gala izpildītājiem. Dažādu ideju apkopošana, kā procesu var uzlabot. Tas ir ļoti noderīgi, ja varat novērot procesu tieši tādos apstākļos, kādos tas tiek veikts (ne daudziem patīk, ka viņus skatās, bet ko darīt)
Uzņēmējdarbības procesa grafisks un/vai tekstuāls apraksts (primārais)	Sākam aprakstīt saņemto detalizēto informāciju Pirms procesa aprakstīšanas ir jāizlemj, vai tam būs nepieciešams grafisks apraksts. Ja process ir vienkāršs un saprotams, tajā ir maz funkciju un grafiskais attēlojums neuzlabos tā izpratni vai uztveri, tad tam nav jātērē laiks. Šajā gadījumā pietiek to aprakstīt teksta veidā tabulas veidā. Ja process ir sarežģīts, ar dažādiem loģiskiem nosacījumiem, tad labāk ir dot tā grafisko diagrammu. Diagrammas vienmēr ir vieglāk saprotamas. Ja jūs nolemjat aprakstīt procesu grafiskā formā, tas nebūt nenozīmē, ka jums nav jāsniedz tā teksta apraksts. Tie. procesa tekstuālam aprakstam jebkurā gadījumā jābūt un tas jāveido saskaņā ar to pašu shēmu. To ir ērti izdarīt tabulas veidā, kurā norādīt: katra soļa veicējus, kādu informāciju viņi saņem ievadā, katra soļa aprakstu, kāda informācija tiek ģenerēta izejā. Tālāk mēs redzēsim piemēru, kā tas varētu izskatīties.
Saskaņošana ar izpildītājiem un biznesa procesa īpašnieku	Labākais veids, kā saprast, cik labi esat izvēlējies informācijas pasniegšanas stilu, ir procesa lietotājiem (izpildītājiem) parādīt rezultātu. Vissvarīgākais šādā demonstrācijā ir saprast, cik pareizi jūs sapratāt, kā process tiek veikts. Ja projekta komandas apmācība noritēja veiksmīgi, tad var sagaidīt diezgan adekvātas atsauksmes no izpildītājiem. Un, ja viņi sāks interesēties, tad viss sāks virzīties daudz ātrāk.Identificētie precizējumi un neatbilstības ir jāatspoguļo aprakstā (atjaunina), ja nepieciešams, atkārtojiet darbību.
Biznesa procesu indikatoru identificēšana	Kad jums ir laba izpratne par to, kā tiek izpildīts biznesa process, jums ir jādomā par rādītājiem, kas var izmērīt procesa kvalitāti vai ātrumu. Tas nav viegli, bet nepieciešams. Rādītājam jābūt izmērāmam, t.i. izteikta skaitliskā izteiksmē, un ir jābūt vienkāršam veidam, kā iegūt šo vērtību. Ja izmērīto rādītāju nevar identificēt, pastāv risks, ka biznesa process ir slikti identificēts. Turklāt nebūs iespējams saprast (jo to nevar izmērīt), vai izmaiņas procesā novedīs pie tā uzlabošanas vai nē.
Biznesa procesa noslēguma dokumentācija	Kad esam pārliecinājušies, ka saprotam, kā process tiek veikts (vai tam vajadzētu būt), varam to iekļaut dokumentācijā.
	Iespējami arī tālāki varianti: apskatāmie procesi tiks analizēti un optimizēti, izstrādāti darba apraksti, tiek pieņemti lēmumi par atsevišķu procesu automatizācijas nepieciešamību u.c. Tas var būt arī atsevišķs projekts: biznesa procesu apraksts.

Tagad apskatīsim, kā izskatīsies pieeja informācijas sistēmas prasību izpētei ar to tālāku atspoguļojumu darba uzdevumā

	Ko un kā darīt
Biznesa prasības/automatizācijas jomas izcelšana	Praksē tiek izmantota visa automatizācijas jomas izdalīšana kā prasības (piemēram, "Inventārs"), tomēr tas nav efektīvākais veids, kā detalizēt prasības. Automatizācijas joma ir prasību grupa, un labāk tās izskatīt atsevišķi. Piemēram, "Preču saņemšanas uzskaite noliktavā"
Detalizēts pētījums par uzņēmējdarbības prasībām	Ar detalizētu biznesa prasības izpēti saprot to, kā gala lietotājs to vēlas redzēt un izmantos (protams, saskaņā ar projekta mērķiem). Programmatūras izstrādes tehnoloģijās to bieži dēvē par "lietošanas gadījumu". Tādējādi detalizēta biznesa prasību izpēte tiek reducēta līdz lietošanas gadījumu izstrādei. Šādas iespējas piemērs ir sniegts raksta 2. pielikumā. Vienkāršākajos gadījumos vispār nav nepieciešams zīmēt lietošanas gadījumus grafisko diagrammu veidā, varat arī aprobežoties ar tekstuālu formulējumu. Piemēram, prasību "Ievadot preci, cena jāaprēķina kā pirkuma cena + 20%" nav jēgas zīmēt. Diagrammas veidā ir lietderīgi uzrādīt prasības, kas apvienotas līdz automatizācijas jomai, kā parādīts 2. papildinājuma piemērā.
Modelēšanas prasības informācijas sistēmā	Te tas ir! Kā jūs droši vien atceraties, es jau esmu pievērsis uzmanību šim vissvarīgākajam darba uzdevuma izstrādes metodoloģijas elementam. "Uzbūvē modeli - iegūsti rezultātu!" Kas būtu jāmodelē? Nepieciešams modelēt iepriekšējā posmā iegūtos lietošanas gadījumus. Kādam jābūt simulācijas rezultātam? Jums vajadzētu iegūt demonstrācijas programmu, kurā tiek ievadīti lietotāja dati, un vēlams, lai tā būtu pazīstama viņa (lietotāja) dzirdei, ņemot vērā nozares specifiku, aktuālās problēmas. Un ne tikai ievadīts, bet jābūt skaidram, no kurienes šie dati ir iegūti, kā tie tika aprēķināti. Šajā brīdī lasītājam vajadzētu uzdot jautājumus: Bet ja ir plānots izstrādāt jaunu sistēmu un vienkārši nav ko modelēt? Ko darīt, ja demonstrācijai nav pietiekami daudz funkcionalitātes un sistēma ir jāuzlabo? Protams, jums ir jāsaskaras ar šādu situāciju, un tas ir normāli. Ko darīt? Ja sistēma ir pilnīgi jauna (kā saka “no nulles”), tad lielākoties būs jāmodelē uz papīra, šeit ļoti palīdzēs lietošanas gadījumu diagrammas. Daļēji ir jēga ieskicēt dažas ekrāna formas, kuras paredzēts izstrādāt (tieši tajā vidē, kurā tiks veikta izstrāde), jo. to zīmēšana kādā redaktorā prasīs ilgāku laiku, un šis darbs ir garlaicīgs. Ja tiek ieviesta jau gatava sistēma, kurai trūkst funkcionalitātes, tad nav ko uztraukties, dati tiek ievadīti ar roku, un lietotājam tiek pateikts, ka pēc nepieciešamajiem uzlabojumiem jārēķina tā un tā ( un viņš to redz). Šādam modelim ir vēlams pievienot tekstuālu aprakstu, pat ja tas ir īss, lai lietotājs varētu patstāvīgi mēģināt strādāt ar modeli savā brīvajā laikā. Tajā pašā aprakstā varat formulēt prasības uzlabojumiem.
Informācijas modeļa demonstrēšana darba grupai	Iegūto modeli rādām Pasūtītājam un pastāstām, kā visam jāstrādā.Labāk modeli demonstrēt pa apakšsistēmām, t.i. pēc prasību grupas. Ja izrādās, ka piedāvātā shēma klientam nederēs, jādomā par citiem lietošanas gadījumiem, jāveic izmaiņas modelī un jāparāda vēlreiz. Tikai tad, ja ir pārliecība, ka plānotais modelis “dzīvos” kopā ar konkrēto klientu, modeli var uzskatīt par veiksmīgu.
Testa izstrāde	Kāpēc ir nepieciešami testi? Būs jāpārbauda, ​​kā mēs spējām ieviest prasības. Attiecīgi ir vēlams veikt testus visām galvenajām jomām, sarežģītiem algoritmiem utt. Tostarp šos testus var izmantot darbu piegādes laikā. Nemaz nav nepieciešams veikt testus katrai sistēmas funkcijai, visur jābūt veselajam saprātam. Ja mēs runājam par gatavu sistēmu, tad testa veikšana “jauna elementa ievadīšanai klientu direktorijā” izskatīsies muļķīgi un laika un pūļu izšķiešana. Bet, ja šī ir pilnīgi jauna sistēma, tas ir pilnīgi iespējams. Kāpēc veikt testus, ja vēl nav sistēmas?Pirmkārt, izstrādātājam būs skaidrāk, ko viņi vēlas no viņa panākt. Otrkārt, atvieglojam dzīvi testētājam (galu galā kāds pārbaudīs izstrādes rezultātu). Kopumā testēšana ir atsevišķa disciplīna, kas nav ļoti vienkārša ar daudzām metodēm. Praksē, kā likums, joprojām tiek izmantotas vienkāršākās pārbaudes metodes.
Prasību dokumentācija darba uzdevuma veidā	Iepriekšējos posmos apkopotā informācija būs tieši tā, kas ir jāiekļauj dokumenta "Nolikums" bāzē prasību sadaļā, tāpēc atliek to visu pareizi sakārtot.
Turpmākās darbības (vai to trūkums), atkarībā no projekta mērķiem	Izstrādes process, partneru meklēšana projektam, konkursam utt., var aizņemt ilgāku laiku, viss atkarīgs no situācijas.

Jā, darba uzdevuma izstrāde ir laikietilpīgs process un tāpēc dārgs. Bet, ja tas tiek darīts pareizi, tas paglābj Klientu no nepiepildītām cerībām. Izpildītājam ir jādara tas, ko pieprasa Pasūtītājs, nevis jāatkārto viens un tas pats simts reizes. Un kopumā tas piešķir caurskatāmību visam projektam.

Pielikums 1. Aprakstīts biznesa process EPC notācijā.

“Es gribēju uztaisīt pērkona negaisu, bet dabūju kazu...”, jūs domājat, pieņemot no izstrādātāja pavisam jaunu vietni. Šķiet, ka izpildītājs tika izvēlēts pēc ieteikuma. Un viņa portfolio iedveš pārliecību. Un tas nav pirmais gads. Un tas joprojām nedarīja to, ko jūs iedomājāties. Un tagad jūs jau esat vīlies vietņu veidotājos un esat pārliecināts, ka jūs ieskauj blēži un amatieri.

Tikmēr par jebkuras deleģēšanas rezultātu ir atbildīgs ne tikai izpildītājs, bet arī pasūtītājs.

Pareizi sastādīts darba uzdevums mājas lapas izveidei palīdzēs samazināt riskus un palielināt iespēju iegūt savu sapņu interneta resursu.

Kāpēc ir nepieciešama specifikācija?

• Darbuzņēmējs kompetenta vietnes izstrādes tehniskā specifikācija palīdzēs iepriekš novērtēt darba apjomu, sarežģītību un izmaksas. Lai saprastu, vai viņš pats tiks galā ar šādu uzdevumu, vai ir vērts ņemt palīgus. Un tad dariet tieši to, ko klients no viņa sagaida.
• Klients darba uzdevums dod pārliecību, ka viņš ir dokumentējis savas vēlmes attiecībā uz topošo objektu, skaidri iezīmējis termiņus, kas būvuzņēmējam jāievēro, noteicis prasības objektam. Un, ja rezultāts ir neapmierinošs, varat iesniegt pamatotu prasību: "Neatbilst TOR!"

Kā izskatās vietnes darba uzdevumi?

Tava vēlēšanās “emuārs ar bezmaksas saturu, lapa par mani un kontaktpersonas” izpildītājs redz šo:

Vai, jūsuprāt, ar to pietiek, lai izveidotu vietni?

Jūs saņemat gatavu vietni, un tad pēkšņi izrādās, ka jūs domājāt šo:

Apraksta nianses ir ļoti svarīgas

Vai jūtat atšķirību? Formāli šeit kļūdās abas puses: jūs nepievienojāt detaļas, izpildītājs par tām nejautāja. Bet viņš jau ir saņēmis samaksu un ir gatavs ar to pazust, un jums ir puspabeigta vietne, negaidīti izdevumi un pilnīga vilšanās vietņu veidotājos.

Iesaku nenovest lietas līdz tādām galējībām, bet vietnes darba uzdevuma sagatavošanai pieiet apzināti.

Kas ir rakstīts darba uzdevumā?

Vietnes darba uzdevums ir detalizēts dokuments, kurā aprakstīts jūsu attiecību process ar darbuzņēmēju un viņa darba rezultāts.

Lielu un sarežģītu objektu attīstībai nepieciešams apjomīgs un sarežģīts tehniskais uzdevums, mazākiem objektiem un TK būs piemērots.

Pie liela projekta parasti strādā vesela izpildītāju komanda. Viņu rīcība ir jāsaskaņo, un tāpēc vietnes TOR būs diezgan liela. Ja jums nav nepieciešams daudz specifisku funkciju, ja jūsu vietnē strādā viens izstrādātājs (vai uzņēmumā ar dizaineru), dokuments būs vienkāršāks. Bet gan lieliem, gan maziem TK ir viena un tā pati nozīme, un tiem ir jāatbild uz tiem pašiem jautājumiem:

• Kāpēc un kam vietne ir izveidota?
• Ar ko tas būs piepildīts?
• Kā tas viss darbosies?
• Kas un kā strādās pie projekta, kurš par ko atbild?
• Kāds būs iznākums?

Vietnes izstrādes darba uzdevuma galvenās sadaļas

1. Informācija par klientu, tas ir, par jums

Sniedziet pēc iespējas sīkāku informāciju. Norādiet visus avotus, kur izstrādātājs var iegūt trūkstošos datus. Tās var būt bukleti, plakāti, elektroniskie materiāli, saites, to cilvēku kontakti, kuriem var uzdot jautājumus.

2. Informācija par projektu

Kas tas būs: vizītkaršu vietne, interneta veikals, korporatīvais portāls, elektroniskā bibliotēka?

3. Vietnes mērķauditorija

Šis ir gadījums, kad jums ir nepieciešams. Ja jau sen lasāt mūsu emuāru, tad saprotat, ka bez šī rīka mārketingā kopumā var izdarīt ļoti maz.

Vai esat izvēlējies savu vietni, bet joprojām nezināt, kas ir jūsu klients? Tātad, tagad ir laiks izveidot detalizētu viņa portretu.

4. Mērķi un uzdevumi, kas vietnei jāatrisina klienta un auditorijas labā

Iespējams, šī ir galvenā TOR sadaļa vietnes izstrādei. Jums ir skaidri jāsaprot, kāpēc jums ir nepieciešams tīmekļa resurss. Lai uzlabotu attēlu? Tiešajai pārdošanai? Vai vēlaties pārvērst apmeklētājus par abonentiem, izmantojot savu vietni? Vai vēlaties izveidot resursu potenciālo partneru piesaistei?

Norādiet savas vietnes tiešo mērķi.

Rūpīgi pārdomājiet atsevišķus tīmekļa resursa uzdevumus. Piemēram, tai ir jāsniedz jaunākā informācija par tirgus jaunumiem, jādemonstrē jūsu produkti, jāļauj apmeklētājiem sazināties ar jums tieši no vietnes lapām un tā tālāk.

5. Projekta ietvars (galvenā funkcionalitāte)

Vietnei var būt ļoti daudz funkciju: lietotāja reģistrācijas forma, atsauksmes, pasūtījuma pogas, piegādes kalendārs, ziņu plūsma, preču katalogs ar iespēju doties uz grozu, iebūvēts pasta skripts, slēgtas sadaļas klienti - vienalga! Katra no šīm funkcijām jūsu vietnes izstrādes darba uzdevumā ir jāizklāsta visdetalizētākajā veidā.

Tādējādi sadaļa "Projekta joma" ir kaut kas līdzīgs satura rādītājam, kurā uzskaitītas funkcijas bez to rūpīga apraksta. Šī sadaļa jums būs nepieciešama mākslinieka meklēšanas posmā. Tas ļaus jūsu vietnes potenciālajam veidotājam redzēt kopainu un sniegt aptuvenu cenu, kamēr jūs sistematizēsit savas vēlmes pēc funkcionalitātes.

6. Objekta struktūra (karte).

Vietnes TOR nākamajā daļā darbuzņēmējam būs norādīts, kuras lapas būs jūsu vietnē, kuras sadaļas un apakšsadaļas, kā tās tiks savienotas viena ar otru, kā tās tiks parādītas vietnes izvēlnē.

Struktūru ir vieglāk uzzīmēt nekā aprakstīt. Grafiskā formā ir vieglāk domāt par attiecībām starp vietnes apgabaliem.

Vietnes atsevišķu daļu savstarpējo savienojumu shēma

Mums ir vebinārs par šo tēmu “Pārdošanas vietnes satura sistēma”. Un šeit mēs detalizēti runājam par vietnes struktūru, par lapu attiecībām un saitēm starp tām. ES iesaku! Augšējais attēls ir no šī vebināra.

7. Atsevišķas lapas

Kamēr zīmējat vietnes karti, katra lapa ir tikai kvadrāts. Bet izpildītājam ir jāsaprot, kas un kādā secībā atradīsies šajā laukumā (atgādiniet tabulu piemērus raksta sākumā). Kādi informācijas bloki būs? Vai katrā lapā būs izvēlnes, sānjoslas? (atsevišķs bloks ar navigāciju), kājene (apakšējais bloks)? Vai vēlaties lapā redzēt banerus, attēlus? Vai tie būs statiski vai kustīgi?

Jo detalizētāk aprakstīsit katru nākotnes resursa katras lapas elementu, jo izvades rezultāts būs tuvāks jūsu priekšstatiem par vietni.

Patiesībā šajā posmā a . Par to jau rakstījām, ja jāveido mājas lapa, noteikti izlasi.

Katrai vietnes lapai varat izveidot prototipu, pievienojot tai detalizētu verbālu aprakstu. Vai arī vispirms varat izveidot galveno bloku prototipus, kas tiek atkārtoti katrā vai vairākās lapās, un pēc tam izstrādāt atsevišķas lapas, izmantojot jau aprakstītos blokus.

8. Vietnes projektēšanas prasības

Šajā posmā esiet uzmanīgi. Pieņemsim, ka dizainers ir profesionālis. Jums nav jāpieraksta katrs solis. Nestāstiet: “Padariet šo pogu ar pārplūdi no zilas uz sarkanu un šo tekstu 12. izmērā un tā, lai tas mirgo”. Uzskaitiet savas galvenās vēlmes. Piemēram, parādiet esošās tīmekļa vietnes/banerus/drukāšanu, kas, jūsuprāt, atbilst jūsu dizainam. Pastāstiet mums, kādas krāsas vēlaties. Pieņemsim, ka vēlaties izveidot vietni, kas veltīta sieviešu apmācībai, dizainers to var "redzēt" rozā krāsā, bet jums patīk ceriņi un oranži. vispārīgs apraksts vēlmes palīdzēs atrast kompromisu starp jūsu redzējumu un dizainera profesionālo izskatu.

Noteikti sagādājiet dizainerim materiālus darbam, ja tādi ir: logotips, korporatīvo krāsu un fontu kodējumi, gatavi korporatīvās identitātes elementi (druka, baneri utt.).

Ar vietnēm par dzinējiem, piemēram WordPress vai Joomla jūs varat iztikt ar gatavām veidnēm (dažreiz pat bezmaksas). Tas samazina nenoteiktību: vienkārši apskatiet veidnes un izvēlieties sev tīkamāko. Dizaina ziņā daži ir visai dīvaini, tāpēc pamēģini konsultēties ar speciālistu – tas tik un tā iznāks lētāk, nekā pasūtīt dizainu no nulles.

9. Vietnes darba funkcionalitāte

Neesiet slinki un sīki aprakstiet visu funkciju darbu. Sniedziet izpildītājam pēc iespējas vairāk informācijas. Atcerieties, ka viņam nav telepātijas dāvanas un viņš var neuzminēt, ko vēlaties iegūt, rakstot vietnes darba uzdevumā. "abonēšanas forma" vai "kalendārs".

Kāda ir abonēšanas forma? Kā viņa izskatās? Kā tas darbojas? Kas par kalendāru? Vai tas parāda tikai šodienas datumu vai visu pēdējo mēnesi? Vai es varu tajā pāršķirt lapas vai nē? Izpildītājs šīs nianses var neuzminēt, galu galā iegūsi ko pavisam citu, nekā vēlējies. Nauda ir samaksāta, projekts atbilst TOR (Jūs rakstījāt "kalendārs"- šeit tas ir), un jums būs jāapmierinās ar notikušo, lai gan tas nepavisam nav tas, ko gribējāt, vai arī jāpārmaksā par izmaiņām.

Jūtieties brīvi izpētīt citas vietnes - konkurentus vai pat uzņēmumus, kuru darbība nav saistīta ar jums. Konkurenti var ieteikt sev nepieciešamo funkciju ieviešanu, citos tirgos var aizņemties interesantus risinājumus, par kuriem konkurenti vēl nav iedomājušies. Bieži vien ir vieglāk atrast funkciju kāda cita vietnē un dot izpildītājam saiti "tam vajadzētu darboties šādi", nevis rādīt ar pirkstu.

Neaizmirstiet, ka jūsu vietnei jābūt ērtai ne tikai lietotājam, bet arī administratoram. Mūsdienu satura pārvaldības sistēmas parasti ir intuitīvi administrējamas. Bet, ja nezini, ar kuru dzinēju darbojas izpildītājs, pieraksti arī administratora funkcijas. Kas viņam būtu jādara vietnē un kā tas būtu jāīsteno.

Protams, jums ir visas tiesības nezināt, kā kāda funkcija darbosies. Šādā gadījumā lūdziet izstrādātājam piedāvāt jums apstiprināšanas iespējas. Apstipriniet sev piemērotāko variantu (ieskaitot budžetu). Atcerieties: vispirms apsveriet un apstipriniet, tad dariet.

10. Satura apraksts

Ja pasūtāt saturu vienlaikus ar vietnes izveidi un jums ir viens līgumslēdzējs (piemēram, aģentūra), satura apraksts ir atsevišķs TOR tekstu autoram. Ja jūs gatavojaties izveidot saturu pats vai pasūtīt no cita mākslinieka, vietnes izstrādātājam joprojām ir jābūt priekšstatam par to, kas kurā sadaļā tiks ievietots un kā tas izskatīsies. Kur ir teksts, kur ir video, kā tiks veidotas bildes, vai ir vajadzīgs rakstu priekšskatījums, un kāds tas būs utt.

11. Tehniskās prasības

Sarežģīts punkts tiem, kas maz saprot vietnes veidošanā. Ja jūs to saprotat un jums ir svarīgi, kurā valodā, kurā versijā ir jāraksta jūsu resurss, ierakstiet par to vietnes izveides darba uzdevumā. Vai arī jums ir nepieciešamas mitināšanas diska vietas prasības.

Vai nevēlaties būt pilnībā vīlies, pieņemot vietni no izstrādātāja? Tad uzmanīgi izlasi šo rakstu!

Bet varbūt tā nav viņa vaina? Galu galā par jebkuras deleģēšanas rezultātu ir atbildīgs ne tikai izpildītājs, bet arī pasūtītājs.

Lai iegūtu maksimāli vēlamo rezultātu, ir jāzina, kā pareizi noformēt mājas lapas izveides tehnisko uzdevumu.

KĀPĒC JUMS VAJADZĪGS UZDEVUMS?

• Darbuzņēmējs kompetenta vietnes izstrādes tehniskā specifikācija palīdzēs iepriekš novērtēt darba apjomu, sarežģītību un izmaksas. Lai saprastu, vai viņš pats tiks galā ar šādu uzdevumu, vai ir vērts ņemt palīgus. Un tad dariet tieši to, ko klients no viņa sagaida.
• Klients darba uzdevums dod pārliecību, ka viņš ir dokumentējis savas vēlmes attiecībā uz topošo objektu, skaidri iezīmējis termiņus, kas būvuzņēmējam jāievēro, noteicis prasības objektam. Un, ja rezultāts ir neapmierinošs, varat iesniegt pamatotu prasību: "Neatbilst TOR!"

KO VIŅI RAKSTA ATSAUCES NOTEIKUMĀ?

Uzdevums attiecas uz šādiem jautājumiem:

• Kāpēc un kam vietne ir izveidota?
• Ar ko tas būs piepildīts?
• Kā tas viss darbosies?
• Kas un kā strādās pie projekta, kurš par ko atbild?
• Kāds būs iznākums?

VIETNES ATTĪSTĪBAS NOTEIKUMU GALVENĀS SADAĻAS

1. Informācija par klientu, tas ir, par jums

Sniedziet pēc iespējas sīkāku informāciju. Norādiet visus avotus, kur izstrādātājs var iegūt trūkstošos datus. Tās var būt bukleti, plakāti, elektroniskie materiāli, saites, to cilvēku kontakti, kuriem var uzdot jautājumus.

2. Informācija par projektu

Kas tas būs: vizītkaršu vietne, emuārs, interneta veikals, korporatīvais portāls, elektroniskā bibliotēka?

3. Vietnes mērķauditorija

Aprakstiet savu mērķauditoriju, pastāstiet, kas viņiem ir vajadzīgs un kā viņu var interesēt.

4. Mērķi un uzdevumi, kas vietnei jāatrisina klienta un auditorijas labā

Jums ir skaidri jāsaprot, kāpēc jums ir nepieciešama vietne. Lai uzlabotu attēlu? Tiešajai pārdošanai? Jaunumiem? Vai vēlaties pārvērst apmeklētājus par abonentiem, izmantojot savu vietni? Vai vēlaties izveidot resursu potenciālo partneru piesaistei?

Norādiet savas vietnes tiešo mērķi.

Rūpīgi pārdomājiet atsevišķus tīmekļa resursa uzdevumus. Piemēram, tai ir jāsniedz jaunākā informācija par tirgus jaunumiem, jādemonstrē jūsu produkti, jāļauj apmeklētājiem sazināties ar jums tieši no vietnes lapām un tā tālāk.

5. Projekta ietvars (galvenā funkcionalitāte)

Vietnei var būt ļoti daudz funkciju: lietotāja reģistrācijas forma, atsauksmes, pasūtījuma pogas, piegādes kalendārs, ziņu plūsma, preču katalogs ar iespēju doties uz grozu, iebūvēts pasta skripts, slēgtas sadaļas klienti - vienalga! Katra no šīm funkcijām jūsu vietnes izstrādes darba uzdevumā ir jāizklāsta visdetalizētākajā veidā.

Tādējādi sadaļa "Projekta joma" ir kaut kas līdzīgs satura rādītājam, kurā uzskaitītas funkcijas bez to rūpīga apraksta. Šī sadaļa jums būs nepieciešama mākslinieka meklēšanas posmā. Tas ļaus jūsu vietnes potenciālajam veidotājam redzēt kopainu un sniegt aptuvenu cenu, kamēr jūs sistematizēsit savas vēlmes pēc funkcionalitātes.

6. Objekta struktūra (karte).

Vietnes TOR nākamajā daļā darbuzņēmējam būs norādīts, kuras lapas būs jūsu vietnē, kuras sadaļas un apakšsadaļas, kā tās tiks savienotas viena ar otru, kā tās tiks parādītas vietnes izvēlnē.

Struktūru ir vieglāk uzzīmēt nekā aprakstīt. Grafiskā formā ir vieglāk domāt par attiecībām starp vietnes apgabaliem.

7. Atsevišķas lapas

Kamēr zīmējat vietnes karti, katra lapa ir tikai kvadrāts. Bet izpildītājam ir jāsaprot, kas un kādā secībā atradīsies šajā laukumā (atgādiniet tabulu piemērus raksta sākumā). Kādi informācijas bloki būs? Vai katrā lapā būs izvēlnes, sānjoslas? (atsevišķs bloks ar navigāciju), kājene (apakšējais bloks)? Vai vēlaties lapā redzēt banerus, attēlus? Vai tie būs statiski vai kustīgi?

Jo detalizētāk aprakstīsit katru nākotnes resursa katras lapas elementu, jo izvades rezultāts būs tuvāks jūsu priekšstatiem par vietni.

8. Vietnes projektēšanas prasības

Izlemiet par krāsu shēmu, pastāstiet mums, kuras krāsas jums patīk. Nodrošiniet izstrādātājam pieejamos materiālus: logotipu, banerus, krāsu kodus... Parādiet viņam tādu interneta vietņu piemērus, kuras jums patīk un vēlaties kaut ko līdzīgu. Pastāstiet mums, kādas krāsas vēlaties. Piemēram, jūs vēlaties izveidot vietni, kas veltīta sieviešu apmācībai, dizainers to padarīs rozā, bet jums patīk oranžs. Vispārīgs vēlmju apraksts palīdzēs atrast kompromisu starp jūsu redzējumu un dizainera profesionālo izskatu.

9. Vietnes darba funkcionalitāte

Detalizēti aprakstiet, kādu funkcionalitāti vēlaties redzēt vietnē. Sniedziet izpildītājam pēc iespējas vairāk informācijas. Atcerieties, ka viņam nav telepātijas dāvanas un viņš var neuzminēt, ko vēlaties iegūt, rakstot vietnes darba uzdevumā. "abonēšanas forma" vai "kalendārs".

Kāda forma? Par ko? Kādiem priekšmetiem tajā jābūt? Kā viņa izskatās? Izpildītājs šīs nianses var neuzminēt, galu galā iegūsi ko pavisam citu, nekā vēlējies. Nauda ir samaksāta, projekts atbilst TOR (Jūs rakstījāt "kalendārs"- šeit tas ir), un jums būs jāapmierinās ar notikušo, lai gan tas nepavisam nav tas, ko gribējāt, vai arī jāpārmaksā par izmaiņām.

10. Satura apraksts

Ja pasūtāt saturu vienlaikus ar vietnes izveidi un jums ir viens līgumslēdzējs (piemēram, aģentūra), satura apraksts ir atsevišķs TOR tekstu autoram. Ja gatavojaties izveidot saturu pats vai pasūtīt no cita mākslinieka, vietnes izstrādātājam joprojām ir jābūt priekšstatam par to, kas kurā sadaļā tiks ievietots un kā tas izskatīsies. Kur ir teksts, kur ir video, kā tiks veidotas bildes, vai ir vajadzīgs rakstu priekšskatījums, un kāds tas būs utt.

11. Tehniskās prasības

Sarežģīts punkts tiem, kas maz saprot vietnes veidošanā.

Ja nesaproti, ieslēdz loģiku.

Piemēram, jūsu vietnei vajadzētu:

• izskatīties vienlīdz labi uz dažāda platuma monitoriem (responsīvs dizains);
• jābūt SEO optimizētam veicināšanai;
• jāspēj pretoties vīrusiem;
• ir iebūvēta SEO funkcionalitāte un tā tālāk.

Rakstiet tikai par to, par ko esat pārliecināts, vai konsultējieties ar speciālistu. Labāk iepriekš konsultēties, nekā vēlāk pārmaksāt par uzlabojumiem.