Technické specifikace pro modernizaci větrání ve výzkumném ústavu. Technické specifikace pro modernizaci větrání ve výzkumném ústavu Co je to technická specifikace a proč je potřeba?

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 webových stránek. 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 pochopil, jaký bude jeho web a za co budou peníze utráceny. 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.

Jak přesně jsou technické specifikace pro modifikaci 1C vypracovány, přímo určuje, zda budou vyřešeny úkoly přidělené vývojářům. Při práci s takovým dokumentem však existují určité potíže. V širším smyslu specifikuje TOR standardy pro vytváření a modernizaci automatizovaného systému (AS) a také postup práce. Patří sem také soubor standardů pro zahájení projektu. Toto chápání role technických specifikací je diktováno požadavky GOST 19.201-78 a 34.602-89, podle kterých se provádí vývoj technických specifikací pro 1C. Existuje další výklad významu tohoto dokumentu, bližší praxi.

Podle jiné definice jsou zadání pro revizi 1C dokumentem upravujícím účel a parametry budoucího systému, jakož i proces tvorby dokumentace a jejího seznamu. Tento výklad umožňuje zohlednit zájmy programátorů a zákazníka.

Jaká by měla být technická specifikace?

Jakékoli technické zadání pro vývoj programu 1C vytváří dodavatel. Ale to nedělá programátor, ale analytik. To je důležitý bod, protože dokument musí být vypracován v jazyce srozumitelném klientovi, bez vysoce specializovaných odborných výrazů. Když jsou zohledněny všechny nuance projektu a informace jsou správně formulovány, jsou technické specifikace dohodnuty se všemi zákazníky. Pokud je přijat, jsou do práce zapojeni programátoři. V tomto případě musí dokument jasně nastínit požadovaný výsledek. To pomáhá vývojářům nastavit správný cíl a zkontrolovat jej v různých fázích. Při vypracovávání technických specifikací pro modifikaci 1C je třeba věnovat velkou pozornost znění. Je třeba dbát na to, aby byly dostatečně konkrétní a neznamenaly jiné výklady. To je první věc, kterou je třeba pamatovat při práci s technickými specifikacemi. K návrhu je také potřeba přistupovat zodpovědně. To platí i pro titulní stranu dokumentu.

Hlavní chyby v technických specifikacích pro vývoj 1C

Struktura technických specifikací je upravena GOST 34.602-89. Tento dokument obsahuje jasné požadavky na počet a pořadí informačních bloků v technických specifikacích. Zároveň neexistují žádné přísné normy pro způsoby prezentace. Tato situace skrývá velký potenciál pro řešení složitých problémů a zároveň může vést k mnoha chybám při sestavování dokumentu. Nejčastější nepřesnosti jsou:

1. Opakování některých úseků v různých výkladech.
2. Informace jsou poskytovány náhodně. V ideálním případě by se měl týkat konkrétní struktury, jako jsou obchodní procesy nebo systémové moduly.
3. Informace v různých částech jsou prezentovány s různou mírou podrobnosti.

To vše brání zákazníkovi v pochopení informací obsažených v technických specifikacích. To komplikuje proces spolupráce, takže je pracnější.

Poté, co si zákazník prohlédne vzorovou technickou specifikaci pro úpravu 1C, může se změnit a ne vždy k lepšímu. To zase obvykle brání programátorům ve správném vnímání informací. To platí zejména pro specialisty s malými zkušenostmi. V této fázi se často vyskytují následující chyby:

1. Požadavky různých sekcí si vzájemně odporují.
2. Formulace se ukazuje jako nepřesná.
3. Na některých místech jsou informace příliš podrobné.

Je snadné se zbavit všech uvedených chyb. Musíte se zaměřit především na výsledek, a ne na pečlivé předepisování formulací. Je třeba připomenout, že technická specifikace popisuje funkčnost projektu, jeho hlavní parametry a účel.

Jak se vyhnout chybám při vývoji technických specifikací?

Základní pravidlo, které platí pro všechna následná doporučení, je, že formulace musí být konkrétní. Chcete-li to provést, musíte použít odkazy na GOST a další regulační dokumenty. To umožňuje zhotoviteli a zákazníkovi vnímat informace stejným způsobem.

