Taakomschrijving: ontwikkeling en creatie. Technische specificaties voor onderhoud

Niet iedereen begrijpt hoe belangrijk het is om technische specificaties correct te ontwikkelen, maar in feite is het zo'n brede vraag dat het niet in een notendop zal werken. Om deze reden moet u, voordat u doorgaat met deze procedure, alle relevante subtiliteiten begrijpen.

Waar is dit voor?

Voordat u gaat bespreken hoe u technische specificaties correct kunt ontwikkelen, moet u begrijpen waarom dit wordt gedaan en door wie het vervolgens zal worden gebruikt, omdat de noodzakelijke aanpak voor het uitvoeren van deze procedure vrij sterk hiervan afhankelijk is. Het is de moeite waard om enkele basisopties op te merken:

• Een commerciële organisatie is van plan een volledig geautomatiseerd systeem te introduceren, maar het heeft geen eigen IT-service, waardoor het besloot het volgende te doen: een bepaalde geïnteresseerde persoon ontwikkelt technische taken en geeft deze vervolgens aan derde partijen voor verdere ontwikkeling.
• Een commercieel bedrijf gaat een geautomatiseerd systeem gebruiken en het heeft een werkende IT-service. In deze situatie wordt TK ontwikkeld, waarna hierover in detail wordt onderhandeld met de IT-service en vervolgens wordt verzonden naar geïnteresseerde partijen, en uiteindelijk wordt het zelfstandig verkocht.
• De overheid staat op het punt een specifiek IT-project te voltooien. Veel subtiliteiten en valkuilen, waaronder allerlei formaliteiten, komen hier al aan het licht, dus het is zelfs niet raadzaam om deze optie te overwegen, omdat elk individueel geval meestal een volledig individuele aanpak vereist.

Meer complexe zaken

Het moeilijkste geval is wanneer technische specificaties door een IT-bedrijf worden ontwikkeld voor de daaropvolgende ontwikkeling en implementatie van geautomatiseerde systemen. In dergelijke situaties moet u in een breed scala van omstandigheden werken, zoals:

• De aanwezigheid van de klant van zijn eigen specialisten met zijn eigen visie op dit proces, dat bepaalde eisen stelt aan de samengestelde TOR.
• Technische specificaties worden exclusief voor hun eigen ontwikkelaars gemaakt en de klant is in principe niet zo belangrijk wat het resultaat zal zijn.
• TK wordt overgedragen aan de aannemer, dat wil zeggen aan een bepaalde groep specialisten die zich buiten het personeel van het bedrijf bevinden.
• Er is een misverstand tussen het bedrijf en de klant over het resultaat, dus het bedrijf weet niet hoe het technische specificaties voor onderhoud correct moet ontwikkelen.

Er zijn veel andere situaties waarmee ook rekening moet worden gehouden, maar alleen de meest voorkomende worden hierboven aangegeven.

Wat is TK?

Er is een vrij groot aantal GOST's en bepaalde normen die zijn ontworpen om elk activiteitengebied te reguleren. Met dergelijke normen moet met name rekening worden gehouden bij het ontwikkelen van technische specificaties voor onderhoud. Tegelijkertijd kan er een actief debat zijn over hoe relevant deze documenten zijn, maar in elk geval bij het ontwikkelen van uw eigen project moet u ze volledig naleven. In feite moet men goed begrijpen dat GOST's meestal niet de praktische problemen van moderne ontwikkeling onthullen, maar tegelijkertijd stellen ze niet altijd een specifiek en systemisch alternatief voor.

TK is op zichzelf een brondocument voor het ontwerp van een technische faciliteit.Het legt het hoofddoel van deze ontwikkeling vast, evenals verschillende tactische en technische kenmerken, kwaliteitsindicatoren en allerlei technische en economische vereisten, en geeft ook speciale vereisten aan waarmee tijdens het werk rekening moet worden gehouden. De taak als brondocument om enkele nieuwe dingen te maken bestaat in elk modern werkterrein, maar het kan variëren, afhankelijk van de inhoud, de volgorde van het ontwerp en een aantal andere parameters.

