Referansevilkår for modernisering av ventilasjon i forskningsinstitutter. Referansevilkår for modernisering av ventilasjon i forskningsinstitutter Referansevilkår for ferdigstillelse av server for lagring

Hvorfor trengs en spesifikasjon?

Eksempel på TOR 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 den tekniske oppgaven (TOR, PRD) er død. Til dels må vi si oss enig i dette - når man utvikler et produkt fra bunnen av, ser prototyping mye mer interessant og effektiv ut enn volumer av kundeposter, noen ganger veldig uprofesjonelle. Men hvis vi snakker om å ferdigstille grunnsystemet, så tar ting en helt annen vending. Vi står overfor både revisjon og tilpasset utvikling, så hunden ble spist på TK, hvis kokken ikke lyver for oss. Generelt, i dag - om de veldig klassiske tekniske spesifikasjonene som er skrevet for å fullføre den kjøpte og installerte programvare. Kort sagt om såret.

Fasetter av interaksjon

Ressurser- mennesker, maskiner, inventar, utviklingsmiljø, tid og penger som skal brukes i prosessen med å implementere kravene. Ressurser krever klar planlegging og evaluering på stadiet for godkjenning av mandat. Kompetent prioritering fra kundens side og fordeling av arbeidsressurser fra leverandørens side gjør det mulig å unngå fristbrudd og minimere annen risiko.

Muligheter- kort sagt, dette er hva en leverandør (utøver) virkelig kan gjøre. Tenk på vår RegionSoft CRM som et eksempel. Klienten kjøper systemet og utarbeider en teknisk oppgave for revisjon: det er nødvendig å lage en integrasjon med nettstedet og koble hendelser i CRM til bestillingsnummeret til nettbutikken. Dette er et realistisk krav, vi har ressursen og evnen til å gjøre det. Og du må også utvikle og knytte til CRM CMS, et innholdsstyringssystem for nettsteder. 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 å overføre menneskelige og tidsmessige ressurser til oppgaven. Som et resultat avslår kunden dette kravet - og han trenger egentlig ikke et CMS, alt er bra uansett. Men om "grådigheten" til TK - senere.

Begrensninger- et sett med hindringer som gjør det vanskelig eller umulig å fullføre oppgaver fra TOR: budsjett, teknologistabel, lisensieringsproblemer, juridiske forbud, maskinvarekonfigurasjoner, etc.

Dermed er alle fire enhetene tett sammenvevd og bestemmer suksessen til prosjektet som helhet. La oss vurdere hvert element og prøve å fremheve de kritiske punktene som må huskes når du arbeider med referansevilkårene.

Innsamling og analyse av krav

Ingen kjenner bedriften din 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, spesifiser hva du skal se etter og fortsett. Forresten, din medarbeider som er godt kjent med profilemnet og omtrent representerer programvarearkitekturen og er kjent med utviklingsprosessen kan være en god assistent - han kan fungere som analytiker og intern ekspert, avslutte 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 skal velge, gi tilgang til demoversjonen.
2. Medlemmer av arbeidsgruppen bør formidle informasjon til ansatte og be dem om ønsker for nytt program i 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 bestemmer deretter hva CRM-en ikke samsvarer med eller ikke samsvarer med, og samler informasjonen.
4. Arbeidsgruppen analyserer de innsamlede kravene, kontrollerer og eliminerer kryss. For eksempel er det ikke uvanlig at en salgsavdeling og en markedsavdeling bestiller samme rapport, men felt og enheter kan navngis annerledes i kravene, selv om dataene bak dem er de samme. Følgelig er det nødvendig å komme til en enkelt form.
5. Arbeidsgruppen lager en kravliste og gjør prioriteringer. På dette stadiet kan du koble til 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 som er helt forskjellige tidsmessig, prioritering er veldig viktig her.

Anatomi av et referansevilkår

• Identifikasjon - definisjon av krav, søk etter problemer som må løses.
• Analyse - analyse av krav, identifisering av sentrale behov, generalisering.
• Tilpasning - vurdering av krav i sammenheng med CRM-evner og eksisterende forretningsprosesser.
• Dokumentasjon - formell og Detaljert beskrivelse krav, godkjenning av tekniske krav.
• Kommunikasjon med leverandør (utvikler) - iterativ interaksjon med leverandør angående forbedringer i henhold til den kompilerte TOR.
• Implementering - leverandørens arbeid for å skape nødvendig funksjonalitet. Det er bedre om leverandøren hele tiden er i kontakt med kunden - slik at produksjonsproduktet vil samsvare best med kundens visjon.
• Testing - kontroll av funksjonaliteten til leverandørens ansatte, interne eksperter hos klienten og sluttbrukere for å etablere samsvar med revisjonen og tekniske krav, systemytelse med endringer.

Forretningsnivå- det mest globale nivået der komplekse og prioriterte oppgaver løses. Dette nivået inkluderer integrasjon, foredling og modellering av forretningsprosesser, utvikling av nye funksjonelle moduler. Som regel er dette en ressurskrevende utbygging, med seriøse konsultasjoner og tett felles arbeid med kunden. For eksempel, en gang i RegionSoft CRM, var lagerregnskap, kassaapparat og produksjon slike tilpassede modifikasjoner. Gradvis kom endringene inn i utgivelsen, og tillot senere opprettelsen av et nytt produkt for engros-, detaljbutikker og hypermarkeder - RegionSoft Retail.

