TK rengimas. Techninės užduoties sąlygos: Teisės aktų reikalavimai ir geriausia praktika

Projekto apimties apibrėžimas, techninių specifikacijų rengimas

Šiame skyriuje trumpai aptariamas kūrimo klausimas įgaliojimai(toliau TK). Pirmiausia pateikiamas TK apibrėžimas, aprašomi TK pranašumai tiek užsakovui, tiek rangovui, išvardijamos pagrindinės TK funkcijos. Toliau aptariama, kokia yra TK esmė, atskleidžiama TK struktūra ir turinys, taip pat pateikiami TK struktūros pavyzdžiai. Apibendrinant, atkreipiamas dėmesys į novatoriškų projektų TOR ypatybes.

Kadangi naujoviško projekto, turinčio savo ypatybes, techninių specifikacijų rengimo užduotys iš esmės išlieka tokios pačios, kaip ir kuriant bet kokias technines specifikacijas, pirmiausia buvo svarstomas visų techninių specifikacijų rengimo klausimas.

Apibrėžimas

Reikėtų pažymėti, kad šiuo metu nėra standartizuoto naujoviško projekto techninių užduočių (TOR) apibrėžimo. Dabartinėje nacionalinių standartų duomenų bazėje yra trys standartai, susiję su TK. Visi jie priklauso informacinių technologijų sričiai:

GOST 19.201-78. viena sistema programinės įrangos dokumentacija. Techninė užduotis. Reikalavimai turiniui ir dizainui.

GOST 25123-82. Skaičiavimo mašinos ir duomenų apdorojimo sistemos. Techninė užduotis. Statybos, pristatymo ir projektavimo tvarka.

GOST 34.602-89. Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Sukūrimo sąlygos automatizuota sistema.

Pavyzdžiui, „GOST 19.201-78. Vieninga programos dokumentacijos sistema. Techninė užduotis. Reikalavimai turiniui ir dizainui“ pateikiamas toks TOR apibrėžimas: „Automatizuotos sistemos techninė užduotis – tai tinkamai patvirtintas dokumentas, kuriame apibrėžiami tikslai, reikalavimai ir pagrindiniai pradiniai duomenys, būtini automatizuotos sistemos kūrimui ir kuriame yra preliminarus ekonominio efektyvumo vertinimas“.

Sakoma, kad TK leidžia:

rangovui – suprasti užduoties esmę, parodyti užsakovui būsimo produkto, programinės įrangos produkto ar automatizuotos sistemos „techninę išvaizdą“;

klientas – suvokti, ko būtent jam reikia;

abi šalys – pristatyti gatavą produktą;

vykdytojui - planuoti projekto įgyvendinimą ir dirbti pagal planą;

užsakovui - reikalauti iš rangovo, kad prekė atitiktų visas TOR nurodytas sąlygas;

rangovui - atsisakyti atlikti TOR nenurodytus darbus;

užsakovui ir rangovui – atlikti taškinį gatavo produkto patikrinimą (priėmimo testavimą – atlikimą bandymai);

venkite klaidų, susijusių su besikeičiančiais reikalavimais (visuose kūrimo etapuose ir etapuose, išskyrus bandymai).

Taigi techninė užduotis yra dokumentas, kuriame yra nustatytas reikalavimų rinkinys ir leidžiantis tiek kūrėjui, tiek užsakovui pristatyti galutinį produktą ir vėliau patikrinti, ar jis atitinka reikalavimus.

Kuo išsamesnis TOR, tuo mažiau ginčų tarp užsakovo ir kūrėjo kils priėmimo testų metu.

TK atlieka keturias pagrindines funkcijas:

Teisinė. TK yra teisinis dokumentas ir kaip paraiška įtraukta į užsakovo ir rangovo sutartį.

Organizacinis. TK pagalba galite supaprastinti tolesnį darbą, paversti jį užduočių eile (schema) ir nešvaistyti jėgų nereikalingiems veiksmams.

Informacinis. Gerai parašytas TOR gali būti geras informacijos, reikalingos projektui užbaigti, šaltinis. TK struktūrizavimas leidžia turėti informaciją, kuri tikrai domina, tokia forma, kuri yra lengviausiai suvokiama ir tiek, kiek reikia darbui atlikti.

Komunikabilus. Išsamus TOR padeda rangovui geriau suprasti užsakovo poreikius ir atlikti visus jo skonį atitinkančius darbus. Tai taip pat palengvina projekto tvirtinimo procesą.

TK esmė

Darbas su TOR reiškia, kad yra numatytas kokios nors užduoties sprendimas ir jis žingsnis po žingsnio aprašytas šiame dokumente. TK gali būti sukurtas bet kam: technologijai, naujai medžiagai, įrenginiui, svetainei, programai, standartui sukurti, renginio įgyvendinimui ir pan.

Projekto įgyvendinimo metu gauti galutiniai rezultatai gali būti materialūs (medžiagos, procesas, technologijos), organizaciniai (norma, standartas), moksliniai, techniniai ir moksliniai bei metodiniai (projektinė dokumentacija, tyrimo ataskaita, edukacinė programa), nematerialūs ( patentai, monografijos, straipsniai) ir kitos formos.

TK esmė – sėkmingas užduoties atlikimas. Kuo geriau ir geriau bus sudarytas TOR, tuo efektyviau bus atlikta užduotis. Be to, tai nepriklauso nuo jo masto. Neteisingai paruoštas TOR gali turėti pasekmių, pavyzdžiui, rezultato nenuspėjamumas, darbas nebus atliktas taip, kaip turėjo būti atliktas užsakovo, arba nebus atliktas iš viso. Darbo užsakovas negaus to, ko norėjo ir turi teisę už atliktus darbus nemokėti.

Darbas su TK yra sunkus ir atsakingas etapas, nes daugelis duomenų dar nėra žinomi. Projekto sėkmė, ekspertų teigimu, 50-70% priklauso nuo kvalifikuoto TOR plėtros etapo įgyvendinimo.

Paprastai prieš techninių specifikacijų kūrimo etapą yra tiriama dalykinė sritis, atliekami skaičiavimai ir modeliavimas.

Atsakingas darbas su TK leis jo kūrėjams pamatyti užduoties įvykdymo scenarijų. Aiškiai supraskite savo stipriąsias puses ir silpnosios pusės kaip išgyventi užduoties atlikimo procesą. Nustatyti kriterijus, nustatyti rodiklius, charakteristikas, sumas, įvertinti išteklius.

TK derinama su užsakovu arba kuriama bendrai.

Nepaisant svarbos, TK turinys ir struktūra norminiais dokumentais praktiškai nereglamentuojami.

Dažniausiai klientas nustato tikslą (kaip jis supranta) ir išteklių (laiko, pinigų) apribojimus. Rangovo užduotis, visų pirma, yra išversti reikalavimus į dalykinės srities kalbą, kuo išsamiau ir kompetentingiau suformuluoti užduotį, pagrįsti jos sprendimo poreikį, suvokti ir patikslinti pradinius duomenis. ToR turinys turėtų apimti informaciją, susijusią su konkrečius poreikius įgyvendinančių funkcijų tikslais ir vykdymu, kurie visada yra susiję su tam tikrų reikalavimų tenkinimu.

Darbas su reikalavimais priklauso nuo vadovybės. Neaiškūs reikalavimai sukelia neapibrėžtumą tarp visų darbo dalyvių, nes leidžia skirtingai interpretuoti reikalavimus ir neleis objektyviai įvertinti kuriamo produkto kokybės.

Formuojant reikalavimų sistemą būtina išanalizuoti užsakovo ir kūrėjo dispozicijoje esančių išteklių: finansinių, gamybinių, žmogiškųjų, laikinųjų, taip pat atsižvelgiant į priežiūros ir licencijas išduodančių institucijų reikalavimus, pvz. , projektuojant technologinius kompleksus (gamybas). Dažniausiai kontroliuoja regioninės Rostekhnadzor, Rosstandart, Rospotrebnadzor, Rosprirodnadzor ir kt.

Toliau pateikiami TK struktūros pavyzdžiai iš įvairių šaltinių.

Pavyzdžiui, TK gali būti sekcijų:

TK dalykas;

atliekamo darbo tikslas;

ataskaitų teikimo reikalavimai;

darbo organizavimo tvarka;

Pavyzdys iš pirmiau minėto GOST 19.201-78.

įvadas;

plėtros pagrindas;

plėtros tikslas;

reikalavimai programai ar programinės įrangos produktui;

reikalavimai programinės įrangos dokumentacijai;

techniniai ir ekonominiai rodikliai;

raidos etapai ir etapai;

kontrolės ir priėmimo tvarka;

į techninę užduotį leidžiama įtraukti paraiškas.

Toliau pateikiamas konsultavimo paslaugų teikimo TOR pavyzdys

Bendrosios nuostatos;

Tikslas;

kvalifikaciniai reikalavimai kandidatams.

TOR pavyzdys tiriamajam darbui „Technologijų ir inovacijų parko Permės mieste kūrimo koncepcijos, plėtros strategijos ir galimybių studijos sukūrimas“ (toliau – MTEP) pavyzdys.

tyrimų pagrindu

atlikėjas ir bendraatlikėjai

1. tyrimo uždaviniai

   pradiniai duomenys

   pagrindiniai reikalavimai atliekant tyrimus

   kalendorinis tyrimų vykdymo planas

   numatytas tyrimo rezultatų panaudojimas

   tyrimo rezultatų įteikimo ir priėmimo tvarka

MTTP šablono struktūros pavyzdys

Pagrindas darbui

Vykdytojas

Darbo sąlygos

Darbo tikslas

MTEP rezultatai

Kuriami produktai

Techniniai reikalavimai

Pagrindiniai parametrai, kuriuos reikia pasiekti atlikus darbą:

Pagrindiniai dizaino reikalavimai (jei taikoma)

Reikalavimai pagal užstato rūšis (jei taikoma)

Standartizavimo, unifikavimo, suderinamumo su besijungiančiais objektais ir pakeičiamumo reikalavimai.

Žmonių gyvybės ir sveikatos saugos bei aplinkos apsaugos užtikrinimo reikalavimai

Patikimumo reikalavimai (jei taikoma)

Patikimumo ir ilgaamžiškumo reikalavimai.

Ergonomikos ir techninės estetikos reikalavimai (jei taikoma)

Eksploatacijos, tinkamumo naudoti ir techninės priežiūros reikalavimai (jei taikoma)

Atsparumo reikalavimai (jei taikoma)

Veikimo reikalavimai (jei taikoma)

Sertifikavimo reikalavimai

Kiti reikalavimai ir specialūs reikalavimai pagal pramonės šaką

Patento grynumo ir patentabilumo reikalavimai

Reikalavimai dokumentacijai

Darbų priėmimo tvarka.

Taigi, analizuojant pateiktuose pavyzdžiuose pateiktą struktūrą, galima pastebėti, kad TK struktūrą ir turinį padiktuoja užduotis, kurią reikia atlikti.

Inovatyvaus projekto techninių specifikacijų kūrimo ypatumai

Inovatyvūs projektai yra unikalūs renginiai, nes jie siejami su mokslinių ir techninių idėjų pavertimu naujais ar patobulintais produktais, taip pat naujais ar patobulintais technologiniais procesais, naudojamais praktinėje veikloje, arba į naujus požiūrius į socialines paslaugas. Reikia daryti tai, ko dar niekada nebuvo. Ir ankstesnė patirtis gali tik ribotai parodyti, ko tikėtis. Todėl inovatyvūs projektai turi didelį neapibrėžtumo ir rizikos laipsnį, ir tai yra jų ypatumas.

Kuriant inovatyvų projektą, siekiama rasti sprendimus, kaip išgauti numatytą galutinę projekto idėją ir sukurti užduočių bei veiklų rinkinį, kurį šiam novatoriškam projektui įgyvendinti susietų laikas, ištekliai ir vykdytojai. Bet koks inovatyvus projektas jo įgyvendinimo metu eina tam tikru keliu: nuo idėjos kūrimo fazės iki idėjos neaktualumo fazės. Techninių specifikacijų rengimo etapas reiškia pradinį naujoviško projekto etapą.

Inovatyviame projekte, kuriant visiškai naujas produktas sunku iš anksto suplanuoti visus parametrus, todėl siūloma naudoti dinaminį išplėstinį TOR, kuris daugiausia yra aprašomasis.

Pirmas žingsnis po naujo produkto idėjos sugeneravimo yra reikalavimų katalogas, kuriame gali būti klientų reikalavimai, naujo produkto rinkos segmentacija, normos, standartai, bendri tikslai (rinkos dalis, išlaidos), laikas iki rinkos, gyvavimo ciklas, bendra rizika. įvertinimas.

Reikalavimų kataloge nurodyti rodikliai yra nurodyti dokumente, kuris vadinamas išplėstine užduotimi.

Jei reikalavimų katalogas sudarytas „klientų kalba“, tai išplėstinis TOR yra „įmonės kalba“. Į išplėstą TNI, be tradicinių dalykų (darbo apimtis, ataskaitų teikimas, pradiniai duomenys, parametrų reikalavimai ir kt.), turėtų būti įtraukti kai kurie projekto verslo plano elementai (numatoma kainų politika, planuojama rinkos dalis, planuojama apyvarta ir kt. .) .

Kadangi reikalavimų katalogas kuriamas kliento požiūriu, reikalavimų katalogo rašymo kalba taip pat parenkama taip, kad būtų suprantama klientui (be konkrečių techninių detalių). Reikalavimų katalogas atspindi įmonės pasiūlymus, atsižvelgiant į klientų poreikius.

Išplėstas TOR gali apimti:

1. Projekto aprašymas

2. Rinkos ir ekonominiai projekto tikslai

3. Laiko nustatymo parametrai

4. Techniniai parametrai

5. Gamybos parametrai

8. Reikalavimai dizainui ir ergonomikai

9. Standartai ir taisyklės

Taigi pagrindinis išplėstinio TOR sudarymo uždavinys yra surinkti kuo išsamesnę informaciją apie kuriamą produktą, į kurią atsižvelgiama planuojant.

Išplėstinė TOR informacija papildomai patikslinama atsižvelgiant į produkto struktūrą, kuri yra visų komponentų, kurie sudarys projekto rezultatą, sąrašas. Projekto rezultatų struktūros plane yra visi kuriamo produkto komponentai, blokai, mazgai.

Svarbiausi TOR elementai yra: darbo tikslas, rezultatų apimtis, darbo turinys, jo įgyvendinimo programa, techniniai, ekonominiai ir kiti rodikliai, reikalavimai darbui, lygis ir būdas. jo įgyvendinimo, darbo rezultatus, laukiamų rezultatų mokslinę, mokslinę, techninę ir praktinę vertę; numatomas rezultatų panaudojimas ir ataskaitinės medžiagos tipas, pateikimo forma.

Apsvarstykite TK vietą struktūroje inovacijų procesas organizacijoje(naujovės organizacijoje) pagal .

Iš pradžių kuriama inovacijų koncepcija. Prieš kurį vyksta tyrimo etapas (organizacijos apklausa, būsimos inovacinės veiklos veiklos rodiklių parinkimas, inovacijoms įgyvendinti reikalingų veiklų sąrašo pagrindimas). Suburtos kūrėjų komandos inovacijų koncepcija išsiskleidžia į inovatyvaus projekto kūrimo užduotį (TOR), kurioje turėtų būti visi pagrindimai, pradiniai nustatymai ir parametrai, reikalingi tolesniam projektavimui.

Remiantis inovatyvaus projekto kūrimo užduotimi, sudaromas detalus veiksmų planas atskiroms užduotims parengti ir spręsti, taip pat jų vykdymui stebėti (kontrolės taškai pagal terminus, kontroliuojamų parametrų sąrašas, kontrolės kriterijai). ir kt.). Tiesą sakant, darbo užduotys, veiksmų planas yra naujoviško projekto kūrimo pagrindas.

