Co je technická specifikace a co je třeba vzít v úvahu v technických specifikacích.

Tento text vznikl čistě z důvodu existence trvalého odkazu, který by mohl sám autor, ale i vy všichni, bez obav zasílat svým budoucím zákazníkům, kolegům, příbuzným a známým v podobě standardizované odpovědi na otázku: "Potřebuji vaše technické specifikace a co obecně?" Tohle?"

Jak se říká – „místo tisíce slov“, protože pokaždé evangelizovat 4–5 hodin na Skype na dané téma je již únavné a globální tendence vklouznout do definice „technických specifikací“ naprosté nesmysly v průběhu let zesilující.

Problém

Faktem je, že když existuje konkrétní formát, stejně jako jasná a srozumitelná definice termínu, pak všechny jeho manipulace a záměny za vaše vlastní briefy, prototypy, dotazníky vymyšlené za běhu, popisy a jednoduše příchozí aplikace vypadají přinejmenším neprofesionální. Proto začneme vědeckou definicí našeho pojmu:

Zadání - originální dokument pro návrh technického předmětu (výrobku). Technická specifikace stanoví hlavní účel vyvíjeného objektu, jeho technické vlastnosti, ukazatele kvality a technicko-ekonomické požadavky, pokyny pro dokončení nezbytných stupňů tvorby dokumentace (projekční, technologická, softwarová atd.) a její složení, jakož i jako speciální požadavky. Technická specifikace je právní dokument - žádost je součástí smlouvy mezi objednatelem a zhotovitelem projekční práce a je jejím základem: určuje postup a podmínky prací včetně účelu, cílů, zásad, očekávaných výsledků a termínů. . To znamená, že musí existovat objektivní kritéria, podle kterých lze určit, zda byla určitá část práce dokončena nebo ne. Veškeré změny, doplňky a upřesnění znění technických specifikací musí být odsouhlaseny se zákazníkem a jím schváleny. To je také nezbytné, protože pokud se v procesu řešení konstrukčního problému objeví nepřesnosti nebo chyby ve výchozích datech, je nutné určit míru zavinění každé ze stran zúčastněných na vývoji a rozložení ztrát vzniklých v souvislosti s tím. Zadání, jako pojem v oblasti informačních technologií, je právně významný dokument obsahující komplexní informace nezbytné pro stanovení úkolů pro výkonné umělce pro vývoj, implementaci nebo integraci softwarového produktu, informačního systému, webové stránky, portálu nebo jiné IT služby. .

Překlad do srozumitelného jazyka

1) Technické zadání - stanoví úkol. To znamená, že by to mělo přijít před prototyp, skicu, test, designový projekt, protože jakákoli myšlenková mapa, diagram toku dat, architektura je již dokončením určitého úkolu, to je odpověď na otázku. A než samotná otázka ještě nebude položena, zformulována a podepsána všemi stranami, bude jakákoliv odpověď a priori nesprávná, že? Začátkem jakékoli práce na jakémkoli projektu je tedy formulace problému, a ne zběsilé hledání náčrtů tuctu možností jeho řešení.

2) Z prvního bodu vlastně logicky vyplývá nový - samotný text TK musí začínat kapitolou „Cíle a záměry“, která jasně formuluje, jaké obchodní cíle sleduje tento poslední pokus o zvýšení entropie ve světě. . Bezúčelný úkol, který neřeší žádné problémy, ničeho nedosahuje a dělá se „z nudy“, není oficiálně považován za technický úkol a od nynějška je ve stavu „obyčejného kusu papíru“.

3) Jak rozumíte tomu, zda navrhovaná koncepce designu nebo interaktivní prototyp, nebo dokonce webová stránka připravená k použití, řeší výše uvedený obchodní problém? Nedá se nic dělat, budeme se muset znovu vrátit k definici: „určuje... očekávané výsledky a termíny. To znamená, že musí existovat objektivní kritéria, podle kterých lze určit, zda byla ta či ona položka práce dokončena nebo ne.“ To znamená, že technické specifikace nemohou existovat bez jasných měřitelných ukazatelů v rublech, sekundách, tunokilometrech nebo stupních Celsia. Možná brief, prototyp nebo jakýkoli jiný absurdní kus papíru, ale ne technické zadání.

Odtud docházíme k závěru, že v tomto TOR musí být kapitola „Procedura přijímání a hodnocení“, kdy jsou stejné indikátory brány, měřeny a strany si buď podají ruce, nebo pošlou projekt k přepracování.

4) Technické zadání musí být nutně v souladu s celkovým obchodním plánem zákazníka, jeho strategií rozvoje podnikání a analýzou segmentů trhu. To vše vám umožní nastavit správné cíle, odvodit přesné metriky, které pak poslouží k adekvátnímu přijetí hotového informačního produktu. Absence obchodního plánu od zákazníka automaticky zaručuje neodborné provedení Technických specifikací.

Zná outsourcované studio obchodní cíle a měřitelné ukazatele podniku lépe než jeho majitel? Je zřejmé, že ne, což znamená, že správné technické specifikace by měly být napsány zástupci objednatele, nikoli najatými zaměstnanci dodavatele. Je absurdní, když si performer zadá úkol, pak vymyslí způsoby, jak ho zhodnotit, a nakonec si dá závěrečnou známku za odvedenou práci. V ideálním případě by taková „amatérská činnost“ neměla existovat, i když v praxi se to přesně děje všude, v důsledku čehož Technické zadání neposkytuje potřebnou pomoc projektu, který je příliš často v podstatě fiktivním dokumentem. Nedělejte to tímto způsobem.

