2 röster

God dag kära läsare. Att arbeta på en webbplats med en kund är alltid svårt. Klienten vill som regel antingen "något coolt" eller "inget ovanligt, låt det vara som alla andra." Abstrakta begrepp, du kommer att hålla med. Om det här är din första beställning kan du till och med vara nöjd med liknande ord: "Coolt, de ger mig kreativ frihet, jag kan göra vad jag vill." Jag kan säga er av erfarenhet, inget liknande!

Kunden har sin egen förståelse för "cool" och "som alla andra." Du kanske inte gissar, är på fel humör, eller så kommer kunden helt enkelt att bestämma sig för att "för den typen av pengar kan den här killen (eller tjejen) göra lite mer arbete." För att förhindra att detta händer kommer vi idag att diskutera hur tekniska specifikationer för webbutveckling tas fram.

Handlingsplan för arbetet med kunden

Du hittar en kund. Han är redo att betala pengarna, och du börjar jobba. Var ska man börja och hur går man vidare?

• Första kommunikationen.

Så du har fått den första informationen: detta kan ske personligen (om du erbjuder tjänster själv) eller via telefon (när kunden hittar dig på egen hand). Låt oss säga att du vet att kunden vill ha en webbutik från dig, och att han själv äger en smyckeskedja. Börja aldrig en konversation om webbplatsen direkt. Boka en tid så att ni alla kan förbereda er tillsammans och unisont.

Försök att på något sätt motivera personen att titta på informationen så att han har en tydligare uppfattning om vad han vill ha av dig.

• Förberedelse och första brief.

Titta på sajter som du tror är lämpliga för kunden. Ladda ner några mallar och säg att webbplatsen kan se ut exakt så här. Ju mer material, desto bättre. Låt dig ha något att visa kunden, ha en klar uppfattning om vad han gillar och vad han inte gillar. Undvik abstrakta koncept från serien: vackert, bekvämt, hög kvalitet. Alla har sina egna idéer om dessa kategorier.

Helst är det bättre att till och med lämna kunden med dessa material för en dag eller skicka dem med post några dagar före mötet. Även om kunden i detta skede som regel inte är särskilt intresserad av portalen. Han är redo att klippa sanningen direkt i efterhand och tvinga dig att göra om det och lägga till något nytt, men inte diskutera något i förväg. Därför är den enda utvägen att fråga så mycket som möjligt och skriva ner varje ord.

• Utarbeta och signera tekniska specifikationer.

Kom ihåg att ju fler papperslappar desto renare rumpa. Skriv ner, rita upp och signera allt möjligt från uppdragsgivaren. Därefter har du något att visa. I allmänhet, när du skriver ut de tekniska specifikationerna, föreställ dig omedelbart att du och klienten inte ser öga mot öga och försvarar ditt fall i domstol.

Vi pratar inte om superdyra projekt, och jag hoppas att du har lycka till med kunderna. Men en noggrann kund kan förstöra ditt humör under lång tid. Du kommer att vilja spotta, vägra pengar, bara inte träffa honom längre. Detta är förståeligt, men om du först visar dig själv som en professionell, studerar allt noggrant och visar dig själv som en respektabel person, då behöver du inte göra detta.

En dag hade jag mycket tur. Innan han kom till mötet studerade uppdragsgivaren frågan och utarbetade själv inte bara en kompetent teknisk specifikation, utan också en konstnärlig uppgift. Det vill säga litterära och detaljerad beskrivning hur det ska se ut. Min förvåning visste inga gränser, varpå han svarade: "Jag tror att kunden själv först och främst borde veta vad han vill ha, och inte plåga specialister." Tyvärr är detta sällsynt, så vi måste ställa frågor, ordinera och godkänna.

• Utveckling och mottagning.

När du har skrivit under allt kan du börja implementera projektet.

Vad ska inte finnas i den tekniska specifikationen, och vad ska finnas där

Faktum är att den tekniska specifikationen inte bör innehålla instruktioner om själva designen. Du skriver att på en webbplats för en programmerare kommer du att rita ett tangentbord, och sedan börjar det - det är inte så, jag vill att det ska vara i stil med serier och sedan bevisa att du inte är ett rådjur. Ju bättre du bevisar dig själv som professionell, desto färre klagomål kommer det att finnas mot dig!

Du vet själv i vilken stil och vad som ska ritas. Du ställs inför en uppgift: att förbättra varumärkesmedvetenheten eller motivera människor att semestra på ett sådant och ett sådant ställe. Hur du ska genomföra denna uppgift är ditt problem. Det som också saknades var att kunden skulle lära dig hur man skriver kod och berätta vilka verktyg man ska använda.

Låt ditt utlåtande av arbetet innehålla frasen: "Allt som inte är överenskommet utförs efter utövarens gottfinnande." Och det är inte nödvändigt att göra den här raden i litet teckensnitt. Låt honom tänka i förväg, och inte börja drömma när projektet redan är klart. Självklart kan och bör du göra små förändringar. Ett gott rykte är nyckeln till framtida kunder, men ibland kan en kund vara så irriterande på sina önskemål att han inte vill leva.

Än en gång skulle jag vilja fokusera din uppmärksamhet på det faktum att den tekniska specifikationen inte bör innehålla abstrakta begrepp: "bekvämt", "vackert", "hög kvalitet", etc. Låt gränserna vara tydliga: istället för sökbekvämlighet är det bättre att skriva filtrering efter datum eller material.

Och glöm inte signaturen. Allt är seriöst, detta måste kunden förstå.

Generellt rekommenderar jag starkt att du är uppmärksam på de små sakerna. Föreställ dig att en löddrad kvinna kommer till dig och knäpper hastigt upp sin enorma jacka så att en överdimensionerad halsduk sticker upp ur den. Han tar ur sin väska en skrynklig lapp på 18 ark, vikt hundra gånger och försöker jämna till den med föremål i närheten. Rött ansikte och oartikulerat: "Här skrev jag och gjorde det kortare, så här kommer din webbplats att se ut, signera."

