Ne visi supranta, kaip svarbu teisingai kurti technines specifikacijas, tačiau iš tikrųjų tai yra toks platus klausimas, kad neveiks trumpai. Dėl šios priežasties prieš atlikdami šią procedūrą turite suprasti visas svarbias subtilybes.
Kam tai skirta?
Prieš aptardami, kaip teisingai sukurti technines specifikacijas, turite suprasti, kodėl tai daroma ir kas vėliau tai naudos, nes nuo to gana priklauso požiūris, kaip atlikti šią procedūrą. Verta paminėti keletą pagrindinių variantų:
- Komercinė organizacija ketina įdiegti visiškai automatizuotą sistemą, tačiau ji neturi savo IT paslaugos, todėl nusprendė atlikti šiuos veiksmus: tam tikras suinteresuotas asmuo parengia technines užduotis, o paskui jas atiduoda trečiųjų šalių organizacijoms toliau plėtoti.
- Komercinė įmonė ketina naudoti automatizuotą sistemą ir turi veikiančią IT paslaugą. Esant tokiai situacijai, yra plėtojamas TK, po kurio išsamiai deramasi su IT tarnyba, o po to išsiunčiama suinteresuotoms šalims, o galiausiai jis parduodamas atskirai.
- Vyriausybė ruošiasi užbaigti konkretų IT projektą. Čia jau susiduriama su daugybe subtilumų ir nesklandumų, įskaitant įvairius formalumus, todėl net nepatartina svarstyti šios galimybės, nes kiekvienas atskiras atvejis dažniausiai reikalauja visiškai individualaus požiūrio.
Sudėtingesni atvejai
Sunkiausias atvejis yra tas, kai IT įmonė parengia technines specifikacijas, skirtas vėlesniam automatinių sistemų kūrimui ir diegimui. Tokiose situacijose turite dirbti labai įvairiomis sąlygomis, tokiomis kaip:
- Kliento buvimas savo specialistais, turintis savo viziją apie šį procesą, o tai kelia tam tikrus reikalavimus sudarytam TOR.
- Techninės specifikacijos yra sukurtos tik jų pačių kūrėjams, o klientui iš esmės nėra taip svarbu, koks bus rezultatas.
- TK bus perduota rangovui, tai yra, tam tikrai specialistų grupei, esančiai už įmonės darbuotojų ribų.
- Tarp įmonės ir kliento kyla nesusipratimas dėl rezultato, todėl įmonė nežino, kaip teisingai sukurti technines priežiūros specifikacijas.
Yra ir daugybė kitų situacijų, į kurias taip pat reikia atsižvelgti, tačiau aukščiau nurodytos tik dažniausios.
Kas yra TK?
Yra gana didelis skaičius GOST ir tam tikrų standartų, kurie yra skirti kiekvienai veiklos sričiai reguliuoti. Visų pirma, į tokius standartus reikia atsižvelgti rengiant technines priežiūros specifikacijas. Tuo pačiu metu gali kilti aktyvių diskusijų apie tai, kokie yra šie dokumentai, tačiau bet kokiu atveju kurdami savo projektą turite visiškai jų laikytis. Tiesą sakant, reikia teisingai suprasti, kad GOST dažniausiai neatskleidžia praktinių šiuolaikinės plėtros problemų, tačiau tuo pat metu ne visada siūlo konkrečią ir sisteminę alternatyvą.
TK savaime yra pirminis dokumentas, reglamentuojantis techninės įrangos projektavimą.Jame nustatomas pagrindinis šios plėtros tikslas, taip pat įvairios taktinės ir techninės charakteristikos, kokybės rodikliai ir visų rūšių techniniai bei ekonominiai reikalavimai, taip pat nurodomi specialieji reikalavimai, į kuriuos būtina atsižvelgti atliekant darbą. Užduotis kaip šaltinio dokumentas sukurti kai kuriuos naujus dalykus egzistuoja kiekvienoje šiuolaikinėje veiklos srityje, tačiau ji gali skirtis priklausomai nuo turinio, projektavimo tvarkos ir daugelio kitų parametrų.
Naudojimo ypatybės
Visiškai natūralu, kad GOST reikalavimų aiškiai nepakanka, kad galų gale visi galėtų sukurti veiksmingą techninės užduoties pavyzdį, ir tai yra visiškai normalu, nes ne visi gali atlikti darbą visiškai laikydamiesi standartų. Be paties GOST, taip pat reikia atsižvelgti į tam tikrus metodus ir praktiką, ir šis faktas yra šios problemos priežastis.
Daugelis ekspertų dėl tam tikrų priežasčių, kurdami objekto projektavimo technines specifikacijas ar atlikdami tam tikrus darbus, remiasi vien GOST reikalavimais, tačiau iš tikrųjų tai iš esmės yra neteisingas požiūris.
Pagrindinis iššūkis
Kaip išplaukia iš paties apibrėžimo, pagrindinis TK tikslas yra suformuluoti pagrindinius reikalavimus kuriamam objektui. Tokiu atveju reikia teisingai suprasti, kad mes kalbame apie pagrindinius reikalavimus, bet ne vienintelius.
Kaip nustatyti reikalavimus?
Visų pirma, jūs turite atsiminti, kad projektavimo ar tobulinimo sąlygose turėtų būti reikalavimai, padalyti iš savybių ir tipų. Tiesą sakant, GOST mums labiausiai padeda. Čia pateiktas sąrašas yra puikus pavyzdys, kokius jų tipus reikės apsvarstyti, būtent:
- Funkcionalumas
- saugumas ir prieigos teisės;
- personalo kvalifikacija.
Į ką atkreipti dėmesį?
Žinoma, tai nėra visas sąrašas. Tačiau pagrindinis veiksnys, kurį reikėtų išskirti iš sėkmingo techninės užduoties pavyzdžio, yra tinkamai suformuluoti funkcionalumo reikalavimai, ir būtent šiems reikalavimams specialistai skiria didžiąją dalį metodų ir darbų. Daugelis ekspertų teigia, kad funkcionalumo reikalavimai apima apie 90% viso darbo, susijusio su techninių specifikacijų kūrimu, sudėtingumo, o visa kita yra savotiškas „kamufliažas“, kuris vėliau bus dėvimas pagal šiuos reikalavimus.
Jei reikalavimai suformuluoti neteisingai, nesvarbu, kaip gražiai ant jų uždėsite kamufliažą, galų gale neveiks norint sukurti tikrai sėkmingą projektą. Žinoma, atsižvelgiant į GOST, visi reikalavimai yra visiškai įvykdyti, užduotys (pavyzdys pateiktas žemiau) yra parengtos, pasirašytos ir patvirtintos, o specialistas už tai gavo apmokėjimą, tačiau tada jūs turite suprasti, ką daryti su šiuo dokumentu. Jei mes kalbame apie valstybės užsakymo projektą, tada dažnai jokių problemų nekyla, nes yra daug mažesnių biudžeto suvaržymų, o pagrindinės detalės jau bus įvardytos įgyvendinimo procese. Bet jei mes kalbame apie komercines organizacijas, kur jos išsamiau apsvarsto pinigus ir reikalauja kitokio rezultato, tada viskas jau yra sudėtingesnė.
Naudinga ir efektyvi plėtra
Jei reikalavimų tipai gali būti labai skirtingi, o čia viskas daugiausia priklauso tik nuo projekto tikslų, tada yra tik trys savybės:
- suprantamumas;
- specifiškumas;
- išbandomumas.
Tuo pačiu metu reikia teisingai suprasti, kad, kuriant techninę užduotį, pavyzdys turi būti teisingai išbandytas, ir tai jau priklauso nuo pirmųjų dviejų savybių.Jei vieno ar kito reikalavimo įvykdymo rezultatas negali būti patikrintas, tai rodo, kad šis reikalavimas arba nėra visiškai suprantamas, arba nėra konkretus, ir jūs turite apie tai galvoti, nes būtent šių reikalavimų nuosavybė priklauso kūrėjo profesionalumui ir įgūdžiams, ir todėl patyrę specialistai tokį darbą atlieka daug greičiau ir geriau.
Papildomi niuansai
Taip pat yra keletas svarbių punktų, į kuriuos reikia atsižvelgti kuriant techninę užduotį. Reikalavimų sistema yra tokia:
- Kokia kalba (suvokimo sudėtingumo požiūriu) ji turėtų būti parašyta?
- Ar būtina jame aprašyti konkrečias įvairių funkcijų ypatybes, algoritmus, reikalingos informacijos rūšis ir kitas technines subtilybes?
- Kas yra techninis projektas, kuris, beje, pažymimas esamose valstybės standartų specifikacijose, ir kaip jis susijęs su sudarytomis techninėmis specifikacijomis?
Atsakymai į visus šiuos klausimus yra gana svarbūs ir būtent dėl šios priežasties daugelis dažnai pradeda ginčytis dėl to, ar pakanka parengto TOR ir ar jame yra visos būtinos reikalavimų detalės. Be kita ko, taip pat svarbu, kiek šis dokumentas bus suprantamas užsakovo ir rangovo požiūriu, koks jis nereikalingas ir koks yra pateikimo formatas.
Užduotis ir projektas
TK yra dokumentas, apimantis įvairius reikalavimus, kurie suformuluoti kalba, kuri yra ypač suprantama klientui ir rangovui. Be to, jei specialistas rengia techninę užduotį, jo paslaugos taip pat gali apimti pramonės technologijos, skirtos galutiniam rangovui suprantamiausiai suformuluoti, naudojimą. Čia svarbu atsiminti, kad būtina vengti bet kokio susirišimo su techninio įgyvendinimo specifika, tai yra, kuriant TK, iš esmės nesvarbu, kurioje konkrečioje platformoje visi šie reikalavimai bus įgyvendinti. Žinoma, yra tam tikrų išimčių, tačiau tai yra ypatingi atvejai.
Įvairių reikalavimų išaiškinimą ir tolesnį suformulavimą, taip pat galutinį TG sukūrimą turėtų atlikti jau specializuotas verslo analitikas, o ne vykdytojas (nebent, žinoma, jis pats derina šiuos vaidmenis savyje, o tai vyksta periodiškai). Kitaip tariant, specialistas turi bendrauti su klientu jo vadovaujamos verslo kalba.
Projekto skirtumai nuo užduoties
Techninės užduoties sukūrimas iš projekto skiriasi tuo, kad pastarasis yra dokumentas, kuriame pateikiami pagrindiniai reikalavimai, kaip turėtų būti įgyvendinami TOR nurodyti reikalavimai. Šiame dokumente pateikiamos pagrindinės įgyvendinto produkto subtilybės ir būtini elementai, kuriuos darbe naudos techniniai specialistai.
Klientui nereikia gilintis į tokį darbą, nes didžioji dauguma reikalavimų jam gali net būti neaiškūs. Dažnai techninio projekto įgyvendinimą vykdo konkretus specialistas, todėl jau gana įmanoma suderinti šį vaidmenį su atlikėju. Tuo pačiu metu jūs turite suprasti, kad kuo didesnis projektas, tuo daugiau žmonių rengia technines specifikacijas.
Kokia praktika?
Dažnai atsitinka taip, kad direktorius priverstas koordinuoti TK, į kurį įeina labai daug techninės terminijos, dėl kurio jis bando į tai įsigilinti, bandydamas pagauti pažįstamus žodžius ir neprarasti pagrindinės verslo reikalavimų grandinės. Paprastai tokiose situacijose vis dar patvirtinama, įgyvendinama darbo techninė užduotis ir dažniausiai paaiškėja, kad rezultatas neatitinka atlikto darbo fakto, nes daugybę niuansų buvo nuspręsta pakeisti, perdaryti,kai kurie elementai buvo nesuprasti, kilo daugybė kitų problemų.
Štai kodėl svarbu suprasti skirtumą tarp TK ir techninio projekto, kuris iš dalies yra susijęs su atitinkamų specialistų kompetencija, o iš dalies - su noru sumažinti biudžetą ir laiką, nes tokia dokumentacija reikalauja daug laiko.