Příklad technické specifikace pro modifikaci 1C předpokládá použití jazyka obchodního sektoru, pro který je projekt realizován. To je nutné především pro zákazníka. V textu byste však neměli používat žádná přirovnání, protože je lze interpretovat různými způsoby.

Základní pravidla při sestavování technických specifikací pro vývoj zprávy a dalších prvků 1C:

1. Technickou specifikaci tvoří společně zhotovitel a objednatel.
2. Na práci programátorů by měly být kladeny pouze objektivní požadavky. Pro úspěšný vývoj projektu musí být subjektivní vize zákazníka minimalizována.
3. Je potřeba detailně popsat výsledek, který zákazník potřebuje. V tomto případě je v příkladu technické specifikace pro vývoj konfigurace 1C nutné specifikovat všechny parametry, podle kterých má prvek fungovat. V opačném případě se může výsledek výrazně lišit od požadovaného.
4. Rizika zhotovitele a objednatele by měla být přibližně stejná a minimalizovaná.
5. Nemůžete používat termíny, které se používají v obchodní komunikaci a nepoužívají se v konkrétním odvětví.

Pro vytvoření technické specifikace pro vývoj zprávy v 1C nebo jiném prvku musí analytik znát všechny vlastnosti oblasti činnosti zákazníka. Požadavky by měly poskytovat pouze užitečné informace, které budou užitečné pro dodavatele. Vzhledem k tomu, že se zde zaměřujeme na konečné problémy, které musí software vyřešit, neexistuje jediný příklad technické specifikace.

Nebezpečí nesprávného sestavení technických specifikací

Výše uvedené chyby mohou vést ke zvýšení času stráveného vytvářením systému. To s sebou nese zbytečné náklady a nespokojenost. Zadávací podmínky pro vývoj databáze nebo jiné konfigurace 1C by měli vypracovat zkušení specialisté. Přínos všech účastníků závisí na tom, jak snadno je tento dokument srozumitelný. Zákazník dostává efektivní automatizovaný systém pro řešení obchodních problémů. Zhotovitel má přitom dalšího spokojeného klienta. Majitelé firem musí být při výběru partnerských společností 1C co nejopatrnější, protože efektivita organizace do značné míry závisí na tom, jak dobře jsou vypracovány technické specifikace pro revizi.

Pokud procházíte zahraniční stránky s požadavkem „dokument s požadavky na produkt“, můžete najít kreativní a přesvědčivé články o tom, že technické specifikace (TOR, PRD) jsou mrtvé. S tím musíme částečně souhlasit - při vývoji produktu od nuly vypadá prototypování mnohem zajímavěji a efektivněji než objemy poznámek zákazníků, které jsou někdy velmi neprofesionální. Pokud se však bavíme o finalizaci základního systému, pak věci naberou úplně jiný spád. Čelíme jak úpravám, tak zakázkovému vývoji, takže technická specifikace je pes-eat-dog, pokud nám kuchař nelže. Obecně se dnes bavíme o těch klasických technických úlohách, které jsou psány pro vylepšení zakoupeného a nainstalovaného softwaru. Zkrátka o bolestivých věcech.

Aspekty interakce

Zdroje- lidé, stroje, zařízení, vývojové prostředí, čas a peníze, které musí být použity v procesu implementace požadavků. Zdroje vyžadují jasné plánování a hodnocení ve fázi schvalování technických specifikací. Správné stanovení priorit na straně zákazníka a rozdělení pracovních zdrojů na straně dodavatele umožňuje vyhnout se promeškaným termínům a minimalizovat další rizika.

Možnosti- zkrátka tohle prodejce (umělec) skutečně umí. Podívejme se na příklad našeho RegionSoft CRM. Klient zakoupí systém a vypracuje technickou specifikaci pro úpravu: je nutné vytvořit integraci s webem a napojit události v CRM na číslo objednávky internetového obchodu. To je realistický požadavek, máme zdroje a schopnosti to udělat. K CRM také potřebujete vyvinout a připojit CMS, systém pro správu obsahu webových stránek. Teoreticky to umíme, ale nemáme možnost to udělat levně a klient nám nemá možnost zaplatit tolik, abychom na úkol vyčlenili lidské a časové zdroje. V důsledku toho zákazník tento požadavek odmítá – a CMS vlastně nepotřebuje, vše je v pořádku. Ale o „chamtivosti“ TK později.

