Tehnički zadatak- pismeno uputstvo drugoj strani da izvrši navedene radnje ili izvrši traženi posao (uslugu). Zasebno, takav dokument se obično ne koristi.

Pa ipak, u nekim slučajevima takav zadatak je jedina pismena potvrda nastanka prava i obaveza.

Pravila koja se primjenjuju na takve zadatke

Ona (pravila) su postavljena na javnom mjestu i svaka osoba koja prihvati njihove uslove smatra se stranom koja je sklopila javni ugovor za pružanje usluga, te razne druge opcije za transakcije.

Dokaz o prihvatanju od strane naručioca uslova izvođača mogu biti različiti dokumenti. To mogu biti blagajnički čekovi, nalozi za plaćanje koji pokazuju da je kupac platio usluge izvođača, kao i druga pisana dokumenta, uključujući tehničke specifikacije.

Istovremeno, zadatak treba jasno naznačiti lokaciju glavnih pravila za proizvodnju rada, ili se mogu u njemu u cijelosti iznijeti.

Zakonodavstvo dozvoljava zaključivanje projektnog zadatka na daljinu. Ovu mogućnost treba detaljno precizirati u pravilima za izvođenje radova (pružanje usluga). Prepiska se može voditi različitim sredstvima komunikacije (e-mail, faks, itd.).

U svakom slučaju, strane moraju jasno razumjeti i biti svjesne posljedica sklapanja transakcije i nastanka određenih prava i obaveza za njih. U cilju potvrđivanja zaključenja ugovora (ugovora) od strane strana, dozvoljena je upotreba elektronskih digitalnih potpisa, kao i faksimila (ako je to izričito naznačeno u uslovima transakcije).

Drugi oblici upotrebe takvog dokumenta

U normalnoj poslovnoj praksi, projektni zadaci su sastavni dio glavnog ugovora i bez njega su nevažeći. Na internetu postoje razni primjeri tehničkih specifikacija.

Njihova raznolikost često igra okrutnu šalu, jer nije jasno koju opciju odabrati. Pokušaćemo da razmotrimo obavezne uslove koji se moraju poštovati prilikom sastavljanja ovog dokumenta ili analize uzorka projektnog zadatka, preuzeto sa interneta:

Dokument je sastavljen u pisanoj formi i zapečaćen potpisima stranaka ili njihovih ovlašćenih predstavnika. Ako je stranka pravno lice, onda dokument mora biti ovjeren pečatom organizacije. Mora se obratiti pažnja na odgovarajuće ovlaštenje osobe koja potpisuje zadatak. Predstavnici obično imaju punomoćje. Pravna lica sastaviti punomoći u jednostavnom pisanom obliku, pojedinci- u javnobilježničkom obliku. S obzirom da punomoćje, lice koje ga je izdalo, može u svakom trenutku opozvati, prije potpisivanja dokumenta treba provjeriti njegovu valjanost.

Detalji zadatka tehnički zahtjevi na obavljene radove (usluge). Uputstva izvođača su obavezujuća za kupca, pod uslovom da ne krše odredbe glavnog ugovora i da njihova primjena neće dovesti do štetnih posljedica.

Dokument sadrži datum izrade, rokove za završetak radova. Mogu se specificirati faze izvođenja radova, kao i uslovi prihvatanja rezultata. Ako je potrebno, u dokumentu se navode osobe odgovorne za njegovu implementaciju. Ovaj zadatak može sadržavati i detalje o stranama.

Po potrebi se uz projektni zadatak mogu priložiti različiti dokumenti, kako u originalima tako i u kopijama. Izrađena dokumentacija se izrađuje u broju primjeraka jednakom broju primjeraka projektnog zadatka. Svaka strana u transakciji ima pravo na originalni projektni zadatak sa svim prilozima uz njega.

Ispod je jedna od tehničkih specifikacija. Ostale uzorke projektnog zadatka možete pronaći u odjeljku naše web stranice "Uzorci dokumenata". Pročitajte pravnu dokumentaciju na ovu temu u odjeljku "Pitanja i odgovori" na stranici. Pravilna registracija nastalih prava i obaveza je garancija njihove implementacije od strane svih strana uključenih u transakciju.

Projektni zadatak za obavljanje poslova

Često me pitaju: "Kako izraditi tehnički zadatak za automatizovani sistem?". O sličnoj temi se stalno raspravlja na raznim forumima. Ovo pitanje je toliko široko da je nemoguće odgovoriti ukratko. Stoga sam odlučio da napišem poduži članak na ovu temu.

• U prvom dijelu" Izrada tehničkih specifikacija. Šta je to, zašto je potrebno, odakle početi i kako bi trebalo da izgleda? Pokušat ću detaljno odgovoriti na pitanja iz teme, razmotriti strukturu i svrhu Projektnog zadatka i dati neke preporuke o formuliranju zahtjeva.
• Drugi dio" Izrada tehničkih specifikacija. Kako formulisati zahteve? biće u potpunosti posvećen identifikaciji i formulisanju zahteva za informacioni sistem.

Prvo morate shvatiti šta je zapravo pitanje koje zanima one koji se pitaju "Kako izraditi projektni zadatak?" Činjenica je da će pristup izradi tehničkih specifikacija u velikoj mjeri ovisiti o svrhama u koje se to radi, kao io tome ko će ga koristiti. O kojim opcijama govorim?

• Jedna komercijalna organizacija odlučila je da implementira automatizovani sistem. Nema sopstveni IT servis i odlučio je da uradi sledeće: Zainteresovana osoba mora izraditi Projektni zadatak i dati ga na razvoj trećoj organizaciji;
• Jedna komercijalna organizacija odlučila je da implementira automatizovani sistem. Ima sopstvenu IT uslugu. Odlučili smo da uradimo ovo: izradimo Projektni zadatak, zatim ga koordiniramo između IT službe i zainteresovanih strana i implementiramo ga sami;
• Državna struktura odlučila je da pokrene IT projekat. Ovdje je sve tako blatnjavo, puno formalnosti, mitinga, rezova itd. Ovu opciju neću razmatrati u ovom članku.

• IT kompanija se bavi uslugama razvoja i/ili implementacije automatizovanih sistema. Ovo je najviše težak slučaj, jer morate raditi u raznim uslovima:

  • Klijent ima svoje stručnjake sa sopstvenim stavovima, i oni imaju specifične zahteve za Projektni zadatak;
  • Projektni zadaci su razvijeni za naše vlastite programere (klijenta nije briga);
  • Projektni zadaci se izrađuju za prijenos na izvođača (tj. grupu programera koji su izvan osoblja kompanije, ili pojedinog stručnjaka);
  • Postoji nesporazum između kompanija i klijenta u vezi sa postignutim rezultatom, a kompanija iznova postavlja pitanje: „Kako treba izraditi Projektni zadatak?“. Potonji slučaj može izgledati kao paradoks, ali je istina.
  • Moguće su i druge, manje uobičajene opcije;

Mislim da bi sada čitalac trebalo da ima pitanja:

• Zašto se projektni zadatak ne može razvijati uvijek na isti način?;
• Postoje li neki standardi, metode, preporuke? Gdje ih nabaviti?
• Ko bi trebao izraditi Projektni zadatak? Da li ova osoba mora imati neka posebna znanja?
• Kako razumjeti da li je projektni zadatak dobro napisan ili ne?
• O čijem trošku ga treba razvijati i da li je uopšte potrebno?

Ova lista bi mogla biti beskonačna. Toliko samouvjereno govorim iz činjenice da se bavim profesionalnim razvojem softvera već 15 godina, a pitanje projektnog zadatka se pojavljuje u svakom razvojnom timu s kojim moram raditi. Razlozi za to su različiti. Pokrećući temu izrade Projektnog zadatka, dobro sam svjestan da ga neću moći 100% prezentirati za sve zainteresovane za ovu temu. Ali, pokušaću, kako kažu, "sve staviti na police". Oni koji su već upoznati sa mojim člancima znaju da ne koristim "copy-paste" tuđe radove, ne preštampam tuđe knjige, ne citiram standarde na više stranica i druge dokumente koje i sami možete pronaći na internetu, propuštajući ih kao svoje briljantne misli. Dovoljno je da u pretraživač ukucate "Kako izraditi Projektni zadatak" i moći ćete da pročitate mnogo zanimljivog, ali, nažalost, mnogo puta ponovljenog. Po pravilu, oni koji vole da budu pametni na forumima (pokušajte ipak da pretražuju!), nikada sami nisu napravili razuman Projektni zadatak i neprestano citiraju GOST preporuke o ovom pitanju. A oni koji se zaista ozbiljno bave ovim pitanjem obično nemaju vremena da sjede po forumima. Usput, razgovarat ćemo i o GOST-ovima. Tokom godina mog rada, video sam mnoge varijante tehničke dokumentacije koju su sastavljali kako pojedinačni stručnjaci, tako i eminentni timovi i konsultantske kuće. Ponekad se bavim i takvim aktivnostima: odvajam vrijeme za sebe i tražim informacije o temi koja me zanima iz neobičnih izvora (kao što je malo inteligencije). Kao rezultat toga, morao sam vidjeti dokumentaciju o takvim čudovištima kao što su Gazprom, Ruske željeznice i mnoge druge zanimljive kompanije. Naravno da se pridržavam politika privatnosti, uprkos činjenici da ovi dokumenti dolaze do mene iz javno dostupnih izvora ili neodgovornosti konsultanata (razbacuju informacije po internetu). Stoga odmah kažem: ne dijelim povjerljive informacije koje pripadaju drugim kompanijama, bez obzira na izvore nastanka (profesionalna etika).

Šta je tehnički zadatak?

Prva stvar koju ćemo sada uraditi je da shvatimo o kakvoj se životinji radi, “Zahtjev za rad”.

Da, zaista postoje GOST-ovi i standardi u kojima se pokušava regulirati ovaj dio aktivnosti (razvoj softvera). Nekada su svi ovi GOST-ovi bili relevantni i aktivno korišteni. Sada postoje različita mišljenja o relevantnosti ovih dokumenata. Neki tvrde da su GOST-ove razvili vrlo dalekovidi ljudi i da su još uvijek relevantni. Drugi kažu da su beznadežno zastarjeli. Možda je neko sada pomislio da je istina negdje na sredini. Odgovorio bih Geteovim rečima: „Kažu da između dva suprotna mišljenja leži istina. Ni u kom slučaju! Postoji problem između njih." Dakle, između ovih mišljenja nema istine. Jer GOST-ovi ne otkrivaju praktične probleme modernog razvoja, a oni koji ih kritikuju ne nude alternative (specifične i sistemske).

Imajte na umu da GOST jasno ne daje čak ni definiciju, već samo kaže: „Terminal za nuklearnu elektranu je glavni dokument koji definiše zahtjeve i postupak za stvaranje (razvoj ili modernizaciju - daljnje kreiranje) automatiziranog sistema, u skladu sa koji se vrši izrada NEK i njen prijem nakon puštanja u rad."

Ako se neko pita o kojim GOST-ovima govorim, evo ih:

• GOST 2.114-95 jedan sistem projektnu dokumentaciju. Specifikacije;
• GOST 19.201-78 Jedinstveni sistem programske dokumentacije. Tehnički zadatak. Zahtjevi za sadržaj i dizajn;
• GOST 34.602-89 Informaciona tehnologija. Skup standarda za automatizovani sistemi. Projektni zadatak za kreiranje automatizovanog sistema.

Mnogo bolja definicija je predstavljena na Wikipediji (istina o TK-u općenito, a ne samo za softver): “ Tehnički zadatak je originalni projektni dokument tehnički objekt. Tehnički zadatak utvrđuje glavnu namjenu objekta koji se razvija, njegove tehničko-taktičko-tehničke karakteristike, pokazatelje kvaliteta i tehničko-ekonomske zahtjeve, uputstva za završetak potrebnih faza izrade dokumentacije (projektantske, tehnološke, softverske i dr.) i njen sastav, kao i kao i posebne zahtjeve. Zadatak kao izvorni dokument za kreiranje nečeg novog postoji u svim oblastima delatnosti, koji se razlikuje po nazivu, sadržaju, redosledu izvođenja itd. (npr. projektantski zadatak u građevinarstvu, borbeni zadatak, domaći zadatak, ugovor za književno djelo itd.)"

I tako, kao što slijedi iz definicije, glavna svrha Projektnog zadatka je da formuliše zahtjeve za objekt koji se razvija, u našem slučaju, za automatizirani sistem.

To je glavni, ali jedini. Vrijeme je da preuzmete glavnu stvar: da sve stavite "na police", kao što je obećano.

Šta trebate znati o zahtjevima? Mora se jasno shvatiti da svi zahtjevi moraju biti podijeljeni po vrsti i svojstvima. Sada ćemo naučiti kako to učiniti. Da odvojimo zahtjeve prema vrsti, GOST će nam samo pomoći. Spisak tipova zahteva koji je tamo predstavljen je dobar primer o tome koje vrste zahteva treba uzeti u obzir. Na primjer:

• zahtjevi funkcionalnosti;
• Zahtjevi za sigurnost i prava pristupa;
• Zahtjevi za kvalifikacijom osoblja;
• …. itd. O njima možete pročitati u spomenutom GOST-u (a u nastavku ću ih također razmotriti malo detaljnije).

