Ikke alle forstår hvor viktig det er å utvikle tekniske spesifikasjoner riktig, men faktisk er det et så bredt spørsmål at det ikke vil fungere i et nøtteskall. Av denne grunn, før du fortsetter med denne prosedyren, må du forstå alle relevante finesser.
Hva er dette for?
Før du diskuterer hvordan du skal utvikle tekniske spesifikasjoner på riktig måte, må du forstå hvorfor dette gjøres og av hvem det senere skal brukes, fordi den nødvendige tilnærmingen for å utføre denne prosedyren avhenger ganske sterkt av dette. Det er verdt å merke seg noen få grunnleggende alternativer:
- En kommersiell organisasjon har til hensikt å innføre et helautomatisert system, men den har ikke sin egen IT-tjeneste, som et resultat av at de bestemte seg for å gjøre følgende: en viss interessert person utvikler tekniske oppgaver, og gir dem deretter til tredjepartsorganisasjoner for videre utvikling.
- Et kommersielt selskap skal bruke et automatisert system, og det har en fungerende IT-tjeneste. I denne situasjonen utvikles TK, hvoretter det forhandles i detalj med IT-tjenesten og deretter sendes til interesserte parter, og til slutt selges den på egen hånd.
- Regjeringen er i ferd med å fullføre et spesifikt IT-prosjekt. Mange overflater og fallgruver, inkludert alle slags formaliteter, dukker allerede opp her, så det er ikke en gang tilrådelig å vurdere dette alternativet, siden hvert enkelt tilfelle ofte krever en helt individuell tilnærming.
Mer kompliserte saker
Det vanskeligste tilfellet er når tekniske spesifikasjoner utvikles av et IT-selskap for påfølgende utvikling og implementering av automatiserte systemer. I slike situasjoner må du jobbe under en rekke forhold, for eksempel:
- Kundens tilstedeværelse av egne spesialister med sin egen visjon om denne prosessen, som stiller visse krav til den kompilerte TOR.
- Tekniske spesifikasjoner opprettes utelukkende for sine egne utviklere, og klienten er i prinsippet ikke så viktig hva resultatet blir.
- TK vil bli overført til entreprenøren, det vil si til en viss gruppe spesialister som er lokalisert utenfor selskapets stab.
- Det er en misforståelse mellom selskapet og klienten angående resultatet, slik at selskapet ikke vet hvordan de skal utvikle tekniske spesifikasjoner for vedlikehold på riktig måte.
Det er mange andre situasjoner som også må vurderes, men bare de hyppigste er angitt ovenfor.
Hva er TK?
Det er et ganske stort antall GOST-er og visse standarder som er utformet for å regulere hvert aktivitetsområde. Spesielt må slike standarder tas i betraktning når man utvikler tekniske spesifikasjoner for vedlikehold. Samtidig kan det være en aktiv debatt om hvor relevante disse dokumentene er, men i alle fall i løpet av prosessen med å utvikle et eget prosjekt, må du følge dem fullt ut. Faktisk må man riktig forstå at GOST-er ofte ikke avslører de praktiske problemene med moderne utvikling, men samtidig foreslår de ikke alltid et spesifikt og systemisk alternativ.
TK i seg selv er et kildedokument som styrer utformingen av et teknisk anlegg.Den etablerer hovedformålet med denne utviklingen, så vel som forskjellige taktiske og tekniske egenskaper, kvalitetsindikatorer og alle slags tekniske og økonomiske krav, og indikerer også spesielle krav som må tas i betraktning under arbeidet. Oppgaven som kildedokument for å lage noen nye ting finnes i alle moderne aktivitetsfelt, men det kan variere, avhengig av innhold, rekkefølgen på design og en rekke andre parametere.
Funksjoner ved bruk
Det er helt naturlig at kravene i GOST tydeligvis ikke er nok, slik at alle til slutt kan lage et effektivt eksempel på en teknisk oppgave, og dette er ganske normalt, fordi ikke alle kan gjøre jobben i full overensstemmelse med standardene. I tillegg til GOST selv, må også visse metoder og fremgangsmåter tas i betraktning, og dette faktum ligger til grunn for dette problemet.
Mange eksperter, av en eller annen grunn, som utvikler tekniske spesifikasjoner for design av et objekt eller utfører visse arbeider, er utelukkende basert på kravene fra GOST, men i virkeligheten er dette grunnleggende en feil tilnærming.
Hovedutfordring
Som følger av selve definisjonen, er hovedformålet med TK å formulere de grunnleggende kravene til det utviklede objektet. I dette tilfellet må man riktig forstå at vi snakker om de grunnleggende kravene, men ikke de eneste.
Hvordan bestemme kravene?
Først av alt, må du huske at referansevilkårene for design eller utvikling bør omfatte krav som er delt på egenskaper og typer. I dette hjelper faktisk GOST oss mest. Listen som finnes der er et utmerket eksempel på hvilke typer av dem som må vurderes, nemlig:
- funksjonalitet;
- sikkerhet og tilgangsrettigheter;
- personalets kvalifikasjoner.
Hva du skal ta hensyn til?
Dette er selvfølgelig ikke en fullstendig liste. Imidlertid er nøkkelfaktoren som bør skilles med et vellykket eksempel på den tekniske oppgaven, de korrekt formulerte kravene til funksjonalitet, og det er til disse kravene fagfolkene bruker det overveldende flertallet av metoder og arbeider. Mange eksperter sier at kravene til funksjonalitet inkluderer rundt 90% av den totale kompleksiteten i arbeidet relatert til utvikling av tekniske spesifikasjoner, og alt annet er en slags "kamuflasje", som deretter vil bli brukt på disse kravene.
Hvis kravene blir dannet på feil måte, uansett hvor vakkert du legger kamuflasje på dem, til slutt vil det ikke fungere å lage et virkelig vellykket prosjekt. I følge GOST er selvfølgelig alle krav fullt ut oppfylt, referansevilkårene (prøve nedenfor) er utviklet, signert og godkjent, og spesialisten mottok betaling for det, men da må du forstå hva du skal gjøre med dette dokumentet. Hvis vi snakker om et prosjekt for en statlig ordre, oppstår det ofte ingen problemer, fordi det er mye mindre budsjettbegrensninger, og hoveddetaljene vil allerede bli identifisert i implementeringsprosessen. Men hvis vi snakker om kommersielle organisasjoner, der de vurderer penger mer detaljert og krever et annet resultat, så er alt allerede mer komplisert.
Nyttig og effektiv utvikling
Hvis kravene kan være veldig forskjellige, og her avhenger alt hovedsakelig av prosjektets mål, så er det bare tre egenskaper:
- tydeliggjøring;
- betong;
- testbarhet.
Samtidig må man riktig forstå at når man utvikler en teknisk oppgave, må en prøve testes riktig, og dette avhenger allerede av de to første egenskapene.Hvis resultatet av oppfyllelsen av et eller annet krav ikke kan testes, indikerer dette at dette kravet enten ikke er helt forstått eller ikke spesifikt, og du må tenke på det, fordi det er i eierskapet til disse egenskapene til kravene at utviklerens profesjonalitet og dyktighet ligger, og derfor utfører erfarne spesialister slikt arbeid mye raskere og bedre.
Ytterligere nyanser
Det er også noen få viktige punkter som må tas i betraktning når du utvikler en teknisk oppgave. Kravssystemet er som følger:
- Hvilket språk (fra synspunktet om kompleksitet i persepsjonen) skal det skrives?
- Er det nødvendig å beskrive noen spesifikke funksjoner i forskjellige funksjoner, algoritmer, typer nødvendig informasjon og andre tekniske finesser?
- Hva er teknisk design, som forresten er notert i eksisterende standardstandardspesifikasjoner, og hvordan forholder det seg til de tekniske tekniske spesifikasjonene?
Svarene på alle disse spørsmålene er ganske viktige, og nettopp derfor begynner mange å krangle om hvor tilstrekkelig den utarbeidede TOR er og om den inneholder alle nødvendige detaljer om kravene. Det er blant annet også viktig hvor forståelig dette dokumentet vil være fra kundens og entreprenørens synspunkt, hvor overflødig det er og hva presentasjonsformatet er.
Oppgave og prosjekt
TK er et dokument som inkluderer ulike krav som er formulert på et språk som er ekstremt forståelig for kunden og for entreprenøren. Dessuten, hvis en profesjonell utvikler en teknisk oppgave, kan tjenestene hans også omfatte bruk av industriteknologi, som er designet for å gi den mest forståelige ordlyden for den endelige entreprenøren. Det er viktig å huske her at det er nødvendig å unngå bindinger til det spesifikke ved teknisk implementering, det vil si at i ferd med å utvikle TK, i prinsippet spiller det ingen rolle på hvilken spesifikk plattform implementeringen av alle disse kravene vil bli implementert. Selvfølgelig er det visse unntak, men dette er spesielle tilfeller.
Avklaringen og den videre formuleringen av de forskjellige kravene, samt den endelige utviklingen av ToR, bør allerede gjøres av en spesialisert forretningsanalytiker, og ikke av eksekutoren (med mindre han selvfølgelig kombinerer disse rollene i seg selv, noe som skjer med jevne mellomrom). Spesialisten må med andre ord kommunisere med kunden på språket i virksomheten han utfører.
Forskjeller av prosjektet fra oppgaven
Å lage en teknisk oppgave fra et prosjekt er annerledes ved at sistnevnte er et dokument som inkluderer de grunnleggende kravene for hvordan kravene som er spesifisert i ToR skal implementeres. Dette dokumentet inneholder de viktigste subtilitetene til det implementerte produktet og de nødvendige elementene som vil bli brukt i arbeidet av tekniske spesialister.
Det er ikke nødvendig for kunden å fordype seg i slikt arbeid, fordi det overveldende flertallet av kravene kanskje ikke engang er klart for ham. Ofte gjennomføres implementeringen av et teknisk prosjekt av en spesifikk spesialist, derfor er det allerede fullt mulig å kombinere denne rollen med utøveren. Samtidig må du forstå at jo større prosjektet er, jo flere utvikler de tekniske spesifikasjonene.
Hva er praksis?
Det hender ofte at direktøren blir brakt til koordineringen av TK, som inkluderer mye teknisk terminologi, som et resultat av at han prøver å fordype seg i dette, prøver å fange kjente ord og ikke miste hovedkjeden for virksomhetskrav. I slike situasjoner er den tekniske oppgaven for arbeid fremdeles godkjent, implementert, og i de fleste tilfeller viser det seg at resultatet ikke samsvarer med faktum for utført arbeid, siden et stort antall nyanser ble besluttet endret, gjort om,og noen elementer ble misforstått, og en rekke andre problemer oppsto.
Derfor er det viktig å forstå forskjellen mellom TK og teknisk design, som delvis er relatert til kompetansen til de aktuelle spesialistene, og dels til ønsket om å redusere budsjett og tid, siden slik dokumentasjon tar mye tid.