Omezení- soubor překážek, které ztěžují nebo znemožňují provádění úkolů z technických specifikací: rozpočet, zásobník technologií, problémy s licencemi, legislativní zákazy, konfigurace hardwaru atd.

Všechny čtyři podstaty se tedy úzce prolínají a určují úspěšnost projektu jako celku. Podívejme se na každý prvek a pokusme se zdůraznit kritické body, které je třeba mít na paměti při práci na technických specifikacích.

Sběr a analýza požadavků

Nikdo nezná vaši společnost lépe než vy a vaši zaměstnanci. To znamená, že shromažďování a analýza požadavků je výhradně vaším úkolem, ve kterém vám může prodejce pomoci a vést, ale v žádném případě do procesu nezasahovat. Zeptejte se vývojáře na takové implementace, zjistěte, co hledat a začněte. Mimochodem, dobrým asistentem může být váš zaměstnanec, který se dobře orientuje ve specializovaném tématu a má přibližnou představu o softwarové architektuře a zná proces vývoje – může působit jako analytik a interní expert dohlížející na proces tvorby technických specifikací a komunikace s prodejcem.

Existuje velmi jednoduché schéma pro sběr požadavků.

1. Vytvořte pracovní skupinu manažerů a zkušených specialistů z oddělení, kteří budou využívat CRM. Řekněte nám o řešení, které si hodláte vybrat, poskytněte přístup k demo verzi.
2. Členové pracovní skupiny by měli zaměstnancům zprostředkovat informace a zcela volnou formou se jich zeptat na jejich přání k novému programu. Pokud se některý ze zaměstnanců s takovým softwarem nikdy nesetkal a není připraven hovořit o budoucím použití, musíte ho požádat, aby popsal své pravidelné úkoly, jedná se o univerzální přístup.
3. Každé oddělení pak identifikuje, co CRM nemá nebo co neměří, a agreguje informace.
4. Pracovní skupina analyzuje shromážděné požadavky, kontroluje a odstraňuje křižovatky. Například obchodní oddělení a marketingové oddělení často objednávají stejnou sestavu, ale požadavky mohou mít různé názvy pro pole a entity, ačkoli data za nimi jsou stejná. V souladu s tím musíme dojít k jednotné formě.
5. Pracovní skupina vytvoří seznam požadavků a stanoví priority. V této fázi můžete zapojit dodavatele, protože je odpovědný za zdroje. Můžete například požádat o vytvoření vlastní sestavy pro RegionSoft CRM nebo si můžete objednat integraci s webem. Jde o úkoly se zcela odlišnými termíny, priorita je zde velmi důležitá.

Anatomie technické specifikace

• Identifikace – definování požadavků, hledání problémů, které je třeba řešit.
• Analýza - analýza požadavků, identifikace klíčových potřeb, zobecnění.
• Adaptace – posouzení požadavků v kontextu schopností CRM a stávajících obchodních procesů.
• Dokumentace - formální a podrobný popis požadavků, schválení technických specifikací.
• Komunikace s dodavatelem (vývojářem) - iterativní interakce s prodejcem ohledně vylepšení v souladu se sestavenými technickými specifikacemi.
• Implementace je práce dodavatele na vytvoření potřebné funkcionality. Je lepší, když je prodejce neustále v kontaktu se zákazníkem – výsledný produkt tak bude co nejpřesněji odpovídat představě klienta.
• Testování - kontrola funkčnosti zaměstnanci dodavatele, interními experty klienta a koncovými uživateli za účelem zjištění souladu s modifikací a technickými specifikacemi a provozuschopnosti systému se změnami.

Obchodní úroveň- nejglobálnější úroveň, na které se řeší složité a prioritní úkoly. Tato úroveň zahrnuje integraci, zlepšování a modelování podnikových procesů, vývoj nových funkčních modulů. Zpravidla se jedná o vývoj náročný na zdroje, se seriózními konzultacemi a úzkou spoluprací se zákazníkem. Například v RegionSoft CRM byly kdysi takové zakázkové úpravy skladové účetnictví, pokladna a výroba. Postupně byly změny začleněny do vydání a později umožnily vytvořit nový produkt pro velkoobchody, maloobchody a hypermarkety - RegionSoft Retail.