5) Každá změna hotové technické specifikace musí stát peníze. Nemůžete volně a donekonečna upravovat „Ústavu svého projektu“ jen proto, že jedna ze stran změnila názor, nevyspala se, najednou se rozhodla šetřit atd. Cena každé změny v technických specifikacích by měla být také předem jasně uvedena v příslušné kapitole.

Mimochodem, teoreticky by stejně tak každá úprava v designu nebo změna seznamu stránek či funkcí měla mít jasnou cenu, která se platí předem, před provedením této změny. Osobně navrhuji, aby případná úprava schválené technické specifikace byla odhadnuta na 30 % celého rozpočtu projektu, ale můžete to udělat i jinak.

Stojí za zmínku, že v zadání jednoduše musí být předem uvedeno načasování a celkový rozpočet na rozvoj a také seznam všech existujících zdrojů a omezení? - Ne, bude to příliš zřejmé.

Takže: Co děláme? Proč? Jak pochopíme, co jsme udělali? Kolik stojí každý pivot? - odpovědi na všechny tyto otázky napsané na kusu papíru jsou „stříbrnou kulkou“, která dokáže vytáhnout i ten nejneúspěšnější projekt.

Kontrolní otázky

1) Možná existuje také oficiální GOST pro psaní technických specifikací? - Ano, dokonce několik.

2) Co, Technická specifikace neobsahuje popis požadovaných stránek, počet tlačítek, použité knihovny, pokyny atd.? - Ne do samotného TOR, ale do Příloh si to vše můžete dát, samozřejmě s tím, že to vše přizpůsobíte výše popsaným cílům, omezením a metodám dalšího hodnocení dosaženého výsledku. Zveřejněte alespoň veškerý budoucí obsah, dokonce i popis typických postav – ne však místo jasného zadání úkolu, ale až po něm.

3) Možná to tak nepotřebuji? - Možná jsou dnes tisíce stránek vytvořeny zcela bez technických specifikací, stejně jako tisíce lidí na světě žijí dobře a jsou slepí od narození. Pokud ale chcete vidět, kam směřujete, vědomě se rozhodovat a nezávisle vyhodnocovat získané výsledky, pak se bez technických specifikací neobejdete.

4) Vy a Wikipedie tedy píšete, že technickou specifikaci vytváří zákazník. Ale nevím jak/nemám čas/prostě se mi to nechce dělat. Jak být? - Zadávejte vývoj technických specifikací třetí straně, která je dokonale obeznámena s vaším podnikáním, jeho úkoly, cílovou skupinou a potřebami a zároveň má důkladné znalosti o všech fázích vývoje webu. Tato třetí strana se stane jakýmsi „webovým notářem“, tedy garantem, že zhotovitel nepodcení vámi potřebné ukazatele nebo nebude zdržovat termíny a že zákazník nastaví dosažitelné metriky a při konečné přejímce nebude subjektivně hodnotit vytvořený produkt a měnit dříve zaznamenané požadavky za běhu.

5) A co když je technická specifikace právní dokument, tak můžu outsourcera zažalovat, nezaplatit mu, donutit ho podesáté vše předělat? - Pokud je dokument zpracován správně, jsou uvedeny cíle a metodika hodnocení jejich dosažení; pokud je dokument podepsán stranami a uveden ve Smlouvě (samotné podmínky nejsou dohodou) - pak samozřejmě můžete. Ale s obvyklým briefem, prototypy, výtvarně kreativním rozložením, Safe deal na FL - už ne.

6) Říkají mi, že práce bude provedena pomocí nějakého druhu Scrumu nebo Agile; což znamená, že již nepotřebuji archaické technické specifikace. To je pravda? - Posuďte sami: nazývají vás nesrozumitelným slovem, které jasně něco maskuje, a nyní na základě neznámého termínu nabízejí opuštění právně způsobilého dokumentu plného cílů a metrik. Agile si sama o sobě nemůže dávat žádné cíle jako „dosáhnout alespoň 10 000 návštěv do konce roku“ nebo „dosáhnout více než 25 objednávek z webu za měsíc“, je to jen způsob pořádání schůzek a nová organizace neopatrných zaměstnanců. Zamyslete se několikrát: "Nevrhají ti prach do očí?" Profesionální technické specifikace ve skutečnosti nemohou poškodit žádný nový Scrum, ale určitě pomohou.

Otázka „Je vůbec nutné vypracovat technickou specifikaci (TOR)? může vzniknout pouze u těch, kteří si vývoj webových stránek nikdy v životě neobjednali, neboť jeho potřeba vzniká již po první komunikaci mezi zákazníkem a zhotovitelem.

Technická specifikace je dokument, který podrobně a úplně popisuje budoucí projekt. Čím je detailnější, tím přesněji bude nápad realizován a tím méně konfliktů a kontroverzních situací bude vznikat při realizaci projektu, protože naprosto cokoliv se dá dělat různými způsoby. Může se na něj odkazovat, pokud něco není dokončeno nebo provedeno nesprávně nebo jsou udělány jiné chyby. Zákazník před zahájením prací obvykle popíše budoucí projekt v abstraktní formě nebo vyplní brief a zhotovitel všechny tyto požadavky a přání formalizuje a případně navrhne úpravy. Zákazník se zároveň musí ujistit, že všechna jeho „přání“ jsou zaznamenána ve specifikacích.