Projekto turinys – planuojamų veiklų aprašymas ir reglamentai, optimalaus išteklių panaudojimo skaičiavimai, numatomų įgyvendinimo rezultatų įvertinimas, suvestas į kiekybines reikšmes. Inovatyvaus projekto pagrindas yra jo organizacinė ir finansinė dalys. Po to seka projekto pritaikymo ir įgyvendinimo etapai bei projekto rezultatų analizė.

Patvirtinus TOR kaip dokumentą, atliekamas projekto darbų planavimas.

Iš autoriaus: Kaip rašyti tinklalapio kūrimo sąlygos? Tema yra gana plati, o viename straipsnyje sunku ją išardyti 100% (jei įmanoma). Tačiau bendrąsias nuostatas, į ką reikia atsižvelgti, į ką turėtumėte atkreipti dėmesį rengdami TOR, pabandysiu pakankamai išsamiai išdėstyti šiame straipsnyje.

Taigi, TK

Darbo sąlygos sudaromos svetainės kūrėjui. Sudarant sutartį tarp užsakovo ir rangovo būtina remtis TK. Turėtų būti nustatyta abiejų pusių atsakomybė už TOR punktų ir sąlygų nevykdymą arba neteisingą įvykdymą. Bet svarbiausias dalykas (mano nuomone), kuriam sukurtas TK, skirtas pagreitinti svetainės kūrimo procesą.

Išanalizuokime šį pavyzdį:

Tarkime, kad jums reikia kalendoriaus kažkur jūsų svetainės šone. Tai atrodė smulkmena. Tačiau kuo daugiau aprašysite šio kalendoriaus funkcionalumą, tuo greičiau gausite rezultatą.

Aš čia šiek tiek paaiškinsiu. Kalendorius kitoks. Yra kalendorius, kuriame tiesiog rodomi einamojo mėnesio savaitės dienų skaičiai. Yra kalendorius su galimybe slinkti per mėnesius. Yra kalendorius su galimybe vartyti mėnesius ir metus.

Tarkime, jums reikia naujausios kalendoriaus versijos (su galimybe slinkti mėnesius ir metus) su paryškinta dabartine data. TOR nurodėte: „Šoninėje juostoje reikalingas kalendorius“. Klientas jums padaro pirmąją kalendoriaus versiją (tiesiog rodo skaičius pagal einamojo mėnesio savaitės dienas).

Ką mes turime. Rangovas užbaigė TK punktą, bet jūs norėjote visai kitokio kalendoriaus. Atrodo, kad viskas pagal TOR, niekas nekaltas, ne taip konfliktavo, bet svarbiausia prarasta laiko ir pinigų.

Tai tiesiog banalaus kalendoriaus pavyzdys.

O jei teks perdaryti ką nors rimtesnio, kurio apdorojimas užtrunka daugiau nei pusę dienos, kaip būna su kalendoriumi? Ir jūs neturite svetainės, o klientas su jumis maišosi, nors galėtų užbaigti jūsų projektą ir pradėti naują.

Todėl nei daugiau Jei aprašysite kiekvieno svetainės modulio funkcionalumą, tuo greičiau gausite rezultatą. Tuo turėtų būti suinteresuotos abi pusės.

Iš kokių elementų paprastai susideda TOR?

Įsivaizduokime, kad esate kokios nors įmonės ar firmos savininkas. Jūsų įmonė užsiima bet kokio produkto gamyba ir jos įgyvendinimu. Turite pirkėjų. Bendradarbiaujate su pardavėjais (parduotuvėmis ir internetinėmis parduotuvėmis), paslaugų centrais, prekių vartotojais. Arba kuriate interneto svetainę tokiai įmonei ir reikia parašyti techninę specifikaciją.

Nepriklausomai nuo to, kokį vaidmenį atliekate, pirmiausia reikia ištirti organizacijos struktūrą, jos veiklą, nomenklatūrą, charakteristikas ir apskritai viską, kas susiję su produktu ir įmone. Nuo to, kaip giliai klientas įsigilins į to, kas vyksta įmonėje, esmę, priklauso nuo to, kas vyks svetainėje. Todėl užduotis čia yra abipusė: klientas turėtų kuo išsamiau papasakoti apie įmonę, o atlikėjas turi gerai suprasti to, kas vyksta.

Net jei jūs pats rašote technines specifikacijas įmonei, kuri gamins svetainę, visai tai įvertinti ant popieriaus lapo nėra blogai.

Eikime prie punktų.

Svetainės aprašymas

Čia galite pora sakinių parašyti apie įmonę, kuo ji užsiima. Padarykite kažką panašaus į įžangą.

kam – tikslinė svetainės auditorija:

• potencialių pirkėjų
• prekių pardavėjai (parduotuvės, internetinės parduotuvės)
• aptarnavimo centrai
• partneriai (firmos)
• produktų vartotojai (tie, kurie jau nusipirko)

Kodėl jums reikalinga svetainė:

• Gerinti įmonės įvaizdį
• Norėdami padidinti pardavimus
• Klientų patogumui

Svetainės tipas:

• Įmonės
• Tinklalapis – vizitinė kortelė
• Internetinė parduotuvė

Kalbos versijos:

• Anglų
• rusų

Svetainė turi išspręsti kai kurias problemas. Atitinkamai mes judame toliau pagal svetainės tikslus ir uždavinius.

Svetainės tikslai ir uždaviniai

Šiame TOR skyriuje apžvelgiame visą tikslinę auditoriją ir aprašome užduočių, kurias svetainė turėtų jai išspręsti, spektrą.

Potencialūs prekių pirkėjai.

Tikslas: pritraukti daugiau pirkėjų ir įtikinti juos atlikti pirmąjį pirkinį, padėti apsispręsti.

Problemas reikia spręsti:

Suteikite kokybišką, išsamią informaciją apie gaminius, papildomas paslaugas, garantijas, aptarnavimą, atrankos būdus.

• Pateikite informaciją apie parduotuves
• Pateikite mažmeninės prekybos informaciją

Suteikite galimybę užduoti klausimą per įmonės specialistų organizuojamas potencialių pirkėjų konsultacijas internetu dėl produktų pasirinkimo, pirkimo.

Taigi mes einame per visą tikslinę auditoriją. Jei sekate mūsų svetainę, aprašome tikslus ir uždavinius produktų pardavėjams (parduotuvėms, internetinėms parduotuvėms), paslaugų centrams, partneriams (įmonėms), produktų vartotojams. Tai yra, ką svetainė turėtų padaryti konkrečiai kiekvienam iš jų.

Dabar mes išvardijame svetainės modulius.

Svetainės funkcionalumas

Norėdami išvardyti svetainės funkcijas, turite nuspręsti, ko jai reikia:

• Ar jums reikia naujienų svetainėje
• Ar jums reikia skelbimų bloko?
• Ar reikalinga registracija
• Ar man reikia privačios svetainės dalies (tik registruotiems vartotojams)
• Ar jums reikia atsiliepimų formos?
• Ar man reikia pašto scenarijaus
• ir kt. ir taip toliau.

Po to, kai visa tai buvo aprašyta, pereiname prie svarbiausio ir įdomiausio. Žinoma, visi aukščiau atlikti darbai yra labai svarbūs, bet dabar darosi dar „karščiau“.

Svetainės funkcionalumo aprašymas

Šiuo metu žinome, kam svetainė skirta, kokius tikslus ir užduotis ji turėtų atlikti, jos papildomas funkcionalumas.

Atėjo laikas, kai reikia sunešti visą surinktą informaciją į sistemą ir gražiai įdėti į svetainę. Kad būtų lengviau ir neišradinėtumėte dviračio iš naujo, galite pažvelgti į panašių temų svetaines. Sužinokite ką nors iš jų, pamatykite ir išbandykite jų funkcionalumą ir pabandykite patobulinti tai, kas jūsų svetainėje atrodė nepatogu. Iš principo galite pažvelgti į panašių temų svetaines (o jei neturite patirties, tada net reikia) pačioje TOR sudarymo pradžioje.

Siūlau pradėti nuo meniu punktų. Ji turi rodyti pagrindinius svetainės puslapius ir užtikrinti, kad kiekvienas lankytojas greitai surastų informaciją sau. O lankytojai yra mūsų tikslinė auditorija. Meniu bus daug elementų, todėl jis bus išskleidžiamojo sąrašo pavidalu.

Pirmiausia turite papasakoti apie įmonę. Gali būti puslapių apie įmonę, įmonės istoriją, kontaktus, atsiliepimus.

Natūralu, kad meniu turėtų būti elementas „produktai“ su antriniais punktais „ Produktų katalogas“, „išleidimai“, „produktų apžvalgos“.

Apskritai, tikiuosi, aišku, kaip piešti. Pateiksiu galutinę galimo mūsų svetainės meniu versiją:

Apie įmonę

• įmonės istorija
• kontaktai
• apžvalgos

žinios

• įvykius
• atsargos
• naujas vietoje

Produktai

• Produktų katalogas
• išleidžia
• produktų apžvalgos

Aptarnavimas

• aptarnavimo skyrius
• garantinis aptarnavimas
• pogarantinis aptarnavimas

Vartotojas

• pirkimas ir pristatymas
• naudoti
• apie paslaugą

Parduotuvės ir internetinės parduotuvės

• produktų nuotraukos
• DUK

Aptarnavimo centrai

• Kaip tapti paslaugų centru
• DUK

Partneriai

• kvietimas bendradarbiauti
• DUK

Mes tarsi išsiaiškinome meniu. Dabar reikia aprašyti, kas bus kiekviename puslapyje ir kaip visa tai veikia apskritai. Be to, pateikite apytikslį svetainės išdėstymą. Jį galima nupiešti ant popieriaus lapo pieštuku, nuskenuoti ir pritvirtinti prie TK. Pasakysiu tik tiek, kad neribokite dizainerio fantazijos, nubraižykite ją pačia bendriausia forma.

Ši dalis keičiasi priklausomai nuo to, kaip norite, kad jūsų puslapis atrodytų. Gal nereikia tiek daug banerių viršuje, gal reikia nurodyti kontaktus viršuje (adresas, telefonas, faksas), gal piktogramų pavidalu "svetainės žemėlapis", "namai", "kontaktai". Galbūt jums nereikia naujienų kairėje, bet kairėje rodykite „akcijas ir leidimus“.

Dabar svarbiausia apibūdinti darbo logiką.

Veikimo logika

Aprašysiu remdamasis aukščiau esančiu paveikslu.

Svetainės viršus kiekviename svetainės puslapyje išlieka toks pat. Naujienų kanalas matomas tik pagrindinis puslapis. Kairėje esančiuose antriniuose puslapiuose rodome prekės, kurioje šiuo metu esame, meniu poskyrius (pavyzdžiui, jei esame „serviso“ puslapyje, tada rodome nuorodas į „garantinis aptarnavimas“, „paštas“ -garantinis aptarnavimas“). Atitinkamai, šių nuorodų perėjimai nukreipia į atitinkamus puslapius. Čia, po antriniais punktais kairėje, rodome duomenis, skirtus susisiekti su internetiniais konsultantais (Skype, ICQ). Blokuoti reklamas ir leidimus lieka kiekviename puslapyje. Svetainės poraštė rodoma vienodai kiekviename puslapyje.

Maždaug taip aprašoma bendra darbo logika.

Dabar mes išsamiai aprašome kiekvieną bloką. Pavyzdžiui, „Naujienų kanalas“.

10 „Naujienų srautas“. Naujausios naujienos. Kiekvieną naujieną turi sudaryti naujienos pavadinimas, paskelbimo data, trumpa naujienos pradžia (4–5 eilutės) ir nuoroda „skaityti visą“. Paspaudę nuorodą „skaityti visą“ patenkame į naujienų puslapį. Nukentėjusios naujienos rodomos vietoje pagrindinio turinio. Jame taip pat yra naujienos pavadinimas, paskelbimo data. Naujienų kanalas taip pat rodomas kairėje. Ankstesnių mėnesių ir metų žinios archyvuojamos. Tai yra, po einamojo mėnesio naujienomis rodome „(tokio ir tokio mėnesio ar metų) archyvą“. Kai paspausite žemyn nuorodą „archyvas (tokio mėnesio ar metų)“, iškrenta atitinkamo mėnesio / metų naujienų sąrašas.

Taip aprašome kiekvieno bloko veikimą. Nepamirškime atvejo su kalendoriumi. Ir svarbiausia, jums reikia nudažyti gaminių katalogo darbą. Štai duodu tau užduotį: pabandykite pagalvoti ir aprašyti, kaip veiks katalogas. Savo galimybes siųskite el. Mes paskelbsime geriausią.

Kas dar turėtų būti? Būtų malonu nurodyti suderinamumą.

Suderinamumas

Šioje pastraipoje nurodome, kuri Operacinės sistemos ir kuriose naršyklėse svetainė turėtų atrodyti vienodai gerai. Kokia versija, kokia kalba turėtų būti rašoma. Kokia TVS naudojama. Verta atkreipti dėmesį, jei tikrai suprantate, apie ką kalbate.

Jei šie klausimai jums nepriklauso, tiesiog nurodykite naršykles, kuriose svetainė turėtų būti rodoma teisingai. Dėl kitų pasikliaukite atlikėjo sąžine.

Išvada

Šiame straipsnyje aš nesiekiau parodyti, kad TK sudaromas taip, o ne daugiau. Padarykite tai ir neturėsite jokių problemų. Aukštos kokybės TOR sudarymas yra labiau patirties reikalas. Pirmoje poroje ne visiems pavyks sudaryti kompetentingą TK.

Šiame straipsnyje norėjau parodyti principus, kuriais remiantis kuriamos techninės užduotys, pagrindinius dalykus, į kuriuos verta atkreipti dėmesį. Kiek man pavyko, tikiuosi pasimokyti iš jūsų komentarų.

Ir nepamirškite iššūkio!

Manęs dažnai klausia: „Kaip parengti techninę užduotį automatizuotai sistemai?“. Panaši tema nuolat diskutuojama įvairiuose forumuose. Šis klausimas yra toks platus, kad į jį neįmanoma atsakyti trumpai. Todėl nusprendžiau parašyti ilgą straipsnį šia tema.

• Pirmoje dalyje " Techninių specifikacijų rengimas. Kas tai yra, kodėl to reikia, nuo ko pradėti ir kaip turėtų atrodyti? Pabandysiu išsamiai atsakyti į temos klausimus, apžvelgsiu techninės užduoties struktūrą ir paskirtį, pateiksiu keletą rekomendacijų dėl reikalavimų formulavimo.
• Antra dalis " Techninių specifikacijų rengimas. Kaip suformuluoti reikalavimus? bus visiškai skirtas reikalavimams nustatyti ir formuluoti informacinė sistema.

Pirmiausia turite išsiaiškinti, koks klausimas iš tikrųjų domina tuos, kurie klausia "Kaip parengti techninę užduotį?" Faktas yra tai, kad požiūris į techninių specifikacijų kūrimą labai priklausys nuo tikslų, kuriems tai bus daroma, ir nuo to, kas jį naudos. Apie kokius variantus kalbu?

• Komercinė organizacija nusprendė įdiegti automatizuotą sistemą. Ji neturi savo IT paslaugos ir nusprendė tai padaryti: Suinteresuotas asmuo turi parengti techninę užduotį ir perduoti ją parengti trečiosios šalies organizacijai;
• Komercinė organizacija nusprendė įdiegti automatizuotą sistemą. Ji turi savo IT paslaugą. Mes nusprendėme tai padaryti: parengti techninę užduotį, tada derinti ją tarp IT tarnybos ir suinteresuotų šalių ir įgyvendinti savo jėgomis;
• Valstybės struktūra nusprendė pradėti IT projektą. Viskas čia taip purvina, daug formalumų, atatrankų, pjūvių ir tt Šiame straipsnyje šio varianto nenagrinėsiu.

