Ne visi saprot, cik svarīgi ir pareizi izstrādāt tehniskās specifikācijas, taču patiesībā tas ir tik plašs jautājums, ka īsi tas nedarbosies. Šī iemesla dēļ pirms šīs procedūras veikšanas jums ir jāsaprot visi attiecīgie smalkumi.
Kam tas domāts?
Pirms apspriest, kā pareizi izstrādāt tehniskās specifikācijas, jums jāsaprot, kāpēc tas tiek darīts un kurš to vēlāk izmantos, jo no tā diezgan lielā mērā ir atkarīga pieeja, kas nepieciešama šīs procedūras veikšanai. Ir vērts atzīmēt dažas pamata iespējas:
- Komerciāla organizācija plāno ieviest pilnībā automatizētu sistēmu, taču tai nav sava IT pakalpojuma, kā rezultātā tā nolēma rīkoties šādi: noteikta ieinteresētā persona izstrādā tehniskos uzdevumus, un pēc tam tos nodod trešo personu organizācijām turpmākai attīstībai.
- Komerciāls uzņēmums plāno izmantot automatizētu sistēmu, un tam ir strādājošs IT pakalpojums. Šajā situācijā tiek izstrādāts TK, pēc tam tas tiek sīki apspriests ar IT pakalpojumu un pēc tam nosūtīts ieinteresētajām pusēm, un galu galā tas tiek pārdots atsevišķi.
- Valdība gatavojas pabeigt konkrētu IT projektu. Šeit jau sastopas daudz smalkumu un nepilnību, ieskaitot visa veida formalitātes, tāpēc pat nav ieteicams izskatīt šo iespēju, jo katram atsevišķam gadījumam visbiežāk ir nepieciešama pilnīgi individuāla pieeja.
Sarežģītāki gadījumi
Sarežģītākais gadījums ir tad, kad IT uzņēmums izstrādā tehniskās specifikācijas automatizēto sistēmu turpmākai izstrādei un ieviešanai. Šādās situācijās jums jāstrādā ļoti dažādos apstākļos, piemēram:
- Klienta klātbūtne pie saviem speciālistiem ar savu redzējumu par šo procesu, kas uzliek noteiktas prasības sastādītajam TOR.
- Tehniskās specifikācijas tiek izveidotas tikai viņu izstrādātājiem, un klientam principā nav tik svarīgi, kāds būs rezultāts.
- TK tiks nodota darbuzņēmējam, tas ir, noteiktai speciālistu grupai, kas atrodas ārpus uzņēmuma darbiniekiem.
- Starp uzņēmumu un klientu rodas neizpratne par rezultātu, tāpēc uzņēmums nezina, kā pareizi izstrādāt tehniskās apkopes tehniskās specifikācijas.
Ir arī daudzas citas situācijas, kuras arī jāņem vērā, bet iepriekš ir norādītas tikai biežākās.
Kas ir TK?
Ir diezgan liels skaits GOST un noteiktu standartu, kas ir paredzēti katras darbības jomas regulēšanai. Īpaši šie standarti ir jāņem vērā, izstrādājot tehniskās apkopes specifikācijas. Tajā pašā laikā var būt aktīvas debates par to, cik svarīgi ir šie dokumenti, taču jebkurā gadījumā sava projekta izstrādes procesā jums tie pilnībā jāievēro. Faktiski ir pareizi jāsaprot, ka GOST visbiežāk neatklāj mūsdienu attīstības praktiskās problēmas, bet tajā pašā laikā tie ne vienmēr piedāvā īpašu un sistēmisku alternatīvu.
TK pats par sevi ir attaisnojuma dokuments, kas reglamentē tehniskās iekārtas projektēšanu.Tas nosaka šīs attīstības galveno mērķi, kā arī dažādus taktiskos un tehniskos parametrus, kvalitātes rādītājus un visa veida tehniskās un ekonomiskās prasības, kā arī norāda īpašās prasības, kas jāņem vērā darba laikā. Uzdevums kā avota dokuments, lai izveidotu dažas jaunas lietas, pastāv katrā modernā darbības jomā, taču tas var mainīties atkarībā no satura, noformējuma secības un vairākiem citiem parametriem.
Lietošanas pazīmes
Ir pilnīgi dabiski, ka GOST prasības acīmredzami nav pietiekamas, lai galu galā ikviens varētu izveidot efektīvu tehniskā uzdevuma piemēru, un tas ir pilnīgi normāli, jo ne visi var veikt darbu pilnīgā saskaņā ar standartiem. Papildus pašam GOST ir jāņem vērā arī noteiktas metodes un prakse, un šis fakts ir šīs problēmas pamatā.
Daudzi eksperti kaut kādu iemeslu dēļ izstrādā tehniskās specifikācijas objekta projektēšanai vai noteiktu darbu veikšanai, pamatojoties tikai uz GOST prasībām, taču patiesībā tā principā ir nepareiza pieeja.
Galvenais izaicinājums
Kā izriet no pašas definīcijas, TK galvenais mērķis ir formulēt izstrādātā objekta pamatprasības. Šajā gadījumā ir pareizi jāsaprot, ka mēs runājam par pamatprasībām, bet ne vienīgajām.
Kā noteikt prasības?
Pirmkārt, jums jāatceras, ka projektēšanas vai izstrādes pamatnoteikumos jāiekļauj prasības, kuras ir sadalītas pa īpašībām un veidiem. Šajā faktiski GOST mums visvairāk palīdz. Tur atrodamais saraksts ir lielisks piemērs, kādi to veidi būs jāņem vērā, proti:
- Funkcionalitāte
- drošība un piekļuves tiesības;
- personāla kvalifikācija.
Uz ko jāpievērš uzmanība?
Protams, tas nav pilnīgs saraksts. Tomēr galvenais faktors, kas būtu jānošķir ar veiksmīgu tehniskā uzdevuma piemēru, ir pareizi noformulētas funkcionalitātes prasības, un tieši šīm prasībām speciālisti pavada lielāko daļu metožu un darbu. Daudzi eksperti saka, ka funkcionalitātes prasības ietver apmēram 90% no visa darba sarežģītības, kas saistīts ar tehnisko specifikāciju izstrādi, un viss pārējais ir sava veida “maskēšanās”, kas pēc tam tiks valkāta pēc šīm prasībām.
Ja prasības tiek formulētas nepareizi, neatkarīgi no tā, cik skaisti jūs tām uzliekat maskēties, galu galā tas nedarbosies, lai izveidotu patiešām veiksmīgu projektu. Protams, saskaņā ar GOST, visas prasības ir pilnībā izpildītas, tiek izstrādāti, parakstīti un apstiprināti darba uzdevumi (tālāk redzamais paraugs), un speciālists par to saņēma samaksu, bet tad jums ir jāsaprot, ko darīt ar šo dokumentu. Ja mēs runājam par valsts pasūtījuma projektu, tad bieži vien problēmas nerodas, jo ir daudz mazāki budžeta ierobežojumi, un galvenā detaļa jau tiks identificēta ieviešanas procesā. Bet, ja mēs runājam par komerciālām organizācijām, kur tās sīkāk apsver naudu un prasa atšķirīgu rezultātu, tad viss jau ir sarežģītāk.
Noderīga un efektīva attīstība
Ja prasību veidi var būt ļoti dažādi, un šeit viss galvenokārt ir atkarīgs tikai no projekta mērķiem, tad ir tikai trīs īpašības:
- saprotamība;
- specifiskums;
- pārbaudāmība.
Tajā pašā laikā ir pareizi jāsaprot, ka, izstrādājot tehnisko uzdevumu, paraugs ir jāpārbauda pareizi, un tas jau ir atkarīgs no pirmajām divām īpašībām.Ja vienas vai citas prasības izpildes rezultātu nevar pārbaudīt, tad tas norāda, ka šī prasība vai nu nav pilnībā izprotama vai nav specifiska, un jums par to ir jādomā, jo tieši šo prasību īpašumā ir izstrādātāja profesionalitāte un prasmes, un tāpēc pieredzējuši speciālisti šādu darbu veic daudz ātrāk un labāk.
Papildu nianses
Ir arī daži svarīgi punkti, kas jāņem vērā, izstrādājot tehnisko uzdevumu. Prasību sistēma ir šāda:
- Kāda valoda (no uztveres sarežģītības viedokļa) būtu jāraksta?
- Vai tajā ir jāapraksta dažādu funkciju, algoritmu, nepieciešamās informācijas veidu un citu tehnisko smalkumu specifiskās iezīmes?
- Kas ir tehniskais dizains, kurš, starp citu, tiek norādīts esošajās valsts standarta specifikācijās, un kā tas attiecas uz apkopotajām tehniskajām specifikācijām?
Atbildes uz visiem šiem jautājumiem ir diezgan svarīgas, un tieši šī iemesla dēļ daudzi bieži sāk strīdēties par to, cik pietiekams ir sagatavotais TOR un vai tajā ir visas nepieciešamās prasības. Cita starpā ir svarīgi arī tas, cik saprotams šis dokuments būs no pasūtītāja un darbuzņēmēja viedokļa, cik lieks tas ir un kāds ir prezentācijas formāts.
Uzdevums un projekts
TK ir dokuments, kas ietver dažādas prasības, kas ir noformulētas klientam un darbuzņēmējam ārkārtīgi saprotamā valodā. Turklāt, ja profesionālis izstrādā tehnisku uzdevumu, viņa pakalpojumi var ietvert arī nozares tehnoloģiju izmantošanu, kas ir paredzēta, lai galauzņēmējam sniegtu saprotamāko formulējumu. Šeit ir svarīgi atcerēties, ka ir jāizvairās no jebkādām saistībām ar tehniskās ieviešanas specifiku, tas ir, TK izstrādes procesā principā nav svarīgi, kurā konkrētajā platformā tiks īstenota visu šo prasību ieviešana. Protams, ir daži izņēmumi, taču tie ir īpaši gadījumi.
Dažādu prasību skaidrojums un turpmāka formulēšana, kā arī ToR galīgā izstrāde jau būtu jāveic specializētam biznesa analītiķim, nevis izpildītājam (ja vien, protams, viņš pats neapvieno šīs lomas, kas notiek periodiski). Citiem vārdiem sakot, speciālistam ir jāsazinās ar klientu tā biznesa valodā, kuru viņš vada.
Projekta atšķirības no uzdevuma
Tehniskā uzdevuma izveide no projekta atšķiras ar to, ka pēdējais ir dokuments, kurā ietvertas pamatprasības, kā jāīsteno TR noteiktās prasības. Šajā dokumentā ir ietverti galvenie ieviestā produkta smalkumi un nepieciešamie elementi, kurus darbā izmantos tehniskie speciālisti.
Klientam nav nepieciešams ienirt šādā darbā, jo lielākais vairums prasību viņam var nebūt pat saprotamas. Bieži vien tehniskā projekta īstenošanu veic noteikts speciālists, tāpēc jau ir pilnīgi iespējams šo lomu apvienot ar izpildītāju. Tajā pašā laikā jums jāsaprot, ka jo lielāks ir projekts, jo vairāk cilvēku izstrādā tehniskās specifikācijas.
Kāda ir prakse?
Bieži gadās, ka direktoru ved uz TK koordināciju, kas ietver daudz tehniskās terminoloģijas, kā rezultātā viņš mēģina tajā ienirt, mēģinot noķert pazīstamus vārdus un nepazaudēt galveno biznesa prasību ķēdi. Parasti šādās situācijās darba tehniskais uzdevums joprojām tiek apstiprināts, ieviests, un vairumā gadījumu izrādās, ka rezultāts neatbilst veiktā darba faktam, jo lielu daļu nianšu tika nolemts mainīt, pārkārtot,un daži elementi tika pārprasti, un radās virkne citu problēmu.
Tāpēc ir svarīgi saprast atšķirību starp TK un tehnisko dizainu, kas daļēji ir saistīta ar attiecīgo speciālistu kompetenci un daļēji ar vēlmi samazināt budžetu un laiku, jo šāda dokumentācija prasa daudz laika.