Pokud je s webovým studiem nebo freelancerem uzavřena dohoda o vývoji webu, technický úkol obvykle přichází jako její příloha. A v kontroverzních situacích se řídí tím, co je tam napsáno.

Z čeho se skládá technická specifikace?

Předpokládejme, že v rámci projektu potřebujete vypracovat technické specifikace pro vývoj webu pro copywriting studio Pero. Jaké body by měl obsahovat?

Obecné informace (popis)

Zde jsou následující:

Informace o společnosti. Obecné informace o studiu, co dělá. Bylo by dobré uvést seznam poskytovaných služeb. Zde můžete přidat adresu budoucí webové stránky a kontaktní údaje.

Fáze a načasování projektu. Velmi důležitý bod: plán pro všechny fáze práce je zpravidla vypracován na samém konci. Tato část poskytuje pochopení toho, co a kdy se bude dělat. Například (s daty):

• Přípravná fáze;
• Vývoj konceptu webových stránek;
• Design;
• Tvorba designového rozvržení;
• Vývoj designu stránek;
• Rozložení;
• Programování;
• Obsah náplně;
• SEO optimalizace;
• Testování;
• Zahájení.

Některé fáze, například propagace SEO, nemusí existovat. Záleží na cílech a záměrech zákazníka a kompetencích zhotovitele.

Účel a cíle

Zde je formulováno, jaké funkce bude stránka plnit a pro koho je určena.

Účel webu. Jakých cílů by mělo být vytvořením webu dosaženo? Proč je to potřeba, jaké problémy řeší?

• Reklama a získávání nových klientů;
• Zákaznická a partnerská podpora;
• Ukázka dokončené práce;
• Seznámení se seznamem služeb;
• Vytváření a udržování image společnosti.

Možná by měly být některé body popsány podrobněji. Pokud je například úkolem webu také informovat návštěvníky, pak je lepší vysvětlit, o co přesně jde.

cílové publikum. Kdo bude web používat, pro koho je vytvořen?

• Webmasteři, blogeři;
• Majitelé internetových obchodů;
• Majitelé informačních portálů;
• Reklamní studia;
• Zástupci firem a společností prezentujících se v online prostoru.

Požadavky

Rozsáhlá a nesmírně důležitá sekce, která zohledňuje co nejvíce konstrukčních a vývojových aspektů, protože za funkčnost neuvedenou v technických specifikacích si zákazník bude muset připlatit.

Typ. Do jaké kategorie webový zdroj patří?

• Vstupní stránka;
• Webové stránky vizitek;
• Firemní webové stránky;
• Informační portál;
• Internetový obchod.

Požadavky na registraci. Mohou být následujícího typu:

• Web by měl být minimalistický a zároveň odrážet typ činnosti společnosti.
• Primární barvy: zelená a bílá, podle knihy značek nebo podle uvážení designéra.
• V návrhu nemůžete použít animaci, vyskakovací okna, prvky Flash ani designové excesy.
• Nelze použít patkové fonty (lze použít standardní: Verdana, Arial, Tahoma atd.). Velikost písma by měla zajistit maximální čitelnost (12-16 bodů).

Pokud jde o požadavky na design, lze použít různé přístupy. Pokud zákazník sám přesně ví, co chce dostávat, pak svá přání podrobně popíše, uvede příklady stránek, které se mu líbí a uvede další specifika. Občas se ale stane, že on sám přesně neví, jak to má všechno vypadat, v tomto případě většinou vycházejí z úkolů, které by měl návrh řešit. Dodavatel vypracuje koncepty, nabídne řešení, obhájí svůj nápad a upraví jej na základě připomínek zákazníka. Druhá možnost je dražší a vyžaduje od zhotovitele větší kvalifikaci.

Jazykové požadavky. Mluvčí v jakém jazyce budou mít ke zdroji přístup? Jaké jazykové verze stránky by měly být?

• Ruština;
• Angličtina;
• Esperanto.

Požadavky na kompatibilitu. Z jakých zařízení a z jakých prohlížečů se stránky otevřou správně? V poslední době je trend k adaptivnímu rozložení, kdy se stránka správně zobrazí na jakémkoli zařízení s jakýmkoli poměrem stran a rozlišením obrazovky. Zde můžete uvést prohlížeče, se kterými by měl být zdroj rozhodně kompatibilní. Obvykle se stránky zobrazují na všech moderních prohlížečích stejně, problémy jsou pouze se staršími verzemi Internet exploreru.

Požadavky na CMS. Možnosti správy webu určují, které bloky lze upravovat a konfigurovat prostřednictvím ovládacího panelu, aniž by bylo nutné zasahovat do kódu nebo přímo upravovat databázi, ale pomocí pohodlného vizuálního rozhraní. Může být formulován například takto:

• Schopnost měnit obsah na stránkách webu;
• Schopnost spravovat stránky (přidávání, přejmenování, mazání atd.);
• Schopnost upravovat strukturu webu a položky nabídky;
• Funkce automatického zpracování grafiky (vytváření náhledů, transformace na danou velikost atd.);
• Schopnost psát jedinečné meta tagy;

Stejně jako v jiných podsekcích je potřeba popsat všechny požadavky a přání.

Často má zákazník již zkušenosti s prací s některým z oblíbených CMS, pak je vhodné hledat dodavatele pro konkrétní motor. Také při výběru CMS je lepší nespokojit se s řešeními napsanými vlastními silami, protože v budoucnu to bude záviset na interpretovi. Samostatně napsané motory podle mého názoru mají opodstatnění pouze ve velmi velkých projektech, kde je vyžadována specifická funkčnost nebo optimalizace velkých zátěží.