• IT įmonė užsiima automatizuotų sistemų kūrimo ir/ar diegimo paslaugomis. Tai pats sunkiausias atvejis, nes tenka dirbti įvairiomis sąlygomis:

  • Klientas turi savo specialistus, turinčius savo nuomonę, ir jiems keliami specifiniai techninės užduoties reikalavimai;
  • Darbo sąlygos rengiamos mūsų pačių kūrėjams (klientui tai nerūpi);
  • Darbo užduotys rengiamos perdavimui rangovui (t. y. programuotojų grupei, nepriklausančiai įmonės personalui, arba individualiam specialistui);
  • Tarp įmonių ir kliento kyla nesusipratimas dėl gauto rezultato, ir įmonė vėl ir vėl užduoda klausimą: „Kaip reikėtų parengti techninę užduotį?“. Pastarasis atvejis gali atrodyti kaip paradoksas, bet tai tiesa.
  • Galimi ir kiti, rečiau paplitę variantai;

Manau, kad dabar skaitytojui turėtų kilti klausimų:

• Kodėl techninės užduoties sąlygos negali būti visada rengiamos vienodai?;
• Ar yra kokių nors standartų, metodų, rekomendacijų? Kur jų gauti?
• Kas turėtų parengti techninę užduotį? Ar šis asmuo turi turėti kokių nors specialių žinių?
• Kaip suprasti, ar techninė užduotis yra gerai surašyta, ar ne?
• Kieno sąskaita jis turėtų būti plėtojamas ir ar apskritai to reikia?

Šis sąrašas gali būti begalinis. Kalbu taip užtikrintai dėl to, kad jau 15 metų dirbu profesionalaus programinės įrangos kūrimo srityje, o užduoties sąlygos iškyla bet kurioje kūrimo komandoje, su kuria turiu dirbti. To priežastys yra skirtingos. Keldamas Techninės užduoties rengimo temą, puikiai suprantu, kad 100% jos pristatyti visiems besidomintiems tema nepavyks. Bet aš pabandysiu, kaip sakoma, „viską sudėti į lentynas“. Tie, kurie jau yra susipažinę su mano straipsniais, žino, kad aš nenaudoju svetimų darbų „copy-paste“, neperspausdinu svetimų knygų, necituoju kelių puslapių standartų ir kitų dokumentų, kuriuos patys galite rasti internete, perteikdamas jas kaip savo nuostabias mintis. Pakanka į paieškos sistemą įvesti „Kaip sukurti techninę užduotį“ ir galėsite perskaityti daug įdomaus, bet, deja, kartojamo daugybę kartų. Paprastai tie, kurie mėgsta būti sumanūs forumuose (visgi pabandykite ieškoti!), patys niekada nesudarė protingų techninės užsakymo sąlygų ir nuolat cituoja GOST rekomendacijas šiuo klausimu. O tie, kurie tikrai rimtai sprendžia šią problemą, dažniausiai neturi laiko sėdėti forumuose. Beje, kalbėsime ir apie GOST. Per savo darbo metus mačiau daugybę techninės dokumentacijos variantų, sudarytų tiek pavienių specialistų, tiek iškilių komandų ir konsultacinių įmonių. Kartais užsiimu ir tokia veikla: skiriu laiko sau ir ieškau informacijos dominančia tema iš neįprastų šaltinių (tokia maža žvalgyba). Dėl to teko matyti dokumentus apie tokius monstrus kaip Gazprom, Rusijos geležinkeliai ir daug kitų įdomių kompanijų. Žinoma, aš laikausi konfidencialumo politikos, nepaisant to, kad šie dokumentai man atkeliauja iš viešų šaltinių ar konsultantų neatsakingumas (jie išbarsto informaciją internete). Todėl iš karto sakau: aš nesidalinu konfidencialia informacija, kuri priklauso kitoms įmonėms, nepaisant atsiradimo šaltinių (profesinė etika).

Kas yra techninė užduotis?

Pirmas dalykas, kurį dabar padarysime, yra išsiaiškinti, koks tai gyvūnas, „Referencijos sąlygos“.

Taip, tikrai yra GOST ir standartai, kuriuose bandoma reguliuoti šią veiklos dalį (programinės įrangos kūrimą). Kadaise visi šie GOST buvo aktualūs ir aktyviai naudojami. Dabar yra įvairių nuomonių dėl šių dokumentų aktualumo. Kai kurie teigia, kad GOST sukūrė labai toliaregiški žmonės ir jie vis dar aktualūs. Kiti sako, kad jie beviltiškai pasenę. Galbūt kažkas dabar pagalvojo, kad tiesa yra kažkur per vidurį. Atsakyčiau Gėtės žodžiais: „Sako, tarp dviejų priešingų nuomonių slypi tiesa. Jokiu būdu! Tarp jų yra problema“. Taigi, tarp šių nuomonių nėra tiesos. Nes GOST neatskleidžia praktinių šiuolaikinės plėtros problemų, o juos kritikuojantys alternatyvų (specifinių ir sisteminių) nepasiūlo.

Atkreipkite dėmesį, kad GOST aiškiai net nepateikia apibrėžimo, o tik sako: „AE TOR yra pagrindinis dokumentas, apibrėžiantis automatizuotos sistemos sukūrimo (plėtojimo ar modernizavimo - tolesnio kūrimo) reikalavimus ir tvarką. su kuria vykdoma AE plėtra ir jos priėmimas pradėjus eksploatuoti“.

Jei kam nors įdomu, apie kokius GOST aš kalbu, tai štai jie:

• GOST 2.114-95 Vieninga projektinės dokumentacijos sistema. Specifikacijos;
• GOST 19.201-78 Vieninga programos dokumentacijos sistema. Techninė užduotis. Reikalavimai turiniui ir dizainui;
• GOST 34.602-89 Informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Automatizuotos sistemos sukūrimo techninė užduotis.

Daug geresnis apibrėžimas pateiktas Vikipedijoje (tiesa apie TK apskritai, o ne tik programinei įrangai): „ Techninė užduotis yra originalus projekto dokumentas techninis objektas. Techninė užduotis nustato pagrindinę kuriamo objekto paskirtį, jo technines ir taktines bei technines charakteristikas, kokybės rodiklius ir techninius bei ekonominius reikalavimus, nurodymus atlikti būtinus dokumentacijos (projekto, technologinės, programinės įrangos ir kt.) kūrimo etapus ir jos sudėtį, kaip taip pat specialius reikalavimus. Užduotis, kaip pirminis dokumentas, skirtas sukurti kažką naujo, egzistuoja visose veiklos srityse, kurios skiriasi pavadinimu, turiniu, vykdymo tvarka ir pan. (pavyzdžiui, projektavimo užduotis statyboje, kovinė užduotis, namų darbai, sutartis literatūros kūrinys ir pan.). e.)"

Taigi, kaip matyti iš apibrėžimo, pagrindinis techninės užduotys tikslas yra suformuluoti reikalavimus kuriamam objektui, mūsų atveju – automatizuotai sistemai.

Tai pagrindinis, bet vienintelis. Laikas imtis pagrindinio dalyko: viską sudėti „į lentynas“, kaip žadėta.

Ką reikia žinoti apie reikalavimus? Reikia aiškiai suprasti, kad visi reikalavimai turi būti suskirstyti pagal tipą ir savybes. Dabar mes išmoksime tai padaryti. Norėdami atskirti reikalavimus pagal tipą, GOST mums tiesiog padės. Ten pateiktas reikalavimų tipų sąrašas yra geras pavyzdys, į kokius reikalavimus reikėtų atsižvelgti. Pavyzdžiui:

• funkcionalumo reikalavimai;
• Reikalavimai saugumui ir prieigos teisėms;
• Reikalavimai personalo kvalifikacijai;
• …. ir kt. Apie juos galite perskaityti minėtame GOST (o žemiau taip pat apžvelgsiu juos šiek tiek išsamiau).

Manau, kad jums akivaizdu, kad gerai suformuluoti funkcionalumo reikalavimai yra sėkmingos techninės užsakymo sąlygos. Būtent šie reikalavimai yra skirti daugumai darbų ir metodų, apie kuriuos kalbėjau. Funkcionalumo reikalavimai sudaro 90 % techninės užduoties kūrimo sudėtingumo. Visa kita dažnai yra „kamufliažas“, kuris keliamas šiems reikalavimams. Jei reikalavimai suformuluoti prastai, tai kad ir kokį gražų kamufliažą juos uždėtumėte, sėkmingas projektas nepasiteisins. Taip, formaliai visi reikalavimai bus įvykdyti (pagal GOST J), TOR parengtas, patvirtintas ir pasirašytas, už tai gauti pinigai. Ir ką? Ir tada prasideda linksmybės: ką daryti? Jeigu tai projektas dėl Valstybės užsakymo, tai nėra problemų - yra toks biudžetas, kad netilps į jokią kišenę, viskas išsiaiškins vykdymo procese (jei yra). Būtent tokiu būdu yra pjaunama didžioji dalis projektų pagal Valstybės užsakymus biudžetų (padegė „TK“, sujungė dešimtis milijonų, bet projekto nepradėjo daryti. Visi formalumai buvo sutvarkyti, kaltų nebuvo, naujas automobilis prie namo.Grožis!). Bet mes kalbame apie komercines organizacijas, kur pinigai skaičiuojami, o rezultatas kitoks. Todėl spręskime pagrindinį dalyką, kaip tobulėti naudingos ir veikiančios techninės sąlygos.

Aš sakiau apie reikalavimų tipus, o kaip su savybėmis? Jei reikalavimų tipai gali būti skirtingi (priklausomai nuo projekto tikslų), tai su savybėmis viskas yra paprasčiau, jų yra 3:

1. Reikalavimas turi būti suprantamas;
2. Reikalavimas turi būti betono;
3. Reikalavimas turi būti išbandyta;

Be to, paskutinis turtas neįmanomas be dviejų ankstesnių, t.y. yra savotiškas „lakmuso popierėlis“. Jei reikalavimo rezultatas negali būti patikrintas, jis arba neaiškus, arba nekonkretus. Pagalvok apie tai. Dėl šių trijų reikalavimų savybių slypi įgūdžiai ir profesionalumas. Tiesą sakant, viskas yra labai paprasta. Kai išsiaiškinsi.

Šią istoriją apie tai, kas yra techninės užduotys, galima užbaigti ir pereiti prie pagrindinio dalyko: kaip suformuluoti reikalavimus. Bet ne viskas taip greitai. Yra dar vienas nepaprastai svarbus punktas:

• kokia kalba (kalbant apie supratimo sudėtingumą) turėtų būti rašoma techninė užduotis?
• Ar jame turėtų būti aprašyta įvairių funkcijų specifikacija, algoritmai, duomenų tipai ir kiti techniniai dalykai?
• O kas yra techninis projektas, kuris, beje, yra paminėtas ir GOST, ir kaip jis susijęs su technine užduotimi?

Atsakymuose į šiuos klausimus slypi labai klastingas dalykas. Būtent todėl dažnai kyla ginčų dėl reikiamos reikalavimų specifikacijos pakankamumo ar nebuvimo, dėl dokumento suprantamumo užsakovui ir Rangovams, dėl pertekliškumo, pateikimo formato ir kt. O kur riba tarp techninės užduoties ir techninio projekto?

Techninė užduotis yra dokumentas, paremtas reikalavimais, suformuluotas Klientui suprantama (įprasta, pažįstama) kalba. Šiuo atveju galima ir turi būti vartojama Klientui suprantama pramonės terminija. Techninio įgyvendinimo ypatumai neturėtų būti įpareigoti. Tie. TK etape iš esmės nesvarbu, kurioje platformoje šie reikalavimai bus įgyvendinti. Nors yra išimčių. Jei kalbame apie sistemos, pagrįstos esamu programinės įrangos produktu, įgyvendinimą, tai toks susiejimas gali įvykti, bet tik ekrano formų, ataskaitų formų ir pan. verslo analitikas. Ir tikrai ne programuotojas (nebent jis derina šiuos vaidmenis, taip atsitinka). Tie. šis asmuo turėtų kalbėtis su Klientu jo verslo kalba.

Techninis projektas yra dokumentas, skirtas techniniam užduotyje suformuluotų reikalavimų įgyvendinimui. Tiesiog šiame dokumente aprašomos duomenų struktūros, trigeriai ir saugomos procedūros, algoritmai ir kiti dalykai, kurių reikės technikos specialistai. Klientui visiškai nebūtina į tai gilintis (jis gali nesuprasti tokių terminų). Tai daro techninis projektas Sistemos architektas(Čia šio vaidmens derinimas su programuotoju yra gana normalus). Tiksliau – AO specialistų grupė, vadovaujama architekto. Kuo didesnis projektas, tuo daugiau žmonių dirba su užduoties sąlygomis.

Ką mes turime praktikoje? Juokinga žiūrėti, kai direktorius atvežamas tvirtinti pagal techninę terminiją, duomenų tipų ir jų reikšmių aprašymus, duomenų bazių struktūrą ir t.t. Jis, žinoma, stengiasi suprasti, nes taip reikia. tvirtinti, stengiantis tarp eilučių rasti pažįstamus žodžius ir neprarasti grandininio verslo reikalavimų. Ką, pažįstama situacija? Ir kuo tai baigiasi? Paprastai tokie TOR yra patvirtinami, tada įgyvendinami ir 80% atvejų visiškai neatitinka atlikto darbo fakto, nes daug ką jie nusprendė pakeisti, perdaryti, nesuprato, neteisingai galvojo ir pan. ir taip toliau. Ir tada prasideda perdavimo serija. „Bet čia ne taip, kaip mums reikia“, o „tai mums neveiks“, „tai per sudėtinga“, „nepatogu“ ir pan. Pažįstamas?! Taigi žinau, kad turėjau laiku užpildyti iškilimus.

Taigi, ką mes turime praktiškai? Tačiau praktiškai mes turime neaiškią ribą tarp techninės užduotys ir techninio projekto. Jis plūduriuoja tarp TK ir TP įvairiais būdais. Ir tai yra blogai. Ir taip išeina, nes vystymosi kultūra susilpnėjo. Iš dalies taip yra dėl specialistų kompetencijos, iš dalies dėl noro sumažinti biudžetus ir terminus (juk dokumentacija atima daug laiko – tai faktas). Yra dar vienas svarbus veiksnys, turintis įtakos Techninio projekto, kaip atskiro dokumento, naudojimui: spartus greito kūrimo priemonių, taip pat kūrimo metodikų vystymas. Bet tai yra atskira istorija, apie tai pasakysiu keletą žodžių žemiau.

Dar vienas mažas, bet svarbus momentas. Kartais techninės užduotys vadinamos maža reikalavimų dalimi, paprasta ir suprantama. Pavyzdžiui, norėdami patikslinti objekto paiešką pagal tam tikras sąlygas, pridėkite stulpelį prie ataskaitos ir pan. Toks požiūris yra gana pagrįstas, kam apsunkinti gyvenimą. Tačiau jis naudojamas ne dideliems projektams, o nedideliems patobulinimams. Sakyčiau, tai yra arčiau programinės įrangos produkto priežiūros. Šiuo atveju Techninėje užduotyje gali būti aprašytas ir konkretus techninis reikalavimo įgyvendinimo sprendimas. Pavyzdžiui, „Padaryti tokį ir tokį algoritmo pakeitimą“, nurodant konkrečią procedūrą ir konkretų pakeitimą programuotojui. Taip yra tada, kai visiškai panaikinama riba tarp techninių užduočių ir techninių projektų, nes nėra ekonominės galimybės išpūsti popierizmą ten, kur jų nereikia, ir sukuriamas naudingas dokumentas. Ir tai yra teisinga.