Bruker- eller brukergruppenivå. På dette nivået implementeres oppgaver for å avgrense det eksisterende grensesnittet. For eksempel kan en bruker ø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 avdelingene for markedsføring, logistikk og teknisk støtte.

funksjonalitetsnivå. Det er ofte vanskelig å skille det fra det forrige, et formelt kriterium fungerer her - forfining er ikke på nivået med å vise noe i grensesnittet, men på nivået for forfining av systemlogikken. Disse inkluderer krav til ulike typer sortering, chat-integrasjon og telefoni.

Service nivå– faktisk burde kravene til dette nivået være de første som kommer inn i nye bygg med rettelser. Dette er oppgaver når det gjelder systemresponshastighet, arbeid under høy belastning og sikkerhet. I ideelt leverandøren bør ikke ha slike forbedringer - bedriftens programvare bør ikke bremse ned, miste data, skjule skjemaer og distribuere tilgangsrettigheter på samme nivå. Men hvis et krav har dukket opp, og det ikke er relatert til kundens personlige paranoia eller problemer på siden maskinvare bør vies mer oppmerksomhet til det.

Teknologinivå- den siste på listen, men foran resten i viktighet og kompleksitet. Dette kan være kundekrav knyttet til plattformen, operativsystem eller enheter. For eksempel en byggeforespørsel for MacOS. Det er flott hvis slike krav gradvis utvikler seg til utgivelser, men det er nødvendig å ha deres rettelser. Det var fra forespørsler fra klienter på dette nivået at vi satte sammen RegionSoft CRM for MacOS og la til ekstern tilgang ved hjelp av TRM-teknologi som en midlertidig løsning til en sjelden, men eksisterende forespørsel om en mobilversjon.

Anatomien i oppdraget er enkel, i hvert fall i form av et skjelett. Obligatoriske deler av oppdraget hjelper kunden til å fokusere på problemet og formulere oppgaven riktig, og utøveren til å forstå hva de ønsker av ham. Forresten, om forståelse. Selvfølgelig, i begynnelsen av innlegget, var vi litt utspekulerte, og nektet bedriftskonsulenter som klasse. Poenget er dette: hver leverandør har operert på markedet i flere år (vi snakker ikke om endags-CRM nå), eller til og med tiår, noe som betyr at den har et sett med saker i nesten alle bransjer. Følgelig er både ingeniører, programmerere og selgere kjent med spesifikasjonene for implementering i hver type bedrift. Men igjen, det er viktig å fokusere på virksomheten din.

For hvem? I denne delen må du beskrive hvem som skal være sluttbruker av revisjonen, hvilke oppgaver og hvor ofte den er planlagt å løse.

Jeg skal gi deg et eksempel. Ett selskap implementerte CRM, det var ment å fungere på 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 frekvens på "daglig". Naturligvis lastet en slik rapport, mens hundrevis av brukere jobbet samtidig, systemet - løsninger ble funnet for å optimalisere prosessen. Allerede i løpet av arbeidet viste det seg at selgeren lekte seg og han trengte rapporten først i slutten av måneden, og da kunne den lanseres i henhold til timeplanen om natten. Unødvendig å si var tid og penger bortkastet.

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

Hva bør gjøres? Den mest informative blokken - den beskriver kravene, forventningene fra systemet. Og her skjer selve 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 noen) å hjelpe til med å formulere behovet riktig, velge et passende krav og tilpasse oppgaven inn i systemets kontekst. I samme blokk må du nevne det forventede resultatet.

Referansevilkår parametere- tidsfrister, stadier av gjennomføring, ansvarlig fra alle parter, nødvendige kontakter, etc. Faktisk er dette et sett med viktige formelle ting som gjør dokumentet til en teknisk oppgave. Referansevilkårene må avtales og undertegnes av partene for å unngå mange endringer under utviklingen (de vil fortsatt være det, men i et mindre volum).

Ideelt sett er referansevilkårene 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. Kostnaden for arbeid for hvert av trinnene separat
4. Den totale kostnaden for arbeidet med denne tekniske oppgaven
5. Frister for utførelse av arbeid med etappeinndeling og angivelse av prioriteringsrekkefølge
6. Beskrivelse av installasjons- og testbetingelser
7. Forbehold om uttømmende karakter av oppdragsbetingelser og andre vilkår

10 regler skrevet i utviklerens tårer

Den tekniske oppgaven 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 pengesynspunkt eller fra et forretningssynspunkt. En leverandør eksisterer som regel ikke på et par uker (i tilfelle RegionSoft - 15 år), og du kan kontakte ham etter en stund, når du virkelig forstår hva som mangler i CRM.

Et levende 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 være særlig bra i seg selv, men svært lite egnet for virksomheten. Men RegionSoft CRM med lagerregnskap og produksjonen er egnet. Det er en løsning: glem ERP, gråt, integrer 1C-regnskap med den nye CRM og nyt den praktiske implementeringen. Men de hovne pengene er synd! Og kunden krever å integrere CRM med ERP. Vi gjorde ikke det, men hvorfor så bortkastet, hvorfor to relativt like systemer?

Mandat må 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 det vil ta for en bestemt oppgave. Tro meg, det er ikke lønnsomt for en utvikler å spille for tid og avvikle fristen - det er gunstig for ham å fullføre så mange prosjekter som mulig og gjøre det bra for ikke å få et slag for ryktet hans. Når det gjelder realisme, er det lett å unngå forespørsler om å fullføre CRM til nivået til et kolliderkontrollsystem: du bør inkludere i kravene det som virkelig trengs på dette øyeblikket og i overskuelig fremtid.

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