Struktura a navigace. Jaké sekce, podsekce a jednotlivé stránky bude projekt obsahovat?

• Domovská stránka
• Služby

• Copywriting
• Přepisování
• SEO copywriting
• Korektura
• Transkripce
• Správa obsahu
• Obsahový marketing

• Portfolio
• O nás
• Kontakty

Uveďte stručný popis každé stránky a uveďte definice. Co například znamená stránka „Kontakt“? Má obsahovat adresu, telefon a email v textové podobě? Nebo by tam měl být formulář pro zpětnou vazbu? Nebo možná potřebujete vložit kód Yandex Maps? Nebo vše výše uvedené umístit na stránku kontaktů plus odkazy na zástupce na sociálních sítích?

Obsah je vhodné připravit nebo alespoň nastínit před zahájením práce se zhotovitelem. To podpoří efektivnější komunikaci.

Další požadavky. Vše, co není zahrnuto v jiných částech sekce.

Popis sekcí webu

V tomto bodě jsou detaily. Obvykle je popsán obsah všech unikátních stránek: jaké prvky tam budou, jak s nimi bude uživatel pracovat.

Domovská stránka. Formulace problému může být následující.

Hlavní část hlavní stránky by měla být vytvořena ve formě vstupní stránky. Následující prvky by na něm měly být umístěny shora dolů:

• Záhlaví - logo, název společnosti;
• Navigační menu;
• Informace o akcích a slevách;
• tlačítko objednat;
• Reklamní texty;
• Blok s pěti nejlepšími pracemi a odkazem na sekci portfolia;

A tak hlavní standardy, metodiky a soubory znalostí, které zmiňují TK nebo SRS (Software (nebo System) Requirements Specification):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK atd.

GOST 34

Podle GOST 34 musí technická specifikace obsahovat následující oddíly:

1. Obecné informace
2. Účel a cíle tvorby (vývoje) systému
3. Charakteristika objektů automatizace
4. Systémové požadavky
5. Skladba a obsah práce na vytvoření systému
6. Postup pro kontrolu a přejímku systému
7. Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu
8. Požadavky na dokumentaci
9. Zdroje rozvoje

Při vývoji technických specifikací pro vládní projekty zákazníci zpravidla požadují shodu s tímto konkrétním standardem.

GOST 19

1. Úvod;
2. Důvody rozvoje;
3. Účel rozvoje;
4. Požadavky na program nebo softwarový produkt;
5. Požadavky na dokumentaci programu;
6. Technické a ekonomické ukazatele;
7. Etapy a fáze vývoje;
8. Postup pro kontrolu a přejímku;
9. Aplikace.

Přirozeně, GOST 34 (a 19) jsou již zastaralé a nerad je používám, ale se správnou interpretací norem můžete získat dobré technické specifikace, viz Závěr.

IEEE STD 830-1998

Popisuje obsah a kvalitativní charakteristiky dobře napsané specifikace požadavků na software (SRS) a poskytuje několik šablon SRS. Tento doporučený postup je určen ke stanovení požadavků na vyvíjený software, ale může být také použit jako pomoc při výběru proprietárních a komerčních softwarových produktů.

Podle normy musí zadání obsahovat následující oddíly:

1. Úvod

• 1. Účel
• 2. Rozsah
• 3. Definice, akronymy a zkratky
• 4. Odkazy
• 5. Stručný přehled

• 1. Interakce produktu (s jinými produkty a komponenty)
• 2. Vlastnosti produktu (stručný popis)
• 3. Uživatelské vlastnosti
• 4. Omezení
• 5. Předpoklady a závislosti

• 1. Požadavky na externí rozhraní
  • 1. Uživatelská rozhraní
  • 2. Hardwarová rozhraní
  • 3. Softwarová rozhraní
  • 4. Rozhraní
• 2. Funkční požadavky
• 3. Požadavky na výkon
• 4. Omezení návrhu (a odkazy na normy)
• 5. Nefunkční požadavky (spolehlivost, dostupnost, bezpečnost atd.)
• 6. Další požadavky

Ve skutečnosti je pro začátečníka docela obtížné pochopit, co by mělo být obsaženo v těchto částech podle výše uvedené struktury (jako v případě GOST), takže si musíte přečíst samotnou normu, která. ovšem v angličtině. Jazyk.

Pro ty, kteří dočetli až do konce, je tu bonus: příklad technických specifikací, které jsem napsal před mnoha lety (teď už dávno nepracuji jako analytik a další úspěšnější příklady jsou zakázány otevřela k veřejnému nahlédnutí NDA).

• Prezentace Yuri Buluy Klasifikace požadavků na software a její reprezentace ve standardech a metodikách.
• Analýza požadavků na automatizované informační systémy. Přednáška 11: Požadavky na dokumentaci.
• (číst spolu s komentáři)
• Příklady technických specifikací a další dokumentace pro vývoj AS pro Ministerstvo hospodářského rozvoje
• Styl řízení GOST. Gapertonův článek o správné práci s technickými specifikacemi podle GOST
• Šablony dokumentů obchodního analytika z

Co je to technická specifikace? Jak na to a k čemu to je? Příklady, vzorky, tipy a doporučení.

Zdálo by se, jak skvělé je, když vám někdo dokonale rozumí. Dal jsi pár frází a tady to je, přesně to, co sis představoval. Bohužel to tak nefunguje.