Úroveň uživatele nebo skupiny uživatelů. Na této úrovni jsou implementovány úkoly pro upřesnění stávajícího rozhraní. Uživatel může například chtít, aby se při najetí myší na zákazníka zobrazilo okno s číslem a stavem poslední objednávky, nebo vlastní sestava se speciálním seskupením dat. Přepracování na této úrovni zabere méně času, ale může jich být mnoho – například několik požadavků z oddělení marketingu, logistiky a technické podpory.

Úroveň funkčnosti.Často je těžké ho oddělit od předchozího, funguje zde formální kritérium - zlepšení není na úrovni zobrazení něčeho v rozhraní, ale na úrovni finalizace systémové logiky. To může zahrnovat požadavky na různé druhy třídění, integraci chatu a možnosti telefonování.

Úroveň služby- ve skutečnosti by požadavky této úrovně měly být jako první zahrnuty do nových sestavení s opravami. Jedná se o úkoly související s rychlostí odezvy systému, provozem při vysoké zátěži a zabezpečením. V ideálním případě by prodejce neměl mít takové úpravy – firemní software by neměl zpomalovat, ztrácet data, sbalovat formuláře a distribuovat přístupová práva na stejné úrovni. Pokud se ale objeví požadavek a nesouvisí s osobní paranoiou zákazníka nebo problémy na hardwarové straně, vyplatí se mu věnovat zvýšenou pozornost.

Technologická úroveň- poslední na seznamu, ale před ostatními v důležitosti a složitosti. Mohou to být požadavky zákazníků související s platformou, operačním systémem nebo zařízeními. Například požadavek na sestavení pro MacOS. Bylo by skvělé, kdyby se takové požadavky postupně rozvinuly do vydání, ale je nezbytné mít pro ně opravy. Právě z požadavků zákazníků na této úrovni jsme vytvořili RegionSoft CRM pro MacOS a přidali vzdálený přístup pomocí technologie TRM jako dočasné řešení ke vzácnému, ale existujícímu požadavku na mobilní verzi.

Anatomie technické specifikace je jednoduchá, alespoň ve formě kostry. Povinné části technické specifikace pomáhají zákazníkovi zaměřit se na problém a správně formulovat úkol a zhotoviteli pochopit, co po něm chce. Mimochodem, o porozumění. Samozřejmě jsme na začátku příspěvku trochu lhali a popírali obchodní konzultanty jako třídu. Jde o to, že každý dodavatel působí na trhu několik let (nemluvíme o jednodenních CRM), nebo dokonce desetiletí, což znamená, že má řadu případů v téměř každém odvětví. Inženýři, programátoři a prodejci jsou tedy obeznámeni se specifiky implementace v každém typu společnosti. Opět je ale důležité zaměřit se konkrétně na své podnikání.

Pro koho? V této části musíte popsat, kdo bude konečným uživatelem vylepšení, jaké úkoly se plánují řešit a s jakou frekvencí.

Dovolte mi uvést příklad. Jedna společnost implementovala CRM a měla pracovat s poměrně velkým polem dat (několik desítek milionů záznamů měsíčně, několik set tisíc záznamů denně). Vedoucí obchodního oddělení si vyžádal zprávu o nahrávání těchto záznamů v „denní“ frekvenci. Přirozeně, že taková zpráva se stovkami uživatelů pracujících současně zatížila systém – byla nalezena řešení pro optimalizaci procesu. Už v průběhu práce se ukázalo, že obchodník hrál na jistotu a report potřebuje až na konci měsíce a pak se to dalo spustit podle plánu v noci. Netřeba dodávat, že čas a peníze byly promarněny.

Proč? Zdůvodnění potřeby zlepšení a jeho místo v obchodním procesu. Tento bod je potřebnější pro samotného zákazníka, ale také je užitečné, aby prodejce věděl, jaké další procesy budou ovlivněny. Někdy to pomůže najít alternativní řešení.

