Technické špecifikácie na modernizáciu vetrania vo výskumnom ústave. Technické špecifikácie pre modernizáciu ventilácie vo výskumnom zariadení Technické špecifikácie pre úpravu servera úložiska

Prečo je potrebná technická špecifikácia?

Príklad technických špecifikácií pre programátora

Ak si prejdete zahraničné stránky s požiadavkou “dokument s požiadavkami na produkt”, nájdete kreatívne a presvedčivé články o tom, že technické špecifikácie (TOR, PRD) sú mŕtve. S tým musíme čiastočne súhlasiť – pri vývoji produktu od nuly vyzerá prototypovanie oveľa zaujímavejšie a efektívnejšie ako objemy poznámok zákazníkov, ktoré sú niekedy veľmi neprofesionálne. Ak sa však bavíme o finalizácii základného systému, tak veci naberú úplne iný smer. Stretávame sa s úpravami aj zákazkovým vývojom, takže technická špecifikácia je pes-eat-dog, ak nám šéfkuchár neklame. Vo všeobecnosti dnes hovoríme o tých klasických technických úlohách, ktoré sú napísané na dokončenie zakúpeného a nainštalovaného softvér. Skrátka o bolestivých veciach.

Aspekty interakcie

Zdroje- ľudia, stroje, zariadenia, vývojové prostredie, čas a peniaze, ktoré musia byť použité v procese implementácie požiadaviek. Zdroje vyžadujú jasné plánovanie a hodnotenie vo fáze schvaľovania technických špecifikácií. Správne stanovenie priorít na strane zákazníka a distribúcia pracovných zdrojov na strane predajcu umožňuje vyhnúť sa nedodržaniu termínov a minimalizovať ďalšie riziká.

možnosti- skrátka to je to, čo predajca (umelec) skutočne dokáže. Pozrime sa na príklad nášho RegionSoft CRM. Klient kúpi systém a vypracuje technickú špecifikáciu na úpravu: je potrebné vytvoriť integráciu s webovou stránkou a prepojiť udalosti v CRM na číslo objednávky internetového obchodu. Je to realistická požiadavka, máme na to zdroje a schopnosti. K CRM tiež potrebujete vyvinúť a pripojiť CMS, systém na správu obsahu webových stránok. Teoreticky to vieme urobiť, ale nemáme možnosť to urobiť lacno a klient nám nemá možnosť zaplatiť toľko, aby sme na danú úlohu vyčlenili ľudské a časové zdroje. Výsledkom je, že zákazník túto požiadavku odmietne - a v skutočnosti nepotrebuje CMS, všetko je v poriadku. Ale o „chamtivosti“ TK neskôr.

Obmedzenia- súbor prekážok, ktoré sťažujú alebo znemožňujú vykonávanie úloh z technických špecifikácií: rozpočet, technologický balík, problémy s licenciami, legislatívne zákazy, konfigurácie hardvéru atď.

Všetky štyri podstaty sú teda úzko prepojené a rozhodujú o úspechu projektu ako celku. Pozrime sa na každý prvok a pokúsme sa zdôrazniť kritické body, ktoré je potrebné mať na pamäti pri práci na technických špecifikáciách.

Zber a analýza požiadaviek

Nikto nepozná vašu spoločnosť lepšie ako vy a vaši zamestnanci. To znamená, že zhromažďovanie a analýza požiadaviek je výlučne vašou úlohou, pri ktorej vám môže predajca pomôcť a usmerniť, ale v žiadnom prípade nezasahovať do procesu. Opýtajte sa vývojára na takéto implementácie, zistite, čo hľadať a začnite. Mimochodom, dobrým asistentom môže byť váš zamestnanec, ktorý sa dobre orientuje v špecializovanej téme a má približnú predstavu o softvérovej architektúre a je oboznámený s procesom vývoja – môže pôsobiť ako analytik a interný expert, dohliadajúci na proces vytvárania technických špecifikácií a komunikácie s predajcom.

Existuje veľmi jednoduchý obvod požiadavky na zber.

1. Vytvorte pracovnú skupinu manažérov a skúsených špecialistov z oddelení, ktorí budú využívať CRM. Povedzte nám o riešení, ktoré si chcete vybrať, poskytnite prístup k demo verzii.
2. Členovia pracovnej skupiny by mali poskytovať informácie zamestnancom a žiadať ich o návrhy nový program v úplne voľnej forme. Ak sa niektorý zo zamestnancov s takýmto softvérom nikdy nestretol a nie je pripravený hovoriť o budúcom použití, musíte ho požiadať, aby opísal svoje pravidelné úlohy, je to univerzálny prístup.
3. Každé oddelenie potom identifikuje, čo CRM nemá alebo čo nemeria, a agreguje informácie.
4. Pracovná skupina analyzuje zozbierané požiadavky, kontroluje a odstraňuje križovatky. Napríklad obchodné oddelenie a marketingové oddelenie často objednávajú rovnakú zostavu, ale požiadavky môžu mať rôzne názvy polí a entít, hoci údaje za nimi sú rovnaké. Preto musíme dospieť k jednotnej forme.
5. Pracovná skupina vytvorí zoznam požiadaviek a stanoví priority. V tejto fáze môžete zapojiť predajcu, pretože je zodpovedný za zdroje. Môžete napríklad požiadať o vytvorenie vlastnej zostavy pre RegionSoft CRM alebo si môžete objednať integráciu so stránkou. Sú to úlohy s úplne inými termínmi, priorita je tu veľmi dôležitá.

Anatómia technickej špecifikácie

• Identifikácia – definovanie požiadaviek, hľadanie problémov, ktoré je potrebné riešiť.
• Analýza - analýza požiadaviek, identifikácia kľúčových potrieb, zovšeobecnenie.
• Adaptácia – posudzovanie požiadaviek v kontexte schopností CRM a existujúcich obchodných procesov.
• Dokumentácia – formálna a Detailný popis požiadavky, schvaľovanie technických špecifikácií.
• Komunikácia s predajcom (vývojárom) - iteratívna interakcia s predajcom ohľadom vylepšení v súlade so zostavenými technickými špecifikáciami.
• Implementácia je prácou predajcu na vytvorení potrebnej funkcionality. Je lepšie, ak je predajca neustále v kontakte so zákazníkom – takto bude finálny produkt čo najviac zodpovedať predstave klienta.
• Testovanie – kontrola funkčnosti zamestnancami predajcu, internými odborníkmi klienta a koncovými používateľmi s cieľom zistiť súlad s modifikáciou a technickými špecifikáciami a prevádzkyschopnosť systému so zmenami.

Obchodná úroveň- najglobálnejšia úroveň, na ktorej sa riešia zložité a prioritné úlohy. Táto úroveň zahŕňa integráciu, zlepšovanie a modelovanie obchodných procesov, vývoj nových funkčných modulov. Spravidla ide o vývoj náročný na zdroje, s vážnymi konzultáciami a uzavretím pracovať spolu so zákazníkom. Napríklad v RegionSoft CRM boli kedysi takýmito zákazkovými úpravami skladové účtovníctvo, pokladňa a výroba. Postupne boli zmeny zahrnuté do vydania a neskôr umožnili vytvorenie nového produktu pre veľkoobchody, maloobchody a hypermarkety - RegionSoft Retail.

Úroveň používateľa alebo skupiny používateľov. Na tejto úrovni sú implementované úlohy na spresnenie existujúceho rozhrania. Používateľ môže napríklad chcieť, aby sa pri umiestnení kurzora myši na zákazníka zobrazilo okno s číslom a stavom poslednej objednávky alebo vlastný prehľad so špeciálnym zoskupením údajov. Vylepšenia na tejto úrovni zaberú menej času, ale môže ich byť veľa – napríklad viaceré požiadavky z marketingu, logistiky a technická podpora.

Úroveň funkčnosti.Často je ťažké ho oddeliť od predchádzajúceho, funguje tu formálne kritérium - zlepšenie nie je na úrovni zobrazenia niečoho v rozhraní, ale na úrovni dokončenia logiky systému. To môže zahŕňať požiadavky na rôzne druhy triedenia, integrácie chatu a možností telefonovania.