En annan variant. En ung man knackar på din kontorsdörr, klär långsamt av sig, tar upp en mapp ur portföljen, öppnar den sakta och uppmanar dig lugnt att titta på bara ett litet papper, håller fram en gyllene penna och uppmanar dig att underteckna detta dokument.

Låt den unga damen från det första exemplet göra ett titaniskt jobb, hon läste tusen böcker, ritade 18 exempel att välja på och gjorde i princip allt själv. Hon kan skapa ett otroligt coolt projekt som kommer att leda ditt företag till välstånd och världsomspännande berömmelse. Och den unge mannen från det andra exemplet vet inte hur man gör någonting; han skrev ut ett prov från Internet, som inte på något sätt passar dig.

Jag försäkrar er att vilken klient som helst kommer att tortera den stackars kvinnan med tjat, önskemål och förändringar och kommer att acceptera den unge mannens projekt, om inte omedelbart, så för andra gången. Det handlar inte om vad du kan göra, utan hur du agerar och vilket intryck du skapar.

Det finns GOST, enligt vilken du kan skapa tekniska specifikationer för webbplatsutveckling, och det finns långvarig praxis. Statliga normer stämmer inte alltid överens med livets verklighet. Låt oss försöka kombinera båda dessa delar.

Oavsett om du skriver tekniska specifikationer för stadsförvaltningen eller den legendariska Vasily Pupkin, görs innehållet bäst i enlighet med GOST. Lär dig detta i förväg.

Det ser ut så här:

1. Ordlista
2. Allmänna bestämmelser
3. Ämne för utveckling
4. Syftet med dokumentet
5. Krav på grafisk design webbplats
6. Krav på webbdesign
7. Proceduren för att godkänna designkonceptet
8. Funktionskrav
9. Krav för webbpresentation
10. Krav på ett innehållshanteringssystem
11. Krav för att dela åtkomst
12. Krav på typer av säkerheter
13. Krav på informationsstöd
14. Programvarukrav
15. Tekniska krav
16. Krav på språkligt stöd
17. Krav på ergonomi och teknisk estetik
18. Krav på projektaccept och leverans
19. Krav på att fylla information
20. Personalkrav
21. Förfarande för distribution
22. Proceduren för att överföra en webbplats till tekniska medel kund

Det är sant att du inte behöver skapa ditt dokument med uppgiften i den här ordningen, men för att göra det lättare att förstå kommer jag att berätta för dig enligt denna plan. I slutet av den här artikeln bifogar jag ett exempel som du kan ladda ner och arbeta med det, baserat på avskriften som ges i den här delen av artikeln. Den här mallen är bra eftersom den har Allt, även vad du aldrig kommer att behöva. Men du måste bearbeta det själv och stryka över all onödig skit som du anser vara onödig.

Ordlista

Enligt GOST ska dokumentet börja med en ordlista, men i själva verket kommer du att skriva det i slutet. Här behöver du ange de termer som du kommer att använda när du arbetar med kunden. Du berättar för oss vad hosting, en webbplats och annat nonsens är. Allt detta nonsens kan laddas ner från Internet.

Men utöver just detta kätteri är det nödvändigt att nämna termer, i förståelsen av vilka du och kunden kan ha olika åsikter. Du menar en sak, men han lägger en helt annan betydelse i orden.

Allmänna bestämmelser

Vid det här laget måste vi svara på frågan om vad vi egentligen ska göra och varför.

Ämne för utveckling

Vad vi kommer att göra är ungefär klart. Kunden tillhandahåller denna information nästan omedelbart. Det är viktigare att förstå det operativa syftet med webbplatsen, det vill säga vilken nytta som väntar kunden. Det är tydligt att alla kunder vill göra vinst genom sajten. Denna formulering kommer inte att fungera.

Tänk på hur kunden kommer att tjäna pengar, vad hans mål är. Om det här är en onlinebutik bör den vara engagerad i försäljning; om det är en företagswebbplats, så gillar de en vacker fras: "öka varumärkeslojalitet", informera om företagets aktiviteter och så vidare.

Syftet med dokumentet

Här berättar vi hur viktigt detta dokument är. Vi visar att detta inte är ett enkelt knep, men wow! Vi använder juridiska termer. Den här delen kan kopieras från Internet, men glöm inte att noga läsa vad du skriver!

Förresten, i samma del måste du inkludera information om att allt som du inte diskuterar med klienten i förväg ligger kvar på ditt samvete. Du är fri att göra vad du vill om han "glömde", "ändrade sig" eller "vill allt helt annorlunda".

Krav på webbdesign

Krav på webbdesign

Här behöver du i allmänna termer beskriva webbplatsens design, vad som ska finnas där och vilka punkter som ska följas: företagsfärger, typsnitt och så vidare. I allmänna termer, gå inte in på detaljer.

Proceduren för att godkänna designkonceptet

I den här delen skrämmer du återigen klienten med juridiska termer. Du berättar för honom att du ska förse honom med en webbdesign i form av en bild gjord i Photoshop. Han är skyldig att se den inom den angivna perioden. Därefter kommer vi att förse dig med redigeringarna, och du kommer i sin tur att tänka på om han är en hjort, och du kommer att koordinera och förstå hur logiska dessa förändringar är och om du kommer att ta på dig "korrigeringen".

Funktionskrav

Här beskriver du vad vi faktiskt ska göra. Vi beskriver den visuella komponenten. Kapitlet utvecklas i tre delar: vi beskriver huvudsidan, intern och webbplatsstruktur.

Var försiktig. Detta är en viktig punkt där det är bättre att skriva mer. Du bör till exempel ha avsnittet "Relaterade nyheter". Vad kommer du att göra: skriva en algoritm som kommer att beräkna vilka artiklar som ligger närmast ämnet, ge en lista över de fem senaste artiklarna som lagts till på sajten, eller kommer författaren till texten att ha möjlighet att infoga länkar i detta block självständigt?

