Tekniske spesifikasjoner for modernisering av ventilasjon i forskningsinstituttet. Tekniske spesifikasjoner for modernisering av ventilasjon i forskningsanlegget Tekniske spesifikasjoner for modifikasjon av lagringsserveren

Hvorfor er den tekniske spesifikasjonen nødvendig?

Eksempel på tekniske spesifikasjoner for en programmerer

Hvis du går gjennom utenlandske nettsteder med forespørselen "produktkravsdokument", kan du finne kreative og overbevisende artikler om det faktum at de tekniske spesifikasjonene (TOR, PRD) er døde. Vi må delvis være enig i dette - når man utvikler et produkt fra bunnen av, ser prototyping mye mer interessant og effektiv ut enn volumer av kundenotater, som noen ganger er veldig uprofesjonelle. Men hvis vi snakker om å ferdigstille grunnsystemet, så tar ting en helt annen vending. Vi står overfor både modifikasjoner og skreddersydd utvikling, så den tekniske spesifikasjonen er en hundespisende hund, hvis ikke kokken lyver for oss. Generelt snakker vi i dag om de klassiske tekniske oppgavene som er skrevet for å fullføre det kjøpte og installerte programvare. Kort sagt om vonde ting.

Fasett av interaksjon

Ressurser- mennesker, maskiner, utstyr, utviklingsmiljø, tid og penger som må brukes i prosessen med å implementere kravene. Ressurser krever klar planlegging og vurdering på stadiet for godkjenning av tekniske spesifikasjoner. Riktig prioritering fra kundens side og fordeling av arbeidsressurser fra leverandørens side gjør at man unngår tapte tidsfrister og minimerer annen risiko.

Muligheter- kort sagt, dette er hva leverandøren (utøveren) faktisk kan gjøre. La oss se på eksemplet med vår RegionSoft CRM. Klienten kjøper systemet og utarbeider en teknisk spesifikasjon for modifikasjon: det er nødvendig å lage integrasjon med nettstedet og koble hendelser i CRM til ordrenummeret til nettbutikken. Dette er et realistisk krav, vi har ressursen og evnen til å gjøre det. Du må også utvikle og knytte et CMS, et innholdsstyringssystem for nettsteder, til CRM. Teoretisk sett kan vi gjøre dette, men vi har ikke mulighet til å gjøre det billig, og oppdragsgiver har ikke mulighet til å betale oss nok til at vi kan avsette menneskelige og tidsmessige ressurser til oppgaven. Som et resultat avslår kunden dette kravet - og han trenger egentlig ikke et CMS, alt er i orden. Men om "grådigheten" til TK senere.

Begrensninger- et sett med hindringer som gjør det vanskelig eller umulig å utføre oppgaver fra de tekniske spesifikasjonene: budsjett, teknologistabel, lisensieringsproblemer, lovforbud, maskinvarekonfigurasjoner, etc.

Dermed er alle fire essensene tett sammenvevd og bestemmer suksessen til prosjektet som helhet. La oss se på hvert element og prøve å fremheve de kritiske punktene som må huskes når du arbeider med de tekniske spesifikasjonene.

Kravinnsamling og analyse

Ingen kjenner din bedrift bedre enn deg og dine ansatte. Dette betyr at innsamling og analyse av krav utelukkende er din oppgave, der leverandøren kan hjelpe og veilede, men ikke i noe tilfelle forstyrre prosessen. Spør utvikleren om slike implementeringer, finn ut hva du skal se etter og kom i gang. Forresten, en god assistent kan være din medarbeider som er godt kjent med det spesialiserte emnet og har en grov ide om programvarearkitekturen og er kjent med utviklingsprosessen - han kan fungere som en analytiker og intern ekspert, som fører tilsyn med prosessen med å lage tekniske spesifikasjoner og kommunisere med leverandøren.

Det er veldig enkel krets krav til innsamling.

1. Opprett en arbeidsgruppe med ledere og erfarne spesialister fra avdelinger som skal bruke CRM. Fortell oss om løsningen du har tenkt å velge, gi tilgang til demoversjonen.
2. Medlemmer av arbeidsgruppen bør formidle informasjon til ansatte og be om deres forslag til nytt program i en helt fri form. Hvis en av de ansatte aldri har møtt slik programvare og ikke er klar til å snakke om fremtidig bruk, må du be ham beskrive sine periodiske oppgaver; dette er en universell tilnærming.
3. Hver avdeling identifiserer deretter hva CRM ikke har eller ikke måler opp til og samler informasjonen.
4. Arbeidsgruppen analyserer de innsamlede kravene, kontrollerer og eliminerer kryss. For eksempel bestiller ofte salgsavdelingen og markedsavdelingen samme rapport, men kravene kan ha forskjellige navn på felt og enheter, selv om dataene bak dem er de samme. Følgelig må vi komme til en enhetlig form.
5. Arbeidsgruppen lager en kravliste og setter prioriteringer. På dette stadiet kan du involvere leverandøren, siden han er ansvarlig for ressursene. Du kan for eksempel be om å lage en tilpasset rapport for RegionSoft CRM, eller du kan bestille integrasjon med nettstedet. Dette er oppgaver med helt andre tidsfrister, her er prioritering veldig viktig.

Anatomi av en teknisk spesifikasjon

• Identifisere – definere krav, finne problemer som må løses.
• Analyse - analyse av krav, identifisering av sentrale behov, generalisering.
• Tilpasning - vurdere krav i sammenheng med CRM-evner og eksisterende forretningsprosesser.
• Dokumentasjon - formell og Detaljert beskrivelse krav, godkjenning av tekniske spesifikasjoner.
• Kommunikasjon med leverandøren (utvikleren) - iterativ interaksjon med leverandøren angående forbedringer i henhold til de kompilerte tekniske spesifikasjonene.
• Implementering er leverandørens arbeid for å skape nødvendig funksjonalitet. Det er bedre om leverandøren hele tiden er i kontakt med kunden - på denne måten vil sluttproduktet samsvare nærmest med kundens visjon.
• Testing - kontroll av funksjonaliteten av leverandørens ansatte, kundens interne eksperter og sluttbrukere for å etablere samsvar med modifikasjonen og tekniske spesifikasjoner, og driften av systemet med endringene.

Forretningsnivå- det mest globale nivået der komplekse og prioriterte oppgaver løses. Dette nivået inkluderer integrasjon, forbedringer og modellering av forretningsprosesser, utvikling av nye funksjonelle moduler. Som regel er dette en ressurskrevende utbygging, med seriøse konsultasjoner og tett jobber sammen med kunden. For eksempel, på en gang i RegionSoft CRM var slike tilpassede modifikasjoner lagerregnskap, kasseapparat og produksjon. Etter hvert ble endringene inkludert i utgivelsen, og gjorde det senere mulig å lage et nytt produkt for grossist, detaljhandel og hypermarked - RegionSoft Retail.

Bruker- eller brukergruppenivå. På dette nivået implementeres oppgaver for å avgrense det eksisterende grensesnittet. En bruker kan for eksempel ønske at et vindu med nummeret og statusen til den siste bestillingen skal vises når du holder musepekeren over en kunde, eller en egendefinert rapport med en spesiell gruppering av data. Forbedringer på dette nivået tar kortere tid, men det kan være mange av dem – for eksempel flere krav fra markedsføring, logistikk og teknisk støtte.

Funksjonalitetsnivå. Det er ofte vanskelig å skille det fra det forrige; et formelt kriterium fungerer her - forbedring er ikke på nivået med å vise noe i grensesnittet, men på nivået med å fullføre systemlogikken. Dette kan inkludere krav til ulike typer sortering, chat-integrasjon og telefoni.