Problém vnímání informací je věčný. Efekt „rozbitého telefonu“ je běžný jev. Ale co když prostě nevíte, jak zadat úkol? Ano, i to se stává a je potřeba s tím nějak pracovat, ale jak? Abyste zajistili, že výsledky vámi nastavených úkolů splní vaše očekávání, napište technickou specifikaci.

Co je to technická specifikace

Technická specifikace (nebo TOR) je dokument, který obsahuje požadavky zákazníka na produkty nebo služby poskytované dodavatelem. Jednoduše řečeno: Chci mít sedm vzájemně kolmých čar a také nakreslit některé červeně a některé nakreslit bezbarvě (doporučuji zhlédnout video na toto téma na konci materiálu).

Oddělení designu

Tento dokument může zabírat buď jednu stránku A4, nebo celý svazek, vše závisí na úkolech a přáních, které jsou v něm obsaženy. Můžete například napsat technickou specifikaci pro malou vstupní stránku (jednostránkový web) nebo pro složitý software se strojovým učením a dalšími funkcemi.

Proč potřebujete technické specifikace?

• Přidělovat úkoly účinkujícím.
• Chcete-li podrobně popsat, co chcete na konci získat.
• Dohodnout se na pořadí prací.
• Zhodnotit a přijmout práci po realizaci.
• Chcete-li...(doplňte své možnosti do komentářů).

Ve skutečnosti existuje mnohem více účelů a výhod technické specifikace než ve výše uvedeném seznamu. Pro mě osobně je hlavním úkolem, který technické specifikace řeší, implementace toho, co potřebuji s minimálními odchylkami od očekávání (mých očekávání).

Díky technickým specifikacím se můžete vždy zeptat na čas realizace, peníze a dodržení deklarovaných vlastností finálního produktu nebo služby.

Ve skutečnosti se jedná o seriózní dokument, který sestavuje zákazník a zhotovitel. V rozsahu, v jakém jsou stanoveny sankce a povinnosti stran. Existuje celá řada GOST, čtěte více na Habré.

Vývoj technických specifikací

Pokud mluvíme o „dospělé“ hře, například o technickém úkolu pro vývoj mobilní aplikace nebo webu, pak se jedná o samostatnou práci, za kterou se platí hodně peněz. Přilákáte osobu, obvykle bývalého nebo současného technického ředitele, a požádáte ho, aby vám pomohl.

Mít vousy je volitelné

V závislosti na rozsahu projektu/úkolů tato osoba shromáždí všechna vaše „přání“, přeloží je do odborného jazyka, možná připraví skici (jak by to přibližně mělo vypadat) a předá vám hotový dokument. Dále předáte tento dokument účinkujícím (týmu ve vaší společnosti nebo externě), dohodnete se na penězích, termínech a pustíte se do práce.

Tip: CTO by měl být ve vašem týmu, jinak vám s největší pravděpodobností během implementace něco unikne. Na všechno prostě nemáte dostatek znalostí. Kdo se podílel na psaní technických specifikací, kontroluje je.

Z čeho se skládá technická specifikace?

Vše bude záviset na šabloně, kterou si vyberete (o něco dále dám nějaké odkazy na šablony/příklady), ale v technických specifikacích jsou zahrnuty základní bloky:

1. Popis projektu/úkolu. Stručně napíšeme, jaký je projekt nebo úkol, který je potřeba dokončit.
2. Účel a cíle. Jaké jsou cíle projektu?
3. Požadavky. Design, funkce, technologie, které jsou potřeba.
4. Popis práce. Co, kdy a jak se bude dělat.
5. Kontrolní a akceptační řízení. Jak bude dílo přijato, co lze považovat za dokončené.
6. Aplikace. Skici, skici, prototypy.

Cena díla je obvykle zahrnuta v samostatné příloze smlouvy, ale stane se tak, když si strany uvedou částky v technických specifikacích samy.

Omlouvám se za přerušení čtení. Připojte se k mému telegramovému kanálu. Čerstvé oznámení článků, vývoj digitálních produktů a hack pro růst, to vše je tam. Čekám na tebe! Pokračujme...

Příklady technických specifikací

Navzdory skutečnosti, že vývoj technických specifikací je složitý proces, je velmi zajímavý. Vaším úkolem je znovu vytvořit obrázek konečného výsledku a poté jej po částech popsat.

Příklad jednoho z mých zadání pro aktualizaci aplikace Smart TV. Úkoly pro složitější a složitější produkty byly sestaveny za pomoci kolegů z technického oddělení. Neváhejte požádat o pomoc své spoluhráče, zapojte je do procesu co nejčastěji. A nezapomeňte dát zpětnou vazbu! Není nic horšího, než dát do něčeho úsilí a čas, aniž byste znali výsledky. Řekněte nám, jak byly rady toho člověka užitečné ve vaší práci, jinak je to jednostranná hra.

Referenční podmínky pro rozvoj internetového obchodu

Zadání pro vývoj mobilní aplikace

Referenční podmínky pro web

Referenční podmínky pro služby/aktualizace

Pokud potřebujete další vzorky, stačí si to vygooglit.

Hlavním doporučením je to udělat. Potíž je v tom, že mateřská lenost přemůže každého a není snadné jí odolat. Seberte veškerou svou vůli a začněte psát technické specifikace, prostě pište a nepřestávejte. Nebojte se, že to nevyjde „dokonale“, řeknu vám tajemství, tohle se nikdy nestane. Stačí napsat, bude to pokaždé lepší a lepší.

Tak to má být