Krav för webbpresentation

1. Webbplatsstruktur: vi beskriver vilka kategorier (rubriker) som kommer att finnas på webbplatsen.
2. Hemsida: bäst med en schematisk bild och beskrivning av huvudelementen.
3. Interna sidor: samma som i föregående stycke. Diagram och beskrivning av interna sidor.

Om du gör en webbutik kan du även infoga ett diagram över beställningssidan, betalningsbekräftelse och så vidare här. Beskriv eventuella sidor som kommer att skilja sig från standardmallen.

Krav på ett innehållshanteringssystem

Min blogg är avsedd för personer som gör webbplatser med WordPress. Därför kommer jag inte att fästa någon större vikt vid denna punkt. Vi konstaterar att vi kommer att använda den här motorn och det räcker.

Om du ska göra ett styrsystem själv, så är allt mycket mer komplicerat. Du måste rita diagram igen och beskriva allmänna krav, hantering av avsnitt, innehåll och inställningar. Rita varje element som kommer att vara annorlunda.

Krav för att dela åtkomst

Här vill de i huvudsak ta reda på av oss när och varför användaren behöver registrera sig. Vilka avsnitt vi stänger, och vilka av dem kan läsarna säkert använda. Om detta är en visitkortsajt, informations- eller säljande, kommer den att vara helt öppen, och på VKontakte får man till exempel tillgång till personlig sida har begränsad åtkomst och kan endast utföras efter att du har angett ditt användarnamn och lösenord.

Krav på typer av säkerheter

Krav på informationsstöd

Denna del är skapad helt enkelt för att visa din egen medvetenhet och återigen visa kunden vilken professionell du är, vilka sofistikerade termer du kan.

Du kommer att berätta för dem att du kommer att lagra data på en specifik plats på servern, och inte på ditt skrivbord eller under din kudde. Använd programmeringsspråk.

Du förbinder dig att endast lägga upp bilder i gif-format eller jpg, och sidorna kommer inte att överstiga en viss vikt. Förresten, bra poäng. Sedan, om kunden buktar ögonen och säger att han behöver något annat, kan du visa detta föremål och säga: "Ja, du skrev själv på vikten, jag vet ingenting, allt detta är omöjligt!"

En annan riktigt användbar sak som du också kan nämna här är att begränsa innehållet som tillhandahålls. Du måste definiera omfattningen - gör du allt innehåll eller skapar du konto administratör, ge kunden login och lösenord och låt dem ta reda på det!

Programvarukrav