co by to mělo dělat? Nejinformativnější blok - popisuje požadavky a očekávání od systému. A tady se dějí samé perly, zázraky a srážky, které je právě vhodné poslat do bashorga a které, no, velmi ztěžují život. Důvod je jediný – uživatel neví, co chce, co je potřeba udělat. Je tu ještě jeden malý poddůvod – uživatel nemůže formulovat požadavky. A zde je úkolem vývojáře (pracovní skupiny, analytika, pokud existuje) pomoci správně formulovat potřebu, vybrat vhodný požadavek a zasadit úkol do kontextu fungování systému. Ve stejném bloku musíte uvést očekávaný výsledek.

Parametry specifikace- termíny, fáze realizace, odpovědnost ze všech stran, potřebné kontakty atd. Ve skutečnosti se jedná o soubor důležitých formálních věcí, které z dokumentu dělají technickou specifikaci. Zadání musí být dohodnuto a podepsáno stranami, aby se předešlo četným změnám během vývoje (stále k nim dojde, ale v menší míře).

V ideálním případě je technická specifikace vypracována za aktivní účasti prodejce a jejím výsledkem je přibližně následující struktura:

1. Popis požadavků každého mechanismu a každé funkce
2. Popis implementace této funkcionality
3. Cena práce pro každou fázi zvlášť
4. Celková cena práce pro tuto technickou specifikaci
5. Časové rámce pro dokončení práce, rozdělené podle fází a s uvedením priority
6. Popis podmínek instalace a testování úprav
7. Výhrady týkající se vyčerpávající povahy podmínek zadání a dalších podmínek

10 pravidel napsaných v slzách vývojáře

Technická specifikace by neměla být zištná. Podnik často přeceňuje své schopnosti nebo chce získat „všechno najednou“. Tento přístup není opodstatněný ani z finančního, ani obchodního hlediska. Prodejce zpravidla několik týdnů neexistuje (v případě RegionSoftu - 15 let) a můžete ho kontaktovat po nějaké době, až skutečně pochopíte, co v CRM chybí.

Nápadný příklad redundance doslova ze včerejška: klient si koupil ERP od známé ruské společnosti v domnění, že když účetnictví funguje, bude ERP od tohoto dodavatele dobré. ERP se ukázalo nejen jako nepříliš dobré samo o sobě, ale také jako velmi nevhodné pro podnikání. RegionSoft CRM je ale vhodný pro skladové účetnictví a výrobu. Existuje řešení: zapomeňte na ERP, brečte, integrujte účetnictví 1C s novým CRM a užijte si pohodlnou implementaci. Ale škoda těch vyhozených peněz! A klient vyžaduje integraci CRM s ERP. Neudělali jsme to, ale proč takové plýtvání, proč dva relativně podobné systémy?

Zadávací podmínky musí být realistické a dosažitelné- jak z hlediska požadavků, tak termínů. Zde je důležité naslouchat názoru prodejce, protože přesně ví, kolik času stráví tento nebo ten úkol. Věřte, že pro vývojáře není výhodné ztrácet čas a zvyšovat termíny – je pro něj výhodné dokončit co nejvíce projektů a udělat to dobře, aby neutrpěl ránu na své pověsti. Co se týče realističnosti, vyhnout se požadavkům na upgrade CRM na úroveň systému pro správu colliderů je jednoduché: do požadavků byste měli zahrnout to, co je v současnosti a v dohledné době skutečně potřeba.

Například RegionSoft CRM je desktopový program, nemáme klienta prohlížeče. Žádat nás o vytvoření webové aplikace pro jednu společnost je nesmyslné, jedná se o zásadní vývoj, aktuálně probíhá a není možným vývojem pro jednu společnost. Ne, samozřejmě, všechno má svou cenu, ale opět - obecně platí, že požadavek nelze splnit.

Nemělo by se to zaměňovat se situací, kdy se bavíme o zakázkovém vývoji a radikálně se mění myšlenka a logika aplikace, ve skutečnosti je sponzorována tvorba nového softwaru „pro sebe“. Ale to už je jiný příběh.

Zadávací podmínky musí být podrobné. Je nutné uvést všechny významné detaily budoucího projektu: od frekvence používání programu až po přání pro rozhraní. Čím podrobnější požadavky budou, tím jednodušší a rychlejší bude implementace a testování. Zvláště stojí za to věnovat pozornost detailu, pokud pracujete v konkrétním odvětví (lékařství, pojišťovnictví, banky) - podrobné představení nuancí interakce mezi obchodem a programem zajistí, že prodejce porozumí úkolu a rychle přizpůsobí systém tvoje společnost.