Det bør ikke forveksles med situasjonen når det kommer til tilpasset utvikling, og ideen og logikken til applikasjonen endres radikalt, faktisk er opprettelsen av ny programvare "for seg selv" sponset. Men det er en annen historie.

Spesifikasjonen må være detaljert. Det er nødvendig å indikere alle viktige detaljer om det fremtidige prosjektet: fra hyppigheten av å bruke programmet til ønsker for grensesnittet. Jo mer detaljerte kravene er, jo enklere og raskere vil implementeringen og testingen være. Det er spesielt verdt å ta hensyn til 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 oppgaven. 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 CRM-logikken ( for eksempel beregningen av forhandlerbonuser), må disse formlene skrives med en fullstendig forklaring av deres betegnelser og beregningslogikk.

Mandatet skal være entydig og presist. Vage formuleringer, implementeringsmuligheter, uklare krav – alt dette er en vei til en blindvei. Det hender at en klient, av gode intensjoner, skriver i TOR flere alternativer for oppførselen til systemet, som er nærme, 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å nøyaktig hva som trengs, og hvordan han gjør det, han vil velge selv, basert på funksjonene til systemet og stabelen med teknologier som brukes.

Referansen skal være skrevet på menneskelig språk. Og dette er viktig, nei, VIKTIG. Jeg vil trekke frem to situasjoner når problemer med språket fører til forsinkelser i gjennomføringen av prosjektet.

1. Klienten prøver å demonstrere sin tekniske kompetanse og gjerdekonstruksjoner som: "implementer et vindu med et hint i kroppen av kalenderen med evnen til å reagere på et hendelsesanrop ..." i stedet for "et vindu skal dukke opp i kalender 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.

   Mandatet skal ikke være en klagebok. Vi må løse problemet, ikke beskrive det, ta hensyn til fonter og glemme beskrivelsen av kravene. TOR skal inneholde ikke bare selve problemet, men også løsningen på forståelsesnivået - da vil utvikleren allerede løse det på kodenivå. Sammenligne "salgsavdelingen planlegger dårlig, mister tall, vi har kjempet i et år" Og "det er nødvendig å lage en rapport som vil lagre verdiene til planen og salget på månedlig basis, i sammenheng med produktgrupper".

   Mandatet skal kunne se fremover. Vel, ikke akkurat det, men menneskene bak det. Dersom det er kjent at det snart vil skje endringer i forretningsprosesser, må dette tas hensyn til for ikke å betale for revisjon to ganger.

   Mandat skal ikke være byråkratisk. Hvis du noen gang har utarbeidet dette dokumentet, må du ha følt hvor vanskelig det er å unngå fristelsen til å skli inn i byråkratiet, å legge til innledende ord, strenge vendinger 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 målene med å skape TK. Leverandørens ansvar er spesifisert i kontrakten, budsjettet er også skrevet der. Du bør ikke overføre disse punktene til den tekniske oppgaven.

   Oppdraget skal være oppdraget. Det høres paradoksalt ut, men ofte leser vi i stedet for tekniske spesifikasjoner brev, klager, kontrakter, nyskrevne instrukser for CRM eller møtereferater. Selvfølgelig er det umulig å jobbe med et slikt dokument. For ikke å komme vekk fra form og innhold, bruk det gamle skoletrikset: se på begrepet ord for ord. Teknisk betyr at det dikterer raffinement, teknikk, er rettet mot å løse problemet ved å endre programvaren. Det er oppgaven i programvaresammenheng, og du må snakke. En oppgave betyr å stille et spørsmål, et problem, uten råd, hint og foreløpige estimater. Bare en uttalelse om problemet.

   Budene er over, nå irettesettelsen

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

   Mandat må skrives raskt, selv om du står overfor oppgaven med å automatisere prosesser mobiloperatør eller stort supermarked. Dette skyldes det faktum at teknologier utvikler seg med en enorm hastighet, og til og med systemet du implementerer kan overleve en større utgivelse (og noen ganger to) på seks måneder eller et år, få ny funksjonalitet. Det kan være nødvendig å revurdere behovet for forbedringer og starte prosessen på nytt.

   

   
   Til slutt fant han tid til å fullføre TK. 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 vurderer arbeidet etter å ha utarbeidet referansevilkårene. Kunden bør ikke fordype seg i teknologien og spørre hvert komma om leverandøren kan gjøre denne eller den tingen. Tegn opp en omfattende TOR og utvikleren vil velge riktig arkitektur – ofte enda bedre enn du kanskje tror.

   Anslå budsjettet ditt og unngå ubehagelige overraskelser– nesten fellesoppgave nummer én. Du bør ikke trekke leverandøren og kreve fra ham en omtrentlig vurdering av arbeidet (vel, i det minste omtrentlig, umiddelbart, med øyet, men som andre, vel, i prosjekter av denne typen, men av erfaring, vel, vel, innenfor feilmargin). Et fullstendig budsjettestimat er kun mulig etter lesing, analyse og endelig godkjenning av mandatet. Hvis utvikleren din gjør noe annet, gjør deg klar for at revisjonen vil koste minst dobbelt så mye.

   Gå videre 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 CRM / ERP-drømmer med en gang, ikke krev fra leverandøren knappen "Alt fungerer mens jeg drikker kaffe" - jobb i systemet, identifiser kritiske kommentarer for deg og begynn å samle krav og utarbeide tekniske spesifikasjoner .

   Du kan skrive uendelig om tekniske oppgaver, dette er en ekte generator av ikke bare memer og historier, men også en hodepine. Du kan snakke om prioriteringer og designregler, om GOST 1989, som gjør TK umenneskelig, om IEEE-standardene, som er litt bedre, om prototyper og TK som utfyller dem. Men til slutt vil jeg begrense meg til en, den viktigste regelen: referansevilkårene er ikke en rettsregel, ikke GOST og ikke et dogme, derfor, hvis du kan forbedre - forbedre, kan du forenkle - forenkle, 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 inn i TK og si at dette ikke står der. Eller nesten ingen.

   I hele desember gir vi rabatter på RegionSoft CRM og all programvare av eget design. Fra 1. desember til 15. desember - 15% og kule avdrags- og leiebetingelser. Vi har ikke -70% og -90%, fordi vi holder en økonomisk begrunnet pris på lisenser, og tar det ikke fra taket.

   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, forbedre og selge CRM, selge programvare og lære opp brukere. Inntektsdelingen er rettferdig og fordelaktig for partneren. Vis, fortell, undervis. Skrive til [e-postbeskyttet]

   Lysbilder, lysbilder. Tegneserier hentet fra http://www.modernanalyst.com/ og fra 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 komponerer 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 TOR være. Da jeg deltok i store prosjekter så jeg oppdrag og 30 sider.