Mislim da vam je očigledno da su dobro formulisani zahtjevi za funkcionalnošću ključ uspješnog Projektnog zadatka. Upravo tim zahtjevima posvećena je većina radova i metoda o kojima sam govorio. Zahtjevi funkcionalnosti su 90% složenosti izrade Projektnog zadatka. Sve ostalo je često "kamuflaža" koja se stavlja na ove zahtjeve. Ako su zahtjevi loše formulirani, onda bez obzira kakvu lijepu kamuflažu stavite na njih, uspješan projekt neće uspjeti. Da, formalno će svi zahtjevi biti ispunjeni (prema GOST J), TOR je razvijen, odobren i potpisan, a novac je za to primljen. Pa šta? A onda počinje zabava: šta da se radi? Ako se radi o projektu na državnoj narudžbi, onda nema problema - postoji takav budžet da neće stati ni u jedan džep, sve će se razjasniti u procesu implementacije (ako postoji). Tacno tako se pilje vecina budzeta projekata po drzavnim narudzbinama (zapalili "TK", spojili deset miliona, ali nisu poceli da rade projekat. Ispunjene su sve formalnosti, nije bilo krivih, novi auto blizu kuća. Ljepota!). Ali mi pričamo o tome komercijalne organizacije gdje se računa novac, a potreban je drugačiji rezultat. Stoga, hajde da se pozabavimo glavnom stvari, kako se razvijati korisni i radni Zadaci.

Rekao sam o vrstama zahtjeva, ali šta je sa svojstvima? Ako vrste zahtjeva mogu biti različite (ovisno o ciljevima projekta), onda je sa svojstvima sve jednostavnije, postoje 3 njih:

1. Zahtjev mora biti razumljivo;
2. Zahtjev mora biti beton;
3. Zahtjev mora biti testirano;

Štaviše, posljednje svojstvo je nemoguće bez dva prethodna, tj. je svojevrsni "lakmus test". Ako se rezultat zahtjeva ne može testirati, onda on ili nije jasan ili nije specifičan. Razmisli o tome. U posedovanju ova tri svojstva zahteva leže veština i profesionalizam. U stvari, sve je vrlo jednostavno. Kad shvatiš.

Ovu priču o tome šta je projektni zadatak, moglo bi se dovršiti i preći na ono glavno: kako formulisati zahtjeve. Ali nije sve tako brzo. Postoji još jedna izuzetno važna tačka:

• na kom jeziku (u smislu složenosti razumijevanja) treba napisati projektni zadatak?
• Treba li u njemu opisati specifikaciju različitih funkcija, algoritama, tipova podataka i drugih tehničkih stvari?
• A što je tehnički dizajn, koji se, inače, također spominje u GOST-ovima, i kako je povezan s Projektnim zadatkom?

Postoji jedna vrlo podmukla stvar u odgovorima na ova pitanja. Zbog toga se često javljaju sporovi o dovoljnosti ili nepostojanju potrebnih detaljnih zahtjeva, o razumljivosti dokumenta od strane Naručioca i Izvođača, o redundantnosti, formatu prezentacije itd. A gdje je granica između projektnog zadatka i tehničkog projekta?

Tehnički zadatak je dokument zasnovan na zahtjevima formulisanim na jeziku razumljivom (uobičajenom, poznatom) Kupcu. U ovom slučaju se može i treba koristiti terminologija koja je razumljiva Kupcu. Ne bi trebalo biti nikakvih vezivanja za karakteristike tehničke implementacije. One. u fazi TK, u principu, nije bitno na kojoj će platformi ovi zahtjevi biti implementirani. Iako postoje izuzeci. Ako je riječ o implementaciji sistema baziranog na postojećem softverskom proizvodu, onda se takvo uvezivanje može dogoditi, ali samo na nivou ekranskih obrazaca, obrazaca izvještaja itd. poslovni analitičar. I sigurno ne programer (osim ako ne kombinuje ove uloge, to se dešava). One. ova osoba treba da razgovara sa Klijentom na jeziku njegovog poslovanja.

Tehnički projekat je dokument koji je namijenjen tehničkoj implementaciji zahtjeva formuliranih u Projektnom zadatku. Upravo ovaj dokument opisuje strukture podataka, pokretače i pohranjene procedure, algoritme i druge stvari koje će biti potrebne tehnički stručnjaci. Uopšte nije neophodno da se kupac upušta u ovo (možda ne razume takve uslove). Tehnički projekat radi System Architect(Ovdje je kombinacija ove uloge sa programerom sasvim normalna). Tačnije, grupa stručnjaka za AO na čelu sa arhitektom. Što je projekat veći, više ljudi radi na Projektnom zadatku.

Šta imamo u praksi? Smiješno je gledati kada direktora dovode na odobrenje Projektni zadatak, koji obiluje tehničkom terminologijom, opisima tipova podataka i njihovih vrijednosti, strukture baze podataka itd. On se, naravno, trudi da razumije, jer je to neophodno tvrditi, pokušavajući pronaći poznate riječi između redova i ne izgubiti poslovne zahtjeve lanca. Šta, poznata situacija? I kako se to završava? Takav TOR se po pravilu odobrava, potom sprovodi i u 80% slučajeva onda uopšte ne odgovara činjenici obavljenog posla, jer mnogo stvari su odlučili da promene, poprave, pogrešno shvatili, pogrešno mislili itd. itd. A onda počinje serija primopredaje. “Ali ovdje nije onako kako nam treba”, već “neće nam uspjeti”, “previše je komplikovano”, “nezgodno je” itd. Poznat?! Tako da znam, morao sam na vrijeme popuniti neravnine.

Dakle, šta imamo u praksi? Ali u praksi imamo zamagljenu granicu između projektnog zadatka i tehničkog projekta. Lebdi između TK i TP na razne načine. A ovo je loše. A ispada jer je razvojna kultura oslabila. To je dijelom zbog kompetentnosti stručnjaka, dijelom zbog želje za smanjenjem budžeta i rokova (na kraju krajeva, dokumentacija oduzima puno vremena - to je činjenica). Postoji još jedan važan faktor koji utiče na upotrebu tehničkog projekta kao zasebnog dokumenta: brzi razvoj alata za brzi razvoj, kao i razvojnih metodologija. Ali ovo je posebna priča, o tome ću reći nekoliko riječi u nastavku.

Još jedna mala, ali važna tačka. Ponekad se Projektni zadaci nazivaju malim zahtjevima, jednostavnim i razumljivim. Na primjer, da biste precizirali pretragu objekta prema nekim uvjetima, dodajte kolonu u izvještaj itd. Ovakav pristup je sasvim opravdan, čemu komplicirati život. Ali ne koristi se na velikim projektima, već na manjim poboljšanjima. Rekao bih da je ovo bliže održavanju softverskog proizvoda. U ovom slučaju, Projektni zadatak može opisati i specifično tehničko rješenje za implementaciju zahtjeva. Na primjer, "Učiniti takvu i takvu promjenu u algoritmu", što ukazuje na specifičnu proceduru i specifičnu promjenu za programera. To je slučaj kada je granica između projektnog zadatka i tehničkih projekata potpuno izbrisana, jer ne postoji ekonomska izvodljivost da se papirologija naduva tamo gde nije potrebna, a kreira se koristan dokument. I to je tačno.

Da li vam je zaista potrebna tehnička specifikacija? Šta je sa inženjerskim projektom?

Jesam li pregrijan? Da li je ovo uopšte moguće bez projektni zadatak? Zamislite možda (tačnije, javlja se), a ovaj pristup ima mnogo sljedbenika, a njihov broj se povećava. Po pravilu, nakon što mladi stručnjaci pročitaju knjige o Scrum-u, Agile-u i drugim tehnologijama brzog razvoja. Zapravo, ovo su divne tehnologije i rade, samo što doslovno ne kažu „nema potrebe za tehničkim poslovima“. Kažu „minimum papirologije“, posebno nepotrebne, bliže Kupcu, više konkretnih stvari i brži rezultati. Ali niko nije otkazao fiksiranje uslova i to je tamo jasno navedeno. Tu se utvrđuju zahtjevi na osnovu tri divna svojstva o kojima sam gore govorio. Samo, kod nekih je svijest uređena tako da ako se nešto može pojednostaviti, hajde da uprostimo do potpunog odsustva. Kao što je Ajnštajn rekao " Neka bude što jednostavnije, ali ne jednostavnije od toga." . Zlatne riječi idu uz sve. Dakle Tehnički zadatak neophodno, inače nećete vidjeti uspješan projekat. Drugo je pitanje kako komponovati i šta tu uključiti. U svjetlu metodologija brzog razvoja, trebate se fokusirati samo na zahtjeve, a sva "kamuflaža" se može odbaciti. U suštini, slažem se sa ovim.

Šta je sa tehničkim projektom? Ovaj dokument je veoma koristan i nije izgubio na važnosti. Štaviše, često je jednostavno nemoguće bez toga. Pogotovo kada je u pitanju outsourcing razvojnih poslova, tj. na bazi outsourcinga. Ako se to ne učini, postoji rizik da naučite mnogo o tome kako bi sistem koji imate na umu trebao izgledati. Treba li ga kupac upoznati? Ako hoće zašto ne, ali insistirajte i tvrdite ovaj dokument nema potrebe, samo će kočiti i ometati rad. Gotovo je nemoguće dizajnirati sistem do najsitnijih detalja. U tom slučaju ćete morati kontinuirano unositi izmjene u Tehnički dizajn, što oduzima dosta vremena. A ako je organizacija jako birokratizirana, onda općenito ostavite sve živce tamo. Upravo se o ovoj vrsti smanjenja dizajna raspravlja u savremenim metodologijama brzog razvoja, koje sam već spomenuo. Inače, svi su bazirani na klasičnom pristupu XP (ekstremno programiranje), starom već oko 20 godina. Zato napravite visokokvalitetan Projektni zadatak, razumljiv kupcu, i koristite Tehnički dizajn kao interni dokument za odnos između arhitekte sistema i programera.

Zanimljiv detalj o tehničkom dizajnu: neki razvojni alati raspoređeni po principu predmetne orijentacije (kao što je 1C i slično) sugeriraju da je dizajn (što znači proces dokumentacije) potreban samo za stvarno teška područja, gdje je potrebna interakcija između cijelih podsistema. U najjednostavnijem slučaju, na primjer, za kreiranje referentne knjige, dokumenta, dovoljni su samo pravilno formulirani poslovni zahtjevi. O tome svjedoči i poslovna strategija ove platforme u smislu obuke stručnjaka. Ako pogledate ispitni list nekog specijaliste (tako se zove, a ne „programera“), vidjet ćete da tu postoje samo poslovni zahtjevi, a kako ih implementirati u programskom jeziku je zadatak specijalista. One. onaj dio zadatka za koji je tehnički projekt osmišljen da riješi, specijalista mora riješiti „u glavu“ (govorimo o zadacima srednje složenosti), a ovdje i sada, slijedeći određene standarde razvoja i dizajna, koji su opet formirana od strane 1C kompanije za svoju platformu. Tako, od dva specijalista, čiji rezultat rada izgleda isto, jedan može položiti ispit, a drugi ne, jer. grubo narušeni razvojni standardi. Odnosno, očigledno se pretpostavlja da stručnjaci moraju imati takve kvalifikacije da mogu sami dizajnirati tipične zadatke, bez uključivanja sistemskih arhitekata. I ovaj pristup funkcionira.

Nastavimo proučavanje pitanja: "Koje zahtjeve treba uključiti u Projektni zadatak?"

Formulisanje zahteva za informacioni sistem. Struktura projektnog zadatka

Odmah da razjasnimo: govorit ćemo o formulaciji zahtjeva za informacioni sistem, tj. pod pretpostavkom da su poslovi izrade poslovnih zahtjeva, formalizacije poslovnih procesa i svi dosadašnji konsultantski poslovi već završeni. Naravno, neke dorade se mogu izvesti u ovoj fazi, ali samo dorade. Sam projekat automatizacije ne rešava poslovni problem—imajte to na umu. Ovo je aksiom. Iz nekog razloga, neki menadžeri to pokušavaju opovrgnuti, vjerujući da će, ako kupe program, red doći u haotičnom poslu. Ali na kraju krajeva, aksiom je aksiom koji ne zahtijeva dokaz.

Kao i kod svake aktivnosti, formulacija zahtjeva se može (i treba) podijeliti u faze. Sve ima svoje vrijeme. Ovo je težak intelektualni rad. A ako se tretira s nedovoljnom pažnjom, onda će rezultat biti odgovarajući. Prema procjenama stručnjaka, troškovi izrade Projektnog zadatka mogu biti 30-50%. Ja sam istog mišljenja. Iako je 50 možda previše. Uostalom, Projektni zadatak nije posljednji dokument koji treba izraditi. Uostalom, mora postojati i tehnički dizajn. Ova varijacija je rezultat različitih platformi za automatizaciju, pristupa i tehnologija koje koriste projektni timovi tokom razvoja. Na primjer, ako govorimo o razvoju na klasičnom jeziku kao što je C++, onda je detaljan tehnički dizajn neophodan. Ako govorimo o implementaciji sistema na 1C platformi, onda je situacija s dizajnom nešto drugačija, kao što smo vidjeli gore (iako je, kada se razvija sistem od nule, dizajniran prema klasičnoj shemi).