Ar jums tikrai reikia techninės specifikacijos? O kaip su inžineriniu projektu?

Ar aš perkaitinau? Ar tai įmanoma net be įgaliojimai? Įsivaizduokite galbūt (tiksliau, pasitaiko), ir šis požiūris turi daug pasekėjų, ir jų daugėja. Paprastai po to, kai jauni specialistai perskaito knygas apie Scrum, Agile ir kitas sparčiai vystomas technologijas. Tiesą sakant, tai yra nuostabios technologijos ir jos veikia, tik jose tiesiogine prasme nepasakoma „nereikia atlikti techninių užduočių“. Sako „minimaliai popierizmo“, ypač nereikalingų, arčiau Kliento, konkretesnė ir greitesni rezultatai. Bet niekas neatšaukė reikalavimų nustatymo, ir ten tai aiškiai pasakyta. Būtent ten reikalavimai nustatomi remiantis trimis nuostabiomis savybėmis, apie kurias kalbėjau aukščiau. Tiesiog kai kurių žmonių sąmonė taip išsidėsčiusi, kad jei galima ką nors supaprastinti, tai supaprastinkime iki visiško nebuvimo. Kaip sakė Einšteinas " Padarykite tai kuo paprasčiau, bet ne paprasčiau. . Auksiniai žodžiai tinka prie visko. Taigi Techninė užduotis būtina, kitaip nepavyks pamatyti sėkmingo projekto. Kitas klausimas – kaip sudaryti ir ką ten įtraukti. Sparčiai tobulėjančių metodikų šviesoje reikia koncentruotis tik į reikalavimus, o viso „kamufliažo“ galima išmesti. Iš esmės aš su tuo sutinku.

O kaip su techniniu projektu? Šis dokumentas yra labai naudingas ir neprarado savo aktualumo. Be to, dažnai be jo tiesiog neįmanoma. Ypač kalbant apie vystymo darbų perdavimą iš išorės, t.y. užsakomųjų paslaugų pagrindu. Jei to nepadarysite, rizikuojate daug sužinoti apie tai, kaip turėtų atrodyti jūsų turima sistema. Ar klientas turėtų jį pažinti? Jei jis nori, kodėl gi ne, bet nereikia reikalauti ir tvirtinti šio dokumento, jis tik suvaržys ir trukdys dirbti. Beveik neįmanoma sukurti sistemos iki smulkmenų. Tokiu atveju turėsite nuolat keisti Techninį projektą, o tai užima daug laiko. Ir jei organizacija yra labai biurokratizuota, tada apskritai palikite visus nervus. Būtent apie tokį dizaino mažinimą kalbama šiuolaikinėse sparčios plėtros metodikose, kurias minėjau aukščiau. Beje, visi jie paremti klasikiniu XP (ekstremalaus programavimo) požiūriu, kuriam jau apie 20 metų. Taigi sudarykite kokybišką, užsakovui suprantamą Techninę užduotį ir naudokite Techninį projektą kaip vidinį sistemos architekto ir programuotojų santykių dokumentą.

Įdomi techninio projektavimo detalė: kai kurios kūrimo priemonės, išdėstytos pagal orientacijos į dalyką principą (pvz., 1C ir panašiai), leidžia manyti, kad projektavimas (tai yra dokumentacijos procesas) reikalingas tik tikrai sudėtingose ​​srityse, kur reikalinga sąveika tarp ištisų posistemių. Paprasčiausiu atveju, pavyzdžiui, norint sukurti žinyną, dokumentą, pakanka tik teisingai suformuluotų verslo reikalavimų. Tai liudija šios platformos verslo strategija specialistų rengimo prasme. Jei pažvelgsite į Egzamino bilietas specialistas (taip jis vadinamas, o ne „programuotoju“), tada pamatysite, kad yra tik verslo reikalavimai, o kaip juos įgyvendinti programavimo kalba – specialisto užduotis. Tie. tą užduoties dalį, kuriai spręsti skirtas Techninis projektas, specialistas turi išspręsti „galvoje“ (kalbame apie vidutinio sudėtingumo užduotis), o čia ir dabar, vadovaujantis tam tikrais kūrimo ir projektavimo standartais, kurie vėlgi yra sukūrė 1C kompanija savo platformai. Taigi iš dviejų specialistų, kurių darbo rezultatas atrodo vienodas, egzaminą galima išlaikyti, o antras – ne, nes. šiurkščiai pažeidė plėtros standartus. Tai yra, akivaizdu, kad daroma prielaida, kad specialistai turi turėti tokią kvalifikaciją, kad galėtų savarankiškai, neįtraukdami sistemų architektų, suprojektuoti tipines užduotis. Ir šis metodas veikia.

Tęskime klausimo tyrimą: „Kokie reikalavimai turi būti įtraukti į techninę užduotį?

Informacinės sistemos reikalavimų formulavimas. Techninės užduoties struktūra

Iš karto išsiaiškinkime: kalbėsime apie reikalavimų informacinei sistemai formulavimą, t.y. darant prielaidą, kad verslo reikalavimų kūrimo, verslo procesų įforminimo ir visi ankstesni konsultaciniai darbai jau baigti. Žinoma, šiame etape galima atlikti kai kuriuos patobulinimus, bet tik patobulinimus. Pats automatizavimo projektas neišsprendžia verslo problemos – turėkite tai omenyje. Tai yra aksioma. Kažkodėl kai kurie vadovai bando tai paneigti, manydami, kad jei nupirks programą, chaotiškame versle ateis tvarka. Bet juk aksioma yra aksioma, kuriai nereikia įrodymų.

Kaip ir bet kuri veikla, reikalavimų formulavimas gali būti (ir turėtų būti) suskirstytas į etapus. Viskam savas laikas. Tai sunkus intelektualinis darbas. Ir jei jis bus traktuojamas nepakankamai dėmesio, rezultatas bus tinkamas. Ekspertų vertinimu, techninės užduoties rengimo kaina gali siekti 30-50%. Aš esu tos pačios nuomonės. Nors 50 gal ir per daug. Juk techninė užduotis nėra paskutinis rengiamas dokumentas. Juk turi būti ir techninis projektas. Šis skirtumas atsiranda dėl skirtingų automatizavimo platformų, požiūrių ir technologijų, kurias projektų komandos naudoja kuriant. Pavyzdžiui, jei mes kalbame apie plėtrą klasikine kalba, tokia kaip C++, tada be išsamaus techninis projektasčia neužtenka. Jei mes kalbame apie sistemos įdiegimą 1C platformoje, tada situacija su dizainu yra šiek tiek kitokia, kaip matėme aukščiau (nors kuriant sistemą nuo nulio, ji sukurta pagal klasikinę schemą).

Nors reikalavimų formulavimas yra pagrindinė dalis įgaliojimai, o kai kuriais atvejais tai tampa vienintele ToR skyriumi, turėtumėte atkreipti dėmesį į tai, kad tai yra svarbus dokumentas ir jis turėtų būti atitinkamai surašytas. Kur pradėti? Pirmiausia reikia pradėti nuo turinio. Sukurkite turinį ir pradėkite jį išskleisti. Asmeniškai aš darau taip: pirmiausia išdėstau turinį, aprašau tikslus, visą įžanginę informaciją, o tada imuosi pagrindinės dalies – reikalavimų formulavimo. Kodėl gi ne atvirkščiai? Nežinau, man taip patogiau. Pirma, tai yra daug mažesnė laiko dalis (palyginti su reikalavimais), ir, antra, aprašydami visą įžanginę informaciją, prisiderini prie pagrindinio dalyko. Na, kam patinka. Laikui bėgant, jūs sukursite savo techninės užduoties šabloną. Pirmiausia rekomenduoju kaip turinį paimti būtent tą, kuris aprašytas GOST. Tai puikiai tinka turiniui! Tada imame ir pradedame apibūdinti kiekvieną skyrių, nepamirštant šių trijų savybių rekomendacijų: suprantamumo, specifiškumo ir tikrinamumo. Kodėl aš taip reikalauju? Daugiau apie tai kitame skyriuje. O dabar siūlau visapusiškai pereiti tuos TK punktus, kurie rekomenduojami GOST.

1. Bendra informacija;
2. sistemos kūrimo (plėtros) tikslas ir tikslai;
3. automatikos objektų charakteristikos;
4. Sistemos reikalavimai;
5. sistemos kūrimo darbo sudėtis ir turinys;
6. sistemos kontrolės ir priėmimo tvarka;
7. Darbo, skirto automatizavimo objektui parengti sistemos paleidimui, sudėties ir turinio reikalavimai;
8. dokumentacijos reikalavimai;
9. plėtros šaltiniai.

Iš viso 9 skyriai, kurių kiekvienas taip pat suskirstytas į poskyrius. Paimkime juos iš eilės. Patogumui prie kiekvienos prekės viską pateiksiu lentelės forma.

1 skyrius. Bendroji informacija.

Rekomendacijos pagal GOST
visas sistemos pavadinimas ir jos simbolis;	Čia viskas aišku: parašome, kaip sistema vadinsis, jos trumpąjį pavadinimą
temos šifras arba sutarties šifras (numeris);	Tai neaktualu, bet jei reikia, galite nurodyti.
sistemos kūrėjo ir užsakovo (naudotojo) įmonių (asociacijų) pavadinimas ir jų rekvizitai;	nurodyti, kas (kokios organizacijos) dirbs su projektu. Taip pat galite nurodyti jų vaidmenis.Šį skyrių galite išvis ištrinti (gana formalu).
dokumentų, kurių pagrindu kuriama sistema, sąrašas, kas ir kada šie dokumentai buvo patvirtinti;	Naudinga informacija. Čia turėtumėte nurodyti norminius ir informacinius dokumentus, kurie buvo pateikti norint susipažinti su tam tikra reikalavimų dalimi
planuojamos sistemos kūrimo darbų pradžios ir pabaigos datos;	Laiko palinkėjimai. Kartais apie tai rašo TOR, bet dažniau tokie dalykai aprašomi darbo sutartyse
informacija apie darbų finansavimo šaltinius ir tvarką;	Panašiai, kaip ir ankstesnėje pastraipoje apie laiką. Labiau tinka vyriausybės užsakymams (valstybės tarnautojams)
Sistemos (jos dalių) kūrimo, atskirų priemonių (techninės, programinės įrangos, informacijos) ir programinės ir techninės (programinės ir metodinės) kompleksų gamybos ir derinimo darbų rezultatų įforminimo ir pateikimo užsakovui tvarka. sistema.	Nematau šios pastraipos reikalo, tk. dokumentacijai keliami reikalavimai sudaromi atskirai, be to, yra visas atskiras skyrius „Sistemos kontrolės ir priėmimo tvarka“.

2 skyrius. Sistemos sukūrimo (plėtojimo) tikslas ir tikslai.

Rekomendacijos pagal GOST	Ką su juo daryti praktiškai
Sistemos paskirtis	Viena vertus, susitikimas yra paprastas. Bet norėčiau būti konkretus. Jei rašote kažką panašaus į „aukštos kokybės sandėlio apskaitos automatizavimas įmonėje X“, tuomet galite ilgai diskutuoti apie rezultatą jį užbaigus, net nepaisant geros reikalavimų formuluotės. Nes Klientas visada gali pasakyti, kad sakydamas kokybę jis turėjo omenyje ką kita. Apskritai nervai gali vienas kitą labai sugadinti, bet kodėl? Geriau iš karto parašyti maždaug taip: „Sistema skirta sandėlio apskaitai tvarkyti įmonėje X pagal šiose techninės užduotyse nustatytus reikalavimus“.
Sistemos kūrimo tikslai	Tikslai tikrai yra svarbi dalis. Jei jį įjungsime, turime sugebėti suformuluoti šiuos tikslus. Jei kyla sunkumų formuluojant tikslus, geriau iš viso neįtraukti šio skyriaus. Nesėkmingo tikslo pavyzdys: „Užtikrinkite greitą vadovo dokumentų tvarkymą“. Kas yra greitas? Tada tai gali būti įrodyta be galo. Jei tai svarbu, geriau suformuluoti šį tikslą taip: „Pardavimų vadybininkas turi turėti galimybę išduoti dokumentą“ Prekių pardavimas „100 eilučių per 10 minučių“. Toks tikslas gali atsirasti, jei, pavyzdžiui, vadovas šiuo metu tam skiria apie valandą, o tai šiai įmonei yra per daug ir jiems tai svarbu. Šioje formuluotėje tikslas jau kertasi su reikalavimais, o tai gana natūralu, nes. plėsdami tikslų medį (t.y. skaidydami juos į mažesnius susijusius tikslus), jau priartėsime prie reikalavimų. Todėl neturėtumėte nusivilti.

Apskritai, gebėjimas identifikuoti tikslus, juos suformuluoti, kurti tikslų medį yra visiškai atskira tema. Prisiminkite pagrindinį dalyką: jei žinote, kaip – ​​rašykite, jei nesate tikri – visai nerašykite. Kas atsitiks, jei nenustatysite tikslų? Dirbsite pagal reikalavimus, tai dažnai praktikuojama.

3 skyrius. Automatikos objektų charakteristikos.

4 skyrius Sistemos reikalavimai

GOST iššifruoja tokių reikalavimų sąrašą:

• reikalavimai sistemos struktūrai ir veikimui;
• reikalavimai sistemos darbuotojų skaičiui ir kvalifikacijai bei darbo režimui;
• paskirties rodikliai;
• patikimumo reikalavimai;
• saugos reikalavimai;
• ergonomikos ir techninės estetikos reikalavimai;
• gabenamumo reikalavimai mobiliajai AS;
• sistemos komponentų eksploatavimo, priežiūros, remonto ir saugojimo reikalavimai;
• informacijos apsaugos nuo neteisėtos prieigos reikalavimai;
• informacijos saugos reikalavimai avarijų atveju;
• apsaugos nuo išorinių poveikių reikalavimai;
• patento grynumo reikalavimai;
• standartizavimo ir unifikavimo reikalavimai;

Nepaisant to, kad pagrindinis, žinoma, bus skyrius su specifiniais reikalavimais (funkcionalus), šį skyrių taip pat gali būti labai svarbus (o daugeliu atvejų taip ir yra). Kas gali būti svarbu ir naudinga:

• Kvalifikacijos reikalavimai. Gali būti, kad kuriama sistema pareikalaus perkvalifikuoti specialistus. Tai gali būti ir būsimos sistemos vartotojai, ir IT specialistai, kurių prireiks ją palaikyti. Nepakankamas dėmesys šiai problemai dažnai virsta problemomis. Jei esamų darbuotojų kvalifikacija yra aiškiai nepakankama, geriau nustatyti reikalavimus mokymų organizavimas, mokymo programa, terminai ir kt.
• Reikalavimai informacijos apsaugai nuo neteisėtos prieigos. Komentarų čia nėra. Būtent tokie yra prieigos prie duomenų kontrolės reikalavimai. Jeigu tokie reikalavimai yra numatyti, tuomet juos reikia rašyti atskirai, kuo detaliau pagal tas pačias taisykles kaip ir funkciniai reikalavimai (suprantamumas, konkretumas, patikrinamumas). Todėl šiuos reikalavimus galima įtraukti į skyrių su funkciniais reikalavimais.
• standartizavimo reikalavimus. Jei yra kokių nors projektui taikomų kūrimo standartų, jie gali būti įtraukti į reikalavimus. Paprastai tokius reikalavimus inicijuoja Kliento IT tarnyba. Pavyzdžiui, 1C įmonė turi reikalavimus programos kodo dizainui, sąsajos dizainui ir kt .;
• Reikalavimai sistemos struktūrai ir veikimui.Čia gali būti aprašyti sistemų tarpusavio integravimo reikalavimai, pateikiamas bendrosios architektūros aprašymas. Dažniau integracijos reikalavimai apskritai išskiriami atskirame skyriuje ar net atskirame techninės užduotyse, nes šie reikalavimai gali būti gana sudėtingi.