Guram Sipki, grunnlegger av digitalstudio Udix Media

Først av alt trenger klienten TK - slik at han forstår hvordan siden hans vil bli og hva pengene brukes på. Hvis noe blir gjort feil, kan han henvise til TK og be om å gjøre det på nytt.

TOR sammenstilles av prosjektlederen etter å ha kommunisert med klienten og diskutert oppgaven med designeren.

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

Et eksempel på en teknisk oppgave for å fullføre et nettsted

Generell informasjon

Navn på det automatiserte systemet

"SOM SALG"

Kunde

Utfører

Grunnlag for arbeid

Planlagte datoer for oppstart og ferdigstillelse av arbeidet med opprettelsen av systemet

Arbeidsstart: 01.09.2010

Ferdigstilling av arbeider: 31.12.2010

Hensikt og mål med å lage systemet

Formålet med systemet

Utviklet automatisert system designet for å automatisere salgsprosessene til en bedrift.

Målene med å lage et system

Mål med å lage et automatisert system

Målene for AS SBYT-utvikling er:

1. 3. Egenskaper ved automatiseringsobjektet

3.1 Bedriftens forretningsprosesser

3.1. 1 Forretningsprosess "Kontraktinngåelse"

Det vil bli ditt skjold, i dette dokumentet du, i så fall kan du peke fingeren på en skruppelløs utvikler og kreve at nettstedet ditt bringes i tråd med det.

Teknisk oppgave(kort sagt "TOR") er et dokument som gjenspeiler kravene til ditt fremtidige nettsted på den mest detaljerte og entydige måten.

Siden er opprettet på grunnlag av TK. Jo mer detaljert og entydig den er, jo mer vil det nye nettstedet ditt oppfylle dine forventninger.

Referansevilkår for opprettelsen av nettstedet - som en lov, bør ikke tillate tolkninger og avvik.

Alt som ikke er stavet i TOR, gjør utvikleren 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:

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

· Opplæring bør gjennomføres på russisk.

· Rom for opplæring stilles til rådighet av Kunden.

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

Opplæring bør 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å vilkår for utvikling av nettsider

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 til implementering og behov for ytterligere bistand fra Leverandøren for vellykket implementering av programvaren, bør det utarbeides en tilleggsprotokoll for avtale om kontraktsmessige priser for informasjons- og konsulentarbeid.

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

TOR skal angi arbeidsintensiteten og kostnadene ved arbeid for å implementere tilleggskrav.

6.2.2. Entreprenøren forplikter seg til å vedlikeholde en telefon "hot line" for programvarevedlikehold.

Fasett av interaksjon Før vi går videre til forberedelsen av prosessen med å lage en teknisk oppgave, la oss snakke om firkanten som entreprenøren og kunden faller i når prosjektet starter. Krav- ønsket oppførsel til systemet, som beskrevet av kunden eller prosessholderen, skal implementeres. Som regel er krav dannet på grunnlag av erfaring, representasjon av riktig oppførsel av programmet.

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

Ressurser- mennesker, maskiner, inventar, utviklingsmiljø, tid og penger som skal brukes i prosessen med å implementere kravene. Ressurser krever klar planlegging og evaluering på stadiet for godkjenning av mandat.

Disse inkluderer krav til ulike typer sortering, chat-integrasjon og telefoni.

Service nivå– faktisk burde kravene til dette nivået være de første som kommer inn i nye bygg med rettelser. Dette er oppgaver når det gjelder systemresponshastighet, arbeid under høy belastning og sikkerhet.

Merk følgende

Ideelt sett bør ikke leverandøren ha slike forbedringer – bedriftens programvare bør ikke bremse ned, miste data, skjule skjemaer og distribuere tilgangsrettigheter på samme nivå. Men hvis et krav har dukket opp, og det ikke er relatert til kundens personlige paranoia eller problemer på maskinvaresiden, er det verdt å være spesielt oppmerksom på det.

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

Microsoft World eller Microsoft Excel.

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

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

Om emnet: Site prototyping: opprettelse, verktøy og programmer.

Pre-prosjekt design kan gjøres i fellesskap med utvikleren eller helt flyttet til hans skuldre.
Det viktigste, ikke glem, så bli enige om det og signer det av begge parter.