Iako je formulacija zahtjeva glavni dio projektni zadatak, a u nekim slučajevima postaje jedini odjeljak ToR-a, treba obratiti pažnju na činjenicu da je ovo važan dokument i da ga treba sastaviti u skladu s tim. Gdje početi? Prije svega, morate početi sa sadržajem. Sastavite sadržaj, a zatim ga počnite razvijati. Ja lično radim ovo: prvo skiciram sadržaj, opisujem ciljeve, sve osnovne informacije, a onda prelazim na glavni dio – formulaciju zahtjeva. Zašto ne i obrnuto? Ne znam, meni je zgodnije. Prvo, ovo je mnogo manji dio vremena (u poređenju sa zahtjevima), a drugo, dok opisujete sve uvodne informacije, prelazite na ono glavno. Pa ko god voli. Vremenom ćete razviti svoj vlastiti predložak zadatka. Za početak, preporučujem da kao sadržaj uzmete upravo onaj koji je opisan u GOST-u. Odličan je za sadržaj! Zatim uzimamo i počinjemo da opisujemo svaki odeljak, ne zaboravljajući preporuke za sledeća tri svojstva: razumljivost, specifičnost i mogućnost testiranja. Zašto toliko insistiram na ovome? Više o tome u sljedećem odjeljku. A sada predlažem potpuno takt da prođemo kroz one točke TK-a koje se preporučuju u GOST-u.

1. opće informacije;
2. svrha i ciljevi stvaranja (razvoja) sistema;
3. karakteristike objekata automatizacije;
4. Zahtjevi sustava;
5. sastav i sadržaj rada na kreiranju sistema;
6. postupak kontrole i prihvatanja sistema;
7. zahtjevi za sastavom i sadržajem rada na pripremi objekta automatizacije za puštanje sistema u rad;
8. zahtjevi za dokumentacijom;
9. razvojni izvori.

Ukupno, 9 odjeljaka, od kojih je svaki također podijeljen na pododjeljke. Uzmimo ih redom. Radi praktičnosti, predstavit ću sve u obliku tabele za svaku stavku.

Odjeljak 1. opšte informacije.

Preporuke prema GOST-u
puni naziv sistema i njegov simbol;	Ovdje je sve jasno: pišemo kako će se sistem zvati, njegov kratki naziv
šifra teme ili šifra (broj) ugovora;	Ovo nije relevantno, ali možete odrediti ako je potrebno.
naziv preduzeća (udruženja) programera i korisnika (korisnika) sistema i njihovi detalji;	naznačiti ko (koje organizacije) će raditi na projektu. Možete odrediti i njihove uloge.Ovu sekciju možete potpuno izbrisati (prilično formalno).
spisak dokumenata na osnovu kojih je sistem kreiran, ko i kada su ti dokumenti odobreni;	Korisne informacije. Ovdje treba navesti regulatornu i referentnu dokumentaciju koju ste dobili da biste se upoznali sa određenim dijelom zahtjeva
planiranih datuma početak i kraj rada na kreiranju sistema;	Vremenske želje. Ponekad o tome pišu u TOR-u, ali češće se takve stvari opisuju u ugovorima o radu
podatke o izvorima i postupku finansiranja radova;	Slično, kao u prethodnom paragrafu o vremenu. Relevantnije za vladine naloge (za državne službenike)
postupak formalizovanja i predstavljanja naručiocu rezultata rada na izradi sistema (njegovih delova), na izradi i prilagođavanju pojedinačnih sredstava (hardver, softver, informacija) i softversko-hardverskih (softversko-metodoloških) kompleksa sistem.	Ne vidim potrebu za ovim paragrafom, tk. posebno se izrađuju zahtjevi za dokumentaciju, a pored toga postoji i cijeli poseban odjeljak „Procedura kontrole i prijema“ sistema.

Odjeljak 2. svrha i ciljevi stvaranja (razvoja) sistema.

Preporuke prema GOST-u	Šta raditi s tim u praksi
Svrha sistema	S jedne strane, imenovanje je jednostavno. Ali želio bih biti konkretan. Ako napišete nešto poput „visokokvalitetne automatizacije kontrole zaliha u kompaniji X“, onda možete dugo razgovarati o rezultatu kada se završi, čak i bez obzira na dobre formulacije zahtjeva. Jer Kupac uvijek može reći da je pod kvalitetom mislio na nešto drugo. Općenito, živci mogu dosta pokvariti jedni druge, ali zašto? Bolje je odmah napisati nešto ovako: "Sistem je dizajniran za održavanje skladišne ​​evidencije u kompaniji X u skladu sa zahtjevima utvrđenim u ovom Projektnom zadatku."
Ciljevi stvaranja sistema	Golovi su svakako važan dio. Ako ga uključimo, onda moramo biti u stanju formulirati ove ciljeve. Ako imate poteškoća s formuliranjem ciljeva, onda je bolje da ovaj odjeljak potpuno isključite. Primjer neuspješnog cilja: "Osigurati brzu papirologiju od strane menadžera." Šta je brzo? To se onda može dokazivati ​​beskonačno. Ako je ovo važno, onda je bolje ovaj cilj preformulisati na sljedeći način: „Menadžer prodaje bi trebao biti u mogućnosti izdati dokument „Prodaja robe“ od 100 redova za 10 minuta“. Takav cilj može se pojaviti ako, na primjer, menadžer trenutno potroši oko sat vremena na ovo, što je za ovu kompaniju previše i za njih je važno. U ovoj formulaciji cilj se već ukršta sa zahtjevima, što je sasvim prirodno, jer. kada proširujemo stablo ciljeva (tj. dijelimo ih na manje povezane ciljeve), već ćemo pristupiti zahtjevima. Stoga se ne treba zanositi.

Općenito, sposobnost identificiranja ciljeva, njihovog formuliranja, izgradnje stabla ciljeva je potpuno zasebna tema. Zapamtite glavnu stvar: ako znate kako - pišite, ako niste sigurni - ne pišite nikako. Šta se dešava ako ne postavite ciljeve? Radit ćete prema zahtjevima, to se često praktikuje.

Odjeljak 3. Karakteristike objekata automatizacije.

Odjeljak 4 Sistemski zahtjevi

GOST dešifruje listu takvih zahtjeva:

• zahtjevi za strukturom i funkcionisanjem sistema;
• zahtjeve za brojem i kvalifikacijama osoblja sistema i načinom njegovog rada;
• indikatori odredišta;
• zahtjevi za pouzdanost;
• sigurnosni zahtjevi;
• zahtjevi za ergonomiju i tehničku estetiku;
• zahtjevi za prenosivosti za mobilni AS;
• zahtjevi za rad, održavanje, popravku i skladištenje komponenti sistema;
• zahtjevi za zaštitu informacija od neovlaštenog pristupa;
• zahtjevi za sigurnost informacija u slučaju nesreća;
• zahtjevi za zaštitu od utjecaja vanjskih utjecaja;
• zahtjevi za čistoću patenta;
• zahtjevi za standardizaciju i unifikacija;

Unatoč činjenici da će glavni, naravno, biti dio sa specifičnim zahtjevima (funkcionalan), ovaj odjeljak također može imati veliki značaj(i u većini slučajeva jeste). Šta može biti važno i korisno:

• Kvalifikacijski zahtjevi. Moguće je da će sistem koji se razvija zahtijevati prekvalifikaciju stručnjaka. Može biti kao korisnici budući sistem, i IT stručnjaci koji će biti potrebni da ga podrže. Nedovoljna pažnja ovom pitanju često prerasta u probleme. Ukoliko su kvalifikacije postojećeg osoblja očigledno nedovoljne, bolje je propisati uslove za organizaciju obuke, program obuke, termine i sl.
• Zahtjevi za zaštitu informacija od neovlaštenog pristupa. Ovdje nema komentara. Upravo to su zahtjevi za kontrolu pristupa podacima. Ako se takvi zahtjevi planiraju, onda ih je potrebno posebno napisati, što je moguće detaljnije po istim pravilima kao i funkcionalni zahtjevi (razumljivost, specifičnost, provjerljivost). Stoga se ovi zahtjevi mogu uključiti u odjeljak sa funkcionalnim zahtjevima.
• zahtjevi za standardizaciju. Ako postoje razvojni standardi koji su primjenjivi na projekat, oni se mogu uključiti u zahtjeve. Takve zahtjeve po pravilu inicira IT služba Kupca. Na primjer, kompanija 1C ima zahtjeve za dizajn programskog koda, dizajn interfejsa itd.;
• Zahtjevi za strukturu i funkcioniranje sistema. Ovdje se mogu opisati zahtjevi za međusobnu integraciju sistema, predstavljen je opis opšte arhitekture. Češće se integracijski zahtjevi izdvajaju općenito u posebnom dijelu ili čak u zasebnom Projektnom zadatku, jer ovi zahtjevi mogu biti prilično složeni.

Svi ostali zahtjevi su manje važni i mogu se izostaviti. Po mom mišljenju, oni samo otežavaju dokumentaciju i od male su praktične koristi. I vrlo je teško opisati zahtjeve za ergonomiju u obliku općih zahtjeva, bolje ih je prenijeti na funkcionalne. Na primjer, može se formulirati zahtjev „Informirajte se o cijeni proizvoda pritiskom na samo jedno dugme“. Po mom mišljenju, ovo je ipak bliže specifičnim funkcionalnim zahtjevima, iako se odnosi na ergonomiju.Zahtjevi za funkcije (zadatke) koje sistem obavlja Evo, to je ono najvažnije i ključno što će odrediti uspjeh. Čak i ako je sve ostalo savršeno urađeno, a ovaj dio je na "3", onda će rezultat projekta biti u najboljem slučaju "3", ili će čak i projekat propasti. To su oni kojima ćemo se detaljnije pozabaviti u drugom članku, koji će biti uključen u 5. izdanje mailing liste. Upravo na ovom mestu važi „pravilo tri svojstva zahteva“ o kome sam govorio. Zahtevi za vrste bezbednosti

GOST razlikuje sljedeće vrste:

• Matematički
• informativni
• Lingvistički
• Softver
• Technical
• metrološki
• Organizacijski
• metodički
• i drugi…

Na prvi pogled može izgledati da ovi zahtjevi nisu važni. Ovo važi za većinu projekata. Ali ne uvek. Kada opisati ove zahtjeve:

• Nije donesena odluka na kojem će jeziku (ili platformi) biti razvoj;
• Sistem podliježe zahtjevima višejezičnog sučelja (na primjer, ruski / engleski)
• Za funkcionisanje sistema potrebno je stvoriti posebnu jedinicu ili zaposliti nove radnike;
• Da bi sistem funkcionisao, Kupac mora proći kroz promene u metodama rada i te promene moraju biti specificirane i planirane;
• Pretpostavlja se integracija sa nekom opremom i na nju se postavljaju zahtjevi (na primjer, certifikacija, kompatibilnost, itd.)
• Moguće su i druge situacije, sve zavisi od konkretnih ciljeva projekta.

Odjeljak 5. Sastav i sadržaj rada na kreiranju sistema

Odjeljak 6. Procedura za kontrolu i prihvatanje sistema

Opšti uslovi za prijem radova po fazama (spisak preduzeća i organizacija koje učestvuju, mesto i termin), procedura za ugovaranje i odobravanje prijemne dokumentacije; toplo preporučujem da preuzmete odgovornost za proceduru primopredaje radova i proveru sistema. To je ono čemu služe provjerljivi zahtjevi, ali čak ni prisustvo provjerljivih zahtjeva možda neće biti dovoljno tokom isporuke sistema, ako procedura za prihvatanje i prijenos rada nije jasno navedena. Na primjer, uobičajena zamka: sistem je gotov, potpuno je funkcionalan, ali Kupac iz nekog razloga nije spreman za rad u njemu. Ti razlozi mogu biti bilo koji: jednom su se ciljevi promijenili, neko je odustao, itd. I kaže: “Pošto još ne radimo u novom sistemu, ne možemo biti sigurni da funkcionira.” Zato naučite ispravno identificirati faze rada, načine za provjeru rezultata ovih faza. Štaviše, takve metode moraju biti jasne Kupcu od samog početka. Ako su oni fiksirani na nivou Projektnog zadatka, onda ih uvijek možete kontaktirati ako je potrebno i završiti posao s prijenosom.

Odjeljak 7. Zahtjevi za sastav i sadržaj rada za pripremu objekta automatizacije za puštanje sistema u rad

Mogu postojati neka druga pravila za unos informacija koje je kompanija usvojila (ili planira). Na primjer, ranije su se podaci o ugovoru unosili kao tekstualni red u proizvoljnom obliku, a sada se traži zasebno broj, posebno datum itd. Takvih uslova može biti mnogo. Neki od njih se mogu uočiti uz otpor osoblja, pa je bolje sve takve slučajeve registrovati na nivou zahteva za redosled unosa podataka Promene koje je potrebno izvršiti u objektu automatizacije

Stvaranje uslova za funkcionisanje objekta automatizacije, pod kojima je zagarantovana usklađenost kreiranog sistema sa zahtevima sadržanim u TOR-u, sve promene koje mogu biti potrebne. Na primjer, kompanija nema lokalnoj mreži, zastarjela flota računara na kojima sistem neće raditi.

Možda neke potrebne informacije obrađeno na papiru, a sada se mora unijeti u sistem. Ako se to ne uradi, onda neki modul neće raditi itd.

Možda je nešto pojednostavljeno, ali sada o tome treba detaljnije voditi računa, pa neko mora prikupljati informacije po određenim pravilima.

Ova lista može biti duga, pogledajte konkretan slučaj vašeg projekta Stvaranje odjela i službi neophodnih za funkcionisanje sistema;