Visi kiti reikalavimai yra mažiau svarbūs ir gali būti nepaisomi. Mano nuomone, jie tik apsunkina dokumentaciją ir praktiškai nenaudingi. O ergonomikos reikalavimus apibūdinti bendrų reikalavimų forma labai sunku, geriau juos perkelti į funkcinius. Pavyzdžiui, galima suformuluoti reikalavimą „Gauti informaciją apie prekės kainą paspaudus tik vieną mygtuką“. Mano nuomone, tai visgi yra arčiau specifinių funkcinių reikalavimų, nors tai susiję su ergonomika Reikalavimai sistemos atliekamoms funkcijoms (užduotims) Čia yra pats pagrindinis ir esminis momentas, kuris lems sėkmę. Net jei visa kita atlikta nepriekaištingai, o ši skiltis yra ties „3“, tada projekto rezultatas geriausiu atveju bus „3“ arba net projektas žlugs. Tai yra tie, kuriuos mes išsamiau aptarsime antrajame straipsnyje, kuris bus įtrauktas į 5-ąjį adresų sąrašo leidimą. Būtent iki šiol galioja „trijų reikalavimų savybių taisyklė“, apie kurią kalbėjau. Reikalavimai saugumo rūšims

GOST išskiria šiuos tipus:

• Matematinė
• informaciniai
• Lingvistinė
• Programinė įranga
• Techninė
• Metrologinis
• Organizacinis
• metodiškas
• ir kiti…

Iš pirmo žvilgsnio gali atrodyti, kad šie reikalavimai nėra svarbūs. Tai galioja daugumai projektų. Bet ne visada. Kada aprašyti šiuos reikalavimus:

• Nebuvo priimtas sprendimas, kurioje kalboje (ar platformoje) bus plėtojama;
• Sistemai taikomi daugiakalbės sąsajos reikalavimai (pavyzdžiui, rusų / anglų k.)
• Sistemos funkcionavimui turi būti sukurtas atskiras padalinys arba samdomi nauji darbuotojai;
• Kad sistema veiktų, Klientui turi būti atlikti darbo metodų pakeitimai, šie pakeitimai turi būti patikslinti ir suplanuoti;
• Numatoma integracija su kai kuriais įrenginiais ir jai keliami reikalavimai (pavyzdžiui, sertifikavimas, suderinamumas ir pan.)
• Galimos ir kitos situacijos, viskas priklauso nuo konkrečių projekto tikslų.

5 skyrius. Sistemos kūrimo darbo sudėtis ir turinys

6 skyrius. Sistemos kontrolės ir priėmimo tvarka

Bendrieji darbų priėmimo etapais reikalavimai (dalyvaujančių įmonių ir organizacijų sąrašas, vieta ir laikas), priėmimo dokumentacijos susitarimo ir tvirtinimo tvarka; Primygtinai rekomenduoju prisiimti atsakomybę už darbų perdavimo ir sistemos patikrinimo tvarką. Tam ir yra skirti testuojami reikalavimai, tačiau net ir testuojamų reikalavimų gali neužtekti sistemos pristatymo metu, jei nėra aiškiai išdėstyta darbų priėmimo ir perdavimo tvarka. Pavyzdžiui, dažni spąstai: sistema sutvarkyta, pilnai veikia, bet Klientas kažkodėl nepasiruošęs joje dirbti. Šios priežastys gali būti bet kokios: kartą pasikeitė tikslai, kažkas pasitraukė ir pan. Ir jis sako: „Kadangi mes dar nedirbame naujoje sistemoje, negalime būti tikri, kad ji veikia“. Taigi išmokite teisingai nustatyti darbo etapus, būdus, kaip patikrinti šių etapų rezultatus. Be to, tokie metodai Klientui turėtų būti aiškūs nuo pat pradžių. Jei jie yra nustatyti techninės užduotys lygmeniu, tuomet prireikus visada galite su jais susisiekti ir užbaigti darbą su perkėlimu.

7 skyrius. Reikalavimai darbų, skirtų automatizavimo objektui paruošti sistemos paleidimui, sudėties ir turinio

Gali būti ir kitos įmonės priimtos (ar planuojamos) informacijos įvedimo taisyklės. Pavyzdžiui, informacija apie sutartį anksčiau buvo įvedama kaip teksto eilutė savavališkai, o dabar numeris reikalingas atskirai, data atskirai ir pan. Tokių sąlygų gali būti daug. Kai kurie iš jų gali būti suvokiami su personalo pasipriešinimu, todėl visus tokius atvejus geriau registruoti duomenų įvedimo tvarkos reikalavimų lygmenyje Keitimai, kuriuos reikia atlikti automatikos objekte

Automatikos objekto funkcionavimo sąlygų, kurioms esant garantuojama sukurtos sistemos atitiktis TOR esantiems reikalavimams, sudarymas Bet kokie pakeitimai, kurių gali prireikti. Pavyzdžiui, įmonė neturi vietinis tinklas, pasenęs kompiuterių parkas, kuriame sistema neveiks.

Galbūt tam tikra reikalinga informacija buvo apdorota popieriuje, o dabar ją reikia įvesti į sistemą. Jei to nepadarysite, neveiks koks nors modulis ir pan.

Galbūt kažkas buvo supaprastinta, bet dabar į tai reikia atsižvelgti išsamiau, todėl kažkas turi rinkti informaciją pagal tam tikras taisykles.

Šis sąrašas gali būti ilgas, pažiūrėkite į konkretų Jūsų projekto atvejį.Sistemos funkcionavimui reikalingų skyrių ir paslaugų kūrimas;

Personalo komplektavimo ir personalo mokymo terminai ir procedūros Apie tai jau kalbėjome anksčiau. Galbūt sistema kuriama naujai struktūrai ar veiklos rūšiai, kurios anksčiau nebuvo. Jei nėra tinkamo personalo ir net apmokytų, sistema neveiks, kad ir kaip kompetentingai ji nebūtų sukurta.

8 skirsnis Reikalavimai dokumentacijai

Apsvarstykite, kaip bus pateikiami vartotojo vadovai.

Galbūt Klientas sutiko su įmonės standartais, todėl turite su juo susisiekti.

Dokumentų reikalavimų nepaisymas labai dažnai sukelia netikėčiausių pasekmių projektams. Pavyzdžiui, viskas padaryta ir viskas veikia. Vartotojai taip pat žino, kaip dirbti. Dėl dokumentacijos visiškai nesusitarėme ir nesikalbėjome. Ir staiga, kai darbas perduodamas, vienas iš aukščiausių Užsakovo vadovų, kuris net nedalyvavo projekte, bet dalyvauja priimant darbus, klausia: „Kur yra vartotojo vadovai? Ir jis pradeda jus įtikinėti, kad nebūtina susitarti dėl vartotojo vadovų prieinamumo, tariamai tai „savaime“ numanoma. Ir viskas, jis nenori imtis jūsų darbo. Kieno sąskaita rengsite gaires? Daugelis komandų jau papuolė į šį kabliuką.

9 skyrius Plėtros šaltiniai

Todėl geriau remtis tiesiog apklausos ataskaita, pagrindinių asmenų reikalavimais.

Taigi, mes apsvarstėme visus skyrius, kurie gali būti įtraukti į techninę užduotį. „Gali“, o ne „privalo“ būtent todėl, kad norint pasiekti rezultatą, bet koks dokumentas turi būti parengtas. Todėl jei jums akivaizdu, kad kažkokia atskira skiltis nepriartins jūsų prie rezultato, tuomet jums to nereikia ir nereikia tam gaišti laiko.

Tačiau be pagrindinio dalyko: funkcinių reikalavimų, nė viena kompetentinga techninė užduotis nėra išsami. Noriu pastebėti, kad praktikoje susiduriama su tokiomis techninėmis užduotimis ir kaip! Yra figūros, kurios sugebės atskiesti vandenis visuose ruožuose, aprašyti Bendrieji reikalavimai bendrais bruožais, o dokumentas pasirodo labai svarus ir jame daug protingų žodžių, ir net Klientui gali patikti (t.y. patvirtins). Bet prie to dirbti gali ir nepavykti, t.y. praktinės naudos iš to mažai. Dažniausiai tokie dokumentai gimsta tada, kai reikia gauti daug pinigų būtent už techninę užduotį, ir tai padaryti reikia greitai ir nesigilinant į smulkmenas. O ypač jei žinoma, kad toliau reikalai nenueis, arba tai darys visai kiti žmonės. Apskritai, tik biudžeto, ypač valstybės, plėtrai.

Antrame straipsnyje kalbėsime tik apie 4 skyrių „Reikalavimai sistemai“, o konkrečiai – suformuluosime reikalavimus dėl aiškumo, konkretumo ir patikrinamumo.

Kodėl reikalavimai turi būti aiškūs, konkretūs ir išbandomi.

Nes praktika rodo: iš pradžių dauguma techninių specifikacijų, kurias kuria specialistai, arba pasirodo, nėra paklausios (neatitinka tikrovės), arba tampa problema tam, kuris turėtų jas įgyvendinti, nes Klientas pradeda manipuliuoti nespecifiniais terminais ir reikalavimais. Pateiksiu kelis pavyzdžius, su kokiomis frazėmis susidūriau, prie ko tai privedė, o tada pabandysiu pateikti rekomendacijų, kaip tokių problemų išvengti.

Ar tai tikrinamas reikalavimas? Atrodo, paprastas dalykas, bet kaip tai patikrinti, jei nėra konkretumo?

Kaip būtų galima suformuluoti: „Dokumente nurodyta išlaidų suma turi būti paskirstyta visoms šiame dokumente nurodytoms prekėms proporcingai šių prekių savikainai“. Buvo aišku ir konkretu. Kaip patikrinti, taip pat nėra sunku.

Ergonomika Programa turėtų turėti patogią sąsają.Jei atvirai, vieną kartą teko užsiprenumeruoti šią formuluotę – tada nebuvo jokių problemų suskaičiuoti. Žinoma, tokių formuluočių neturėtų būti. Nėra nei specifikos, nei galimybės patikrinti šio reikalavimo. Nors, žinoma, suprantama (subjektyviai). Čia jokiu būdu neįmanoma performuluoti, būtina išsamiai apibūdinti kiekvieną „patogumo“ elementą, nes Klientas to reikalauja. Pavyzdžiui:

• Eilutes į dokumentą reikia įtraukti tiek paspaudus mygtuką „Pridėti“, tiek paspaudus „įterpti“ klavišus, tiek vartotojui įvedant vardo dalį;
• Peržiūrint prekių sąrašą, turėtų būti galima ieškoti pagal pavadinimą, brūkšninį kodą ir gaminį;
• ir tt

Prieigos teisių diferencijavimas Prieiga prie duomenų apie pelną turėtų būti prieinama tik finansų direktoriui. Beveik. Tiesa, pelnas kitoks, reikia patikslinti.Konkrečiai? Žinoma ne. Kaip tai atrodo įgyvendinant? Jei kalbame apie bendrąjį pelną, tai būtina apriboti prieigą prie duomenų apie pirkimo kainą, nes. kitu atveju bendrąjį pelną nesunku apskaičiuoti, nes pardavimo savikainos duomenis žino daugybė žmonių. Kalbant apie prieigos teises, turite būti labai atsargūs. O jei pardavimų vadybininkus motyvuoja bendrasis pelnas, tai šie reikalavimai irgi prieštarauja vienas kitam, nes. vadovai niekada negalės to patikrinti. Jeigu jau įtraukiame tokį reikalavimą, tai būtina nurodyti konkrečias ataskaitas ir sistemos objektus, kuriuose būtų nurodyta, kuri duomenų dalis turi būti prieinama tam tikroms asmenų kategorijoms. Ir kiekvieną tokį atvejį apsvarstykite individualiai.produktyvumas Pardavimo ataskaita turėtų būti sugeneruota per 1 min.Taip suprantu. Ir netgi yra konkretus laiko limitas: 1 minutė. Bet nežinia, koks detalizavimas šiuo atveju numatomas: kiekvienai prekei, prekių grupėms, pirkėjams ar dar kažkam?daugiau nei 1 minutę, su sąlyga, kad prekių skaičius pasirinkime neviršija 5000 eilučių.

Tikiuosi mintis aiški. Jei turite konkrečių klausimų, rašykite, pasistengsiu padėti.

Į vidų įgaliojimai buvo daugiau specifikos, yra daug rekomendacijų. Yra net sąrašas žodžių, kurių nerekomenduojama vartoti techninėje užduotyje. Apie tai įdomiai rašo K. Vigers knygoje „Programinės įrangos reikalavimų kūrimas“. Čia yra įdomiausios ir, mano nuomone, paprasčiausios rekomendacijos:

• Nevartokite žodžių, turinčių daug sinonimų. Jei reikia, geriau pateikti aiškų termino apibrėžimą Techninės užduoties skiltyje Sąvokos ir apibrėžimai.
• Turėtumėte stengtis nevartoti ilgų sakinių;
• Jei reikalavimas jums atrodo pernelyg bendras, jis turi būti detalizuotas iki mažesnių, bet specifinių reikalavimų;
• Naudokite daugiau diagramų, grafikų, lentelių, brėžinių – taip informacija suvokiama daug lengviau;
• Reikėtų vengti šių žodžių: „efektyvus“, „tinkamas“, „paprastas“, „suprantamas“, „greitas“, „lankstus“, „patobulintas“, „optimalus“, „skaidrus“, „tvarus“, „pakankamas“ , "draugiškas", "lengvas" ir tt Sąrašas gali būti tęsiamas, bet manau, kad mintis aiški (pabandykite ją tęsti patys).

Visa tai, kas parašyta aukščiau, yra svarbi informacija, bet ne pati svarbiausia. Kaip prisimenate, straipsnio pradžioje aš tai pavadinau terminu „kamufliažas“, nes. svarbiausias dalykas, kuris sudarys mažiausiai 90% laiko ir sudėtingumo dirbant su dokumentu, yra reikalavimų nustatymas ir suformulavimas. O informaciją apie reikalavimus vis tiek turi būti galima surinkti, susisteminti ir suformuluoti. Tai, beje, turi daug bendro tarp įmonių tyrimo ir vėlesnio verslo procesų aprašymo. Tačiau yra ir svarbių skirtumų. Vienas iš šių esminių skirtumų yra būsimos sistemos prototipo kūrimo stadija arba, kaip dar vadinama „informacinių sistemų modeliais“.

Kitame straipsnyje kalbėsime tik apie reikalavimų nustatymo metodus, taip pat apsvarstysime, kas yra bendra tarp informacinės sistemos reikalavimų rinkimo ir informacijos rinkimo verslo procesams apibūdinti.

Darbų rūšys renkant reikalavimus apskaitos sistemai ir informaciją verslo procesams aprašyti. 2 dalis

Šioje dalyje kalbėsime apie tai, kaip organizuoti reikalavimų rinkimo darbo etapą, iš ko jis turėtų būti sudarytas ir kokias priemones galima naudoti. Kartoju, kad šie darbai etapais labai panašūs į įmonių apklausą, skirtą verslo procesams apibūdinti.

Kaip įprasta gyvenime:

Kaip tai veikia daugelyje projektų
	Kaip tai atsitinka
	Aišku, kad džiaugsmui yra pagrindo, ypač jei projektas didelis, tai nieko blogo! Svarbiausia per ilgai nesidžiaugti, atidėliojus faktinių darbų pradžią, nuo šiol laikas eis kitaip.
	Paprastai šis procesas apsiriboja keliais susitikimais su vadovybe, vėliau – su padalinių vadovais. Patikslinus kai kuriuos Kliento „raginimus“, jie fiksuojami bendrų formuluočių pavidalu. Kartais prie to pridedama turima dokumentacija (kažkada bandė atlikti ekspertizę, dokumentai pagal galiojančius reglamentus, naudojamos ataskaitų formos). Keista, bet po to dauguma automatizavimo sistemų diegėjų džiaugsmingai sušunka: „taip, mūsų sistema turi. Visa tai! Na, šiek tiek pakoreguoti ir viskas pavyks. Į klausimą, ar reikia diskutuoti, kaip viskas turėtų veikti (ar kaip specifinis procesas) su galutiniais vartotojais atsakymas paprastai yra ne. Išsakoma nuomonė, kad vadovas viską žino už savo pavaldinius. Bet veltui... Už to slypi daugybė spąstų ir kliūčių, o darbų pristatymas gali virsti maratonu kliūčių ruože. Kaip žinia, įprasta maratoną bėgti lygiu keliu, o bėgti su kliūtimis galima tik trumpomis distancijomis (galima ir nebėgti).
Darbo rezultatų dokumentavimas	Po to, priklausomai nuo darbo tikslų, prasideda rezultatų dokumentavimas: Jei reikia parengti techninę užduotį, konsultantas pradeda skleisti gautą informaciją pagal paruoštą dokumento šabloną, kad ji gražiai atrodytų ir pagrindinė reikalavimai yra fiksuoti (tie, kurie yra išsakyti iš vadovybės, kitaip jie gali nepritarti). Suprasdamas, kad praktikoje tokios techninės užduotys nėra itin naudojamos ir viską reikia išsiaiškinti „einant“, jis iškelia pagrindinį techninės užduotys tikslą – minimalų derinimo ir tvirtinimo laiką. Ir, jei įmanoma, informacija, skirta apytiksliai įvertinti būsimų darbų kainą (beje, tai taip pat svarbu). Jei norite apibūdinti verslo procesus. Kaip bebūtų keista, bet dažnai visi ankstesni veiksmai atrodo taip pat, kaip ir rengiant techninę užduotį. Vienintelis skirtumas yra dokumentuose. Čia galimi variantai: konsultantai procesą apibūdina savavališkais žodžiais arba naudoja bet kokias verslo procesų apibūdinimo taisykles (žymėjimus). Pirmuoju atveju toks dokumentas pasirodo stebėtinai panašus į techninę užduotį. Pasitaiko net taip, kad pakeitus titulinį puslapį, jokio skirtumo nepamatysi. formalus aprašymo taisyklių laikymasis.Deja, abu variantai nėra patys geriausi geriausia praktika, nes yra daugiau formalumas ir neduoda daug naudos.

Kodėl yra tokia praktika, kaip aprašyta aukščiau? Prisipažįstu, kad nežinau. Niekas neklausia, niekas nežino. Tuo pačiu situacija nesikeičia labai greitai, nors šia tema nuolat diskutuojama, keičiamasi patirtimi, rašomos knygos... Man atrodo, kad viena iš priežasčių yra žema atitinkamo išsilavinimo kokybė. Tam įtakos gali turėti ir tai, kad daugelis specialistų iš viso ateina iš kitų verslų ir viską supranta praktiškai, t.y. jų patirtį formuoja aplinka, kurioje jie atsiduria. Universitetų požiūris ir nenorėjimas būti arčiau realybės – taip pat žinomas faktas, tačiau kartais jų pozicija mane nustebina. Pavyzdžiui, man buvo atvejis, kai magistrantas, talentingas specialistas, norėjo parašyti baigiamąjį darbą 1C platformoje (geras pramonės vystymasis), tačiau katedroje jai buvo pasakyta, kad, nepaisant temos, tai bus neįmanoma. pasikliauti „puikiu“ pažymiu, nes 1C nėra rimta sistema. Esmė čia yra ne tokios nuomonės rimtumas ir objektyvumas, o tai, kad primityvi užduotis klasikine programavimo kalba iškart buvo pripažinta verta „puikaus“ ​​įvertinimo.

Pabandykime aukščiau aptartam procesui suteikti sistemingesnį požiūrį. Kaip jis tada gali atrodyti?

Kaip matote, procesas baigiasi klausimu, nes šiuo klausimu darbas toli gražu nesibaigė, o tada prasidės pats sunkiausias ir praktiškiausias - būtent tai lems gauto rezultato pritaikymą Tikras gyvenimas. Būtent tai lems ankstesnio kūrinio likimą: arba jis nukeliaus į spintą (lentynoje ar kur nors kitur), arba bus vertingas informacijos šaltinis. Ir dar geriau, jei tai taps pavyzdžiu būsimiems projektams.

Noriu pabrėžti, kad iki paskutinio žingsnio diagramoje (kur klausimas) bendras informacijos apie įmonės veiklą rinkimo principas atrodo taip pat, nepriklausomai nuo to, ką planuojama daryti ateityje, aprašyti verslo procesus ar įgyvendinti automatizuota sistema. Taip, pati veiksmų seka yra ta pati, tačiau kai kuriems iš jų naudojami įrankiai gali skirtis. Šį momentą tikrai apsvarstysime, kai tyrinėsime atskirų etapų metodus ir priemones. Mes tai padarysime išsamiai atskiruose straipsniuose, bet dabar apsvarstysime tik svarbiausius. Tolesni veiksmai skirsis ir priklausys nuo to, ko reikia iš projekto: aprašyti verslo procesus arba įdiegti apskaitos sistemą.

Pažiūrėkime, kaip galite pertvarkyti požiūrį į informacijos apie įmonės veiklą rinkimą.

Kaip tai gali atsitikti su kompetentingesniu darbo organizavimu
	Kaip tai atsitinka
Sprendimas priimtas, projektas bus!	Dėl pirmojo varianto čia niekas nesikeičia, emocijų niekas neatšaukė
Surengėme susitikimą su vadovais, surinkome šiek tiek informacijos apie jų viziją apie rezultatą.	Šis žingsnis taip pat išlieka, ir jis yra labai svarbus. Tačiau pagrindinis pirmojo susitikimo (ar kelių susitikimų) su vadovais ir savininkais tikslas – pažintis. Pažintis pirmiausia su žmonėmis ir kompanija. Tokiuose visuotiniuose susirinkimuose suformuluoti tikslai ir pageidavimai gali būti labai įvairūs, net ir fantastiški. Visi jie, žinoma, bus išgirsti, bet ne tai, kad jie bus įgyvendinti. Giliau pasinėrus į įmonės verslą, atsiras kiti tikslai, taip pat bus atmesti ankstesni. Turiu omenyje tai, kad iš išankstinių susitikimų neįmanoma suformuluoti aiškių tikslų, visa tai reikės atidžiai išstudijuoti, tokiuose susitikimuose būtina išdėstyti visas savininkų ir aukščiausių pareigūnų žinutes, kad vėliau būtų galima prie jų sugrįžti. ir aptarti, kada bus surinkta pakankamai informacijos. Netgi iš pažiūros paprastas reikalavimas gali pasirodyti neįgyvendinamas arba labai sunkus.
Darbo grupės iš Užsakovo ir Rangovo formavimas, vaidmenų paskirstymas	Būtina nuspręsti, kas dirbs su projektu tiek iš Užsakovo, tiek iš Rangovo pusės. Nepaisant akivaizdaus šio etapo paprastumo, jis atlieka labai svarbų vaidmenį. Jei aiškiai nenustatysite, kas už ką atsakingas, rizikuojate susipainioti vykdydami darbą. Jei iš savo pusės visada galite nurodyti vaidmenis savo komandoje, Klientas gali turėti problemų dėl to. Į ką reikėtų atkreipti dėmesį: Užsakovo darbo grupėje būtinai turi būti tie žmonės, kurie ateityje bent kažkaip paveiks rezultato priėmimą. Jeigu darysime prielaidą, kad perdavus darbus prisijungs Užsakovo darbuotojai, kurie nedalyvavo tikslų formavimo ir reikalavimų identifikavimo darbuose, tai problemos garantuotos. Galima net ir tokia absurdiška situacija, kad viskas, pasirodo, daroma ne taip, kaip reikalaujama.Savo praktikoje ne kartą yra tekę susidurti su tokia situacija.Todėl galite apsisaugoti, jei išlyginsite ir dokumentais įrodysite, kad niekas, išskyrus darbų priėmime ir pristatyme gali dalyvauti Užsakovo darbo grupė. Ir geriausia, kad tai būtų nurodyta sutarties sąlygose (sutartyje arba projekto chartijoje). Pamenu, buvo toks atvejis: viename dideliame projekte steigėjas nusprendė prisijungti prie proceso (nežinau kodėl, pasidarė nuobodu žiūrėti) ir dalyvavo viename iš darbinių susitikimų, kur buvo sprendžiamas sąskaitų faktūrų klientams generavimo klausimas. aptarė. Jis nustebo sužinojęs, kad pardavimų vadybininkas išrašo klientui sąskaitą. Jo nuomone, buhalteris turėtų išrašyti sąskaitą, ir nieko daugiau. Bet iš tikrųjų buhalterė visiškai neįsivaizdavo, kas gresia, o vadovas neįsivaizdavo, kaip taip dirbti, jei dėl kiekvienos sąskaitos bėgtų pas buhalterę. Dėl to praradome daug laiko, bet niekas nepasikeitė, sąskaitą vis tiek aprašė vadybininkas. Ir įkūrėjas liko prie savo nuomonės, bet daugiau į procesą nesikišo. Tame pačiame etape patartina parengti Projekto chartiją, kurioje būtų nustatyti dalyvių vaidmenys, komunikacijos tvarka, ataskaitų teikimo taisyklės ir sudėtis, taip pat visa kita, kas turėtų būti įrašyta Chartijoje. Projekto chartijos rengimas vėlgi yra atskiras klausimas.
Apmokyti projekto komandą darbo metodais ir priemonėmis, susitarti dėl darbo taisyklių, dokumentacijos rūšių ir sudėties	Pirmiausia reikia paaiškinti projekto komandai viską, kas parašyta Chartijoje, kaip tai bus taikoma praktikoje. Antra, Kliento projekto komanda turi būti apmokyta darbo metodų, kuriuos ketinate naudoti visuose tolesniuose etapuose. Tikslinga aptarti dokumentų formatus, kurie bus naudojami, apsvarstyti pavyzdžius. Jei bus taikomos kokios nors modelių ar verslo procesų aprašymo taisyklės, šios taisyklės taip pat turi būti aptartos, kad jos būtų suprantamos.
Klausimynas	Apklausos etapas leidžia gana greitai gauti gana patikimą informacijos apie įmonę gabalą. Tokios informacijos kokybę lems trys veiksniai: Visų pirma, kaip apmokėte kliento projekto komandą. Jie turi aiškiai suprasti, kaip vyksta apklausos procesas, ir gebėti perduoti informaciją visiems dalyviams. Pati anketos forma. Anketos turi būti suprantamos. Pageidautina, kad būtų anketų pildymo instrukcija. Dar geriau, jei yra užpildymo pavyzdys. Dalyvių sąrašas. Būtina pasirinkti tinkamą dalyvių sudėtį. Jei apsiribosime tik vadovais, patikimos informacijos surinkti nepavyks. Rekomenduoju į anketą įtraukti visus, kurie naudosis galutiniais rezultatais. Pavyzdžiui, jei kalbame apie automatizuotos sistemos įdiegimą, verta įtraukti visus, kurie bus naudotojai. Pasitaiko atvejų, kai iš 10 vienos pareigybės darbuotojų yra vienas, kuris atlieka kokią nors specialią funkciją, apie kurią nežino nė vienas iš likusių 9 (pvz., rengia specialią ataskaitą vadovybei). Jei kalbame apie tolesnį pareigų perskirstymą ar pareigybių aprašymų kūrimą, tą patį reikėtų daryti ir jums. Atkreipiu jūsų dėmesį į tai, kad apklausos būdas vėlesniam automatizuotos sistemos diegimui ar verslo procesų aprašymui tinkamu atveju skiriasi. Žinoma, anketų struktūra gali būti tokia pati, tačiau tai nėra pats geriausias variantas. Kai aprašome verslo procesus, klausimynai dažniausiai būna bendresnio pobūdžio, nes nėra tiksliai žinoma, su kuo susidurs. Jei kalbame apie konkrečios automatizuotos sistemos įdiegimą, tuomet geriau turėti anketas, kuriose būtų atsižvelgta į šios sistemos ypatybes. Taikydami šį metodą galite iš karto nustatyti visas sistemos kliūtis, kurios netinka šiai įmonei. Paprastai paruoštų sistemų diegimo metodai numato tokių klausimynų prieinamumą. Tokie klausimynai gali būti rengiami arba atskiroms apskaitos sritims (pavyzdžiui, užsakymų apskaita, pardavimas, kainodara), arba konkrečioms pareigoms (pavyzdžiui, finansų direktorius). Klausimų sudėtis yra maždaug tokia pati.
Apklausos	Apklausa – tai žodinis pokalbis su specialistais, siekiant išsiaiškinti atskirų procesų ypatybes. Apklausą būtina organizuoti taip, kad ji neatrodytų tik kaip „susitikimas-pokalbis“, o labiau organizuotas. Tam reikia parengti vadinamąjį apklausos planą. Į jį galite įtraukti tas anketos dalis, kurios jums kelia klausimų, prieštarauja kitų anketų informacijai arba informacija pateikiama paviršutiniškai. Patartina pridėti klausimų ir tik iš asmeninės patirties.Atsakymai turi būti aiškiai išdėstyti. Idealu, jei sutinkate dėl garso įrašo. Tame pačiame etape turėtumėte stebėti pateiktos informacijos apie darbo eigą išsamumą (tiek pirminių dokumentų formas, tiek įvairias ataskaitas).
Pagrindinių verslo procesų arba automatizavimo sričių nustatymas	Atlikus anketą ir apklausą galima pagrįstai manyti, kad informacijos pakanka, kad būtų galima padaryti išvadas apie pagrindinių verslo procesų paskirstymą. Tiesą sakant, jau galima išskirti ne tik pagrindinius verslo procesus, bet ir beveik viską (jei dalyvių sudėtis parinkta teisingai). Verslo procesų identifikavimo klausimas yra visiškai atskira ir ne paprasta tema. Mokymasis čia yra sunkus ir daugiausia vyksta patirties dėka. Sąrašas (klasifikatorius) turėtų būti sudarytas iš pasirinktų verslo procesų. Tada bus galima nuspręsti, kuriuos iš jų reikėtų nagrinėti nuodugniau, kurių ne, taip pat nustatyti prioritetus.
Pagrindinių sistemos reikalavimų, tikslų, projekto sėkmės kriterijų, procesų detaliam tyrimui formulavimas	Iki šio etapo turėtų būti surinkta visa pirminė informacija apie įmonės veiklą, sudarytas verslo procesų sąrašas. Dabar pats laikas grįžti prie tikslų, juos patikslinti, jei reikia, aptarti su pirmaisiais įmonės asmenimis. Formuojant tikslus reikia atsižvelgti į konkrečius rodiklius, kuriuos pasiekę projektą laikysime sėkmingu. Jei mes kalbame apie automatizuotos sistemos įdiegimą, atskirame sąraše galima pabrėžti pagrindinių vartotojų sistemos reikalavimus. Tai darau atskiros lentelės pavidalu, kur visi reikalavimai sugrupuoti pagal posistemes, prie kiekvieno reikalavimo nurodomas reikalavimo autorius, formuluotė ir prioritetas. Ši informacija gali būti naudojama rengiant sistemos diegimo planą (atskirų posistemių diegimo seką), taip pat teikiant pasiūlymus dėl tolimesnės sistemos plėtros (jei dabartiniame projekte nenumatyta diegti atskirų posistemių). Jei reikia aprašyti verslo procesus, priimami sprendimai dėl tų procesų, kuriuos reikia išstudijuoti plačiau.