Functies van gebruik

Het is heel natuurlijk dat de vereisten in GOST duidelijk niet voldoende zijn, zodat uiteindelijk iedereen een effectief voorbeeld van een technische taak kan creëren, en dit is heel normaal, omdat niet iedereen het werk kan doen in volledige overeenstemming met de normen. Naast GOST zelf moet ook rekening worden gehouden met bepaalde methoden en praktijken, en dit feit ligt aan de basis van dit probleem.

Veel experts, om welke reden dan ook, die technische specificaties ontwikkelen voor het ontwerp van een object of het uitvoeren van bepaalde werken, zijn uitsluitend gebaseerd op de vereisten van GOST, maar in werkelijkheid is dit fundamenteel de verkeerde aanpak.

Hoofd uitdaging

Zoals uit de definitie zelf volgt, is het hoofddoel van TK het formuleren van de basisvereisten voor het ontwikkelde object. In dit geval moet men goed begrijpen dat we het hebben over de basisvereisten, maar niet de enige.

Hoe de vereisten bepalen?

Allereerst moet u onthouden dat de taakomschrijving voor ontwerp of ontwikkeling eisen moet bevatten die worden verdeeld door eigenschappen en typen. Hierin helpt GOST ons het meest. De lijst die daar te vinden is, is een uitstekend voorbeeld van de soorten die moeten worden overwogen, namelijk:

• functionaliteit;
• beveiliging en toegangsrechten;
• kwalificaties van het personeel.

Waar moet u op letten?

Dit is natuurlijk geen volledige lijst. De belangrijkste factor die moet worden onderscheiden door een succesvol voorbeeld van de technische taak, zijn de correct geformuleerde vereisten voor functionaliteit, en het zijn aan deze vereisten dat de professionals de overgrote meerderheid van methoden en werken wijden. Veel experts zeggen dat de vereisten voor functionaliteit ongeveer 90% van de totale complexiteit van het werk met betrekking tot de ontwikkeling van technische specificaties omvatten, en al het andere is een soort "camouflage", die dan op deze vereisten wordt gedragen.

Als de vereisten onjuist zijn geformuleerd, maakt het niet uit hoe mooi je ze camoufleert, uiteindelijk zal het niet werken om een ​​echt succesvol project te maken. Natuurlijk is volgens GOST aan alle vereisten voldaan, zijn de referentievoorwaarden (voorbeeld hieronder) ontwikkeld, ondertekend en goedgekeurd en heeft de specialist de betaling ontvangen, maar dan moet je weten wat je met dit document moet doen. Als we het hebben over een project voor een staatsorde, ontstaan ​​er vaak geen problemen, omdat er veel kleinere budgetbeperkingen zijn en de belangrijkste details al in het implementatieproces worden geïdentificeerd. Maar als we het hebben over commerciële organisaties, waar ze geld meer in detail beschouwen en een ander resultaat vereisen, dan is alles al ingewikkelder.

Nuttige en effectieve ontwikkeling

Als de soorten vereisten heel verschillend kunnen zijn, en hier alles hoofdzakelijk alleen afhankelijk is van de doelen van het project, dan zijn er slechts drie eigenschappen:

• duidelijkheid;
• beton;
• testbaarheid.

Tegelijkertijd moet men goed begrijpen dat, bij het ontwikkelen van een technische taak, een monster correct moet worden getest, en dit hangt al af van de eerste twee eigenschappen.Als het resultaat van het voldoen aan een of andere vereiste niet kan worden getest, geeft dit aan dat deze vereiste ofwel niet volledig wordt begrepen of niet specifiek is, en u moet erover nadenken, omdat het in het bezit van deze eigenschappen van de vereisten ligt dat de professionaliteit en vaardigheden van de ontwikkelaar liggen, en daarom voeren ervaren specialisten dergelijk werk veel sneller en beter uit.

Aanvullende nuances

Er zijn ook enkele belangrijke punten waarmee rekening moet worden gehouden bij het ontwikkelen van een technische taak. Het systeem van eisen is als volgt:

• Welke taal (vanuit het oogpunt van complexiteit van perceptie) moet deze worden geschreven?
• Is het noodzakelijk om hierin specifieke kenmerken van verschillende functies, algoritmen, soorten benodigde informatie en andere technische subtiliteiten te beschrijven?
• Wat is technisch ontwerp, dat trouwens wordt opgemerkt in bestaande standaardspecificaties, en hoe verhoudt het zich tot de samengestelde technische specificaties?

De antwoorden op al deze vragen zijn vrij belangrijk, en juist om deze reden beginnen velen vaak ruzie te maken over hoe toereikend de opgestelde TEM is en of deze alle noodzakelijke details van de vereisten bevat. Het is onder andere belangrijk hoe begrijpelijk dit document zal zijn vanuit het oogpunt van de klant en de aannemer, hoe overtollig het is en wat de presentatie-indeling is.

Taak en project

TK is een document dat verschillende vereisten bevat die zijn geformuleerd in een taal die zeer begrijpelijk is voor de klant en voor de aannemer. Bovendien, als een professional een technische taak ontwikkelt, kunnen zijn diensten ook het gebruik van industriële technologie omvatten, die is ontworpen om de meest begrijpelijke bewoording voor de uiteindelijke aannemer te bieden. Het is belangrijk om te onthouden dat het noodzakelijk is om elke binding met de specifieke kenmerken van de technische implementatie te voorkomen, dat wil zeggen dat het bij het ontwikkelen van TK in principe niet uitmaakt op welk specifiek platform de implementatie van al deze vereisten zal worden geïmplementeerd. Natuurlijk zijn er bepaalde uitzonderingen, maar dit zijn speciale gevallen.

De verduidelijking en verdere formulering van de verschillende vereisten, evenals de uiteindelijke ontwikkeling van de ToR, moet al worden gedaan door een gespecialiseerde bedrijfsanalist en niet door de uitvoerder (tenzij hij deze rollen natuurlijk in zichzelf combineert, wat periodiek gebeurt). Met andere woorden, de specialist moet met de klant communiceren in de taal van het bedrijf dat hij uitvoert.

Verschillen van het project met de taak

Het maken van een technische taak vanuit een project is anders, in die zin dat het een document is met de basisvereisten voor hoe de vereisten die zijn gespecificeerd in de ToR moeten worden geïmplementeerd. Dit document bevat de belangrijkste subtiliteiten van het geïmplementeerde product en de noodzakelijke elementen die door technische specialisten in het werk zullen worden gebruikt.

Het is niet nodig voor de klant om zich te verdiepen in dergelijk werk, omdat de overgrote meerderheid van de vereisten hem misschien niet eens duidelijk zijn. Vaak wordt de uitvoering van een technisch project uitgevoerd door een specifieke specialist, daarom is het al heel goed mogelijk om deze rol met de uitvoerder te combineren. Tegelijkertijd moet je begrijpen dat hoe groter het project is, hoe meer mensen de technische specificaties ontwikkelen.

Wat is de praktijk?

Het komt vaak voor dat de directeur naar de coördinatie van TK wordt gebracht, die veel technische terminologie omvat, waardoor hij zich hierin probeert te verdiepen, vertrouwde woorden probeert te vangen en de belangrijkste keten van bedrijfsvereisten niet verliest. In de regel is de technische taak voor werk in dergelijke situaties nog steeds goedgekeurd, geïmplementeerd en in de meeste gevallen blijkt het resultaat niet overeen te komen met het feit van het uitgevoerde werk, omdat werd besloten dat een groot aantal nuances moest worden gewijzigd, vernieuwd,en sommige elementen werden verkeerd begrepen, en tal van andere problemen deden zich voor.

Daarom is het belangrijk om het verschil te begrijpen tussen TK en het technische ontwerp, dat deels gerelateerd is aan de competentie van de relevante specialisten en deels aan de wens om het budget en de tijd te verminderen, omdat dergelijke documentatie veel tijd kost.