Service nivå– faktisk burde kravene til dette nivået være de første som skal inkluderes i nybygg med rettelser. Dette er oppgaver knyttet til systemresponshastighet, drift under høy belastning og sikkerhet. I ideelt Leverandøren bør ikke ha slike modifikasjoner - bedriftsprogramvare skal ikke redusere hastigheten, miste data, skjule skjemaer og distribuere tilgangsrettigheter på samme nivå. Men hvis et krav dukker opp, og det ikke er relatert til kundens personlige paranoia eller problemer ved siden av maskinvare, det er verdt å være spesielt oppmerksom på det.

Teknologinivå- sist på listen, men foran resten i viktighet og kompleksitet. Dette kan være plattformrelaterte kundekrav, operativsystem eller enheter. For eksempel en forespørsel om å bygge for MacOS. Det vil være flott om slike krav gradvis utvikler seg til utgivelser, men det er viktig å ha rettelser for dem. Det var fra kundeforespørsler på dette nivået vi bygde RegionSoft CRM for MacOS og la til fjerntilgang bruker TRM-teknologi som en midlertidig løsning på en sjelden, men eksisterende forespørsel om en mobilversjon.

Anatomien til en teknisk spesifikasjon er enkel, i det minste i skjelettform. Obligatoriske deler av den tekniske spesifikasjonen hjelper kunden til å fokusere på problemet og formulere oppgaven riktig, og entreprenøren til å forstå hva de ønsker av ham. Forresten, om forståelse. Selvfølgelig, i begynnelsen av innlegget løy vi litt, og nektet bedriftskonsulenter som klasse. Poenget er dette: hver leverandør har jobbet på markedet i flere år (vi snakker ikke om endags-CRM), eller til og med tiår, noe som betyr at de har et sett med saker i nesten alle bransjer. Derfor er ingeniører, programmerere og selgere kjent med spesifikasjonene for implementering i hver type bedrift. Men igjen, det er viktig å fokusere spesifikt på virksomheten din.

For hvem? I denne delen skal du beskrive hvem som skal være sluttbruker av forbedringen, hvilke oppgaver som planlegges løst og med hvilken hyppighet.

La meg gi deg et eksempel. Ett selskap implementerte CRM og skulle jobbe med et ganske stort utvalg av data (flere titalls millioner poster per måned, flere hundre tusen poster per dag). Lederen for salgsavdelingen ba om en rapport om opplasting av disse postene med en "daglig" frekvens. Naturligvis lastet en slik rapport, med hundrevis av brukere som jobber samtidig, systemet - løsninger ble funnet for å optimalisere prosessen. Allerede under arbeidet viste det seg at selgeren hadde spilt det trygt og trengte rapporten først i slutten av måneden, og da kunne den kjøres i rute om natten. Unødvendig å si var tid og penger bortkastet.

For hva? Begrunnelse for behovet for forbedring og dets plass i forretningsprosessen. Dette punktet er mer nødvendig for kunden selv, men det er også nyttig for leverandøren å vite hvilke andre prosesser som vil bli påvirket. Noen ganger hjelper dette å finne en alternativ løsning.

Hva skal den gjøre? Den mest informative blokken - den beskriver kravene og forventningene fra systemet. Og her skjer akkurat de perlene, miraklene og kollisjonene som er helt riktige å sende til bashorg, og som, vel, gjør livet veldig vanskelig. Det er bare én grunn - brukeren vet ikke hva han vil, hva som må gjøres. Det er en annen liten undergrunn - brukeren kan ikke formulere krav. Og her er oppgaven til utvikleren (arbeidsgruppe, analytiker, hvis det er en) å hjelpe til med å formulere behovet riktig, velge et passende krav og tilpasse oppgaven inn i konteksten av systemets drift. I samme blokk må du nevne det forventede resultatet.

Spesifikasjonsparametere- tidsfrister, stadier av gjennomføring, ansvar fra alle parter, nødvendige kontakter m.m. Faktisk er dette et sett med viktige formelle ting som gjør dokumentet til en teknisk spesifikasjon. Referansevilkårene må avtales og undertegnes av partene for å unngå mange endringer under utviklingen (de vil fortsatt skje, men i mindre grad).

Ideelt sett er den tekniske spesifikasjonen utarbeidet med aktiv deltakelse fra leverandøren, og resultatet er omtrent følgende struktur:

1. Beskrivelse av kravet til hver mekanisme og hver funksjonalitet
2. Beskrivelse av implementeringen av denne funksjonaliteten
3. Arbeidskostnader for hvert trinn separat
4. Den totale kostnaden for arbeid for denne tekniske spesifikasjonen
5. Tidsrammer for å fullføre arbeid, delt ned etter stadier og angir prioritet
6. Beskrivelse av installasjonsforhold og testing av modifikasjoner
7. Forbehold angående den uttømmende karakteren av referansevilkårene og andre betingelser

10 regler skrevet i tårene til en utvikler

Den tekniske spesifikasjonen skal ikke være grådig. Ofte overvurderer en bedrift sine evner eller ønsker å få "alt på en gang." Denne tilnærmingen er ikke berettiget verken fra et økonomisk eller forretningsmessig synspunkt. En leverandør har som regel ikke eksistert på et par uker (i tilfellet RegionSoft - 15 år), og du kan kontakte ham etter en stund, når du virkelig forstår hva som mangler i CRM.

Et slående eksempel på redundans bokstavelig talt fra i går: en klient kjøpte en ERP fra en velkjent russisk selskap, og tenker at siden regnskap fungerer, vil ERP-en til denne leverandøren være bra. ERP viste seg ikke bare å være ikke veldig bra i seg selv, men også veldig uegnet for virksomheten. Men RegionSoft CRM med lagerregnskap og egnet for produksjon. Det er en løsning: glem ERP, gråt, integrer 1C-regnskap med den nye CRM og nyt den praktiske implementeringen. Men det er synd for bortkastede penger! Og klienten krever integrering av CRM med ERP. Vi gjorde ikke det, men hvorfor så bortkastet, hvorfor to relativt like systemer?

Mandatet skal være realistisk og oppnåelig– både når det gjelder krav og frister. Her er det viktig å lytte til leverandørens mening, siden han vet nøyaktig hvor mye tid som vil bli brukt på denne eller den oppgaven. Tro meg, det er ikke gunstig for en utvikler å kaste bort tid og øke tidsfrister - det er gunstig for ham å fullføre så mange prosjekter som mulig og gjøre det bra, for ikke å lide et slag for hans omdømme. Når det gjelder realisme, er det lett å unngå forespørsler om å oppgradere CRM til nivået til et kolliderstyringssystem: du bør inkludere i kravene det som virkelig trengs for dette øyeblikket og i overskuelig fremtid.

For eksempel er RegionSoft CRM et skrivebordsprogram; vi har ikke en nettleserklient. Å be oss om å lage en webapplikasjon for ett selskap er meningsløst, dette er en stor utvikling, den er i gang og er ikke en mulig utvikling for ett selskap. Nei, selvfølgelig har alt sin pris, men igjen - i det generelle tilfellet er kravet umulig å oppfylle.

Dette bør ikke forveksles med situasjonen når vi snakker om tilpasset utvikling og ideen og logikken til applikasjonen er radikalt endret; faktisk er opprettelsen av ny programvare "for deg selv" sponset. Men det er en annen historie.

Referansen må være detaljert. Det er nødvendig å indikere alle viktige detaljer om det fremtidige prosjektet: fra bruksfrekvensen av programmet til ønsker for grensesnittet. Jo mer detaljerte kravene er, jo enklere og raskere vil implementeringen og testingen være. Det er spesielt verdt å være oppmerksom på detaljer hvis du jobber i en spesifikk bransje (medisin, forsikring, banker) - en detaljert presentasjon av nyansene i samspillet mellom virksomheten og programmet vil sikre at leverandøren forstår oppgaven og raskt tilpasser systemet til din bedrift.