Rokovi i procedure za zapošljavanje i obuku osoblja O tome smo već razgovarali ranije. Možda se sistem razvija za novu strukturu ili vrstu djelatnosti koja prije nije postojala. Ako nema odgovarajućeg kadra, pa čak i obučenog, sistem neće raditi, ma koliko kompetentno nije izgrađen.

Odjeljak 8 Zahtjevi za dokumentaciju

Razmislite kako će biti predstavljeni korisnički vodiči.

Možda je Kupac prihvatio korporativne standarde, pa ga morate kontaktirati.

Ignoriranje zahtjeva za dokumentacijom vrlo često dovodi do najneočekivanijih posljedica na projekte. Na primjer, sve je urađeno i sve radi. Korisnici također znaju kako raditi. Nismo se uopšte dogovorili oko dokumentacije i nismo razgovarali. I odjednom, kada se posao preda, jedan od top menadžera Kupca, koji nije ni učestvovao u projektu, ali učestvuje u prijemu posla, pita vas: „Gde su uputstva za upotrebu?“ I on vas počinje uvjeravati da nije bilo potrebno dogovarati se o dostupnosti korisničkih priručnika, to se "samo po sebi" navodno podrazumijeva. I to je to, on ne želi da uzme tvoj posao. O čijem trošku ćete izraditi smjernice? Mnogi timovi su već nasjeli na ovu udicu.

Odjeljak 9 Izvori razvoja

Stoga je bolje jednostavno se pozvati na izvještaj ankete, zahtjeve ključnih osoba.

I tako, razmotrili smo sve dijelove koji mogu biti uključeni u Projektni zadatak. „Može“, a ne „Mora“ upravo zato što svaki dokument mora biti razvijen da bi se postigao rezultat. Stoga, ako vam je očigledno da vas neka zasebna sekcija neće približiti rezultatu, onda vam nije potrebna i ne trebate gubiti vrijeme na nju.

Ali bez glavne stvari: funkcionalnih zahtjeva, niti jedan kompetentan projektni zadatak nije potpun. Želim da napomenem da se u praksi susrećemo sa takvim Projektnim zadatkom, i to kako! Postoje brojke koje će moći razrijediti vode u svim dijelovima, opišite Opšti zahtjevi uopšteno govoreći, a dokument se ispostavi da je veoma težak, i u njemu ima puno pametnih reči, pa čak i kupcu može da se dopadne (tj., on će ga odobriti). Ali možda neće biti moguće raditi na tome, tj. malo je praktične koristi od toga. U većini slučajeva takvi se dokumenti rađaju kada trebate dobiti puno novca posebno za Projektni zadatak, a to morate učiniti brzo i bez uranjanja u detalje. A pogotovo ako se zna da stvari neće ići dalje, ili će to učiniti potpuno drugi ljudi. Uglavnom, samo za razvoj budžeta, posebno državnog.

U drugom članku ćemo govoriti samo o odeljku 4 „Sistemski zahtevi“, a konkretno, formulisaćemo zahteve iz razloga jasnoće, specifičnosti i mogućnosti testiranja.

Zašto zahtjevi trebaju biti jasni, specifični i provjerljivi.

Jer praksa pokazuje: u početku se većina tehničkih specifikacija koje razvijaju stručnjaci ili ispostavi da nisu tražene (ne odgovaraju stvarnosti), ili postanu problem za onoga ko bi ih trebao implementirati, jer Kupac počinje da manipuliše nespecifičnim uslovima i zahtevima. Navest ću nekoliko primjera na koje sam fraze naišao, do čega je to dovelo, a zatim ću pokušati dati preporuke kako izbjeći takve probleme.

Da li je ovo provjerljiv zahtjev? Izgleda da jeste jednostavna stvar, ali kako to provjeriti ako nema specifičnosti?

Kako bi se to moglo preformulisati: "Iznos troškova koji je naveden u dokumentu treba rasporediti na svu robu naznačenu u ovom dokumentu srazmjerno cijeni ove robe." Bilo je jasno i konkretno. Kako provjeriti također nije teško.

Ergonomija Program bi trebao imati korisničko sučelje. Da budem iskren, morao sam se i sam jednom pretplatiti na ovu formulaciju - tada nije bilo problema za brojanje. Naravno, takve formulacije ne bi trebale biti. Nema specifičnosti, niti mogućnosti provjere ovog zahtjeva. Iako, naravno, razumljivo (subjektivno). Ovdje je nemoguće preformulisati na bilo koji način, potrebno je detaljno opisati svaki element „pogodnosti“, budući da Kupac na tome insistira. Na primjer:

• Linije se unose u dokument kako klikom na dugme "Dodaj" tako i pritiskom na tastere "ubaci", kao i unosom dela imena od strane korisnika;
• Prilikom pregleda liste robe, trebalo bi da postoji mogućnost pretraživanja po nazivu, bar kodu i artiklu;
• itd.

Razlikovanje prava pristupa Pristup podacima o dobiti treba da bude dostupan samo finansijskom direktoru Razumete? Skoro. Istina, dobit je drugačija, potrebno je pojasniti. Naravno da ne. Kako to izgleda u implementaciji? Ako je riječ o bruto dobiti, onda je potrebno ograničiti pristup podacima o cijeni nabavke, jer. inače, bruto dobit je lako izračunati, budući da su podaci o troškovima prodaje poznati širokom krugu ljudi. Kada su u pitanju prava pristupa, morate biti veoma oprezni. A ako su menadžeri prodaje motivirani bruto dobiti, onda su i ovi zahtjevi u suprotnosti jedni s drugima, jer. menadžeri to nikada neće moći provjeriti. Ako već uključujemo takav zahtjev, onda je potrebno naznačiti konkretne izvještaje i objekte sistema u kojima će se naznačiti koji dio podataka treba biti dostupan određenim kategorijama lica. I razmotrite svaki takav slučaj pojedinačno Produktivnost Izvještaj o prodaji bi trebao biti generiran za 1 minut. Da, razumijem. Čak postoji i određeno vremensko ograničenje: 1 minut. Ali nije poznato kakva je detaljizacija u ovom slučaju predviđena: za svaki proizvod, grupe proizvoda, kupce ili nešto drugo više od 1 minute, pod uslovom da broj artikala u izboru ne prelazi 5000 redova.

Nadam se da je ideja jasna. Ako imate konkretna pitanja, pišite, pokušat ću pomoći.

To in projektni zadatak bilo je više specifičnosti, ima mnogo preporuka. Postoji čak i lista riječi koje se ne preporučuju za upotrebu u projektnom zadatku. O tome zanimljivo piše K. Vigers u svojoj knjizi “Razvoj softverskih zahtjeva”. Evo najzanimljivijih i najjednostavnijih, po mom mišljenju, preporuka:

• Nemojte koristiti riječi koje imaju mnogo sinonima. Ako je potrebno, bolje je dati jasnu definiciju pojma u odjeljku Uslovi i definicije Projektnog zadatka.
• Pokušajte da ne koristite dugačke rečenice;
• Ako vam se neki zahtjev čini previše općim, on mora biti detaljan na manje, ali specifične zahtjeve;
• Koristite više dijagrama, grafikona, tabela, crteža – na taj način informacije se mnogo lakše percipiraju;
• Treba izbjegavati sljedeće riječi: “efikasno”, “adekvatno”, “jednostavno”, “razumljivo”, “brzo”, “fleksibilno”, “poboljšano”, “optimalno”, “transparentno”, “održivo”, “dovoljno” , “prijateljski”, “lako” itd. Spisak se može nastaviti, ali mislim da je ideja jasna (pokušajte sami da nastavite).

Sve što je gore napisano su važne informacije, ali ne i najvažnije. Kao što se sjećate, na početku članka sam to nazvao terminom "kamuflaža", jer. najvažnija stvar koja će zauzimati najmanje 90% vremena i složenosti rada na dokumentu je identifikacija i formulisanje zahteva. A informacije o zahtjevima i dalje moraju biti u mogućnosti prikupiti, strukturirati i formulirati. Ovo, inače, ima mnogo zajedničkog između anketiranja preduzeća i naknadnog opisa poslovnih procesa. Ali postoje i bitne razlike. Jedna od ovih ključnih razlika je prisustvo faze izgradnje prototipa budućeg sistema, ili kako ga još nazivaju „modeli informacionog sistema“.

U sledećem članku ćemo govoriti samo o tehnikama identifikacije zahteva, a takođe ćemo razmotriti šta je zajedničko između rada na prikupljanju zahteva za informacioni sistem i prikupljanja informacija za opisivanje poslovnih procesa.

Vrste poslova pri prikupljanju zahtjeva za računovodstveni sistem i informacija za opisivanje poslovnih procesa. Dio 2

U ovom dijelu ćemo govoriti o tome kako organizirati fazu rada na prikupljanju zahtjeva, od čega bi se ona trebala sastojati i koji alati se mogu koristiti. Ponavljam da su ovi radovi po fazama veoma slični anketi preduzeća u cilju opisivanja poslovnih procesa.

Kao i obično u životu:

Kako to funkcionira u većini projekata
	Kako se ovo dešava?
	Jasno je da razloga za veselje ima, pogotovo ako je projekat veliki, u tome nema ništa! Glavna stvar je da se ne veselite predugo, odgađajući početak stvarnog rada, od sada će vrijeme ići drugačije.
	Obično je ovaj proces ograničen na nekoliko sastanaka sa menadžmentom, zatim sa šefovima odeljenja. Nakon fiksiranja nekih „poriva“ od strane Kupca, oni se fiksiraju u obliku općih formulacija. Ponekad se tome doda i dostupna dokumentacija (neko je jednom pokušao da izvrši ispitivanje, dokumenti po postojećim propisima, korišćeni oblici izveštaja). Začudo, nakon toga većina implementatora sistema automatizacije radosno uzvikne: „Da, naš sistem ima sve! Pa, malo dotjerivanja i sve će raditi. Na pitanje da li je potrebno razgovarati o tome kako stvari trebaju funkcionirati (ili kako se određeni proces izvodi) s krajnjim korisnicima, odgovor je obično ne. Izraženo je mišljenje da vođa zna sve za svoje podređene. Ali uzalud... Iza toga se kriju mnoge zamke i prepreke, a isporuka posla može se pretvoriti u maraton duž staze prepreka. Kao što znate, uobičajeno je trčati maraton po ravnoj cesti, a trčanje s preprekama moguće je samo na kratkim udaljenostima (možda ga nećete trčati).
Dokumentacija o rezultatima rada	Nakon toga počinje dokumentacija rezultata u zavisnosti od ciljeva rada: Ako je potrebno izraditi Projektni zadatak, konsultant počinje širiti primljene informacije prema pripremljenom predlošku dokumenta tako da izgleda lijepo i glavni zahtjevi su fiksne (one koje se izjašnjavaju od menadžmenta, inače ih možda neće odobriti). Shvativši da se u praksi ovakav Projektni zadatak ne koristi posebno i da se sve mora smišljati „u hodu“, on postavlja kao glavni cilj Projektnog zadatka minimalno vrijeme za koordinaciju i odobrenje. I, ako je moguće, informacije za grubu procjenu troškova budućeg rada (usput, to je također važno). Ako želite da opišete poslovne procese. Čudno, ali često sve prethodne radnje izgledaju isto, kao u slučaju izrade Projektnog zadatka. Jedina razlika je u dokumentaciji. Ovdje su moguće opcije: konsultanti opisuju proces proizvoljnim riječima ili koriste bilo koja pravila za opisivanje poslovnih procesa (notacije). U prvom slučaju, takav dokument se ispostavi da je iznenađujuće sličan Projektnom zadatku. Dešava se čak i da ako zamijenite naslovnu stranicu, nećete vidjeti nikakvu razliku. formalno pridržavanje pravila opisa Nažalost, obje opcije nisu najbolja praksa, jer su više formalnost i ne donose veliku korist.

Zašto postoji takva praksa kao što je gore opisano? Priznajem da ne znam. Niko ne pita, niko ne zna. Istovremeno, situacija se ne menja brzo, iako se o ovoj temi stalno govori, razmenjuju iskustva, pišu knjige... Čini mi se da je jedan od razloga nizak kvalitet relevantnog obrazovanja. Na to može uticati i činjenica da mnogi stručnjaci dolaze iz drugih delatnosti, a sve shvataju u praksi, tj. njihovo iskustvo oblikuje okruženje u kojem se nalaze. Stav univerziteta i nedostatak njihove želje da se približe stvarnosti je takođe poznata činjenica, ali ponekad me njihov stav iznenadi. Na primjer, imao sam slučaj kada je diplomirani student, talentirani specijalista, htio napisati tezu na 1C platformi (dobar razvoj industrije), ali na odsjeku su joj rekli da će, bez obzira na temu, to biti nemoguće računati na ocjenu „odličan“, jer 1C nije ozbiljan sistem. Ovdje nije poenta u ozbiljnosti i objektivnosti takvog mišljenja, već u činjenici da je primitivan zadatak u klasičnom programskom jeziku odmah smatran vrijednim ocjene "odlično".

Pokušajmo procesu o kome smo gore razgovarali dati sistematičniji pristup. Kako bi onda mogao izgledati?

Kao što vidite, proces se završava pitanjem, jer na ovome, posao je daleko od kraja, a onda će početi najteže i najpraktičnije - upravo ono što će odrediti primjenjivost dobivenog rezultata u stvarnom životu. To je upravo ono što će odrediti sudbinu prethodnog rada: ili će otići u ormar (na policu ili negdje drugdje), ili će biti vrijedan izvor informacija. A još bolje ako postane model za buduće projekte.