Taigi mes priėjome prie klausimo "Kas toliau?". Toliau atskirai svarstysime verslo procesų aprašymo ir techninės užduoties rengimo užduotis. Neatsitiktinai šias užduotis svarstau lygiagrečiai. Tarp jų tikrai yra daug bendro, ką noriu pademonstruoti. Pirmiausia apsvarstykite darbų seką aprašydami verslo procesus.

	Ką ir kaip daryti
Verslo proceso pasirinkimas	Iš bendro verslo procesų sąrašo, gauto ankstesniuose etapuose, išskiriame vieną (pagal prioritetą). išsamus tyrimas. Tada mes darome tą patį su likusia dalimi.
Išsamus verslo proceso tyrimas	Pasirinktą verslo procesą atliekame detaliam tyrimui: analizuojame gautus pirminius dokumentus, ataskaitas ir programos procese naudojamą jų struktūrą, įvairius failus (pvz., Excel), kalbamės su galutiniais vykdytojais. Įvairių idėjų, kaip būtų galima patobulinti procesą, rinkimas. Labai naudinga, jei galite tiksliai stebėti procesą tokiomis sąlygomis, kokiomis jis atliekamas (nedaug kam patinka būti stebimi, bet ką daryti)
Verslo proceso grafinis ir (arba) tekstinis aprašymas (pagrindinis)	Pradedame aprašinėti gautą detalią informaciją Prieš aprašant procesą būtina apsispręsti, ar jam reikės grafinio aprašymo. Jei procesas yra paprastas ir suprantamas, jame yra mažai funkcijų, o grafinis vaizdas nepagerins jo supratimo ar suvokimo, nereikia tam gaišti laiko. Šiuo atveju pakanka jį apibūdinti tekstine forma lentelės pavidalu. Jei procesas yra sudėtingas, su skirtingomis loginėmis sąlygomis, tada geriau pateikti jo grafinę diagramą. Diagramas visada lengviau suprasti. Jei nuspręsite procesą apibūdinti grafine forma, tai visiškai nereiškia, kad jums nereikia pateikti jo tekstinio aprašymo. Tie. Tekstinis proceso aprašymas bet kuriuo atveju turėtų būti sudarytas pagal tą pačią schemą. Patogu tai padaryti lentelės pavidalu, kurioje nurodoma: kiekvieno žingsnio atlikėjai, kokią informaciją jie gauna įėjime, kiekvieno žingsnio aprašymą, kokia informacija generuojama išėjime. Žemiau pamatysime pavyzdį, kaip tai gali atrodyti.
Derinimas su atlikėjais ir verslo proceso savininku	Geriausias būdas suprasti, kaip gerai pasirinkote informacijos pateikimo stilių, yra proceso naudotojams (vykdytojams) parodyti rezultatą.Svarbiausia tokioje demonstracijoje suprasti, kaip teisingai supratote, kaip procesas atliekamas. Jei projekto komandos mokymai buvo sėkmingi, galite tikėtis gana adekvačių atsiliepimų iš atlikėjų. Ir jei jie susidomės, tada viskas pradės judėti daug greičiau.Nustatyti patikslinimai ir neatitikimai turi būti atspindėti aprašyme (atnaujinami), jei reikia, pakartokite operaciją.
Verslo procesų rodiklių identifikavimas	Kai gerai suprasite, kaip vykdomas verslo procesas, turite pagalvoti apie metrikas, kurios gali išmatuoti proceso kokybę ar greitį. Tai nėra lengva, bet būtina. Rodiklis turi būti išmatuojamas, t.y. išreikšta skaitiniais terminais ir turėtų būti paprastas būdas gauti šią vertę. Jei išmatuoto rodiklio nustatyti nepavyksta, kyla rizika, kad verslo procesas buvo netinkamai identifikuotas. Be to, nebus galima suprasti (nes to negalima išmatuoti), ar proceso pakeitimai lems jo tobulėjimą, ar ne.
Galutinė verslo procesų dokumentacija	Kai tik įsitikinsime, kad suprantame, kaip procesas yra (arba turėtų būti) atliekamas, galime įtraukti jį į dokumentus.
	Galimi ir kiti variantai: nagrinėjami procesai bus analizuojami ir optimizuojami, plėtojami pareigybių aprašymai, priimami sprendimai dėl būtinybės automatizuoti atskirus procesus ir pan.Tai gali būti ir atskiras projektas: verslo procesų aprašymas.

Dabar pažiūrėkime, kaip atrodys požiūris į informacinės sistemos reikalavimų tyrimą, toliau juos apžvelgus techninėje užduotyje

	Ką ir kaip daryti
Verslo poreikio / automatizavimo srities išryškinimas	Praktikoje naudojamas visos automatikos srities išskyrimas kaip reikalavimai (pavyzdžiui, „Inventorius“), tačiau tai nėra pats efektyviausias būdas detalizuoti reikalavimus. Automatikos sritis yra reikalavimų grupė, todėl geriau juos apsvarstyti atskirai. Pavyzdžiui, „Prekių gavimo į sandėlį apskaita“
Išsamus verslo poreikio tyrimas	Išsamus verslo reikalavimo tyrimas suprantamas kaip galutinis vartotojas nori jį matyti ir panaudos (žinoma, pagal projekto tikslus). Programinės įrangos kūrimo technologijose tai dažnai vadinama „naudojimo atveju“. Taigi detalus verslo poreikio tyrimas apsiriboja naudojimo atvejų kūrimu. Tokios galimybės pavyzdys pateiktas straipsnio 2 priede. Paprasčiausiais atvejais visai nebūtina braižyti naudojimo atvejų grafinių diagramų pavidalu, taip pat galite apsiriboti tekstiniu formulavimu. Pavyzdžiui, reikalavimo „Įvedant prekę kaina turi būti skaičiuojama kaip pirkimo kaina + 20%“ nėra prasmės braižyti. Diagramos pavidalu prasminga pateikti reikalavimus sujungti iki automatizavimo apimties, kaip parodyta 2 priedo pavyzdyje.
Modeliavimo reikalavimai informacinėje sistemoje	Štai jis! Kaip tikriausiai prisimenate, aš jau atkreipiau dėmesį į šį svarbiausią techninės užduoties rengimo metodikos elementą. „Sukurk modelį – gauk rezultatą! Kas turėtų būti modeliuojama? Būtina modeliuoti ankstesniame etape gautus naudojimo atvejus. Koks turėtų būti modeliavimo rezultatas? Turėtumėte gauti demonstracinę programą, kurioje įvedami vartotojo duomenys ir, pageidautina, žinomą jo (vartotojo) klausai, atsižvelgiant į pramonės specifiką, esamas problemas. Ir ne šiaip įvesti, o turėtų būti aišku, iš kur šie duomenys atkeliavo, kaip buvo paskaičiuoti. Šiuo metu skaitytojui turėtų kilti klausimų: Bet ką daryti, jei planuojama sukurti naują sistemą ir tiesiog nėra ką modeliuoti? Ką daryti, jei demonstracijai nepakanka funkcionalumo, o sistemą reikia tobulinti? Žinoma, jūs turite susidurti su tokia situacija, ir tai yra normalu. Ką daryti? Jei sistema yra visiškai nauja (kaip sakoma „nuo nulio“), tuomet dažniausiai teks modeliuoti popieriuje, čia jums labai padės naudojimo atvejų diagramos. Iš dalies prasminga nubrėžti kai kurias ekrano formas, kurios turėtų būti kuriamos (tiesiog toje aplinkoje, kurioje bus vykdoma plėtra), nes. piešti juos kokiame nors redaktoriuje užtruks ilgiau ir šis darbas yra nuobodus. Jeigu diegiama jau paruošta sistema, o jai trūksta funkcionalumo, tai nėra ko jaudintis, duomenys įvedami ranka, o vartotojui pasakoma, kad atlikus reikiamus patobulinimus reikia skaičiuoti taip ir taip ( ir jis tai mato). Prie tokio modelio patartina pridėti tekstinį aprašymą, net jei jis trumpas, kad vartotojas galėtų savarankiškai pabandyti dirbti su modeliu laisvalaikiu. Tame pačiame aprašyme galite suformuluoti reikalavimus patobulinimams.
Informacinio modelio demonstravimas darbo grupei	Gautą modelį parodome Užsakovui ir pasakome kaip viskas turi veikti.Geriau modelį demonstruoti posistemiais, t.y. pagal reikalavimų grupę. Paaiškėjus, kad pasiūlyta schema klientui netiks, reikia pagalvoti apie kitus panaudojimo atvejus, atlikti modelio pakeitimus ir parodyti dar kartą. Tik tada, kai yra įsitikinimas, kad planuojamas modelis „gyvens“ su konkrečiu klientu, modelis gali būti laikomas sėkmingu.
Testo kūrimas	Kodėl reikalingi testai? Reikės patikrinti, kaip mums pavyko įgyvendinti reikalavimus. Atitinkamai, pageidautina atlikti visų pagrindinių sričių, sudėtingų algoritmų ir kt. Įskaitant šiuos testus galima naudoti darbų pristatymo metu. Nebūtina daryti kiekvienos sistemos funkcijos testų, visur turi būti sveikas protas. Jei mes kalbame apie paruoštą sistemą, tada bandymas „įvesti naują elementą į klientų katalogą“ atrodys kvailas ir laiko bei pastangų švaistymas. Bet jei tai visiškai nauja sistema, tai visiškai įmanoma. Kam daryti testus, jei dar nėra sistemos?Pirma, kūrėjui bus aiškiau, ką iš jo nori pasiekti. Antra, palengviname testuotojo gyvenimą (juk kūrimo rezultatą kas nors patikrins). Apskritai testavimas yra atskira disciplina, kuri nėra labai paprasta naudojant daugybę metodų. Praktikoje, kaip taisyklė, vis dar naudojami paprasčiausi tyrimo metodai.
Reikalavimų dokumentavimas techninės užduoties forma	Ankstesniuose etapuose surinkta informacija bus būtent tai, kas turėtų būti įtraukta į dokumento „Teisės sąlygos“ reikalavimų skiltyje, todėl belieka visa tai teisingai sutvarkyti.
Tolesni veiksmai (arba jų nebuvimas), priklausomai nuo projekto tikslų	Kūrimo procesas, partnerių paieška projektui, konkursas ir pan., gali užtrukti ilgiau, viskas priklauso nuo situacijos.

Taip, techninės užduoties rengimas yra daug laiko reikalaujantis procesas, todėl brangus. Bet jei tai daroma teisingai, tai išgelbėja Klientą nuo neišsipildžiusių lūkesčių. Rangovas turi daryti tai, ko reikalauja Užsakovas, o ne kartoti to paties šimtą kartų. Ir apskritai tai suteikia skaidrumo visam projektui.

Priedas 1. Verslo procesas aprašytas EPC žymėjimu.

„Norėjau padaryti perkūniją, bet gavau ožką...“, – galvojate priimdamas visiškai naują svetainę iš kūrėjo. Panašu, kad atlikėjas buvo atrinktas pagal rekomendaciją. Ir jo portfelis įkvepia pasitikėjimo. Ir jau ne pirmi metai. Ir vis tiek nepadarė to, ką tu įsivaizdavai. Ir dabar jūs jau nusivylėte svetainių kūrėjais ir esate tikri, kad esate apsuptas sukčių ir mėgėjų.

Tuo tarpu už bet kokio delegavimo rezultatą atsako ne tik atlikėjas, bet ir užsakovas.

Teisingai sudarytos svetainės kūrimo sąlygos padės sumažinti riziką ir padidinti tikimybę, kad gausite savo svajonių interneto šaltinį.

Kodėl reikalinga specifikacija?

• Rangovas kompetentinga techninė sklypo plėtros specifikacija padės iš anksto įvertinti darbo kiekį, sudėtingumą ir kainą. Suprasti, ar jis pats susidoros su tokia užduotimi, ar verta imtis padėjėjų. Ir tada daryti būtent tai, ko klientas iš jo tikisi.
• Klientas techninė užduotis suteikia pasitikėjimo, kad jis dokumentais įformino savo pageidavimus dėl būsimos aikštelės, aiškiai nubrėžė terminus, kurių rangovas privalo laikytis, numatė reikalavimus sklypei. Ir jei rezultatas nepatenkinamas, galite pateikti pagrįstą pretenziją: "Neatitinka TOR!"

Kaip atrodo svetainės techninės sąlygos?

Tavo noras „Tinklaraštis su nemokamu turiniu, puslapiu apie mane ir kontaktais“ atlikėjas mato tai:

Ar manote, kad to pakanka norint sukurti svetainę?

Gaunate baigtą svetainę ir staiga paaiškėja, kad turėjote omenyje tai:

Aprašymo niuansai yra labai svarbūs

Jausti skirtumą? Formaliai čia klysta abi pusės: jūs nepridėjote detalių, atlikėjas apie jas neklausė. Bet jis jau gavo mokėjimą ir yra pasirengęs su juo dingti, o jūs turite nebaigtą svetainę, netikėtas išlaidas ir visišką nusivylimą svetainių kūrėjais.

Siūlau nevesti dalykų į tokius kraštutinumus, o į svetainės techninės užduoties rengimą žiūrėti sąmoningai.

Kas parašyta techninėje užduotyje?

Svetainės techninės sąlygos yra išsamus dokumentas, apibūdinantis jūsų santykių su rangovu procesą ir jo darbo rezultatą.

Didelių ir sudėtingų aikštelių plėtrai reikalinga didelė ir sudėtinga techninė užduotis, mažesnėms aikštelėms tiks ir TK.

Dideliame projekte dažniausiai dirba visa atlikėjų komanda. Jų veiksmai turi būti koordinuojami, todėl svetainės TOR bus gana didžiulė. Jei jums nereikia daug specifinių funkcijų, jei jūsų svetainėje (arba įmonėje su dizaineriu) dirba vienas kūrėjas, dokumentas bus paprastesnis. Tačiau tiek dideli, tiek maži TK turi tą pačią reikšmę ir turi atsakyti į tuos pačius klausimus:

• Kodėl ir kam sukurta svetainė?
• Kuo jis bus užpildytas?
• Kaip visa tai veiks?
• Kas ir kaip dirbs projekte, kas už ką atsakingas?
• Kokia bus produkcija?

Pagrindinės svetainės kūrimo techninės užduoties skyriai

1. Informacija apie klientą, tai yra apie Jus

Pateikite kuo daugiau informacijos. Nurodykite visus šaltinius, iš kurių kūrėjas gali gauti trūkstamus duomenis. Tai gali būti lankstinukai, plakatai, elektroninė medžiaga, nuorodos, kontaktai žmonių, kuriems galima užduoti klausimus.

2. Informacija apie projektą

Kas tai bus: vizitinių kortelių svetainė, internetinė parduotuvė, įmonės portalas, elektroninė biblioteka?

3. Tikslinė svetainės auditorija

Tai yra atvejis, kai jums reikia. Jei jau seniai skaitote mūsų tinklaraštį, tuomet suprantate, kad be šio įrankio rinkodaroje apskritai labai mažai ką galima padaryti.

Ar nusprendėte sukurti savo svetainę, bet vis dar tiksliai nežinote, kas yra jūsų klientas? Taigi dabar pats laikas parengti išsamų jo portretą.

4. Tikslai ir užduotys, kurias svetainė turėtų išspręsti klientui ir auditorijai

Galbūt tai yra pagrindinė TOR dalis, skirta svetainės kūrimui. Turite aiškiai suprasti, kodėl jums reikia žiniatinklio šaltinio. Norėdami pagerinti vaizdą? Tiesioginiam pardavimui? Ar norite savo svetainės lankytojus paversti prenumeratoriais? Ar norite sukurti išteklių potencialiems partneriams pritraukti?

Nurodykite tiesioginį savo svetainės tikslą.