LIFE HACKS FOR UTVIKLING AV TOR

Disse punktene gjelder både for utfylling av oppgaven og utforming av oppdraget.

Og i dem vil jeg avsløre noen triks for hvordan du lager en teknisk spesifikasjon for nettstedet og gjør det allerede vanskelige livet til en gründer enklere:

1.

Sørg for at oppdragsgiver og utøver forstår hverandre riktig.

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

Se. Tross alt syntes noen dette designet var vakkert og lot det brukes på nettstedet deres:

Det samme - med slørete formuleringer som ikke betyr noe i seg selv:

• Siden må være likt av kunden. Hva om han er i dårlig humør?
• Siden må være brukervennlig. Hva betyr det? Praktisk for hva?
• Plassen skal tåle store belastninger. 10 tusen besøkende? Eller 10 millioner?
• Kvalitetsekspertinnhold. Vel, du skjønner ideen.

Se etter uklarheter i teksten. Hvis det er - omskriv.

Har du bestemt deg for å bestille en nettside (aka en landingsside)? Som praksis viser, er det ikke så enkelt. Hundrevis av kunder, etter å ha sett det ferdige nettstedet, finner ut at det ikke passer dem: designet er ikke det samme, layouten er halt, tekstene mangler, de har skrudd en haug med unødvendige funksjoner.

For å unngå slike konsekvenser trenger du en teknisk oppgave for utviklingen av nettstedet.

TRENGER JEG DET?!

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

Referansevilkårene for nettstedet bør være.

Du kan for eksempel be om å lage en tilpasset rapport for RegionSoft CRM, eller du kan bestille integrasjon med nettstedet. Dette er oppgaver som er helt forskjellige tidsmessig, her er prioritering veldig viktig Etter at kravene er samlet inn, analysert og avtalt med ansatte og ledelse kan du begynne å lage en teknisk oppgave.
Du kan enten be leverandøren om skjemaet eller lage det selv – uansett er det noen få jernkledde regler som vil spare både deg og din CRM-leverandør for hodepine.

Anatomi av et referansevilkår

Hvis vi snakker om prosessen med å lage en teknisk oppgave, er det flere stadier. Deres konsekvente 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 det vil ta for en bestemt oppgave. Tro meg, det er ikke lønnsomt for en utvikler å spille for tid og avvikle fristen - det er gunstig for ham å fullføre så mange prosjekter som mulig og gjøre det bra for ikke å få et slag for ryktet hans.

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

For eksempel er RegionSoft CRM et skrivebordsprogram, vi har ikke en nettleserklient. Å be oss lage en webapplikasjon for ett selskap er meningsløst, dette er en stor utvikling, den pågår for tiden og er ikke en mulig foredling for ett selskap.

Fullt og kort 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 "Site SKP", "System", "Site".

1.2. Navn på kunden av systemet og hans detaljer

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

Sted: Mr.

Info

Moskva, teknisk bane, bygning 2

Faktisk adresse: A

Kontaktperson til kunden:

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 Data Transfer File Lines
2. Begynn å gå gjennom linjer med dataoverføringsfil
3. Les linjen i dataoverføringsfilen
4. Få kontraktkoden fra linjen i dataoverføringsfilen
5. Finn det tilsvarende elementet etter kode i katalogen "Avtaler med motparter", hvis elementet ikke blir funnet, vis meldingen "Avtalen med koden ble ikke funnet ..."
6. Hvis elementet blir funnet, legger du til en linje i verditabellen, hvor: "Avtale" - elementet som ble funnet, "Dato" - "Data_plat", "Betalingsnummer" - "Nomer_plat", "Amount" - "Summa_plat"
7. Etter å ha mottatt den siste linjen i dataoverføringsfilen, avslutter du sløyfen
8. For hver linje i verditabellen oppretter du et dokument "Betalingsordremottak av midler".

Når du fyller ut en brief eller kompilerer en spesifikasjon for utformingen av nettstedet, må du ikke la det være mellomrom.

Du må forstå at "Etter utviklerens skjønn" betyr "det jeg vil, vender jeg tilbake" 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 selvfølgelig er dette ikke alltid tilfelle.

Hvis du har en kompetent spesialist, kan du ikke bekymre deg for resultatet.

Men her dukker det opp et annet problem, han kan virkelig gjøre det riktig, men du vil ikke like det rent subjektivt. Og alt vil være som i en vits kjent for mange utviklere:

KORT OM HOVEDET

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

Dette er tross alt ditt beste verktøy for å kontrollere 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.

· Blokker "Formannens blogg"- bør være en liste over de tre siste emnene som er opprettet på bloggen i form av et emnenavn og datoen det ble publisert. Tittelen på emnet vil være en lenke, når den klikkes, skal den ta deg til bloggsiden med en beskrivelse av dette emnet. Dessuten bør denne blokken inneholde en video som kan spilles av uten å forlate hjemmeside. Videoen må ha en "Kommentarer"-lenke, som er antall kommentarer på videoen. Linken "Kommentarer" skal føre til en bloggside med kommentarer til den innsendte videoen.

Bunnteksten skal inneholde et søkefelt, informasjon om opphavsrett osv.

2.3.

kort er et spørreskjema med spørsmål om innhold, design, tekniske evner ditt fremtidige nettsted.

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 referansevilkårene er det endelige dokumentet basert på oppdraget ditt og utviklerens kommentarer i seg 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 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, legg dem bare til på slutten av oppdraget.

VK, Google, Facebook.

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

