TECHNICKÁ ÚLOHA
PRE MODERNIZÁCIU STRÁNOK
Jekaterinburg
1. Dôvody pre rozvoj stránky. 3
1.1. Celé a krátke mená Informačný systém.. 3
1.2. Meno zákazníka systému a jeho údaje.. 3
1.3. Zoznam dokumentov, na základe ktorých je Systém vytvorený. 3
1.4. Plánované dátumy spustenia a dokončenia vytvorenia Systému.. 3
2. Systémové požiadavky. 4
2.1. Modernizácia oficiálnej webovej stránky vyšetrovacieho výboru pod prokuratúrou Ruská federácia(ďalej len Webová stránka SKP). 4
2.2. Hlavná stránka. 5
2.3. Typická vnútorná strana. 8
2.4. Požiadavky na modul odosielania noviniek. 9
2.5. Požiadavky na modul na generovanie a zobrazenie zoznamu dokladov. jedenásť
2.6. Zoznam požiadaviek na modul zobrazenia (katalóg) 11
2.7. Blog. 13
2.8. Fotogaléria. 16
2.9. Video prehrávač. 16
2.10. Tagy. 16
2.11. Požiadavky na modul na zber a analýzu údajov o štatistike návštevnosti webovej stránky 16
2.12. Požiadavky na modul vyhľadávania. 17
2.13. Požiadavky na modul "Úradné osoby". 18
2.14. Požiadavky na modul „Sitemap“. 20
2.15. Požiadavky na modul „Zhromažďovanie požiadaviek používateľov“. 20
2.16. Požiadavky na riadenie zdrojov.. 21
2.17. Požiadavky na technickú podporu.. 22
2.18. Požiadavky na unifikáciu a štandardizáciu. 22
2.19. Vypracovanie prevádzkovej dokumentácie. 22
2.20. Organizácia a vedenie odbornej prípravy pre špecialistov vyšetrovacieho výboru pod prokuratúrou Ruskej federácie. 23
3. Prsteň lokalít. 24
3.1. Všeobecné požiadavky. 24
3.2. Textová stránka. 25
3.3. Správy. 26
3.4. Otázky a odpovede.. 28
3.5. Archív súborov. 29
3.6. Formulár na vyzdvihnutie žiadosti. tridsať
3.7. Mapa lokality. tridsať
3.8. Požiadavky na mechanizmus vytvárania a odstraňovania stránok. 31
3.10. Požiadavky na dizajn. 31
3.11. požiadavky na jazykovú podporu. 31
3.12. Vývoj jednotnej softvérovej platformy pre webovú stránku SKP.. 31
3.13. Požiadavky na výsledky vykonanej práce. 32
1. Dôvody rozvoja Stránky
1.1. Úplný a krátky názov 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 "Site SKP", "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: Moskva, Technická ulička, 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. Plánované dátumy začatia a dokončenia vytvorenia Systému
Určené v súlade s Dohodou.
2. Systémové požiadavky
2.1. Modernizácia oficiálnej webovej stránky vyšetrovacieho výboru pod prokuratúrou Ruskej federácie (ďalej len „stránka UPC“)
V rámci modernizácie je potrebné vykonať:
· Redizajn hlavnej stránky Stránky UPC vrátane preskupenia existujúcich blokov na Hlavnej stránke;
· Vytvorenie samostatného bloku na Hlavnej stránke „Vyjadrenia predstaviteľov orgánov a médií k práci vyšetrovacieho výboru“. Sekcia by mala byť realizovaná ako datovaný zoznam s možnosťou pripojenia obrázkov;
Nastavenie predvolených písiem ponúkaných systémom pre rôzne druhy text: pre nadpisy a hlavný text;
· Implementácia možnosti nahradenia grafických prvkov zodpovedajúcim textom (v prípade vypnutej možnosti načítavania obrázkov na strane užívateľa);
· Optimalizácia stránok Stránky UPC z hľadiska množstva dát;
· Prispôsobenie Webovej stránky UPC novému dizajnu;
· Optimalizácia zabezpečenia kódu s cieľom zabrániť možným vonkajším útokom;
Aktualizované hlavné menu vrátane nasledujúcich zmien:
Vytvorte sekciu „O vyšetrovacom výbore“;
Táto sekcia by mala byť samostatnou stránkou UPC Stránky s možnosťou umiestniť formátovaný text a obrázky.
Vytvorte sekciu "Blog predsedu";
V častiach s veľkým množstvom textu („Rozhovory“, „Publikácie“ a „Regulačný rámec“) usporiadajte informácie podľa rokov.
Štruktúra sídla centrály
· Domov
O komisii (textová stránka)
Manuál (modul "Katalóg")
Ø Zoznam manažérov (podsekcia katalógu)
o Oficiálny popis (textová stránka)
Štruktúra (textová stránka)
Normatívny základ (textová stránka)
Novinky (modul „Novinky“)
Ø Zoznam noviniek (podsekcia)
o Popis noviniek (textová stránka)
· Právne informácie (textová stránka)
Služba v systéme (textová stránka)
Boj proti korupcii (modul "Katalóg")
Ø Udalosti a dokumenty
o Zoznam podujatí (podsekcia)
§ Popis udalosti (textová stránka)
Ø Vyšetrovanie trestných činov korupcie
o Zoznam podujatí (podsekcia)
§ Popis udalosti (textová stránka)
Blog (modul "Blog")
Verzia pre zrakovo postihnutých (modul „Verzia pre zrakovo postihnutých“)
Postup pri posudzovaní odvolaní a prijímaní občanov (textová stránka)
· Vyšetrovacie orgány k témam Ruskej federácie (textová stránka)
Tlačené publikácie (modul "Katalóg")
Ø Vestník UPC č. 4 (podsekcia)
Ø Vestník UPC č. 3 (podsekcia)
o Popis čísla (textová stránka)
Médiá o vyšetrovacom výbore (modul „Správy“)
Ø Zoznam publikácií (podsekcia)
o Popis publikácie (textová stránka)
Interakcia s médiami (modul "Katalóg")
Ø Zoznam podsekcií (katalógová podsekcia)
o Popis podsekcie (textová stránka)
Rozhovor (modul "Novinky")
Ø Zoznam rozhovorov (podsekcia)
o Popis rozhovoru (textová stránka)
Sitemap (modul "Sitemap")
2.2. Hlavná stránka
Okrem prvkov identifikácie a dizajnu by hlavná stránka webu mala obsahovať tieto prvky:
· Hlavné menu
Hlavné menu webu je stálym prvkom každej stránky webu. Menu by malo obsahovať nasledujúce odkazy:
ü O výbore
ü Vedenie
ü Štruktúra
ü Regulačný rámec
ü Správy
ü Právne informácie
ü Servis v systéme
ü Boj proti korupcii
Mriežka hlavnej stránky je znázornená na obr. 1.
Aktuálny" v administračnom systéme, to znamená, že ak je tento príznak zaškrtnutý, novinky sa umiestnia do bloku "Aktuálne" a zostanú tam, kým tento príznak neodstránite.
· Blok „Vyhlásenia predstaviteľov úradov a médií“- mal by to byť datovaný zoznam s úplným menom zástupcu úradov alebo médií, jeho postavením, imidžom a citátom.
· Banner- musí ísť o flashový alebo fotografický obrázok, ktorý po kliknutí vedie na stránku alebo sekciu špecifikovanú v redakčnom systéme.
· Blok „Vyšetrovacie orgány v subjektoch Ruskej federácie“- musí to byť flashový obrázok mapy Ruska s rozdelením na federálne okresy. Keď kliknete na konkrétny okres, mal by prejsť na stránku s textovým popisom tohto okresu.
· Blokovať „Blog predsedu“- mal by byť zoznam posledných troch tém vytvorených na blogu vo forme názvu témy a dátumu zverejnenia. Názov témy bude odkaz, po kliknutí by ste sa mali dostať na stránku blogu s popisom tejto témy. Tento blok by mal obsahovať aj video, ktoré je možné prehrať bez opustenia domovskej stránke. Video musí mať odkaz "Komentáre", čo je počet komentárov k videu. Odkaz "Komentáre" by mal viesť na stránku blogu s komentármi k odoslanému videu.
- päta
Päta by mala obsahovať vyhľadávacie pole, informácie o autorských právach atď.
2.3. Typická vnútorná strana
Mriežka typickej vnútornej strany je znázornená na obr. 2
Ryža. 2. Typická vnútorná strana.
Účel:
Typickou vnútornou stránkou by mal byť textový dokument s názvom a popisom niečoho. Mal by obsahovať fotografie a videá, ako aj prílohy na stiahnutie.
2.4. Požiadavky na modul odosielania noviniek
Modul umiestňovania správ by mal poskytovať:
umiestňovanie správ na internetových stránkach publikovaných v chronologickom poradí (správy);
výstup na stránky internetových stránok zoznam noviniek a ich plné texty;
hľadať v archíve správ;
· Export správ vo formáte RSS 2.0.
Na prácu s prvkami informačného kanála správ by mal byť k dispozícii editor HTML, ktorý používateľom umožňuje pridávať a upravovať správy správ od používateľov, ktorí neovládajú špecializované programovacie jazyky.
Modul by mal byť dvojvrstvovej architektúry, prezentovaný ako zoznam všetkých noviniek a popis každej novinky.
Zoznam noviniek uvádzajte ako názov novinky a dátum jej zverejnenia (obr. 3)
https://pandia.ru/text/78/390/images/image005_109.jpg" width="646" height="525 src=">
Ryža. 4. Grid page "popis noviniek".
2.5. Požiadavky na modul na generovanie a zobrazenie zoznamu dokladov
Modul na generovanie a zobrazenie zoznamu dokumentov by mal umožňovať:
Organizovať zverejňovanie dokumentov na stránkach lokality vo forme zoznamu s možnosťou stránkovania a triedenia podľa dátumu zverejnenia;
správca a správca obsahu internetových stránok, aby:
o zobraziť zoznam dokumentov,
o pridávať nové dokumenty,
o upravovať a mazať pridané dokumenty.
2.6. Zoznam požiadaviek na modul zobrazenia (katalóg)
Modul zobrazenia zoznamu by mal poskytovať:
zobrazovanie formátovaných zoznamov na stránkach internetových stránok (zoznam voľných pracovných miest, zoznam pobočiek, zoznam často kladených otázok a odpovedí na ne atď.) vo forme zoznamu odkazov na stránky prvkov zoznamu;
Poskytovanie správcom a správcom obsahu internetových stránok s nasledujúcimi funkciami:
o upravovať, pridávať a odstraňovať položky zoznamu;
o vytvárať nové zoznamy prvkov;
o vymazať existujúce zoznamy.
Modul by mal byť viacúrovňovou architektúrou s rozvetvenou štruktúrou. Hlavná časť katalógu by mala obsahovať podsekcie prezentované ako zoznam tém (obr. 5)
Ryža. 5. Adresár podsekcie mriežky.
Po kliknutí na názov jednej z podsekcií by sa mal otvoriť popis tejto podsekcie vo forme internej normostrany.
Mriežka popisu podsekcie je znázornená na obr. 6
https://pandia.ru/text/78/390/images/image008_83.jpg" width="625" height="526">
Ryža. 7. Grid page "zoznam tém v blogu."
Kliknutím na jednu z tém by sa mala otvoriť stránka s úplným popisom témy a komentármi k nej (obr. 8)
2.8. Fotogaléria
Pomocou tohto modulu by sa na stránky webu mali umiestňovať obrázky, vygenerovať zoznam obrázkov, pri kliknutí na obrázok sa obrázok zväčší.
2.9. Video prehrávač
Pomocou tohto modulu by sa video obrázky mali umiestniť na stránky webu, keď kliknete na obrázok videa, video by sa malo zobraziť.
2.10. Tagy
Mechanizmus štítkov by mal byť navrhnutý tak, aby prepájal všetky správy, rozhovory a iné materiály stránok prostredníctvom štítkov. To znamená, že rôzne materiály na stránke by mali byť schopné patriť k jednému spoločnému prvku.
2.11. Požiadavky na modul na zber a analýzu údajov o štatistikách návštevnosti webových stránok
Modul na zber a analýzu údajov o štatistikách návštevnosti internetovej stránky by mal zabezpečiť zber a zobrazovanie správcom internetových stránok o návštevnosti internetových stránok užívateľmi a dynamike zmien návštevnosti. Musia byť implementované nasledujúce funkcie modulu:
vedenie evidencie štatistík online a práca s údajmi priamo na stránke;
· vykonávanie zberu a výpočtu štatistických údajov, keď návštevník otvorí každú stránku bez umiestnenia tlačidiel, obrázkov alebo dodatočného programového kódu do tela stránky;
Pridelenie tokov návštevníkov podľa jedného z kritérií:
o zoznam odkazujúcich stránok;
o vyhľadávač;
o stránky, na ktoré prišli;
o Extra možnosti: krajina, používateľ, sieť IP a iné.
· analýza ciest naprieč webom s možnosťou vybrať si obdobie analýzy, počet stránok na ceste, prvá stránka cesty, posledná stránka cesty, ľubovoľná stránka cesty a ďalšie parametre vzorkovania údajov s pokročilý filter;
· Analýza návštevnosti sekcií a stránok s možnosťou výberu obdobia analýzy, sekcií a iných parametrov vzorkovania údajov s pokročilým filtrom;
analýza vstupných bodov do lokality s možnosťou výberu obdobia pre analýzu, úsek a ďalšie parametre vzorkovania údajov s pokročilým filtrom;
· analýza návštevnosti stránky na všeobecnom grafe podľa dňa s prezentáciou údajov: prístupy, relácie, návštevníci, hostitelia, noví návštevníci, udalosti, obľúbené položky;
Analýza súhrnnej štatistiky stránky, ktorá predstavuje údaje za minulé obdobia nasledujúcich typov:
o udalosti;
o návštevníci (noví, celkom, obľúbení, online);
o 10 najaktívnejších typov udalostí na stránke;
o 10 najlepších odkazujúcich stránok;
o Top 10 najpopulárnejších vyhľadávacích fráz súčasnosti;
o Top 10 najaktívnejších webových prehľadávačov dňa.
analýza odkazujúcich stránok; schopnosť analyzovať dynamiku počas dňa; účtovanie pre vstavaný vyhľadávací modul ako vyhľadávací nástroj so všetkými analytickými nástrojmi;
· automatické určovanie požiadaviek vyhľadávačov a robotov na doplnenie tabuľky vyhľadávačov;
analýza dynamiky udalostí podľa dňa a prezentácia výsledkov vo forme koláčového grafu;
· Analýza dynamiky udalostí podľa dňa a prezentácia vo forme grafu typov udalostí.
2.12. Požiadavky na modul vyhľadávania
Vyhľadávací modul by mal poskytovať vyhľadávanie stránok internetových stránok, ktoré obsahujú užívateľom špecifikované stránky Kľúčové slová. Musia byť implementované nasledujúce funkcie:
· Vykonanie vyhľadávania na vybranej internetovej stránke a na okruhu stránok, berúc do úvahy ruskú morfológiu;
súčasné vyhľadávanie v statickom obsahu stránky a dynamických informáciách (správy, články, fotografie)
použitie dopytovacieho jazyka pri vytváraní vyhľadávacieho dopytu;
· používanie logické operátory pre zložité vyhľadávacie dopyty;
· automatické indexovanie všetkých dokumentov stránok, ktoré sú publikované cez webové rozhranie vo forme statických HTML stránok alebo prostredníctvom modulov informačných blokov;
triedenie výsledkov vyhľadávania.
2.13. Požiadavky na modul "Úradné osoby".
Modul „úradníci“ by mal poskytovať:
· vedenie zoznamu úradníkov vyšetrovacích orgánov pre zakladajúce subjekty Ruskej federácie (úroveň vedúceho a zástupcov vedúceho územného orgánu vyšetrovacieho výboru pri prokuratúre Ruskej federácie).
uchovávanie informácií o vedení vyšetrovacích orgánov v zakladajúcich subjektoch Ruskej federácie, ktoré pozostávajú z:
o pozíciu,
o fotografovanie,
o životopis,
o datovaný zoznam (páska) publikácií a prejavov.
Modul by mal byť hierarchickou štruktúrou podriadenosti úradníkov (obr. 9)
https://pandia.ru/text/78/390/images/image011_72.jpg" width="646" height="614 src=">
Ryža. 10. Grid page "popis úradníka".
2.14. Požiadavky na modul „Sitemap“.
2.15. Požiadavky na modul „Zhromažďovanie požiadaviek používateľov“
Modul by mal poskytovať funkcie na zhromažďovanie žiadostí od občanov Ruskej federácie pomocou špecializovaného formulára zverejneného na webových stránkach vyšetrovacích orgánov:
zaslanie výsledkov vyplnenia formulára e-mailom zodpovednému pracovníkovi;
· Ukladanie údajov formulára do databázy;
· Zabezpečenie ochrany pred automatickým vypĺňaním formulára zadaním kontrolného grafického kódu.
Mriežka stránky s formulárom žiadosti používateľa je znázornená na obr. jedenásť
Ryža. 11. Grid page "kontaktný formulár".
Stránka by mala byť formulár s poliami na vyplnenie „Meno“, „E-mail“, „Telefónne číslo“, „Adresa“ a „Text správy“. Pri vypĺňaní týchto polí bezpečnostný kód a stlačením tlačidla odoslať by sa informácie mali odoslať do databázy a zodpovedajúci list by sa mal poslať na e-mail zamestnanca zodpovedného za prijímanie žiadostí. Potom by sa na obrazovke v tom istom okne malo používateľovi zobraziť číslo aplikácie, ktorú odoslal.
2.16. požiadavky na riadenie zdrojov
Na správu obsahu internetových stránok, sekcií, menu a prístupových práv by sa mal využívať jednotný systém správy obsahu (CMS) prostredníctvom vývoja existujúcej platformy vyvinutej v rámci vytvárania oficiálnej webovej stránky Vyšetrovací výbor pri prokuratúre Ruskej federácie, ktorý poskytuje tieto funkcie:
· Jednotné rozhranie pre správu a správu obsahu internetových stránok;
· Úprava obsahu sekcií a stránok vybraného webu pomocou grafického editora;
· Správa sekcií menu vybranej internetovej stránky;
· Správa štruktúry vybranej webovej stránky;
Udržiavanie interaktívnej mapy sekcií internetových stránok;
· Umiestnenie správ s jasným časovým odkazom;
· Vedenie archívu spravodajských správ s možnosťou vyhľadávania podľa dátumu zverejnenia všetkých internetových stránok;
Vyhľadávanie informácií na internetových stránkach;
· Zverejňovanie dokumentov na internetových stránkach;
· Miestnosť na školenie poskytuje objednávateľ.
· Miesto a čas školenia je potrebné dohodnúť so zákazníkom.
Školenie by sa malo vykonávať o všetkých funkciách 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. Site ring
Všetky funkcionality systému musia byť implementované v rámci samostatných programových modulov prostredníctvom rozvoja existujúcej platformy Stránky UPC. Spoločné fungovanie rôznych modulov internetových stránok by malo zabezpečovať jadro softvérového komponentu „Ring of Sites“. Moduly, ktoré poskytujú špecifikovanú funkcionalitu, musia byť pripojené samostatne pre každú z internetových lokalít zahrnutých v okruhu lokalít. Všetky softvérové moduly, ktoré implementujú služby internetových stránok, by mali využívať všeobecné princípy fungovania bez ohľadu na stránku zaradenú do okruhu stránok.
Softvérové komponenty internetovej stránky vyšetrovacieho výboru pod prokuratúrou Ruskej federácie by sa mali používať ako jadro softvérového komponentu „Ring of Sites“.
3.1. Všeobecné požiadavky
Vytvorený systém musí spĺňať nasledujúce požiadavky:
· Okruh stránok by mal zabezpečiť súčasné nepretržité fungovanie internetových stránok vyšetrovacích orgánov Vyšetrovacieho výboru pri prokuratúre Ruskej federácie pre zakladajúce subjekty Ruskej federácie;
Okruh lokalít by mal byť zostavený podľa schémy interakcie klient-server tenkého klienta. Webové stránky uložené a generované na strane servera sa musia stiahnuť cez internet do počítačov koncových používateľov;
· Návrh a vývoj softvéru Site Ring by sa mal vykonávať s využitím princípov a prístupov modulárnej architektúry softvérových riešení;
Internetové stránky musia poskytovať prístup informačné zdroje vyšetrovacie orgány v zakladajúcich subjektoch Ruskej federácie a možnosť umiestňovať regionálne referenčné informačné materiály;
· softvér Okruhy stránok by mali poskytovať centralizovanú správu obsahu internetových stránok vyšetrovacích orgánov pomocou grafického rozhrania, ktoré nevyžaduje od používateľov znalosť špecializovaných programovacích jazykov.
Internetové stránky by mali obsahovať nasledujúce typy informačných stránok:
textové stránky;
spravodajstvo;
· Otázky a odpovede;
archív súborov;
Formuláre na zhromažďovanie odvolaní;
· Mapa stránok.
3.2. textová stránka
Mriežka typickej textovej stránky je znázornená na obr. 12
Ryža. 12. Mriežka typickej internej textovej stránky.
Typická textová stránka by mala obsahovať nadpis, obrázok a textový popis. Tiež by malo byť možné vkladať súbory na stiahnutie.
3.3. Správy
Mriežka stránky noviniek je znázornená na obr. 13
Ryža. 13. Grid page "news feed".
Zoznam noviniek by mal byť zostavený v chronologickom poradí a mal by obsahovať informácie o dátume uverejnenia a názve novinky.
Po kliknutí na názov jednej z noviniek by sa mala otvoriť stránka s úplným popisom novinky (obr. 14)
Ryža. 14. Mriežková stránka "Popis noviniek".
Táto stránka by mala obsahovať názov správy, obrázok, textový popis, ako aj video, ktoré by sa malo prehrať v rovnakom okne bez opätovného načítania stránky.
3.4. Otázky a odpovede
Mriežka stránky „otázky a odpovede“ je znázornená na obr. 15
Ryža. 15. Mriežka stránok otázok a odpovedí.
Stránka by mala obsahovať zoznam otázok. Keď kliknete na názov otázky, hneď pod ňou by sa mal otvoriť formulár s odpoveďou bez opätovného načítania stránky.
3.5. Archív súborov
Mala by to byť stránka so zoznamom súborov na stiahnutie. Po kliknutí na názov súboru by sa mal súbor automaticky stiahnuť bez opätovného načítania stránky (obr. 16)
https://pandia.ru/text/78/390/images/image018_31.jpg" width="646" height="505">
Ryža. 17. Mriežková stránka "Kontaktný formulár".
3.7. Mapa stránok
Modul "Mapa stránky" by mal zobrazovať informácie o štruktúre sekcií vybranej webovej stránky.
Názvy sekcií webovej stránky by sa mali zobrazovať ako zoznam odkazov na príslušnú sekciu. Kliknutím na odkazy musí byť používateľovi poskytnutá možnosť navigácie na vybranej webovej stránke.
3.8. Požiadavky na mechanizmus vytvárania a odstraňovania stránok
V rámci vývoja existujúcej softvérovej platformy pre internetovú stránku Vyšetrovacieho výboru pri Prokuratúre Ruskej federácie je potrebné vyvinúť mechanizmus, ktorý umožní pridávanie nových a mazanie existujúcich internetových stránok Site Ring na základe jednotný vzor dohodnutý so zákazníkom. Vytváranie a odstraňovanie internetových stránok by sa malo vykonávať bez použitia programovacích jazykov. Tento mechanizmus by mal poskytovať možnosť vytvorenia oboch stránok s doménové meno tretej úrovne a stránky s názvom domény druhej úrovne.
3.9. Požiadavky na informačnú podporu
V rámci vytvárania okruhu stránok by mala byť jedna pilotná internetová stránka na začiatku naplnená informačnými materiálmi, ktoré poskytne zákazník.
3.10. Požiadavky na dizajn
Pre internetové stránky zahrnuté do okruhu stránok by sa mal vytvoriť jednotný dizajn stránok a ovládacích prvkov, ktorý zodpovedá štýlu a farebnej schéme internetovej stránky Vyšetrovacieho výboru pod prokuratúrou Ruskej federácie. Dizajn musí byť dohodnutý so zákazníkom a za predpokladu, že web patrí príslušnému subjektu Ruskej federácie.
Dizajn webových stránok musí spĺňať moderné požiadavky na dizajn webových stránok. Farebnú schému site ring je potrebné dohodnúť so Zákazníkom v rámci tvorby systému.
Dizajn internetových stránok kruhu stránok musí spĺňať tieto štýlové charakteristiky: prísny, vecný, stručný, ergonomický, informatívny.
3.11. Požiadavky na jazykovú podporu
Rozhrania kruhových stránok musia byť v ruštine a angličtine. Administratívne rozhrania krúžku lokality by sa mali robiť iba v ruštine.
3.12. Vývoj jednotnej softvérovej platformy pre webovú stránku UPC
V rámci vývoja je potrebné vykonať:
· Informačný obsah jednej pilotnej lokality okruhu lokalít v množstve dostatočnom na otestovanie celej funkčnosti Systému, čo by malo byť vykonané v rámci školenia;
· Vykonávanie skúšobnej prevádzky;
· Uvedenie do prevádzky.
3.13. Požiadavky na výsledky vykonanej práce
1. softvérové nástroje Ring of Sites vyšetrovacieho výboru pri prokuratúre Ruskej federácie
2. prevádzková dokumentácia v tomto zložení:
· Program a skúšobná metóda;
· Príručka správcu;
· Príručka správcu obsahu;
· Návod na inštaláciu;
· Príručka programátora.
Oznamovacie materiály musia byť poskytnuté v dvoch kópiách. Softvér sa poskytuje iba na elektronických médiách v jednej kópii.
Priamo závisí od toho, ako presne sú vypracované referenčné podmienky na dokončenie 1C, či sa vyriešia úlohy pridelené vývojárom. Pri práci s takýmto dokumentom však existujú určité ťažkosti. V širšom zmysle TOR predpisuje normy pre vytváranie a modernizáciu automatizovaného systému (AS), ako aj postup práce. To zahŕňa aj súbor štandardov na spustenie projektu. Toto chápanie úlohy zadávacích podmienok je diktované požiadavkami GOST 19.201-78 a 34.602-89, podľa ktorých sa vyvíja TOR pre 1C. Existuje ďalší výklad významu tohto dokumentu, bližšie k praxi.
Podľa inej definície je referenčný rámec pre dokončenie 1C dokument, ktorý upravuje účel a parametre budúci systém, ako aj proces vypracovania dokumentácie a jej zoznamu. Táto interpretácia umožňuje zohľadniť záujmy programátorov a zákazníka.
Aká by mala byť TK?
Akúkoľvek technickú úlohu pre vývoj programu 1C vytvára dodávateľ. Ale toto nie je programátor, ale analytik. Toto je dôležitý bod, pretože dokument musí byť napísaný v jazyku zrozumiteľnom pre klienta, bez vysoko špecializovaných technické výrazy. Keď sa zohľadnia všetky nuansy projektu a informácie sú formulované správne, TOR sa dohodne so všetkými zákazníkmi. Ak je prijatý, programátori sú zapojení do práce. Zároveň by mal byť v dokumente jasne uvedený požadovaný výsledok. To pomáha vývojárom nastaviť si správny cieľ a kontrolovať ho v rôznych fázach. Tiež veľká pozornosť pri zostavovaní podmienok pre revíziu 1C stojí za to venovať pozornosť zneniu. Je potrebné dbať na to, aby boli dostatočne špecifické a neznamenali iné interpretácie. Toto je prvá vec, ktorú si treba pamätať pri práci s TK. K dizajnu treba pristupovať aj zodpovedne. To platí aj pre titulnú stranu dokumentu.
Hlavné chyby v podmienkach vývoja 1C
Štruktúru zadávacích podmienok upravuje GOST 34.602-89. Tento dokument obsahuje jasné požiadavky na počet a postupnosť blokov informácií v TOR. Zároveň neexistujú prísne normy pre spôsoby prezentácie. Táto situácia obsahuje veľký potenciál na riešenie zložitých problémov a zároveň môže viesť k mnohým chybám pri príprave dokumentu. Najčastejšie nepresnosti sú:
- Opakovanie niektorých častí v rôznych interpretáciách.
- Informácie sú podávané náhodne. V ideálnom prípade by sa mal vzťahovať na špecifickú štruktúru, ako sú obchodné procesy alebo systémové moduly.
- Informácie v rôznych častiach sú prezentované s rôznym stupňom podrobností.
To všetko bráni zákazníkovi pochopiť informácie, ktoré sú uvedené v TOR. To komplikuje proces spolupráce, čím je časovo náročnejšia.
Po zhliadnutí zákazníkom sa vzorový TOR pre revíziu 1C môže zmeniť a nie vždy k lepšiemu. To zase zvyčajne bráni programátorom správne vnímať informácie. To platí najmä pre špecialistov s malými skúsenosťami. V tejto fáze sa často vyskytujú tieto chyby:
- Požiadavky rôznych sekcií si navzájom odporujú.
- Vzorce sú nepresné.
- Na niektorých miestach sú informácie príliš podrobné.
Zbaviť sa všetkých týchto chýb je jednoduché. Je potrebné zamerať sa predovšetkým na výsledok a nie na starostlivé predpisovanie formulácií. Je potrebné pripomenúť, že TOR popisuje funkčnosť projektu, jeho hlavné parametre a účel.
Ako sa vyhnúť chybám pri vývoji technických špecifikácií?
Hlavným pravidlom, ktoré platí pre všetky nasledujúce odporúčania, je, že znenie by malo byť konkrétne. Ak to chcete urobiť, musíte použiť odkazy na GOST, iné regulačné dokumenty. To umožňuje zhotoviteľovi a objednávateľovi vnímať informácie rovnakým spôsobom.
Príklad technickej úlohy na dokončenie 1C zahŕňa použitie jazyka obchodného odvetvia, pre ktoré sa projekt realizuje. To je potrebné predovšetkým pre zákazníka. Zároveň by ste v texte nemali používať žiadne prirovnania, pretože ich možno interpretovať rôznymi spôsobmi.
Základné pravidlá pri zostavovaní referenčných podmienok pre vypracovanie správy a ďalších prvkov 1C:
- CK vytvárajú spoločne zhotoviteľ a objednávateľ.
- Na prácu programátorov by mali byť predložené len objektívne požiadavky. Pre úspešný vývoj projektu musí byť subjektívna vízia zákazníka obmedzená na minimum.
- Je potrebné podrobne popísať výsledok, ktorý zákazník potrebuje. Zároveň je v príklade zadávacích podmienok pre vývoj konfigurácie 1C potrebné predpísať všetky parametre, podľa ktorých by mal prvok fungovať. V opačnom prípade sa výsledok môže veľmi líšiť od požadovaného.
- Riziká zhotoviteľa a objednávateľa by mali byť približne rovnaké a minimalizované.
- Nemôžete používať výrazy, ktoré sa používajú v obchodnej komunikácii a nepoužívajú sa v určitom odvetví.
Na vytvorenie TOR na vývoj správy v 1C alebo inom prvku musí analytik poznať všetky vlastnosti oblasti činnosti zákazníka. V požiadavkách musíte uviesť iba užitočná informácia užitočné pre účinkujúceho. Vzhľadom na to, že sa tu venuje osobitná pozornosť konečným úlohám, ktoré musí softvér vyriešiť, neexistuje jediný príklad technickej úlohy.
Nebezpečenstvo nesprávnej prípravy TOR
Vyššie uvedené chyby môžu viesť k zvýšeniu času potrebného na vytvorenie systému. To so sebou prináša zbytočné náklady a nespokojnosť. Technická úloha na vývoj databázy alebo inej konfigurácie 1C by mali robiť skúsení špecialisti. Úžitok všetkých účastníkov závisí od toho, ako je tento dokument zrozumiteľný. Zákazník dostane efektívny automatizovaný systém na riešenie obchodných problémov. Zároveň má zhotoviteľ ďalšieho spokojného klienta. Majitelia podnikov musia byť pri výbere partnerských spoločností 1C čo najopatrnejší, pretože efektívnosť organizácie do značnej miery závisí od toho, ako dobre sú vypracované referenčné podmienky na revíziu.
Naši odborníci pomohli zákazníkovi vytvoriť Referenčné podmienky pre modernizáciu ventilačného systému.
Viac detailov pod strihom..
Technická úloha
na modernizáciu technologického zariadenia ventilačných systémov laboratórnej budovy č. 451 452, budova 17 na adrese: Moskva
1. Všeobecné ustanovenia
1.1. Tento zadávací poriadok zabezpečuje realizáciu prác na modernizácii technologických zariadení, riadiacich systémov a automatizácie vetracích jednotiek budovy, laboratória č.451,452 budovy 17.
1.2. Pre výkon prác vypracovať pracovnú dokumentáciu pre úseky značiek AOV, EM, KhS, AHS, AK, ktorá by mala byť dohodnutá predpísaným spôsobom.
1.3. Vykonávať prácu v súlade s požiadavkami regulačnej a technickej dokumentácie.
1.4. Po dokončení práce predložte dokumentáciu skutočného stavu vyhotovenú v súlade s požiadavkami GOST a SNiP.
1.5. Hotové dielo odovzdajte klientovi.
1.6. Niektoré ustanovenia týchto zadávacích podmienok môžu byť špecifikované v procese práce po dohode so zákazníkom.
2. Technické požiadavky
2.1. Modernizácia riadiacich jednotiek pre zásobovanie teplom a chladom vetracích jednotiek.
2.1.1. Uzly regulácie dodávky tepla.
Modernizácia podlieha:
· riadiace jednotky dodávky tepla pre prvé vykurovanie vetracích jednotiek K1, K2, K2a, K4 budov MIK-V, P2, P6 laboratória č. 452, P1 laboratória.
· riadiace jednotky dodávky tepla pre druhé vykurovanie vetracích jednotiek K1, K2, K2a objektu MIK-V.
Existujúce riadiace jednotky dodávky tepla podliehajú demontáži, pričom niektoré zariadenia riadiacich jednotiek (obehové čerpadlá, uzatváracie armatúry), zodpovedajúce stavu resp. Technické špecifikácie, sa používa v namontovaných riadiacich jednotkách.
Zloženie výbavy montovaných riadiacich jednotiek, ako aj použitá výbava je uvedená v prílohe č.1.
Vykonajte hydraulické skúšky vykurovacích okruhov a ohrievačov vetracích jednotiek s vyhotovením protokolu o hydraulickej skúške.
Vykonávať nátery potrubí a zatepľovacie práce.
2.1.2 Uzly na reguláciu prívodu chladu do ventilačných jednotiek.
Chladiace jednotky pre vetracie jednotky K1, K2, K2a, K4 budov MIK-V, P2, P6 laboratória „452, P1 laboratória č. 451 sú predmetom modernizácie.
Rozsah prác:
· výmena termostatických ventilov riadiacich jednotiek chladenia;
Demontáž/inštalácia ventilátora kompresorovo-kondenzačnej jednotky K1;
· demontáž/inštalácia filtrov-sušičov kompresorovo-kondenzačných jednotiek K1, K2;
Demontáž/inštalácia výparníka ventilačnej jednotky K4;
· tlaková skúška v prostredí inertného plynu, vysávanie, dopĺňanie chladiacich okruhov freónom;
Obnova tepelnej izolácie potrubí.
2.1.3. Napájacie jednotky pre zvlhčovacie okruhy.
Nainštalujte filtre na čistenie studenej vody na napájacie jednotky zavlažovacích komôr klimatizačných zariadení K1, K2, K2a.
2.2. Skrine na riadenie a automatizáciu ventilačných zariadení.
Ovládacie skrine pre vetracie jednotky K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 laboratória MIK-V, P2, P6, V1, V2, V3 č. 451, P1, V1 laboratórium č. 452.
Rozloženie novo nainštalovaných ovládacích panelov:
SHUA K1 - riadiaca skriňa a automatizácia ventilačnej jednotky a kompresorovej a kondenzačnej jednotky (KKB) klimatizácie K1 (MIK-V);
SHUA K2 - ovládacia skriňa a automatizácia ventilačnej jednotky a KKB klimatizácie K2 (MIK-V);
SHUA K2 - ovládacia skriňa a automatizácia ventilačnej jednotky a KKB klimatizácie K2a (MIK-V);
SHUA K4 - ovládacia skriňa a automatizácia ventilačnej jednotky a KKB klimatizácie K4 (MIK-V);
SHUV - ovládacia skriňa pre výfukové jednotky RU3, V1, V2, V3, V6, V7, V8 (MIK-V);
ShUA P2, P6 - riadiaca skriňa a automatizácia ventilačných jednotiek a kompresorových a kondenzačných jednotiek P2, P6 (laboratórium č. 452);
SHUV - ovládacia skriňa pre odsávacie jednotky V1, V2, V3 (laboratórium č. 452);
SHUA P1, V1 - rozvádzač a automatizácia ventilačných jednotiek P1, V1 (laboratórium č. 451).
Modernizované riadiace skrine by mali poskytovať:
výber režimu ovládania ventilačnej jednotky (manuálny/automatický) na prednom paneli skrine;
· svetelná signalizácia pravidelných a núdzových režimov prevádzky technologických zariadení vetracích jednotiek (prevádzka/havária);
vypnutie ventilačných systémov v prípade požiaru;
automatickú činnosť ochrán a blokovanie chodu zariadení v prípade mimoriadnych udalostí.
Ďalej sa majú využívať frekvenčné meniče na riadenie elektromotorov ventilátorov a čerpadiel.
2.3. Automatizačný a dispečerský systém
Automatizačný a dispečerský systém je určený na riadenie a riadenie prevádzky ventilačných jednotiek, ako aj na zber, spracovanie, prezentáciu a ukladanie prichádzajúcich informácií.
2.3.1. Automatizačný systém.
Automatizačný systém by mal vo všeobecnosti zabezpečiť autonómnu prevádzku vetracích jednotiek, ktorá si nevyžaduje zásah personálu údržby a prechod v prípade potreby na manuálny mód zvládanie. Pri akýchkoľvek možnostiach ovládania a bez ohľadu na stav lokálneho ovládača musí byť stav zachovaný automatické vypnutie všeobecné ventilačné systémy v prípade požiaru. Vypnutie musí byť vykonané individuálne pre každý systém pri zachovaní napájania protimrazových okruhov.
Miestna automatizácia ventilačných systémov by mala zahŕňať:
regulácia teploty privádzaného vzduchu na výstupe z vetracej jednotky alebo v prípade potreby teploty odvádzaného vzduchu z obsluhovaných priestorov;
regulácia vlhkosti privádzaného vzduchu;
zastavte ventilátory a zatvorte vzduchové ventily, keď sa spustí požiarny poplach;
Vypnutie zvlhčovania klimatizácie, keď sa zastaví jej ventilátor;
Otvorenie a zatvorenie vzduchového ventilu pri spustení a zastavení ventilátora;
· automatické zahrievanie ohrievačov pred spustením systémov v zimnom režime;
· ochrana proti zamrznutiu ohrievačov vzduchom a vodou (vypnutie ventilátora, zatvorenie vzduchovej klapky, otvorenie ventilu kúrenia na 100%);
vypnutie ventilátora pri absencii tlakového rozdielu;
· kontrola znečistenia filtrov zariadení.
Vzdialený vplyv na lokálnu automatizáciu s pracovnými stanicami je určený v nasledujúcom zväzku:
· zmena nastavení regulátorov teploty a vlhkosti;
· povoliť/zakázať nastavenia.
Existujúce periférne zariadenia automatizačného systému podliehajú overovaniu, čisteniu a ďalšiemu používaniu v nasledujúcom poradí:
· snímače teploty a vlhkosti vetracích jednotiek podliehajú overeniu;
· Snímače diferenčného tlaku je potrebné skontrolovať, vyčistiť;
· Termostaty na ochranu ohrievačov vzduchu pred zamrznutím musia byť vymenené.
· Pohony regulačných ventilov riadiacich jednotiek musia byť vymenené v súlade s bodom 2.1.1.
pohony vzduchových ventilov podliehajú kontrole a ďalšiemu používaniu;
Na ovládanie recirkulácie klimatizácie K1 vymeňte zapínacie a vypínacie ovládače vzduchových ventilov za ventily s riadiacim signálom 0..10V.
2.3.2. dispečerský systém.
Zahrňte do expedičného systému nasledujúce komponenty:
komplex meracích zariadení, akčných členov a automatizačných nástrojov na báze softvérových a hardvérových nástrojov „Honeywell“;
· multifunkčný káblový systém;
· komplex softvérových a hardvérových prostriedkov dispečingu.
Pre dispečerské ventilačné systémy zabezpečte zobrazenie, archiváciu a protokolovanie nasledujúcich informácií:
· grafické znázornenie inštalácií so snímačmi teploty a vlhkosti, protimrazovými termostatmi, diferenčnými tlakovými spínačmi, regulačnými ventilmi, zvlhčovačmi vzduchu, vzduchovými ventilmi;
čísla inštalácie;
údaje snímačov teploty a vlhkosti;
čítanie snímačov relé diferenčného tlaku;
indikácie polohy regulačných ventilov 0..100%;
režim prevádzky ventilátora/stop;
· "pracovný / stop" režim čerpadiel;
poloha vzduchových ventilov "otvorené / zatvorené";
zastaviť systémy pri spustení požiarneho poplachu;
vypnutie systémov, keď hrozí zamrznutie ohrievača;
vypnutie jednotky pri absencii poklesu tlaku na ventilátore;
Vypnutie zvlhčovača vzduchu pri zastavení ventilátora klimatizácie;
Prevádzka systémov podľa daného časového harmonogramu alebo bez neho;
· signalizácia havárií a havarijných situácií v prípade poruchy zariadenia, ako aj - výstup hodnôt technologických parametrov mimo stanovených rozsahov;
registrácia nehôd a núdzových situácií v denníku správ;
· protokol registrácie parametrov pre aktuálny čas s uvedením názvu riadených parametrov, jednotiek merania, čísla regulátora a vstupného/výstupného kanálu.
2.3.3. Napájanie automatizačného a dispečerského systému musí byť napájané zo siete striedavého prúdu s napätím 380/220 V, frekvenciou 50 Hz s použitím neprerušiteľných zdrojov na batérie a zabezpečené ako napájanie elektrospotrebičov I. kategórie.
Z hľadiska GOST *, ktoré regulujú vývoj softvér a automatizovaných systémov (AS) je hlavný dokument, ktorý definuje požiadavky a postup na vývoj alebo modernizáciu (ďalej len vytvorenie) automatizovaného systému, v súlade s ktorým prebieha vývoj AS a jeho akceptácia pri uvedení do prevádzky von.
- *GOST 19.201-78 Jednotný systém dokumentácie programu. Technická úloha. Požiadavky na obsah a dizajn;
- GOST 34.602-89 Informačné technológie. Súbor noriem pre automatizované systémy. Referenčné podmienky pre vytvorenie automatizovaného systému.
Prečo potrebujete technickú úlohu
Hlavné problémy v projekte vyplývajú z nesprávne formulovaných alebo voľných projektových požiadaviek. Hlavné požiadavky na výsledok by mali byť opísané v referenčných podmienkach, ktoré sa tvoria technických špecialistov interpret, nie klient.
Vznikajú tak dodatky k definícii, ktorá už bola sformulovaná vyššie. Dodávam, že tento dokument obsahujúci požiadavky musí byť formulovaný v jazyku zrozumiteľnom pre zákazníka. Väzby na vlastnosti technickej implementácie AU nie sú vytvorené. Tie. v štádiu TK je v zásade jedno, na ktorej platforme budú tieto požiadavky implementované. Objasnenie a formuláciu požiadaviek, ako aj vyhotovenie technických špecifikácií by mal mať na starosti obchodný analytik a nie programátor (aj keď táto možnosť je možná pri kombinovaní rolí), pretože je to analytik, kto hovorí so zákazníkom v jazyk jeho podnikania.
Správne zadávacie podmienky, napísané a dohodnuté medzi všetkými zainteresovanými a zodpovednými osobami, sú kľúčom k úspešnej realizácii akéhokoľvek projektu.
Kto vyvíja technickú úlohu
Objednávateľ spravidla nie je špecialistom na informačné technológie, takže hlavné požiadavky na výsledok by mali byť opísané v zadávacích podmienkach, ktoré tvoria technickí špecialisti zhotoviteľa, a nie objednávateľ.
Typické chyby vo vývoji technických špecifikácií
Dokument je založený na GOST 34.602-89, ktorý poskytuje formalizovanú štruktúru, ale nemá jasné požiadavky na prezentáciu sekcií a odsekov. Táto vlastnosť štandardu je jeho sila a slabosť. Sloboda prezentácie môže viesť k tomu, že požiadavky sekcií (najmä funkčných):
- Nie sú prezentované systematicky, bez odkazu na akúkoľvek štruktúru (systémové moduly, obchodné procesy);
- Duplikovať;
- Pozrite si rôzne úrovne detailov.
Chyby pri príprave zadávacích podmienok vedú k zvýšeniu nákladov a trvania projektu. Hlavnou úlohou technickej úlohy je formalizovať požiadavky zákazníka vo formáte, ktorý je zrozumiteľný a realizovateľný.
Bez riadne vypracovanej technickej špecifikácie nie je možná realizácia požiadaviek zákazníka. Aj u vysoko kompetentných zamestnancov sa môžu vyskytnúť chyby. Najbežnejšie sú tieto:
- Príliš veľa detailov
- Požiadavky, ktoré si navzájom odporujú;
- Nepresná formulácia.
Mnohí zákazníci hrešia tým, že vyžadujú príliš podrobný popis procesu systému, no treba sa zamerať na výsledok a nie na to, ako by mal systém vyzerať.
Požiadavky nesmú byť protichodné. Je tiež žiaduce vyhnúť sa vágnym, nešpecifickým formuláciám. Pri vývoji TOR sa určujú základné požiadavky a účel projektu, jeho funkčnosť.
Ako sa vyhnúť chybám pri zostavovaní TOR
Hlavné pravidlo: buďte konkrétnejší. Pri zostavovaní požiadaviek je potrebné použiť odkazy na GOST, regulačné dokumenty objednávateľa, čím sa zabráni dvojitému výkladu alebo nedorozumeniu medzi objednávateľom a zhotoviteľom.
Pri vývoji technických špecifikácií je potrebné používať suchý, vedecký štýl prezentácie, vyhýbať sa porovnávaniu. Mala by sa použiť terminológia odvetvia, oblasti, v ktorej sa projekt vyvíja.
Musíte sa riadiť nasledujúcimi pravidlami:
- Tvorba technických špecifikácií je spoločným dielom zhotoviteľa a objednávateľa;
- Riziká dodávateľa by mali byť minimalizované a nemali by presiahnuť riziká pre zákazníka (inak to povedie k zvýšeniu nákladov na projekt);
- Požiadavky sa formujú objektívne, neodporúča sa využívať subjektívne videnie zákazníka;
- Nie je dovolené používať výrazy, ktoré sú akceptované v širokej obchodnej komunikácii, ale sú v rozpore s tými, ktoré sú akceptované v odvetví a štandardom;
- Dôraz je kladený na popis výsledkov požadovaných zákazníkom. Napríklad zákazník potrebuje dostať správu o pohybe tovaru v príslušných analytických sekciách, potom by mal TOR podrobne opísať parametre správy (riadky, analytika, obdobie, za ktoré sa zostava zostavuje) a zdroje údajov. pre jeho generáciu. Najdôležitejšou vecou v tomto prípade je neumožniť rozšírený výklad zadávacích podmienok, inak, ak ste neuviedli obdobie alebo zdroj údajov, konečný výsledok sa môže značne líšiť od požiadaviek zákazníka a revízia si bude vyžadovať dodatočné finančné prostriedky a čas.
Vývoj napríklad „správneho“ TK pre programátora 1C znamená úplné ponorenie sa do témy, znalosť všetkých jej aspektov a jemností. TOR by mal odpovedať nielen na otázku „čo má robiť programátor“, ale predovšetkým – „aké úlohy by mal systém 1C:Enterprise riešiť po dokončení práce“. Požiadavky by mali byť formulované podrobne, ale bez zbytočných informácií. Tým sa zníži pravdepodobnosť nepresností a chýb. Preto nie je možné uviesť univerzálny príklad referenčného rámca 1C - každý prípad TOR pre vývoj 1C je jedinečný.
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á úloha (TOR, PRD) je mŕtva. Čiastočne s tým musíme súhlasiť – pri vývoji produktu od nuly vyzerá prototypovanie oveľa zaujímavejšie a efektívnejšie ako objemy záznamov zákazníkov, niekedy veľmi neprofesionálnych. Ak sa však bavíme o finalizácii základného systému, tak veci naberú úplne iný smer. Stretávame sa s revíziou aj zákazkovým vývojom, takže pes bol zjedený na TK, ak nám kuchár neklame. Vo všeobecnosti dnes - o tých veľmi klasických technických úlohách, ktoré sú napísané na dokončenie zakúpeného a nainštalovaného softvéru. Skrátka o boľačkách.
Aspekty interakcie
Predtým, ako pristúpime k príprave procesu tvorby technickej úlohy, povedzme si o štvoruholníku, do ktorého spadá zhotoviteľ a objednávateľ pri spustení projektu.
Požiadavky- požadované správanie systému, ako je opísané zákazníkom alebo držiteľom procesu, ktoré sa má implementovať. Požiadavky sa spravidla vytvárajú na základe skúseností, reprezentácie 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 dochádza k najväčšiemu počtu kolízií, chýb, nadbytočných požiadaviek a pod.
Zdroje- ľudia, stroje, zásoby, vývojové prostredie, čas a peniaze, ktoré sa majú použiť v procese implementácie požiadaviek. Zdroje vyžadujú jasné plánovanie a hodnotenie vo fáze schvaľovania zadávacích podmienok. Kompetentné 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- toto skrátka predajca (interpret) naozaj dokáže. Ako príklad si vezmite náš RegionSoft CRM. Klient kúpi systém a vypracuje technickú úlohu na revíziu: je potrebné vytvoriť integráciu so stránkou a prepojiť udalosti v CRM s číslom objednávky internetového obchodu. Je to realistická požiadavka, máme na to zdroje a schopnosti. A tiež potrebujete vyvinúť a prepojiť CRM CMS, systém na správu obsahu 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 zadanie presunuli ľudské a časové zdroje. Výsledkom je, že zákazník túto požiadavku odmietne – a v skutočnosti nepotrebuje CMS, aj tak je všetko v poriadku. Ale o "chamtivosti" TK - neskôr.
Obmedzenia- súbor prekážok, ktoré sťažujú alebo znemožňujú dokončenie úloh z TOR: rozpočet, zásobník technológií, problémy s licenciami, právne zákazy, konfigurácie hardvéru atď.
Všetky štyri entity sú teda úzko prepojené a určujú úspešnosť projektu ako celku. Zvážme každý prvok a pokúsme sa zdôrazniť kritické body, ktoré je potrebné mať na pamäti pri práci na zadávacích podmienkach.
Zber a analýza požiadaviek
Ide o veľmi dôležitý interný firemný proces, počas ktorého sa ukáže, čo potenciálni používatelia od programu chcú (ďalej budeme brať CRM, ale metódy fungujú aj s inými typmi softvéru). Ak oslovíte veľkého dodávateľa, akým je SAP alebo systémový integrátor, potom vám s vysokou pravdepodobnosťou ponúknu služby obchodného konzultanta (je tiež osobným manažérom, je tiež account manažérom, je tiež „ teraz váš zástupca v našej spoločnosti“). V skutočnosti ide vo väčšine prípadov o obyčajného dobre vyškoleného obchodníka, ktorý má dve úlohy: vyskladať náklady na projekt a nepustiť vás z háku.
Je tu už hodinu a ani sa nedotkol tabule. Nie je skutočným systémovým analytikom
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, v ktorej 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, špecifikujte, čo hľadať a pokračujte. Mimochodom, váš zamestnanec, ktorý sa dobre orientuje v téme profilu a zhruba reprezentuje softvérovú architektúru a pozná proces vývoja, môže byť dobrým pomocníkom – môže pôsobiť ako analytik a interný expert, uzavrieť proces tvorby technických špecifikácií a komunikácia s predajcom.
Existuje veľmi jednoduchá schéma zberu požiadaviek.
- Vytvorte pracovnú skupinu manažérov a skúsených špecialistov oddelení, ktorí budú využívať CRM. Povedzte nám o riešení, ktoré si vyberiete, poskytnite prístup k demo verzii.
- členov pracovná skupina musí zamestnancom sprostredkovať informácie a požiadať ich o želania nového programu v absolútne voľnej forme. Ak sa jeden zo zamestnancov nikdy nestretol s takýmto softvérom 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.
- Každá divízia potom určí, s čím sa CRM nezhoduje alebo nezhoduje, a agreguje informácie.
- Pracovná skupina analyzuje zozbierané požiadavky, kontroluje a odstraňuje križovatky. Napríklad nie je nezvyčajné, že obchodné oddelenie a marketingové oddelenie objednávajú rovnakú zostavu, ale polia a entity môžu byť v požiadavkách pomenované odlišne, hoci údaje za nimi sú rovnaké. Podľa toho je potrebné dospieť k jedinej forme.
- Pracovná skupina tvorí zoznam požiadaviek a stanovuje priority. V tejto fáze môžete pripojiť dodávateľa, 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. Ide o úlohy, ktoré sú časovo úplne odlišné, tu je priorita veľmi dôležitá.
Anatómia referenčného rámca
Ak hovoríme o procese vytvárania technickej úlohy, potom existuje niekoľko etáp. Ich dôsledná pasáž vedie zákazníka k želanému zlepšeniu. Tu sú.
- 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 – posúdenie požiadaviek v kontexte schopností CRM a existujúcich podnikových procesov.
- Dokumentácia – formálna a Detailný popis požiadavky, schvaľovanie technických požiadaviek.
- Komunikácia s predajcom (vývojárom) - iteratívna interakcia s predajcom ohľadom vylepšení v súlade so zostaveným TOR.
- Implementácia – práca predajcu na vytvorení potrebnej funkcionality. Je lepšie, ak je predajca neustále v kontakte so zákazníkom – výstupný produkt tak bude čo najviac zodpovedať vízii klienta.
- Testovanie - kontrola funkčnosti zamestnancov dodávateľa, interných expertov klienta a koncových užívateľov za účelom zistenia súladu s revíziou a technickými požiadavkami, výkonnosť 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, zdokonaľovanie a modelovanie obchodných procesov, vývoj nových funkčných modulov. Spravidla ide o vývoj náročný na zdroje so serióznymi konzultáciami a úzkou spoluprácou so zákazníkom. Napríklad v RegionSoft CRM boli kedysi také zákazkové úpravy skladové účtovníctvo, pokladňa a výroba. Postupne sa zmeny dostali 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 sa implementujú ú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 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 - spresnenie nie je na úrovni zobrazenia niečoho v rozhraní, ale na úrovni spresnenia systémovej logiky. Patria sem 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é, ktoré sa dostanú do nových verzií s opravami. Ide o úlohy z hľadiska rýchlosti odozvy systému, práce pri vysokej záťaži a bezpečnosti. V ideálnom prípade by predajca nemal mať takéto vylepšenia – 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, ktorá nesúvisí s osobnou paranojou zákazníka alebo problémami na strane hardvéru, oplatí sa jej venovať osobitnú pozornosť.
Technologická úroveň- posledný v zozname, ale pred ostatnými v dôležitosti a zložitosti. Môžu to byť požiadavky klientov súvisiace s platformou, operačným systémom alebo zariadeniami. Napríklad žiadosť o zostavenie pre MacOS. Je skvelé, ak sa takéto požiadavky postupne rozvinú do vydaní, no je potrebné mať ich opravy. Práve z požiadaviek zákazníkov na tejto úrovni sme urobili zostavu RegionSoft CRM pre MacOS a doplnili vzdialený prístup na technológii TRM ako dočasné riešenie zriedkavej, ale existujúcej požiadavky na mobilnú verziu.
Anatómia zadávacích podmienok je jednoduchá, aspoň v podobe kostry. Povinné časti zadávacích podmienok pomáhajú zákazníkovi sústrediť sa na problém a správne formulovať úlohu a realizátorovi porozumieť tomu, čo od neho chcú. Mimochodom, o porozumení. Samozrejme, na začiatku príspevku sme boli trochu prefíkaní a popierali obchodných konzultantov ako triedu. Ide o to, že každý predajca pôsobí na trhu niekoľko rokov (teraz 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 na svoje podnikanie.
Pre koho? V tejto časti musíte opísať, kto bude konečným používateľom revízie, aké úlohy a ako často sa plánuje riešiť.
Uvediem príklad. Jedna spoločnosť implementovala CRM, malo pracovať na pomerne veľkom poli dát (niekoľko desiatok miliónov záznamov za mesiac, niekoľko stotisíc záznamov za deň). Vedúci obchodného oddelenia si vyžiadal správu o nahrávaní týchto záznamov s frekvenciou „denne“. Prirodzene, takáto správa, zatiaľ čo stovky používateľov pracovali súčasne, zaťažila systém – našli sa riešenia na optimalizáciu procesu. Už v priebehu práce sa ukázalo, že predajca hral na istotu a report potreboval až na konci mesiaca a potom sa mohol spustiť podľa harmonogramu v noci. Netreba dodávať, že čas a peniaze boli zbytočné.
Prečo? Zdôvodnenie potreby zlepšenia a jeho miesto v obchodnom procese. Túto položku viac potrebuje samotný zákazník, ale je tiež užitočné, aby predajca vedel, aké ďalšie procesy budú ovplyvnené. Niekedy pomôže nájsť alternatívne riešenie.
čo treba urobiť? Najinformatívnejší blok - popisuje požiadavky, 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ý čiastkový dôvod – používateľ nevie formulovať požiadavky. A tu je úlohou vývojára (pracovnej skupiny, prípadne analytika) pomôcť správne formulovať potrebu, vybrať vhodnú požiadavku a zasadiť úlohu do kontextu systému. V tom istom bloku musíte spomenúť očakávaný výsledok.
Parametre referenčných podmienok- termíny, fázy realizácie, zodpovedný 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ú úlohu. Zadávacie podmienky musia byť dohodnuté a podpísané stranami, aby sa predišlo početným zmenám počas vývoja (stále budú, ale v menšom objeme).
V ideálnom prípade sú zadávacie podmienky vypracované za aktívnej účasti predajcu a výsledkom je približne nasledujúca štruktúra:
- Opis požiadaviek každého mechanizmu a každej funkčnosti
- Popis implementácie tejto funkcionality
- Náklady na prácu pre každú z etáp samostatne
- Celkové náklady na prácu na tejto technickej úlohe
- Lehoty na vykonanie prác s rozpisom podľa etáp a uvedením poradia prednosti
- Popis podmienok inštalácie a testovania
- Výhrady k vyčerpávajúcemu charakteru zadávacích podmienok a iných podmienok
10 pravidiel napísaných v slzách vývojára
Referenčnými podmienkami pre revíziu by mali byť TOR pre revíziu, a nie 300-stranový popis CRM, ktorý klient potrebuje. Pred vypracovaním požiadaviek by ste sa mali dôkladne oboznámiť so systémovým rozhraním, jeho schopnosťami, dokumentáciou - s najväčšou pravdepodobnosťou je väčšina „zoznamu želaní“ už v základnom balíku. Ako druhý krok by som odporučil venovať pozornosť vstavaným spresňujúcim nástrojom (návrhári zostáv, konfigurátory atď.) – potrebné zmeny snáď zvládne programátor na plný úväzok (majú ich mnohé firmy).Technická úloha by nemala byť chamtivá. Podnik často preceňuje svoje možnosti alebo chce získať „všetko naraz“. Tento prístup nie je opodstatnený ani z pohľadu peňazí, ani z pohľadu podnikania. Predajca spravidla neexistuje niekoľko týždňov (v prípade RegionSoft - 15 rokov) a môžete ho kontaktovať po chvíli, keď skutočne pochopíte, čo v CRM chýba.
Živý príklad redundancie doslova zo včera: klient si kúpil ERP od známeho ruská spoločnosť, mysliac si, ze kedze uctovnictvo funguje, tak ERP tohto dodavatela bude dobre. Ukázalo sa, že ERP nie je samo o sebe veľmi dobré, ale veľmi nevhodné na podnikanie. Vhodné je ale RegionSoft CRM so skladovým účtovníctvom a výrobou. Existuje riešenie: zabudnite na ERP, plačte, integrujte účtovníctvo 1C s novým CRM a užívajte si pohodlnú implementáciu. Ale tých nafúknutých peňazí je škoda! A klient pož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é vypočuť si názor predajcu, pretože presne vie, koľko času bude konkrétna úloha trvať. Verte mi, pre vývojára sa nevypláca hrať o čas a naťahovať termín – je pre neho výhodné dokončiť čo najviac projektov a urobiť to dobre, aby nedostal ranu do svojej povesti. Čo sa týka realizmu, je ľahké vyhnúť sa požiadavkám na dokončenie CRM na úroveň riadiaceho systému collider: do požiadaviek by ste mali zahrnúť to, čo je skutočne potrebné na 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 nezmyselné, ide o veľký vývoj, momentálne prebieha a nie je možným dolaďovaním pre jednu spoločnosť. Nie, samozrejme, všetko má svoju cenu, ale opäť - vo všeobecnom prípade je požiadavka nemožná.
Nemalo by sa to zamieňať so situáciou, keď ide o zákazkový vývoj 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.
Špecifikácia musí 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ému do vašej spoločnosti.
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 svoje vlastné vzorce, ktoré je potrebné zahrnúť do logiky CRM ( napríklad výpočet dealerských bonusov), tieto vzorce by sa mali písať pomocou úplný prepis ich označenia a logiky výpočtu.
Áno, firemný softvér vyzerá nejako takto a je v ňom veľa dôležitých maličkostí.
Zadávacie podmienky musia 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 TOR niekoľko možností správania sa systému, ktoré sú si blízke, ale nie rovnocenné. V tomto prípade si je istý, že pomôže, vyzve 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 ako to urobiť, sám si vyberie na základe na vlastnostiach systému a zásobníka použitých technológií.
Tento rok si opäť môžete vysloviť jedno želanie. Len to prosím neplytvajte na niečo, čo nemôžem splniť ani ja, ako sú jasné obchodné požiadavky!
Referenčné podmienky musia byť napísané v ľudskom jazyku. A to je dôležité, nie, DÔLEŽITÉ. Vyzdvihnem dve situácie, kedy problémy s jazykom vedú k oneskoreniu realizácie projektu.
- Klient sa snaží preukázať svoju technickú gramotnosť a konštrukcie oplotenia typu: „do tela kalendára implementovať okno s náznakom s možnosťou reagovať na volanie udalosti...“ namiesto „okno by malo vyskočiť v kalendár, 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.
Zadávacie podmienky by nemali byť knihou sťažností. Problém musíme riešiť, nie ho opisovať, venovať pozornosť fontom a zabudnúť na popis požiadaviek. TOR by mal obsahovať nielen samotný problém, ale aj jeho riešenie na úrovni pochopenia – potom ho už vývojár vyrieši na úrovni kódu. Porovnaj „obchodné oddelenie zle plánuje, stráca čísla, bojujeme už rok“ A „je potrebné vytvoriť zostavu, ktorá bude ukladať hodnoty plánu a skutočnosť predaja na mesačnej báze v kontexte skupín produktov“.
Zadávacie podmienky by mali byť schopné hľadieť do budúcnosti. Teda nie presne to, ale ľudia za tým. Ak je známe, že čoskoro dôjde k zmenám v obchodných procesoch, treba to vziať do úvahy, aby sa za revíziu neplatilo dvakrát.
Zadávacie podmienky by nemali byť byrokratické. Ak ste niekedy pripravovali tento dokument, určite ste pocítili, aké ťažké je vyhnúť sa pokušeniu skĺznuť do byrokracie, pridať úvodné slová, strohé obraty a každú položku opísať ako článok Trestného zákona (najlepšie s trestom pre každého porušenie). Byrokratické formulácie maskujú neúplné pochopenie cieľov tvorby TK. Zodpovednosť predajcu je uvedená v zmluve, je tam napísaný aj rozpočet. Tieto body by ste nemali prenášať na technickú úlohu.
Zadávacie podmienky musia byť referenčné. 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 zo stretnutí. Samozrejme, na takomto dokumente sa nedá pracovať. Aby ste neušli z formy a obsahu, použite trik zo starej školy: pozrite sa na výraz slovo po slove. Technický znamená, že diktuje zdokonalenie, techniku, je zameraný na vyriešenie problému zmenou softvéru. To je úloha v kontexte softvéru a musíte sa porozprávať. Úloha znamená položiť otázku, problém, bez rád, rád a predbežných odhadov. Len konstatovanie problému.
Prikázania skončili, teraz napomenutie
Okrem vyššie uvedených pravidiel je tu ešte pár vecí, ktoré stoja za reč. Hovoríme o cieľoch, plánoch a očakávaniach – všetkých tých, ktorí odchádzajú, vďaka ktorým je projekt úspešný a vzťah medzi predajcom a klientom je takmer priateľský.Referenčné podmienky je potrebné napísať rýchlo, aj keď stojíte pred úlohou automatizovať procesy mobilného operátora alebo veľkého hypermarketu. Je to spôsobené tým, že technológie sa vyvíjajú obrovskou rýchlosťou a dokonca aj systém, ktorý implementujete, môže prežiť veľké vydanie (a niekedy aj dve) za šesť mesiacov alebo rok a získať nové funkcie. Možno bude potrebné prehodnotiť potrebu vylepšení a začať proces odznova.
Nakoniec si našiel čas dokončiť TK. Ž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 úlohou predajcu, je to on, kto hodnotí prácu po vypracovaní zadávacích podmienok. Zákazník by sa nemal hrabať v technológii a pýtať sa každej čiarky, či predajca môže urobiť to alebo ono. Vypracujte si komplexný TOR a developer vyberie vhodnú architektúru – často dokonca lepšiu, ako by ste si mysleli.
Odhadnite svoj rozpočet a vyhnite sa nepríjemným prekvapeniam- takmer spoločná úloha číslo jeden. Nemali by ste naťahovať dodávateľa a požadovať od neho približné posúdenie práce (dobre, aspoň približne, z ruky, od oka, ale ako ostatní, dobre, v projektoch tohto typu, ale zo skúseností, dobre, dobre, v rámci tolerancia chyby). Úplný odhad 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 robí inak, pripravte sa na to, že revízia bude stáť minimálne dvakrát toľko.
Vychádzajte z 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. Preto sa nesnažte hneď vytvárať sny CRM / ERP, 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 zostavovať technické špecifikácie .
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 bolesti hlavy. Môžete hovoriť o prioritách a pravidlách dizajnu, o GOST 1989, ktorý robí TK neľudským, o štandardoch IEEE, ktoré sú o niečo lepšie, o prototypoch a TK, ktoré ich dopĺňajú. Nakoniec by som sa však rád obmedzil na jedno, najdôležitejšie pravidlo: referenčné podmienky nie sú právnym štátom, nie GOST a nie dogmou, a preto, ak sa môžete zlepšiť - zlepšiť, môžete zjednodušiť - zjednodušiť, môžete to urobiť s gráciou a tak, aby sa to všetkým páčilo - urobte to. Som si istý, že po tomto už nikto nebude strkať nos do TK a povedať, že toto tam nie je napísané. Alebo takmer nikto.
Počas celého decembra poskytujeme zľavy na RegionSoft CRM a všetok softvér z vlastného vývoja. Od 1. decembra do 15. decembra - 15% a cool podmienky na splátky a prenájom. Nemáme -70% a -90%, pretože držíme ekonomicky opodstatnenú cenu za licencie a neberieme ju zo stropu.
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, zlepšovať a predávať CRM, predávať softvér a školiť používateľov. Rozdelenie príjmov je spravodlivé a pre partnera výhodné. Ukáž, povedz, pouč. Písať [chránený e-mailom]
Šmykľavky, šmýkačky. Komiksy prevzaté z http://www.modernanalyst.com/ a z Pinterestu. Ak existuje lepší preklad, radi ho zaradíme do príspevku.