Ako napísať vzorku technickej úlohy. Referenčné podmienky podľa GOST

Vývoj technických špecifikácií je základom vytváraného automatizovaného systému. V akom štádiu implementácie EDMS by mal byť tento dokument vytvorený a čo by mal obsahovať? Prečítajte si odpovede na tieto základné a mnohé ďalšie dôležité otázky súvisiace s vývojom zadávacích podmienok v tomto článku.

Zadanie (ďalej len TOR) je výsledkom analýzy procesov organizácie a koncepčných návrhov na automatizáciu týchto procesov. Pred vytvorením TOR je potrebné vykonať informačný prieskum procesov, ktorý je vypracovaný vo forme správy o prieskume, a vyvinúť koncept automatizácie, ktorý obsahuje samotnú myšlienku automatizácie a odhaľuje ciele automatizácie a poskytuje aj základné návrhy architektúry a zloženia systému. Zároveň by mala byť správa o informačných procesoch a koncepcia vypracovaná v dvoch paradigmách: „ako je“ a „ako by malo byť“. Veľmi užitočným doplnkom týchto reportov bude grafické zobrazenie procesov (tzv. procesné modelovanie) v ľubovoľnej zvolenej metodike. Najbežnejšou metodikou v ruskej praxi sú dnes notácie ARIS* s rovnakým názvom súprava nástrojov a UML**. Vývoj EDMS je vždy projektová činnosť ktorá má začiatok a koniec. Vývoj končí prechodom systému do komerčnej prevádzky a začiatkom procesu údržby EDMS.

Projektoví manažéri pre vývoj EDMS majú vždy na výber, ktorou metódou sa budú pri vytváraní systému riadiť: kaskádovým modelom alebo iteračným.

1. Kaskádový model.

Kaskádový alebo klasický vývojový model model vodopádu- vodopádový model) - model procesu vývoja softvéru, v ktorom proces vývoja vyzerá ako tok, ktorý postupne prechádza fázami analýzy požiadaviek, návrhu, implementácie, testovania, integrácie a podpory.

Vo vodopádovom modeli idú fázy vytvárania EDMS jedna za druhou, výsledky jednej fázy sa vyvinú do výsledkov ďalšej. Pri tomto modeli je návrat do predchádzajúcej fázy značne problematický a vyžaduje si revíziu a prehodnotenie mnohých postulátov projektu. Podľa tejto metodiky sú postavené ruské GOST.

2. Iteračný model.

Iteračný prístup iteráciu- opakovanie) - vykonávanie práce súbežne s priebežnou analýzou získaných výsledkov a úpravou predchádzajúcich etáp práce. Zároveň vývoj v každej fáze vývoja prechádza opakujúcim sa cyklom: plánovanie – implementácia – overovanie – hodnotenie.

Iteračný vývojový model je postupný vývoj v každej fáze, v ktorej kompletný proces vytvorenie EDMS, ale v obmedzenom množstve funkčnosti. Proces vývoja pozostáva z takýchto iterácií s neustálym zvyšovaním funkčnosti.

Ktorý z týchto prístupov je správny, závisí od konkrétneho projektu (rozsahu projektových úloh) a od želaní zákazníka.

Napriek tomu, bez ohľadu na zvolený model vývoja, v každom z nich existuje fáza tvorby požiadaviek na vytvorený EDMS. Táto fáza a pravidlá vytvárania samotnej TK sú opísané v ruskej legislatíve, konkrétne v GOST 34. Základné dokumenty - GOST 34.602-89. Informačné technológie. Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému a RD 50-34.698-90. Smernice. Informačné technológie. Súbor noriem a smerníc pre automatizované systémy. Automatizované systémy. Požiadavky na obsah dokumentu.

V iteračnom prístupe sa pri prvom vytváraní požiadaviek vytvorí TOR a s následným objasnením požiadaviek, súkromné ​​referenčné podmienky (ChTZ).

Zloženie zadávacích podmienok

Podľa GOST 34.602-89 sú hlavné časti TK:

1. Všeobecné informácie.

2. Účel a ciele tvorby (vývoja) systému.

3. Charakteristika objektov automatizácie.

4. Systémové požiadavky.

5. Skladba a obsah práce na tvorbe systému.

6. Poradie kontroly a akceptovania systému.

7. Požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky.

8. Požiadavky na dokumentáciu.

9. Zdroje rozvoja.

Všetky tieto oddiely sa dajú rozdeliť na pododdiely a môžu obsahovať prílohy, ktoré sú uvedené na konci dokumentu a sú vypracované ako prílohy k zadávacím podmienkam. CTZ má rovnaké zloženie, ktoré môže byť vytvorené iteratívnym prístupom vo veľkých projektoch na objasnenie požiadaviek. Vyhlásenie o práci pre EDMS musí byť vypracované na listoch formátu A4 v súlade s GOST 2.301-68 * bez rámu, hlavného nápisu a ďalších stĺpcov.

Čísla hárkov (strán) sa uvádzajú od prvého hárku po titulnej strane v hornej časti hárku (nad textom, v strede) po označení TK kódu na EDMS.

Titulná strana TK obsahuje tieto údaje:

Griffin "Schvaľujem";

Úplný názov EDMS;

Názov dokumentu (v našom prípade - "Podmienky referencie" a "Súkromné ​​referenčné podmienky");

Kód dokumentu;

Počet listov;

Umiestnenie dokumentu.

Schvaľovacie víza môžu byť nalepené aj na titulnej strane, alebo sú umiestnené na samostatnom schvaľovacom hárku. Ďalej po titulná strana je tam list s informáciami o vývojároch dokumentu - autoroch, ktorí zostavili text dokumentu alebo urobili technické riešenia opísané v TOR. Schvaľovací hárok a informácie o vývojároch dokumentu je možné vypracovať na jednom hárku ZP - poslednom, v súlade s odporúčaniami GOST 34.602-89 (dodatok 3 k GOST).

Kód TK pre EDMS je označenie projektového dokumentu, ktoré prideľuje zákazník alebo vývojár dokumentu v súlade s GOST 2.201-80**. Kód sa skladá z nasledujúcich častí: prvé 4 znaky - kód vývojárskej organizácie, ďalších 6 znakov - kód klasifikačnej charakteristiky, ďalšie 3 číslice - sériové registračné číslo. Číslo TK môže vyzerať napríklad takto:

TsNTP. 425180,048.

Vlastnosti písania niektorých častí TK

kapitola" Všeobecné informácie» by mala obsahovať informácie o objednávateľovi a možnom realizátorovi diela, o spôsobe určenia zhotoviteľa, rozpočte, z ktorého je tvorba EDMS financovaná a približný časový harmonogram a etapy prác na tvorbe EDMS.