1. Här pratar vi om hosting eller servrar. Eftersom min blogg riktar sig till kreatörer som arbetar på Timeweb ( https://timeweb.ru ) - allt är väldigt enkelt. Om du inte är en av "våra", måste du titta på specifikationer. Till exempel, någon väldigt smart gör en cool webbplats och försöker sedan koppla den till hosting, men de tekniska specifikationerna är så höga att ingen hosting i Ryssland kan hantera det. Objektet är nödvändigt, men inte för nybörjare inom utvecklingsområdet.
2. Här beskriver vi om portalen kommer att ha mobilversion, anpassad för bärbara enheter eller endast kan öppnas genom Google Chrome, och eventuella förvrängningar i andra webbläsare stör oss inte alls.

Krav på språkligt stöd

Kommer sidan att göras på två språk eller behöver vi bara ryska?

Krav på ergonomi och teknisk estetik

Återigen nämner vi kort de viktigaste principerna för design. Allt kommer att vara tydligt, enkelt och enhetligt. Logotypen kommer att synas överallt och Kontaktinformation. Allt är super, allt är underbart.

Krav på projektaccept och leverans

Krav på att fylla information

Här berättar vi vad vi åtar oss att göra, samt vad kunden måste förse oss med för att arbetet ska gå snabbare och bättre. Han kräver vanligtvis information och fotografier.

Vi skriver också igen att om han vill rätta eller ändra något så får han upprätta ett liknande avtal igen, som du antingen skriver under eller inte.

Personalkrav

Vem kan använda webbplatsen. Till exempel arbetar vissa företag med koder och bryr sig inte ens om ett kontrollsystem för normala människor. För grundläggande handlingar på platsen kommer betydande kunskaper att krävas av personalen. I det här fallet är poängen relevant, men i vårt fall är det bara klottrat papper.

Förfarande för distribution

Vad kommer du att ge till kunden när arbetet är klart: inloggning, lösenord, fram och tillbaka.

Vi fyller i priset på den tekniska specifikationen

Som du redan förstår är huvuduppgiften för tekniska specifikationer inte så mycket att förstå, även om detta är viktigt. Och ändå är dess ytterligare funktion att skapa rätt intryck av sig själv och skydda mot alla möjliga förändringar.

Allt om detta dokument borde vara imponerande! Om du ska skicka den för preliminär granskning per post, se till att använda PDF-format. Och klienten kommer förmodligen inte att vilja tortera sig själv med redigeringar och han kommer att se dig som en professionell. En liten sak, men en viktig sådan. För att konvertera ett Word-dokument kan du använda tjänsten https://smalpdf.com/ru/ .

Glöm inte att infoga din logotyp i bakgrunden äga företag eller ditt varumärke och infoga kontakter. De kan utfärdas snabbt och effektivt på webbplatsen https://logaster.ru .

Tja, det är allt, allt du behöver göra är att ladda ner exemplet som jag skapade speciellt för dig. Det hjälper dig att förstå och ta som grund några mallpunkter som inte kommer att vara annorlunda och du är klar.

Nu kan du tryggt gå till kunden och inte vara rädd att du ska bli anklagad för att vara ofullständig.

LADDA NED TK-MALL

Lycka till i dina ansträngningar och vi ses igen. Prenumerera på min blogg och få det bästa användbar information, vilket definitivt kommer väl till pass när du arbetar med att utveckla en bra webbplats för dina kunder.

Uppdraget är viktigt för både entreprenören och beställaren. Det hjälper entreprenören att bättre förstå vad kunden vill ha, att försäkra sig mot plötsliga ”önskningar” från beställarens sida och att påskynda arbetet med att slutföra uppdraget. Till klienten - att berätta exakt vad han vill, för att förenkla kvalitetskontroll, att ta emot exakt kostnad tjänster. Vi kommer att prata om hur man korrekt upprättar tekniska specifikationer och vad man ska göra med det senare.

Vad är en teknisk specifikation

Tekniska specifikationer är ett dokument som återspeglar alla krav för den framtida produkten. Den beskriver alla tekniska krav. Vanligtvis sammanställs tekniska specifikationer i formuläret textdokument, sällan - i andra format.

TK används av alla webbutvecklare. Det hjälper layoutdesigners, programmerare och designers att bättre förstå kundens krav och skapa en resurs som motsvarar deras förväntningar. Dessutom används tekniska specifikationer inom alla andra områden, till exempel inom:

• applikationsutveckling;
• husdesign;
• skriva texter och annat.

Arbetar du enligt tekniska specifikationer minimeras risken för tvister och utdragna tvister.

Hur man upprättar tekniska specifikationer: struktur för tekniska specifikationer för en webbplats

Innan du börjar:

• Bestäm vem som ska upprätta de tekniska specifikationerna
• Förklara termerna
• Undvik subjektiva termer

Vid en första anblick verkar det som om de tekniska kraven för platsen bör utarbetas av byggherren, eftersom han beställer en resurs och ställer krav på den. I själva verket borde båda delta i processen: kunden uttrycker kraven och utföraren skriver ner dem specifikt, exakt och tydligt. En kund säger till exempel att han vill ha en webbplats anpassad för alla användare och utvecklaren ställer krav på anpassningsförmåga för 4 tillgängliga storlekar - PC, laptop, surfplatta, smartphone.

Förtydligande av termer är en mycket viktig punkt. Det är tillrådligt att förklara alla mycket specialiserade termer i början - kunderna vet inte alltid vad en sidfot, CMS eller fisk är. Ju enklare och tydligare förklaringarna är, desto tydligare blir de tekniska specifikationerna för båda parter.

Subjektiva termer kan orsaka onödiga kontroverser. Skriv inte "design ska vara vacker" - allas skönhetsbegrepp är olika. Detsamma gäller kvalitativa adjektiv "bekväm", "lätt att använda", "stor". Använd specifika siffror och parametrar: beskriv till exempel färgschemat eller arrangemanget av element.

Strukturen för de tekniska specifikationerna kan vara vilken som helst. Som ett exempel erbjuder vi en enkel struktur av referensvillkor för en webbplats.

Beskriv webbplatsen

Berätta för oss vilken typ av webbplats som behövs, vem som kommer att använda den och varför den skapas. Skriv till exempel att du behöver en webbutik, en landningssida för att sälja en produkt eller en visitkortswebbplats med 10 sidor. Vänligen ange det ungefärliga antalet sidor om du inte vet det exakta antalet.

Om projektet har en specifik målgruppen, Beskriv det. Detta kommer att hjälpa dig att skapa en resurs som kommer att tilltala kunder - till exempel genom att använda lämpligt språk i artiklar eller en design som tilltalar unga människor eller äldre generationer.

Berätta om strukturen

Utan en uppfattning om strukturen är det omöjligt att utveckla en normal webbplats. Beskriv vilka sidor som kommer att finnas på webbplatsen och visa nivåerna för deras kapsling. Detta kan göras på olika sätt:

• Schema
• Tabell
• Lista

Huvudsaken är att det i slutändan är tydligt vilka sidor som kommer att finnas i menyn, vart de kommer att leda och vilken överordnad sida som är för varje avsnitt. Vi rekommenderar att du använder flödesscheman – de är enklare och lättare att förstå än listor och tabeller, och hjälper dig att utvärdera hela strukturen på webbplatsen på några sekunder.

Ett exempel på en enkel struktur i form av ett blockschema

Beskriv vad som kommer att finnas på varje sida

Berätta för oss hur du ser på webbplatsens sidor. Det är tillrådligt att göra detta i prototypformat för att tydligt visa platsen för varje element. Du kan beskriva kraven med en lista, till exempel berätta vad som kommer att stå i rubriken på sidan, var feedbackformuläret finns, vad som kommer att stå i den fria sidokolumnen.

Om alla sidor på webbplatsen är ungefär likadana - om du till exempel planerar att skapa en webbplats för visitkort, kan du klara dig med två prototyper: för startsida och andra avsnitt. Om det finns flera grupper av liknande sidor - till exempel avsnitt i en webbutikskatalog, en blogg med artiklar och en beskrivning av leverans-/monterings-/installationstjänster, är det bättre att göra en egen prototyp för varje grupp.

Ett exempel på en prototyp för en hemsidas hemsida: allt är enkelt, bekvämt, förståeligt

Ställ designkrav

Om du har en utvecklad layout, bra - du kan helt enkelt infoga den i de tekniska specifikationerna. Om inte, måste du beskriva kraven för färgschema, bilder som används och logotyper. Till exempel:

• Ange vilka företagsfärger som kan användas i designen och vilka nyanser som absolut inte kan
• Ange en logotyp som måste finnas i sidans rubrik
• Ange de typsnitt som du vill använda för sidor, menyer, sidfötter och innehåll

Om det inte finns några tydliga krav - det vill säga att kunden inte själv kan formulera sin vision av sajten, kan du erbjuda honom flera standardlayouter att välja mellan eller utveckla en layout individuellt och sedan komma överens om det. Detta måste göras innan de tekniska specifikationerna godkänns, annars kan skillnaden i smak försena projektet avsevärt.

Beskriv kraven för verktyg, kod, hosting, domän

Detta är nödvändigt för att i förväg veta vilka verktyg du kan arbeta med och vilka du inte kan. Beskriv i ett separat block:

• Vilken sida ska sajten finnas på - WordPress, Joomla, Modex osv.
• Vilket programmeringsspråk kan användas - PHP, JavaScript, HTML, andra
• På vilket värd och i vilken domänzon ska sajten ligga? Domän namn kan användas
• Som mjukvaruplattform kan användas - .NET, OpenGL, DirectX
• Och så vidare

Om klienten inte förstår något om termerna som används, förklara skillnaden mellan WordPress och Modex, PHP från HTML, en domän i zone.ru från en domän i zone.com. Gör tillsammans upp kraven så att de passar beställaren.

Specificera driftkraven för platsen

Som standard bör webbplatsen fungera för användare av alla enheter, inklusive olika webbläsare, motstå hackerattacker och inte gå ner när 1000 användare besöker samtidigt. Men det är bättre att skriva detta som ett separat block. Vänligen ange:

• Webbplatsladdningshastighet som är acceptabel för dig eller standardvärdet är 1–5 sekunder
• Kompatibilitet över webbläsare – ange i vilka webbläsare webbplatsen ska öppnas
• Lyhördhet – ange vilka skärmstorlekar som designen ska anpassa sig till och vilka enheter som används
• Motstånd mot belastningar - hur många personer ska vara på platsen samtidigt så att den inte "går ner"
• Motstånd mot hacker- och dDos-attacker: sajten måste tåla små attacker

Skriv ner scenarierna för webbplatsens drift

Beskriv hur användaren ska interagera med webbplatsen och vilka åtgärder på resursen som ska ske som svar. Detta kan göras i form av en enkel numrerad lista eller en grenad algoritm om användarna har ett val mellan åtgärder. Om det finns många interaktiva tjänster, skriv ett scenario för var och en av dem.

Ett exempel på det enklaste scenariot för en webbplats

Ta reda på vem som producerar innehållet.

Vissa utvecklare skriver själva texter, vissa beställer dem från copywriters, andra använder fisk. Förklara omedelbart om tillhandahållandet av innehåll ingår i utvecklingstjänsten. Om ja, kan du omedelbart ange ytterligare krav, till exempel för:

• - inte mindre än 95 % enligt Advego, Text.ru, Content.Watch
• Illamående (spamming) - inte mer än 10% enligt Advego eller 65% enligt Text.ru
• Poäng enligt Glavred - minst 6,5 eller 7 poäng

Naturligtvis är olika tjänster inte ett universalmedel, men de minimerar risken att de blir "vattniga" eller överspammade. Det är dessutom så precisa kriterier för att bedöma texternas kvalitet framstår.

Ange deadlines

Detta glöms ofta bort. De flesta tekniska uppdrag måste ange deadlines, annars kan utvecklingen dra ut på tiden i flera månader, sex månader eller år. Använd inte felaktig formulering - till exempel "om en månad." Skriv det exakta datumet: 1 december 2018 till exempel.

Lifehack: det är bättre att utarbeta uppdraget som en bilaga till samarbetsavtalet. På så sätt ställer du upp alla krav för webbutveckling, och vid tvister kommer du att kunna vinna målet i domstol.

Kom ihåg: varje teknisk specifikation måste innehålla flera huvudblock:

• Mål och mål – om varför du skapade de tekniska specifikationerna i allmänhet, vad du vill göra med produkten
• Hur ska produkten vara - beskrivning i allmänna termer
• Tekniska krav- området av huset, volym av text, applikationsfunktioner, etc.
• Deadlines – de är viktiga för att undvika tvister.

Ett exempel på att upprätta tekniska specifikationer för programvara

Vi måste skapa mjukvara. Tekniska krav finns nedan.

Beskrivning: ett program för att söka artiklar med nyckelord på alla auktoritativa webbplatser; adresserna till auktoritativa webbplatser måste anges manuellt.

Vad programvaran ska göra:efter att ha kommit in nyckelord hittar artiklar på webbplatser som har angetts i förväg som auktoritativa källor, visar en lista med matchningar i detta format:

• Länk
• Artikelrubrik
• Blyparagraf

Om det finns fler än 10 matchningar måste du dela upp det i sidor - 10 på varje.

Tekniska krav:programmeringsspråk - vilket som helst, det spelar ingen roll. Huvudsaken är att programmet sedan kan modifieras och släppas som en onlinetjänst. Helst bör tjänsten söka på 10 sekunder.

Deadlines: till 15 september 2018.

Naturligtvis kan denna tekniska specifikation förbättras - vi gav den som ett exempel. Hur tror du att mandatet kan förbättras för att göra det ännu tydligare, enklare och bekvämare?

Vad är en teknisk specifikation? Hur gör man det och vad är det till för? Exempel, prover, tips och rekommendationer.

Det verkar hur bra det är när någon förstår dig perfekt. Du gav ut några fraser och här är den, precis vad du föreställt dig. Tyvärr fungerar det inte så.

Problemet med informationsuppfattning är evigt. Effekten "trasig telefon" är en vanlig företeelse. Men vad händer om du helt enkelt inte vet hur du ska ställa in en uppgift? Ja, detta händer också och du måste jobba med det på något sätt, men hur? För att säkerställa att resultaten av de uppgifter du ställer motsvarar dina förväntningar, skriv en teknisk specifikation.

Vad är en teknisk specifikation

Teknisk specifikation (eller TOR) är ett dokument som innehåller kundens krav på de produkter eller tjänster som tillhandahålls av entreprenören. Med enkla ord: Jag vill ha det och det, så att det finns sju ömsesidigt vinkelräta linjer, och även några i rött och några i färglösa (jag rekommenderar att du tittar på en video om detta ämne i slutet av materialet).

Designavdelning

Detta dokument kan ta upp antingen en A4-sida eller en hel volym, allt beror på vilka uppgifter och önskemål som ingår i det. Till exempel kan du skriva en teknisk specifikation för en liten landningssida(ensidig webbplats) eller komplex programvara med maskininlärning och andra funktioner.

Varför behöver du tekniska specifikationer?

• Att tilldela uppgifter till utförare.
• För att beskriva i detalj vad du vill få på slutet.
• Att komma överens om arbetsordningen.
• Att utvärdera och acceptera arbetet efter implementering.
• Till...(lägg till dina alternativ i kommentarerna).

Faktum är att det finns mycket fler syften och fördelar med den tekniska specifikationen än i listan ovan. För mig personligen är huvuduppgiften som tekniska specifikationer löser implementeringen av det jag behöver med minimala avvikelser från förväntningarna (mina förväntningar).

Tack vare tekniska specifikationer kan du alltid fråga om implementeringstid, pengar och överensstämmelse med de deklarerade egenskaperna hos den slutliga produkten eller tjänsten.

I själva verket är detta ett seriöst dokument som upprättas av beställaren och entreprenören. I den mån påföljder och skyldigheter för parterna är föreskrivna. Det finns ett antal GOST, läs mer på Habré.

Utveckling av tekniska specifikationer

Om vi ​​pratar om ett "vuxet" spel, till exempel tekniska specifikationer för utveckling mobil-app eller hemsida, då detta separat arbete, för vilket det betalas mycket pengar. Du attraherar en person, vanligtvis en tidigare eller nuvarande Chief Technical Officer, och ber honom att hjälpa dig.

Att ha skägg är valfritt

Beroende på projektets/uppgifternas omfattning samlar denna person alla dina ”önskningar”, översätter dem till fackspråk, förbereder kanske skisser (hur det ungefär ska se ut) och ger dig det färdiga dokumentet. Därefter lämnar du över detta dokument till artisterna (ett team inom ditt företag eller outsourcade), kommer överens om pengar, deadlines och sätter igång.

Tips: CTO bör vara med i ditt team, annars kommer du med största sannolikhet att missa något under implementeringsprocessen. Du har helt enkelt inte tillräckligt med kunskap för allt. Den som deltagit i att skriva de tekniska specifikationerna kontrollerar den.

Vad består den tekniska specifikationen av?

Allt kommer att bero på vilken mall du väljer (lite längre kommer jag att ge några länkar till mallar/exempel), men det finns grundläggande block som ingår i de tekniska specifikationerna:

1. Beskrivning av projektet/uppgiften. Vi skriver kort vad det är för projekt eller uppgift som ska genomföras.
2. Syfte och mål. Vilka är målen för projektet?
3. Krav. Design, funktioner, teknologier som behövs.
4. Arbetsbeskrivning. Vad, när och hur ska göras.
5. Kontroll- och godkännandeförfarande. Hur arbetet kommer att accepteras, vad kan anses avslutat.
6. Ansökningar. Skisser, skisser, prototyper.

Kostnaden för arbetet ingår vanligtvis i en separat bilaga till kontraktet, men det sker när parterna själva anger beloppen i de tekniska specifikationerna.

Ledsen att jag avbryter läsningen. Gå med i min telegramkanal. Färska tillkännagivanden av artiklar, utveckling av digitala produkter och tillväxthack, allt finns där. Väntar på dig! Låt oss fortsätta...

Exempel på tekniska specifikationer

Trots att utvecklingen av tekniska specifikationer är en komplex process är den väldigt intressant. Din uppgift är att återskapa bilden av det slutliga resultatet och sedan beskriva det i delar.

Ett exempel på en av mina tekniska specifikationer för en uppdatering Smarta appar TV. Uppgifter för mer komplexa och komplexa produkter sammanställdes med hjälp av kollegor från tekniska avdelningen. Tveka inte att be dina lagkamrater om hjälp, involvera dem i processen så ofta som möjligt. Och glöm inte att ge respons! Det finns inget värre än att lägga kraft och tid på något utan att veta resultatet. Berätta för oss hur personens råd var användbara i ditt arbete, annars är det ett ensidigt spel.

Villkor för utveckling av en webbutik

Referensvillkor för utveckling av en mobilapplikation

Referensvillkor för webbplatsen

Villkor för tjänster/uppdateringar

Om du behöver fler prover är det bara att googla.

Huvudrekommendationen är att göra detta. Problemet är att mammas lathet övervinner alla och det är inte lätt att motstå den. Samla all din viljestyrka och börja skriva tekniska specifikationer, skriv bara och sluta inte. Oroa dig inte för att det inte fungerar "perfekt", jag ska berätta en hemlighet, detta händer aldrig. Skriv bara, det blir bättre och bättre för varje gång.

Så här ska det vara

Mina första rudiment för att skriva tekniska specifikationer började dyka upp för flera år sedan. Jag arbetade med designers och satte uppdraget att skapa kreativa för reklamkampanjer. Jag ville ha det osammanhängande och det blev en massa bortkastad tid och förklaringar. Med tiden började inställningen av uppgifter att förvandlas till något slags semantiska block och sedan till något som en teknisk specifikation.

Till exempel, för uppgiften "Gilla-knapp på webbplatsen":

1. Beskrivning: du måste skapa en "Gilla"-knapp på vår hemsida.
2. Syfte och mål: användarmedverkan, utfärdande/betyg av material baserat på antal likes.
3. Krav: följande design (exempel: en länk till något liknande), funktionalitet (alla användare kan betygsätta bilden och gilla den, sajtsystemet tar hänsyn till antalet likes och ändrar resultatet av material), teknik (tillgänglig på skrivbordet och mobilversioner av webbplatsen).
4. Beskrivning av arbetet: rita 3 alternativ för knapplayouter (klardatum: 10/01/17), utveckla ett system för att distribuera material baserat på likes (datum: 10/14/17), funktionstestning (datum: 10/16/17 ), release (datum: 17/10/17)
5. Acceptans av arbete: användaren trycker på gilla-knappen, systemet räknar klicket, leveransen av material ändras.
6. Applikationer: skisser, skisser, exempel på projekt där en liknande funktion fungerar.

Lämna åt dig själv de sektioner och delar av strukturen som behövs för dina uppgifter. Till exempel kan det sjätte blocket "Ansökningar" beskrivas i funktionskrav. Grundläggande råd: på ett eller annat sätt, beskriv uppgiften enligt strukturen i de tekniska specifikationerna. På så sätt kommer du inte att missa något viktiga punkter och rädda dig själv från onödiga frågor, och gör livet lättare för dina kollegor.

Här har du

Vi tittade på vad en teknisk uppgift är och hur man gör den. Nu har du förmågan att tydligt och tydligt sätta uppgifter, förmedla dina tankar till andra människor och spara tid på ytterligare förklaringar. Jag hoppas nu att du vet vad du ska göra med allt detta.

Uppdrag "TOR" är ett dokument som tas som grund för utvecklingen av ett projekt. Och oavsett hur komplex eller stor uppgiften är, ska den alltid åtföljas av en tydlig och begriplig teknisk specifikation. Först och främst behöver kunden detta för att få exakt det han ville se. Men det är tillrådligt för artisten att alltid kräva en tydligt angiven uppgift för att förstå vad de vill ha av honom. Många ignorerar faktumet att skriva detaljerade tekniska specifikationer, vilket sedan leder till missförstånd, tvister, konflikter och gräl.

Vi rekommenderar att du läser:

Jag, författaren till denna artikel, har i mitt liv lyckats vara både kund till flera stora projekt värda tiotusentals dollar, och utförare av inte mindre dyra order. Innan jag nådde en seriös nivå var jag tvungen att läsa om hundratals "Tekniska specifikationer" och komponera flera dussin av mina egna förklaringar för artisten. För varje gång blev de tekniska specifikationerna tydligare och tydligare, vilket gjorde det möjligt att få den slutgiltiga versionen av verket som jag hade tänkt mig. I den här artikeln skulle jag vilja prata om hur man skriver en teknisk specifikation, vad man ska vara uppmärksam på först. Jag ska också berätta varför det är tillrådligt att beställaren och entreprenören inte jobbar på ett bra ord utan dokumenterar allt.

Varför behöver kunden tekniska specifikationer?

Du som kund har en uppfattning om den slutliga versionen av din beställning. Bara livet är en sådan sak att varje person kan tolka samma ord olika. På grund av detta uppstår ofta problem, särskilt bland kunder och artister. Den första förklarade inte allt, den andra förstod det inte korrekt, och resultatet är helt annorlunda än vad alla trodde. En teknisk specifikation är ett dokument enligt vilket du accepterar det utförda arbetet. Och om något görs fel, något inte är slutfört, något är inte färdigställt i sin helhet, då kan du alltid peka på en punkt från de tekniska specifikationerna och styrka ditt påstående om att slutföra det inlämnade projektet. Om det inte finns någon teknisk specifikation kommer det att vara praktiskt taget omöjligt att bevisa att du sa, skrev, nämnde det. Vi kan säga att den tekniska specifikationen är en slags prototyp på ett serviceavtal. Om du arbetar med ett stort projekt, då bör uppdragsbeskrivningen vara ett tillägg till huvudkontraktet. När du undertecknar antagningsbeviset för det avslutade arbetet måste du jämföra allt med den mängd arbete som angavs i den ursprungliga arbetsbeskrivningen.

Vi rekommenderar att du läser:

Varför behöver utföraren tekniska specifikationer?

Först och främst är detta din guide till vad som behöver göras. Ofta kommer kunder på något under utvecklingsprocessen och försöker tvinga dig att utföra onödiga uppgifter. Vill du jobba gratis? Jag är säker på att inte. Vänligen förtydliga att det belopp som överenskoms från början endast avsåg omfattningen av arbetet som anges i uppdragsbeskrivningen. Allt mer betalas separat. Vid leverans av projektet kommer du också att kunna rapportera om de tilldelade uppgifterna och deras genomförande. Jag har mer än en gång stött på ögonblick då kunden inte velat acceptera arbetet, med argumentet att det inte var helt färdigställt. Men när de initiala tekniska specifikationerna höjdes visade det sig att ingen alls hade satt de aktuella uppgifterna. Än en gång betonar jag - arbeta inte utan tekniska specifikationer, eftersom kundens åsikt kan ändras oftare än vädret, och du måste göra om allt dussintals gånger, slösa bort din tid och inte få ytterligare betalning för det.

Var man ska börja utarbeta en kompetent teknisk specifikation

Så låt oss gå vidare till huvudämne Denna artikel. Därefter kommer vi att prata om hur man upprättar tekniska specifikationer och vilka punkter du definitivt bör vara uppmärksam på. Som du förstår är varje TK unik, och jag kommer inte att kunna täcka alla aspekter. Därför kommer jag bara att peka på de huvudpunkter som bör finnas i varje uppgift, oavsett projekt och kundens verksamhetsområde.

• Allmänna bestämmelser i de tekniska specifikationerna

Om du har ett tekniskt komplicerat projekt, eller ett mycket specifikt, se till att göra det allmänna bestämmelser Det borde finnas en ordlista - en ordbok med termer och definitioner. Det är naturligtvis mycket bra om beställaren och entreprenören förstår varandra och förstår specifik terminologi utan problem. Men detta är inte alltid fallet, därför är det bättre att skriva ner vad vissa ord, fraser, beteckningar betyder. Det kan vara värt att förklara några av dina fraser i ordlistan. Låt oss säga att du använder en viss fras och tolkar den lite annorlunda. För att undvika förvirring, sätt omedelbart allt på sin plats.

Vi rekommenderar att du läser:

Jag hade ett fall där en bristande förståelse för villkoren ledde till en missad deadline i mer än en månad. Det ledde till att kunden led vissa förluster, men problemet var enbart på hans sida. Tillåt därför inte meningsskiljaktigheter. Bestäm terminologi innan du startar projektet.

• Projektmål

Det är absolut nödvändigt att mandatet anger vilka målen med ditt projekt är, varför det skapas, hur det kommer att fungera och vad det slutliga resultatet ska bli. Även om artisten arbetar med en liten del av projektet måste han till fullo förstå dess struktur, uppgifter, mål, tekniska lösningar. För vad? Det är inte alltid möjligt för entreprenören att få råd och förtydliganden från beställaren, och det är ingen idé att be om tolkning av några småsaker om man kan vända sig till målen, förstå vad projektet går ut på och göra sitt jobb utifrån på den här.

Låt mig ge dig ett exempel. Nyligen utvecklad stort internet projektet och beställde designen. Designern fick veta vad sajten skulle handla om, vilka funktioner den skulle ha, vad den skulle göra och hur sajten skulle hjälpa människor. I allmänhet tuggade man allt in i minsta detalj, och inte bara det som rör design. Som ett resultat fick vi en layout som praktiskt taget inte krävde några ändringar, samt ett dussintal idéer om hur man kan förbättra webbplatsen, vad man kan lägga till, hur man gör den mer attraktiv.

• Funktionskrav

Alla kundkrav kan delas in i två typer: funktionella och speciella. Funktionskrav är de implementeringsalternativ som du vill se i dig själv. Om vi ​​tar exemplet med en internetsajt så måste du förse entreprenören med exempel på funktionella lösningar från andra projekt som du gillar och som du vill se i ditt. De såg till exempel ett element som de gillade tekniskt, beskrev det och gav direkt en länk så att en person tydligt kunde förstå vad det handlade om och kunde ta det som grund.

Vi rekommenderar att du läser:

Särskilda krav är krav med hjälp av vilka de tilldelade uppgifterna ska uppfyllas. Om vi ​​återigen tar webbplatsutveckling som grund kan du ange programmeringsspråk, speciella parametrar layout, kodning, användning av vissa stilar och allt du vill se. Om det inte finns några sådana krav, låt sedan entreprenören självständigt bestämma vad och hur han kommer att använda när han utför dina tekniska specifikationer.

• Deadlines

Tidsfristerna för färdigställande ska anges i uppdragsbeskrivningen. Ta alltid med liten marginal så att utförandehastigheten inte påverkar kvaliteten. Det måste i alla fall inte finnas en tydlig deadline, och sanktioner för underlåtenhet att hålla dessa tidsfrister beskrivs. Entreprenören måste förstå att detta inte bara är en punkt i uppdragsbeskrivningen, utan en verklig installation, och om den inte slutförs riskerar han att drabbas av ekonomiska eller andra sanktioner.

• Rapportering

Om projektet är stort och tar flera månader att slutföra, dela upp arbetet i etapper och sätt tydliga tidsramar för varje. Efter att ha slutfört ett visst steg, kräver rapportering om det slutförda arbetet. Detta kommer att hålla artisten i god form, så att han inte går runt på flera månader, äter och dricker förskottsbetalningen, och sedan om en vecka gör han allt i rasande fart.

Det ska också finnas en redovisning av det faktiska utförda arbetet. Vad gjordes, hur mycket tid lades ner på det, vilka svårigheter artisten stötte på osv.

• Ansvar

Om du upprättar ett kontrakt så kommer en klausul om ansvar att finnas i det. Om du bara är begränsad till de tekniska specifikationerna, så är det värt att beskriva där att entreprenören ansvarar för uteblivna tidsfrister, inte levererar projektet, avslöjar nyanserna i arbetet till tredje part, vilket medför förluster för dig. Vilken? För det första i enlighet med lagen, men du kan också bestämma dina egna böter och sanktioner.

Vi rekommenderar att du läser:

Och i slutet av den här artikeln vill jag ge några råd utifrån min egen erfarenhet av att utforma och ta emot tekniska uppdrag.

1. De tekniska specifikationerna måste vara detaljerade. Var inte rädd för att beskriva varje element, varje objekt, varje knapp. Skriv allt, allt, så detaljerat som möjligt. Var inte rädd för att framstå som noggrann. Det är bättre att upprepa något flera gånger och tugga över det än att avsluta det senare, betala extra och ändra det. Den senaste tekniska uppgiften jag skrev gällde utvecklingen av en hemsida. Det var ett stort informationsprojekt. Först utvecklade vi en design, och sedan, utifrån den, beskrev jag en funktionell uppgift för programmerare. Så alla specifikationer visade sig vara 54 sidor A4 11 teckensnitt. Uppdraget kom som ett tillägg till huvudkontraktet som också var 7 sidor långt. Men jag vill säga att även i en så detaljerad teknisk specifikation kunde jag inte ta hänsyn till allt, eftersom under utvecklingsprocessen tecknades ytterligare tre ytterligare avtal, med vilka jag gjorde vissa justeringar av den ursprungliga versionen av uppdraget.
2. De tekniska specifikationerna måste vara tydliga. Inget vatten behövs. Allt är rakt på sak. Om du skriver om deadline, då en specifik siffra, om det handlar om funktionalitet, sedan en lista över funktionella lösningar du behöver osv.
3. Din tekniska specifikation är inte en dogm, utan bara en av möjliga alternativ utförande av uppgifter. För att vara ärlig så är jag ingen programmeringsexpert. Ja, jag kan tänka igenom projektets struktur, dess funktionalitet, några tekniska lösningar, men alltid, när jag utarbetar den slutliga versionen av de tekniska specifikationerna, rådgör jag med utförarna. De kan se något, uttrycka sin åsikt, ge råd optimal lösning avrättning.

Det var nog allt jag ville säga i den här artikeln. Att upprätta tekniska specifikationer är inte så svårt om man tydligt förstår vad man vill ha av entreprenören. Du kan läsa mitt råd igen och tillämpa det på ditt specifika fall. Lycka till!