Ikke alle forstår, hvor vigtigt det er at udvikle tekniske specifikationer korrekt, men det er faktisk et så bredt spørgsmål, at det ikke fungerer i et nøddeskal. Af denne grund skal du forstå alle de relevante subtiliteter, før du fortsætter med denne procedure.
Hvad er dette til?
Inden du diskuterer, hvordan du udvikler tekniske specifikationer korrekt, skal du forstå, hvorfor dette gøres, og af hvem det efterfølgende vil blive brugt, fordi den nødvendige tilgang til udførelse af denne procedure afhænger ganske kraftigt af dette. Det er værd at bemærke et par grundlæggende muligheder:
- En kommerciel organisation har til hensigt at indføre et fuldt automatiseret system, men den har ikke sin egen IT-service, som et resultat heraf besluttede de at gøre følgende: en bestemt interesseret person udvikler tekniske opgaver og giver dem derefter til tredjepartsorganisationer til videre udvikling.
- En kommerciel virksomhed bruger et automatiseret system, og det har en fungerende IT-service. I denne situation udvikles TK, hvorefter det forhandles detaljeret med IT-tjenesten og derefter sendes til interesserede parter, og i sidste ende sælges det på egen hånd.
- Regeringen er ved at afslutte et specifikt it-projekt. En masse subtiliteter og faldgruber, inklusive alle former for formaliteter, overflader allerede her, så det er ikke engang tilrådeligt at overveje denne mulighed, da hvert enkelt tilfælde ofte kræver en helt individuel tilgang.
Mere komplicerede sager
Det vanskeligste tilfælde er, når tekniske specifikationer udvikles af en it-virksomhed til efterfølgende udvikling og implementering af automatiserede systemer. I sådanne situationer er du nødt til at arbejde under en lang række forhold, såsom:
- Klientens tilstedeværelse af sine egne specialister med sin egen vision for denne proces, der stiller visse krav til den udarbejdede TOR.
- Tekniske specifikationer oprettes udelukkende til deres egne udviklere, og klienten er i princippet ikke så vigtig, hvad resultatet bliver.
- TK overføres til entreprenøren, det vil sige til en bestemt gruppe specialister, der er placeret uden for virksomhedens personale.
- Der er en misforståelse mellem virksomheden og klienten med hensyn til resultatet, så virksomheden ikke ved, hvordan man korrekt udvikler tekniske specifikationer for vedligeholdelse.
Der er mange andre situationer, der også skal overvejes, men kun de hyppigste er angivet ovenfor.
Hvad er TK?
Der er et ret stort antal GOST'er og visse standarder, der er designet til at regulere hvert aktivitetsområde. Især skal sådanne standarder tages i betragtning ved udvikling af tekniske specifikationer for vedligeholdelse. På samme tid kan der være en aktiv debat om, hvor relevante disse dokumenter er, men under alle omstændigheder skal du under udarbejdelsen af dit eget projekt fuldt ud overholde dem. Faktisk skal man med rette forstå, at GOST'er ofte ikke afslører de praktiske problemer med moderne udvikling, men på samme tid foreslår de ikke altid et specifikt og systemisk alternativ.
TK er i sig selv et kildedokument, der styrer designet til en teknisk facilitet.Det fastlægger hovedformålet med denne udvikling, samt forskellige taktiske og tekniske egenskaber, kvalitetsindikatorer og alle former for tekniske og økonomiske krav, og angiver også særlige krav, der skal tages i betragtning under arbejdet. Opgaven som kildedokument til at skabe nogle nye ting findes i alle moderne aktivitetsområder, men det kan variere afhængigt af indholdet, rækkefølgen af design og en række andre parametre.
Funktioner ved brug
Det er helt naturligt, at kravene i GOST helt klart ikke er nok, så alle i sidste ende kan skabe et effektivt eksempel på en teknisk opgave, og det er helt normalt, fordi ikke alle kan udføre jobbet i fuld overensstemmelse med standarderne. Ud over GOST selv skal visse metoder og fremgangsmåder også tages i betragtning, og dette faktum er roden til dette problem.
Mange eksperter, der af en eller anden grund udvikler tekniske specifikationer til design af et objekt eller udfører visse værker, er udelukkende baseret på GOST-kravene, men i virkeligheden er dette grundlæggende den forkerte tilgang.
Hovedudfordring
Som følger af selve definitionen er hovedformålet med TK at formulere de grundlæggende krav til det udviklede objekt. I dette tilfælde skal man korrekt forstå, at vi taler om de grundlæggende krav, men ikke de eneste.
Hvordan fastlægges kravene?
Først og fremmest skal du huske, at forretningsbetingelserne for design eller udvikling skal omfatte krav, der er divideret med egenskaber og typer. I dette hjælper GOST os faktisk mest. Den liste, der kan findes der, er et fremragende eksempel på, hvilke typer af dem der skal overvejes, nemlig:
- funktionalitet;
- sikkerheds- og adgangsrettigheder;
- personalets kvalifikationer.
Hvad skal man være opmærksom på?
Naturligvis er dette ikke en komplet liste. Den vigtigste faktor, der skal adskilles ved et vellykket eksempel på den tekniske opgave, er imidlertid de korrekt formulerede krav til funktionalitet, og det er til disse krav, at fagfolkene afsætter det overvældende flertal af metoder og værker. Mange eksperter siger, at kravene til funktionalitet inkluderer ca. 90% af den samlede kompleksitet af arbejde, der er relateret til udvikling af tekniske specifikationer, og alt andet er en slags "camouflage", som derefter bæres på disse krav.
Hvis kravene er forkert dannet, uanset hvor smuk du lægger camouflage på dem, vil det i sidste ende ikke arbejde for at lave et rigtig vellykket projekt. Ifølge GOST er naturligvis alle krav fuldt ud opfyldt, forretningsbetingelserne (prøve nedenfor) er udviklet, underskrevet og godkendt, og specialisten modtog betaling for det, men så skal du forstå, hvad du skal gøre med dette dokument. Hvis vi taler om et projekt til en statsordre, opstår der ofte ingen problemer, fordi der er meget mindre budgetbegrænsninger, og de vigtigste detaljer vil allerede blive identificeret i implementeringsprocessen. Men hvis vi taler om kommercielle organisationer, hvor de betragter penge mere detaljeret og kræver et andet resultat, så er alt allerede mere kompliceret.
Nyttig og effektiv udvikling
Hvis kravstyperne kan være meget forskellige, og her afhænger alt hovedsageligt udelukkende af projektets mål, er der kun tre egenskaber:
- klarhed;
- beton;
- testbarhed.
Samtidig skal man korrekt forstå, at når man udvikler en teknisk opgave, skal en prøve testes korrekt, og dette afhænger allerede af de to første egenskaber.Hvis resultatet af opfyldelsen af et eller andet krav ikke kan testes, indikerer dette, at dette krav enten ikke er fuldt ud forstået eller ikke specifikt, og du er nødt til at tænke over det, fordi det er i ejerskabet til disse egenskaber for kravene, at udviklerens professionalisme og dygtighed ligger, og derfor udfører erfarne specialister sådan arbejde meget hurtigere og bedre.
Yderligere nuancer
Der er også et par vigtige punkter, der skal tages i betragtning, når man udvikler en teknisk opgave. Kravssystemet er som følger:
- Hvilket sprog (ud fra synspunktet om kompleksitet i opfattelsen) skal det skrives?
- Er det nødvendigt at beskrive i det specifikke træk ved forskellige funktioner, algoritmer, typer nødvendige oplysninger og andre tekniske subtiliteter?
- Hvad er teknisk design, der forresten er noteret i eksisterende standardstandardspecifikationer, og hvordan forholder det sig til de udarbejdede tekniske specifikationer?
Svarene på alle disse spørgsmål er ganske vigtige, og netop derfor begynder mange ofte at diskutere, hvor tilstrækkelig den udkastede TOR er, og om den indeholder alle de nødvendige detaljer om kravene. Det er blandt andet vigtigt, hvor forståeligt dette dokument vil være fra kundens og entreprenørens synspunkt, hvor overflødigt det er, og hvad præsentationsformatet er.
Opgave og projekt
TK er et dokument, der indeholder forskellige krav, der er formuleret på et sprog, der er yderst forståeligt for kunden og for entreprenøren. Hvis en professionel desuden udvikler en teknisk opgave, kan hans tjenester også omfatte brugen af industriteknologi, der er designet til at give den mest forståelige ordlyd for den endelige entreprenør. Det er vigtigt at huske her, at det er nødvendigt at undgå bindinger til det specifikke ved teknisk implementering, det vil sige i processen med at udvikle TK, i princippet betyder det ikke noget på hvilken specifik platform implementeringen af alle disse krav implementeres. Der er naturligvis visse undtagelser, men dette er specielle tilfælde.
Afklaringen og den videre formulering af de forskellige krav såvel som den endelige udvikling af ToR bør allerede udføres af en specialiseret forretningsanalytiker og ikke af eksekutoren (medmindre han selvfølgelig kombinerer disse roller i sig selv, hvilket sker periodisk). Med andre ord skal specialisten kommunikere med kunden på det sprog i den virksomhed, han udfører.
Forskelle i projektet fra opgaven
Oprettelse af en teknisk opgave fra et projekt er forskellig, idet sidstnævnte er et dokument, der indeholder de grundlæggende krav til, hvordan kravene, der er specificeret i ToR, skal implementeres. Dette dokument inkluderer de vigtigste subtiliteter i det implementerede produkt og de nødvendige elementer, der vil blive brugt i arbejdet af tekniske specialister.
Det er ikke nødvendigt for kunden at gå i dybden med sådant arbejde, fordi det overvældende flertal af kravene måske ikke engang er klart for ham. Ofte gennemføres implementeringen af et teknisk projekt af en bestemt specialist, det er derfor allerede muligt at kombinere denne rolle med udøveren. På samme tid skal du forstå, at jo større projektet er, jo flere udvikler de tekniske specifikationer.
Hvad er praksis?
Det sker ofte, at instruktøren bringes til koordineringen af TK, der inkluderer en masse teknisk terminologi, som et resultat af hvilket han forsøger at gå i dybden ved at prøve at fange kendte ord og ikke miste hovedkæden for forretningskrav. Som regel er den tekniske opgave for arbejde stadig i sådanne situationer godkendt, implementeret, og i de fleste tilfælde viser det sig, at resultatet ikke svarer til det faktum, det arbejde, der blev udført, da et stort antal nuancer blev besluttet ændret, omgjort,og nogle elementer blev misforstået, og en række andre problemer opstod.
Derfor er det vigtigt at forstå forskellen mellem TK og den tekniske design, som dels er relateret til kompetencen hos de relevante specialister, og dels til ønsket om at reducere budgettet og tiden, da sådan dokumentation tager meget tid.