Nezapomeňte věnovat pozornost formátům čísel, názvům polí, přítomnosti či nepřítomnosti rozevíracích seznamů, chování tlačítek a nápověd a datovým typům. Pokud zákazník používá vlastní vzorce, které musí být zahrnuty v logice provozu CRM ( například výpočet dealerských bonusů), tyto vzorce musí být napsány s úplným vysvětlením jejich označení a logiky výpočtu.

Technická specifikace musí být jednoznačná a přesná. Vágní formulace, možnosti implementace, nejasné požadavky – to vše je cesta do slepé uličky. Stává se, že klient z dobrých úmyslů napíše do technické specifikace několik možností chování systému, blízkých, ale ne ekvivalentních. V tomto případě si je jistý, že pomáhá, pobízí programátora, ale ve skutečnosti je cesta do pekel dlážděna dobrými úmysly, vývojář musí pochopit, co přesně je potřeba, a sám si vybere, jak to udělat, na základě na vlastnostech systému a zásobníku použitých technologií.

Technická specifikace musí být napsána v lidské řeči. A to je důležité, ne, DŮLEŽITÉ. Zdůrazním dvě situace, kdy jazykové problémy vedou ke zpoždění v realizaci projektu.

1. Klient se snaží prokázat svou technickou gramotnost a dělá konstrukce typu: „implementovat do těla kalendáře okno s nápovědou s možností reagovat na události volání...“ místo „v kalendáři by mělo vyskočit okno ve kterém můžete označit úkol jako dokončený.“ Pokud vy nebo váš interní expert nemáte schopnosti psát odborné texty, negooglete – pište obyčejnými slovy, my jim rozumíme.

   Referenční podmínky by neměly být knihou stížností. Musíte problém vyřešit, ne ho popisovat, věnovat pozornost fontům a zapomenout na popis požadavků. Technická specifikace musí obsahovat nejen samotný problém, ale i jeho řešení na úrovni porozumění – vývojář jej pak vyřeší na úrovni kódu. Porovnejte "Obchodní oddělení neplánuje dobře, ztrácí čísla, už rok se trápíme" A „je nutné vytvořit report, který bude ukládat hodnoty plánovaných a skutečných prodejů měsíčně v členění podle produktových skupin“.

   Zadání musí být schopné nahlížet do budoucnosti. Tedy ne přesně to, ale lidé za tím. Pokud je známo, že brzy nastanou změny v obchodních procesech, je třeba s tím počítat, aby se za úpravy neplatilo dvakrát.

   Mandát by neměl být byrokratický. Pokud jste někdy sepisovali tento dokument, pravděpodobně jste cítili, jak těžké je vyhnout se pokušení sklouznout k byrokracii, přidat úvodní slova, strohé fráze a popsat každý bod jako článek trestního zákoníku (nejlépe s trestem pro každého za porušení ). Byrokratické formulace maskují neúplné pochopení účelů tvorby technických specifikací. Ve smlouvě je uvedena odpovědnost dodavatele a je tam napsán i rozpočet. Tyto body byste neměli převádět do technických specifikací.

   Referenční podmínky musí být technické specifikace. Zní to paradoxně, ale často místo technických specifikací čteme dopisy, stížnosti, smlouvy, nově sepsané pokyny k CRM nebo zápisy z jednání. Podle takového dokumentu se samozřejmě pracovat nedá. Chcete-li zůstat na vrcholu formy a obsahu, použijte trik ze staré školy: podívejte se na termín slovo po slovu. Technický znamená, že diktuje modifikaci, technologii a je zaměřen na řešení problému změnou softwaru. To je to, o čem musíme mluvit v kontextu softwaru. Zadání znamená položit otázku, problém, bez rad, tipů nebo předběžných hodnocení. Jen konstatování problému.

   Přikázání skončila, nyní kárání

   Kromě vyjmenovaných pravidel stojí za řeč ještě pár věcí. Hovoříme o cílech, plánech a očekáváních – všech těch prvcích, díky kterým je projekt úspěšný, a vztah mezi dodavatelem a klientem je téměř přátelský.

   Technické specifikace je třeba napsat rychle, i když stojíte před úkolem zautomatizovat procesy mobilního operátora nebo velkého hypermarketu. To je způsobeno skutečností, že technologie se vyvíjejí obrovskou rychlostí a dokonce i systém, který implementujete, může přežít hlavní vydání (nebo někdy dvě) za šest měsíců nebo rok a získat nové funkce. Možná budete muset znovu zvážit potřebu úprav a zahájit proces znovu.

   

   
   Nakonec si našel čas na dokončení technického úkolu. Ale bohužel už tu nejsou žádní vývojáři, kteří by to implementovali.

   Klient nezná zásobník a technická omezení. A neměl by vědět - to je úkol prodejce, je to on, kdo hodnotí práci po vypracování technických specifikací. Zákazník by se neměl vrtat v technologii a každou čárkou se ptát, zda prodejce umí to či ono. Vypracujte komplexní technickou specifikaci a developer vybere vhodnou architekturu – často dokonce lepší, než byste si mysleli.

   Zhodnoťte svůj rozpočet a vyhněte se nepříjemným překvapením- téměř společný úkol číslo jedna. Neměli byste na dodavatele tlačit a vyžadovat od něj přibližné posouzení práce (no, alespoň přibližně, z ruky, od oka, ale jako u jiných, dobře, v projektech tohoto typu, ale ze zkušenosti, dobře, v rámci míra chyby). Úplné posouzení rozpočtu je možné pouze po přečtení, analýze a konečném schválení zadání. Pokud se váš vývojář chová jinak, připravte se na to, že revize bude stát minimálně dvakrát tolik.

   Na základě objektivní potřeby změn a rozšíření- Výše ​​jsem psal, že vývojář nemizí a je připraven kdykoliv provést změny a doplňky dle vašich požadavků. Nesnažte se proto hned vytvořit CRM/ERP svých snů, nevyžadujte od prodejce tlačítko „Všechno funguje, když piju kávu“ – zapracujte v systému, identifikujte pro vás kritické komentáře a začněte shromažďovat požadavky a kreslit nahoru technické specifikace.

   O technických úkolech můžete psát donekonečna, toto je skutečný generátor nejen memů a příběhů, ale také bolestí hlavy. Můžete mluvit o prioritách a pravidlech designu, o GOST 1989, díky kterému jsou technické specifikace nehumánní, o standardech IEEE, které jsou o něco lepší, o prototypech a technických specifikacích, které je doplňují. Ale nakonec bych se rád omezil na jedno, nejdůležitější pravidlo: technická specifikace není právním řádem, není GOST a není dogma, takže pokud ji můžete zlepšit, vylepšete ji, pokud můžete zjednodušit to, zjednodušte to, pokud to umíte s grácií a tak, aby se to všem líbilo, udělejte to. Jsem si jistý, že poté už nikdo nebude strkat nos nad technickými specifikacemi a říkat, že to tam není napsáno. Nebo skoro nikdo.

   Po celý prosinec poskytujeme slevy na RegionSoft CRM a veškerý náš vlastní software. Od 1. prosince do 15. prosince - 15 % a strmé podmínky pro splátky a pronájmy. Nemáme -70 % a -90 %, protože držíme cenu za licence ekonomicky oprávněnou a netaháme ji z ničeho nic.

   Pokud potřebujete CRM systém (s úpravou nebo bez úpravy), přejděte na naše webové stránky, o CRM, jeho výhodách a dalším firemním softwaru je toho hodně.

   A ano, vždy hledáme partnery, kteří jsou připraveni prodávat CRM a další produkty, upravovat a prodávat CRM, prodávat software a školit uživatele. Rozdělení příjmů je spravedlivé a pro partnera výhodné. Ukážeme vám, řekneme vám, naučíme vás. Napsat [e-mail chráněný]

   Skluzavky, skluzavky. Komiksy převzaty z http://www.modernanalyst.com/ a Pinterestu. Pokud bude lepší překlad, rádi jej do příspěvku zařadíme.

Mnoho lidí se potýká s tím, že je poměrně těžké stručně a jasně vysvětlit, co v běžném životě chceme. A když potřebujete specialistovi zadat úkol napsat program pro organizaci nebo jednotlivého podnikatele s přihlédnutím k funkcím a vašim vlastním přáním o funkčnosti, můžete se úplně zaseknout.

Kdo by měl psát technické specifikace?