V tejto časti môže byť napríklad uvedené, že dodávateľ je určený uzavretím štátnej zmluvy.

kapitola" Účel a ciele tvorby (vývoja) systému» by mal obsahovať popis hlavného účelu vytvorenia systému a výsledkov, ktoré zákazník od implementácie systému očakáva. Tieto výsledky musia byť ekonomicky merateľné alebo môžu byť špecifikované spôsoby ich merania.

Účelom zavedenia EDMS môže byť napríklad skrátenie času na odsúhlasenie zmlúv na 1 pracovný deň pre všetky pobočky spoločnosti.

kapitola" Charakteristika objektov automatizácie» obsahuje popis procesov v organizácii, ktoré vyžadujú automatizáciu, a je výsledkom správy z informačného prieskumu, ktorá sa zostavuje pri prieskume procesov organizácie.

kapitola" Požiadavky na systém„je hlavnou časťou TOR. Tejto časti by sa mala venovať osobitná pozornosť, pretože je to on, kto reguluje a opravuje mnohé technické vlastnosti budúceho systému.

Táto časť by mala popisovať nasledujúce požiadavky:

1. Požiadavky na systém ako celok vrátane požiadaviek na architektúru systému, skladbu pracovísk, požiadavky na personál systému, požiadavky na spoľahlivosť, požiadavky na ergonómiu, požiadavky na zabezpečenie utajenia (ak sa v systéme spracúvajú dôverné dokumenty), požiadavky na ochranu informácií pred neoprávneným prístupom, požiadavky na škálovanie systému a iné.

2. Požiadavky na funkcie (úlohy) vykonávané systémom musia obsahovať popis funkčnosti podsystémov (modulov) EDMS.

3. Požiadavky na interakciu subsystémov (modulov) EDMS musia popisovať mechanizmy interakcie subsystémov (modulov).

4. Požiadavky organizácie na prepojenie so susednými systémami by mali popisovať, ktoré systémy susedia a ako môžu byť prepojené s ERMS.

Napríklad HR systém môže poskytovať zoznamy užívateľov pre ERMS. 5. Požiadavky na režim prevádzky EDMS by mali obsahovať popis režimu prevádzky (napríklad 24 hodín 7 dní v týždni) a postup vykonávania preventívnych prác na preinštalovanie systému alebo jeho aktualizáciu.

Napríklad aktualizácia systému by sa mala vykonať bez zastavenia fungovania systému.

6. Požiadavky na druhy podpory by mali obsahovať: jazykovú podporu systému, požiadavky na vstupné a výstupné formy EDMS, požiadavky na databázy, požiadavky na organizačnú podporu, požiadavky na informácie, softvérové ​​resp. technická podpora systémov.

7. Požiadavky na správu systému s popisom úloh a zodpovedností správcov systému.

Odporúča sa vytvoriť časť „Zloženie a obsah práce na vytvorení systému“ vo forme tabuľky s názvami fáz práce na vytvorení EDMS, približné dátumy začiatok a koniec etáp, ako aj výsledky ukončenia týchto etáp.

Časť „Postup kontroly a prevzatia systému“ by mala určiť, aké typy skúšok sa musia vykonať na akceptáciu systému, vrátane zoznamu dokumentácie požadovanej pre tieto skúšky.

Napríklad na uvedenie systému do prevádzky je možné vykonať oddelené testy v súlade s programom a metodikou testovania vyvinutou a schválenou zákazníkom.

kapitola" Požiadavky na skladbu a obsah prác prípravy objektu automatizácie na uvedenie systému do prevádzky» opisuje zoznam činností na školenie používateľov EDMS, na vypracovanie príručiek a učebných materiálov, požiadavky na konverziu dát alebo vkladanie prvotných dát do EDMS, požiadavky na vytvorenie infraštruktúry pre fungovanie EDMS.

Popisuje časť Požiadavky na dokumentáciu všeobecné pravidlá vypracovanie pracovnej dokumentácie pre systém a môže sa odvolávať na podnikové normy alebo GOST.

kapitola" Zdroje rozvoja“je konečná a uvádza dokumenty, ktoré slúžili ako základ pre vývoj systému a prijatie určitých technických riešení.

Zároveň by mali byť v texte TOR uvedené odkazy na všetky zdroje rozvoja. Uvedenie jedného alebo druhého zdroja musí byť odôvodnené a potvrdené v texte ZP.

Dúfame, že po prečítaní tohto článku ste sa s ním lepšie oboznámili regulačný rámec ToR, jeho zloženie a obsah a sú teraz pripravené na prácu s týmto dokumentom.

* ARIS (angl. Architecture of Integrated Information Systems) – metodológia a replikovaný softvérový produkt, ktorý vlastní Software AG
pre modelovanie obchodných procesov organizácií.
** UML (angl. Unifi ed Modeling Language) - grafický popisný jazyk pre objektové modelovanie v oblasti vývoja softvéru; bola vytvorená s cieľom definovať, vizualizovať, navrhovať a dokumentovať prevažne softvérové ​​systémy.

Od autora: Ako napísať referenčné podmienky pre vývoj webových stránok? Téma je to dosť rozsiahla a v rámci jedného článku je ťažké ju rozobrať na 100% (ak sa to vôbec dá). ale všeobecné ustanovenia, čo je potrebné vziať do úvahy, na čo si dať pozor pri zostavovaní TOR, sa pokúsim dostatočne podrobne popísať v tomto článku.

Takže TK

Referenčné podmienky sú vypracované pre vývojára stránky. Na CK je potrebné odkázať pri uzatváraní zmluvy medzi objednávateľom a zhotoviteľom. Mala by byť stanovená zodpovednosť za nesplnenie alebo nesprávne splnenie bodov a podmienok TOR na oboch stranách. Ale to najdôležitejšie (podľa mňa), na čo je TK vytvorená, je za urýchlenie procesu vývoja stránky.

Poďme analyzovať tento príklad:

Predpokladajme, že potrebujete kalendár niekde na boku vašej stránky. Vyzeralo to ako maličkosť. Ale čím viac opíšete funkčnosť tohto kalendára, tým rýchlejšie sa dopracujete k výsledku.

Tu to trochu vysvetlím. Kalendár je iný. Existuje kalendár, ktorý jednoducho zobrazuje čísla dní v týždni aktuálneho mesiaca. K dispozícii je kalendár s možnosťou rolovania v mesiacoch. K dispozícii je kalendár s možnosťou listovania mesiacmi a rokmi.