Želim da istaknem da do posljednjeg koraka u dijagramu (gdje je pitanje) opšti princip prikupljanja informacija o aktivnostima kompanije izgleda isto, bez obzira na to šta se planira uraditi u budućnosti, opisati poslovne procese ili implementirati automatizovani sistem. Da, sam slijed koraka je isti, ali alati koji se koriste na nekim od njih mogu se razlikovati. Mi ovog trenutka svakako razmotrite kada proučavamo metode i alate pojedinih faza. To ćemo detaljno učiniti u zasebnim člancima, ali sada ćemo razmotriti samo najvažnije. Dalji koraci će se razlikovati i biti će određeni onim što se traži od projekta: opisati poslovne procese ili implementirati računovodstveni sistem.

Hajde da vidimo kako možete reorganizovati pristup prikupljanju informacija o aktivnostima kompanije.

Kako se ovo može dogoditi sa više nadležna organizacija radi
	Kako se ovo dešava?
Odluka je donesena, projekat će biti!	Ovdje se ništa ne mijenja u pogledu prve opcije, niko nije otkazao emocije
Održali smo sastanak sa čelnicima, prikupili neke informacije o njihovoj viziji rezultata.	I ovaj korak ostaje, i on je od velike važnosti. Ali glavna svrha prvog sastanka (ili nekoliko sastanaka) sa menadžerima i vlasnicima je upoznavanje. Upoznavanje prije svega sa ljudima i kompanijom. Formulirani ciljevi i želje na ovakvim generalnim skupovima mogu biti vrlo različiti, uključujući i fantastične. Svi će se, naravno, čuti, ali ne i činjenica da će biti sprovedeni. Sa dubljim uranjanjem u poslovanje kompanije, pojaviće se i drugi ciljevi, ali i prethodni će biti odbačeni. Mislim da je nemoguće formulisati jasne ciljeve sa preliminarnih sastanaka, sve će to zahtevati pažljivo proučavanje.Na takvim sastancima je potrebno izneti sve poruke vlasnika i najviših zvaničnika, da bi se kasnije vratili na njih i razgovarali kada se prikupi dovoljno informacija. Čak i naizgled jednostavan zahtjev može se pokazati kao neostvariv ili vrlo naporan.
Formiranje radne grupe od Naručioca i Izvođača, raspodjela uloga	Potrebno je odlučiti ko će raditi na projektu i od strane naručioca i od strane izvođača. Uprkos prividnoj jednostavnosti ove faze, ona ima veoma važnu ulogu. Ako ne odredite jasno ko je za šta odgovoran, rizikujete da naiđete na zabunu tokom realizacije posla. Ako, sa vaše strane, uvijek možete odrediti uloge u svom timu, tada bi Kupac mogao imati problema s tim. Na šta treba obratiti pažnju: radna grupa Kupca mora nužno uključivati ​​one ljude koji će u budućnosti barem nekako utjecati na prihvaćanje rezultata. Ako pretpostavimo da će se prilikom primopredaje posla uključiti zaposlenici Naručioca koji nisu učestvovali u radu na postavljanju ciljeva i identifikovanju zahteva, onda su problemi zagarantovani. Moguća je i ovakva apsurdna situacija da se sve, ispostavilo se, ne radi kako treba.U svojoj praksi sam se više puta susreo sa takvom situacijom.mogu učestvovati u prijemu i predaji radova. I najbolje od svega, da se to propiše u ugovornim uslovima (u ugovoru ili Povelji projekta). Sjećam se da je bio jedan takav slučaj: u jednom velikom projektu osnivač je odlučio da se uključi u proces (ne znam zašto, postalo je dosadno gledati) i prisustvovao jednom od radnih sastanaka na kojem je bilo pitanje generiranja računa za klijente raspravljali. Bio je iznenađen kada je saznao da menadžer prodaje izdaje račun klijentu. Po njegovom mišljenju, računovođa treba da izda račun, i ništa drugo. Ali u stvari, računovođa nije imao pojma o čemu se radi, a menadžer nije mogao zamisliti kako da tako radi ako trči kod računovođe za svaki račun. Kao rezultat toga, izgubili smo dosta vremena, ali ništa se nije promijenilo, račun je i dalje naplaćivao menadžer. I osnivač je ostao pri svom mišljenju, ali se više nije miješao u proces. U istoj fazi, preporučljivo je izraditi Povelju projekta, koja fiksira uloge učesnika, proceduru komunikacije, pravila i sastav izvještavanja, kao i sve ostalo što bi trebalo da bude zapisano u Povelji. Izrada Povelje projekta je opet posebno pitanje.
Obuka projektnog tima o metodama i alatima rada, dogovaranje pravila rada, vrste i sastava dokumentacije	Prvo, potrebno je projektnom timu objasniti sve što piše u Povelji, kako će se primjenjivati ​​u praksi. Drugo, projektni tim Kupca treba da bude obučen za metode rada koje ćete koristiti u svim narednim fazama. Ima smisla razgovarati o formatima dokumenata koji će se koristiti, razmotriti uzorke. Ako će se primjenjivati ​​bilo koja pravila za opisivanje modela ili poslovnih procesa, onda se o ovim pravilima također mora razgovarati kako bi se razumjela.
Upitnik	Faza upitnika dozvoljava relativno brz način dobiti prilično pouzdan dio informacija o kompaniji. Kvalitetu takvih informacija određuju tri faktora: Prije svega, kako ste predavali projektni tim Kupac. Moraju jasno razumjeti kako se odvija proces anketiranja i biti u stanju da prenesu informacije svim učesnicima. Sama forma upitnika. Upitnici moraju biti razumljivi. Poželjno je da postoji uputstvo za popunjavanje upitnika. Još bolje ako postoji primjer punjenja. Spisak učesnika. Potrebno je odabrati pravi sastav učesnika. Ako se ograničimo samo na menadžere, neće biti moguće prikupiti pouzdane informacije. Preporučujem da u upitnik uključite sve koji će biti korisnici konačnih rezultata. Na primjer, ako govorimo o uvođenju automatiziranog sistema, onda vrijedi uključiti sve koji će biti korisnik. Postoje slučajevi da od 10 zaposlenih na jednoj poziciji postoji jedan koji obavlja neku posebnu funkciju za koju niko od preostalih 9 ljudi više ne zna (na primjer, priprema poseban izvještaj za menadžment). Ako govorimo o daljoj preraspodjeli odgovornosti ili izradi opisa poslova, to biste trebali učiniti i vi. Skrećem vam pažnju da je način ispitivanja za naknadnu implementaciju automatizovanog sistema ili opis poslovnih procesa u pravom slučaju drugačiji. Naravno, struktura upitnika može biti ista, ali ovo nije najviše najbolji način. Kada opisujemo poslovne procese, upitnici su obično opštije prirode, jer ne zna se tačno sa čime će se suočiti. Ako govorimo o uvođenju konkretnog automatizovanog sistema, onda je bolje imati upitnike koji uzimaju u obzir karakteristike ovog sistema. Ovim pristupom možete odmah identifikovati sva uska grla sistema koja nisu prikladna za ovo preduzeće. Po pravilu, metode za implementaciju gotovih sistema omogućavaju dostupnost takvih upitnika. Takvi upitnici mogu se razviti ili za pojedinačna područja računovodstva (na primjer, računovodstvo narudžbi, prodaja, cijene), ili za specifične pozicije(finansijski direktor, na primjer). Sastav pitanja je otprilike isti.
Ankete	Anketa je usmeni razgovor sa stručnjacima kako bi se saznale karakteristike pojedinih procesa. Anketu je potrebno organizovati tako da ne liči na samo "meet-talk", već organizovanije. Za to je potrebno pripremiti tzv. anketni plan. U njega možete uključiti one dijelove upitnika koji vam postavljaju pitanja, koji su u suprotnosti sa podacima drugih upitnika ili su informacije predstavljene površno. Preporučljivo je dodati pitanja i to samo iz ličnog iskustva.Odgovori moraju biti izneseni bez greške. Idealno, ako se složite oko audio snimka. U istoj fazi potrebno je pratiti kompletnost datih informacija o toku rada (i forme primarnih dokumenata i razni izvještaji)
Identifikacija ključnih poslovnih procesa ili područja automatizacije	Nakon upitnika i ankete, s razlogom se može smatrati da postoji dovoljno informacija za donošenje zaključaka o raspodjeli ključnih poslovnih procesa. Zapravo, već je moguće izdvojiti ne samo ključne poslovne procese, već gotovo sve (ako je sastav učesnika pravilno odabran). Pitanje identifikacije poslovnih procesa je sasvim zasebna i nije jednostavna tema. Učenje ovdje je teško i razvija se uglavnom iskustvom. Od odabranih poslovnih procesa treba sastaviti listu (klasifikator). Tada će biti moguće odlučiti koje od njih treba detaljnije istražiti, a koje ne, kao i odrediti prioritete.
Formulacija ključnih sistemskih zahtjeva, ciljeva, kriterija uspješnosti projekta, procesa za detaljnu studiju	Do ove faze treba prikupiti sve primarne informacije o aktivnostima kompanije, sastaviti listu poslovnih procesa. Sada je vrijeme da se vratimo ciljevima, preciziramo ih, ako je potrebno, razgovaramo sa prvim osobama kompanije. Prilikom formulisanja ciljeva treba uzeti u obzir specifične indikatore, po dostizanju kojih ćemo smatrati da je projekat uspješan. Ako govorimo o uvođenju automatiziranog sistema, onda se posebnom listom mogu istaknuti zahtjevi za sistem od strane ključnih korisnika. To radim u obliku posebne tabele, gdje su svi zahtjevi grupisani po podsistemima, za svaki zahtjev je naznačen autor zahtjeva, formulacija i prioritet. Ove informacije se mogu koristiti za izradu plana implementacije sistema (redosled implementacije pojedinih podsistema), kao i za predloge za dalji razvoj sistema (ako se ne planira implementacija pojedinih podsistema u aktuelnom projektu). Ukoliko je potrebno opisati poslovne procese, donose se odluke o onim procesima koje je potrebno detaljnije proučiti.

Tako smo došli do pitanja “Šta dalje?”. Nadalje, posebno ćemo razmotriti zadatke opisivanja poslovnih procesa i izrade Projektnog zadatka. Nije slučajno što ove zadatke razmatram paralelno. Zaista ima dosta zajedničkog među njima, što želim da pokažem. Prvo razmotrite redoslijed rada u opisivanju poslovnih procesa.

	Šta i kako učiniti
Odabir poslovnog procesa	Od opšta lista od poslovnih procesa dobijenih u prethodnim fazama, izdvajamo jedan (po prioritetu) za detaljnije proučavanje. Zatim radimo isto sa ostalima.
Detaljna studija poslovnog procesa	Odabrani poslovni proces podvrgavamo detaljnoj studiji: analiziramo primljene primarne dokumente, izvještaje i njihovu strukturu koja se koristi u procesu programa, razne fajlove (npr. Excel), razgovaramo sa krajnjim izvršiocima. Sakupljanje razne ideje o tome kako se proces može poboljšati. Veoma je korisno ako možete posmatrati proces tačno u uslovima u kojima se izvodi (malo ljudi ne voli da ih gleda, ali šta da radite)
Grafički i/ili tekstualni opis poslovnog procesa (primarni)	primljeno detaljne informacije počinjemo s opisom Prije opisa procesa potrebno je odlučiti da li će za njega biti potreban grafički opis. Ako je proces jednostavan i razumljiv, ima malo funkcija u njemu, a grafički prikaz neće poboljšati njegovo razumijevanje ili percepciju, onda nema potrebe gubiti vrijeme na to. U ovom slučaju, dovoljno ga je opisati u tekstualnom obliku u obliku tabele. Ako je proces složen, sa različitim logičkim uslovima, onda je bolje dati njegov grafički dijagram. Dijagrame je uvijek lakše razumjeti. Ako odlučite da proces opišete u grafičkom obliku, to uopće ne znači da ne morate dati njegov tekstualni opis. One. tekstualni opis procesa u svakom slučaju treba da bude i napravljen prema istoj šemi. Pogodno je to učiniti u obliku tabele u kojoj se naznačuju: izvođači svakog koraka, koje informacije dobijaju na ulazu, opis svakog koraka, koje informacije se generišu na izlazu. U nastavku ćemo vidjeti primjer kako bi ovo moglo izgledati.
Koordinacija sa izvođačima i vlasnikom poslovnog procesa	Najbolji način da shvatite koliko ste dobro odabrali stil prezentovanja informacija jeste da pokažete rezultat korisnicima (izvršiocima) procesa.Najvažnije u takvoj demonstraciji je da shvatite koliko ste ispravno shvatili kako se proces izvodi. Ako je obuka projektnog tima bila uspješna, onda možete očekivati ​​sasvim adekvatnu povratnu informaciju od izvođača. A ako se zainteresuju, onda će se sve početi kretati mnogo brže.Uočena pojašnjenja i nedosljednosti moraju se odraziti u opisu (ažurirati), ako je potrebno, ponovite operaciju.
Identifikacija indikatora poslovnih procesa	Nakon što ste dobro razumjeli kako se poslovni proces izvršava, morate razmišljati o metrikama koje mogu mjeriti kvalitet ili brzinu procesa. Nije lako, ali neophodno. Indikator mora biti mjerljiv, tj. izraženo u numeričkim terminima i trebao bi postojati lak način da se dobije ova vrijednost. Ako se izmjereni indikator ne može identificirati, postoji rizik da je poslovni proces loše identificiran. Osim toga, neće biti moguće razumjeti (jer se ne može izmjeriti) da li će promjene procesa dovesti do njegovog poboljšanja ili ne.
Završna dokumentacija poslovnog procesa	Nakon što se uvjerimo da razumijemo kako je proces (ili bi trebao biti) obavljen, možemo ga uključiti u dokumentaciju.
	Moguće su i dalje opcije: procesi koji se razmatraju biće analizirani, optimizovani, razvijeni opisi poslova, donose se odluke o potrebi automatizacije pojedinih procesa itd. Može biti i poseban projekat: opis poslovnih procesa.