Pass på å ta hensyn til tallformater, feltnavn, tilstedeværelse eller fravær av rullegardinlister, oppførselen til knapper og hint, og datatyper. Hvis kunden bruker sine egne formler, som må inkluderes i logikken for CRM-drift ( for eksempel beregning av forhandlerbonuser), må disse formlene skrives med en fullstendig forklaring av deres betegnelser og beregningslogikk.

Den tekniske spesifikasjonen skal være entydig og presis. Vage formuleringer, implementeringsmuligheter, uklare krav – alt dette er en vei til en blindvei. Det hender at en klient, av gode intensjoner, skriver i den tekniske spesifikasjonen flere alternativer for oppførselen til systemet, nære, men ikke likeverdige. I dette tilfellet er han sikker på at han hjelper, ber programmereren, men faktisk er veien til helvete brolagt med gode intensjoner, utvikleren må forstå hva som er nødvendig, og han vil velge hvordan han gjør det selv, basert på på egenskapene til systemet og stabelen med teknologier som brukes.

Den tekniske spesifikasjonen skal være skrevet på menneskelig språk. Og dette er viktig, nei, VIKTIG. Jeg vil trekke frem to situasjoner når språkproblemer fører til forsinkelser i prosjektgjennomføringen.

1. Klienten prøver å demonstrere sin tekniske kompetanse og lager konstruksjoner som: "implementer et vindu med et hint i kroppen av kalenderen med evnen til å reagere på anropshendelser..." i stedet for "et vindu skal dukke opp i kalenderen der du kan merke oppgaven som fullført." Hvis du eller din interne ekspert ikke har kompetansen til å skrive tekniske tekster, ikke Google – skriv med vanlige ord, vi forstår dem.

   Referansen skal ikke være en klagebok. Du må løse problemet, ikke beskrive det, være oppmerksom på skriftene og glemme å beskrive kravene. Den tekniske spesifikasjonen må inneholde ikke bare selve problemet, men også løsningen på forståelsesnivået - så vil utvikleren løse det på kodenivå. Sammenligne "Salgsavdelingen planlegger ikke godt, den taper tall, vi har slitt i et år nå" Og "det er nødvendig å lage en rapport som lagrer verdiene for det planlagte og faktiske salget månedlig, fordelt på produktgrupper".

   Mandatet skal kunne se inn i fremtiden. Vel, ikke akkurat det, men menneskene bak det. Hvis det er kjent at endringer i forretningsprosesser snart vil skje, må dette tas i betraktning for ikke å betale for modifikasjoner to ganger.

   Mandatet skal ikke være byråkratisk. Hvis du noen gang har utarbeidet dette dokumentet, har du sannsynligvis følt hvor vanskelig det er å unngå fristelsen til å gli inn i byråkratiet, legge til innledende ord, strenge fraser og beskrive hvert punkt som en artikkel i straffeloven (helst med straff for alle for brudd). ). Byråkratiske formuleringer maskerer en ufullstendig forståelse av formålet med å lage tekniske spesifikasjoner. Leverandørens ansvar er spesifisert i kontrakten, og budsjettet er også skrevet der. Du bør ikke overføre disse punktene til de tekniske spesifikasjonene.

   Referansevilkårene skal være tekniske spesifikasjoner. Det høres paradoksalt ut, men ofte leser vi i stedet for tekniske spesifikasjoner brev, klager, kontrakter, nyskrevne instrukser for CRM eller møtereferat. Selvfølgelig er det umulig å jobbe i henhold til et slikt dokument. For å holde deg oppdatert på form og innhold, bruk et gammelt skoletriks: se på begrepet ord for ord. Teknisk betyr at det dikterer modifikasjon, teknologi og er rettet mot å løse et problem ved å endre programvaren. Dette er hva vi må snakke om i sammenheng med programvare. En oppgave betyr å stille et spørsmål, et problem, uten råd, tips eller foreløpige vurderinger. Bare en uttalelse om problemet.

   Budene er over, nå irettesettelsen

   I tillegg til de oppførte reglene er det noen flere ting som er verdt å snakke om. Vi snakker om mål, planer og forventninger - alle de elementene som gjør prosjektet vellykket, og forholdet mellom leverandør og klient nesten vennlig.

   Tekniske spesifikasjoner må skrives raskt, selv om du står overfor oppgaven med å automatisere prosesser mobiloperatør eller et stort hypermarked. Dette skyldes det faktum at teknologier utvikler seg med enorm hastighet, og til og med systemet du implementerer kan overleve en større utgivelse (eller noen ganger to) på seks måneder eller et år og få ny funksjonalitet. Du må kanskje revurdere behovet for modifikasjoner og starte prosessen på nytt.

   

   
   Endelig fant han tid til å fullføre den tekniske oppgaven. Men dessverre er det ingen utviklere igjen for å implementere det.

   Klienten er uvitende om stabelen og tekniske begrensninger. Og han burde ikke vite - dette er leverandørens oppgave, det er han som evaluerer arbeidet etter å ha utarbeidet de tekniske spesifikasjonene. Kunden skal ikke fordype seg i teknologi og spørre ved hvert komma om leverandøren kan gjøre denne eller den tingen. Lag en omfattende teknisk spesifikasjon og utvikleren vil velge en passende arkitektur – ofte enda bedre enn du kanskje tror.

   Vurder budsjettet ditt og unngå ubehagelige overraskelser– nesten felles oppgave nummer én. Du bør ikke presse leverandøren og kreve av ham en omtrentlig vurdering av arbeidet (vel, i det minste omtrentlig, umiddelbart, med øyet, men som med andre, vel, i prosjekter av denne typen, men av erfaring, vel, innenfor feilmargin). En fullstendig budsjettvurdering er kun mulig etter å ha lest, analysert og endelig godkjenning av mandatet. Hvis utvikleren din opptrer annerledes, gjør deg klar for at revisjonen vil koste minst dobbelt så mye.

   Ut fra det objektive behovet for endringer og utvidelser– Jeg skrev ovenfor at utvikleren ikke forsvinner og er klar til å gjøre endringer og tillegg i henhold til dine krav når som helst. Derfor, ikke prøv å lage drømmenes CRM/ERP med en gang, ikke krev fra leverandøren en "Alt fungerer mens jeg drikker kaffe"-knapp - jobb i systemet, identifiser kritiske kommentarer for deg og begynn å samle krav og tegne opp tekniske spesifikasjoner.

   Du kan skrive i det uendelige om tekniske oppgaver; dette er en ekte generator av ikke bare memer og historier, men også hodepine. Du kan snakke om prioriteringer og designregler, om GOST 1989, som gjør tekniske spesifikasjoner umenneskelige, om IEEE-standarder, som er litt bedre, om prototyper og tekniske spesifikasjoner som utfyller dem. Men til slutt vil jeg begrense meg til en, den viktigste regelen: en teknisk spesifikasjon er ikke en rettsregel, ikke GOST og ikke et dogme, derfor, hvis du kan forbedre det, forbedre det, hvis du kan forenkle det, forenkle det, hvis du kan gjøre det grasiøst og slik at alle liker det, gjør det. Jeg er sikker på at etter dette vil ingen stikke nesen på de tekniske spesifikasjonene og si at det ikke er skrevet der. Eller nesten ingen.

   I hele desember gir vi rabatter på RegionSoft CRM og all vår egen programvare. Fra 1. desember til 15. desember - 15 % og steile vilkår for avdrag og utleie. Vi har ikke -70 % og -90 %, fordi vi holder prisen for lisenser økonomisk forsvarlig, og tar den ikke ut av det blå.

   Vel, hvis du trenger et CRM-system (med eller uten modifikasjon), så gå til vår nettside, er det mye om CRM, dets fordeler og annen bedriftsprogramvare.

   Og ja, vi ser alltid etter partnere som er klare til å selge CRM og andre produkter, modifisere og selge CRM, selge programvare og lære opp brukere. Inntektsdelingen er rettferdig og fordelaktig for partneren. Vi skal vise deg, fortelle deg, lære deg. Skrive til [e-postbeskyttet]

   Lysbilder, lysbilder. Tegneserier hentet fra http://www.modernanalyst.com/ og Pinterest. Hvis det finnes en bedre oversettelse, tar vi den gjerne med i innlegget.

