Esimerkki tuotteen muokkauksen teknisistä tiedoista. Tutkimuslaitoksen ilmanvaihdon modernisoinnin tekniset tiedot

Pavel Moljanov

Muistatko Murphyn lain? Jos sinut voidaan ymmärtää väärin, sinut ymmärretään varmasti väärin. Tämä ei päde vain ihmisten välisessä viestinnässä, vaan myös verkkosivustojen luomisessa. Asiakas halusi toisen Facebookin, mutta sai foorumin nuorille koirankasvattajille. Kehittäjä ei arvannut mitä asiakas halusi - hän tuhlasi aikaansa.

Tässä oppaassa kerron sinulle, mitä ja miksi sinun tulee kirjoittaa toimeksiantoon. Samalla näytän sinulle, kuinka olla kirjoittamatta, jotta teknisten eritelmien luominen ei muutu ajanhukkaa.

Artikkeli on hyödyllinen:

• Kaikille verkkosivustojen luomiseen osallistuville: kehittäjille, suunnittelijoille, taittosuunnittelijoille.
• Projektipäälliköt.
• Digitaalisten studioiden johtajat.
• Yrittäjät, jotka suunnittelevat verkkosivujen kehittämisen tilaamista.

Jotta materiaalista olisi hyötyä, keräsin kommentteja useilta kehittäjiltä, ​​suunnittelijoilta, projektipäälliköiltä ja digistudioiden omistajilta. Lisäsin arvokkaimmat artikkelin loppuun. Mennään ottamaan selvää.

Mikä on tekninen eritelmä ja miksi sitä tarvitaan?

Tekninen eritelmä on asiakirja, joka määrittelee sivuston vaatimukset. Mitä selkeämpiä ja yksityiskohtaisempia nämä vaatimukset ovat, sitä paremmin kaikki prosessiin osallistujat ymmärtävät, millaista sen tulisi olla. Tämä tarkoittaa, että mahdollisuus, että kaikki ovat tyytyväisiä tulokseen, kasvaa.

Teknisen eritelmän päätavoitteena on varmistaa, että tilaaja ja urakoitsija ymmärtävät toisiaan oikein.

Teknisistä tiedoista on monia etuja. Se on erilainen jokaiselle puolelle.

Edut asiakkaalle:

• Ymmärrä, mistä hän maksaa rahaa ja millainen sivusto tulee olemaan. Näet heti rakenteen, ymmärrät, mikä toimii ja miten. Selvitä, sopiiko kaikki sinulle. Jos ei, sen muuttaminen ennen kehityksen aloittamista ei ole ongelma.
• Katso esiintyjän pätevyys. Jos toimeksianto on selkeä ja täsmällinen, luottamus kehittäjään lisääntyy. Jos siinä lukee puuroa, ehkä sinun pitäisi juosta eikä katsoa taaksepäin.
• Vakuuta esiintyjän epärehellisyyttä vastaan. Kun sivusto on valmis, se voidaan tarkastaa teknisten eritelmien mukaisesti. Onko epäjohdonmukaisuuksia? Kehittäjä on velvollinen korjaamaan ne. Jos teet yhteistyötä virallisesti ja olet tehnyt sopimuksen, voit jopa pakottaa sen oikeuteen.
• Yksinkertaista esiintyjien vaihtaminen. Jos asiakas ja kehittäjä riitelivät ja pakenivat, sivuston luominen voi viedä paljon aikaa. Kun yksityiskohtainen tekninen eritelmä on, se voidaan siirtää uudelle tiimille - he pääsevät työhön monta kertaa nopeammin.
• Ota selvää monimutkaisen tuotteen kehittämisen kustannuksista. Monimutkaisen verkkopalvelun kehittämisen tarkkaa ajoitusta ja kustannuksia on mahdotonta arvioida välittömästi. Ensin sinun on ymmärrettävä, miten palvelu toimii ja mitä toimintoja sillä on. Tätä varten sinun on laadittava tekniset tiedot.

Edut esiintyjälle:

• Ymmärtää mitä asiakas haluaa. Asiakkaalta kysytään kymmeniä kysymyksiä, näytetään esimerkkejä ja tarjotaan ratkaisuja. Sitten he kirjoittavat kaiken yhteen asiakirjaan ja sopivat siitä. Jos kaikki on kunnossa - hurraa, ymmärsit oikein.
• Vakuuta itsesi asiakkaan äkillisiä toiveita vastaan. Joskus törmäät asiakkaisiin, jotka haluavat muuttaa tehtävää puolivälissä. Jos olet sopinut ja allekirjoittanut toimeksiannon, et pelkää tätä. Jos jotain tapahtuu, jopa tuomioistuin on puolellasi.
• Näytä osaamisesi. Hyvin valmisteltu tekninen eritelmä näyttää asiakkaalle kehittäjien asiantuntemuksen. Jos yritys epäili, pitäisikö sinun luottaa verkkosivustojen kehittämiseen, epäilykset todennäköisesti hälvenevät.
• Tienata rahaa. Jotkut studiot ja kehittäjät tarjoavat teknisten eritelmien laatimisen erillisenä palveluna.

• Helpottaa ja nopeuttaa kehitysprosessia. Hyvä tekninen eritelmä ilmaisee jokaisella sivulla sivuston rakenteen, tarvittavat toiminnot ja elementit. Kun kaikki vaatimukset ovat jo silmien edessä, ei ole muuta kuin suunnitella ja kirjoittaa koodi.

Nyt selvitetään, kuinka luodaan hyvä tekninen eritelmä, joka suorittaa kaikki nämä toiminnot.

Toimeksiannon laatii esiintyjä

Yleensä kuka tahansa voi laatia tekniset tiedot. "Tarvitsemme hammasklinikalle käyntikorttisivuston" - tämä on jo tekninen tehtävä. Mutta täyttääkö se tehtävänsä? Tuskin.

Hyvän teknisen eritelmän laatii aina toteuttaja: projektipäällikkö tai kehittäjä. Ilmeisesti web-kehittäjä ymmärtää enemmän verkkosivustojen luomisesta kuin kahvilan tai hammasklinikan omistaja. Siksi hänen on kuvailtava hanke.

Tämä ei tarkoita, että asiakas katoaa ja ilmestyy aivan lopussa ja kirjoittaa: "Zbs, hyväksyn." Hänen tulee myös osallistua prosessiin:

Asiakas voi tietysti luonnostella oman versionsa teknisistä tiedoista. Ehkä tämä nopeuttaa lopullisten teknisten eritelmien luomista. Tai ehkä tuloksena on roskaa, joka heitetään salaa roskakoriin.

Kirjoita selkeästi ja tarkasti

Tämä neuvo seuraa toimeksiannon päätavoitteesta - "Varmista, että tilaaja ja urakoitsija ymmärtävät toisiaan oikein."

Tehtävä ei saa sisältää laadukkaita adjektiiveja: kaunis, luotettava, moderni. Niitä ei voi selkeästi ymmärtää. Jokaisella on omat käsityksensä kauneudesta ja nykyaikaisuudesta.

Katso. Jonkun mielestä tämä malli oli kaunis ja antoi sen käyttää verkkosivuillaan:

Sama tapahtuu epämääräisten formulaatioiden kanssa, jotka eivät sinänsä merkitse mitään:

• Asiakkaan tulee pitää sivustosta. Entä jos hän on huonolla tuulella?
• Sivuston tulee olla kätevä. Mitä se tarkoittaa? Kätevä mihin?
• Työpaikan on kestettävä raskaita kuormia. 10 tuhatta kävijää? Tai 10 miljoonaa?
• Laadukas asiantuntijasisältö. No ymmärrät idean.

Tarkista, onko tekstissä epäselvyyksiä. Jos on, kirjoita se uudelleen. Sanamuotosi tulee olla selkeä ja täsmällinen:

• Sivuston on latauduttava nopeasti → Jokaisella sivuston sivulla on oltava yli 80 pistettä Google PageSpeed ​​​​Insightsissa.
• Raskaat kuormat → 50 tuhatta kävijää samaan aikaan.
• Pääsivulla on luettelo artikkeleista → Pääsivulla näkyy luettelo 6 viimeisestä julkaistusta artikkelista.
• Minimalistinen käyttäjäystävällinen tilausliittymä → "Jätä sähköpostisi" -kenttä ja "Tilaa"-painike → *piirretty luonnos*.

Olemme selvittäneet sanamuodon, käydään läpi rakennetta.

Anna yleisiä tietoja

Kaikkien tiimin jäsenten on ymmärrettävä oikein, mitä yritys tekee ja kuka sen kohdeyleisö on. Jotta kukaan ei hämmentyisi, on parempi kirjoittaa tämä muistiin heti toimeksiannon alkuun.

Kannattaa myös mainita sivuston tarkoitus ja kuvata sen toimivuus pähkinänkuoressa – jottei päädy verkkokauppaan blogin sijaan.

Selitä vaikeat termit

Toimeksiannon ensimmäinen sääntö on, että sen on oltava kaikkien ymmärrettävissä, joille se on tarkoitettu. Jos aiot käyttää termejä, joita asiakkaasi, lasten lelukaupan omistaja, ei ehkä ymmärrä, muista selittää ne. Selkeällä kielellä, ei copy-paste Wikipediasta.

Kuvaa työkalut ja isännöintivaatimukset

Kuvittele, että vietit 2 kuukautta upean verkkosivuston luomiseen. Jokainen vaihe sovittiin asiakkaan kanssa - hän oli iloinen. Ja nyt on aika luovuttaa työt. Näytät hallintapaneelin ja asiakas huutaa: "Mikä tämä on? Modeksi?! Ajattelin, että tekisit sen WordPressillä!”

Tällaisten ongelmien välttämiseksi kuvaile käytetyt työkalut, moottorit ja kirjastot. Ilmoita samalla isännöintitarpeesi. Et koskaan tiedä, teet sen PHP:llä - ja asiakkaalla on palvelin .NET:ssä.

Listaa sivuston toiminnan vaatimukset

Sivuston tulee toimia kaikilla nykyisillä selaimilla ja kaikentyyppisillä laitteilla. Kyllä, tämä on ilmeistä kaikille kehittäjille ja asiakkaille. Mutta on parempi kirjoittaa suojellaksesi asiakasta vilpillisessä mielessä tehdyltä työltä.