Sada razmotrimo kako će izgledati pristup proučavanju zahtjeva za informacioni sistem sa njihovim daljim odrazom u Projektnom zadatku

	Šta i kako učiniti
Isticanje poslovnog zahtjeva/područja automatizacije	Izdvajanje čitave oblasti automatizacije kao zahtjeva (na primjer, „Inventar“) se koristi u praksi, međutim, ovo nije najefikasniji način za detaljiziranje zahtjeva. Područje automatizacije je grupa zahtjeva i bolje ih je razmotriti pojedinačno. Na primjer, "Obračun prijema robe u skladište"
Detaljna studija zahtjeva poslovanja	Detaljna studija poslovnog zahtjeva podrazumijeva kako ga krajnji korisnik želi vidjeti i kako će ga koristiti (naravno, u skladu sa ciljevima projekta). U tehnologijama razvoja softvera, ovo se često naziva "slučaj upotrebe". Stoga se detaljna studija poslovnog zahtjeva svodi na razvoj slučajeva korištenja. Primjer takve opcije dat je u Dodatku 2 ovog članka. U najjednostavnijim slučajevima uopće nije potrebno crtati slučajeve upotrebe u obliku grafičkih dijagrama, možete se ograničiti i na tekstualnu formulaciju. Na primjer, zahtjev "Prilikom unosa artikla cijena treba izračunati kao kupoprodajna cijena + 20%" nema smisla izvlačiti. U obliku dijagrama ima smisla prikazati zahtjeve kombinovane do obima automatizacije, kao što je prikazano u primjeru u Dodatku 2.
Modeliranje zahtjeva u informacionom sistemu	Evo ga! Kao što se vjerovatno sjećate, već sam obratio pažnju na ovaj najvažniji element u metodologiji izrade Projektnog zadatka. "Izgradite model - dobijte rezultat!" Šta treba modelirati? Potrebno je modelirati slučajeve upotrebe dobijene u prethodnoj fazi. Kakav bi trebao biti rezultat simulacije? Trebali biste dobiti demo program u koji se unose podaci o korisniku, a po mogućnosti poznat njegovom (korisničkom) sluhu, uzimajući u obzir specifičnosti industrije, trenutne probleme. I ne samo uneti, nego treba da bude jasno odakle su ti podaci, kako su izračunati. U ovom trenutku, čitatelj bi trebao imati pitanja: Ali šta ako se planira razvoj novog sistema i jednostavno nema šta da se modelira? Šta ako nema dovoljno funkcionalnosti za demonstraciju, a sistem treba poboljšati? Naravno, morate se suočiti sa takvom situacijom, i to je normalno. sta da radim? Ako je sistem potpuno nov (kako kažu "od nule"), onda ćete morati modelirati uglavnom na papiru, ovdje će vam dijagrami slučajeva puno pomoći. Djelomično, ima smisla skicirati neke od ekranskih formi koje bi trebalo da se razvijaju (pravo u okruženju u kojem će se odvijati razvoj), jer. crtanje u nekom editoru će trajati duže i ovaj posao je dosadan. Ako se implementira gotov sistem, a nedostaje mu funkcionalnost, onda nema razloga za brigu, podaci se unose ručno, a korisniku se kaže da nakon potrebnih poboljšanja treba računati ovako i onako (i on to vidi). Takav model je poželjno popratiti tekstualnim opisom, čak i ako je kratak, kako bi korisnik mogao samostalno pokušati raditi s modelom u slobodno vrijeme. U istom opisu možete formulirati zahtjeve za poboljšanja.
Demonstracija informacionog modela radnoj grupi	Dobijeni model pokažemo Kupcu i kažemo kako sve treba da funkcioniše.Model je bolje demonstrirati po podsistemima, tj. prema grupi zahtjeva. Ako se ispostavi da predložena shema neće raditi za klijenta, morate razmisliti o drugim slučajevima korištenja, napraviti promjene u modelu i ponovo ga prikazati. Samo ako postoji uverenje da će planirani model „živeti” sa datim klijentom, model se može smatrati uspešnim.
Razvoj testa	Zašto su potrebni testovi? Kako smo uspjeli da implementiramo zahtjeve, morat će se provjeriti. Shodno tome, poželjno je uraditi testove za sve ključne oblasti, složene algoritme itd. Uključujući ovi testovi se mogu koristiti tokom izvođenja radova. Uopšte nije potrebno raditi testove za svaku funkciju sistema, svuda bi trebalo da postoji zdrav razum. Ako govorimo o gotovom sistemu, onda će izvođenje testa za "unošenje novog elementa u korisnički imenik" izgledati glupo i gubljenje vremena i truda. Ali ako je ovo potpuno nov sistem, to je sasvim moguće. Zašto testirati ako još nema sistema?Prvo, programeru će biti jasnije šta žele da postignu od njega. Drugo, olakšavamo život testeru (na kraju krajeva, neko će testirati rezultat razvoja). Općenito, testiranje je posebna disciplina, ne baš jednostavna s mnogo metoda. U praksi se, po pravilu, i dalje koriste najjednostavnije metode ispitivanja.
Dokumentacija zahtjeva u formi Projektnog zadatka	Informacije prikupljene u prethodnim fazama će biti upravo ono što bi trebalo da bude uključeno u osnovu dokumenta "Terms of Reference" u odeljku sa zahtevima, tako da ostaje da se sve ovo pravilno uredi.
Dalje radnje (ili nedostatak istih), ovisno o ciljevima projekta	Proces razvoja, traženje partnera za projekat, tender itd. može potrajati duže, sve zavisi od situacije.

Da, izrada Projektnog zadatka je dugotrajan proces, a samim tim i skup. Ali ako se to uradi kako treba, to spašava Kupca od neispunjenih očekivanja. Izvođač mora da uradi ono što naručilac zahteva i da ne ponavlja istu stvar sto puta. I općenito, daje transparentnost cijelom projektu.

Dodatak 1. Opisani poslovni proces u EPC notaciji.

Definisanje obima projekta, izrada tehničkih specifikacija

Ovaj dio ukratko govori o razvoju projektnog zadatka (u daljem tekstu TOR). Najprije je data definicija TK-a, opisane su prednosti TK-a i za kupca i za izvođača radova, te su navedene glavne funkcije TK-a. Dalje, razmatra se šta je suština TK, otkriva se struktura i sadržaj TK, a daju se i primjeri strukture TK. U zaključku se navode karakteristike TOR-a inovativnih projekata.

Budući da zadaci izrade tehničkih specifikacija za inovativni projekat, koji imaju svoje karakteristike, u principu ostaju isti kao i kod izrade bilo koje tehničke specifikacije, prvo je razmatrano pitanje razvoja tehničkih specifikacija u cjelini.

Definicija

Treba napomenuti da u ovom trenutku ne postoji standardizovana definicija projektnog zadatka (TOR) za inovativni projekat. U trenutnoj bazi podataka nacionalnih standarda postoje tri standarda vezana za TK. Svi oni pripadaju oblasti informacionih tehnologija:

GOST 19.201-78. Jedinstveni sistem programske dokumentacije. Tehnički zadatak. Zahtjevi za sadržaj i dizajn.

GOST 25123-82. Računalne mašine i sistemi za obradu podataka. Tehnički zadatak. Redoslijed izgradnje, prezentacije i dizajna.

GOST 34.602-89. Informaciona tehnologija. Set standarda za automatizovane sisteme. Projektni zadatak za kreiranje automatizovanog sistema.

Na primjer, u "GOST 19.201-78. Jedinstveni sistem programske dokumentacije. Tehnički zadatak. Zahtjevi za sadržaj i format“ data je sljedeća definicija TOR-a: „Zahtjev za rad za automatizirani sistem je propisno odobren dokument koji definira ciljeve, zahtjeve i osnovne početne podatke potrebne za razvoj automatiziranog sistema i sadrži preliminarnu ocjenu ekonomske efikasnosti.”

Kaže da TK dozvoljava:

izvođaču - da razume suštinu zadatka, da pokaže kupcu "tehnički izgled" budućeg proizvoda, softverskog proizvoda ili automatizovanog sistema;

kupac - da shvati šta mu je tačno potrebno;

obje strane - da prezentiraju gotov proizvod;

izvršiocu - da planira realizaciju projekta i rad po planu;

kupcu - zahtijevati od izvođača da proizvod ispunjava sve uslove navedene u TOR-u;

izvođaču - da odbije izvođenje radova koji nisu navedeni u TOR;

kupcu i izvođaču - da izvrši provjeru gotovog proizvoda od tačke do tačke (prihvatno ispitivanje - izvođenje testovi);

izbjegavajte greške povezane s promjenom zahtjeva (u svim fazama i fazama kreiranja, s izuzetkom testovi).

Dakle, projektni zadatak je dokument koji sadrži skup zahtjeva i omogućava i programeru i kupcu da predstave finalni proizvod i naknadno provjere usklađenost sa zahtjevima.

Što je TOR detaljniji, to će se manje sporova pojaviti između kupca i programera tokom testova prihvatanja.

TK obavlja četiri glavne funkcije:

Pravni. TK je pravni dokument, a kao aplikacija je uključen u ugovor između naručioca i izvođača.

Organizacijski. Uz pomoć TK-a, možete pojednostaviti dalji rad, pretvorite ga u red (šemu) zadataka i ne gubite trud na nepotrebne radnje.

Informativno. Dobro napisan TOR može biti dobar izvor informacije potrebne za završetak projekta. Strukturiranje TK vam omogućava da imate informacije koje su zaista zanimljive, u obliku koji se najlakše percipira iu količini koja je neophodna za završetak posla.

Komunikativna. Detaljan TOR pomaže izvođaču da bolje razumije potrebe kupca i izvrši posao koji zadovoljava sve njegove ukuse. Ovo također olakšava proces odobravanja projekta.

Esencija TK

Rad na TOR-u znači da se pretpostavlja rješenje nekog zadatka i opisano je korak po korak u ovom dokumentu. TK se može razviti za bilo šta: za kreiranje tehnologije, novog materijala, uređaja, web stranice, programa, standarda, implementaciju događaja itd.

Konačni rezultati dobijeni tokom realizacije projekta mogu biti materijalni (materijali, proces, tehnologija), organizacioni (norma, standard), naučno-tehnički i naučno-metodološki (projektna dokumentacija, izvještaj o istraživanju, obrazovni program), nematerijalni (patenti, monografije, članci) i drugi oblici.

Suština TK-a je uspješno izvršenje zadatka. Što će TOR biti bolje i bolje sastavljen, to će zadatak biti efikasnije izvršen. Štaviše, to ne zavisi od njegovog obima. Nepravilna izrada TOR-a može imati posljedice, na primjer, nepredvidivost rezultata, posao neće biti obavljen onako kako je trebao biti obavljen od strane kupca ili neće biti urađen uopće. Naručilac posla neće dobiti ono što je želio i ima pravo da ne plati urađeni posao.

Rad na TK je teška i odgovorna faza, jer mnogi podaci još nisu poznati. Uspjeh projekta, prema stručnjacima, za 50-70% zavisi od kvalifikovane implementacije faze razvoja TOR-a.

Po pravilu, fazi izrade tehničkih specifikacija prethodi proučavanje predmetne oblasti, proračuni i modeliranje.

Odgovoran rad na TK-u omogućit će njegovim programerima da vide scenario za završetak zadatka. Jasno shvatite svoje prednosti i slabe strane kako živjeti proces izvršavanja zadatka. Odredite kriterijume, postavite indikatore, karakteristike, količine, procenite resurse.

TK se dogovara sa kupcem ili razvija zajednički.

Uprkos svom značaju, sadržaj i struktura TK-a praktično nisu regulirani regulatornim dokumentima.

Obično kupac postavlja cilj (kako ga on razumije) i ograničenja resursa (vrijeme, novac). Zadatak izvođača je, prije svega, da zahtjeve prevede na jezik predmetne oblasti, što potpunije i kompetentnije formuliše zadatak, opravda potrebu za njegovim rješavanjem, shvati i razjasni početne podatke. Sadržaj Projektnog zadatka treba da sadrži informacije koje se odnose na ciljeve i obavljanje funkcija kojima se realizuju određene potrebe, a koje su uvijek povezane sa zadovoljenjem određenih zahtjeva.

Rad sa zahtjevima podliježe menadžmentu. Nesigurni zahtjevi izazivaju nesigurnost kod svih učesnika u radu, jer dozvoljavaju različita tumačenja zahtjeva i neće omogućiti objektivnu ocjenu kvaliteta proizvoda koji se razvija.

Prilikom formiranja sistema zahtjeva potrebno je analizirati dostupnost resursa koji su na raspolaganju naručiocu i izvođaču: finansijski, proizvodni, kadrovski, privremeni, kao i uzimajući u obzir zahtjeve nadzornih i licencnih organa, npr. , pri projektovanju tehnoloških kompleksa (proizvodnja). Najčešće kontrolišu regionalni organi Rostekhnadzor, Rosstandart, Rospotrebnadzor, Rosprirodnadzor itd.