Moje první základy pro psaní technických specifikací se začaly objevovat před několika lety. Spolupracoval jsem s designéry a měl jsem za úkol vytvářet kreativy pro reklamní kampaně. Chtěl jsem to nesouvisle a změnilo se to na spoustu ztraceného času a vysvětlování. Postupem času se nastavovací úkoly začaly měnit v jakési sémantické bloky a následně v něco jako technickou specifikaci.

Například pro úkol „Tlačítko To se mi líbí na webu“:

1. Popis: na našem webu musíte vytvořit tlačítko „To se mi líbí“.
2. Účel a cíle: zapojení uživatelů, vydávání/hodnocení materiálů na základě počtu lajků.
3. Požadavky: následující design (příklad: odkaz na něco podobného), funkčnost (obrázek může hodnotit a lajkovat každý uživatel, systém webu zohledňuje počet lajků a mění výstup materiálů), technologie (dostupné na ploše a mobilní verze webu).
4. Popis práce: nakreslete 3 možnosti rozložení tlačítek (připravený termín: 10/01/17), vyvinout systém pro distribuci materiálů na základě lajků (datum: 14/10/17), testování funkcí (datum: 16/10/17 ), vydání (datum: 17.10.17)
5. Převzetí práce: uživatel stiskne tlačítko líbí, systém započítá kliknutí, změní se dodávka materiálů.
6. Aplikace: skici, skici, příklady projektů, kde funguje podobná funkce.

Nechte si pro sebe ty části a části struktury, které jsou potřebné pro vaše úkoly. Například šestý blok „Aplikace“ může být popsán ve funkčních požadavcích. Základní rada: tak či onak popište úkol podle struktury technické specifikace. Tímto způsobem vám neuniknou důležité body a ušetříte se zbytečných otázek a zároveň usnadníte život svým kolegům.

Tady máš

Podívali jsme se na to, co je to technický úkol a jak ho provést. Nyní máte možnost jasně a jasně stanovit úkoly, sdělit své myšlenky ostatním lidem a ušetřit čas na další vysvětlování. Doufám, že teď už víte, co s tím vším dělat.

Pamatujete na Murphyho zákony? Pokud můžete být nepochopeni, budete jistě nepochopeni. To platí nejen v komunikaci mezi lidmi, ale i při tvorbě webových stránek. Klient chtěl druhý Facebook, ale dostal fórum pro mladé chovatele psů. Vývojář neuhádl, co zákazník chce – ztrácel čas.

V této příručce vám řeknu, co a proč musíte napsat do podmínek zadání. Zároveň vám ukážu, jak nepsat, aby se tvorba technických specifikací neproměnila v ztracený čas.

Článek bude užitečný:

• Pro všechny, kteří se podílejí na tvorbě webových stránek: vývojáře, designéry, designéry rozložení.
• Projektoví manažeři.
• Vedoucí digitálních studií.
• Podnikatelé, kteří si plánují objednat vývoj webových stránek.

Aby byl materiál užitečný, shromáždil jsem komentáře od několika vývojářů, designérů, projektových manažerů a majitelů digitálních studií. Ty nejcennější jsem doplnil na konec článku. Pojďme to zjistit.

Co je to technická specifikace a proč je potřeba?

Technická specifikace je dokument, který stanoví požadavky na lokalitu. Čím jasnější a podrobnější jsou tyto požadavky, tím lépe všichni účastníci procesu chápou, jak by to mělo být. To znamená, že se zvyšuje šance, že všichni budou s výsledkem spokojeni.

Hlavním cílem technické specifikace je zajistit, aby si objednatel a zhotovitel správně rozuměli.

Technická specifikace má mnoho výhod. Pro každou stranu je to jiné.

Výhody pro klienta:

• Uvědomte si, za co platí peníze a jaké budou stránky. Můžete okamžitě vidět strukturu, pochopit, co bude fungovat a jak. Zjistěte, zda vám vše vyhovuje. Pokud ne, není problém to před zahájením vývoje změnit.
• Viz kompetence interpreta. Pokud jsou zadávací podmínky jasné a přesné, důvěra ve vývojáře se zvyšuje. Pokud je napsáno kaše, možná byste měli utéct a neohlížet se.
• Pojistit proti nepoctivosti interpreta. Když je stránka připravena, lze ji zkontrolovat podle technických specifikací. Existují nějaké nesrovnalosti? Developer je povinen je opravit. Pokud spolupracujete oficiálně a uzavřeli jste dohodu, můžete ji dokonce vynutit soudní cestou.
• Zjednodušte výměnu účinkujících. Pokud se klient a vývojář pohádali a utekli, může vytvoření webu zabrat spoustu času. Když bude podrobná technická specifikace, může se to přenést na nový tým – zapojí se do práce mnohonásobně rychleji.
• Zjistěte náklady na vývoj složitého produktu. Je nemožné okamžitě odhadnout přesné načasování a náklady na vývoj komplexní webové služby. Nejprve musíte pochopit, jak bude služba fungovat a jaké funkce bude mít. K tomu je třeba připravit technické specifikace.

Výhody pro interpreta:

• Pochopte, co zákazník chce. Klientovi jsou položeny desítky dotazů, ukázány příklady a nabídnuta řešení. Pak vše sepíší do jediného dokumentu a dohodnou se na něm. Pokud je vše v pořádku - hurá, pochopili jste správně.
• Pojistěte se proti náhlým přáním klienta. Občas narazíte na zákazníky, kteří chtějí v polovině úkol změnit. Pokud jste souhlasili a podepsali podmínky zadání, tak se toho nebojíte. Pokud se něco stane, i soud bude na vaší straně.
• Ukažte svou kompetenci. Dobře připravená technická specifikace ukáže klientovi odbornost vývojářů. Pokud společnost pochybuje, zda vám má svěřit vývoj webových stránek, pochybnosti budou s největší pravděpodobností rozptýleny.
• Vydělat peníze. Některá studia a vývojáři nabízejí přípravu technických specifikací jako samostatnou službu.