Úroveň služieb- v skutočnosti by požiadavky tejto úrovne mali byť prvé zahrnuté v nových zostavách s opravami. Ide o úlohy súvisiace s rýchlosťou odozvy systému, prevádzkou pri vysokej záťaži a bezpečnosťou. IN ideálne Predajca by nemal mať takéto úpravy – firemný softvér by nemal spomaľovať, strácať dáta, skladať formuláre a distribuovať prístupové práva na rovnakej úrovni. Ak sa však objaví požiadavka, ktorá nesúvisí s osobnou paranojou zákazníka alebo problémami na strane hardvér, stojí za to venovať mu osobitnú pozornosť.

Technologická úroveň- posledný na zozname, ale pred ostatnými v dôležitosti a zložitosti. Môžu to byť požiadavky zákazníkov súvisiace s platformou, operačný systém alebo zariadenia. Napríklad žiadosť o zostavenie pre MacOS. Bude skvelé, ak sa takéto požiadavky postupne rozvinú do vydaní, ale je nevyhnutné mať pre ne opravy. Práve z požiadaviek zákazníkov na tejto úrovni sme vytvorili RegionSoft CRM pre MacOS a pridali vzdialený prístup pomocou technológie TRM ako dočasného riešenia zriedkavej, ale existujúcej požiadavky na mobilnú verziu.

Anatómia technickej špecifikácie je jednoduchá, aspoň vo forme kostry. Povinné časti technickej špecifikácie pomáhajú objednávateľovi zamerať sa na problém a správne formulovať zadanie a zhotoviteľovi porozumieť, čo od neho chcú. Mimochodom, o porozumení. Samozrejme, na začiatku príspevku sme trochu klamali a popriali obchodných konzultantov ako triedu. Ide o to, že každý predajca pôsobí na trhu niekoľko rokov (nehovoríme o jednodňových CRM) alebo dokonca desaťročia, čo znamená, že má súbor prípadov takmer v každom odvetví. V súlade s tým sú inžinieri, programátori a predajcovia oboznámení so špecifikami implementácie v každom type spoločnosti. Opäť je však dôležité zamerať sa konkrétne na váš biznis.

Pre koho? V tejto časti musíte popísať, kto bude konečným používateľom vylepšenia, aké úlohy sa plánujú riešiť a s akou frekvenciou.

Uvediem príklad. Jedna spoločnosť implementovala CRM a mala pracovať s pomerne veľkým množstvom údajov (niekoľko desiatok miliónov záznamov za mesiac, niekoľko stoviek tisíc záznamov za deň). Vedúci obchodného oddelenia si vyžiadal správu o nahrávaní týchto záznamov v „dennej“ frekvencii. Prirodzene, takáto správa so stovkami používateľov pracujúcich súčasne zaťažila systém – našli sa riešenia na optimalizáciu procesu. Už počas prác sa ukázalo, že predavač to hral na istotu a report potrebuje až na konci mesiaca a potom sa to v noci dalo spustiť podľa plánu. Netreba dodávať, že čas a peniaze boli zbytočné.

Prečo? Zdôvodnenie potreby zlepšenia a jeho miesto v obchodnom procese. Tento bod je potrebný skôr pre samotného zákazníka, ale je užitočné aj pre predajcu, aby vedel, aké ďalšie procesy budú ovplyvnené. Niekedy to pomôže nájsť alternatívne riešenie.

čo by to malo robiť? Najinformatívnejší blok - popisuje požiadavky a očakávania od systému. A tu sa dejú samé perly, zázraky a zrážky, ktoré je práve vhodné poslať do bashorga a ktoré, nuž, veľmi sťažujú život. Dôvod je len jeden – používateľ nevie, čo chce, čo treba urobiť. Je tu ešte jeden malý poddôvod – používateľ nemôže formulovať požiadavky. A tu je úlohou vývojára (pracovnej skupiny, analytika, ak nejaký existuje) pomôcť správne formulovať potrebu, vybrať vhodnú požiadavku a zapadnúť úlohu do kontextu fungovania systému. V tom istom bloku musíte uviesť očakávaný výsledok.

Parametre špecifikácie- termíny, fázy realizácie, zodpovednosť zo všetkých strán, potrebné kontakty a pod. V skutočnosti ide o súbor dôležitých formálnych vecí, ktoré z dokumentu robia technickú špecifikáciu. Podmienky musia byť dohodnuté a podpísané stranami, aby sa predišlo početným zmenám počas vývoja (stále sa budú diať, ale v menšom rozsahu).

V ideálnom prípade je technická špecifikácia vypracovaná za aktívnej účasti predajcu a jej výsledkom je približne nasledujúca štruktúra:

1. Opis požiadaviek každého mechanizmu a každej funkčnosti
2. Popis implementácie tejto funkcionality
3. Cena práce pre každú etapu zvlášť
4. Celkové náklady na prácu pre túto technickú špecifikáciu
5. Časové rámce na dokončenie práce rozdelené podľa etáp s uvedením priority
6. Popis podmienok inštalácie a testovania úprav
7. Výhrady týkajúce sa vyčerpávajúceho charakteru zadávacích podmienok a iných podmienok

10 pravidiel napísaných v slzách vývojára

Technická špecifikácia by nemala byť zištná. Podnik často preceňuje svoje schopnosti alebo chce získať „všetko naraz“. Tento prístup nie je opodstatnený ani z finančného, ​​ani z obchodného hľadiska. Predajca spravidla neexistuje niekoľko týždňov (v prípade RegionSoft - 15 rokov) a môžete ho kontaktovať po určitom čase, keď skutočne pochopíte, čo v CRM chýba.

Pozoruhodný príklad redundancie doslova zo včera: klient si kúpil ERP od jedného známeho ruská spoločnosť, mysliac si, ze kedze uctovnictvo funguje, tak ERP tohto dodavatela bude dobre. ERP sa ukázalo nielen ako nie veľmi dobré, ale aj ako veľmi nevhodné pre podnikanie. Ale RegionSoft CRM s skladové účtovníctvo a vhodné na výrobu. Existuje riešenie: zabudnite na ERP, plačte, integrujte účtovníctvo 1C s novým CRM a užívajte si pohodlnú implementáciu. Ale škoda tých vyhodených peňazí! A klient vyžaduje integráciu CRM s ERP. Neurobili sme to, ale prečo také plytvanie, prečo dva relatívne podobné systémy?

Referenčné podmienky musia byť realistické a dosiahnuteľné- z hľadiska požiadaviek aj termínov. Tu je dôležité počúvať názor predajcu, pretože presne vie, koľko času strávi na tejto alebo tej úlohe. Verte, že pre developera nie je výhodné strácať čas a zvyšovať termíny – je pre neho výhodné dokončiť čo najviac projektov a urobiť to dobre, aby neutrpel ranu na svojej povesti. Čo sa týka realizmu, je ľahké vyhnúť sa požiadavkám na inováciu CRM na úroveň systému riadenia collider: do požiadaviek by ste mali zahrnúť to, čo je skutočne potrebné pre tento moment a v dohľadnej dobe.

Napríklad RegionSoft CRM je desktopový program, nemáme klienta prehliadača. Žiadať od nás vytvorenie webovej aplikácie pre jednu spoločnosť je zbytočné, ide o veľký vývoj, momentálne prebieha a nejde o možný vývoj pre jednu spoločnosť. Nie, samozrejme, všetko má svoju cenu, ale opäť – vo všeobecnosti je požiadavka nesplniteľná.

Netreba si to zamieňať so situáciou, keď hovoríme o zákazkovom vývoji a radikálne sa mení myšlienka a logika aplikácie, v skutočnosti je sponzorovaná tvorba nového softvéru „pre seba“. Ale to je už iný príbeh.