Jeg legger ofte ved sideprototyper slik at klienten forstår hvordan siden hans vil se ut. Deretter lager jeg en egen oppgave for layoutdesigneren - med tekniske detaljer og forklaringer som vil hjelpe i arbeidet hans.

Jo mer kompleks oppgaven er, desto mer detaljert bør den tekniske spesifikasjonen være. Da jeg deltok i store prosjekter, så jeg tekniske spesifikasjoner som var på 30 sider.

Guram Sipki, grunnlegger av digitalstudio Udix Media

Først og fremst trenger kunden tekniske spesifikasjoner – slik at han forstår hvordan nettsiden hans vil bli og hva pengene skal brukes på. Hvis noe blir gjort feil, kan han henvise til de tekniske spesifikasjonene og be om at det gjøres om.

Den tekniske spesifikasjonen utarbeides av prosjektleder etter å ha kommunisert med byggherren og diskutert oppgaven med prosjekterende.

Store kunder ber ofte om svært detaljerte tekniske spesifikasjoner, som beskriver hver knapp. Små bedrifter, tvert imot, liker ikke grundige 100-siders dokumenter.

Et eksempel på en teknisk oppgave for forbedring av nettstedet

Generell informasjon

Navn på det automatiserte systemet

"AS Sbyt"

Kunde

Utfører

Grunnlag for arbeidet

Planlagte datoer for start og slutt på arbeidet med å lage systemet

Arbeidsstart: 01.09.2010

Ferdigstilling av arbeid: 31.12.2010

Hensikt og mål med å lage systemet

Formålet med systemet

Under utvikling automatisert system designet for å automatisere bedriftens salgsprosesser.

Mål med å lage systemet

Mål med å lage et automatisert system

Målene for utviklingen av "AS Sbyt" er:

1. 3. Egenskaper ved automatiseringsobjektet

3.1 Enterprise forretningsprosesser

3.1. 1 Forretningsprosess "Å inngå en avtale"

Det vil bli ditt skjold; i dette dokumentet, hvis noe skjer, vil du kunne peke fingeren på en skruppelløs utvikler og kreve at nettstedet ditt blir brakt i samsvar med det.

Teknisk oppgave(kort sagt "TOR") er et dokument som reflekterer kravene til din fremtidige nettside så detaljert og entydig som mulig.

Nettsiden er laget nettopp på bakgrunn av tekniske spesifikasjoner. Jo mer detaljert og entydig den er, jo mer vil det nye nettstedet ditt oppfylle dine forventninger.

Referansevilkår for opprettelse av et nettsted - som en lov, bør ikke tillate tolkninger og avvik.

Utbygger gjør alt som ikke er spesifisert i de tekniske spesifikasjonene etter eget skjønn.

· Administratorveiledning;

· Innholdsbehandlerveiledning;

· Installasjonsveiledning;

· Programmeringsveiledning.

2.20. Organisering og gjennomføring av opplæring for spesialister fra etterforskningskomiteen under den russiske føderasjonens påtalemyndighet

Følgende opplæringskrav gjelder:

· Entreprenøren skal gjennomføre opplæring for ansatte i Granskingsutvalget ved påtalemyndigheten Den russiske føderasjonen som ikke består av mer enn 10 personer.

· Opplæringen skal gjennomføres på russisk.

· Opplæringslokaler stilles til rådighet av Kunden.

· Sted og tidspunkt for opplæring må avtales med Kunden.

Opplæring må gjennomføres på all funksjonalitet i systemet.

Som en del av opplæringen er det nødvendig å utføre informasjonsinnholdet til ett pilotnettsted for Ring of Sites til etterforskningskomiteen under påtalemyndigheten i Den russiske føderasjonen.

3.

Eksempel på tekniske spesifikasjoner for forbedring av nettstedet

Viktig

Under gjennomføringsprosessen skal Leverandøren yte bistand til Kunden innenfor rammen av Gjennomføringsplanen.

6.1.11. Ved dårlig forberedelse av Kundens personell for implementering og behov for ytterligere bistand fra Leverandøren for vellykket implementering av programvaren, skal det utarbeides en tilleggsprotokoll for avtale om kontraktsmessige priser for informasjons- og konsulentarbeid.

6.2 Prosedyren for videre støtte til AS "SALG"-oppgaver.

TOR må indikere kompleksiteten og kostnadene ved arbeidet for å implementere tilleggskrav.

6.2.2. Leverandøren forplikter seg til å opprettholde en telefontelefon for programvarestøtte.

Fasett av interaksjon Før vi begynner å dissekere prosessen med å lage en teknisk spesifikasjon, la oss snakke om firkanten som entreprenøren og kunden befinner seg i når prosjektet starter. Krav- ønsket oppførsel til systemet, beskrevet av kunden eller prosessholderen, som skal implementeres. Som regel stilles krav på grunnlag av arbeidserfaring og forståelse for riktig oppførsel av programmet.

Dette er nøkkelinformasjon for utvikleren (leverandøren), men det er på stadiet med innsamling av krav at det oppstår flest kollisjoner, feil, unødvendige forespørsler osv.

Ressurser- mennesker, maskiner, utstyr, utviklingsmiljø, tid og penger som må brukes i prosessen med å implementere kravene. Ressurser krever klar planlegging og vurdering på stadiet for godkjenning av tekniske spesifikasjoner.

Dette kan inkludere krav til ulike typer sortering, chat-integrasjon og telefoni.

Service nivå– faktisk burde kravene til dette nivået være de første som skal inkluderes i nybygg med rettelser. Dette er oppgaver knyttet til systemresponshastighet, drift under høy belastning og sikkerhet.

Merk følgende

Ideelt sett bør ikke leverandøren ha slike modifikasjoner - bedriftens programvare bør ikke redusere hastigheten, miste data, skjule skjemaer og distribuere tilgangsrettigheter på samme nivå. Men hvis et krav dukker opp, og det ikke er relatert til kundens personlige paranoia eller problemer på maskinvaresiden, er det verdt å være mer oppmerksom på det.

Teknologinivå- sist på listen, men foran resten i viktighet og kompleksitet.

Microsoft World eller Microsoft Excel.

Personlig bruker vi spesielle programvareprodukter når vi utvikler en landingsside.

Med deres hjelp kan du raskt og enkelt lage prosjekter for selv komplekse nettsteder - for eksempel Balsamiq. Hvordan vi lager hele prototypen er imidlertid allerede beskrevet i artikkelen.

Om emnet: Prototyping av nettsider: opprettelse, verktøy og programmer.

Pre-prosjekt design kan gjøres i fellesskap med utvikleren eller fullstendig overført til hans skuldre.
Hovedsaken er, ikke glem, så er det avtalt og signert av begge parter.

LIFE HACKS FOR DRAFTING TOR

Disse punktene gjelder både for utfylling av oppgaven og utarbeidelse av tekniske spesifikasjoner.