Kirjoita tähän vaatimukset sivuston latausnopeudelle, kuormituksen kestävyydelle, hakkerihyökkäyksiltä suojautumisesta ja vastaavista asioista.

Määritä sivuston rakenne

Ennen kuin aloitat suunnittelun ja asettelun piirtämisen, sinun on sovittava sivuston rakenne asiakkaan kanssa.

Keskustele asiakkaan kanssa ja selvitä, mitä hän tarvitsee. Kokoa yhteen kehittäjät, SEO-asiantuntijat, markkinoijat, päätoimittaja - ja päätä, mitä sivuja sivustolle tarvitaan. Mieti, miten ne yhdistetään toisiinsa, mistä voit vaihtaa.

Voit näyttää rakenteen luettelolla, voit piirtää lohkokaavion. Kuten haluat.

Tämä on yksi sivuston työskentelyn tärkeimmistä vaiheista. Rakenne on perusta. Jos se ei onnistu, sivusto osoittautuu vinoon.

Selitä, mitä kullakin sivulla on

Asiakkaan tulee ymmärtää, miksi kutakin sivua tarvitaan ja mitä elementtejä sille tulee. On kaksi tapaa näyttää tämä.

Prototyyppi- visuaalisempi ja yksiselitteisempi tapa. Urakoitsija piirtää jokaisesta sivusta luonnokset ja liittää ne toimeksiantoon. Asiakas näkee miltä hänen tulevan nettisivunsa käyttöliittymä tulee näyttämään ja kertoo mistä pitää ja mitä pitää muuttaa.

Elementtien luettelointi- laiska vaihtoehto prototyypille. Kirjoita vain muistiin, mitä lohkojen tulisi olla sivulla ja mitä ne tekevät.

Kuvaile skenaarioita sivuston käytöstä

Jos olet tekemässä jonkinlaista epätyypillistä käyttöliittymää, pelkkä rakenteen ja sivujen pikkukuvien näyttäminen ei riitä. On tärkeää, että koko toteutusryhmä ja asiakas ymmärtävät, kuinka kävijät käyttävät sivustoa. Skriptit ovat hyviä tähän. Skenaariokaavio on hyvin yksinkertainen:

• Käyttäjän toiminta.
• Sivuston vastaus.
• Tulos.

Tietenkin, jos teet tavallisen käyntikortin tai aloitussivun, sinun ei tarvitse kirjoittaa skriptejä. Mutta jos sivustolla on joitain interaktiivisia palveluita, se on erittäin toivottavaa.

Lue lisää käyttötapauksista Wikipediasta.

Selvitä, kuka on vastuussa sisällöstä

Jotkut kehittäjät luovat verkkosivuston, jossa on sisältöä heti. Muut sijoittavat kaloja. Toiset taas voivat kirjoittaa tekstejä, mutta lisämaksusta. Sovi tästä rannalla ja kirjoita toimeksiantoon, mitä sisältöä sinun tulee valmistaa.

On melko vaikeaa keksiä objektiivisia kriteerejä tekstien laadun arvioimiseksi. On parempi olla kirjoittamatta muuta kuin "Laadukasta, mielenkiintoista ja myyvää kohdeyleisölle hyödyllistä sisältöä". Se on roskaa, kukaan ei tarvitse sitä.

On hyödyllistä määrittää, että kaiken sisällön on oltava yksilöllistä. Toinen suoja asiakkaalle häikäilemättömiltä esiintyjiltä.

Kuvaile mallia (jos voit)

Kuten tekstinkin tapauksessa, on vaikea keksiä objektiivisia kriteerejä verkkosivujen suunnittelun arvioimiseksi. Jos olette sopineet asiakkaan kanssa värimaailmasta, kirjoita se ylös. Jos hänellä on tuotemerkki, jossa fontit on määritetty, ilmoita myös ne.

Kauniista ja modernista muotoilusta ei tarvitse kirjoittaa. Se ei tarkoita mitään, sillä ei ole voimaa ja yleensä ugh.

Päätelmän sijaan: toimeksiannon rakenne

Teknisten eritelmien rakenne on erilainen eri tehtävissä. On typerää tehdä samat tekniset tiedot uudelle sosiaaliselle verkostolle ja porkkanoiden tukkumyynnin aloitussivulle. Mutta yleensä tarvitset nämä osiot:

• Tietoja yrityksestä ja kohdeyleisöstä, sivuston tavoitteista ja tavoitteista.
• Sanasto termeistä, jotka eivät välttämättä ole asiakkaalle selviä.
• Sivuston ulkoasun ja toiminnan tekniset vaatimukset.
• Kuvaus käytetyistä teknologioista ja luettelo hosting-vaatimuksista.
• Yksityiskohtainen sivuston rakenne.
• Sivujen prototyypit tai kuvaukset elementeistä, joiden pitäisi olla niillä.
• Skenaariot epästandardin käyttöliittymän käyttämisestä (valinnainen).
• Luettelo kehittäjän tekemästä sisällöstä.
• Suunnitteluvaatimukset (valinnainen).

• Ohjelmistovaatimusmäärittelyn laatimista koskevat säännöt. SRS on seuraava askel teknisten eritelmien kehityksessä. Tarvitaan suuriin ja monimutkaisiin projekteihin.
• Ohjelmistokehityksen teknisten eritelmien standardit ja mallit. Kuvaukset eri GOST:ista ja menetelmistä teknisten eritelmien luomiseksi.

Tämä on kirjoittamani osan loppu. Mutta on toinenkin - oppaan tekemiseen auttaneiden asiantuntijoiden kommentit. Lue se, se on myös mielenkiintoinen.

Kehittäjän kommentit

Keskustelin useiden kehittäjien kanssa selvittääkseni, kuinka he luovat tekniset tiedot. Annan mikrofonin heille.

Ensinnäkin asiakas tarvitsee tekniset tiedot - jotta hän ymmärtää, millainen hänen verkkosivustonsa tulee olemaan ja mihin rahat käytetään. Jos jotain tehdään väärin, hän voi viitata teknisiin eritelmiin ja pyytää sen uusimista.

Teknisen eritelmän laatii projektipäällikkö oltuaan yhteydessä tilaajan ja keskusteltuaan tehtävästä suunnittelijan kanssa.

Suuret asiakkaat pyytävät usein erittäin yksityiskohtaisia ​​teknisiä tietoja, joissa kuvataan jokainen painike. Pienet yritykset sitä vastoin eivät pidä huolellisista 100-sivuisista asiakirjoista. Se on pitkä luku, ja on helppo unohtaa jotain tärkeää. Useammin teemme tiiviitä 10–15 sivun teknisiä eritelmiä.

Osoitamme:

• Tietoja yrityksestä ja sivuston tarkoituksesta.
• Vaatimukset suunnittelulle, värimaailmalle.
• Käytetyt tekniikat ja CMS.
• Kuka tuottaa sisällön - me vai asiakas.
• Sivuston rakenne jokaiselle sivulle asti.
• Jokaisen sivun kuvaukset. Emme tee prototyyppejä, mutta määrittelemme, mitä elementtejä sivulla tulee olla ja miten niiden tulee toimia.

2 viimeistä osaa ovat tärkeimmät. He ovat niitä, jotka antavat käsityksen siitä, millainen sivusto tulee olemaan ja miten se toimii.

Erittäin tärkeä kohta - et voi vain antaa toimeksiantoja kehittäjille ja toivoa, että he tekevät kaiken hyvin. Tekninen eritelmä on luettelo sivuston vaatimuksista, se ei voi korvata viestintää. On tärkeää varmistaa, että jokainen tiimin jäsen ymmärtää yleistavoitteen eikä tee tehtäviä vain lennossa. Jos jokin on epäselvää, on tarpeen selittää, keskustella ja antaa yksityiskohtaisia ​​kommentteja.

Liitän usein sivujen prototyyppejä, jotta asiakas ymmärtää, miltä hänen sivustonsa tulee näyttämään. Sitten teen taittosuunnittelijalle erillisen tehtävän - teknisine yksityiskohtineen ja selitykset, jotka auttavat hänen työssään.

Mitä monimutkaisempi tehtävä, sitä yksityiskohtaisempi teknisen eritelmän tulee olla. Kun osallistuin suuriin projekteihin, näin tekniset tiedot, jotka olivat 30 sivua pitkiä.

Guram Sipki, digitaalisen studion Udix Media perustaja

Ensinnäkin asiakas tarvitsee tekniset tiedot - jotta hän ymmärtää, millainen hänen verkkosivustonsa tulee olemaan ja mihin rahat käytetään. Jos jotain tehdään väärin, hän voi viitata teknisiin eritelmiin ja pyytää sen uusimista.

Teknisen eritelmän laatii projektipäällikkö oltuaan yhteydessä tilaajan ja keskusteltuaan tehtävästä suunnittelijan kanssa.

Suuret asiakkaat kysyvät usein erittäin yksityiskohtaisia ​​teknisiä tietoja, joissa kuvataan jokainen painike. Pienet yritykset sitä vastoin eivät pidä huolellisista 100-sivuisista asiakirjoista.

Esimerkki teknisestä tehtävästä verkkosivuston parantamiseksi

Yleistä tietoa

Automatisoidun järjestelmän nimi

"AS Sbyt"

Asiakas

Toteuttaja

Työn peruste

Suunnitellut päivämäärät järjestelmän luontityön alkamiselle ja päättymiselle

Työ alkaa: 01.09.2010

Työn valmistuminen: 31.12.2010

Järjestelmän luomisen tarkoitus ja tavoitteet

Järjestelmän tarkoitus

Kehitettävä automatisoitu järjestelmä on suunniteltu automatisoimaan yrityksen myyntiprosesseja.

Järjestelmän luomisen tavoitteet

Tavoitteet automatisoidun järjestelmän luomisessa

"AS Sbytin" kehittämisen tavoitteet ovat:

1. 3. Automaatioobjektin ominaisuudet

3.1 Yrityksen liiketoimintaprosessit

3.1. 1 Liiketoimintaprosessi "Sopimuksen tekeminen"

Siitä tulee suojasi tässä asiakirjassa. Jos jotain tapahtuu, voit osoittaa sormella häikäilemätöntä kehittäjää ja vaatia, että sivustosi saatetaan sen mukaiseksi.