Podmienky pôsobnosti musia byť podrobné. Je potrebné uviesť všetky dôležité detaily budúceho projektu: od frekvencie používania programu až po priania rozhrania. Čím podrobnejšie požiadavky budú, tým jednoduchšia a rýchlejšia bude implementácia a testovanie. Zvlášť stojí za to venovať pozornosť detailom, ak pracujete v konkrétnom odvetví (medicína, poisťovníctvo, banky) - podrobná prezentácia nuancií interakcie medzi obchodom a programom zabezpečí, že predajca porozumie úlohe a rýchlo prispôsobí systém tvoja spoločnosť.

Nezabudnite venovať pozornosť formátom čísel, názvom polí, prítomnosti alebo neprítomnosti rozbaľovacích zoznamov, správaniu tlačidiel a tipov a typom údajov. Ak zákazník používa vlastné vzorce, ktoré musia byť zahrnuté v logike fungovania CRM ( napríklad výpočet dealerských bonusov), tieto vzorce musia byť napísané s úplným vysvetlením ich označení a logiky výpočtu.

Technická špecifikácia musí byť jednoznačná a presná. Nejasné formulácie, možnosti implementácie, nejasné požiadavky – to všetko je cesta do slepej uličky. Stáva sa, že klient z dobrého úmyslu napíše do technickej špecifikácie niekoľko možností správania sa systému, blízkych, ale nie ekvivalentných. V tomto prípade si je istý, že pomáha, vyzýva programátora, ale v skutočnosti je cesta do pekla dláždená dobrými úmyslami, vývojár musí pochopiť, čo presne je potrebné, a sám si vyberie, ako to urobiť, na základe na charakteristike systému a zásobníka použitých technológií.

Technická špecifikácia musí byť napísaná v ľudskom jazyku. A to je dôležité, nie, DÔLEŽITÉ. Vyzdvihnem dve situácie, keď jazykové problémy vedú k oneskoreniam pri realizácii projektu.

1. Klient sa snaží demonštrovať svoju technickú gramotnosť a robí konštrukcie typu: „do tela kalendára implementovať okno s náznakom s možnosťou reagovať na udalosti vyvolania...“ namiesto „v kalendári by malo vyskočiť okno“ v ktorom môžete označiť úlohu ako dokončenú.“ Ak vy alebo váš interný odborník nemáte zručnosti na písanie odborných textov, negooglite – píšte obyčajnými slovami, my im rozumieme.

   Referenčné podmienky by nemali byť knihou sťažností. Problém treba riešiť, nie ho opisovať, venovať pozornosť písmu a zabudnúť na popis požiadaviek. Technická špecifikácia musí obsahovať nielen samotný problém, ale aj jeho riešenie na úrovni pochopenia – vývojár ho potom vyrieši na úrovni kódu. Porovnaj „Obchodné oddelenie neplánuje dobre, stráca čísla, už rok sa trápime“ A „je potrebné vytvoriť report, ktorý bude ukladať hodnoty plánovaného a skutočného predaja mesačne, rozdelené podľa skupín produktov“.

   Zadávacie podmienky musia byť schopné nahliadnuť do budúcnosti. Teda nie presne to, ale ľudia za tým. Ak je známe, že čoskoro nastanú zmeny v obchodných procesoch, treba to vziať do úvahy, aby sa za úpravy neplatilo dvakrát.

   Referenčné podmienky by nemali byť byrokratické. Ak ste niekedy zostavovali tento dokument, pravdepodobne ste cítili, aké ťažké je vyhnúť sa pokušeniu skĺznuť do byrokracie, pridať úvodné slová, strohé frázy a každý bod opísať ako článok Trestného zákona (najlepšie s trestom pre každého za porušenie ). Byrokratické formulácie maskujú neúplné pochopenie účelu tvorby technických špecifikácií. Zodpovednosť predajcu je špecifikovaná v zmluve a je tam napísaný aj rozpočet. Tieto body by ste nemali prenášať do technických špecifikácií.

   Referenčnými podmienkami musia byť technické špecifikácie. Znie to paradoxne, ale často namiesto technických špecifikácií čítame listy, sťažnosti, zmluvy, novo napísané pokyny k CRM či zápisnice z porady. Samozrejme, podľa takéhoto dokumentu sa nedá pracovať. Ak chcete zostať na vrchole formy a obsahu, použite trik zo starej školy: pozrite sa na výraz slovo po slove. Technický znamená, že diktuje modifikáciu, technológiu a je zameraný na riešenie problému zmenou softvéru. To je to, o čom musíme hovoriť v kontexte softvéru. Zadanie znamená položiť otázku, problém bez rady, tipov alebo predbežného hodnotenia. Len konstatovanie problému.

   Prikázania skončili, teraz pokarhanie

   Okrem vymenovaných pravidiel stojí za reč ešte niekoľko vecí. Hovoríme o cieľoch, plánoch a očakávaniach – všetkých tých prvkoch, ktoré robia projekt úspešným a vzťah medzi predajcom a klientom je takmer priateľský.

   Technické špecifikácie je potrebné napísať rýchlo, aj keď stojíte pred úlohou automatizovať procesy mobilného operátora alebo veľký hypermarket. Dôvodom je skutočnosť, že technológie sa vyvíjajú obrovskou rýchlosťou a dokonca aj systém, ktorý implementujete, môže prežiť veľké vydanie (alebo niekedy aj dve) za šesť mesiacov alebo rok a získať nové funkcie. Možno budete musieť prehodnotiť potrebu úprav a začať proces odznova.

   

   
   Nakoniec si našiel čas na dokončenie technickej úlohy. Žiaľ, už tu nie sú žiadni vývojári, ktorí by to implementovali.

   Klient si nie je vedomý zásobníka a technických obmedzení. A nemal by vedieť - to je úloha predajcu, je to on, kto hodnotí prácu po vypracovaní technických špecifikácií. Zákazník by sa nemal vŕtať v technológiách a pri každej čiarke sa pýtať, či predajca dokáže to či ono. Vypracujte komplexnú technickú špecifikáciu a developer vyberie vhodnú architektúru – často dokonca lepšiu, ako by ste si mysleli.

   Zhodnoťte svoj rozpočet a vyhnite sa nepríjemným prekvapeniam- takmer spoločná úloha číslo jeden. Nemali by ste na predajcu tlačiť a požadovať od neho približné posúdenie práce (dobre, aspoň približne, z ruky, od oka, ale ako u iných, dobre, v projektoch tohto typu, ale zo skúseností, dobre, v rámci tolerancia chyby). Úplné posúdenie rozpočtu je možné až po prečítaní, analýze a konečnom schválení zadávacích podmienok. Ak váš vývojár koná inak, pripravte sa na to, že revízia bude stáť minimálne dvakrát toľko.

   Na základe objektívnej potreby zmien a rozšírení- Vyššie som napísal, že vývojár nezaniká a je pripravený kedykoľvek vykonať zmeny a doplnky podľa vašich požiadaviek. Nesnažte sa preto hneď vytvárať CRM/ERP svojich snov, nevyžadujte od predajcu tlačidlo „Všetko funguje, kým pijem kávu“ – pracujte v systéme, identifikujte pre vás kritické pripomienky a začnite zbierať požiadavky a kresliť do technických špecifikácií.

   O technických úlohách môžete písať donekonečna, toto je skutočný generátor nielen mémov a rozprávok, ale aj bolestí hlavy. Môžete hovoriť o prioritách a pravidlách dizajnu, o GOST 1989, ktorý robí technické špecifikácie nehumánnymi, o štandardoch IEEE, ktoré sú o niečo lepšie, o prototypoch a technických špecifikáciách, ktoré ich dopĺňajú. Na záver by som sa však rád obmedzil na jedno, najdôležitejšie pravidlo: technická špecifikácia nie je právnym štátom, nie GOST a nie dogmou, preto, ak ju môžete zlepšiť, vylepšite ju, ak ju môžete zjednodušiť. to, zjednodušte si to, ak to viete robiť s gráciou a tak, aby sa to všetkým páčilo, urobte to. Som si istý, že potom už nikto nebude strkať nos nad technickými špecifikáciami a nepovie, že to tam nie je napísané. Alebo takmer nikto.

   Počas celého decembra poskytujeme zľavy na RegionSoft CRM a všetok náš vlastný softvér. Od 1. decembra do 15. decembra - 15 % a strmé podmienky na splátky a prenájmy. Nemáme -70 % a -90 %, pretože ceny za licencie držíme ekonomicky opodstatnené a neberieme ich z ničoho nič.

   Ak potrebujete systém CRM (s úpravou alebo bez nej), prejdite na stránku našej webovej stránke, je toho veľa o CRM, jeho výhodách a inom firemnom softvéri.

   A áno, vždy hľadáme partnerov, ktorí sú pripravení predávať CRM a ďalšie produkty, upravovať a predávať CRM, predávať softvér a školiť používateľov. Rozdelenie príjmov je spravodlivé a pre partnera výhodné. Ukážeme vám, povieme, naučíme vás. Písať [e-mail chránený]

   Šmykľavky, šmýkačky. Komiksy prevzaté z http://www.modernanalyst.com/ a Pinterestu. Ak existuje lepší preklad, radi ho zaradíme do príspevku.