• Usnadnit a urychlit proces vývoje. Dobrá technická specifikace udává strukturu webu, potřebné funkce a prvky na každé stránce. Když už máte všechny požadavky před očima, zbývá už jen navrhnout a napsat kód.

Nyní pojďme zjistit, jak vytvořit dobrou technickou specifikaci, která plní všechny tyto funkce.

Mandát sestavuje výkonný umělec

Obecně platí, že každý může sestavit technické specifikace. „Potřebujeme webovou vizitku pro zubní kliniku“ – to je již technický úkol. Bude ale plnit své funkce? Stěží.

Dobrou technickou specifikaci vždy připraví vykonavatel: projektový manažer nebo vývojář. Je zřejmé, že webový vývojář rozumí tvorbě webových stránek více než majitel kavárny nebo zubní kliniky. Proto bude muset projekt popsat.

To neznamená, že klient zmizí a objeví se úplně na konci a napíše: „Zbs, schvaluji.“ Měl by se také zúčastnit procesu:

Zákazník si samozřejmě může načrtnout vlastní verzi technických specifikací. Snad to urychlí proces tvorby finálních technických specifikací. Nebo možná výsledkem budou odpadky, které budou tajně vyhozeny do koše.

Pište jasně a přesně

Tato rada vyplývá z hlavního cíle zadání – „Ujistit se, že si klient a zhotovitel správně rozumí.“

Zadávací podmínky by neměly obsahovat kvalitní přívlastky: krásný, spolehlivý, moderní. Nelze je jasně pochopit. Každý má své vlastní představy o kráse a modernosti.

Dívej se. Někdo si myslel, že tento design je krásný a dovolil, aby byl použit na svých webových stránkách:

Totéž se děje s vágními formulacemi, které samy o sobě nic neznamenají:

• Zákazníkovi se stránky musí líbit. Co když má špatnou náladu?
• Stránka by měla být pohodlná. Co to znamená? Pohodlné k čemu?
• Místo musí odolat velkému zatížení. 10 tisíc návštěvníků? Nebo 10 milionů?
• Vysoce kvalitní odborný obsah. No, rozumíte tomu.

Zkontrolujte, zda v textu nejsou nejasnosti. Pokud existuje, přepište jej. Vaše formulace by měla být jasná a přesná:

• Stránka se musí načítat rychle → Každá stránka na webu musí mít v Google PageSpeed ​​​​Insights více než 80 bodů.
• Velké zatížení → 50 tisíc návštěvníků současně.
• Na hlavní stránce se zobrazí seznam článků → Na hlavní stránce se zobrazí seznam posledních 6 publikovaných článků.
• Minimalistické uživatelsky přívětivé rozhraní předplatného → pole „Nechte svůj e-mail“ a tlačítko „Přihlásit se“ → *nakreslená skica*.

Vyřešili jsme formulaci, pojďme na strukturu.

Uveďte prosím obecné informace

Všichni členové týmu musí správně rozumět tomu, co společnost dělá a kdo je její cílová skupina. Aby se nikdo nepletl, je lepší to napsat na úplný začátek zadání.

Vyplatí se také uvést účel webu a ve zkratce popsat jeho funkčnost – abyste místo blogu neskončili u internetového obchodu.

Vysvětlete obtížné pojmy

Prvním pravidlem zadání je, že musí být srozumitelné každému, komu je určen. Pokud budete používat termíny, kterým váš klient, majitel dětského hračkářství, nemusí rozumět, určitě je vysvětlete. Jasným jazykem, nikoli kopírováním a vkládáním z Wikipedie.

Popište nástroje a požadavky na hosting

Představte si, že jste strávili 2 měsíce tvorbou skvělého webu. Každá fáze byla koordinována s klientem - byl potěšen. A teď je čas odevzdat práci. Ukážete admin panel a klient zakřičí: „Co je tohle? Modex?! Myslel jsem, že to uděláš na WordPressu!“

Chcete-li se těmto problémům vyhnout, popište použité nástroje, motory a knihovny. Zároveň uveďte své požadavky na hosting. Nikdy nevíte, uděláte to v PHP - a klient má server v .NET.

Vyjmenujte požadavky na provoz stránek

Stránka musí fungovat ve všech současných prohlížečích a na všech typech zařízení. Ano, to je zřejmé každému vývojáři a každému zákazníkovi. Ale je lepší napsat, abyste ochránili klienta před prací vykonanou ve zlé víře.

Napište sem požadavky na rychlost načítání stránek, odolnost proti zatížení, ochranu před útoky hackerů a podobné věci.

Určete strukturu webu

Než začnete kreslit návrh a rozložení, musíte se s klientem dohodnout na struktuře webu.

Promluvte si se zákazníkem a zjistěte, co potřebuje. Shromážděte vývojáře, SEO specialisty, marketéry, šéfredaktora – a rozhodněte, jaké stránky jsou na webu potřeba. Přemýšlejte o tom, jak budou vzájemně propojeny, ze kterého můžete přejít.

Strukturu můžete zobrazit seznamem, můžete nakreslit blokové schéma. Jak si přejete.