Tekninen tehtävä(lyhyesti "TOR") on asiakirja, joka kuvastaa tulevan verkkosivustosi vaatimuksia mahdollisimman yksityiskohtaisesti ja yksiselitteisesti.

Sivusto on luotu juuri teknisten eritelmien perusteella. Mitä yksityiskohtaisempi ja yksiselitteisempi se on, sitä paremmin uusi sivustosi vastaa odotuksiasi.

Verkkosivuston luomista koskevien toimeksiantojen - lain mukaan - ei pitäisi sallia tulkintoja ja ristiriitaisuuksia.

Kehittäjä tekee kaiken, mitä ei ole määritelty teknisissä eritelmissä oman harkintansa mukaan.

· Järjestelmänvalvojan opas;

· Sisällönhallintaopas;

· Asennusohje;

· Ohjelmoijan opas.

2.20. Venäjän federaation syyttäjänviraston alaisen tutkintakomitean asiantuntijoiden koulutuksen järjestäminen ja toteuttaminen

Seuraavat koulutusvaatimukset ovat voimassa:

· Urakoitsijan on järjestettävä koulutus Venäjän federaation syyttäjänviraston tutkintakomitean työntekijöille, joissa on enintään 10 henkilöä.

· Koulutus tulee suorittaa venäjäksi.

· Asiakas tarjoaa koulutustilat.

· Koulutuksen paikka ja aika tulee sopia Asiakkaan kanssa.

Koulutus on suoritettava kaikista järjestelmän toiminnoista.

Osana koulutusta on tarpeen suorittaa Venäjän federaation syyttäjänviraston alaisen tutkintakomitean Ring of Sites -pilottisivuston tietosisältö.

3.

Esimerkki tekniset tiedot verkkosivuston parantamiseksi

Tärkeä

Toteutusprosessin aikana Toimeksisaajan tulee avustaa tilaajaa Toteutusaikataulun puitteissa.

6.1.11. Mikäli Tilaajan henkilöstön valmistautuminen toteutukseen on huono ja Toimeksisaaja tarvitsee lisäapua ohjelmiston onnistuneeseen käyttöönottoon, on laadittava lisäpöytäkirja tiedotus- ja konsultointityön sopimushintojen sopimiseksi.

6.2 AS "MYYNTI"-tehtävien lisätukimenettely.

Ohjelmiston käyttöönoton jälkeen voidaan toteuttaa Asiakkaan lisämuokkauksia ja -toiveita asiakkaan kanssa sovittujen teknisten eritelmien mukaisesti.

TOR:ssa on ilmoitettava lisävaatimusten toteuttamiseen tarvittavan työn monimutkaisuus ja kustannukset.

6.2.2. Toimeksisaaja sitoutuu ylläpitämään puhelinpalvelua ohjelmistotukea varten.

Vuorovaikutuksen puolia Ennen kuin alamme pohtimaan teknisen eritelmän luomisprosessia, puhutaan nelikulmiosta, johon urakoitsija ja tilaaja joutuvat projektia aloittaessaan. Vaatimukset- asiakkaan tai prosessin haltijan kuvaama järjestelmän toivottu käyttäytyminen, joka on tarkoitus toteuttaa. Vaatimukset muodostuvat pääsääntöisesti työkokemuksen ja ohjelman oikean toiminnan ymmärtämisen perusteella.

Tämä on avaintietoa kehittäjälle (toimittajalle), mutta juuri vaatimusten keruuvaiheessa syntyy eniten törmäyksiä, virheitä, tarpeettomia pyyntöjä jne.

Resurssit- ihmiset, koneet, laitteet, kehitysympäristö, aika ja raha, jotka tulee käyttää vaatimusten toteuttamiseen. Resurssit vaativat selkeää suunnittelua ja arviointia teknisten eritelmien hyväksymisvaiheessa.

Tämä voi sisältää vaatimuksia erilaisille lajittelu-, chat-integraatio- ja puhelintoiminnoille.

Palvelutaso- Itse asiassa tämän tason vaatimukset tulisi sisällyttää ensimmäisinä uusiin korjauksiin. Nämä ovat tehtäviä, jotka liittyvät järjestelmän vastenopeuteen, korkeaan kuormitukseen ja turvallisuuteen.

Huomio

Ihannetapauksessa toimittajalla ei pitäisi olla tällaisia ​​muutoksia - yritysohjelmistot eivät saisi hidastaa, menettää tietoja, kutistaa lomakkeita ja jakaa saman tason käyttöoikeuksia. Mutta jos vaatimus ilmenee, eikä se liity asiakkaan henkilökohtaiseen vainoharhaisuuteen tai laitteistoongelmiin, siihen kannattaa kiinnittää enemmän huomiota.

Tekniikan taso- listan viimeinen, mutta tärkeydessään ja monimutkaisuudessaan muita edellä.

Nämä voivat olla alustaan, käyttöjärjestelmään tai laitteisiin liittyviä asiakkaan vaatimuksia. Esimerkiksi pyyntö rakentaa MacOS:lle.

Microsoft World tai Microsoft Excel.

Henkilökohtaisesti käytämme erityisiä ohjelmistotuotteita aloitussivun kehittämisessä.

Niiden avulla voit nopeasti ja helposti luoda projekteja monimutkaisillekin kohteille - esimerkiksi Balsamiqille. Kuitenkin, kuinka teemme koko prototyypin, on jo kuvattu artikkelissa.

Aiheesta: Verkkosivuston prototyyppi: luominen, työkalut ja ohjelmat.

Esiprojektisuunnittelu voidaan tehdä yhdessä kehittäjän kanssa tai siirtää kokonaan hänen harteilleen.
Tärkeintä, älä unohda, sitten molemmat osapuolet sopivat ja allekirjoittavat.

LIFE HACKS TOR:N LUONNOSTAMISEEN

Nämä kohdat pätevät yhtäläisesti sekä esitteen täyttämiseen että teknisten eritelmien laatimiseen.

Ja niissä paljastan sinulle pieniä temppuja, kuinka voit laatia verkkosivuston tekniset tiedot ja helpottaa yrittäjän jo ennestään vaikeaa elämää:

1.

Varmista, että asiakas ja esiintyjä ymmärtävät toisiaan oikein."

Tehtävä ei saa sisältää laadukkaita adjektiiveja: kaunis, luotettava, moderni. Niitä ei voi selkeästi ymmärtää. Jokaisella on omat käsityksensä kauneudesta ja nykyaikaisuudesta.

Katso. Jonkun mielestä tämä malli oli kaunis ja antoi sen käyttää verkkosivuillaan:

Sama tapahtuu epämääräisten formulaatioiden kanssa, jotka eivät sinänsä merkitse mitään:

• Asiakkaan tulee pitää sivustosta. Entä jos hän on huonolla tuulella?
• Sivuston tulee olla kätevä. Mitä se tarkoittaa? Kätevä mihin?
• Työpaikan on kestettävä raskaita kuormia. 10 tuhatta kävijää? Tai 10 miljoonaa?
• Laadukas asiantuntijasisältö. No ymmärrät idean.

Tarkista, onko tekstissä epäselvyyksiä. Jos on, kirjoita se uudelleen.

Oletko päättänyt tilata verkkosivuston (alias aloitussivun)? Kuten käytäntö osoittaa, se ei ole niin yksinkertaista. Sadat asiakkaat, nähtyään valmiin nettisivunsa, huomaavat, että se ei sovi heille: suunnittelu on väärä, ulkoasu surkea, tekstit väärät, lisätty joukko tarpeettomia toimintoja.

Tällaisten seurausten välttämiseksi tarvitset verkkosivuston kehittämisen tekniset tiedot.

TARVITSEN SITÄ?!

Ei ole väliä kuka ylläpitää sivustoa - sinä itse, sukulaisesi, freelancerit vaatimattomalla palkalla, erikoistunut yritys valtavalla summalla...

Sivustolla on oltava tekniset tiedot.

Voit esimerkiksi pyytää luomaan mukautetun raportin RegionSoft CRM:lle tai tilata integroinnin sivuston kanssa. Nämä ovat tehtäviä, joiden määräajat ovat täysin erilaiset, kun vaatimukset on kerätty, analysoitu ja sovittu työntekijöiden ja johdon kanssa, voit aloittaa teknisen spesifikaation.
Voit pyytää lomakkeen myyjältä tai luoda sen itse - joka tapauksessa on olemassa useita rautaisia ​​sääntöjä, joiden noudattaminen säästää sinua ja CRM-toimittajasi päänsärkyä.

Teknisen eritelmän anatomia

Jos puhumme teknisen eritelmän luomisprosessista, siinä on useita vaiheita. Niiden peräkkäinen kulku johtaa asiakkaan haluttuun parannukseen.
Täällä he ovat.

Tässä on tärkeää kuunnella myyjän mielipidettä, koska hän tietää tarkalleen, kuinka paljon aikaa käytetään tähän tai tuohon tehtävään. Uskokaa minua, kehittäjän ei ole kannattavaa tuhlata aikaa ja pidentää määräaikoja - hänen on hyödyllistä suorittaa mahdollisimman monta projektia ja tehdä se hyvin, jotta hän ei kärsi iskua maineelleen.

Mitä tulee realismiin, CRM:n päivityspyyntöjen välttäminen törmäyslaitteiden hallintajärjestelmän tasolle on yksinkertaista: vaatimuksiin kannattaa sisällyttää se, mitä todella tarvitaan tällä hetkellä ja lähitulevaisuudessa.

Esimerkiksi RegionSoft CRM on työpöytäohjelma, meillä ei ole selainasiakasta. On turhaa pyytää meitä luomaan web-sovellus yhdelle yritykselle, tämä on merkittävä kehitystyö, se on parhaillaan käynnissä, eikä se ole mahdollista kehitystyötä yhdelle yritykselle.

Tietojärjestelmän täydelliset ja lyhyet nimet

Järjestelmän koko nimi on Venäjän federaation syyttäjänviraston alaisen tutkintakomitean virallinen verkkosivusto.

Järjestelmän lyhyt nimi on "SKP Site", "System", "Site".

1.2. Järjestelmän asiakkaan nimi ja hänen tiedot