Často prikladám prototypy stránok, aby klient pochopil, ako bude jeho stránka vyzerať. Potom vypracujem samostatnú úlohu pre dizajnéra rozloženia - s technickými detailmi a vysvetleniami, ktoré mu pomôžu pri práci.

Čím je úloha zložitejšia, tým podrobnejšia by mala byť technická špecifikácia. Keď som sa podieľal na veľkých projektoch, videl som zadávacie podmienky, ktoré mali 30 strán.

Guram Sipki, zakladateľ digitálneho štúdia Udix Media

Klient potrebuje v prvom rade technické špecifikácie – aby rozumel, aká bude jeho web stránka a na čo sa budú míňať peniaze. Ak sa niečo urobí zle, môže sa obrátiť na technické špecifikácie a požiadať o prepracovanie.

Technickú špecifikáciu vypracuje projektový manažér po komunikácii s klientom a prerokovaní úlohy s projektantom.

Veľkí zákazníci často žiadajú veľmi podrobné technické špecifikácie, ktoré popisujú každé tlačidlo. Malé firmy, naopak, nemajú rady pedantné 100-stranové dokumenty.

Príklad technickej úlohy na zlepšenie webovej stránky

Všeobecné informácie

Názov automatizovaného systému

"AS Sbyt"

Zákazník

Exekútor

Základ pre prácu

Plánované termíny začiatku a konca prác na vytvorení systému

Začiatok prác: 01.09.2010

Ukončenie prác: 31.12.2010

Účel a ciele vytvorenia systému

Účel systému

Vo vývoji automatizovaný systém navrhnuté tak, aby automatizovali procesy podnikového predaja..

Ciele tvorby systému

Ciele vytvorenia automatizovaného systému

Ciele rozvoja "AS Sbyt" sú:

1. 3. Charakteristika objektu automatizácie

3.1 Podnikové obchodné procesy

3.1. 1 Obchodný proces „Uzatvorenie zmluvy“

Stane sa vaším štítom, v tomto dokumente, ak sa niečo stane, budete môcť ukázať prstom na bezohľadného vývojára a požadovať, aby bol váš web uvedený do súladu s ním.

Technická úloha(v skratke „TOR“) je dokument, ktorý čo najpodrobnejšie a najjednoznačnejšie odráža požiadavky na váš budúci web.

Stránka je vytvorená presne na základe technických špecifikácií. Čím je podrobnejší a jednoznačnejší, tým viac bude vaša nová stránka spĺňať vaše očakávania.

Zadávacie podmienky pre tvorbu webovej stránky – ako zákon, by nemali umožňovať výklady a nezrovnalosti.

Vývojár robí všetko, čo nie je uvedené v technických špecifikáciách, podľa vlastného uváženia.

· Príručka správcu;

· Príručka správcu obsahu;

· Návod na inštaláciu;

· Príručka programátora.

2.20. Organizovanie a vedenie školenia pre špecialistov vyšetrovacieho výboru pri prokuratúre Ruskej federácie

Platia nasledujúce požiadavky na školenie:

· Dodávateľ musí vykonať školenie zamestnancov vyšetrovacieho výboru na prokuratúre Ruská federácia pozostáva z najviac 10 osôb.

· Školenie musí prebiehať v ruštine.

· Školiace priestory zabezpečuje objednávateľ.

· Miesto a čas školenia je potrebné dohodnúť so Zákazníkom.

Školenie musí byť vykonané na všetky funkcie systému.

V rámci školenia je potrebné zrealizovať informačný obsah jednej pilotnej stránky Ring of Sites vyšetrovacieho výboru pod prokuratúrou Ruskej federácie.

3.

Vzorové technické špecifikácie na zlepšenie webových stránok

Dôležité

Počas procesu implementácie musí Dodávateľ poskytnúť Zákazníkovi súčinnosť v rámci Harmonogramu implementácie.

6.1.11. V prípade zlej prípravy personálu objednávateľa na implementáciu a potreby ďalšej asistencie zo strany dodávateľa pre úspešnú implementáciu softvéru je potrebné spísať dodatočný protokol o dohodnutí zmluvných cien za poskytovanie informačných a poradenských prác.

6.2 Postup ďalšej podpory úloh AS „PRODEJ“.

TOR musí uvádzať zložitosť a cenu práce na implementáciu dodatočných požiadaviek.

6.2.2. Dodávateľ sa zaväzuje udržiavať telefonickú horúcu linku pre softvérovú podporu.

Fazety interakcie Skôr ako začneme rozoberať proces tvorby technickej špecifikácie, povedzme si niečo o štvoruholníku, do ktorého sa ocitajú zhotoviteľ a objednávateľ pri spustení projektu. Požiadavky- požadované správanie systému opísané zákazníkom alebo držiteľom procesu, ktoré sa má implementovať. Požiadavky sa spravidla vytvárajú na základe pracovných skúseností a pochopenia správneho správania programu.

Pre vývojára (vendora) ide o kľúčovú informáciu, avšak práve v štádiu zbierania požiadaviek vzniká najväčší počet kolízií, chýb, zbytočných požiadaviek a pod.

Zdroje- ľudia, stroje, zariadenia, vývojové prostredie, čas a peniaze, ktoré musia byť použité v procese implementácie požiadaviek. Zdroje vyžadujú jasné plánovanie a hodnotenie vo fáze schvaľovania technických špecifikácií.

To môže zahŕňať požiadavky na rôzne druhy triedenia, integrácie chatu a možností telefonovania.

Úroveň služieb- v skutočnosti by požiadavky tejto úrovne mali byť prvé zahrnuté v nových zostavách s opravami. Ide o úlohy súvisiace s rýchlosťou odozvy systému, prevádzkou pri vysokej záťaži a bezpečnosťou.

Pozornosť

V ideálnom prípade by predajca nemal mať takéto úpravy – firemný softvér by nemal spomaľovať, nestratiť dáta, nezbaliť formuláre a distribuovať prístupové práva na rovnakej úrovni. Ak sa však objaví požiadavka a nesúvisí s osobnou paranojou zákazníka alebo problémami na strane hardvéru, oplatí sa jej venovať zvýšenú pozornosť.

Technologická úroveň- posledný na zozname, ale pred ostatnými v dôležitosti a zložitosti.

Microsoft World alebo Microsoft Excel.

Osobne pri vývoji vstupnej stránky používame špeciálne softvérové ​​produkty.

S ich pomocou môžete rýchlo a jednoducho vytvárať projekty aj pre zložité stránky - napríklad Balsamiq. Ako však robíme celý prototyp sme už popísali v článku.

Na tému: Prototypovanie webových stránok: tvorba, nástroje a programy.

Predprojektový dizajn môže byť urobený spoločne s developerom alebo úplne prenesený na jeho plecia.
Hlavná vec, nezabudnite, potom je to dohodnuté a podpísané oboma stranami.