Slijede primjeri strukture TK iz različitih izvora.

Na primjer, TK može sadržavati odjeljke:

predmet TK;

svrha posla koji se obavlja;

zahtjevi za izvještavanje;

red organizacije rada;

Primjer iz gore navedenog GOST 19.201-78.

uvod;

osnove za razvoj;

svrha razvoja;

zahtjevi za program ili softverski proizvod;

zahtjevi za softversku dokumentaciju;

tehničko-ekonomski pokazatelji;

faze i faze razvoja;

postupak kontrole i prihvatanja;

dozvoljeno je uključivanje aplikacija u projektni zadatak.

Sljedeći primjer TOR-a za pružanje konsultantskih usluga

opšte odredbe;

svrha rada;

kvalifikacioni uslovi za kandidate.

Primjer projektnog zadatka za implementaciju istraživačkog rada "Razvoj koncepta, strategije razvoja i studije izvodljivosti za stvaranje tehnološkog i inovacionog parka u gradu Permu" (u daljem tekstu: R&D)

osnova za istraživanje

izvođača i saizvođača

1. istraživački zadaci

   početni podaci

   osnovni zahtevi za sprovođenje istraživanja

   kalendarski plan za realizaciju istraživanja

   namjeravanu upotrebu rezultata istraživanja

   postupak dostavljanja i prihvatanja rezultata istraživanja

Primjer strukture TOR predloška za istraživanje i razvoj

Osnova za rad

Izvršitelj

Uslovi rada

Svrha rada

Rezultati istraživanja i razvoja

Proizvodi u razvoju

Tehnički zahtjevi

Glavni parametri koji se trebaju postići kao rezultat rada:

Osnovni zahtjevi dizajna (ako je primjenjivo)

Zahtjevi prema vrstama kolaterala (ako je primjenjivo)

Zahtjevi za standardizaciju, unificiranje, kompatibilnost sa objektima parenja i zamjenjivost.

Zahtjevi za obezbjeđivanje sigurnosti za život i zdravlje ljudi i zaštitu životne sredine

Zahtjevi za pouzdanost (ako je primjenjivo)

Zahtjevi za pouzdanost i trajnost.

Zahtjevi ergonomije i tehničke estetike (ako je primjenjivo)

Zahtjevi za rad, udobnost Održavanje i mogućnost održavanja (ako je primjenjivo)

Zahtjevi otpornosti (ako je primjenjivo)

Zahtjevi za performanse (ako je primjenjivo)

Zahtjevi za certifikaciju

Ostali zahtjevi i posebni zahtjevi industrije

Zahtjevi za čistoću patenta i patentabilnost

Zahtjevi za dokumentaciju

Redoslijed prijema radova.

Dakle, analizirajući strukturu u datim primjerima, može se primijetiti da strukturu i sadržaj TK diktira zadatak koji treba obaviti.

Značajke razvoja tehničkih specifikacija za inovativni projekat

Inovativni projekti su jedinstveni događaji jer su povezani s transformacijom naučnih i tehničkih ideja u nove ili poboljšane proizvode, kao i u nove ili poboljšane tehnološke procese koji se koriste u praktičnim aktivnostima, odnosno u nove pristupe socijalnim uslugama. Morate učiniti nešto što nikada prije nije urađeno. A prošlo iskustvo može dati samo ograničenu naznaku šta očekivati. Stoga inovativni projekti imaju visok stepen neizvjesnosti i rizika i to je njihova posebnost.

Razvoj inovativnog projekta ima za cilj pronalaženje rješenja za dobivanje predviđene konačne ideje projekta i kreiranje skupa zadataka i aktivnosti koje će vremenski, resursi i izvođači povezati za realizaciju ovog inovativnog projekta. Svaki inovativni projekat tokom svoje implementacije prolazi određeni put: od faze razvoja ideje do faze nebitnosti ideje. Faza izrade tehničkih specifikacija odnosi se na početnu fazu inovativnog projekta.

U inovativnom projektu, kada kreirate potpuno novi proizvod teško je unaprijed planirati sve parametre, stoga se predlaže korištenje dinamičkog proširenog TOR-a, koji je uglavnom deskriptivan.

Prvi korak nakon što se generira ideja o novom proizvodu je katalog zahtjeva, koji može uključivati ​​zahtjeve kupaca, segmentaciju tržišta za novi proizvod, norme, standarde, ukupne ciljeve (udio na tržištu, troškovi), vrijeme izlaska na tržište, životni ciklus, ukupni rizik procjena.

Indikatori navedeni u katalogu zahtjeva navedeni su u dokumentu koji se naziva proširenim projektnim zadatkom.

Ako je katalog zahtjeva sastavljen na „jeziku kupaca“, onda je prošireni TOR na „jeziku preduzeća“. Prošireni TOR bi, pored tradicionalnih stavki (obim posla, izvještavanje, početni podaci, zahtjevi parametara, itd.) trebao uključivati ​​i neke elemente poslovnog plana projekta (procijenjena politika cijena, planirani tržišni udio, planirani promet itd.) .) .

Budući da se katalog zahtjeva kreira sa stanovišta klijenta, jezik za pisanje kataloga zahtjeva se također bira tako da bude razumljiv klijentu (bez specifičnih tehničkih detalja). Katalog zahteva odražava predloge preduzeća kao odgovor na potrebe kupaca.

Prošireni TOR može uključivati:

1. Opis projekta

2. Tržišni i ekonomski ciljevi projekta

3. Vremenski parametri

4. Tehnički parametri

5. Proizvodni parametri

8. Zahtjevi za dizajn i ergonomiju

9. Standardi i propisi

Stoga je glavni zadatak sastavljanja proširenog TOR-a prikupiti najviše potpune informacije o proizvodu koji se razvija, od kojeg se odbijaju prilikom planiranja.

Proširene TOR informacije su dalje specificirane u smislu strukture proizvoda, što je lista svih komponenti koje će činiti rezultat projekta. Plan strukture rezultata projekta sadrži sve komponente, blokove, čvorove proizvoda koji se kreira.

Najvažniji elementi zadatka su: svrha rada, obim rezultata, sadržaj rada, program za njegovu realizaciju, tehnički, ekonomski i drugi pokazatelji, zahtjevi za rad, nivo i način rada. njegove implementacije, rezultate rada, naučnu, naučnu, tehničku i praktičnu vrijednost očekivanih rezultata; namjeravanu upotrebu rezultata i vrstu, oblik prezentacije izvještajnog materijala.

Razmotrite mjesto TK-a u strukturi inovacioni proces u organizaciji(inovacija u organizaciji) prema .

U početku se razvija koncept inovacije. Kojem prethodi faza istraživanja (istraživanje organizacije, izbor indikatora učinka za njene predstojeće inovacione aktivnosti, opravdanje liste aktivnosti neophodnih za implementaciju inovacija). Koncept inovacije formiranog razvojnog tima razvija se u zadatak (TOR) za razvoj inovativnog projekta, koji treba da sadrži sva opravdanja, početne postavke i parametre potrebne za naknadno projektovanje.

Na osnovu zadatka za izradu inovativnog projekta izrađuje se detaljan akcioni plan za izradu i rešavanje pojedinačnih zadataka, kao i za praćenje njihove realizacije (kontrolne tačke po rokovima, lista kontrolisanih parametara, kontrolni kriterijumi). itd.). Zapravo, projektni zadatak, akcioni plan su osnova za razvoj inovativnog projekta.

Sadržaj projekta je opis i regulativa planiranih aktivnosti, proračuni optimalnog korišćenja resursa, procjena očekivanih rezultata realizacije, dovedeni do kvantitativnih vrijednosti. Osnova inovativnog projekta je njegov organizacioni i finansijski dio. Zatim slijede faze adaptacije i implementacije projekta i analiza rezultata projekta.

Kada se TOR kao dokument odobri, vrši se planiranje rada na projektu.

„Hteo sam da napravim grmljavinu, ali dobio sam kozu...“, pomislite, prihvatajući potpuno novu lokaciju od programera. Čini se da je izvođač izabran na preporuku. A njegov portfolio ulijeva povjerenje. I nije prva godina. I dalje nije uradio ono što ste zamislili. A sada ste već razočarani u graditelje sajtova i sigurni ste da ste okruženi lopovima i amaterima.

U međuvremenu, ne samo izvođač, već i kupac je odgovoran za rezultat bilo kojeg delegiranja.

Ispravno sastavljeni projektni zadaci za kreiranje web stranice pomoći će u smanjenju rizika i povećati vjerojatnost da dobijete internetski resurs svojih snova.

Zašto je potrebna specifikacija?

• Izvođač kompetentna tehnička specifikacija za razvoj stranice pomoći će unaprijed procijeniti količinu posla, njegovu složenost i cijenu. Da shvati hoće li se sam nositi s takvim zadatkom ili je vrijedno uzeti pomoćnike. I onda uradite tačno ono što kupac očekuje od njega.
• Kupac projektni zadatak daje povjerenje da je dokumentovao svoje želje za buduću lokaciju, jasno naznačio rokove koje izvođač mora ispoštovati, propisao uslove za lokaciju. A ako je rezultat nezadovoljavajući, možete dati valjanu tvrdnju: "Ne ispunjava TOR!"

Kako izgleda projektni zadatak za stranicu?

Tvoja želja “blog sa besplatnim sadržajem, stranicom o meni i kontaktima” izvođač vidi ovo:

Mislite li da je ovo dovoljno za kreiranje web stranice?

Dobijate gotovu stranicu, a onda se odjednom ispostavi da ste mislili ovo:

Nijanse opisa su veoma važne

Osjetite razliku? Formalno, obje strane ovdje griješe: niste dodali detalje, izvođač nije pitao za njih. Ali on je već primio uplatu i spreman je da nestane s njom, a vi imate nedovršenu web stranicu, neočekivane troškove i potpuno razočarenje u kreatore web stranica.

Predlažem da se stvari ne dovode u takve krajnosti, već da se pripremi projektnog zadatka za stranicu pristupi svjesno.

Šta piše u projektnom zadatku?

Projektni zadatak za stranicu je detaljan dokument koji opisuje proces vašeg odnosa sa izvođačem i rezultat njegovog rada.

Za razvoj velikih i složenih lokacija potreban je obimni i složeni tehnički zadatak, za manje lokacije i TK će odgovarati.

Veliki projekat obično ima cijeli tim izvođača koji radi na njemu. Njihove akcije moraju biti koordinirane, pa će stoga TOR za lokaciju biti prilično masivan. Ako ti ne treba veliki broj specifične funkcije, ako jedan programer radi na vašem sajtu (ili u kompaniji sa dizajnerom), dokument će biti jednostavniji. Ali i veliki i mali TK imaju isto značenje i moraju odgovoriti na ista pitanja:

• Zašto i za koga je sajt kreiran?
• Čime će biti ispunjen?
• Kako će sve ovo funkcionirati?
• Ko će i kako raditi na projektu, ko je za šta odgovoran?
• Šta će biti izlaz?

Glavni dijelovi projektnog zadatka za razvoj stranice

1. Podaci o kupcu, odnosno o vama

Navedite što više detalja. Navedite sve izvore gdje programer može dobiti podatke koji nedostaju. To mogu biti leci, posteri, elektronski materijali, linkovi, kontakti ljudi kojima se mogu postaviti pitanja.

2. Informacije o projektu

Šta će to biti: web stranica za posjetnice, internetska trgovina, korporativni portal, elektronska biblioteka?

3. Ciljna publika stranice

Ovo je slučaj kada vam je potrebno. Ako već dugo čitate naš blog, onda razumijete da se bez ovog alata u marketingu, općenito, vrlo malo može učiniti.

Odlučili ste se za vlastitu web stranicu, ali još uvijek ne znate detaljno ko je vaš klijent? Dakle, sada je vrijeme da nacrtamo njegov detaljan portret.

4. Ciljevi i zadaci koje sajt treba da reši za kupca i za publiku

Ovo je možda glavni dio TOR-a za razvoj stranice. Morate jasno razumjeti zašto vam je potreban web resurs. Da poboljšate sliku? Za direktnu prodaju? Želite li posjetitelje pretvoriti u pretplatnike pomoću vaše web stranice? Želite li napraviti resurs za privlačenje potencijalnih partnera?

Navedite direktnu svrhu vaše stranice.

Pažljivo razmislite o pojedinačnim zadacima web resursa. Na primjer, trebao bi pružiti ažurirane informacije o novostima na tržištu, predstaviti vaše proizvode, omogućiti posjetiteljima da vas kontaktiraju direktno sa stranica web-mjesta i tako dalje.

5. Okvir projekta (glavna funkcionalnost)

Stranica može imati ogroman broj funkcija: obrazac za registraciju korisnika, Povratne informacije, dugmad za naručivanje, kalendar dostave, news feed, katalog proizvoda sa mogućnošću odlaska u korpu, ugrađena mailing skripta, zatvorene sekcije za kupce - svejedno! Svaka od ovih funkcija u projektnom zadatku za razvoj vašeg sajta treba da bude na najdetaljniji način.

Dakle, odeljak „Opseg projekta“ je nešto poput tabele sadržaja, u kojoj se navode funkcije bez njihovog preciznog opisa. Ovaj odjeljak će vam trebati u fazi traženja umjetnika. To će omogućiti potencijalnom kreatoru Vaše stranice da sagleda širu sliku i da okvirnu cijenu, a vi sistematizujte svoje želje za funkcionalnošću.