Atidžiai pagalvokite apie atskiras žiniatinklio šaltinio užduotis. Pavyzdžiui, ji turėtų pateikti naujausią informaciją apie rinkos naujienas, demonstruoti jūsų produktus, leisti lankytojams susisiekti su jumis tiesiogiai iš svetainės puslapių ir pan.

5. Projekto struktūra (pagrindinė funkcija)

Svetainėje gali būti daugybė funkcijų: vartotojo registracijos forma, atsiliepimai, užsakymo mygtukai, pristatymo kalendorius, naujienų kanalas, produktų katalogas su galimybe pereiti į krepšelį, įmontuotas pašto scenarijus, uždaros skiltys klientai - bet kas! Kiekviena iš šių funkcijų jūsų svetainės kūrimo techninėse sąlygose turėtų būti išdėstyta kuo detaliau.

Taigi skyrius „Projekto apimtis“ yra kažkas panašaus į turinį, kuriame pateikiamos funkcijos be kruopštaus jų aprašymo. Šios skilties jums reikės menininko paieškos etape. Tai leis potencialiam Jūsų svetainės kūrėjui matyti bendrą vaizdą ir pateikti apytikslę kainą, o Jūs susisteminsite savo pageidavimus dėl funkcionalumo.

6. Aikštelės struktūra (žemėlapis).

Kitoje svetainės TOR pastraipoje rangovui bus nurodyta, kurie puslapiai bus jūsų svetainėje, kurie skyriai ir poskyriai, kaip jie bus sujungti vienas su kitu, kaip jie bus rodomi svetainės meniu.

Struktūrą lengviau nupiešti nei aprašyti. Grafinėje formoje lengviau galvoti apie santykį tarp svetainės sričių.

Atskirų sklypo dalių sujungimų schema

Šia tema rengiame internetinį seminarą „Pardavimo svetainės turinio sistema“. Ir čia mes išsamiai kalbame apie svetainės struktūrą, apie puslapių ir nuorodų tarp jų ryšį. Rekomenduoju! Aukščiau pateikta nuotrauka yra iš šio internetinio seminaro.

7. Atskiri puslapiai

Kai piešiate svetainės schemą, kiekvienas puslapis yra tik kvadratas. Tačiau atlikėjas turi suprasti, kas ir kokia tvarka bus šioje aikštėje (prisiminkime lentelių pavyzdžius straipsnio pradžioje). Kokie bus informacijos blokai? Ar kiekviename puslapyje bus meniu, šoninės juostos? (atskiras blokas su navigacija), poraštė (apatinis blokas)? Ar norite puslapyje matyti reklamjuostes, paveikslėlius? Ar jie bus statiški ar judantys?

Kuo išsamiau apibūdinsite kiekvieną kiekvieno būsimo šaltinio puslapio elementą, tuo išvesties rezultatas bus artimesnis jūsų idėjoms apie svetainę.

Tiesą sakant, šiame etape a. Apie tai jau rašėme, jei tenka susikurti svetainę, būtinai perskaitykite.

Galite sukurti kiekvieno svetainės puslapio prototipą kartu su išsamiu žodiniu aprašymu. Arba pirmiausia galite sukurti pagrindinių blokų prototipus, kurie kartojasi kiekviename ar daugelyje puslapių, o tada sukurti atskirus puslapius naudodami jau aprašytus blokus.

8. Aikštelės projektavimo reikalavimai

Šiame etape būkite atsargūs. Tarkime, kad dizaineris yra profesionalas. Nereikia užsirašyti kiekvieno žingsnio. Nesakyk: „Padarykite šį mygtuką su perpildymu iš mėlynos į raudoną, o šį tekstą 12 dydžiu ir taip, kad jis mirgėtų“. Išvardykite savo pagrindinius norus. Pavyzdžiui, parodykite esamas svetaines / reklamjuostes / spaudinius, kurie, jūsų manymu, tinka jūsų dizainui. Pasakykite mums, kokios spalvos jums labiau patinka. Tarkime, kad norite sukurti svetainę, skirtą moterų mokymams, dizainerė gali „pamatyti“ ją rausvomis spalvomis, bet jums patinka alyvinė ir oranžinė. Bendras aprašymas norai padės rasti kompromisą tarp Jūsų vizijos ir profesionalios dizainerio išvaizdos.

Būtinai dizaineriui pateikite medžiagas darbui, jei turite: logotipą, firminių spalvų ir šriftų koduotes, jau paruoštus firminio identiteto elementus (spauda, ​​baneriai ir kt.).

Su svetainėmis apie variklius, pvz WordPress arba Joomla galite apsieiti su jau paruoštais šablonais (kartais net nemokamais). Tai sumažina netikrumą: tiesiog pažiūrėkite į šablonus ir išsirinkite jums patinkantį. Kalbant apie dizainą, kai kurie iš jų yra gana keisti, todėl pabandykite pasikonsultuoti su specialistu – tai vis tiek išeis pigiau, nei užsisakyti dizainą nuo nulio.

9. Darbinis svetainės funkcionalumas

Nepatingėkite ir detaliai aprašykite visų funkcijų darbą. Suteikite atlikėjui kuo daugiau informacijos. Atminkite, kad jis neturi telepatijos dovanos ir gali neatspėti, ko norite gauti, kai rašote svetainės technines sąlygas. "prenumeratos forma" arba "kalendorius".

Kokia yra prenumeratos forma? Kaip ji atrodo? Kaip tai veikia? Koks kalendorius? Ar rodoma tik šios dienos data, ar visas paskutinis mėnuo? Ar galiu jame vartyti puslapius ar ne? Atlikėjas gali neatspėti šių niuansų, galiausiai gausite visai ką kita, nei norėjote. Pinigai sumokėti, projektas atitinka TOR (rašėte "kalendorius"- čia yra), ir turėsite pasitenkinti tuo, kas atsitiko, nors tai visai ne tai, ko norėjote, arba permokėti už pokyčius.

Nedvejodami naršykite ir kitas svetaines – konkurentus ar net įmones, kurių veikla su jumis neturi nieko bendra. Konkurentai gali pasiūlyti įgyvendinti jums reikalingas funkcijas, kitose rinkose pasiskolinti įdomių sprendimų, apie kuriuos konkurentai dar nepagalvojo. Dažnai lengviau rasti funkciją kieno nors kito svetainėje ir pateikti atlikėjui nuorodą „tai turėtų veikti taip“, nei rodyti pirštais.

Nepamirškite, kad jūsų svetainė turi būti patogi ne tik vartotojui, bet ir administratoriui. Šiuolaikinės turinio valdymo sistemos paprastai yra intuityviai administruojamos. Bet, jei nežinote, kokiu varikliu veikia atlikėjas, užsirašykite ir administratoriaus funkcijas. Ką jis turėtų daryti svetainėje ir kaip tai įgyvendinti.

Žinoma, jūs turite teisę nežinoti, kaip veiks kuri nors funkcija. Tokiu atveju paprašykite kūrėjo pasiūlyti patvirtinimo parinktis. Patvirtinkite jums tinkantį variantą (įskaitant biudžetą). Atsiminkite: pirmiausia apsvarstykite ir patvirtinkite, tada darykite.

10. Turinio aprašymas

Jei turinį užsakote kartu su svetainės kūrimu ir turite vieną rangovą (pavyzdžiui, agentūrą), turinio aprašymas yra atskiras tekstų kūrėjo TOR. Jei ketinate kurti turinį patys arba užsisakyti iš kito atlikėjo, svetainės kūrėjas vis tiek turėtų turėti idėją, kas kurioje skiltyje bus patalpinta ir kaip ji atrodys. Kur tekstas, kur video, kaip bus kuriamos nuotraukos, ar reikalinga straipsnių peržiūra ir kokia ji bus ir pan.

11. Techniniai reikalavimai

Sunkus dalykas tiems, kurie mažai supranta statybvietės kūrimą. Jei tai suprantate ir jums svarbu, kuria kalba, kurios versijos turi būti parašytas jūsų šaltinis, parašykite apie tai svetainės kūrimo techninėje užduotyje. Arba turite prieglobos vietos diske reikalavimų.

Nenorite visiškai nusivilti priimdami svetainę iš kūrėjo? Tada atidžiai perskaitykite šį straipsnį!

Bet gal tai ne jo kaltė? Juk už bet kokio delegavimo rezultatą atsakingas ne tik atlikėjas, bet ir užsakovas.

Norėdami gauti maksimalų norimą rezultatą, turite žinoti, kaip teisingai sudaryti techninę užduotį kuriant svetainę.

KODĖL JUMS REIKIA UŽDUOTIES?

• Rangovas kompetentinga techninė sklypo plėtros specifikacija padės iš anksto įvertinti darbo kiekį, sudėtingumą ir kainą. Suprasti, ar jis pats susidoros su tokia užduotimi, ar verta imtis padėjėjų. Ir tada daryti būtent tai, ko klientas iš jo tikisi.
• Klientas techninė užduotis suteikia pasitikėjimo, kad jis dokumentais įformino savo pageidavimus dėl būsimos aikštelės, aiškiai nubrėžė terminus, kurių rangovas privalo laikytis, numatė reikalavimus sklypei. Ir jei rezultatas nepatenkinamas, galite pateikti pagrįstą pretenziją: "Neatitinka TOR!"

KĄ JIE RAŠO PRIEMONĖSE?

Užduotis apima šiuos klausimus:

• Kodėl ir kam sukurta svetainė?
• Kuo jis bus užpildytas?
• Kaip visa tai veiks?
• Kas ir kaip dirbs projekte, kas už ką atsakingas?
• Kokia bus produkcija?

PAGRINDINĖS SVETAINĖS PLĖTROS SĄLYGŲ SKYRIAI

1. Informacija apie klientą, tai yra apie Jus

Pateikite kuo daugiau informacijos. Nurodykite visus šaltinius, iš kurių kūrėjas gali gauti trūkstamus duomenis. Tai gali būti lankstinukai, plakatai, elektroninė medžiaga, nuorodos, kontaktai žmonių, kuriems galima užduoti klausimus.

2. Informacija apie projektą

Kas tai bus: vizitinių kortelių svetainė, tinklaraštis, internetinė parduotuvė, įmonės portalas, elektroninė biblioteka?

3. Tikslinė svetainės auditorija

Apibūdinkite savo tikslinę auditoriją, pasakykite, ko jai reikia ir kaip jai gali būti įdomu.

4. Tikslai ir užduotys, kurias svetainė turėtų išspręsti klientui ir auditorijai

Turite aiškiai suprasti, kodėl jums reikalinga svetainė. Norėdami pagerinti vaizdą? Tiesioginiam pardavimui? Dėl naujienų? Ar norite savo svetainės lankytojus paversti prenumeratoriais? Ar norite sukurti išteklių potencialiems partneriams pritraukti?

Nurodykite tiesioginį savo svetainės tikslą.

Atidžiai pagalvokite apie atskiras žiniatinklio šaltinio užduotis. Pavyzdžiui, ji turėtų pateikti naujausią informaciją apie rinkos naujienas, demonstruoti jūsų produktus, leisti lankytojams susisiekti su jumis tiesiogiai iš svetainės puslapių ir pan.

5. Projekto struktūra (pagrindinė funkcija)

Svetainėje gali būti daugybė funkcijų: vartotojo registracijos forma, atsiliepimai, užsakymo mygtukai, pristatymo kalendorius, naujienų kanalas, produktų katalogas su galimybe pereiti į krepšelį, įmontuotas pašto scenarijus, uždaros skiltys klientai - bet kas! Kiekviena iš šių funkcijų jūsų svetainės kūrimo techninėse sąlygose turėtų būti išdėstyta kuo detaliau.

Taigi skyrius „Projekto apimtis“ yra kažkas panašaus į turinį, kuriame pateikiamos funkcijos be kruopštaus jų aprašymo. Šios skilties jums reikės menininko paieškos etape. Tai leis potencialiam Jūsų svetainės kūrėjui matyti bendrą vaizdą ir pateikti apytikslę kainą, o Jūs susisteminsite savo pageidavimus dėl funkcionalumo.

6. Aikštelės struktūra (žemėlapis).

Kitoje svetainės TOR pastraipoje rangovui bus nurodyta, kurie puslapiai bus jūsų svetainėje, kurie skyriai ir poskyriai, kaip jie bus sujungti vienas su kitu, kaip jie bus rodomi svetainės meniu.

Struktūrą lengviau nupiešti nei aprašyti. Grafinėje formoje lengviau galvoti apie santykį tarp svetainės sričių.

7. Atskiri puslapiai

Kai piešiate svetainės schemą, kiekvienas puslapis yra tik kvadratas. Tačiau atlikėjas turi suprasti, kas ir kokia tvarka bus šioje aikštėje (prisiminkime lentelių pavyzdžius straipsnio pradžioje). Kokie bus informacijos blokai? Ar kiekviename puslapyje bus meniu, šoninės juostos? (atskiras blokas su navigacija), poraštė (apatinis blokas)? Ar norite puslapyje matyti reklamjuostes, paveikslėlius? Ar jie bus statiški ar judantys?

Kuo išsamiau apibūdinsite kiekvieną kiekvieno būsimo šaltinio puslapio elementą, tuo išvesties rezultatas bus artimesnis jūsų idėjoms apie svetainę.

8. Aikštelės projektavimo reikalavimai

Nuspręskite dėl spalvų schemos, pasakykite, kokios spalvos jums labiau patinka. Pateikite kūrėjui turimą medžiagą: logotipą, reklamjuostes, spalvų kodus... Parodykite jam veikiančių svetainių internete pavyzdžius, kurios jums patinka ir norite kažko panašaus. Pasakykite mums, kokios spalvos jums labiau patinka. Pavyzdžiui, norite padaryti internetinį puslapį, skirtą moterų treniruotėms, dizainerė padarys ją rožine, bet jums patinka oranžinė. Bendras pageidavimų aprašymas padės rasti kompromisą tarp jūsų vizijos ir profesionalios dizainerio išvaizdos.

9. Darbinis svetainės funkcionalumas

Išsamiai aprašykite, kokias funkcijas norite matyti svetainėje. Suteikite atlikėjui kuo daugiau informacijos. Atminkite, kad jis neturi telepatijos dovanos ir gali neatspėti, ko norite gauti, kai rašote svetainės technines sąlygas. "prenumeratos forma" arba "kalendorius".

Kokia forma? Kam? Kokie daiktai jame turi būti? Kaip ji atrodo? Atlikėjas gali neatspėti šių niuansų, galiausiai gausite visai ką kita, nei norėjote. Pinigai sumokėti, projektas atitinka TOR (rašėte "kalendorius"- čia yra), ir turėsite pasitenkinti tuo, kas atsitiko, nors tai visai ne tai, ko norėjote, arba permokėti už pokyčius.

10. Turinio aprašymas

Jei turinį užsakote kartu su svetainės kūrimu ir turite vieną rangovą (pavyzdžiui, agentūrą), turinio aprašymas yra atskiras tekstų kūrėjo TOR. Jei ketinate turinį kurti patys arba užsisakyti iš kito atlikėjo, svetainės kūrėjas vis tiek turėtų turėti idėją, kas kurioje skiltyje bus patalpinta ir kaip ji atrodys. Kur tekstas, kur video, kaip bus kuriamos nuotraukos, ar reikalinga straipsnių peržiūra ir kokia ji bus ir pan.

11. Techniniai reikalavimai

Sunkus dalykas tiems, kurie mažai supranta statybvietės kūrimą.

Jei nesuprantate, įjunkite logiką.

Pavyzdžiui, jūsų svetainė turėtų:

• vienodai gerai atrodo ant skirtingų pločių monitorių (reaktyvus dizainas);
• būti SEO optimizuotas reklamai;
• gebėti atsispirti virusams;
• turi integruotą seo funkcionalumą ir pan.

Rašykite tik apie tai, kuo esate tikri, arba pasitarkite su specialistu. Geriau pasitarti iš anksto, nei vėliau permokėti už patobulinimus.