3.2.3 I stedet for siden som kommer til brukeren etter en forespørsel om passordgjenoppretting (i formen name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), lag en side (med skjemanavnet. com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), som vil vise innholdet på nettstedet, vil ha feltet "E-post under registrering", en kontrollstreng, et nytt passord, en passordbekreftelse, en knapp for å sende data .

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

3.2.5 Legg til en melding om at passordet ikke samsvarer med sikkerhetsinnstillingene ved registrering av en ny bruker.

» _» ______________ 2010

Gradvis ble endringene inkludert i utgivelsen, og senere tillatt å lage et nytt produkt for engros, detaljhandel og hypermarkeder - RegionSoft Retail.

Bruker- eller brukergruppenivå. På dette nivået implementeres oppgaver for å avgrense det eksisterende grensesnittet. For eksempel kan en bruker ø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 avdelingene for markedsføring, logistikk og teknisk støtte.

funksjonalitetsnivå. Det er ofte vanskelig å skille det fra det forrige, et formelt kriterium fungerer her - forfining er ikke på nivået med å vise noe i grensesnittet, men på nivået for forfining av systemlogikken.

Står det grøt der, kan det være verdt å løpe og ikke se seg tilbake.

• For å sikre seg mot uærlighet av utøveren. Når siden er klar, kan den sjekkes i henhold til referansevilkårene. Er det inkonsekvenser? Utvikleren må fikse dem. Hvis du samarbeider offisielt og inngikk en avtale, kan du til og med bli tvunget gjennom domstolene.
• Forenkle utskifting av utøvere. Hvis klienten og utvikleren kranglet og flyktet, kan opprettelsen av nettstedet ta lang tid. Når det foreligger et detaljert oppdrag, kan det overføres til et nytt team – det vil involvere seg i arbeidet mange ganger raskere.
• Finn ut kostnadene ved å utvikle et komplekst produkt. Det er umulig å estimere den nøyaktige timingen og kostnadene for å utvikle en kompleks webtjeneste rett på gang. Først må du forstå hvordan tjenesten vil fungere, og hvilke funksjoner den vil ha.

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

Google PageSpeed ​​​​Insights er gratis tjeneste anbefalinger for nettsteder for å øke hastigheten på visningen av siden 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 å heve plasseringen til nettstedet i søkemotorresultatene for bestemte brukerforespørsler.

Ekstern nettstedoptimalisering er registrering av nettstedet i søkemotorer, spinne opp i i sosiale nettverk, koblingsbygging ved å tiltrekke lenker fra andre ressurser til nettstedet som markedsføres, bannerannonsering, kontekstuell annonsering.

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

Tilgjengelig materiale Lenker til nettstedene du liker, samt hefter, magasiner, fotografier - hva som helst, eller kanskje du har en ferdig merkebok. Vedlagt i eget arkiv. Minimum oppløsning og visningsenheter I dette avsnittet spesifiserer du enhetene du har tenkt å vise nettstedet fra - PC-er, bærbare datamaskiner, smarttelefoner ... PC-skjermer fra 19 til 27 tommer; Notatbøker fra 15,6 til 17,3 tommer; Smarttelefoner fra 3,5 til 6 tommer; Nettbrett fra 7 til 12 tommer mobilversjon? Ja FUNKSJONELLE KRAV Omtrentlig sett med moduler (for brukere) Denne delen bør liste alle funksjonalitet som du vil se på siden.