Toto je jedna z nejdůležitějších fází práce na webu. Struktura je základ. Pokud nebude úspěšný, web se ukáže jako křivý.

Vysvětlete, co bude na každé stránce

Klient musí pochopit, proč je každá stránka potřebná a jaké prvky na ní budou. Existují dva způsoby, jak to ukázat.

Prototyp- názornějším a jednoznačným způsobem. Zhotovitel nakreslí náčrtky každé stránky a připojí je k zadání. Klient vidí, jak bude vypadat rozhraní jeho budoucího webu a říká, co se mu líbí a co je potřeba změnit.

Výčet prvků- líná alternativa k prototypu. Stačí napsat, jaké bloky by na stránce měly být a co dělají.

Popište scénáře používání webu

Pokud vytváříte nějaké nestandardní rozhraní, nestačí pouze ukázat strukturu a miniatury stránek. Je důležité, aby celý realizační tým a klient pochopili, jak budou návštěvníci stránky používat. Skripty jsou na to skvělé. Schéma scénáře je velmi jednoduché:

• Akce uživatele.
• Odpověď webu.
• Výsledek.

Samozřejmě, pokud vytváříte standardní vizitku nebo vstupní stránku, nemusíte psát skripty. Ale pokud jsou na webu nějaké interaktivní služby, je to velmi žádoucí.

Přečtěte si více o případech použití na Wikipedii.

Určete, kdo je za obsah zodpovědný

Někteří vývojáři vytvoří web s obsahem hned. Jiní umisťují ryby. Ještě jiní mohou psát texty, ale za příplatek. Domluvte se na tom na břehu a napište si do zadání, jaký obsah byste si měli připravit.

Vymyslet objektivní kritéria pro hodnocení kvality textů je poměrně obtížné. Je lepší nepsat nic jiného než „Vysoce kvalitní, zajímavý a prodejný obsah, který je užitečný pro cílové publikum“. Je to odpad, nikdo to nepotřebuje.

Je užitečné určit, že veškerý obsah musí být jedinečný. Další ochrana klienta před bezohlednými umělci.

Popište design (pokud můžete)

Stejně jako u textu je obtížné přijít s objektivními kritérii pro hodnocení designu. Pokud jste se s klientem dohodli na barevném provedení, napište ho. Pokud má značku, ve které jsou fonty specifikovány, uveďte je také.

O krásném a moderním designu není třeba psát. Nic to neznamená, nemá moc a obecně fuj.

Místo závěru: struktura zadání

Struktura technických specifikací se bude pro různé úkoly lišit. Je hloupé vytvářet stejné technické specifikace pro novou sociální síť a vstupní stránku pro velkoobchodní prodej mrkve. Ale obecně potřebujete tyto sekce:

• Informace o společnosti a cílové skupině, cílech a záměrech webu.
• Slovníček pojmů, které nemusí být klientovi jasné.
• Technické požadavky na uspořádání a provoz staveniště.
• Popis použitých technologií a seznam požadavků na hosting.
• Detailní struktura webu.
• Prototypy stránek nebo popisy prvků, které by na nich měly být.
• Scénáře pro použití nestandardního rozhraní (volitelné).
• Seznam obsahu, který vytváří vývojář.
• Požadavky na design (volitelné).

• Pravidla pro sestavování specifikace požadavků na software. SRS je dalším krokem ve vývoji technických specifikací. Potřebné pro velké a složité projekty.
• Standardy a šablony technických specifikací pro vývoj softwaru. Popisy různých GOST a metodik pro vytváření technických specifikací.

Toto je konec části, kterou jsem napsal. Ale je tu ještě jeden - komentáře od specialistů, kteří pomohli vytvořit průvodce. Přečtěte si to, je to také zajímavé.

Komentáře vývojářů

Mluvil jsem s několika vývojáři, abych zjistil, jak vytvářejí technické specifikace. Předám jim mikrofon.

Klient potřebuje v první řadě technické specifikace – aby rozuměl tomu, jaký bude jeho web a za co budou utráceny peníze. Pokud se něco udělá špatně, může se obrátit na technické specifikace a požádat o přepracování.

Technickou specifikaci vypracuje projektový manažer po komunikaci s klientem a projednání úkolu s projektantem.

Velcí zákazníci často žádají velmi podrobné technické specifikace, které popisují každé tlačítko. Malé firmy naopak nemají rády pečlivé 100stránkové dokumenty. Je to dlouhé čtení a snadno se stane, že vám něco důležitého unikne. Častěji zpracováváme stručné technické specifikace v rozsahu 10–15 stran.

Uvádíme:

• Informace o společnosti a účelu stránek.
• Požadavky na design, barevné provedení.
• Použité technologie a CMS.
• Kdo vytváří obsah – my nebo klient.
• Struktura webu až na každou stránku.
• Popis každé stránky. Neděláme prototypy, ale specifikujeme, jaké prvky mají na stránce být a jak mají fungovat.

Poslední 2 části jsou nejdůležitější. Jsou to oni, kdo poskytuje pochopení toho, jak bude web vypadat a jak bude fungovat.

Velmi důležitý bod - nemůžete jen zadat podmínky vývojářům a doufat, že vše udělají dobře. Technická specifikace je seznam požadavků na stránky, nemůže nahradit komunikaci. Je důležité se ujistit, že každý člen týmu rozumí celkovému cíli a nedělá úkoly jen za chodu. Pokud je něco nejasné, je potřeba to vysvětlit, prodiskutovat a podrobně komentovat.