Povedzme, že potrebujete najnovšiu verziu kalendára (s možnosťou rolovania v mesiacoch a rokoch) so zvýrazneným aktuálnym dátumom. V TOR ste uviedli: "potrebný kalendár na bočnom paneli." Zákazník vám vyrobí prvú verziu kalendára (jednoducho zobrazí čísla podľa dní v týždni aktuálneho mesiaca).

Čo máme. Zhotoviteľ dokončil položku TK, ale vy ste chceli úplne iný kalendár. Zdá sa, že všetko je v súlade s TOR, nikto nie je vinný, neprišlo to ku konfliktu, ale to najdôležitejšie je stratené čas a peniaze.

Toto je príklad len banálneho kalendára.

A ak musíte prerobiť niečo vážnejšie, ktorých spracovanie trvá viac ako pol dňa, ako je to v prípade kalendára? A vy nemáte webovú stránku a zákazník sa s vami baví, hoci by mohol dokončiť váš projekt a začať nový.

Preto, než viac Ak popíšete funkčnosť každého modulu stránky, tým rýchlejšie získate výsledok. To by malo zaujímať obe strany.

Z akých položiek sa TOR zvyčajne skladá?

Predstavme si, že ste majiteľom nejakej firmy alebo firmy. Vaša spoločnosť sa zaoberá výrobou akéhokoľvek produktu a jeho realizáciou. Máte kupujúcich. Spolupracujete s predajcami (obchody a internetové obchody), servisnými strediskami, spotrebiteľmi produktov. Alebo pre takúto firmu robíte web a potrebujete napísať technickú špecifikáciu.

Bez ohľadu na to, v akej úlohe ste, prvá vec, ktorú musíte urobiť, je preštudovať si štruktúru organizácie, čo robí, nomenklatúru, charakteristiky a vo všeobecnosti všetko, čo súvisí s produktom a spoločnosťou. Od toho, ako hlboko sa zákazník ponorí do podstaty toho, čo sa deje v podniku, závisí od toho, čo sa stane na mieste. Úloha je tu preto vzájomná: zákazník by mal o podniku povedať čo najpodrobnejšie a umelec by mal dôkladne pochopiť podstatu toho, čo sa deje.

Aj keď sami napíšete technické špecifikácie pre firmu, ktorá bude stránku robiť, nie je zlé to všetko odhadnúť na papier.

Poďme k bodom.

Popis lokality

Tu môžete napísať pár vetami o spoločnosti, čo robí. Urobte niečo ako úvod.

pre koho - cieľové publikum stránky:

• potenciálnych kupcov
• predajcovia produktov (obchody, internetové obchody)
• servisné strediská
• partneri (firmy)
• spotrebitelia produktov (tí, ktorí si už kúpili)

Prečo potrebujete webovú stránku:

• Na zlepšenie imidžu spoločnosti
• Na zvýšenie predaja
• Pre pohodlie zákazníka

Typ lokality:

• korporátne
• Webstránka - vizitka
• Internetový obchod

Jazykové verzie:

• Angličtina
• ruský

Stránka musí vyriešiť nejaké problémy. Podľa toho sa posúvame ďalej po cieľoch a zámeroch stránky.

Ciele a ciele stránky

V tejto časti TOR si prejdeme celú cieľovú skupinu a popíšeme okruh úloh, ktoré by pre nich mala stránka vyriešiť.

Potenciálni kupci produktov.

Cieľ: prilákať viac kupujúcich a presvedčiť ich, aby urobili prvý nákup, pomôžte pri výbere.

Problémy treba riešiť:

Poskytujte kvalitné, komplexné informácie o produktoch, doplnkových službách, zárukách, servise, spôsoboch výberu.

• Odošlite informácie o predajniach
• Odošlite informácie o maloobchode

Poskytnite príležitosť položiť otázku prostredníctvom organizácie online poradenstva potenciálnych kupcov špecialistami podniku na výber, nákup produktov.

Ideme teda cez celú cieľovú skupinu. Ak sledujete našu stránku, popisujeme ciele a zámery pre predajcov produktov (obchody, internetové obchody), servisné strediská, partnerov (firmy), spotrebiteľov produktov. To znamená, čo by mala stránka robiť konkrétne pre každú z nich.

Teraz vymenujeme moduly lokality.

Funkčnosť stránky

Ak chcete uviesť funkcie stránky, musíte sa rozhodnúť, čo potrebuje:

• Potrebujete novinky na stránke
• Je potrebné reklamný blok
• Vyžaduje sa registrácia
• Potrebujem súkromnú časť stránky (len pre registrovaných používateľov)
• Potrebujete formulár spätnej väzby?
• Potrebujem poštový skript
• Atď. a tak ďalej.

Po tomto všetkom sa dostávame k tomu najdôležitejšiemu a najzaujímavejšiemu. Samozrejme, všetka práca vykonaná vyššie je veľmi dôležitá, ale teraz je to ešte „horúcejšie“.

Popis funkčnosti stránky

Zapnuté tento moment vieme, pre koho je stránka určená, aké ciele a úlohy by mala spĺňať, jej doplnková funkcionalita.

Nastal čas, keď potrebujete priniesť všetky zozbierané informácie do systému a krásne ich vložiť na stránku. Na uľahčenie úlohy a nie znovuobjavenie kolesa sa môžete pozrieť na stránky súvisiace témy. Naučte sa od nich niečo, pozrite si a otestujte ich funkčnosť a pokúste sa vylepšiť to, čo sa vám na vašej stránke zdalo nepohodlné. V zásade si môžete pozrieť stránky s podobnými témami (a ak nemáte skúsenosti, potom dokonca musíte) na samom začiatku zostavovania TOR.

Odporúčam začať s položkami menu. Potrebuje zobraziť hlavné stránky webu a zabezpečiť, aby si každý z návštevníkov rýchlo našiel informácie pre seba. A návštevníci sú naša cieľová skupina. Menu bude obsahovať veľa položiek, takže bude vo forme rozbaľovacieho zoznamu.

Najprv musíte povedať o spoločnosti. Môžu tu byť stránky o spoločnosti, histórii spoločnosti, kontaktoch, recenziách.

Samozrejmosťou by mala byť položka menu „produkty“ s podpoložkami „katalóg produktov“, „vydania“, „recenzie produktov“.

Vo všeobecnosti dúfam, že je jasné, ako maľovať. Predstavím konečnú verziu možného menu pre našu stránku:

O spoločnosti

• históriu spoločnosti
• kontakty
• recenzie

Správy

• diania
• zásob
• nové na stránke

Produkty

• Katalóg produktov
• vydania
• recenzie produktov

servis

• servisné oddelenie
• záručný servis
• pozáručný servis

Spotrebiteľ

• nákup a doručenie
• použitie
• o službe

Obchody a internetové obchody

• produktové fotografie
• FAQ