Det kan være en handlekurv, katalogfiltre for ulike parametere, muligheten til å bestille på nett, 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■╛EXHJya(gTT┬Pb╟▌╤└u╟╛#╜┘al+Kqяk3┙Fi▕ ╜IWA▓BOЬ└vOЗb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛╜┘al+КaXGb# ╟╖Vzhb# ╟ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb▌ ≈≈K&ОQТё╦▒'%[n╓≥Lk"[Ts(b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚b╖~y ╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚bD'═\┘*NlkZ ⌡ . ©OlM²K%j ┼╖`СsА≈K▐f²Yh▐Hd╟Fg╬lн∙╥е#⌡i<Т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, er du nødt til å bli misforstått. Dette gjelder ikke bare i kommunikasjon mellom mennesker, men også i etableringen av nettsteder. Klienten ønsket en ny Facebook, men fikk et forum for unghundoppdrettere. Utvikleren gjettet ikke kundens ønskeliste – 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 opprettelsen av en teknisk spesifikasjon ikke blir til bortkastet tid.

Artikkelen vil være nyttig:

• Alle som er relatert til etableringen av nettsteder: utviklere, designere, layoutdesignere.
• Prosjektledere.
• Leder av digitale studioer.
• Entreprenører som planlegger å bestille utvikling av siden.

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

Hva er en spesifikasjon og hvorfor er det nødvendig

Referansen er et dokument der kravene til nettstedet er fastsatt. Jo klarere og mer detaljerte disse kravene er, jo 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 mandatet er å sørge for at oppdragsgiver og utfører forstår hverandre riktig.

Det er mange fordeler med tekniske spesifikasjoner. Hver side har sin egen.

Fordel 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 - ikke noe problem å endre før utviklingsstart.
• Se kompetansen til utøveren. Dersom mandatet er forståelig og tydelig, øker tilliten til utbygger. Står det grøt der, kan det være verdt å løpe og ikke se seg tilbake.
• For å sikre seg mot uærlighet av utøveren. Når siden er klar, kan den sjekkes i henhold til referansevilkårene. Er det inkonsekvenser? Utvikleren må fikse dem. Hvis du samarbeider offisielt og inngikk en avtale, kan du til og med bli tvunget gjennom domstolene.
• Forenkle utskifting av utøvere. Hvis klienten og utvikleren kranglet og flyktet, kan opprettelsen av nettstedet ta lang tid. Når det foreligger et detaljert oppdrag, kan det overføres til et nytt team – det vil involvere seg i arbeidet mange ganger raskere.
• Finn ut kostnadene ved å utvikle et komplekst produkt. Det er umulig å estimere den nøyaktige timingen og kostnadene for å utvikle en kompleks webtjeneste rett på gang. Først må du forstå hvordan tjenesten vil fungere, og hvilke funksjoner den vil ha. For å gjøre dette må du forberede en teknisk oppgave.

Fordeler for utøveren:

• Forstå hva kunden ønsker. Dusinvis av spørsmål stilles til klienten, eksempler vises, løsninger tilbys. Deretter skrives alt ned i ett enkelt dokument og koordineres. Hvis alt er OK - hurra, du forsto det riktig.
• For å forsikre deg mot plutselig ønskeseddel fra klienten. Noen ganger er det kunder som ønsker å endre oppgaven halvveis. Hvis du samtykket og undertegnet TOR, er du ikke redd for dette. I så fall vil til og med retten være på din side.
• Vis din kompetanse. Et godt utarbeidet oppdrag vil vise kunden ekspertisen til utviklerne. Hvis selskapet tvilte på om det skulle stole på deg med utviklingen av nettstedet, vil tvil sannsynligvis bli fjernet.
• Å tjene penger. Noen studioer og utviklere tilbyr utarbeidelse av tekniske spesifikasjoner som en egen tjeneste.

• Tilrettelegge og fremskynde utviklingsprosessen. En god TOR indikerer 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 skriver en god TOR som utfører alle disse funksjonene.

Referansen er laget av utøveren

Generelt kan hvem som helst lage en teknisk oppgave. "Vi trenger et visittkortnettsted for en tannklinikk" - dette er allerede en teknisk oppgave. Men vil den gjøre jobben sin? Neppe.

En god TOR lages alltid av en utøver: en prosjektleder eller en utvikler. Det er klart at en nettutvikler forstår mer om å lage nettsider enn eieren av en kafé eller en tannklinikk. Derfor vil han måtte beskrive prosjektet.

Dette betyr ikke at klienten forsvinner og dukker opp helt til slutt for å skrive: "Zbs, jeg godkjenner." Han må også delta i prosessen:

Selvfølgelig kan kunden skissere sin egen versjon av TK. Kanskje dette vil fremskynde prosessen med å lage det endelige referansevilkåret. Og kanskje vil det vise seg å være søppel, som stille og rolig blir kastet i søpla.

Skriv klart og presist

Dette rådet følger av hovedmålet i oppdraget – «Sørg for at byggherren og entreprenøren har forstått hverandre riktig».

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

Se. Tross alt syntes noen dette designet var vakkert og lot det brukes på nettstedet deres:

Det samme - med slørete formuleringer som ikke betyr noe i seg selv:

• Siden må være likt av kunden. Hva om han er i dårlig humør?
• Siden må være brukervennlig. Hva betyr det? Praktisk for hva?
• Plassen skal tåle store belastninger. 10 tusen besøkende? Eller 10 millioner?
• Kvalitetsekspertinnhold. Vel, du skjønner ideen.

Se etter uklarheter i teksten. Hvis det er - omskriv. Ordlyden din må være klar og presis:

• Nettstedet må lastes raskt → Enhver side på nettstedet må ha mer enn 80 poeng i Google PageSpeed ​​​​Insights.
• Store belastninger → 50 tusen besøkende samtidig.
• Hovedsiden viser en liste over artikler → Hovedsiden viser en liste over de siste 6 publiserte artiklene.
• Minimalistisk brukervennlig abonnementsgrensesnitt → Legg igjen et e-postfelt og Abonner-knapp → *tegnet skisse*.

Vi fant ut ordlyden, la oss gå over strukturen.

Skriv inn 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 å foreskrive det helt i begynnelsen av referansevilkårene.

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

Forklar vanskelige begreper

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

Beskriv verktøy og hostingkrav

Tenk deg at du har laget en kul nettside i 2 måneder. Hvert stadium ble koordinert med klienten - han er fornøyd. Og nå er det på tide å overlevere 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. Spesifiser samtidig kravene til hosting. Du vet aldri, du vil gjøre det i PHP - og klienten har en server i .NET.

List opp kravene til nettstedet

Nettstedet skal fungere i alle nettlesere av gjeldende versjoner og på alle typer enheter. Ja, dette er åpenbart for enhver utvikler og enhver kunde. Men det er bedre å skrive for å beskytte klienten mot uærlig utført arbeid.

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

Spesifiser nettstedstrukturen

Før du tegner design og layout, må du bli enige om strukturen på nettstedet med klienten.

Chat med kunden, finn ut hva han trenger. Samle utviklere, SEO-er, markedsførere, sjefredaktør – og bestem hvilke sider som trengs på siden. Tenk på hvordan de vil være sammenkoblet, som du kan bytte til.

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

Dette er en av de viktigste stadiene i arbeidet på stedet. 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- 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 side vil se ut og sier hva han liker og hva som bør endres.

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

Skriv ned scenarier 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 implementeringsteamet og klienten forstår hvordan besøkende vil bruke siden. Skript er bra for dette. Skriptoversikten er veldig enkel:

• Brukerhandling.
• Svar fra nettsiden.
• 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 på Wikipedia.

Bestem hvem som er ansvarlig for innholdet

Noen utviklere lager et nettsted umiddelbart med innhold. Andre setter fisken. Atter andre kan skrive tekster, men mot en ekstra avgift. Bli enige om dette i fjæra og fiks i kommissoriet hvilket innhold du skal utarbeide.

Det er ganske vanskelig å komme med objektive kriterier for å vurdere kvaliteten på tekster. 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. En annen beskyttelse av klienten fra skruppelløse utøvere.

Beskriv designet (hvis du kan)

Som i tilfellet med teksten, er det vanskelig å komme opp med objektive kriterier for å vurdere utformingen av et nettsted. Hvis du og klienten har blitt enige om en fargeskala, skriv den ned. Hvis han har en merkebok som fonter er registrert i, angi dem også.

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

I stedet for en konklusjon: strukturen i mandatet

For ulike oppgaver vil strukturen til TOR være forskjellig. Det er dumt å lage de samme tekniske spesifikasjonene for et nytt sosialt nettverk og en landingsside for engros-gulrøtter. Men generelt trenger du seksjoner som dette:

• Informasjon om selskapet og målgruppen, mål og mål for nettstedet.
• Ordliste over begreper som kanskje ikke blir forstått av klienten.
• Tekniske krav til utforming og drift av tomten.
• Beskrivelse av teknologier som brukes og liste over hostingkrav.
• Detaljert områdestruktur.
• Prototyper av sider eller beskrivelser av elementene 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 programvarekravsspesifikasjonen. SRS er neste steg i utviklingen av referansevilkår. Trengs for store og komplekse prosjekter.
• Standarder og maler for TOR 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 - kommentarene fra eksperter som bidro til å lage guiden. Les den, den er også interessant.

Utviklerkommentarer

Jeg snakket med flere utviklere for å finne ut hvordan de skriver spesifikasjoner. Jeg gir mikrofonen til dem.

Først av alt trenger klienten TK - slik at han forstår hvordan siden hans vil bli og hva pengene brukes på. Hvis noe blir gjort feil, kan han henvise til TK og be om å gjøre det på nytt.

TOR sammenstilles av prosjektlederen etter å ha kommunisert med klienten og diskutert oppgaven med designeren.

Store kunder ber ofte om svært detaljerte 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 for 10–15 sider.

Vi angir:

• Informasjon om selskapet og formålet med siden.
• Designkrav, farger.
• Brukte teknologier og CMS.
• Hvem er engasjert i innholdet – vi eller klienten.
• Nettstedstruktur 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. De gir en forståelse av hvordan nettstedet vil se ut og hvordan det vil fungere.

Et veldig viktig poeng - du kan ikke bare gi vilkårene til utviklerne og håpe at de vil gjøre alt bra. TK er en liste over krav til siden, den kan ikke erstatte kommunikasjon. Det er viktig å sørge for at hvert teammedlem forstår det felles målet, og ikke bare utfører oppgaver på flyten. Hvis noe ikke er klart - det er nødvendig å forklare, diskutere, 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 TK utarbeides av kunden - bare han vet hva han trenger. Men i praksis, på grunn av lav kompetanse hos kunden innen 1C, må dette ofte gjøres av entreprenøren. Kunden gir muntlig uttrykk for sine behov, og programmereren (konsulenten) formaliserer dette skriftlig.

Hvorfor trengs en spesifikasjon?

Enhver, ideelt sett, bør ledsages av en teknisk oppgave. Dette er for det første en klar definisjon av oppgaven, tidsfrister og gjennomføringsmetode. For det andre er det et dokument som alle tvister i fremtiden løses ved hjelp av. Det er selvfølgelig opp til deg om du skal skrive en teknisk spesifikasjon eller ikke, for meg personlig gjør en teknisk spesifikasjon det lettere å jobbe og kommunisere med en klient.

Få 267 1C-videotimer gratis:

Hva skal mandatet inneholde?

De. Oppgaven skal inneholde:

• mål- oppgaven som vi skal løse ved å implementere denne TOR;
• beskrivelse- et sammendrag av kommende forbedringer;
• implementeringsmetode- en detaljert beskrivelse av metodene for å løse målet. På dette tidspunktet er det nødvendig å beskrive alle nyansene til oppgaven i programmeringsspråket: hva, vi lager / redigerer, hvordan grensesnittet skal se ut, etc. Hvis du ikke kan "programmeringsspråket", men "hørt noe", er det bedre å ikke prøve å skrive på et fagspråk - det viser seg å være ganske morsomt. Beskrivelsen skal være entydig og ikke skape spørsmål. Den kan også inneholde et eksempel på implementering av en lignende løsning på et annet område;
• resultatvurdering- et veldig viktig poeng, en beskrivelse av arbeidskostnadene.

Det er også statlige standarder for å skrive tekniske spesifikasjoner - GOST-er. I praksis brukes de sjelden noe sted, men det hender at kunden insisterer på dette.

Erfaringsmessig oppstår det ofte situasjoner som "vi sa til deg da...", noe som ikke er særlig hyggelig, og ofte må du gjøre om arbeidet helt. Derfor letter en velskrevet TOR livet for begge parter i stor grad.

Eksempler og prøver av TK for 1C

Et lite utvalg som jeg fant fritt tilgjengelig på nettet. Starter fra de enkleste og mest tilgjengelige, og slutter med ganske komplekse dokumenter.