6. Struktura (mapa) lokacije

Sljedeći paragraf TOR-a za stranicu će reći izvođaču koje će stranice biti na vašoj web-lokaciji, koje sekcije i pododjeljci, kako će biti međusobno povezane, kako će biti prikazane u meniju stranice.

Strukturu je lakše nacrtati nego opisati. U grafičkom obliku, lakše je razmišljati o odnosu između područja stranice.

Šema međusobnog povezivanja pojedinih dijelova lokacije

Imamo webinar na ovu temu pod nazivom “Sistem sadržaja prodajnog sajta”. I ovdje govorimo detaljno o strukturi stranice, o odnosu stranica i veza između njih. Predlažem! Slika iznad je sa ovog webinara.

7. Pojedinačne stranice

Dok crtate sitemap, svaka stranica je samo kvadrat. Ali izvođač mora razumjeti šta će se i kojim redoslijedom nalaziti na ovom kvadratu (sjetite se primjera tablica na početku članka). Koji će informacioni blokovi postojati? Hoće li biti menija, bočnih traka na svakoj stranici? (poseban blok sa navigacijom), podnožje (donji blok)? Da li želite da vidite banere, slike na stranici? Hoće li biti statične ili pokretne?

Što detaljnije opišete svaki element svake stranice budućeg resursa, to će izlazni rezultat biti bliži vašim idejama o web mjestu.

U stvari, u ovoj fazi, a . O tome smo već pisali, ako morate napraviti web stranicu, svakako je pročitajte.

Možete kreirati prototip svake stranice web stranice, poprativši je detaljnim verbalnim opisom. Ili možete prvo kreirati prototipove glavnih blokova koji se ponavljaju na svakoj ili više stranica, a zatim razviti pojedinačne stranice koristeći blokove koji su već opisani.

8. Zahtjevi za dizajn lokacije

U ovoj fazi budite oprezni. Pretpostavimo da je dizajner profesionalac. Ne morate zapisivati ​​svaki korak. ne reci: “Napravi ovo dugme sa prelivom iz plave u crvenu, a ovaj tekst u 12. veličini i tako da treperi”. Navedite svoje glavne želje. Na primjer, pokažite postojeće web stranice/banere/štampe za koje mislite da odgovaraju vašem dizajnu. Recite nam koje boje preferirate. Recimo da želite da napravite sajt posvećen ženskom treningu, dizajner ga može "videti" u ružičastim bojama, ali volite lila i narandžastu. opći opisželje će vam pomoći da pronađete kompromis između vaše vizije i profesionalnog izgleda dizajnera.

Obavezno obezbijedite dizajneru materijale za rad, ako ih imate: logotip, kodiranja korporativnih boja i fontova, gotove elemente korporativnog identiteta (štampa, baneri i sl.).

Sa stranicama na motorima poput WordPress ili Joomla možete se snaći sa gotovim šablonima (ponekad čak i besplatnim). Ovo smanjuje nesigurnost: samo pogledajte šablone i odaberite onaj koji vam se sviđa. Što se tiče dizajna, neki od njih su prilično čudni, pa se pokušajte posavjetovati sa stručnjakom - i dalje će ispasti jeftinije od naručivanja dizajna od nule.

9. Radna funkcionalnost stranice

Nemojte biti lijeni i detaljno opišite rad svih funkcija. Dajte izvođaču što više informacija. Zapamtite da on nema dar telepatije i možda neće pogoditi šta želite da dobijete kada napišete u opisu poslova za stranicu "formular za pretplatu" ili "kalendar".

Šta je obrazac za pretplatu? Kako ona izgleda? Kako to radi? Šta je kalendar? Da li prikazuje samo današnji datum ili cijeli prošli mjesec? Mogu li da okrećem stranice u njemu ili ne? Izvođač možda neće pogoditi ove nijanse, na kraju ćete dobiti nešto potpuno drugačije od onoga što ste željeli. Novac je uplaćen, projekat je u skladu sa TOR (napisali ste "kalendar"- evo ga), i morat ćete se zadovoljiti onim što se dogodilo, iako to uopće nije ono što ste željeli, ili preplatite promjene.

Slobodno istražite druge stranice - konkurente ili čak kompanije čije aktivnosti nemaju nikakve veze s vama. Konkurenti mogu predložiti implementaciju funkcija koje su vam potrebne, na drugim tržištima možete posuditi zanimljiva rješenja na koje se konkurenti još nisu setili. Često je lakše pronaći funkciju na tuđoj stranici i dati izvođaču link "ovo bi trebalo da funkcionira ovako" nego upirući prstom.

Ne zaboravite da vaša stranica treba biti zgodna ne samo za korisnika, već i za administratora. Moderni sistemi Kontrole stranice su obično intuitivne za administraciju. Ali, ako ne znate na kojem motoru radi izvođač, zapišite i funkcije administratora. Šta treba da radi na sajtu i kako to treba implementirati.

Naravno, imate pravo da ne znate kako će neka funkcija funkcionirati. U tom slučaju, zamolite programera da vam ponudi opcije za odobrenje. Odobrete opciju koja vam odgovara (uključujući i budžet). Zapamtite: prvo razmotrite i odobrite, a zatim uradite.

10. Opis sadržaja

Ako naručujete sadržaj istovremeno sa kreiranjem stranice, a imate jednog izvođača (na primjer, agenciju), opis sadržaja je poseban TOR za copywritera. Ako ćete sami kreirati sadržaj ili naručiti od drugog umjetnika, programer stranice bi ipak trebao imati ideju o tome što će biti smješteno u koji odjeljak i kako će izgledati. Gdje je tekst, gdje je video, kako će biti dizajnirane slike, da li je potreban pregled članaka i šta će to biti itd.

11. Tehnički zahtjevi

Teška stvar za one koji se malo razumiju u izgradnju sajtova. Ako ovo razumijete i važno vam je na kojem jeziku na kojoj verziji bi vaš resurs trebao biti napisan, napišite o tome u opisu zadataka za kreiranje stranice. Ili imate zahtjeve za diskovnim prostorom za hosting.

Kako kupiti ono što vam je potrebno bez kršenja antimonopolskih zakona? Ključ uspjeha u ovom poslu je dobro napisan tehnički zadatak. Koje implicitne prekršaje čine kupci pročitajte u članku.

U općenitom slučaju, prilikom sastavljanja TOR-a nabavke, kupac mora pratiti potpunu bezličnost opisanog objekta, odnosno ne bi trebao sadržavati nikakve zahtjeve ili čak naznake specifičnih zaštitni znakovi, proizvođača ili čak zemlje porijekla robe.

Zapravo, prilično je teško ispravno pripremiti opis predmeta nabavke, projektni zadatak za 44-FZ, bez posebnog znanja u određenoj oblasti. Neki kupci čak kreiraju nabavku za pružanje usluga za izradu projektnog zadatka. Ali sasvim je moguće to učiniti sami, ako pažljivo proučite zahtjeve za predmete nabave, uporedite ih sa svojim potrebama i strogo slijedite pravila za opis predmeta nabave prema 44-FZ.

Mora se imati na umu da su neke karakteristike šifrirane u označavanju proizvoda. Na primjer, projektni zadatak predviđa materijal "ploče za popločavanje" sa oznakom "Classico 1KO.4", projektni zadatak ne postavlja nikakve zahtjeve za debljinu pločice. Prema dekodiranju oznake, njegova debljina je 4 cm (posljednja cifra oznake označava debljinu u cm). Međutim, prilikom izvođenja kontakta ispostavilo se da je potrebna pločica debljine 6 cm, a opterećenje koje može izdržati zavisi od debljine pločice. Nepismeno sastavljeni projektni zadaci doveli su do kupovine materijala koji ne ispunjava potrebne uslove. Stoga je potrebno pažljivo provjeriti označavanje svih materijala u projektnom zadatku i naznačiti sve osnovne, bitne zahtjeve za materijale.

Poželjno nemojte kopirati opise proizvoda sa različitih stranica. Podaci u opisu možda nisu pouzdani i ispostavilo se da niti jedan proizvod ne ispunjava navedene zahtjeve. Velika je vjerovatnoća da pod dati opis jedini proizvod odgovara. Ovo se može smatrati ograničenjem konkurencije.

Svi zahtjevi za performanse ne bi trebali biti dvosmisleni. U suprotnom, biće mnogo zahtjeva za pojašnjenjem. Često se dešava da sa puno zahtjeva, kupac nema vremena da na njih pravovremeno odgovori u meritumu i možda nema vremena za prilagođavanje projektnog zadatka. Na osnovu toga, ponekad kupac u pojašnjenju naznači da je dovoljno dostaviti samo saglasnost, bez navođenja materijala. Zauzvrat, to smanjuje šanse da se kupi upravo ono što je potrebno, jer iz aplikacije nije jasno koji će se materijali koristiti u izvođenju radova.

Bolje je sastaviti uputstva za pripremu aplikacije nakon što opišete zahtjeve za tehničke specifikacije. Uputstvo ne treba da zbuni učesnika, već da precizira zahteve projektnog zadatka, kako bi se izbegli mnogi zahtevi učesnika. Neusklađenost projektnog zadatka sa uputstvima, što stvara prepreku za pripremu prijave, može izazvati podnošenje prigovora FAS-u od strane potencijalnih učesnika u nabavci.

Koje je druge zahtjeve važno navesti u projektnom zadatku:

• Garantnim rokom robe, radova, usluga i (ili) obimom davanja garancija njihovog kvaliteta. Kupac u zadatku mora odrediti garantni rok ne kraći od garantnog roka proizvođača.
• Na garantni servis robe.
• Na troškove rada proizvoda.
• Obavezna montaža i puštanje u rad robe.
• Za obuku osoba uključenih u upotrebu i održavanje robe.

Glavna pravila

1. Prilikom pripreme dokumentacije za nabavku obratite pažnju na kodove Sveruskog klasifikatora proizvoda (OKPD2) koji se odnose na predmet nabavke. Neophodno je da korišteni kod odgovara konkretnom objektu nabavke.
2. Pored odredbi 44-FZ, prilikom izrade projektnog zadatka, treba imati na umu i zahtjeve drugih pravnih akata, antimonopolskih organa, tehničkih normi i standarda (GOST, TU, SNiP, itd.).
3. Roba i materijali koje kupac traži u projektnom zadatku moraju odgovarati predmetu kupovine i predračunskoj dokumentaciji (ako postoji).
4. Prilikom kupovine za ugovor o građenju potrebno je priložiti i neispravnu izjavu, predračun, a u slučaju kapitalne izgradnje (rekonstrukcija, kapitalne popravke) potrebno je priložiti i projektnu dokumentaciju.
5. Naznačite da želite kupiti novu robu i materijal (tj. nisu korišteni, nisu popravljani, restaurirani, nisu restaurirani). U suprotnom, kupac može dobiti rabljenu robu.

Uobičajena pitanja

Pitanje: Da li je moguće propisati oznaku "original" za nabavku rezervnih dijelova?
odgovor: Moguće je ukoliko se radi o proizvodu pod garancijom, ili postoji potreba da se obezbedi interakcija takve robe sa robom koju koristi kupac, kao i u slučaju kupovine rezervnih delova i Zalihe na mašine i opremu.

Pitanje: Da li je obavezno propisivanje identifikacionog koda nabavke u zadatku?
odgovor: Identifikacioni kod nabavke se navodi u planu nabavki, rasporedu, obaveštenju o nabavci, pozivu za učešće u izboru dobavljača (izvođača, izvođača) koji se sprovodi zatvorenom metodom, dokumentaciji o nabavci, u ugovoru, kao i u drugim dokumente predviđene ovim saveznim zakonom. Nije potrebno to specificirati u TOR-u.

Pitanje: Morate kupiti uređaj za naučno istraživanje na postojeći sistem od 3 uređaja jednog proizvođača. U radu je potrebno sve u potpunosti kombinovati. Ekvivalent nije poželjan. Zar ne mogu napisati ekvivalent i navesti proizvođača? Sistem je veoma prilagodljiv i skup.
odgovor: Ako se vaš slučaj uklapa pod „... osim u slučajevima nekompatibilnosti robe na koju se stavljaju drugi zaštitni znakovi i potrebe da se osigura interakcija takve robe s robom koju koristi kupac...) - možete, u drugim slučajevima - Ne možeš.

Pitanje: Da li je moguće naznačiti uske pokazatelje u projektnom zadatku za remont, na primjer, boju zidova s ​​određenom shemom boja, priložiti primjer kompozicije gipsane ploče na stropu, određenu kolekciju pločica bez ekvivalenta, pozivajući se na estetske sklonosti?
odgovor: Prilikom formiranja projektnog zadatka, kupci se moraju rukovoditi zahtjevima člana 33. Zakona br. 44-FZ. Boja zidova je izbor kupca, to je njegova potreba, ne ograničavajući broj dobavljača. Raspored, skica kompozicije od gipsanih ploča na plafonu je takođe potreba naručioca, svi izvođači će moći da ponove raspored dat u dokumentaciji. Zbirka pločica bez ekvivalenta predstavlja kršenje stava 1. člana 33. Zakona br. 44-FZ: „Dokumentacija o nabavci može sadržavati naznaku žigova ako se u obavljanju poslova, pružanju usluga pretpostavlja koristiti robu čija isporuka nije predmet ugovora. Istovremeno, preduslov je uključivanje riječi “ili ekvivalent” u opis predmeta nabavke.