Nimi: Venäjän federaation syyttäjänviraston alainen tutkintakomitea

Sijainti:

Tiedot

Moskova, Tekhnicheskiy lane, rakennus 2

Todellinen osoite: A

Asiakkaan yhteyshenkilö:

Puhelin: (4, (4;

Sähköpostiosoite

1.3. Luettelo asiakirjoista, joiden perusteella järjestelmä luodaan

Valtion sopimus nro ________________ päivätty _______ _______________ 2010

1.4.

Suunnitellut päivämäärät järjestelmän luomiseen liittyvien töiden alkamiselle ja valmistumiselle

Päätetään sopimuksen mukaisesti.

2. Järjestelmävaatimukset

2.1.

maksupäivä

Maksun numero

Maksunumero maksujärjestelmässä

Maksun määrä

1. Valitse tiedonsiirtotiedoston rivit
2. Aloita tiedonsiirtotiedoston rivien selaaminen
3. Lue tiedonsiirtotiedoston rivi
4. Hanki sopimuskoodi tiedonsiirtotiedostoriviltä
5. Etsi vastaava elementti koodin mukaan "Vastapuolisopimukset" -hakemistosta, jos elementtiä ei löydy, näytä viesti "Sopimusta koodilla ei löytynyt..."
6. Jos elementti löytyy, lisää arvotaulukkoon rivi, jossa: "Sopimus" on löydetty elementti, "Päiväys" on "Data_plat", "Payment Number" on "Nomer_plat", "Summa" on "Summa_plat".
7. Kun olet vastaanottanut tiedonsiirtotiedoston viimeisen rivin, lopeta sykli
8. Luo jokaiselle arvotaulukon riville "Maksumääräys varojen vastaanottamisesta" -asiakirja.

Kun täytät esitettä tai laadit toimeksiantoa verkkosivuston suunnittelulle, älä jätä siihen aukkoja.

Sinun on ymmärrettävä, että "kehittäjän harkinnan mukaan" tarkoittaa "teen mitä haluan" tai "kaikki, mitä ei ole määritelty, tehdään esiintyjän harkinnan mukaan". Ja uskokaa minua, tämä ei ole vain porsaanreikä, vaan kehittäjälle koko ikkuna Eurooppaan.

Ja näin ei tietenkään aina tapahdu.

Jos kohtaat pätevän asiantuntijan, sinun ei tarvitse huolehtia tuloksesta.

Mutta tässä syntyy toinen ongelma: hän voi itse asiassa tehdä sen oikein, mutta sinä et pidä siitä puhtaasti subjektiivisesti. Ja kaikki tulee olemaan kuten monien kehittäjien tuntemassa vitsissä:

LYHYESTI PÄÄASIJOISTA

Et varmasti tule katumaan aikaa, joka kuluu verkkosivuston tai aloitussivun laatimiseen ja sopimiseen.

Loppujen lopuksi tämä on paras työkalusi prosessin aikana syntyvien erimielisyyksien seurantaan ja ratkaisemiseen.

Kun napsautat tiettyä piiriä, sen pitäisi siirtyä sivulle, jolla on tekstikuvaus tästä piiristä.

· Lohko "Puheenjohtajan blogi"- tulee olla luettelo kolmesta viimeisimmästä blogissa luodusta aiheesta aiheen otsikon ja julkaisupäivämäärän muodossa. Aiheen nimi on linkki, jota napsautettuna sinun pitäisi ohjata aihetta kuvaavalle blogisivulle. Tämän lohkon tulisi sisältää myös video, joka voidaan toistaa poistumatta pääsivulta. Videossa tulee olla "Kommentit"-linkki, joka edustaa annettuun videokuvaan annettujen kommenttien määrää. "Kommentit"-linkin pitäisi johtaa blogisivulle, jolla on kommentteja lähetetystä videosta.

Alatunnisteen tulee sisältää hakukenttä, tekijänoikeustiedot jne.

2.3.

Lyhyt on kyselylomake, jossa on kysymyksiä tulevan verkkosivustosi sisällöstä, suunnittelusta ja teknisistä ominaisuuksista.

Tietenkin molempien osapuolten allekirjoittama yksityiskohtainen ohje voi korvata toimeksiannon.

Loppujen lopuksi tämä on käytännössä sama asia, ainoa ero on, että ohje on sinun visiosi ja tekninen eritelmä on lopullinen asiakirja, joka perustuu esitteeseen ja kehittäjän kommentteihin.

Jos tietyt kohdat aiheuttavat vaikeuksia, älä epäröi kysyä kehittäjältä kysymyksiä, kuten "Mitä tämä tarkoittaa?", "Miten tämä vaikuttaa sivustoni toimintaan?", koska kaikki kehittäjät eivät ymmärrä samaa asiaa kuin sinä.

Tai muista mainita "Lisätietoja" -sarakkeessa kaikki toiveesi, jotka eivät sisältyneet kysymyksiin vastauksissa.

Jos tämä sarake puuttuu, lisää ne esitteen loppuun.

VK, Google, Facebook.

3.2.2 Lisää henkilökohtaisen tilisi tilausosioon kenttä tarjouskoodin lisäämistä varten.

3.2.3 Sen sivun sijaan, jonka käyttäjä saa salasanan palautuspyynnön jälkeen (kuten name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), tee sivu (kuten name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), joka näyttää sivuston sisällön, sisältää "Sähköposti rekisteröinnin yhteydessä" -kentän, ohjausrivin, uuden salasanan, salasanan vahvistuksen ja lähetä tiedot -painikkeen.

3.2.4 Kun lisäät tuotteita ostoskoriin, tulee näkyviin viesti, joka ilmoittaa, että tuote on lisätty ostoskoriin.

3.2.5 Lisää viestitulostus, joka ilmoittaa, että salasana ei vastaa suojausparametreja, kun rekisteröit uutta käyttäjää.

AutomatisoituMYYNTI järjestelmä.Tekninen tehtävä Arkeilla Voimassa “__” _______________ 2010 alkaen

"_" __________________ 2010

Vähitellen muutokset sisällytettiin julkaisuun, ja ne mahdollistivat myöhemmin uuden tuotteen luomisen tukku-, vähittäismyymälöille ja hypermarketeille - RegionSoft Retail.

Käyttäjä tai käyttäjäryhmätaso. Tällä tasolla toteutetaan tehtäviä olemassa olevan käyttöliittymän hiomiseksi. Käyttäjä voi esimerkiksi haluta ikkunan, jossa näkyy viimeisen tilauksen numero ja tila, kun hän vie hiiren osoittimen asiakkaan päälle, tai mukautetun raportin, jossa on erityinen tietojen ryhmittely.

Uudelleentyöstö tällä tasolla vie vähemmän aikaa, mutta niitä voi olla monia - esimerkiksi useita vaatimuksia markkinoinnin, logistiikan ja teknisen tuen osastoilta.

Toimivuustaso. Sitä on usein vaikea erottaa edellisestä, tässä toimii muodollinen kriteeri - parannus ei ole siinä, että jotain näytetään käyttöliittymässä, vaan järjestelmän logiikan viimeistely.

Jos siinä lukee puuroa, ehkä sinun pitäisi juosta eikä katsoa taaksepäin.

• Vakuuta esiintyjän epärehellisyyttä vastaan. Kun sivusto on valmis, se voidaan tarkastaa teknisten eritelmien mukaisesti. Onko epäjohdonmukaisuuksia? Kehittäjä on velvollinen korjaamaan ne. Jos teet yhteistyötä virallisesti ja olet tehnyt sopimuksen, voit jopa pakottaa sen oikeuteen.
• Yksinkertaista esiintyjien vaihtaminen. Jos asiakas ja kehittäjä riitelivät ja pakenivat, sivuston luominen voi viedä paljon aikaa. Kun yksityiskohtainen tekninen eritelmä on, se voidaan siirtää uudelle tiimille - he pääsevät työhön monta kertaa nopeammin.
• Ota selvää monimutkaisen tuotteen kehittämisen kustannuksista. Monimutkaisen verkkopalvelun kehittämisen tarkkaa ajoitusta ja kustannuksia on mahdotonta arvioida välittömästi. Ensin sinun on ymmärrettävä, miten palvelu toimii ja mitä toimintoja sillä on.

Siellä on pääkäyttäjän oikeudet, omat IP-osoitteesi, portit, suodatussäännöt ja reititystaulukot.

Google PageSpeed ​​​​Insights on ilmainen suosituspalvelu verkkosivustoille, jotka nopeuttavat sivun näyttöä käyttäjän selaimessa (https://developers.google.com/speed/pagespeed/insights/).

Hakukoneoptimointi (tai SEO) on joukko sisäisen ja ulkoisen optimoinnin toimenpiteitä, joilla pyritään parantamaan sivuston asemaa hakukonetuloksissa tiettyjen käyttäjien pyyntöjen perusteella.

Ulkoinen verkkosivuston optimointi on verkkosivustojen rekisteröinti hakukoneissa, edistäminen sosiaalisissa verkostoissa, linkkien rakentaminen houkuttelemalla linkkejä muista resursseista mainostettavalle verkkosivustolle, bannerimainonta, kontekstuaalinen mainonta.

Sisäinen sivuston optimointi on tekstin, URL-osoitteiden optimointia, sivuston rakenteen muokkaamista, linkittämistä, palvelimen vastausten tarkistamista.

Käytettävissä olevat materiaalit Linkkejä suosikkisivustoillesi sekä esitteitä, aikakauslehtiä, valokuvia - mitä tahansa, tai ehkä sinulla on valmis tuotemerkkikirja. Liitteenä erillisenä arkistona. Vähimmäisresoluutio ja näyttölaitteet Ilmoita tässä kappaleessa, millä laitteilla aiot tarkastella sivustoa - PC:t, kannettavat tietokoneet, älypuhelimet... PC-näytöt 19-27 tuumaa; Kannettavat tietokoneet 15,6 - 17,3 tuumaa; Älypuhelimet 3,5 - 6 tuumaa; Tabletit 7-12 tuumaa Tarvitsetko mobiiliversion? Kyllä TOIMINNALLISET VAATIMUKSET Likimääräinen moduulisarja (käyttäjille) Tässä osiossa sinun on lueteltava kaikki toiminnot, jotka haluat nähdä sivustolla.

Tämä voi olla ostoskori, eri parametreihin perustuvat katalogisuodattimet, mahdollisuus tehdä online-tilaus, pyytää takaisinsoittoa, tilata uutiskirje ja mitä tahansa muita vaihtoehtoja hinnan, aakkosten, valmistajan mukaan.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EХHJя(gTT┬Pb╟▌╤└u╟╛#╜┘al+Ka Kqяk3└┘al+Ka Kqяk3┴ █ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:╜┘al+KaXG[ b:▓Vzhb╤└u╟╛Vzhb╜┘╤ ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛#╜└u╟╛#╜└u╟╛#╜┘al+┟╟╛┘┟╟╛┘ ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┥al+KaXG[ b:bVzhb╤└u╟╛#╜┘al+KaXG ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NлkZ┐⌡ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈Д7и$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еНФх═с╒°еНФх═с╒°еНФх═с┬Bl✠ьЕс┬├6 ∙rr mVC╪ ┬ 7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s) ©E4SCg┬╨ ▌▀s) OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Jos käyt ulkomaisten sivustojen läpi ”tuotevaatimusasiakirja”-pyynnöllä, voit löytää luovia ja vakuuttavia artikkeleita siitä, että tekniset tiedot (TOR, PRD) ovat kuolleet. Tästä meidän on osittain oltava samaa mieltä - kun tuotetta kehitetään tyhjästä, prototyyppien tekeminen näyttää paljon mielenkiintoisemmalta ja tehokkaammalta kuin asiakasmuistiinpanojen volyymit, jotka ovat joskus erittäin epäammattimaisia. Jos kuitenkin puhumme perusjärjestelmän viimeistelystä, asiat saavat täysin toisen käänteen. Edessämme on sekä modifikaatioita että räätälöityjä kehitystöitä, joten tekninen erittely on koiran syöntiä, jos kokki ei valehtele. Yleensä tänään puhumme niistä klassisista teknisistä tehtävistä, jotka on kirjoitettu parantamaan ostettuja ja asennettuja ohjelmistoja. Lyhyesti sanottuna tuskallisista asioista.

Vuorovaikutuksen puolia

Ennen kuin alamme pohtimaan teknisen eritelmän luomisprosessia, puhutaan nelikulmiosta, johon urakoitsija ja tilaaja joutuvat projektia aloittaessaan.

Vaatimukset- asiakkaan tai prosessin haltijan kuvaama järjestelmän toivottu käyttäytyminen, joka on tarkoitus toteuttaa. Vaatimukset muodostuvat pääsääntöisesti työkokemuksen ja ohjelman oikean toiminnan ymmärtämisen perusteella. Tämä on avaintietoa kehittäjälle (toimittajalle), mutta juuri vaatimusten keruuvaiheessa syntyy eniten törmäyksiä, virheitä, tarpeettomia pyyntöjä jne.

Resurssit- ihmiset, koneet, laitteet, kehitysympäristö, aika ja raha, jotka tulee käyttää vaatimusten toteuttamiseen. Resurssit vaativat selkeää suunnittelua ja arviointia teknisten eritelmien hyväksymisvaiheessa. Asiakkaan asianmukainen priorisointi ja toimittajan työvoimaresurssien jakaminen mahdollistavat määräaikojen myöhästymisen välttämisen ja muiden riskien minimoimisen.

Mahdollisuudet- Lyhyesti sanottuna tämä on mitä myyjä (esittäjä) voi itse asiassa tehdä. Katsotaanpa esimerkkiä RegionSoft CRM:stämme. Asiakas ostaa järjestelmän ja laatii teknisen spesifikaation muokkausta varten: on luotava integraatio verkkosivuston kanssa ja linkitettävä CRM:n tapahtumat verkkokaupan tilausnumeroon. Tämä on realistinen vaatimus, meillä on resurssit ja kyky tehdä se. Sinun on myös kehitettävä ja liitettävä CMS:ään CMS, verkkosivuston sisällönhallintajärjestelmä. Teoriassa voimme tehdä tämän, mutta meillä ei ole mahdollisuutta tehdä sitä halvalla, eikä asiakkaalla ole mahdollisuutta maksaa meille tarpeeksi, jotta voimme kohdentaa tehtävään henkilö- ja aikaresursseja. Tämän seurauksena asiakas kieltäytyy tästä vaatimuksesta - eikä hän oikeastaan ​​tarvitse CMS:ää, kaikki on kunnossa. Mutta TK:n "ahneudesta" myöhemmin.

Rajoitukset- joukko esteitä, jotka tekevät teknisten eritelmien mukaisten tehtävien suorittamisen vaikeaksi tai mahdottomaksi: budjetti, teknologiapino, lisenssiongelmat, lainsäädännölliset kiellot, laitteistokokoonpanot jne.

Siten kaikki neljä olemusta kietoutuvat tiiviisti yhteen ja määräävät projektin onnistumisen kokonaisuutena. Tarkastellaan jokaista elementtiä ja yritetään korostaa kriittisiä kohtia, jotka on pidettävä mielessä teknisiä eritelmiä käsiteltäessä.

Vaatimusten kerääminen ja analysointi

Tämä on erittäin tärkeä yrityksen sisäinen prosessi, jonka aikana käy selväksi mitä potentiaaliset käyttäjät haluavat ohjelmalta (tässä otamme CRM:n, mutta menetelmät toimivat myös muiden ohjelmistojen kanssa). Jos otat yhteyttä suureen toimittajaan, kuten SAP:iin tai järjestelmäintegraattoriin, sinulle tarjotaan suurella todennäköisyydellä yrityskonsultin palveluita (alias henkilökohtaista johtajaa, alias asiakaspäällikköä, eli "nyt sinun edustajasi yhtiö"). Itse asiassa useimmissa tapauksissa tämä on tavallinen hyvin koulutettu myyjä, jolla on kaksi tehtävää: nostaa projektin kustannuksia eikä päästää sinua irti.

Hän on ollut täällä tunnin, eikä ole edes koskenut tauluun. Hän ei ole todellinen järjestelmäanalyytikko

Kukaan ei tunne yritystäsi paremmin kuin sinä ja työntekijäsi. Tämä tarkoittaa, että vaatimusten kerääminen ja analysointi on yksinomaan sinun tehtäväsi, jossa myyjä voi auttaa ja ohjata, mutta ei missään tapauksessa häiritä prosessia. Kysy kehittäjältä tällaisista toteutuksista, selvitä mitä etsiä ja aloita. Muuten hyvä avustaja voi olla erityisaiheeseen hyvin perehtynyt työntekijä, jolla on karkea käsitys ohjelmistoarkkitehtuurista ja joka tuntee kehitysprosessin – hän voi toimia analyytikkona ja sisäisenä asiantuntijana, joka valvoo teknisten eritelmien luomisprosessi ja yhteydenpito toimittajan kanssa.

Vaatimusten keräämiseen on hyvin yksinkertainen järjestelmä.

1. Luo työryhmä johtajista ja kokeneista asiantuntijoista osastoilta, jotka käyttävät CRM:ää. Kerro meille ratkaisusta, jonka aiot valita, ja anna pääsy demoversioon.
2. Työryhmän jäsenten tulee välittää tietoa työntekijöille ja kysyä heiltä toiveita uudesta ohjelmasta täysin vapaassa muodossa. Jos joku työntekijöistä ei ole koskaan törmännyt sellaiseen ohjelmistoon eikä ole valmis puhumaan tulevasta käytöstä, sinun on pyydettävä häntä kuvaamaan säännöllisiä tehtäviä, tämä on universaali lähestymistapa.
3. Jokainen osasto määrittää sitten, mitä CRM:llä ei ole tai se ei noudata, ja kokoaa tiedot.
4. Työryhmä analysoi kerätyt vaatimukset, tarkastaa ja eliminoi risteyksiä. Usein esimerkiksi myyntiosasto ja markkinointiosasto tilaavat saman raportin, mutta vaatimuksilla voi olla eri kenttien ja entiteettien nimet, vaikka niiden taustalla olevat tiedot ovat samat. Näin ollen meidän on päästävä yhtenäiseen muotoon.
5. Työryhmä laatii listan vaatimuksista ja asettaa prioriteetit. Tässä vaiheessa voit ottaa toimittajan mukaan, koska hän on vastuussa resursseista. Voit esimerkiksi pyytää luomaan mukautetun raportin RegionSoft CRM:lle tai tilata integroinnin sivuston kanssa. Nämä ovat tehtäviä, joiden määräajat ovat täysin erilaiset.

Kun vaatimukset on kerätty, analysoitu ja sovittu työntekijöiden ja johdon kanssa, voit aloittaa teknisen eritelmän laatimisen. Voit pyytää lomakkeen myyjältä tai luoda sen itse - joka tapauksessa on olemassa useita rautaisia ​​sääntöjä, joiden noudattaminen säästää sinua ja CRM-toimittajasi päänsärkyä.

Teknisen eritelmän anatomia

Jos puhumme teknisen eritelmän luomisprosessista, siinä on useita vaiheita. Niiden peräkkäinen kulku johtaa asiakkaan haluttuun parannukseen. Täällä he ovat.

• Tunnistaminen - vaatimusten määrittely, ratkaistavien ongelmien löytäminen.
• Analyysi - vaatimusten analysointi, keskeisten tarpeiden tunnistaminen, yleistäminen.
• Sopeutuminen - vaatimusten arviointi CRM-ominaisuuksien ja olemassa olevien liiketoimintaprosessien yhteydessä.
• Dokumentaatio - muodollinen ja yksityiskohtainen vaatimusten kuvaus, teknisten eritelmien hyväksyminen.
• Viestintä toimittajan (kehittäjän) kanssa - iteratiivinen vuorovaikutus toimittajan kanssa koottujen teknisten eritelmien mukaisista parannuksista.
• Toteutus on toimittajan työtä tarvittavien toimintojen luomiseksi. On parempi, jos myyjä on jatkuvasti yhteydessä asiakkaaseen - näin lopputuote vastaa parhaiten asiakkaan visiota.
• Testaus - toimivuuden tarkistaminen toimittajan työntekijöiden, asiakkaan sisäisten asiantuntijoiden ja loppukäyttäjien toimesta, jotta voidaan varmistaa muutosten ja teknisten eritelmien noudattaminen sekä järjestelmän toimivuus muutosten kanssa.

Yleensä tekninen spesifikaatio voidaan luoda useiden tasojen vaatimusten perusteella, jotka voivat olla ristikkäisiä ja tehdä yhteistyötä projektin luomisessa tai olla vuorovaikutuksessa ollenkaan.

Liiketoiminnan taso- Maailmanlaajuisin taso, jolla monimutkaisia ​​ja ensisijaisia ​​tehtäviä ratkaistaan. Tämä taso sisältää liiketoimintaprosessien integroinnin, parannukset ja mallintamisen sekä uusien toiminnallisten moduulien kehittämisen. Tämä on pääsääntöisesti resurssivaltaista kehitystyötä, johon liittyy vakavia konsultaatioita ja tiivistä yhteistyötä asiakkaan kanssa. Esimerkiksi aikoinaan RegionSoft CRM:ssä tällaisia ​​mukautettuja muutoksia olivat varastokirjanpito, kassakone ja tuotanto. Vähitellen muutokset sisällytettiin julkaisuun, ja ne mahdollistivat myöhemmin uuden tuotteen luomisen tukku-, vähittäismyymälöille ja hypermarketeille - RegionSoft Retail.

Käyttäjä tai käyttäjäryhmätaso. Tällä tasolla toteutetaan tehtäviä olemassa olevan käyttöliittymän hiomiseksi. Käyttäjä voi esimerkiksi haluta ikkunan, jossa näkyy viimeisen tilauksen numero ja tila, kun hän vie hiiren osoittimen asiakkaan päälle, tai mukautetun raportin, jossa on erityinen tietojen ryhmittely. Uudelleentyöstö tällä tasolla vie vähemmän aikaa, mutta niitä voi olla monia - esimerkiksi useita vaatimuksia markkinoinnin, logistiikan ja teknisen tuen osastoilta.

Toimivuustaso. Sitä on usein vaikea erottaa edellisestä, tässä toimii muodollinen kriteeri - parannus ei ole siinä, että jotain näytetään käyttöliittymässä, vaan järjestelmän logiikan viimeistely. Tämä voi sisältää vaatimuksia erilaisille lajittelu-, chat-integraatio- ja puhelintoiminnoille.

Palvelutaso- Itse asiassa tämän tason vaatimukset tulisi sisällyttää ensimmäisinä uusiin korjauksiin. Nämä ovat tehtäviä, jotka liittyvät järjestelmän vastenopeuteen, korkeaan kuormitukseen ja turvallisuuteen. Ihannetapauksessa toimittajalla ei pitäisi olla tällaisia ​​muutoksia - yritysohjelmistot eivät saisi hidastaa, menettää tietoja, kutistaa lomakkeita ja jakaa saman tason käyttöoikeuksia. Mutta jos vaatimus ilmenee, eikä se liity asiakkaan henkilökohtaiseen vainoharhaisuuteen tai laitteistoongelmiin, siihen kannattaa kiinnittää enemmän huomiota.

Tekniikan taso- listan viimeinen, mutta tärkeydessään ja monimutkaisuudessaan muita edellä. Nämä voivat olla alustaan, käyttöjärjestelmään tai laitteisiin liittyviä asiakkaan vaatimuksia. Esimerkiksi pyyntö rakentaa MacOS:lle. On hienoa, jos tällaiset vaatimukset kehittyvät vähitellen julkaisuiksi, mutta niihin on ehdottomasti tehtävä korjauksia. Tämän tason asiakkaiden pyynnöstä rakensimme RegionSoft CRM:n MacOS:lle ja lisäsimme etäkäytön TRM-tekniikalla väliaikaisena ratkaisuna harvinaiseen, mutta olemassa olevaan mobiiliversion pyyntöön.

Teknisen eritelmän anatomia on yksinkertainen, ainakin luuston muodossa. Teknisen eritelmän pakolliset osat auttavat tilaajaa keskittymään ongelmaan ja muotoilemaan tehtävän oikein ja urakoitsijaa ymmärtämään, mitä häneltä haluaa. Muuten, ymmärryksestä. Tietenkin postauksen alussa valehtelimme hieman ja kielsimme yrityskonsultit luokkana. Asia on tässä: jokainen myyjä on työskennellyt markkinoilla useita vuosia (emme puhu yhden päivän CRM:istä) tai jopa vuosikymmeniä, mikä tarkoittaa, että heillä on useita tapauksia melkein kaikilla toimialoilla. Näin ollen insinöörit, ohjelmoijat ja myyjät tuntevat toteutuksen erityispiirteet kussakin yritystyypissä. Mutta jälleen kerran, on tärkeää keskittyä erityisesti yritykseesi.

Kenelle? Tässä osiossa tulee kuvata, kuka on parannuksen loppukäyttäjä, mitä tehtäviä on tarkoitus ratkaista ja millä tiheydellä.

Annan sinulle esimerkin. Yksi yritys otti käyttöön CRM:n, ja sen piti työskennellä melko suurella datajoukolla (useita kymmeniä miljoonia tietueita kuukaudessa, useita satoja tuhansia tietueita päivässä). Myyntiosaston päällikkö pyysi selvitystä näiden tietueiden lataamisesta "päivittäin". Luonnollisesti tällainen raportti, jossa satoja käyttäjiä työskenteli samanaikaisesti, kuormitti järjestelmän - ratkaisuja löydettiin prosessin optimoimiseksi. Jo työn aikana kävi ilmi, että myyjä oli pelannut varman ja tarvitsi raportin vasta kuun lopussa, ja sitten sitä voitiin ajaa aikataulun mukaan yöllä. Sanomattakin on selvää, että aikaa ja rahaa meni hukkaan.

Minkä vuoksi? Parantamisen tarpeen perustelu ja paikka liiketoimintaprosessissa. Tämä kohta on tarpeellisempi asiakkaalle itselleen, mutta on myös hyödyllistä, että myyjä tietää, mihin muihin prosesseihin se vaikuttaa. Joskus tämä auttaa löytämään vaihtoehtoisen ratkaisun.

Mitä sen pitäisi tehdä? Informatiivisin lohko - se kuvaa järjestelmän vaatimuksia ja odotuksia. Ja täällä tapahtuu juuri niitä helmiä, ihmeitä ja törmäyksiä, jotka sopivat lähetettäväksi bashorgiin ja jotka tekevät elämästä erittäin vaikeaa. On vain yksi syy - käyttäjä ei tiedä, mitä hän haluaa, mitä on tehtävä. On toinen pieni osasyy - käyttäjä ei voi muotoilla vaatimuksia. Ja tässä kehittäjän (työryhmän, analyytikon, jos sellainen on) tehtävänä on auttaa muotoilemaan tarve oikein, valitsemaan sopiva vaatimus ja sovittamaan tehtävä järjestelmän toiminnan kontekstiin. Samassa lohkossa sinun on mainittava odotettu tulos.

Erittelyparametrit- määräajat, toteutusvaiheet, kaikkien osapuolten vastuu, tarvittavat kontaktit jne. Itse asiassa tämä on joukko tärkeitä muodollisia asioita, jotka tekevät asiakirjasta teknisen eritelmän. Toimeksianto tulee sopia ja allekirjoittaa osapuolten kesken, jotta vältytään lukuisilta muutoksilta kehityksen aikana (niitä tapahtuu edelleen, mutta vähäisemmässä määrin).

Ihannetapauksessa tekninen eritelmä laaditaan toimittajan aktiivisella osallistumisella, ja sen tulos on suunnilleen seuraava rakenne:

1. Kuvaus kunkin mekanismin ja kunkin toiminnon vaatimuksesta
2. Kuvaus tämän toiminnon toteutuksesta
3. Työkustannukset jokaiselle vaiheelle erikseen
4. Tämän teknisen eritelmän työn kokonaiskustannukset
5. Työn suorittamisen aikakehykset vaiheittain jaoteltuina ja tärkeysjärjestyksessä
6. Asennusolosuhteiden kuvaus ja muutosten testaus
7. Varaukset, jotka koskevat toimeksiantojen ja muiden ehtojen kattavuutta

10 kehittäjän kyynelillä kirjoitettua sääntöä

Revisioinnin toimeksiantojen tulee olla tarkistuksen tekniset eritelmät, eikä asiakkaan tarvitsemaa 300-sivuista CRM-kuvausta. Ennen vaatimusten laatimista sinun tulee tutustua huolellisesti järjestelmän käyttöliittymään, sen ominaisuuksiin ja dokumentaatioon - todennäköisesti suurin osa "haluuksista" sisältyy jo peruspakettiin. Toinen askel, jonka suosittelen, on kiinnittää huomiota sisäänrakennetuihin muokkaustyökaluihin (raporttisuunnittelijat, konfiguraattorit jne.) - ehkä kokopäiväinen ohjelmoija voi tehdä tarvittavat muutokset (monilla yrityksillä on niitä).

Tekniset tiedot eivät saa olla ahneita. Usein yritys yliarvioi kykynsä tai haluaa saada "kaiken kerralla". Tämä lähestymistapa ei ole perusteltu taloudellisesti tai liiketoiminnallisesti. Myyjä ei ole pääsääntöisesti ollut olemassa pariin viikkoon (RegionSoftin tapauksessa - 15 vuotta), ja voit ottaa häneen yhteyttä jonkin ajan kuluttua, kun todella ymmärrät, mitä CRM:stä puuttuu.

Silmiinpistävä esimerkki redundanssista kirjaimellisesti eiliseltä: asiakas osti ERP:n tunnetulta venäläiseltä yritykseltä luullen, että koska kirjanpito toimii, niin tämän myyjän ERP on hyvä. ERP osoittautui paitsi ei kovin hyväksi sinänsä, myös erittäin sopimattomaksi yritykselle. Mutta RegionSoft CRM sopii varastokirjanpitoon ja tuotantoon. Ratkaisu on olemassa: unohda ERP, itke, integroi 1C-kirjanpito uuteen CRM:ään ja nauti kätevästä toteutuksesta. Mutta se on sääli tuhlattua rahaa! Ja asiakas vaatii CRM:n integroinnin ERP:hen. Emme tehneet niin, mutta miksi tällainen haaskaus, miksi kaksi suhteellisen samanlaista järjestelmää?

Toimeksiantojen on oltava realistisia ja saavutettavissa olevia- sekä vaatimusten että määräaikojen osalta. Tässä on tärkeää kuunnella myyjän mielipidettä, koska hän tietää tarkalleen, kuinka paljon aikaa käytetään tähän tai tuohon tehtävään. Uskokaa minua, kehittäjän ei ole kannattavaa tuhlata aikaa ja pidentää määräaikoja - hänen on hyödyllistä suorittaa mahdollisimman monta projektia ja tehdä se hyvin, jotta hän ei kärsi iskua maineelleen. Mitä tulee realismiin, CRM:n päivityspyyntöjen välttäminen törmäyslaitteiden hallintajärjestelmän tasolle on yksinkertaista: vaatimuksiin kannattaa sisällyttää se, mitä todella tarvitaan tällä hetkellä ja lähitulevaisuudessa.

Esimerkiksi RegionSoft CRM on työpöytäohjelma, meillä ei ole selainasiakasta. On turhaa pyytää meitä luomaan web-sovellus yhdelle yritykselle, tämä on merkittävä kehitystyö, se on parhaillaan käynnissä, eikä se ole mahdollista kehitystyötä yhdelle yritykselle. Ei, tietenkään kaikella on hintansa, mutta jälleen kerran - yleisessä tapauksessa vaatimusta on mahdotonta täyttää.

Tätä ei pidä sekoittaa tilanteeseen, jossa puhutaan mukautetusta kehityksestä ja sovelluksen idea ja logiikka muuttuvat radikaalisti, itse asiassa uuden ohjelmiston luominen "itsellesi" on sponsoroitu. Mutta se onkin toinen tarina.

Toimeksiannon tulee olla yksityiskohtainen. On tarpeen ilmoittaa kaikki tulevan projektin merkittävät yksityiskohdat: ohjelman käyttötiheydestä käyttöliittymän toiveisiin. Mitä yksityiskohtaisemmat vaatimukset ovat, sitä helpompaa ja nopeampaa käyttöönotto ja testaus ovat. Erityisesti yksityiskohtiin kannattaa kiinnittää huomiota, jos työskentelet tietyllä toimialalla (lääketiede, vakuutus, pankit) - yksityiskohtainen esitys liiketoiminnan ja ohjelman välisen vuorovaikutuksen vivahteista varmistaa, että myyjä ymmärtää tehtävän ja mukauttaa järjestelmän nopeasti yhtiösi.

Muista kiinnittää huomiota numeromuotoihin, kenttien nimiin, avattavien luetteloiden olemassaoloon tai puuttumiseen, painikkeiden ja vihjeiden toimintaan sekä tietotyyppeihin. Jos asiakas käyttää omia kaavoitaan, jotka tulee sisällyttää CRM:n toiminnan logiikkaan ( esimerkiksi jälleenmyyjän bonusten laskeminen), nämä kaavat on kirjoitettava niin, että niiden nimitykset ja laskentalogiikka on selitetty täydellisesti.

Kyllä, yritysohjelmistot näyttävät tältä, ja siinä on monia tärkeitä yksityiskohtia

Teknisen eritelmän tulee olla yksiselitteinen ja täsmällinen. Epämääräiset sanamuodot, toteutusvaihtoehdot, epäselvät vaatimukset - kaikki tämä on polku umpikujaan. Tapahtuu, että asiakas hyvistä aikomuksista kirjoittaa teknisiin eritelmiin useita vaihtoehtoja järjestelmän käyttäytymiselle, lähellä, mutta ei vastaavia. Tässä tapauksessa hän on varma, että hän auttaa, kehottaa ohjelmoijaa, mutta itse asiassa tie helvettiin on kivetty hyvillä aikomuksilla, kehittäjän on ymmärrettävä, mitä tarkalleen tarvitaan, ja hän valitsee, miten se tehdään itse, perustuen järjestelmän ominaisuuksista ja käytettyjen teknologioiden pinosta.

Tänä vuonna voit toistaa yhden toiveen. Älä vain käytä sitä sellaiseen, jota minäkään en voi täyttää, kuten selkeisiin liiketoimintavaatimuksiin!

Tekniset tiedot on kirjoitettava ihmiskielellä. Ja tämä on tärkeää, ei, TÄRKEÄÄ. Nostan esiin kaksi tilannetta, joissa kieliongelmat viivästävät hankkeen toteuttamista.

1. Asiakas yrittää osoittaa teknistä lukutaitoaan ja tekee rakenteita, kuten: "toteuta ikkuna, jossa on vihje kalenterin runkoon ja joka pystyy reagoimaan tapahtumien kutsumiseen..." sen sijaan, että "kalenteriin tulisi ponnahtaa ikkuna. jossa voit merkitä tehtävän suoritetuksi." Jos sinulla tai sisäisellä asiantuntijallasi ei ole taitoja kirjoittaa teknisiä tekstejä, älä googleta - kirjoita tavallisilla sanoilla, me ymmärrämme ne.

   Tehtävä ei saa olla valituskirja. Sinun on ratkaistava ongelma, ei kuvattava sitä, kiinnitettävä huomiota kirjasimiin ja unohtamatta vaatimusten kuvailu. Teknisen eritelmän tulee sisältää paitsi itse ongelma, myös sen ratkaisu ymmärtämisen tasolla - silloin kehittäjä ratkaisee sen kooditasolla. Vertailla "Myyntiosasto ei suunnittele hyvin, he menettävät numeroita, olemme kamppailleet nyt vuoden" Ja "on tarpeen luoda raportti, joka tallentaa suunnitellun ja toteutuneen myynnin arvot kuukausittain tuoteryhmittäin eriteltynä".

   Teknisen eritelmän on pystyttävä katsomaan tulevaisuuteen. No, ei aivan sitä, vaan ihmiset sen takana. Jos tiedetään, että liiketoimintaprosesseihin tulee pian muutoksia, tämä on otettava huomioon, jotta muutoksista ei tarvitse maksaa kahdesti.

   Tehtäväehdot eivät saa olla byrokraattisia. Jos olet joskus laatinut tämän asiakirjan, olet luultavasti tuntenut, kuinka vaikeaa on välttää kiusaus liukua byrokratiaan, lisätä johdantosanoja, tiukkoja lauseita ja kuvailla jokaista kohtaa rikoslain pykäläksi (mieluiten rangaistus jokaiselle rikkomisesta). ). Byrokraattiset muotoilut peittävät epätäydellisen ymmärryksen teknisten eritelmien luomisen tarkoituksesta. Myyjän vastuu on määritelty sopimuksessa ja sinne on kirjoitettu myös budjetti. Näitä kohtia ei pidä siirtää teknisiin eritelmiin.

   Toimeksiannon tulee olla teknisiä tietoja. Kuulostaa paradoksaalista, mutta usein luemme teknisten eritelmien sijasta kirjeitä, valituksia, sopimuksia, äskettäin kirjoitettuja CRM-ohjeita tai kokouspöytäkirjoja. Tietenkin on mahdotonta työskennellä tällaisen asiakirjan mukaan. Pysyäksesi muodon ja sisällön ajan tasalla, käytä vanhan koulun temppua: katso termiä sana sanalta. Tekninen tarkoittaa, että se sanelee muokkauksen, tekniikan ja pyrkii ratkaisemaan ongelman ohjelmistoa vaihtamalla. Tästä meidän on puhuttava ohjelmistojen yhteydessä. Tehtävä tarkoittaa kysymyksen, ongelman esittämistä ilman neuvoja, vinkkejä tai alustavia arvioita. Vain ilmaus ongelmasta.

   Käskyt ovat ohi, nyt nuhteet

   Listattujen sääntöjen lisäksi on vielä muutama asia, joista kannattaa puhua. Puhumme tavoitteista, suunnitelmista ja odotuksista – kaikista niistä elementeistä, jotka tekevät projektista onnistuneen, ja toimittajan ja asiakkaan välisestä suhteesta lähes ystävällisen.

   Tekniset tiedot on kirjoitettava nopeasti, vaikka edessäsi olisi matkapuhelinoperaattorin tai suuren hypermarketin prosessien automatisointi. Tämä johtuu siitä, että teknologiat kehittyvät valtavalla nopeudella ja jopa järjestelmä, jota olet toteuttamassa, voi selviytyä suuresta julkaisusta (tai joskus kahdesta) kuudessa kuukaudessa tai vuodessa ja saada uusia toimintoja. Sinun on ehkä harkittava muutosten tarvetta ja aloitettava prosessi alusta.

   

   
   Lopulta hän löysi aikaa teknisen toimeksiannon suorittamiseen. Mutta valitettavasti ei ole enää kehittäjiä toteuttamaan sitä.

   Asiakas ei ole tietoinen pinosta ja teknisistä rajoituksista. Ja hänen ei pitäisi tietää - tämä on myyjän tehtävä, hän arvioi työn teknisten eritelmien laatimisen jälkeen. Asiakkaan ei pidä syventyä tekniikkaan ja kysyä jokaisen pilkun kohdalla, voiko myyjä tehdä tämän tai sen. Laadi kattava tekninen spesifikaatio ja kehittäjä valitsee sopivan arkkitehtuurin - usein jopa paremman kuin uskotkaan.

   Arvioi budjettisi ja vältä ikäviltä yllätyksiltä- melkein yhteinen tehtävä numero yksi. Sinun ei pitäisi painostaa myyjää ja vaatia häneltä likimääräistä arviota työstä (no, ainakin suunnilleen, suoraan, silmin, mutta kuten muissakin, no, tämän tyyppisissä projekteissa, mutta kokemuksen perusteella, no, virhemarginaali). Täydellinen budjettiarvio on mahdollista vasta toimeksiannon lukemisen, analysoinnin ja lopullisen hyväksynnän jälkeen. Jos kehittäjäsi toimii toisin, varaudu siihen, että uudelleentyöstö maksaa vähintään kaksi kertaa niin paljon.

   Perustuu objektiiviseen muutos- ja laajennustarpeeseen- Kirjoitin yllä, että kehittäjä ei katoa ja on valmis tekemään muutoksia ja lisäyksiä tarpeidesi mukaan milloin tahansa. Älä siis yritä luoda unelmiesi CRM/ERP:tä heti, älä vaadi myyjältä "Kaikki toimii, kun juon kahvia" -painiketta - työskentele järjestelmässä, tunnista kriittiset kommentit sinulle ja aloita vaatimusten kerääminen ja piirtäminen. tekniset tiedot.

   Voit kirjoittaa loputtomasti teknisistä tehtävistä, tämä ei ole vain meemien ja tarinoiden, vaan myös päänsärkyjen generaattori. Voit puhua prioriteeteista ja suunnittelusäännöistä, GOST 1989:stä, joka tekee teknisistä eritelmistä epäinhimillisiä, IEEE-standardeista, jotka ovat hieman parempia, prototyypeistä ja niitä täydentävistä teknisistä eritelmistä. Mutta lopuksi haluaisin rajoittua yhteen, tärkeimpään sääntöön: tekninen eritelmä ei ole oikeussääntö, ei GOST eikä dogma, joten jos voit parantaa sitä, paranna sitä, jos voit yksinkertaistaa se, yksinkertaista se, jos voit tehdä sen kauniisti ja niin, että kaikki pitävät siitä, tee se. Olen varma, että tämän jälkeen kukaan ei tönäisi nenäänsä teknisiin eritelmiin ja väitä, ettei sitä ole siellä kirjoitettu. Tai tuskin kukaan.

   Koko joulukuun annamme alennuksia RegionSoft CRM:stä ja kaikista omista ohjelmistoistamme. 1.12.-15.12. - 15% ja jyrkät ehdot osamaksulle ja vuokralle. Meillä ei ole -70% ja -90%, koska pidämme lisenssien hinnat taloudellisesti perusteltuina, emmekä ota sitä tyhjästä.

   No, jos tarvitset CRM-järjestelmän (muokkauksella tai ilman), siirry kohtaan meidän nettisivumme, on paljon CRM:stä, sen eduista ja muista yritysohjelmistoista.

   Ja kyllä, etsimme jatkuvasti kumppaneita, jotka ovat valmiita myymään CRM:ää ja muita tuotteita, muokkaamaan ja myymään CRM:ää, myymään ohjelmistoja ja kouluttamaan käyttäjiä. Tulojen jako on oikeudenmukaista ja hyödyllistä kumppanille. Näytämme, kerromme, opetamme. Kirjoittaa [sähköposti suojattu]

   Liukumäkiä, liukumäkiä. Sarjakuvat osoitteesta http://www.modernanalyst.com/ ja Pinterest. Jos on parempi käännös, sisällytämme sen mielellämme julkaisuun.

Se, kuinka tarkasti 1C:n muutoksen tekniset tiedot on laadittu, määrittää suoraan, ratkaistaanko kehittäjille annetut tehtävät. Tällaisen asiakirjan kanssa työskentelyssä on kuitenkin joitain vaikeuksia. Laajassa mielessä TOR määrittelee standardit automatisoidun järjestelmän (AS) luomiselle ja modernisoinnille sekä työmenettelyn. Tämä sisältää myös joukon standardeja projektin käynnistämiselle. Tämän teknisten eritelmien roolin ymmärtämisen määräävät GOST 19.201-78 ja 34.602-89 vaatimukset, joiden mukaan 1C:n teknisiä eritelmiä kehitetään. Tämän asiakirjan merkityksestä on toinen tulkinta, joka on lähempänä käytäntöä.

Toisen määritelmän mukaan 1C:n tarkistamisen tehtävät ovat asiakirja, joka säätelee tulevan järjestelmän tarkoitusta ja parametreja sekä dokumentaation ja sen luettelon kehittämisprosessia. Tämä tulkinta mahdollistaa ohjelmoijien ja asiakkaan edun huomioimisen.

Mikä teknisen eritelmän pitäisi olla?

Urakoitsija luo kaikki tekniset toimeksiannot 1C-ohjelman kehittämiseksi. Mutta tätä ei tee ohjelmoija, vaan analyytikko. Tämä on tärkeä seikka, koska asiakirja on laadittava asiakkaan ymmärtämällä kielellä ilman erittäin erikoistuneita teknisiä termejä. Kun projektin kaikki vivahteet on otettu huomioon ja tiedot on muotoiltu oikein, tekniset eritelmät sovitaan kaikkien asiakkaiden kanssa. Jos se hyväksytään, ohjelmoijat ovat mukana työhön. Tässä tapauksessa asiakirjassa on selvästi esitettävä haluttu tulos. Tämä auttaa kehittäjiä asettamaan oikean tavoitteen ja tarkistamaan sen eri vaiheissa. Myös 1C:n muuttamisen teknisiä eritelmiä laadittaessa on kiinnitettävä paljon huomiota sanamuotoon. On huolehdittava siitä, että ne ovat riittävän tarkkoja eivätkä ehdota muita tulkintoja. Tämä on ensimmäinen asia, joka tulee muistaa työskennellessäsi teknisten eritelmien kanssa. Suunnitteluun on myös suhtauduttava vastuullisesti. Tämä koskee myös asiakirjan otsikkosivua.

Tärkeimmät virheet 1C:n kehittämisen teknisissä eritelmissä

Teknisten eritelmien rakennetta säätelee GOST 34.602-89. Tämä asiakirja sisältää selkeät vaatimukset teknisten eritelmien tietolohkojen lukumäärästä ja järjestyksestä. Samaan aikaan esitysmenetelmille ei ole tiukkoja standardeja. Tämä tilanne sisältää suuret mahdollisuudet monimutkaisten ongelmien ratkaisemiseen ja voi samalla johtaa moniin virheisiin asiakirjaa laadittaessa. Yleisimmät epätarkkuudet ovat:

1. Joidenkin osien toisto eri tulkinnoin.
2. Tiedot annetaan satunnaisesti. Ihannetapauksessa sen tulisi liittyä tiettyyn rakenteeseen, kuten liiketoimintaprosesseihin tai järjestelmämoduuleihin.
3. Eri osioissa olevat tiedot esitetään vaihtelevan yksityiskohtaisesti.

Kaikki tämä estää asiakasta ymmärtämästä teknisten eritelmien sisältämiä tietoja. Tämä vaikeuttaa yhteistyöprosessia ja tekee siitä työvoimavaltaisemman.

Kun asiakas on katsonut mallin 1C:n muunnoksen teknisen eritelmän, se voi muuttua, eikä aina parempaan suuntaan. Tämä puolestaan ​​yleensä estää ohjelmoijia ymmärtämästä tietoa oikein. Tämä koskee erityisesti asiantuntijoita, joilla on vähän kokemusta. Tässä vaiheessa tapahtuu usein seuraavia virheitä:

1. Eri osien vaatimukset ovat ristiriidassa keskenään.
2. Sanamuoto osoittautuu epätarkoksi.
3. Joissain paikoissa tiedot ovat liian yksityiskohtaisia.

Kaikista luetelluista virheistä on helppo päästä eroon. Ensinnäkin sinun on keskityttävä tulokseen, ei huolelliseen sanamuotoon. On syytä muistaa, että teknisessä eritelmässä kuvataan projektin toimivuus, sen tärkeimmät parametrit ja tarkoitus.

Kuinka välttää virheet teknisiä eritelmiä kehitettäessä?

Perussääntö, joka koskee kaikkia myöhempiä suosituksia, on, että sanamuodon on oltava täsmällinen. Tätä varten sinun on käytettävä viittauksia GOST:eihin ja muihin sääntelyasiakirjoihin. Näin urakoitsija ja tilaaja näkevät tiedon samalla tavalla.

Esimerkki 1C:n muuttamisen teknisestä spesifikaatiosta olettaa, että käytetään sen liiketoiminta-alueen kieltä, jota varten hanketta toteutetaan. Tämä on välttämätöntä ennen kaikkea asiakkaalle. Tekstissä ei kuitenkaan kannata käyttää vertailuja, koska niitä voidaan tulkita eri tavoin.

Perussäännöt laadittaessa teknisiä eritelmiä raportin ja muiden 1C-elementtien kehittämiseksi:

1. Teknisen eritelmän laativat urakoitsija ja tilaaja yhdessä.
2. Ohjelmoijien työlle tulisi asettaa vain objektiivisia vaatimuksia. Onnistunut projektikehitys edellyttää, että asiakkaan subjektiivinen näkemys on minimoitu.
3. On tarpeen kuvata yksityiskohtaisesti asiakkaan tarvitsema tulos. Tässä tapauksessa 1C-kokoonpanon kehittämisen teknisen eritelmän esimerkissä on tarpeen määrittää kaikki parametrit, joilla elementin tulee toimia. Muussa tapauksessa tulos voi poiketa suuresti halutusta.
4. Urakoitsijan ja tilaajan riskien tulee olla suunnilleen samat ja minimoitua.
5. Et voi käyttää termejä, joita käytetään yritysviestinnässä ja joita ei käytetä tietyllä toimialalla.

Teknisen spesifikaation luomiseksi raportin kehittämiseksi 1C:ssä tai muussa elementissä analyytikon on tunnettava kaikki asiakkaan toiminta-alan ominaisuudet. Vaatimusten tulee sisältää vain hyödyllistä tietoa, josta on hyötyä urakoitsijalle. Koska tässä keskitytään loppuongelmiin, jotka ohjelmiston on ratkaistava, teknisestä spesifikaatiosta ei ole yhtä esimerkkiä.

Teknisten eritelmien virheellisen laadinnan vaara

Yllä luetellut virheet voivat lisätä järjestelmän luomiseen käytettyä aikaa. Tämä aiheuttaa tarpeettomia kustannuksia ja tyytymättömyyttä. Kokeneiden asiantuntijoiden tulee laatia tietokannan tai muun 1C-kokoonpanon kehittämistä koskevat toimeksiantoehdot. Kaikkien osallistujien hyöty riippuu siitä, kuinka helppoa tämä asiakirja on ymmärtää. Asiakas saa tehokkaan automatisoidun järjestelmän liiketoiminnan ongelmien ratkaisemiseen. Samaan aikaan urakoitsijalla on toinen tyytyväinen asiakas. Yritysten omistajien on oltava mahdollisimman varovaisia ​​valitessaan 1C-kumppaniyrityksiä, koska organisaation tehokkuus riippuu pitkälti siitä, kuinka hyvin tarkistuksen tekniset tiedot on laadittu.