Servisné strediská

• Ako sa stať servisné stredisko
• FAQ

Partneri

• pozvanie na spoluprácu
• FAQ

Nejako sme prišli na jedálny lístok. Teraz musíte popísať, čo bude na každej stránke a ako to celé funguje ako celok. Okrem toho uveďte približné rozloženie stránky. Dá sa nakresliť na papier ceruzkou, naskenovať a priložiť k TK. Jediná vec, ktorú poviem, je, že neobmedzujú fantáziu dizajnéra, náčrt v samom všeobecný pohľad.

Táto časť sa mení v závislosti od toho, ako chcete, aby vaša stránka vyzerala. Možno nepotrebujete toľko bannerov v hornej časti, možno potrebujete uviesť kontakty v hornej časti (adresa, telefón, fax), možno vo forme ikon „mapa stránok“, „domov“, „kontakty“. Možno nepotrebujete správy vľavo, ale vľavo zobrazte „propagácie a vydania“.

Hlavná vec je teraz opísať logiku práce.

Prevádzková logika

Popíšem na základe obrázku vyššie.

Horná časť lokality zostáva rovnaká na každej stránke lokality. Informačný kanál noviniek je viditeľný iba na domovskej stránke. Na vedľajších stránkach vľavo zobrazujeme podpoložky menu položky, v ktorej sa práve nachádzame (ak sa nachádzame napríklad na stránke „servis“, tak zobrazujeme odkazy na „záručný servis“, „post -záručný servis"). Preto prechody na týchto odkazoch vedú na príslušné stránky. Tu pod podpoložkami vľavo zobrazujeme údaje pre kontaktovanie online konzultantov (Skype, ICQ). Blokové propagácie a vydania zostávajú na každej stránke. Päta stránky sa zobrazuje rovnako na každej stránke.

Približne tak je opísaná všeobecná logika práce.

Teraz podrobne opíšeme každý blok. Napríklad „Správy“.

"Správy" z 10 najnovšie správy. Každá novinka by mala obsahovať názov novinky, dátum uverejnenia, krátky začiatok správy (4-5 riadkov) a odkazy „prečítaj celé“. Kliknutím na odkaz "čítať celé" sa dostaneme na stránku s novinkami. Správy, ktoré boli zasiahnuté, sa zobrazujú namiesto hlavného obsahu. Obsahuje aj názov novinky, dátum vydania. Naľavo sa zobrazuje aj informačný kanál. Správy z predchádzajúcich mesiacov a rokov sú archivované. To znamená, že pod správami za aktuálny mesiac zobrazujeme „archív za (taký a taký mesiac alebo rok)“. Po kliknutí na odkaz „archivovať za (taký mesiac alebo rok)“ dole vypadne zoznam noviniek za príslušný mesiac/rok.

Takto popisujeme činnosť každého bloku. Nezabudnime ani na puzdro s kalendárom. A čo je najdôležitejšie, musíte maľovať dielo katalógu produktov. Tu vám dávam úlohu: skúste sa zamyslieť a popísať, ako bude katalóg fungovať. Pošlite svoje možnosti e-mailom. Najlepšie uverejníme.

Čo iné by malo byť? Bolo by pekné uviesť kompatibilitu.

Kompatibilita

V tomto odseku uvádzame, ktoré operačné systémy a v ktorých prehliadačoch by mala stránka vyzerať rovnako dobre. V akej verzii, v akom jazyku by sa malo písať. Aký CMS sa používa. Stojí za to poukázať na to, ak skutočne rozumiete tomu, o čom hovoríte.

Ak tieto otázky nevlastníte, jednoducho uveďte prehliadače, v ktorých sa má stránka správne zobrazovať. Vo zvyšku počítajte so svedomím interpreta.

Záver

V tomto článku som sa nesnažil ukázať, že takto sa zostavuje TK a nič iné. Urobte to a nebudete mať žiadne problémy. Zostavenie kvalitného TOR je skôr otázkou skúseností. V prvej dvojici sa nie každému podarí zostaviť kompetentnú TK.

V tomto článku som chcel ukázať princípy, podľa ktorých sú zadávacie podmienky postavené, hlavné body, ktorým sa oplatí venovať pozornosť. Do akej miery sa mi to podarilo, dúfam, že sa poučím z vašich komentárov.

A nezabudnite na výzvu!

Od autora: Ako napísať referenčné podmienky (TOR) pre rozvoj stránky? Téma je pomerne rozsiahla a v rámci jednej poznámky je ťažké ju rozobrať na 100% (ak je to vôbec možné). Ale všeobecné ustanovenia, o tom, čo je potrebné vziať do úvahy a na čo si dať pozor pri zostavovaní webovej stránky, sa pokúsim uviesť dostatočne podrobne.

Takže zadávacie podmienky pre rozvoj stránky

Zadávacie podmienky sú vypracované pre developera. Na CK je potrebné odkázať pri uzatváraní zmluvy medzi objednávateľom a zhotoviteľom. Mala by byť stanovená zodpovednosť za nesplnenie alebo nesprávne splnenie bodov a termínov na oboch stranách. Ale najdôležitejšia vec (podľa mňa), pre ktorú je technická úloha vytvorená, je pre urýchlenie procesu vývoja projektu.

Poďme analyzovať tento príklad:

Predpokladajme, že potrebujete kalendár niekde na boku vašej stránky. Vyzeralo to ako maličkosť. Ale čím viac opíšete jeho funkčnosť, tým rýchlejšie získate výsledok.

Tu to trochu vysvetlím. Existuje kalendár, ktorý jednoducho zobrazuje čísla dní v týždni aktuálneho mesiaca. A je tu možnosť posúvania sa po mesiacoch. K dispozícii je kalendár s možnosťou listovania mesiacmi a rokmi.

Povedzme, že chcete najnovšiu verziu (s možnosťou rolovania v mesiacoch a rokoch) so zvýrazneným aktuálnym dátumom. V podmienkach zadania ste uviedli: „na bočnom paneli je potrebný kalendár.“ Urobí vám prvú možnosť (jednoducho zobrazuje čísla dní v týždni aktuálneho mesiaca).

Čo máme. Zhotoviteľ splnil položku TK, ale vy ste chceli niečo úplne iné. Zdá sa, že všetko je v súlade, nikto za to nemôže, neprišlo to ku konfliktu, ale to najdôležitejšie je stratené čas a peniaze.

Toto je príklad len banálneho kalendára.

A ak musíte prerobiť niečo vážnejšie, ktorých spracovanie trvá viac ako pol dňa, ako je to v prípade kalendára? Dodávateľ sa s vami zahráva, keď by mohol dokončiť váš projekt a začať nový.

Preto, než viac opíšete funkčnosť každého modulu, tým rýchlejšie získate výsledok. To by malo zaujímať obe strany.

Ktoré položky zvyčajne pozostávajú z technickej úlohy?

Predstavme si, že ste majiteľom nejakej firmy alebo firmy. Vaša spoločnosť sa zaoberá výrobou akéhokoľvek produktu a jeho realizáciou. Máte kupujúcich. Spolupracujete s predajcami (obchody a internetové obchody), servisnými strediskami, spotrebiteľmi produktov. Alebo robíte zdroj pre takúto spoločnosť a potrebujete napísať technickú úlohu.

Bez ohľadu na to, akú úlohu hráte, prvá vec, ktorú musíte urobiť pred vypracovaním technickej úlohy na vytvorenie dizajnu webovej stránky, je preštudovať si štruktúru organizácie, čo robí, nomenklatúru, vlastnosti a vo všeobecnosti všetko, čo s ňou súvisí. s produktmi a so spoločnosťou. Od toho, ako hlboko sa zákazník ponorí do podstaty toho, čo sa deje v podniku, závisí od toho, čo sa stane so zdrojom. Úloha je tu preto vzájomná: zákazník by mal o podniku povedať čo najpodrobnejšie a umelec by mal dôkladne pochopiť podstatu toho, čo sa deje.

Aj keď sami napíšete zadanie pre firmu, ktorá bude robiť váš projekt, nie je zlé si to všetko vyrátať na papieri.

Poďme k bodom.

Popis

Tu môžete napísať pár vetami o spoločnosti, čo robí. Urobte niečo ako úvod.

Pre koho je cieľová skupina:

potenciálnych kupcov

predajcovia produktov (obchody, internetové obchody)

servisné strediská

partneri (firmy)

spotrebitelia produktov (tí, ktorí si už kúpili)

Prečo potrebujete webovú stránku:

Na zlepšenie imidžu spoločnosti

Na zvýšenie predaja

Pre pohodlie zákazníka

korporátne

Webstránka - vizitka

Internetový obchod

Jazykové verzie:

Angličtina

Stránka musí vyriešiť nejaké problémy. Podľa toho sa posúvame ďalej v rámci cieľov a zámerov.

Ciele a ciele

V tejto časti zadávacích podmienok prejdeme celú cieľovú skupinu a popíšeme okruh úloh, ktoré by pre nich mala stránka riešiť.

Potenciálni kupci produktov.

Cieľ: prilákať viac kupujúcich a presvedčiť ich, aby urobili prvý nákup, pomôcť pri výbere.

Úlohy, ktoré treba vyriešiť:

Poskytujte kvalitné a komplexné informácie o produktoch, doplnkové služby, záruka, servis, spôsoby výberu.

Odošlite informácie o predajniach

Odošlite informácie o maloobchode

Poskytnite príležitosť položiť otázku prostredníctvom organizácie online poradenstva potenciálnych kupcov špecialistami podniku na výber, nákup produktov.

Ideme teda cez celú cieľovú skupinu. Taktiež popisujeme ciele a zámery pre predajcov produktov (obchody, internetové obchody), servisné strediská, partnerov (firmy), spotrebiteľov produktov. To znamená, čo by mala stránka robiť konkrétne pre každú z nich.

Teraz poďme na zoznam modulov.

Funkčnosť stránky

Ak chcete uviesť funkcie, musíte sa rozhodnúť, čo potrebuje:

Vyžaduje sa registrácia

Potrebujem uzavretú sekciu (len pre registrovaných užívateľov)

Potrebujete formulár spätnej väzby?

Atď. a tak ďalej.

Moderné trendy a prístupy vo vývoji webu

Naučte sa algoritmus pre rýchly rast od nuly pri vytváraní webových stránok

Po tomto všetkom sa dostávame k tomu najdôležitejšiemu a najzaujímavejšiemu. Samozrejme, všetka práca vykonaná vyššie je veľmi dôležitá, ale teraz je to ešte „horúcejšie“.

Popis funkčnosti

V tejto chvíli vieme, pre koho je stránka určená, aké ciele a úlohy by mala spĺňať, jej doplnková funkcionalita.

Nastal čas, keď potrebujete všetky zozbierané informácie preniesť do systému a krásne ich dať. Aby ste si túto úlohu uľahčili a neobjavili znovu koleso, môžete si pozrieť zdroje na podobné témy. Naučte sa od nich niečo, pozrite si a otestujte ich funkčnosť a pokúste sa vylepšiť to, čo sa vám na vašom projekte zdalo nepohodlné. V zásade si môžete pozrieť stránky podobných predmetov (a ak nemáte skúsenosti, potom dokonca musíte) na samom začiatku prípravy zadávacích podmienok.

Odporúčam začať s položkami menu. Potrebuje zobraziť hlavné stránky a zabezpečiť, aby si každý z návštevníkov rýchlo našiel informácie pre seba. A návštevníci sú naša cieľová skupina. Menu bude obsahovať veľa položiek, takže bude vo forme rozbaľovacieho zoznamu.

Najprv musíte povedať o spoločnosti. Môžu tu byť stránky o spoločnosti, histórii spoločnosti, kontaktoch, recenziách.

Samozrejmosťou by mala byť položka menu „produkty“ s podpoložkami „katalóg produktov“, „vydania“, „recenzie produktov“.

Vo všeobecnosti dúfam, že je jasné, ako maľovať. Predstavím finálnu verziu možného menu:

O spoločnosti

históriu spoločnosti

kontakty

Produkty

Katalóg produktov

recenzie produktov

servisné oddelenie

záručný servis

pozáručný servis

spotrebiteľ

nákup a doručenie

použitie

o službe

obchody a online obchody

produktové fotografie

FAQ

servisné strediská

Ako sa stať servisným strediskom

FAQ

partneri

pozvanie na spoluprácu

FAQ

Nejako sme prišli na jedálny lístok. Teraz musíte popísať, čo bude na každej stránke a ako to celé funguje ako celok. Plus poskytnúť hrubé rozloženie. Dá sa nakresliť na kus papiera ceruzkou, naskenovať a priložiť k zadávacím podmienkam. Jediné, čo poviem, je, že neobmedzujte fantáziu dizajnéra, načrtnite ho v najvšeobecnejšej forme.

Táto časť sa mení v závislosti od toho, ako chcete, aby vaša stránka vyzerala. Možno nepotrebujete toľko bannerov v hornej časti, možno potrebujete uviesť kontakty v hornej časti (adresa, telefón, fax), možno vo forme ikon „mapa stránok“, „domov“, „kontakty“. Možno nepotrebujete správy vľavo, ale vľavo zobrazte „propagácie a vydania“.

Hlavná vec je teraz opísať logiku práce.

Prevádzková logika

Popíšem na základe obrázku vyššie.

Vrchná časť(hlavička) zostáva na každej stránke rovnaká. Informačný kanál je viditeľný iba na hlavnej stránke. Na vedľajších stránkach vľavo zobrazujeme podpoložky menu položky, v ktorej sa práve nachádzame (ak sa nachádzame napríklad na stránke „servis“, tak zobrazujeme odkazy na „záručný servis“, „post -záručný servis"). Preto prechody na týchto odkazoch vedú na príslušné stránky. Tu pod podpoložkami vľavo zobrazujeme údaje pre kontaktovanie online konzultantov (Skype, ICQ). Blokové propagácie a vydania zostávajú na každej stránke. Päta (päta) sa zobrazuje rovnako na každej strane.

Približne tak je opísaná všeobecná logika práce.

Teraz v našej TK pre vývoj stránky podrobne popíšeme každý určený blok stránky. Napríklad „Správy“.

"Správy" 10 najnovších správ. Každá novinka by mala obsahovať názov novinky, dátum vydania, krátky začiatok správy (4-5 riadkov) a odkaz „prečítať celé“. Kliknutím na odkaz "čítať celé" sa dostaneme na stránku s novinkami. Správy, ktoré boli zasiahnuté, sa zobrazujú namiesto hlavného obsahu. Obsahuje aj názov novinky, dátum vydania. Naľavo sa zobrazuje aj informačný kanál. Správy z predchádzajúcich mesiacov a rokov sú archivované. To znamená, že pod správami za aktuálny mesiac zobrazujeme „archív za (taký a taký mesiac alebo rok)“. Po kliknutí na odkaz „archivovať za (taký mesiac alebo rok)“ dole vypadne zoznam noviniek za príslušný mesiac/rok.

Takto popisujeme činnosť každého bloku. Nezabudnime ani na puzdro s kalendárom. A čo je najdôležitejšie, musíte maľovať dielo katalógu produktov. Tu vám dávam úlohu: skúste sa zamyslieť a popísať, ako bude katalóg fungovať. Pošlite svoje možnosti e-mailom. Najlepšie uverejníme.

Čo iné by malo byť? Bolo by pekné uviesť kompatibilitu.

Kompatibilita

V tomto odseku našich podmienok pre tvorbu stránky uvádzame, na ktorých operačných systémoch a v ktorých prehliadačoch by mala stránka vyzerať rovnako dobre. V akej verzii, v akom jazyku by sa malo písať. Aký CMS sa používa. Stojí za to poukázať na to, ak skutočne rozumiete tomu, o čom hovoríte.

Ak tieto otázky nevlastníte, jednoducho uveďte prehliadače, v ktorých sa má stránka správne zobrazovať. Vo zvyšku počítajte so svedomím interpreta.

Záver

V tomto článku som sa nesnažil ukázať, že takto sa zostavuje TK a nič iné. Urobte to a nebudete mať žiadne problémy. Zostavte kvalitu referenčné podmienky pre vývoj webových stránok je skôr otázka skúsenosti. V prvom páre nie každý bude schopný vypracovať kompetentnú technickú úlohu.

V tomto článku som chcel ukázať príklad a princípy, podľa ktorých je zostavený vzor zadávacích podmienok pre vývoj dizajnu a logiky webovej stránky, ako aj hlavné body, ktorým by ste mali venovať pozornosť. Do akej miery sa mi to podarilo, dúfam, že sa poučím z vašich komentárov.

A nezabudnite na výzvu!

Pri vývoji akéhokoľvek projektu. Ako sa pripravuje tento dokument? O tom sa bude diskutovať v článku.

Technická úloha - čo to je?

Pred začatím akéhokoľvek projektu je potrebné vypracovať plán. Stavebníctvo, podnikanie, bývanie - absolútne každá pracovná oblasť si vyžaduje vypracovanie vhodného plánu. Zároveň vôbec nezáleží na tom, aká náročná alebo vážna je tá či oná práca. Vypracovanie technickej úlohy a v skutočnosti bežného akčného plánu je tu kľúčovou etapou.

Zadávacie podmienky potrebujú obe strany pracovného toku naraz: dodávateľ aj zákazník. Medzi týmito dvoma osobami často dochádza k hádkam, konfliktom a nedorozumeniam. Dobre navrhnutý akčný plán pomôže prísne regulovať všetky povinnosti každej strany.

Prečo technická úloha pre zákazníka?

Ako už bolo spomenuté, vypracovanie zadávacích podmienok je nevyhnutný proces, ktorý je užitočný pre obe strany. pracovná zmluva. Teraz však stojí za to hovoriť o tom, prečo predložený dokument potrebuje priamy zákazník.

Najdôležitejšou vecou, ​​ktorú možno poznamenať, je skutočnosť, že zadávacie podmienky vytvára iba zákazník. Ide o akýsi akčný plán, zmluvu o poskytovaní služieb. Pomocou tohto dokumentu môžu umelci jasne definovať svoje pracovné funkcie, ako aj to, čo presne sa od nich vyžaduje. Uvažovaný dokument by mal byť vždy vypracovaný veľmi kvalitne a starostlivo. Zákazník teda musí vziať do úvahy všetky hlavné tézy a body a tiež sa vyhnúť protichodným momentom. Ak je dokument vyhotovený správne, zákazník bude môcť vždy nespokojného dodávateľa upozorniť na určitú klauzulu zmluvy.

Prečo technická úloha pre účinkujúceho?

Dodávateľ dostane vzorky technických špecifikácií pred začatím vykonávania konkrétneho diela. Pracovník je povinný si pozorne prečítať všetky body, ktoré sú v dokumente. Tento krok pomôže vyhnúť sa manipulácii zo strany zákazníka. Mnohí šéfovia teda môžu od zamestnancov požadovať niečo, čo nebolo prediskutované v zadávacom konaní.

Dodávateľ musí objasniť všetky potrebné body a výšku platby. Preto sa oplatí zabezpečiť, aby sa hotovostné platby týkali iba tých bodov, ktoré sú uvedené v dokumente. V opačnom prípade môžu nepozorní umelci pracovať zadarmo.

Dodávateľ by preto mal čo najčastejšie venovať pozornosť vzoru zadávacích podmienok. To mu pomôže vyhnúť sa zbytočným problémom a nedorozumeniam.

Spustenie dokumentu

Kde mám začať s vypĺňaním dokumentu? Zadania pre výkon práce by mali vždy začínať všeobecnými ustanoveniami a cieľmi. Čo je zahrnuté vo všeobecných ustanoveniach? Najprv malý slovníček. Samozrejme, nie je to podmienkou. Ak je však dokument úzko zameraný, a teda plný špecifickej terminológie, stále stojí za to opraviť malý slovník. V každom prípade to bude ďalší krok k vzájomnému porozumeniu medzi objednávateľom a zhotoviteľom. Po druhé, všeobecné ustanovenia musia obsahovať údaje o zmluvných stranách.

Čo je zahrnuté v cieľoch technickej úlohy? Asi sa to dá ľahko uhádnuť. Preto je potrebné stručne uviesť, aký druh projektu sa vyvíja, prečo je potrebný a ako možno dosiahnuť konečný výsledok. Všetky úlohy a ciele by mali byť opísané čo najpodrobnejšie a najjasnejšie. Tento prístup pomôže vytvoriť vzájomné porozumenie medzi zmluvnými stranami.

Požiadavky a termíny

Akékoľvek zadávacie podmienky na výkon práce musia nepochybne obsahovať určité požiadavky, ako aj jasne stanovené termíny. S načasovaním je všetko relatívne jasné. Aj keď stojí za zmienku, že je lepšie vziať si čas s určitou rezervou. Okrem toho rýchlosť vykonania objednávky by nemala ovplyvniť kvalitu. V prípade, že zhotoviteľ poruší ustanovené lehoty na plnenie, zmluva musí pre tento prípad obsahovať určité sankcie.

Čo poviete na požiadavky? Zákazník si musí pamätať, že všetky požiadavky sú rozdelené do dvoch hlavných typov: špeciálne a funkčné. Funkčné požiadavky sú do istej miery ilustratívne, obrazné. Sú to určité obrázky, prvky, náčrty toho, čo by chcel zákazník vidieť. Osobitné požiadavky sú prísne regulované, čo naznačuje určité úlohy a spôsoby vykonávania. Prirodzene, výrazne by mali prevládať tie špeciálne. V opačnom prípade môže umelec jednoducho úplne nepochopiť, čo presne od neho chcú.

Zodpovednosť a podávanie správ

Stojí za to povedať trochu viac o dvoch najdôležitejších prvkoch, ktoré by mala obsahovať absolútne každá vzorka technických špecifikácií. Je to o zodpovednosti strán a zodpovednosti. Čo je každý z týchto prvkov?

Je žiaduce vytvárať správy po etapách, najmä ak sú zadávacie podmienky rozsiahle. Hneď po dokončení určitej fázy práce je možné predkladať správy (vyžaduje sa). Okrem toho vám takýto systém umožňuje udržiavať umelca v dobrej kondícii. V opačnom prípade môže všetko urobiť na poslednú chvíľu, a preto mimoriadne nekvalitne.

Čo možno povedať o zodpovednosti strán? Okamžite treba poznamenať, že takáto položka nie je povinná. Mnohí zákazníci však stále považujú za potrebné regulovať hlavné druhy pokút, pokút a sankcií rôzne porušenia. Odporúča sa uviesť hlavné prvky zodpovednosti v dokumentoch, ako sú podmienky obstarávania, prepravy atď.

Príprava zadávacích podmienok

Akákoľvek technická úloha (dodávka, výstavba, preprava atď.) musí byť vypracovaná veľmi kompetentne a kvalitne. Je to potrebné, po prvé, aby v budúcnosti nedochádzalo k súdnym sporom, sporom a konfliktom v dôsledku nedorozumení medzi stranami. A po druhé, pre jednoduché pohodlie. Nie každý zákazník je schopný kompetentne vypracovať technickú úlohu. Často sa na tento prípad najímajú právnici, hoci to nedáva veľký zmysel.

Stačí si zapamätať niekoľko jednoduchých pravidiel:

• zmluva musí byť podrobná a podrobná (netreba to však preháňať; je nepravdepodobné, že by aspoň jeden výkonný umelec chcel čítať viaczväzkové komentáre k požiadavkám);
• zmluva musí byť jasná, bez vody a zbytočných informácií;
• úloha by nemala byť akousi dogmou; stojí za to pripomenúť, že ide len o indikáciu, aj keď prísne regulovanú - či už ide o technickú úlohu Údržba alebo vysádzanie stromov.

Všetky vyššie uvedené rady sú správne malá časť z toho, čo sa dalo povedať. Stále však môžete zákazníkom poskytnúť niekoľko pokynov. Takže referenčné podmienky (pre údržbu alebo výstavbu) môžu byť zostavené podľa šablóny. V tomto prípade nie je potrebné túto šablónu odniekiaľ preberať; Ak je teda spísanie zmluvy o poskytovaní služieb celkom bežnou povinnosťou, potom nebude až také ťažké vybudovať si pár klišé.

Je potrebné pripomenúť, aké dôležité je kontrolovať normy: či už ide o GOST, regulačné alebo právne akty, miestne akty atď.

Čo je to technická úloha? Ako to urobiť a prečo je to potrebné? Príklady, ukážky, tipy a triky.

Zdalo by sa, aké je to skvelé, keď vám dokonale rozumie. Rozdal pár fráz a tu je to, čo si si predstavoval. Žiaľ, takto to nefunguje.

Problém vnímania informácií je večný. Efekt rozbitého telefónu častý výskyt. A čo povedať, ak si jednoducho neviete dať úlohu? Áno, aj to sa stáva a treba s tým nejako pracovať, ale ako? Aby výsledky úloh, ktoré ste si stanovili, splnili vaše očakávania, napíšte si zadávacie podmienky.

Čo je to technická úloha

Zadanie (alebo TOR) - dokument, ktorý obsahuje požiadavky zákazníka na produkty alebo služby poskytované dodávateľom. Jednoducho povedané: Chcem tak a tak, aby bolo sedem navzájom kolmých čiar a dokonca aj niektoré červené a niektoré bezfarebné kresby (video o tejto téme na konci materiálu, odporúčam vám ho pozrieť).

Dizajnové oddelenie

Tento dokument môže mať jednu stranu A4 alebo celý zväzok, všetko závisí od úloh a želaní, ktoré sú v ňom zahrnuté. Môžete napríklad napísať technickú úlohu pre malú vstupnú stránku (jednostránkový web) alebo pre komplex softvér pomocou strojového učenia a iných trikov.

Prečo potrebujete technickú úlohu

• Stanoviť úlohu pre účinkujúcich.
• Aby ste podrobne opísali, čo chcete na konci získať.
• Dohodnúť sa na poradí prác.
• Hodnotiť a akceptovať prácu po implementácii.
• Do ... (pridajte svoje možnosti do komentárov).

V skutočnosti existuje oveľa viac úloh a výhod technickej úlohy ako v zozname vyššie. Pre mňa osobne je hlavnou úlohou, ktorú TK rieši, implementácia toho, čo potrebujem, s minimálnymi odchýlkami od očakávaní (mojich očakávaní).

Vďaka technickej špecifikácii sa vždy môžete opýtať na čas realizácie, peniaze a dodržanie deklarovaných vlastností. finálny produkt alebo služby.

V skutočnosti ide o seriózny dokument, ktorý zostavuje zákazník a dodávateľ. Až do tej miery, že sú stanovené sankcie a povinnosti strán. Existuje množstvo GOST, prečítajte si viac o Habré.

Vývoj technických špecifikácií

Ak hovoríme o hre „dospelým spôsobom“, napríklad podmienky vývoja mobilná aplikácia alebo webstránka, tak to je samostatná práca, za ktorú sa platia nemalé peniaze. Privediete osobu, zvyčajne bývalého alebo súčasného technického riaditeľa, a požiadate ju, aby vám pomohla.

Brada je voliteľná

V závislosti od objemu projektu/úloh táto osoba zozbiera všetky vaše „želania“, preloží ich do odborného jazyka, prípadne pripraví náčrty (ako by to približne malo vyzerať) a dá vám hotový dokument. Potom tento dokument prevediete na účinkujúcich (tím vo vašej spoločnosti alebo na outsourcing), dohodnete sa na peniazoch, podmienkach a pustíte sa do práce.

Tip: CTO musí byť vo vašom tíme, inak si s najväčšou pravdepodobnosťou v procese implementácie niečo nevšimnete. Jednoducho nemáte dostatok vedomostí na všetko. Kto sa podieľal na písaní TK, ten kontroluje.

Aká je špecifikácia

Všetko bude závisieť od šablóny, ktorú si vyberiete (niekoľko odkazov na šablóny/príklady uvediem o niečo neskôr), ale v referenčných podmienkach sú zahrnuté základné bloky:

1. Popis projektu/úlohy. Stručne napíšeme, aký druh projektu alebo úlohy je potrebné dokončiť.
2. Účel a ciele. Aké sú ciele projektu.
3. Požiadavky. Dizajn, funkcie, technológie, ktoré sú potrebné.
4. Popis prác. Čo, kedy a ako sa bude robiť.
5. Postup kontroly a prijatia. Ako bude dielo prijaté, čo možno považovať za dokončené.
6. Aplikácie. Skice, skice, prototypy.

Cena práce je zvyčajne uvedená v samostatnej prílohe k zmluve, ale stáva sa to vtedy, keď zmluvné strany predpíšu sumy v samotnom zadávacom podmienkach.

Prepáčte, že som prerušil čítanie. Pripojte sa k môjmu telegramovému kanálu. Čerstvé oznámenia článkov, vývoj digitálnych produktov a rastový hack, všetko je tam. Čakám na teba! Pokračujeme...

Príklady referenčných podmienok

Napriek tomu, že vývoj technických špecifikácií je zložitý proces, ale veľmi zaujímavý. Vašou úlohou je znovu vytvoriť obrázok konečného výsledku a potom ho po častiach opísať.

Príklad jednej z mojich technických špecifikácií na aktualizáciu aplikácie Smart TV. Úlohy pre zložitejšie a komplexnejšie produkty už boli zostavené s pomocou kolegov z technického oddelenia. Neváhajte požiadať o pomoc svojich spolupracovníkov, zapojte ich do procesu čo najčastejšie. A nezabudnite poskytnúť spätnú väzbu! Nie je nič horšie, ako investovať čas a úsilie do niečoho bez toho, aby ste poznali výsledky. Povedzte nám, ako boli rady danej osoby užitočné vo vašej práci, inak je to jednostranná hra.

Referenčné podmienky pre rozvoj internetového obchodu

Referenčné podmienky pre vývoj mobilnej aplikácie

TK na stránke

ToR pre služby/aktualizácie

Ak potrebujete viac vzoriek, stačí si to vygoogliť.

Hlavným odporúčaním je urobiť to. Problém je v tom, že materská lenivosť prekoná každého a nie je ľahké jej odolať. Zhromaždite všetku svoju vôľu v päsť a začnite písať podmienky, len píšte a neprestávajte. Nebojte sa, že to nevyjde „dokonale“, prezradím tajomstvo, to sa nestane. Len píš, zakaždým to bude lepšie a lepšie.

Tak to má byť

Moje prvé základy písania technických špecifikácií sa začali objavovať pred niekoľkými rokmi. Pracoval som s dizajnérmi a stanovil som si za úlohu vytvárať kreatívy pre reklamné kampane. Nekoherentné chcieť a zmenilo sa to na kopu strateného času a vysvetľovania. Postupom času sa nastavenie úloh začalo meniť na akési sémantické bloky a potom na akési technické úlohy.

Napríklad pre úlohu „Tlačidlo Páči sa mi na stránke“:

1. Popis: Na našej webovej stránke musíte vytvoriť tlačidlo „Páči sa mi to“.
2. Účel a ciele: zapojenie používateľov, vydávanie / hodnotenie materiálov podľa počtu lajkov.
3. Požiadavky: takýto dizajn (príklad: odkaz na niečo podobné), funkčnosť (obrázok môže hodnotiť a páčiť sa mu každý používateľ, systém stránky zohľadňuje počet označení páči sa mi a mení výstup materiálov), technológia (dostupná na desktopové a mobilné verzie stránky).
4. Popis práce: nakresliť 3 rozloženia pre tlačidlá (dátum dokončenia: 10.01.17), vyvinúť systém na vydávanie materiálov podľa lajkov (dátum: 14.10.17), testovanie funkcií (dátum: 16.10.17) , vydanie (dátum: 17.10.17)
5. Prevzatie prác: používateľ klikne na tlačidlo páči sa mi, systém kliknutie započíta, dodávka materiálov sa zmení.
6. Aplikácie: skice, skice, príklady projektov, kde funguje podobná funkcia.

Nechajte si pre seba tie časti a časti štruktúry, ktoré sú potrebné pre vaše úlohy. Napríklad šiesty blok „Aplikácie“ možno opísať vo funkčných požiadavkách. Hlavná rada: tak či onak opíšte úlohu podľa štruktúry zadávacích podmienok. Aby ste to nezmeškali dôležité body a ušetrite sa od zbytočných otázok a zjednodušte život svojim kolegom.

Nech sa páči

Analyzovali sme, čo je to technická úloha a ako ju vykonať. Teraz máte možnosť jasne a jasne stanoviť ciele, komunikovať svoje myšlienky s ostatnými ľuďmi a ušetriť čas na ďalšie vysvetľovanie. Dúfam, že teraz viete, čo s tým všetkým robiť.