Kaikki eivät ymmärrä, kuinka tärkeätä on kehittää teknisiä eritelmiä oikein, mutta itse asiassa kysymys on niin laaja, että se ei toimi pähkinänkuoressa. Tästä syystä, ennen kuin jatkat tätä menettelyä, sinun on ymmärrettävä kaikki asiaan liittyvät hienot yksityiskohdat.
Mistä tämä on tarkoitettu?
Ennen kuin keskustelemme siitä, kuinka tekniset eritelmät kehitetään oikein, sinun on ymmärrettävä, miksi tämä tehdään ja kuka sitä myöhemmin käyttää, koska tarvittava lähestymistapa tämän menettelyn toteuttamiseen riippuu melko voimakkaasti tästä. On syytä huomata muutama perusvaihtoehto:
- Kaupallinen organisaatio aikoo ottaa käyttöön täysin automatisoidun järjestelmän, mutta sillä ei ole omaa tietotekniikkapalvelua, minkä seurauksena se päätti toimia seuraavasti: tietty kiinnostunut kehittää teknisiä tehtäviä ja luovuttaa ne sitten kolmansien osapuolien organisaatioille jatkokehitystä varten.
- Kaupallinen yritys aikoo käyttää automatisoitua järjestelmää, ja sillä on toimiva IT-palvelu. Tässä tilanteessa TK kehitetään, minkä jälkeen se neuvotellaan yksityiskohtaisesti IT-palvelun kanssa ja lähetetään sitten sidosryhmille, ja lopulta se myydään yksinään.
- Hallitus valmistelee tiettyä IT-hanketta. Monet hienoukset ja sudenkuopat, mukaan lukien kaikenlaiset muodollisuudet, ovat jo täällä pintoja, joten tätä vaihtoehtoa ei ole edes suositeltavaa harkita, koska jokainen yksittäinen tapaus vaatii useimmiten täysin yksilöllisen lähestymistavan.
Monimutkaisempia tapauksia
Vaikein tapaus on, kun tietotekniikkayritys on kehittänyt tekniset eritelmät automatisoitujen järjestelmien myöhempää kehittämistä ja käyttöönottoa varten. Tällaisissa tilanteissa joudut työskentelemään monenlaisissa olosuhteissa, kuten:
- Asiakkaan läsnäolo omien asiantuntijoiden kanssa, jolla on oma näkemys tästä prosessista, joka asettaa tietyt vaatimukset kootulle TOR: lle.
- Tekniset eritelmät luodaan yksinomaan heidän omistajilleen, eikä asiakkaalla periaatteessa ole niin tärkeää mitä lopputuloksena on.
- TK siirretään urakoitsijalle, ts. Tietylle asiantuntijaryhmälle, joka sijaitsee yrityksen henkilöstön ulkopuolella.
- Yrityksen ja asiakkaan välillä on väärinkäsitys tuloksesta, joten yritys ei osaa kehittää kunnossapidon teknisiä eritelmiä oikein.
On myös monia muita tilanteita, jotka on myös harkittava, mutta vain yleisimmät on mainittu edellä.
Mikä on TK?
On melko suuri määrä GOST-standardeja ja tiettyjä standardeja, joiden tarkoituksena on säännellä kutakin toiminta-aluetta. Erityisesti tällaiset standardit on otettava huomioon kehitettäessä kunnossapidon teknisiä eritelmiä. Samaan aikaan voi käydä aktiivista keskustelua näiden asiakirjojen merkityksellisyydestä, mutta joka tapauksessa oman hankkeen kehittämisprosessissa sinun on noudatettava niitä täysin. Itse asiassa on ymmärrettävä oikein, että GOST-tekniikat eivät useimmiten paljasta nykyaikaisen kehityksen käytännön ongelmia, mutta samalla ne eivät aina ehdota erityistä ja systeemistä vaihtoehtoa.
TK itsessään on lähdeasiakirja, joka ohjaa teknisen laitoksen suunnittelua.Siinä määritetään tämän kehityksen päätarkoitus, samoin kuin erilaiset taktiset ja tekniset ominaisuudet, laatuindikaattorit ja kaikenlaiset tekniset ja taloudelliset vaatimukset sekä ilmoitetaan myös erityisvaatimukset, jotka on otettava huomioon työn aikana. Tehtävä lähdedokumenttina luoda joitain uusia asioita on olemassa kaikilla nykyaikaisilla toiminta-alueilla, mutta se voi vaihdella sisällöstä, suunnittelun järjestyksestä ja monista muista parametreista riippuen.
Käyttöominaisuudet
On aivan luonnollista, että GOST-vaatimukset eivät selvästikään riitä, jotta lopulta kaikki voivat luoda tehokkaan esimerkin teknisestä tehtävästä, ja tämä on aivan normaalia, koska kaikki eivät voi tehdä työtä täysin standardien mukaisesti. Itse GOST: n lisäksi tietyt menetelmät ja käytännöt on myös otettava huomioon, ja tämä tosiasia on tämän ongelman syy.
Monet asiantuntijat kehittävät jostakin syystä tekniset eritelmät esineen suunnitteluun tai tiettyjen töiden suorittamiseen, ja perustuvat yksinomaan GOST: n vaatimuksiin, mutta todellisuudessa tämä on pohjimmiltaan väärä lähestymistapa.
Päähaaste
Kuten itse määritelmästä seuraa, TK: n päätarkoitus on muotoilla kehitetyn kohteen perusvaatimukset. Tässä tapauksessa on ymmärrettävä oikein, että puhumme perusvaatimuksista, mutta emme ainoita.
Kuinka määritellä vaatimukset?
Ensinnäkin, sinun on muistettava, että suunnittelu- tai kehitysohjeiden tulisi sisältää vaatimukset, jotka on jaettu ominaisuuksilla ja tyypeillä. Tässä itse asiassa GOST auttaa meitä eniten. Sieltä löytyvä luettelo on erinomainen esimerkki siitä, minkä tyyppisiä niitä on harkittava:
- toiminnallisuutta;
- turvallisuus ja käyttöoikeudet;
- henkilöstön pätevyys.
Mihin kiinnittää huomiota?
Tietenkin, tämä ei ole täydellinen luettelo. Tärkein tekijä, joka on erotettava onnistuneella esimerkillä teknisestä tehtävästä, on oikein muotoillut toiminnallisuusvaatimukset, ja juuri näille vaatimuksille ammattilaiset omistavat valtaosan menetelmistä ja töistä. Monet asiantuntijat sanovat, että toiminnallisuusvaatimukset sisältävät noin 90% teknisten eritelmien kehittämiseen liittyvän työn kokonaismäärästä, ja kaikki muu on eräänlainen "naamiointi", jota sitten käytetään näihin vaatimuksiin.
Jos vaatimukset on muotoiltu väärin, riippumatta siitä, kuinka kauniita teille naamioit ne, lopulta se ei toimi todella onnistuneen projektin tekemiseen. GOST: n mukaan tietysti kaikki vaatimukset täyttyvät kokonaan, ohjeet (alla oleva esimerkki) kehitetään, allekirjoitetaan ja hyväksytään, ja asiantuntija sai maksun siitä, mutta sitten sinun on ymmärrettävä, mitä tämän asiakirjan kanssa tehdä. Jos puhumme valtion tilausta koskevasta hankkeesta, niin usein ongelmia ei aiheudu, koska budjettirajoitukset ovat paljon pienemmät, ja tärkeimmät yksityiskohdat tunnistetaan jo täytäntöönpanoprosessissa. Mutta jos puhutaan kaupallisista organisaatioista, joissa ne harkitsevat rahaa yksityiskohtaisemmin ja vaativat erilaista tulosta, niin kaikki on jo monimutkaisempaa.
Hyödyllinen ja tehokas kehitys
Jos vaatimustyypit voivat olla hyvin erilaisia, ja tässä kaikki riippuu pääasiassa yksinomaan hankkeen tavoitteista, niin ominaisuuksia on vain kolme:
- selkeys;
- betoni;
- testattavuus.
Samanaikaisesti on ymmärrettävä oikein, että teknistä tehtävää kehitettäessä näyte on testattava oikein, ja tämä riippuu jo kahdesta ensimmäisestä ominaisuudesta.Jos yhden tai toisen vaatimuksen täyttymisen tulosta ei voida testata, tämä osoittaa, että tätä vaatimusta ei joko ymmärretä kokonaan tai se ei ole tarkka, ja sinun on mietittävä sitä, koska kehittäjien ammattitaito ja taidot ovat näiden vaatimusten ominaisuuksien omistuksessa, ja siksi kokeneet asiantuntijat suorittavat tällaisen työn paljon nopeammin ja paremmin.
Muita vivahteita
On myös joitain tärkeitä seikkoja, jotka on otettava huomioon teknistä tehtävää kehitettäessä. Vaatimusjärjestelmä on seuraava:
- Mitä kieltä (käsityksen monimutkaisuuden kannalta) se tulisi kirjoittaa?
- Onko siinä tarpeen kuvailla eri toimintojen, algoritmien, tarvittavien tietojen tyypit ja muut tekniset hienot ominaisuudet?
- Mikä on tekninen suunnittelu, joka muuten mainitaan olemassa olevissa valtion standardimääritelmissä, ja miten se liittyy koottuihin teknisiin eritelmiin?
Vastaukset kaikkiin näihin kysymyksiin ovat melko tärkeitä, ja juuri tästä syystä monet alkavat kiistellä siitä, kuinka riittävä suunniteltu oma pääoma on ja sisältääkö se kaikki tarvittavat yksityiskohdat vaatimuksista. Muun muassa on tärkeää, kuinka ymmärrettävää tämä asiakirja tulee olemaan asiakkaan ja urakoitsijan kannalta, kuinka tarpeeton se on ja mikä on esitysmuoto.
Tehtävä ja projekti
TK on asiakirja, joka sisältää erilaisia vaatimuksia, jotka on muotoiltu asiakkaalle ja urakoitsijalle erittäin ymmärrettävällä kielellä. Lisäksi, jos ammattilainen kehittää teknistä tehtävää, hänen palveluihinsa voi kuulua myös teollisuustekniikan käyttö, jonka tarkoituksena on tarjota loppurakoitsijalle ymmärrettävämpi sanamuoto. Tässä yhteydessä on tärkeää muistaa, että on vältettävä sitoumuksia teknisen toteutuksen erityispiirteisiin, ts. TK: n kehittämisprosessissa ei periaatteessa ole väliä millä erityisellä alustalla kaikkien näiden vaatimusten toteutus toteutetaan. Tietenkin on tiettyjä poikkeuksia, mutta nämä ovat erityistapauksia.
Erilaisten vaatimusten selventämisen ja edelleen muotoilun sekä toimeksiannon lopullisen kehittämisen tulisi jo tehdä erikoistuneelle liiketoimintaanalyytikolle, ei toimeenpanijalle (paitsi jos hän tietysti yhdistää nämä roolit itsessään, mikä tapahtuu määräajoin). Toisin sanoen asiantuntijan on kommunikoitava asiakkaan kanssa liiketoiminnan kielellä, jota hän harjoittaa.
Projektin erot tehtävästä
Teknisen tehtävän luominen projektista eroaa siinä, että jälkimmäinen on asiakirja, joka sisältää perusvaatimukset toimeksiannossa määriteltyjen vaatimusten toteuttamiselle. Tämä asiakirja sisältää toteutetun tuotteen pääpiirteet ja tarvittavat elementit, joita tekniset asiantuntijat käyttävät työssä.
Asiakkaan ei tarvitse kuvitella tällaiseen työhön, koska valtaosa vaatimuksista ei välttämättä edes ole hänelle selvä. Usein teknisen projektin toteuttaa tietty asiantuntija, siksi on jo mahdollista yhdistää tämä rooli esiintyjän kanssa. Samanaikaisesti sinun on ymmärrettävä, että mitä suurempi projekti on, sitä enemmän ihmiset kehittävät teknisiä eritelmiä.
Mikä on käytäntö?
Usein käy niin, että johtaja saatetaan TK: n koordinointiin, joka sisältää paljon teknistä terminologiaa, minkä seurauksena hän yrittää syventyä tähän, yrittää tarttua tuttuihin sanoihin eikä kadota yrityksen pääketjua. Pääsääntöisesti tällaisissa tilanteissa työn tekninen tehtävä hyväksytään, toteutetaan, ja useimmissa tapauksissa käy ilmi, että tulos ei vastaa suoritetun työn tosiasiaa, koska suuri joukko vivahteita päätettiin muuttaa, muuttaa,ja joitain elementtejä ymmärrettiin väärin, ja syntyi joukko muita ongelmia.
Siksi on tärkeää ymmärtää ero TK: n ja teknisen suunnittelun välillä, mikä liittyy osittain asiaankuuluvien asiantuntijoiden pätevyyteen ja toisaalta haluun vähentää budjettia ja aikaa, koska tällainen dokumentointi vie paljon aikaa.