Og i dem vil jeg fortelle deg små triks for hvordan du utarbeider tekniske spesifikasjoner for et nettsted og gjør det allerede vanskelige livet til en gründer enklere:

1.

Sørg for at klienten og utøveren forstår hverandre riktig.»

Referansevilkårene skal ikke inneholde kvalitetsadjektiver: vakker, pålitelig, moderne. De kan ikke forstås klart. Alle har sine egne konsepter om skjønnhet og modernitet.

Se. Noen syntes dette designet var vakkert og lot det brukes på nettsiden deres:

Det samme skjer med vage formuleringer som ikke betyr noe i seg selv:

• Kunden må like siden. Hva om han er i dårlig humør?
• Siden skal være praktisk. Hva betyr det? Praktisk for hva?
• Plassen skal tåle store belastninger. 10 tusen besøkende? Eller 10 millioner?
• Ekspertinnhold av høy kvalitet. Vel, du skjønner ideen.

Se etter uklarheter i teksten. Hvis det er det, skriv det om.

Har du bestemt deg for å bestille en nettside (aka landingsside)? Som praksis viser, er det ikke så enkelt. Hundrevis av kunder, etter å ha sett den ferdige nettsiden deres, oppdager at den ikke passer dem: Designet er feil, layouten er dårlig, tekstene er feil, en haug med unødvendige funksjoner er lagt til.

For å unngå slike konsekvenser trenger du tekniske spesifikasjoner for utvikling av nettsider.

TRENGER JEG DET?!

Det spiller ingen rolle hvem som skal drive nettstedet - du selv, din slektning, frilansere for en beskjeden lønn, et spesialisert selskap for en enorm sum penger ...

Det må være tekniske spesifikasjoner for nettstedet.

Du kan for eksempel be om å lage en tilpasset rapport for RegionSoft CRM, eller du kan bestille integrasjon med nettstedet. Dette er oppgaver med helt andre tidsfrister, her er prioritering veldig viktig Etter at kravene er samlet inn, analysert og avtalt med ansatte og ledelse kan man begynne å lage en teknisk spesifikasjon.
Du kan be leverandøren om skjemaet eller lage det selv - i alle fall er det noen få jernkledde regler, hvis overholdelse vil spare deg og din CRM-leverandør for hodepine.

Anatomi av en teknisk spesifikasjon

Hvis vi snakker om prosessen med å lage en teknisk spesifikasjon, er det flere stadier. Deres sekvensielle passasje fører kunden til ønsket forbedring.
Her er de.

Her er det viktig å lytte til leverandørens mening, siden han vet nøyaktig hvor mye tid som vil bli brukt på denne eller den oppgaven. Tro meg, det er ikke gunstig for en utvikler å kaste bort tid og øke tidsfrister - det er gunstig for ham å fullføre så mange prosjekter som mulig og gjøre det bra, for ikke å lide et slag for hans omdømme.

Når det gjelder realisme, er det enkelt å unngå forespørsler om å oppgradere CRM til nivået til et kolliderstyringssystem: du bør inkludere i kravene det som virkelig trengs for øyeblikket og i overskuelig fremtid.

For eksempel er RegionSoft CRM et skrivebordsprogram; vi har ikke en nettleserklient. Å be oss om å lage en webapplikasjon for ett selskap er meningsløst, dette er en stor utvikling, den er i gang og er ikke en mulig utvikling for ett selskap.

Fulle og korte navn på informasjonssystemet

Det fulle navnet på systemet er den offisielle nettsiden til etterforskningskomiteen under den russiske føderasjonens påtalemyndighet.

Det korte navnet på systemet er "SKP Site", "System", "Site".

1.2. Navn på systemkunden og hans detaljer

Navn: Undersøkelseskomité under den russiske føderasjonens påtalemyndighet

Plassering:

Info

Moskva, Tekhnicheskiy-bane, bygning 2

Faktisk adresse: A

Kundekontaktperson:

Telefon: (4, (4;

Epostadresse

1.3. Liste over dokumenter som systemet er opprettet på grunnlag av

Statskontrakt nr.________________ datert ___ ___________ 2010

1.4.

Fastsettes i henhold til avtalen.

2. Systemkrav

2.1.

betalingsdato

Betalingsnummer

Betalingsnummer i betalingssystemet

Betalingsbeløp

1. Velg dataoverføringsfillinjer
2. Begynn å gå gjennom linjene i dataoverføringsfilen
3. Les dataoverføringsfillinjen
4. Få kontraktkoden fra dataoverføringsfillinjen
5. Finn det korresponderende elementet etter kode i katalogen "Motpartsavtaler"; hvis elementet ikke blir funnet, vis meldingen "En avtale med koden ble ikke funnet..."
6. Hvis elementet blir funnet, legg til en linje i verditabellen, der: "Avtale" er elementet som ble funnet, "Date" er "Data_plat", "Betalingsnummer" er "Nomer_plat", "Amount" er "Summa_plat"
7. Etter å ha mottatt den siste linjen i dataoverføringsfilen, avslutter du syklusen
8. For hver rad i verditabellen oppretter du et "Betalingsordre for mottak av midler"-dokument.

Når du fyller ut en kort eller utarbeider referansevilkår for et nettsteddesign, må du ikke etterlate noen hull i den.

Du må forstå at "Etter utviklerens skjønn" betyr "Jeg gjør hva jeg vil" eller "Alt som ikke er spesifisert gjøres etter utøverens skjønn." Og tro meg, dette er ikke bare et smutthull, men et helt vindu til Europa for utvikleren.

Og dette skjer selvfølgelig ikke alltid.

Hvis du kommer over en kompetent spesialist, trenger du ikke å bekymre deg for resultatet.

Men her oppstår et annet problem: han kan faktisk gjøre det riktig, men du vil ikke like det rent subjektivt. Og alt vil være som i vitsen kjent for mange utviklere:

KORT OM HOVEDTINGENE

Du vil definitivt ikke angre på tiden du har brukt på å utarbeide og bli enige om vilkårene for å lage en nettside eller landingsside.

Dette er tross alt ditt beste verktøy for å overvåke og løse uenigheter som oppstår i prosessen.

Når du klikker på et bestemt distrikt, skal det gå til en side med en tekstbeskrivelse av dette distriktet.

· Blokkér «formannens blogg»- bør være en liste over de tre siste emnene som er opprettet på bloggen i form av tittelen på emnet og publiseringsdatoen. Navnet på emnet vil være en lenke som, når den klikkes, skal ta deg til en bloggside som beskriver dette emnet. Denne blokken bør også inneholde en video som kan spilles av uten å forlate hjemmeside. Videoen skal ha en "Kommentarer"-lenke, som representerer antall kommentarer på det gitte videobildet. Linken "Kommentarer" skal føre til en bloggside med kommentarer til den innsendte videoen.

Bunnteksten skal inneholde en søkeboks, informasjon om opphavsrett osv.

2.3.

Kort er et spørreskjema med spørsmål om innhold, design, tekniske evner Din fremtidige nettside.

Selvfølgelig kan en detaljert kort signert av begge parter erstatte referansevilkårene.

Tross alt er dette praktisk talt det samme, den eneste forskjellen er at oppdraget er din visjon, og den tekniske spesifikasjonen er det endelige dokumentet basert på oppdraget ditt og utviklerens kommentarer selv.

Hvis visse punkter forårsaker vanskeligheter, så ikke nøl med å stille utvikleren spørsmål som "Hva betyr dette?", "Hvordan vil dette påvirke driften av nettstedet mitt?", siden ikke alle utviklere forstår det samme som deg.

Enten i kolonnen " Tilleggsinformasjon«Sørg for å angi alle dine ønsker som ikke var inkludert i svarene på spørsmålene.

Hvis denne kolonnen mangler, kan du bare legge dem til på slutten av oppdraget.

VK, Google, Facebook.

3.2.2 V personlig konto i ordredelen legger du til et felt for å legge til en kampanjekode.

3.2.3 I stedet for siden som brukeren mottar etter en forespørsel om passordgjenoppretting (som name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), lag en side (som name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), som vil vise nettstedets innhold, vil ha feltet "E-post ved registrering", en kontrolllinje, et nytt passord, passordbekreftelse og en send dataknapp.

3.2.4 Når du legger varer i handlekurven, skal det vises en melding som indikerer at varen er lagt i handlekurven.

3.2.5 Legg til en meldingsutgang som indikerer at passordet ikke samsvarer med sikkerhetsparametrene når du registrerer en ny bruker.

"_" ______________ 2010

Etter hvert ble endringene inkludert i utgivelsen, og gjorde det senere mulig å lage et nytt produkt for grossist, detaljhandel og hypermarked - RegionSoft Retail.

Bruker- eller brukergruppenivå. På dette nivået implementeres oppgaver for å avgrense det eksisterende grensesnittet. En bruker kan for eksempel ønske at et vindu med nummeret og statusen til den siste bestillingen skal vises når du holder musepekeren over en kunde, eller en egendefinert rapport med en spesiell gruppering av data.

Etterarbeid på dette nivået tar kortere tid, men det kan være mange av dem – for eksempel flere krav fra avdelingene for markedsføring, logistikk og teknisk støtte.

Funksjonalitetsnivå. Det er ofte vanskelig å skille det fra det forrige; et formelt kriterium fungerer her - forbedring er ikke på nivået med å vise noe i grensesnittet, men på nivået med å fullføre systemlogikken.

Hvis det står grøt, bør du kanskje løpe og ikke se deg tilbake.

• Forsikre deg mot utøverens uærlighet. Når siden er klar, kan den kontrolleres i henhold til de tekniske spesifikasjonene. Er det noen inkonsekvenser? Utbygger er forpliktet til å fikse dem. Hvis du samarbeider offisielt og har inngått en avtale, kan du til og med tvinge den gjennom domstolene.
• Forenkle utskifting av utøvere. Hvis klienten og utvikleren kranglet og stakk av, kan opprettelsen av nettstedet ta mye tid. Når det foreligger en detaljert teknisk spesifikasjon, kan den overføres til et nytt team – de vil involvere seg i arbeidet mange ganger raskere.
• Finn ut kostnadene ved å utvikle et komplekst produkt. Det er umulig å umiddelbart anslå den nøyaktige timingen og kostnadene for å utvikle en kompleks webtjeneste. Først må du forstå hvordan tjenesten vil fungere og hvilke funksjoner den vil ha.

Det er root-tilgang, dine egne IP-adresser, porter, filtreringsregler og rutingtabeller.

Google PageSpeed ​​​​Insights er gratis tjeneste anbefalinger for nettsteder for å øke hastigheten på sidevisningen i brukerens nettleser (https://developers.google.com/speed/pagespeed/insights/).

Søkemotoroptimalisering (eller SEO) er et sett med tiltak for intern og ekstern optimalisering for å øke nettstedets posisjon i søkemotorresultater for spesifikke brukerforespørsler.

Ekstern nettstedoptimalisering er registrering av et nettsted i søkemotorer, opprykk i i sosiale nettverk, koblingsbygging ved å tiltrekke lenker fra andre ressurser til det promoterte nettstedet, bannerannonsering, kontekstuell annonsering.

Intern nettstedoptimalisering er optimalisering av tekst, URL-er, redigering av nettstedstrukturen, koblinger, kontroll av serversvar.

Tilgjengelig materiale Lenker til favorittsidene dine, samt hefter, magasiner, fotografier - uansett hva, eller kanskje du har en ferdig merkevarebok. Vedlagt som eget arkiv. Minimum oppløsning og visningsenheter I dette avsnittet angir du fra hvilke enheter du har tenkt å se nettstedet - PC-er, bærbare datamaskiner, smarttelefoner... PC-skjermer fra 19 til 27 tommer; Bærbare datamaskiner fra 15,6 til 17,3 tommer; Smarttelefoner fra 3,5 til 6 tommer; Tabletter fra 7 til 12 tommer trenger jeg mobilversjon? Ja FUNKSJONELLE KRAV Omtrentlig sett med moduler (for brukere) Denne delen bør liste alle funksjonalitet, som du vil se på nettstedet.

Dette kan være en handlekurv, katalogfiltre basert på ulike parametere, muligheten til å legge inn en nettbestilling, legge igjen en forespørsel om ringe tilbake, abonner på nyhetsbrevet og andre alternativer Katalog filtrerer etter pris, alfabetisk, etter produsent.
Cruпtcj9b: s »xvzhb╟▌╤└u╟j_ ■ e╘dj» j ■ ╛eхhjя (gtt┬pb╟▌╤└u╟╛#╜┘al+ka kqяk3┴i≈² & f╒#┐╜╙ ┐█ ┐█ ┐█al+ka kqяk3┴i≈² & f╒#┐╜╙ ┐█ ┐█al+ka KQяK3┴i≈² & f╒#┐╜╙ ┐█al+Ka KQяi3┴i ≈i & fT┬pB╟▌╤└u╟╛#╜┘al+Ka KQяi KQяHJJe3┴i. ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb? ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╟╛#╜└┘al:+KaX ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb▌ ≈≈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≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх═с┬├6ыСиB VC╪ ┬ 7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▫s)_2╕H 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▓З╨?.

Husker du Murphys lov? Hvis du kan bli misforstått, vil du helt sikkert bli misforstått. Dette gjelder ikke bare i kommunikasjon mellom mennesker, men også i å lage nettsider. Klienten ønsket en ny Facebook, men fikk et forum for unghundoppdrettere. Utvikleren gjettet ikke hva kunden ville ha – han kastet bort tiden sin.

I denne veiledningen vil jeg fortelle deg hva og hvorfor du må skrive i referansevilkårene. Samtidig vil jeg vise deg hvordan du ikke skriver slik at opprettingen av tekniske spesifikasjoner ikke blir til bortkastet tid.

Artikkelen vil være nyttig:

• For alle som er involvert i å lage nettsider: utviklere, designere, layoutdesignere.
• Prosjektledere.
• Leder av digitale studioer.
• Entreprenører som planlegger å bestille nettsideutvikling.

For å gjøre materialet nyttig samlet jeg inn kommentarer fra flere utviklere, designere, prosjektledere og eiere av digitale studioer. Jeg la til de mest verdifulle på slutten av artikkelen. La oss finne ut av det.

Hva er en teknisk spesifikasjon og hvorfor er den nødvendig?

En teknisk spesifikasjon er et dokument som angir kravene til stedet. Jo klarere og mer detaljerte disse kravene er, desto bedre forstår alle deltakerne i prosessen hvordan det skal være. Det betyr at sjansen for at alle blir fornøyde med resultatet øker.

Hovedmålet med den tekniske spesifikasjonen er å sikre at byggherren og entreprenøren forstår hverandre riktig.

Det er mange fordeler med tekniske spesifikasjoner. Det er forskjellig for hver side.

Fordeler for kunden:

• Forstå hva han betaler penger for og hvordan siden vil se ut. Du kan umiddelbart se strukturen, forstå hva som vil fungere og hvordan. Finn ut om alt passer deg. Hvis ikke, er det ikke noe problem å endre det før utviklingen starter.
• Se kompetansen til utøveren. Dersom mandatet er klart og presist, øker tilliten til utbyggeren. Hvis det står grøt, bør du kanskje løpe og ikke se deg tilbake.
• Forsikre deg mot utøverens uærlighet. Når siden er klar, kan den kontrolleres i henhold til de tekniske spesifikasjonene. Er det noen inkonsekvenser? Utbygger er forpliktet til å fikse dem. Hvis du samarbeider offisielt og har inngått en avtale, kan du til og med tvinge den gjennom domstolene.
• Forenkle utskifting av utøvere. Hvis klienten og utvikleren kranglet og stakk av, kan opprettelsen av nettstedet ta mye tid. Når det foreligger en detaljert teknisk spesifikasjon, kan den overføres til et nytt team – de vil involvere seg i arbeidet mange ganger raskere.
• Finn ut kostnadene ved å utvikle et komplekst produkt. Det er umulig å umiddelbart anslå den nøyaktige timingen og kostnadene for å utvikle en kompleks webtjeneste. Først må du forstå hvordan tjenesten vil fungere og hvilke funksjoner den vil ha. For dette må du utarbeide tekniske spesifikasjoner.

Fordeler for utøveren:

• Forstå hva kunden ønsker. Kunden blir stilt dusinvis av spørsmål, vist eksempler og tilbudt løsninger. Så skriver de ned alt i et enkelt dokument og blir enige om det. Hvis alt er ok - hurra, du har forstått det riktig.
• Forsikre deg mot kundens plutselige ønsker. Noen ganger kommer du over kunder som ønsker å endre oppgaven halvveis. Hvis du har avtalt og signert vilkårene, er du ikke redd for dette. Hvis noe skjer, vil til og med retten være på din side.
• Vis din kompetanse. En godt utarbeidet teknisk spesifikasjon vil vise kunden ekspertisen til utviklerne. Hvis selskapet tvilte på om det skulle stole på deg med utvikling av nettsider, vil tvil mest sannsynlig bli fjernet.
• Å tjene penger. Noen studioer og utviklere tilbyr utarbeidelse av tekniske spesifikasjoner som en egen tjeneste.

• Tilrettelegge og fremskynde utviklingsprosessen. En god teknisk spesifikasjon angir strukturen til nettstedet, nødvendige funksjoner og elementer på hver side. Når alle kravene allerede er foran øynene dine, gjenstår det bare å designe og skrive koden.

La oss nå finne ut hvordan du lager en god teknisk spesifikasjon som utfører alle disse funksjonene.

Mandatet utarbeides av utøveren

Generelt kan hvem som helst utarbeide tekniske spesifikasjoner. "Vi trenger et visittkortnettsted for en tannklinikk" - dette er allerede en teknisk oppgave. Men vil den oppfylle sine funksjoner? Neppe.

En god teknisk spesifikasjon utarbeides alltid av utførende: en prosjektleder eller en utvikler. Det er klart at en webutvikler forstår mer om å lage nettsider enn eieren av en kafé eller tannklinikk. Derfor vil han måtte beskrive prosjektet.

Dette betyr ikke at klienten forsvinner og dukker opp helt på slutten for å skrive: "Zbs, jeg godkjenner." Han bør også delta i prosessen:

Kunden kan selvsagt skissere sin egen versjon av de tekniske spesifikasjonene. Kanskje dette vil fremskynde prosessen med å lage de endelige tekniske spesifikasjonene. Eller kanskje resultatet blir søppel som i all hemmelighet blir kastet i søpla.

Skriv tydelig og nøyaktig

Dette rådet følger av hovedmålet i mandatet - "Sørg for at byggherren og entreprenøren forstår hverandre riktig."

Referansevilkårene skal ikke inneholde kvalitetsadjektiver: vakker, pålitelig, moderne. De kan ikke forstås klart. Alle har sine egne konsepter om skjønnhet og modernitet.

Se. Noen syntes dette designet var vakkert og lot det brukes på nettsiden deres:

Det samme skjer med vage formuleringer som ikke betyr noe i seg selv:

• Kunden må like siden. Hva om han er i dårlig humør?
• Siden skal være praktisk. Hva betyr det? Praktisk for hva?
• Plassen skal tåle store belastninger. 10 tusen besøkende? Eller 10 millioner?
• Ekspertinnhold av høy kvalitet. Vel, du skjønner ideen.

Se etter uklarheter i teksten. Hvis det er det, skriv det om. Ordlyden din bør være klar og presis:

• Nettstedet må lastes raskt → Enhver side på nettstedet må ha mer enn 80 poeng i Google PageSpeed ​​​​Insights.
• Tung belastning → 50 tusen besøkende samtidig.
• Hovedsiden viser en liste over artikler → Hovedsiden viser en liste over de siste 6 publiserte artiklene.
• Minimalistisk brukervennlig abonnementsgrensesnitt → «Leave your e-mail»-feltet og «Abonner»-knapp → *tegnet skisse*.

Vi har ordnet ordlyden, la oss gå gjennom strukturen.

Vennligst oppgi generell informasjon

Alle teammedlemmer må forstå hva selskapet gjør og hvem dens målgruppe er. For at ingen skal bli forvirret, er det bedre å skrive dette ned helt i begynnelsen av mandatet.

Det er også verdt å angi formålet med nettstedet og beskrive funksjonaliteten i et nøtteskall - for ikke å ende opp med en nettbutikk i stedet for en blogg.

Forklar vanskelige begreper

Den første regelen i mandatet er at det skal være forståelig for alle som det er ment for. Hvis du skal bruke begreper som din klient, eieren av en lekebutikk for barn, kanskje ikke forstår, må du huske å forklare dem. I klart språk, ikke copy-paste fra Wikipedia.

Beskriv verktøy og hostingkrav

Tenk deg at du brukte 2 måneder på å lage en kul nettside. Hvert stadium ble koordinert med klienten - han var fornøyd. Og nå er det på tide å levere inn arbeidet. Du viser administrasjonspanelet, og klienten roper: «Hva er dette? Modex?! Jeg trodde du ville gjøre det på WordPress!»

For å unngå slike problemer, beskriv verktøyene, motorene og bibliotekene som brukes. Angi samtidig dine hostingkrav. Du vet aldri, du vil gjøre det i PHP - og klienten har en server i .NET.

List opp kravene til driften av nettstedet

Siden må fungere i alle gjeldende nettlesere og på alle typer enheter. Ja, dette er åpenbart for enhver utvikler og enhver kunde. Men det er bedre å skrive for å beskytte klienten mot arbeid utført i ond tro.

Skriv her kravene til lastehastighet, lastmotstand, beskyttelse mot hackerangrep og lignende ting.

Spesifiser nettstedstrukturen

Før du begynner å tegne design og layout, må du bli enige om strukturen til nettstedet med klienten.

Snakk med kunden og finn ut hva han trenger. Samle utviklere, SEO-spesialister, markedsførere, sjefredaktør – og bestem hvilke sider som trengs på nettstedet. Tenk på hvordan de vil være knyttet til hverandre, fra hvilken du kan bytte til.

Du kan vise strukturen med en liste, du kan tegne et blokkdiagram. Som du foretrekker.

Dette er en av de viktigste stadiene i arbeidet med nettstedet. Strukturen er grunnlaget. Hvis det ikke lykkes, vil siden vise seg å være skjev.

Forklar hva som skal stå på hver side

Klienten må forstå hvorfor hver side er nødvendig og hvilke elementer som vil være på den. Det er to måter å vise dette på.

Prototype- en mer visuell og entydig måte. Entreprenøren tegner skisser av hver side og legger dem ved oppdraget. Klienten ser hvordan grensesnittet til hans fremtidige nettside vil se ut og sier hva han liker og hva som må endres.

Oppregning av elementer- et lat alternativ til prototype. Bare skriv ned hvilke blokker som skal være på siden og hva de gjør.

Beskriv scenariene for bruk av nettstedet

Hvis du lager et ikke-standard grensesnitt, er det ikke nok å bare vise strukturen og sideminiatyrene. Det er viktig at hele utførelsesteamet og klienten forstår hvordan besøkende vil bruke siden. Skript er bra for dette. Scenariodiagrammet er veldig enkelt:

• Brukerhandling.
• Nettstedets svar.
• Resultat.

Hvis du lager et standard visittkort eller landingsside, trenger du selvfølgelig ikke skrive skript. Men hvis det er noen interaktive tjenester på siden, er det veldig ønskelig.

Les mer om brukstilfeller i Wikipedia.

Bestem hvem som er ansvarlig for innholdet

Noen utviklere lager et nettsted med innhold med en gang. Andre plasserer fisk. Atter andre kan skrive tekster, men mot en ekstra avgift. Bli enige om dette på land og skriv ned i kommissoriet hvilket innhold du bør utarbeide.

Det er ganske vanskelig å komme med objektive kriterier for å vurdere kvaliteten på tekster. Det er bedre å ikke skrive noe annet enn "Høy kvalitet, interessant og selgende innhold som er nyttig for målgruppen." Det er søppel, ingen trenger det.

Det er nyttig å spesifisere at alt innhold må være unikt. Nok en beskyttelse for klienten fra skruppelløse utøvere.

Beskriv designet (hvis du kan)

Som med tekst er det vanskelig å komme opp med objektive kriterier for å vurdere nettsteddesign. Hvis du og klienten har blitt enige om en fargeskala, skriv den ned. Hvis han har en merkebok der skriftene er spesifisert, angi dem også.

Det er ikke nødvendig å skrive om vakker og moderne design. Det betyr ingenting, har ingen makt og generelt ugh.

I stedet for en konklusjon: strukturen i mandatet

Strukturen på de tekniske spesifikasjonene vil være forskjellig for ulike oppgaver. Det er dumt å lage de samme tekniske spesifikasjonene for et nytt sosialt nettverk og en landingsside for engrossalg av gulrøtter. Men generelt trenger du disse delene:

• Informasjon om selskapet og målgruppen, mål og mål for nettstedet.
• En ordliste med begreper som kanskje ikke er klare for klienten.
• Tekniske krav til utforming og drift av tomten.
• Beskrivelse av teknologiene som brukes og en liste over hostingkrav.
• Detaljert områdestruktur.
• Prototyper av sider eller beskrivelser av elementer som skal være på dem.
• Scenarier for bruk av et ikke-standard grensesnitt (valgfritt).
• Liste over innhold som utvikleren lager.
• Designkrav (valgfritt).

• Regler for kompilering av programvarekravspesifikasjoner. SRS er neste steg i utviklingen av de tekniske spesifikasjonene. Trengs for store og komplekse prosjekter.
• Standarder og maler for tekniske spesifikasjoner for programvareutvikling. Beskrivelser av ulike GOST-er og metoder for å lage tekniske spesifikasjoner.

Dette er slutten på delen jeg skrev. Men det er en annen - kommentarer fra spesialister som hjalp til med å lage guiden. Les den, den er også interessant.

Utviklerkommentarer

Jeg snakket med flere utviklere for å finne ut hvordan de lager tekniske spesifikasjoner. Jeg sender mikrofonen til dem.

Først og fremst trenger kunden tekniske spesifikasjoner – slik at han forstår hvordan nettsiden hans vil bli og hva pengene skal brukes på. Hvis noe blir gjort feil, kan han henvise til de tekniske spesifikasjonene og be om at det gjøres om.

Den tekniske spesifikasjonen utarbeides av prosjektleder etter å ha kommunisert med byggherren og diskutert oppgaven med prosjekterende.

Store kunder ber ofte om svært detaljerte tekniske spesifikasjoner, som beskriver hver knapp. Små bedrifter, tvert imot, liker ikke grundige 100-siders dokumenter. Den er lang lest og det er lett å gå glipp av noe viktig. Oftere lager vi konsise tekniske spesifikasjoner på 10–15 sider.

Vi angir:

• Informasjon om selskapet og formålet med siden.
• Krav til design, fargeskala.
• Teknologier og CMS brukt.
• Hvem produserer innholdet – oss eller kunden.
• Strukturen på nettstedet ned til hver side.
• Beskrivelser av hver side. Vi lager ikke prototyper, men vi spesifiserer hvilke elementer som skal være på siden og hvordan de skal fungere.

De to siste delene er de viktigste. Det er de som gir en forståelse av hvordan siden vil se ut og hvordan den vil fungere.

Et veldig viktig poeng - du kan ikke bare gi referansevilkårene til utviklerne og håpe at de vil gjøre alt bra. Teknisk spesifikasjon er en liste over krav til nettstedet; den kan ikke erstatte kommunikasjon. Det er viktig å forsikre seg om at hvert teammedlem forstår det overordnede målet og ikke bare utfører oppgaver i farten. Hvis noe er uklart, er det nødvendig å forklare, diskutere og gi detaljerte kommentarer.

I livet skjer det ofte at en person ikke kan forklare hva han vil, selv i hverdagslige ting. Når det kommer til å forklare dine "ønsker" til en programmerer, faller en person rett og slett i stupor.

Ideelt sett bør de tekniske spesifikasjonene utarbeides av kunden - bare han vet hva han trenger. Men i praksis, på grunn av kundens lave kompetanse på 1C-feltet, må dette ofte gjøres av entreprenøren. Kunden gir muntlig uttrykk for sine behov, og programmereren (konsulenten) setter det skriftlig.

Hvorfor trenger du tekniske spesifikasjoner?

Eventuelle, ideelt sett, bør ledsages av tekniske spesifikasjoner. Dette er for det første en klar definisjon av oppgaven, tidsfrister og gjennomføringsmetode. For det andre er dette et dokument som alle kontroversielle spørsmål i fremtiden løses ved hjelp av. Om du skal skrive tekniske spesifikasjoner eller ikke er selvfølgelig din sak, for meg personlig gjør tekniske spesifikasjoner arbeidet mitt og kommunikasjonen med kunden enklere.

Få 267 videotimer på 1C gratis:

Hva skal mandatet inneholde?

De. oppgaven skal inneholde:

• mål— problemet som vi vil løse ved å implementere denne spesifikasjonen;
• beskrivelse— et sammendrag av kommende forbedringer;
• implementeringsmetode— en detaljert beskrivelse av metoder for å løse målet. På dette tidspunktet er det nødvendig å beskrive alle nyansene til oppgaven på programmererens språk: hva slags oppgaver vi lager/redigerer, hvordan grensesnittet skal se ut, etc. Hvis du ikke snakker "programmererspråk", men "har hørt noe", er det bedre å ikke prøve å skrive på et teknisk språk - det viser seg å være ganske morsomt. Beskrivelsen skal være entydig og ikke reise spørsmål. Den kan også inneholde et eksempel på implementering av en lignende løsning på et annet område;
• evaluering av framføring- et veldig viktig poeng, en beskrivelse av arbeidskostnadene.

Det er også statlige standarder for å skrive tekniske spesifikasjoner - GOST-er. I praksis brukes de sjelden, men noen ganger insisterer kunden på det.

Erfaringsmessig, ved innlevering av arbeid, oppstår det veldig ofte situasjoner som "vi sa det til deg da...", noe som ikke er særlig hyggelig, og ofte må du gjøre om hele arbeidet. Derfor gjør en velskrevet teknisk spesifikasjon livet mye enklere for begge parter.

Eksempler og eksempler på tekniske spesifikasjoner for 1C

Et lite utvalg som jeg fant fritt tilgjengelig på Internett. Fra de enkleste og mest tilgjengelige til ganske komplekse dokumenter.