ŽIVOTNÉ HACKY PRE Drafting TOR

Tieto body platia rovnako pre vypĺňanie briefu, ako aj pre vypracovanie technických špecifikácií.

A v nich vám poviem malé triky, ako zostaviť technické špecifikácie pre webovú stránku a uľahčiť už aj tak ťažký život podnikateľa:

1.

Uistite sa, že klient a interpret si správne rozumejú.“

Zadávacie podmienky by nemali obsahovať kvalitné prívlastky: krásny, spoľahlivý, moderný. Nedajú sa jasne pochopiť. Každý má svoje vlastné predstavy o kráse a modernosti.

Pozri. Niekto si myslel, že tento dizajn je krásny a dovolil ho použiť na svojej webovej stránke:

To isté sa deje s vágnymi formuláciami, ktoré samy osebe nič neznamenajú:

• Zákazníkovi sa musí stránka páčiť.Čo ak má zlú náladu?
• Stránka by mala byť pohodlná.Čo to znamená? Na čo pohodlné?
• Miesto musí vydržať veľké zaťaženie. 10 tisíc návštevníkov? Alebo 10 miliónov?
• Vysoko kvalitný odborný obsah. Dobre, chápete.

Skontrolujte, či v texte nie sú nejasnosti. Ak existuje, prepíšte ho.

Rozhodli ste sa objednať si webovú stránku (aka vstupnú stránku)? Ako ukazuje prax, nie je to také jednoduché. Stovky zákazníkov, ktorí videli ich hotovú webovú stránku, zistia, že im nevyhovuje: dizajn je chybný, rozloženie je chabé, texty sú nesprávne, pribudlo veľa nepotrebných funkcií.

Aby ste sa vyhli takýmto následkom, potrebujete technické špecifikácie pre vývoj webových stránok.

POTREBUJEM TO?!

Nezáleží na tom, kto bude stránku prevádzkovať – vy sami, váš príbuzný, nezávislí pracovníci za mierny plat, špecializovaná spoločnosť za obrovské množstvo peňazí...

Pre stránku musia existovať technické špecifikácie.

Môžete napríklad požiadať o vytvorenie vlastnej zostavy pre RegionSoft CRM alebo si môžete objednať integráciu so stránkou. Ide o úlohy s úplne odlišnými termínmi, priorita je tu veľmi dôležitá.Po zozbieraní, analýze a odsúhlasení požiadaviek so zamestnancami a manažmentom môžete začať vytvárať technickú špecifikáciu.
Formulár môžete požiadať predajcu alebo si ho vytvoriť sami – v každom prípade existuje niekoľko pevných pravidiel, ktorých dodržiavanie vám a vášmu dodávateľovi CRM ušetrí bolesti hlavy.

Anatómia technickej špecifikácie

Ak hovoríme o procese tvorby technickej špecifikácie, existuje niekoľko etáp. Ich postupný prechod vedie zákazníka k želanému zlepšeniu.
Tu sú.

Tu je dôležité počúvať názor predajcu, pretože presne vie, koľko času strávi na tejto alebo tej úlohe. Verte, že pre developera nie je výhodné strácať čas a zvyšovať termíny – je pre neho výhodné dokončiť čo najviac projektov a urobiť to dobre, aby neutrpel ranu na svojej povesti.

Čo sa týka realizmu, vyhýbať sa požiadavkám na upgrade CRM na úroveň systému riadenia zrážačov je jednoduché: do požiadaviek by ste mali zahrnúť to, čo je skutočne potrebné v súčasnosti a v dohľadnej budúcnosti.

Napríklad RegionSoft CRM je desktopový program, nemáme klienta prehliadača. Žiadať od nás vytvorenie webovej aplikácie pre jednu spoločnosť je zbytočné, ide o veľký vývoj, momentálne prebieha a nejde o možný vývoj pre jednu spoločnosť.

Úplné a krátke názvy informačného systému

Celý názov systému je oficiálna webová stránka Vyšetrovacieho výboru pod prokuratúrou Ruskej federácie.

Skrátený názov systému je „SKP Site“, „System“, „Site“.

1.2. Meno zákazníka systému a jeho údaje

Názov: Vyšetrovací výbor pri prokuratúre Ruskej federácie

miesto:

Info

Moskva, ulica Tekhnicheskiy, budova 2

Skutočná adresa: A

Kontaktná osoba zákazníka:

Telefón: (4, (4;

Emailová adresa

1.3. Zoznam dokumentov, na základe ktorých je Systém vytvorený

Štátna zmluva č. _________________ zo dňa ___ ___________ 2010

1.4.

Určené v súlade s Dohodou.

2. Systémové požiadavky

2.1.

dátum platby

Číslo platby

Číslo platby v platobnom systéme

Výška platby

1. Vyberte riadky súboru prenosu údajov
2. Začnite prechádzať riadkami súboru prenosu údajov
3. Prečítajte si riadok súboru prenosu údajov
4. Získajte kód zmluvy z riadku súboru prenosu údajov
5. Nájdite zodpovedajúci prvok podľa kódu v adresári „Zmluvy protistrany“; ak sa prvok nenájde, zobrazte správu „Zhoda s kódom nebola nájdená...“
6. Ak sa prvok nájde, pridajte do tabuľky hodnôt riadok, kde: „Dohoda“ - nájdený prvok, „Dátum“ - „Data_plat“, „Číslo platby“ - „Nomer_plat“, „Suma“ - „Summa_plat“
7. Po prijatí posledného riadku súboru prenosu údajov ukončite cyklus
8. Pre každý riadok hodnotovej tabuľky vytvorte doklad „Platobný príkaz na príjem prostriedkov“.

Pri vypĺňaní briefu alebo pri zostavovaní zadávacích podmienok pre dizajn webovej stránky v nich nenechávajte žiadne medzery.

Musíte pochopiť, že „Podľa uváženia vývojára“ znamená „Robím, čo chcem“ alebo „Všetko, čo nie je špecifikované, robí podľa uváženia interpreta“. A verte, že to nie je len diera, ale celé okno do Európy pre developera.

A, samozrejme, nie vždy sa to stane.

Ak narazíte na kompetentného odborníka, nemusíte sa obávať výsledku.

Ale tu vzniká ďalší problém: v skutočnosti to môže urobiť správne, ale nebude sa vám to páčiť čisto subjektívne. A všetko bude ako vo vtipe, ktorý mnohí vývojári poznajú:

STRUČNE O HLAVNÝCH VECIACH

Rozhodne neoľutujete čas strávený prípravou a odsúhlasením podmienok tvorby webovej stránky alebo vstupnej stránky.

Koniec koncov, je to váš najlepší nástroj na monitorovanie a riešenie nezhôd, ktoré v procese vzniknú.

Keď kliknete na konkrétny okres, mal by prejsť na stránku s textovým popisom tohto okresu.

· Blok „Blog predsedu“- mal by byť zoznam troch najnovších vytvorených tém na blogu v podobe názvu témy a dátumu jej zverejnenia. Názov témy bude odkaz, na ktorý by ste sa po kliknutí mali dostať na stránku blogu s popisom tejto témy. Tento blok by mal obsahovať aj video, ktoré sa dá prehrať bez opustenia domovskej stránke. Video musí mať odkaz "Komentáre", ktorý predstavuje počet komentárov k danému obrázku videa. Odkaz „Komentáre“ by mal viesť na stránku blogu s komentármi k odoslanému videu.

Päta by mala obsahovať vyhľadávacie pole, informácie o autorských právach atď.

2.3.

Stručný je dotazník s otázkami o obsahu, dizajne, technické možnosti Váš budúci web.

Zadanie môže samozrejme nahradiť podrobný brief podpísaný oboma stranami.

Koniec koncov, je to prakticky to isté, len s tým rozdielom, že brief je vaša vízia a technická špecifikácia je konečný dokument založený na vašom briefe a samotných komentároch vývojára.

Ak niektoré body spôsobujú ťažkosti, potom neváhajte a položte vývojárovi otázky ako „Čo to znamená?“, „Ako to ovplyvní fungovanie mojej stránky?“, pretože nie všetci vývojári chápu to isté ako vy.

Buď v stĺpci „ Ďalšie informácie„Uistite sa, že uvediete všetky svoje želania, ktoré neboli zahrnuté v odpovediach na otázky.

Ak tento stĺpec chýba, jednoducho ich pridajte na koniec briefu.

VK, Google, Facebook.

3.2.2 V osobný účet v sekcii objednávky pridajte pole na pridanie promo kódu.

3.2.3 Namiesto stránky, ktorú používateľ dostane po požiadavke na obnovenie hesla (napríklad name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), vytvorte stránku (napríklad name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), ktorý zobrazí obsah stránky, bude mať pole „E-mail pri registrácii“, kontrolný riadok, nové heslo, potvrdenie hesla a tlačidlo odoslania údajov.

3.2.4 Pri pridávaní položiek do košíka by sa mala zobraziť správa, že položka bola pridaná do košíka.

3.2.5 Pridať výstup správy oznamujúci, že heslo nezodpovedá bezpečnostným parametrom pri registrácii nového používateľa.

"_" _______________ 2010

Postupne boli zmeny zahrnuté do vydania a neskôr umožnili vytvorenie nového produktu pre veľkoobchody, maloobchody a hypermarkety - RegionSoft Retail.

Úroveň používateľa alebo skupiny používateľov. Na tejto úrovni sú implementované úlohy na spresnenie existujúceho rozhrania. Používateľ môže napríklad chcieť, aby sa pri umiestnení kurzora myši na zákazníka zobrazilo okno s číslom a stavom poslednej objednávky alebo vlastný prehľad so špeciálnym zoskupením údajov.

Prepracovanie na tejto úrovni trvá kratšie, no môže ich byť veľa – napríklad viaceré požiadavky z oddelení marketingu, logistiky a technickej podpory.

Úroveň funkčnosti.Často je ťažké ho oddeliť od predchádzajúceho, funguje tu formálne kritérium - zlepšenie nie je na úrovni zobrazenia niečoho v rozhraní, ale na úrovni dokončenia logiky systému.

Ak je napísané kaša, možno by ste mali utiecť a neobzerať sa späť.

• Poistite sa proti nepoctivosti interpreta. Keď je stránka pripravená, je možné ju skontrolovať podľa technických špecifikácií. Existujú nejaké nezrovnalosti? Developer je povinný ich opraviť. Ak spolupracujete oficiálne a uzavreli ste dohodu, môžete si ju vynútiť aj súdnou cestou.
• Zjednodušte výmenu účinkujúcich. Ak sa klient a vývojár pohádali a utiekli, vytvorenie stránky môže zabrať veľa času. Keď bude podrobná technická špecifikácia, môže sa preniesť na nový tím – zapojí sa do práce mnohonásobne rýchlejšie.
• Zistite náklady na vývoj zložitého produktu. Nie je možné okamžite odhadnúť presné načasovanie a náklady na vývoj komplexnej webovej služby. Najprv musíte pochopiť, ako bude služba fungovať a aké funkcie bude mať.

K dispozícii je root prístup, vaše vlastné IP adresy, porty, pravidlá filtrovania a smerovacie tabuľky.

Google PageSpeed ​​​​Insights je bezplatná služba odporúčania pre webové stránky na zrýchlenie zobrazovania stránok v prehliadači používateľa (https://developers.google.com/speed/pagespeed/insights/).

Optimalizácia pre vyhľadávače (alebo SEO) je súbor opatrení pre internú a externú optimalizáciu na zvýšenie pozície stránky vo výsledkoch vyhľadávača pre špecifické požiadavky používateľov.

Optimalizácia externej webovej stránky je registrácia webovej stránky v vyhľadávače, propagácia v v sociálnych sieťach, budovanie odkazov prilákaním odkazov z iných zdrojov na propagovanú stránku, bannerová reklama, kontextová reklama.

Interná optimalizácia stránok je optimalizácia textu, URL adries, úprava štruktúry stránok, linkovanie, kontrola odoziev servera.

Dostupné materiály Odkazy na vaše obľúbené stránky, ako aj brožúry, časopisy, fotografie – čokoľvek, alebo možno máte hotovú knihu značiek. Priložené ako samostatný archív. Minimálne rozlíšenie a zobrazovacie zariadenia V tomto odseku uveďte, z akých zariadení chcete stránku prezerať – PC, notebooky, smartfóny... PC monitory od 19 do 27 palcov; Notebooky od 15,6 do 17,3 palcov; Smartfóny od 3,5 do 6 palcov; Potrebujem tablety od 7 do 12 palcov? mobilná verzia? Áno FUNKČNÉ POŽIADAVKY Približná sada modulov (pre používateľov) Táto sekcia by mala obsahovať všetky funkčnosť, ktoré chcete vidieť na stránke.

Môže to byť nákupný košík, katalógové filtre založené na rôznych parametroch, možnosť zadať online objednávku, zanechať požiadavku na spätný hovor, prihlásenie na odber noviniek a ďalšie možnosti Katalógové filtre podľa ceny, abecedne, podľa výrobcu.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EХHJя(gTT┬Pb╟▌╤└u╟╛#╜┘al+Ka Kqik╔╴#┘al+Ka Kqík ┐█ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘u╛╜┘ual+KaXZG▕ ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛b#╟X╟╛b#╟XGzh╛b#╟XGzh╛b+Ka ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG╜┘al+KaXG╕Xu▀ ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NлkZ ⌡ ⌡ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх╡OьТ┬├6 ∙rrм VC╪ ┬ 7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀J+E2 ©2 OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Pamätáte si Murphyho zákony? Ak môžete byť nepochopení, určite budete nepochopení. Platí to nielen v komunikácii medzi ľuďmi, ale aj pri tvorbe webových stránok. Klient chcel druhý Facebook, ale dostal fórum pre mladých chovateľov psov. Developer neuhádol, čo zákazník chce – strácal čas.

V tejto príručke vám poviem, čo a prečo musíte napísať do podmienok. Zároveň vám ukážem, ako nepísať, aby sa tvorba technických špecifikácií nestala strateným časom.

Článok bude užitočný:

• Pre všetkých, ktorí sa podieľajú na tvorbe webových stránok: vývojári, dizajnéri, dizajnéri rozloženia.
• Projektoví manažéri.
• Vedúci digitálnych štúdií.
• Podnikatelia, ktorí si plánujú objednať vývoj webových stránok.

Aby bol materiál užitočný, zozbieral som pripomienky od viacerých vývojárov, dizajnérov, projektových manažérov a majiteľov digitálnych štúdií. Tie najcennejšie som pridal na koniec článku. Poďme to zistiť.

Čo je to technická špecifikácia a prečo je potrebná?

Technická špecifikácia je dokument, ktorý stanovuje požiadavky na lokalitu. Čím sú tieto požiadavky jasnejšie a podrobnejšie, tým lepšie všetci účastníci procesu chápu, ako by to malo byť. To znamená, že šanca, že budú s výsledkom spokojní všetci.

Hlavným cieľom technickej špecifikácie je zabezpečiť, aby si objednávateľ a zhotoviteľ správne rozumeli.

Technické špecifikácie prinášajú mnohé výhody. Pre každú stranu je to iné.

Výhody pre klienta:

• Pochopte, za čo platí peniaze a aká bude stránka. Môžete okamžite vidieť štruktúru, pochopiť, čo bude fungovať a ako. Zistite, či vám všetko vyhovuje. Ak nie, nie je problém to pred začatím vývoja zmeniť.
• Pozrite si kompetenciu interpreta. Ak sú zadávacie podmienky jasné a presné, dôvera v developera sa zvyšuje. Ak je napísané kaša, možno by ste mali utiecť a neobzerať sa späť.
• Poistite sa proti nepoctivosti interpreta. Keď je stránka pripravená, je možné ju skontrolovať podľa technických špecifikácií. Existujú nejaké nezrovnalosti? Developer je povinný ich opraviť. Ak spolupracujete oficiálne a uzavreli ste dohodu, môžete si ju vynútiť aj súdnou cestou.
• Zjednodušte výmenu účinkujúcich. Ak sa klient a vývojár pohádali a utiekli, vytvorenie stránky môže zabrať veľa času. Keď bude podrobná technická špecifikácia, môže sa preniesť na nový tím – zapojí sa do práce mnohonásobne rýchlejšie.
• Zistite náklady na vývoj zložitého produktu. Nie je možné okamžite odhadnúť presné načasovanie a náklady na vývoj komplexnej webovej služby. Najprv musíte pochopiť, ako bude služba fungovať a aké funkcie bude mať. Na to musíte pripraviť technické špecifikácie.

Prínos pre účinkujúceho:

• Pochopte, čo zákazník chce. Klient dostane desiatky otázok, ukáže príklady a ponúkne riešenia. Potom všetko zapíšu do jedného dokumentu a dohodnú sa. Ak je všetko v poriadku - hurá, pochopili ste správne.
• Poistite sa proti náhlym želaniam klienta. Niekedy narazíte na zákazníkov, ktorí chcú v polovici zmeniť úlohu. Ak ste súhlasili a podpísali zadávacie podmienky, tohto sa nebojíte. Ak sa niečo stane, aj súd bude na vašej strane.
• Ukážte svoju kompetenciu. Dobre pripravená technická špecifikácia ukáže klientovi odbornosť vývojárov. Ak spoločnosť pochybuje, či vám má dôverovať pri vývoji webových stránok, pochybnosti sa s najväčšou pravdepodobnosťou rozptýlia.
• Zarobiť peniaze. Niektoré štúdiá a vývojári ponúkajú prípravu technických špecifikácií ako samostatnú službu.

• Uľahčiť a urýchliť proces vývoja. Dobrá technická špecifikácia naznačuje štruktúru webu, potrebné funkcie a prvky na každej stránke. Keď už máte všetky požiadavky pred očami, ostáva už len navrhnúť a napísať kód.

Teraz poďme zistiť, ako vytvoriť dobrú technickú špecifikáciu, ktorá vykonáva všetky tieto funkcie.

Referenčné podmienky zostavuje výkonný umelec

Vo všeobecnosti môže ktokoľvek vypracovať technické špecifikácie. „Potrebujeme webovú stránku s vizitkou pre zubnú kliniku“ – toto je už technická úloha. Bude však plniť svoje funkcie? Sotva.

Dobrú technickú špecifikáciu vždy pripraví realizátor: projektový manažér alebo developer. Je zrejmé, že webový vývojár rozumie vytváraniu webových stránok viac ako majiteľ kaviarne alebo zubnej ambulancie. Preto bude musieť projekt opísať.

To neznamená, že klient zmizne a objaví sa na samom konci a napíše: „Zbs, súhlasím“. Mal by sa tiež zúčastniť procesu:

Zákazník si samozrejme môže načrtnúť vlastnú verziu technických špecifikácií. Snáď to urýchli proces tvorby finálnych technických špecifikácií. Alebo možno výsledkom bude odpad, ktorý bude tajne vyhodený do koša.

Píšte jasne a presne

Táto rada vyplýva z hlavného cieľa zadávacích podmienok – „Uistite sa, že si klient a dodávateľ správne rozumejú.“

Zadávacie podmienky by nemali obsahovať kvalitné prívlastky: krásny, spoľahlivý, moderný. Nedajú sa jasne pochopiť. Každý má svoje vlastné predstavy o kráse a modernosti.

Pozri. Niekto si myslel, že tento dizajn je krásny a dovolil ho použiť na svojej webovej stránke:

To isté sa deje s vágnymi formuláciami, ktoré samy osebe nič neznamenajú:

• Zákazníkovi sa musí stránka páčiť.Čo ak má zlú náladu?
• Stránka by mala byť pohodlná.Čo to znamená? Na čo pohodlné?
• Miesto musí vydržať veľké zaťaženie. 10 tisíc návštevníkov? Alebo 10 miliónov?
• Vysoko kvalitný odborný obsah. Dobre, chápete.

Skontrolujte, či v texte nie sú nejasnosti. Ak existuje, prepíšte ho. Vaša formulácia by mala byť jasná a presná:

• Stránka sa musí načítať rýchlo → Každá stránka na webe musí mať viac ako 80 bodov v Google PageSpeed ​​​​Insights.
• Veľké zaťaženie → 50 tisíc návštevníkov súčasne.
• Na hlavnej stránke sa zobrazí zoznam článkov → Hlavná stránka zobrazuje zoznam posledných 6 publikovaných článkov.
• Minimalistické užívateľsky prívetivé rozhranie predplatného → pole „Zanechajte svoj e-mail“ a tlačidlo „Prihlásiť sa“ → *nakreslený náčrt*.

Vytriedili sme formuláciu, poďme na štruktúru.

Uveďte prosím všeobecné informácie

Všetci členovia tímu musia správne pochopiť, čo spoločnosť robí a kto je jej cieľová skupina. Aby sa nikto nezmýlil, je lepšie to napísať na úplný začiatok zadávacích podmienok.

Tiež stojí za to uviesť účel stránky a v skratke opísať jej funkčnosť – aby ste neskončili s internetovým obchodom namiesto blogu.

Vysvetlite ťažké pojmy

Prvým pravidlom zadania je, že musí byť zrozumiteľný pre každého, komu je určený. Ak budete používať pojmy, ktorým váš klient, majiteľ detského hračkárstva, nemusí rozumieť, určite mu ich vysvetlite. V jasnom jazyku, nie copy-paste z Wikipédie.

Popíšte nástroje a požiadavky na hosting

Predstavte si, že ste strávili 2 mesiace tvorbou skvelej webovej stránky. Každá fáza bola koordinovaná s klientom - bol nadšený. A teraz je čas odovzdať prácu. Ukážete admin panel a klient zakričí: „Čo je toto? Modex?! Myslel som, že to urobíš na WordPress!“

Aby ste sa vyhli takýmto problémom, popíšte použité nástroje, motory a knižnice. Zároveň uveďte svoje požiadavky na hosting. Nikdy neviete, urobíte to v PHP - a klient má server v .NET.

Uveďte požiadavky na prevádzku stránky

Stránka musí fungovať vo všetkých súčasných prehliadačoch a na všetkých typoch zariadení. Áno, je to zrejmé každému vývojárovi a každému zákazníkovi. Je však lepšie písať, aby ste klienta ochránili pred prácou vykonanou v zlej viere.

Napíšte sem požiadavky na rýchlosť načítania stránok, odolnosť voči zaťaženiu, ochranu pred útokmi hackerov a podobné veci.

Zadajte štruktúru lokality

Skôr ako začnete kresliť dizajn a rozloženie, musíte sa s klientom dohodnúť na štruktúre stránky.

Porozprávajte sa so zákazníkom a zistite, čo potrebuje. Zhromaždite vývojárov, SEO špecialistov, marketérov, šéfredaktorov – a rozhodnite sa, aké stránky sú na webe potrebné. Zamyslite sa nad tým, ako budú navzájom prepojené, na ktorý z nich môžete prepnúť.

Môžete zobraziť štruktúru pomocou zoznamu, môžete nakresliť blokovú schému. Ako chcete.

Toto je jedna z najdôležitejších fáz práce na stránke. Štruktúra je základ. Ak je neúspešná, stránka sa ukáže ako krivá.

Vysvetlite, čo bude na každej stránke

Klient musí pochopiť, prečo je každá stránka potrebná a aké prvky na nej budú. Sú dva spôsoby, ako to ukázať.

Prototyp- názornejší a jednoznačnejší spôsob. Dodávateľ nakreslí náčrty každej strany a pripojí ich k zadávacím podmienkam. Klient vidí, ako bude vyzerať rozhranie jeho budúceho webu a povie, čo sa mu páči a čo treba zmeniť.

Vyčíslenie prvkov- lenivá alternatíva k prototypu. Stačí si napísať, aké bloky majú byť na stránke a čo robia.

Popíšte scenáre používania stránky

Ak vytvárate nejaké neštandardné rozhranie, nestačí len ukázať štruktúru a miniatúry stránok. Je dôležité, aby celý realizačný tím a klient pochopili, ako budú návštevníci stránku používať. Skripty sú na to skvelé. Schéma scenára je veľmi jednoduchá:

• Akcia používateľa.
• Odpoveď stránky.
• Výsledok.

Samozrejme, ak vytvárate štandardnú vizitku alebo vstupnú stránku, nemusíte písať skripty. Ale ak sú na stránke nejaké interaktívne služby, je to veľmi žiaduce.

Prečítajte si viac o prípadoch použitia na Wikipédii.

Zistite, kto je zodpovedný za obsah

Niektorí vývojári okamžite vytvoria webovú stránku s obsahom. Iní umiestňujú ryby. Iní môžu písať texty, ale za príplatok. Dohodnite sa na tom na brehu a do zadávacích podmienok si napíšte, aký obsah si máte pripraviť.

Je dosť ťažké nájsť objektívne kritériá na hodnotenie kvality textov. Je lepšie nepísať nič iné ako „Vysokokvalitný, zaujímavý a predajný obsah, ktorý je užitočný pre cieľové publikum“. Je to odpad, nikto to nepotrebuje.

Je užitočné určiť, že všetok obsah musí byť jedinečný. Ďalšia ochrana klienta pred bezohľadnými umelcami.

Opíšte dizajn (ak môžete)

Rovnako ako v prípade textu je ťažké nájsť objektívne kritériá na hodnotenie dizajnu webových stránok. Ak ste sa s klientom dohodli na farebnej schéme, napíšte ju. Ak má značku, v ktorej sú uvedené typy písma, uveďte ich tiež.

O krásnom a modernom dizajne netreba písať. Nič to neznamená, nemá moc a vo všeobecnosti fuj.

Namiesto záveru: štruktúra zadávacích podmienok

Štruktúra technických špecifikácií sa bude líšiť pre rôzne úlohy. Je hlúpe vytvárať rovnaké technické špecifikácie pre novú sociálnu sieť a vstupnú stránku pre veľkoobchodný predaj mrkvy. Vo všeobecnosti však potrebujete tieto sekcie:

• Informácie o spoločnosti a cieľovom publiku, cieľoch a zámeroch stránky.
• Slovník pojmov, ktoré nemusia byť klientovi jasné.
• Technické požiadavky na usporiadanie a prevádzku lokality.
• Popis použitých technológií a zoznam požiadaviek na hosting.
• Podrobná štruktúra stránky.
• Prototypy stránok alebo popisy prvkov, ktoré by na nich mali byť.
• Scenáre používania neštandardného rozhrania (voliteľné).
• Zoznam obsahu, ktorý vytvára vývojár.
• Požiadavky na dizajn (voliteľné).

• Pravidlá pre zostavovanie Špecifikácie softvérových požiadaviek. SRS je ďalším krokom vo vývoji technických špecifikácií. Potrebné pre veľké a zložité projekty.
• Štandardy a šablóny technických špecifikácií pre vývoj softvéru. Popisy rôznych GOST a metodík na vytváranie technických špecifikácií.

Toto je koniec časti, ktorú som napísal. Ale je tu ďalší - komentáre od špecialistov, ktorí pomohli vytvoriť sprievodcu. Prečítajte si, tiež je to zaujímavé.

Komentáre vývojárov

Hovoril som s niekoľkými vývojármi, aby som zistil, ako vytvárajú technické špecifikácie. Podávam im mikrofón.

Klient potrebuje v prvom rade technické špecifikácie – aby rozumel, aká bude jeho web stránka a na čo sa budú míňať peniaze. Ak sa niečo urobí zle, môže sa obrátiť na technické špecifikácie a požiadať o prepracovanie.

Technickú špecifikáciu vypracuje projektový manažér po komunikácii s klientom a prerokovaní úlohy s projektantom.

Veľkí zákazníci často žiadajú veľmi podrobné technické špecifikácie, ktoré popisujú každé tlačidlo. Malé firmy, naopak, nemajú rady pedantné 100-stranové dokumenty. Je to dlhé čítanie a ľahko sa stane, že vám unikne niečo dôležité. Častejšie robíme stručné technické špecifikácie na 10–15 strán.

Označujeme:

• Informácie o spoločnosti a účele stránky.
• Požiadavky na dizajn, farebnú schému.
• Použité technológie a CMS.
• Kto produkuje obsah – my alebo klient.
• Štruktúra webu až po každú stránku.
• Popis každej stránky. Nerobíme prototypy, ale špecifikujeme, aké prvky majú byť na stránke a ako majú fungovať.

Najdôležitejšie sú posledné 2 časti. Sú to oni, ktorí poskytujú pochopenie toho, aká stránka bude a ako bude fungovať.

Veľmi dôležitý bod - nemôžete len zadať podmienky vývojárom a dúfať, že urobia všetko dobre. Technická špecifikácia je zoznam požiadaviek na stránku, nemôže nahradiť komunikáciu. Je dôležité zabezpečiť, aby každý člen tímu pochopil celkový cieľ a nerobil úlohy len za pochodu. Ak je niečo nejasné, je potrebné vysvetliť, prediskutovať a podrobne komentovať.

V živote sa často stáva, že človek si ani v bežných veciach nevie vysvetliť, čo chce. Keď príde na vysvetľovanie svojich „prianí“ programátorovi, človek jednoducho upadne do stuporov.

V ideálnom prípade by mal technické špecifikácie vypracovať zákazník – len on vie, čo potrebuje. V praxi to však kvôli nízkej kompetencii zákazníka v oblasti 1C musí často robiť dodávateľ. Zákazník ústne vyjadrí svoje potreby a programátor (konzultant) to dá písomne.

Prečo potrebujete technické špecifikácie?

Akékoľvek by v ideálnom prípade mali sprevádzať technické špecifikácie. Ide v prvom rade o jasnú definíciu úlohy, termínov a spôsobu realizácie. Po druhé, toto je dokument, pomocou ktorého sa vyriešia všetky kontroverzné otázky v budúcnosti. Či písať technické špecifikácie alebo nie je samozrejme vaša vec, mne osobne technické špecifikácie uľahčujú prácu a komunikáciu s klientom.

Získajte 267 video lekcií na 1C zadarmo:

Čo by mal obsahovať referenčný rámec?

Tie. zadanie musí obsahovať:

• cieľ— problém, ktorý vyriešime implementáciou tejto špecifikácie;
• popis— súhrn nadchádzajúcich zlepšení;
• spôsob implementácie— podrobný opis metód riešenia cieľa. V tomto bode je potrebné popísať všetky nuansy úlohy v jazyku programátora: aké úlohy vytvárame/upravujeme, ako by malo vyzerať rozhranie atď. Ak nehovoríte „programátorským jazykom“, ale „niečo ste počuli“, je lepšie neskúšať písať v technickom jazyku - ukázalo sa, že je to celkom zábavné. Popis by mal byť jednoznačný a nemal by vyvolávať otázky. Môže obsahovať aj príklad implementácie podobného riešenia v inej oblasti;
• hodnotenie výkonu- veľmi dôležitý bod, popis mzdových nákladov.

Existujú aj štátne normy na písanie technických špecifikácií - GOST. V praxi sa používajú zriedka, ale niekedy na tom zákazník trvá.

Zo skúseností pri odovzdávaní práce veľmi často vznikajú situácie typu „vtedy sme vám hovorili...“, čo nie je veľmi príjemné a často musíte celú prácu prerobiť. Dobre napísaná technická špecifikácia preto značne uľahčuje život obom stranám.

Príklady a vzorky technických špecifikácií pre 1C

Malý výber, ktorý som našiel voľne dostupný na internete. Od najjednoduchších a najdostupnejších až po pomerne zložité dokumenty.