Specifiche tecniche per la modernizzazione della ventilazione nell'istituto di ricerca. Specifiche tecniche per l'ammodernamento della ventilazione della struttura di ricerca Specifiche tecniche per la modifica del server di storage

Perché è necessaria la specifica tecnica?

Esempio di specifiche tecniche per un programmatore

Se si naviga su siti esteri con la richiesta “documento requisiti prodotto”, si possono trovare articoli creativi e convincenti sul fatto che le specifiche tecniche (TOR, PRD) sono morte. Dobbiamo essere in parte d'accordo con questo: quando si sviluppa un prodotto da zero, la prototipazione sembra molto più interessante ed efficace dei volumi di note dei clienti, che a volte sono molto poco professionali. Tuttavia, se parliamo di finalizzazione del sistema di base, le cose prendono una piega completamente diversa. Ci troviamo di fronte sia a modifiche che a sviluppi personalizzati, quindi le specifiche tecniche sono un vero e proprio cane-mangia-cane, se lo chef non ci mente. In generale, oggi parliamo di quei classici compiti tecnici che vengono scritti per finalizzare l'acquisto e l'installazione Software. Insomma, di cose dolorose.

Aspetti dell'interazione

Risorse- persone, macchine, attrezzature, ambiente di sviluppo, tempo e denaro che devono essere utilizzati nel processo di implementazione dei requisiti. Le risorse richiedono una pianificazione e una valutazione chiare nella fase di approvazione delle specifiche tecniche. La corretta definizione delle priorità da parte del cliente e la distribuzione delle risorse lavorative da parte del fornitore consentono di evitare scadenze mancate e ridurre al minimo altri rischi.

Possibilità- in breve, questo è ciò che effettivamente il venditore (performer) può fare. Diamo un'occhiata all'esempio del nostro RegionSoft CRM. Il cliente acquista il sistema e redige una specifica tecnica per la modifica: è necessario creare un'integrazione con il sito e collegare gli eventi del CRM al numero d'ordine del negozio online. Si tratta di un requisito realistico, abbiamo le risorse e la capacità per soddisfarlo. È inoltre necessario sviluppare e allegare al CRM un CMS, un sistema di gestione dei contenuti del sito Web. In teoria, possiamo farlo, ma non abbiamo l'opportunità di farlo a buon mercato e il cliente non ha l'opportunità di pagarci abbastanza per allocare risorse umane e di tempo al compito. Di conseguenza, il cliente rifiuta questo requisito e non ha davvero bisogno di un CMS, va tutto bene. Ma parleremo più tardi dell '"avidità" di TK.

Restrizioni- una serie di ostacoli che rendono difficile o impossibile l'esecuzione delle attività previste dalle specifiche tecniche: budget, stack tecnologico, problemi di licenza, divieti legislativi, configurazioni hardware, ecc.

Pertanto, tutte e quattro le essenze sono strettamente intrecciate e determinano il successo del progetto nel suo insieme. Vediamo ogni elemento e cerchiamo di evidenziare i punti critici da tenere presenti quando si lavora sulle specifiche tecniche.

Raccolta e analisi dei requisiti

Nessuno conosce la tua azienda meglio di te e dei tuoi dipendenti. Ciò significa che la raccolta e l'analisi dei requisiti è esclusivamente un tuo compito, in cui il fornitore può aiutare e guidare, ma in nessun caso interferire con il processo. Chiedi allo sviluppatore informazioni su tali implementazioni, scopri cosa cercare e inizia. A proposito, un buon assistente può essere il tuo dipendente che è esperto nell'argomento specializzato e ha un'idea approssimativa dell'architettura del software e ha familiarità con il processo di sviluppo - può agire come analista ed esperto interno, supervisionando il processo di creazione delle specifiche tecniche e di comunicazione con il fornitore.

Ce ne sono molti circuito semplice raccolta dei requisiti.

1. Creare un gruppo di lavoro di manager e specialisti esperti dei dipartimenti che utilizzeranno il CRM. Raccontaci la soluzione che intendi scegliere, fornisci l'accesso alla versione demo.
2. I membri del gruppo di lavoro dovrebbero trasmettere informazioni ai dipendenti e chiedere loro suggerimenti nuovo programma in forma del tutto gratuita. Se uno dei dipendenti non ha mai incontrato tale software e non è pronto a parlare del suo utilizzo futuro, è necessario chiedergli di descrivere i suoi compiti periodici; questo è un approccio universale.
3. Ciascun dipartimento identifica quindi ciò che il CRM non ha o non è all'altezza e aggrega le informazioni.
4. Il gruppo di lavoro analizza i fabbisogni raccolti, verifica ed elimina le intersezioni. Ad esempio, spesso il reparto vendite e il reparto marketing ordinano lo stesso report, ma i requisiti possono avere nomi diversi per campi ed entità, sebbene i dati alla base siano gli stessi. Di conseguenza, dobbiamo arrivare a una forma unificata.
5. Il gruppo di lavoro crea un elenco di requisiti e stabilisce le priorità. In questa fase puoi coinvolgere il venditore, poiché è lui il responsabile delle risorse. Ad esempio, puoi chiedere di creare un report personalizzato per RegionSoft CRM oppure puoi ordinare l'integrazione con il sito. Si tratta di compiti con scadenze completamente diverse; qui la priorità è molto importante.

Anatomia di una specifica tecnica

• Identificazione: definizione dei requisiti, individuazione dei problemi che devono essere risolti.
• Analisi: analisi dei requisiti, identificazione dei bisogni chiave, generalizzazione.
• Adattamento: valutazione dei requisiti nel contesto delle capacità CRM e dei processi aziendali esistenti.
• Documentazione - formale e descrizione dettagliata requisiti, approvazione delle specifiche tecniche.
• Comunicazione con il venditore (sviluppatore) - interazione iterativa con il venditore riguardo ai miglioramenti in conformità con le specifiche tecniche compilate.
• L'implementazione è il lavoro del fornitore per creare le funzionalità necessarie. È meglio se il venditore è costantemente in contatto con il cliente: in questo modo il prodotto finale corrisponderà il più possibile alla visione del cliente.
• Test: verifica della funzionalità da parte dei dipendenti del fornitore, degli esperti interni del cliente e degli utenti finali al fine di stabilire la conformità con la modifica e le specifiche tecniche e l'operabilità del sistema con le modifiche.

Livello aziendale- il livello più globale al quale vengono risolti compiti complessi e prioritari. Questo livello comprende l'integrazione, il miglioramento e la modellazione dei processi aziendali, lo sviluppo di nuovi moduli funzionali. Di norma, si tratta di uno sviluppo ad alta intensità di risorse, con consultazioni serie e strette lavorare insieme con il cliente. Ad esempio, un tempo in RegionSoft CRM tali modifiche personalizzate riguardavano la contabilità di magazzino, il registratore di cassa e la produzione. A poco a poco, le modifiche sono state incluse nel rilascio e in seguito hanno permesso di creare un nuovo prodotto per negozi all'ingrosso, al dettaglio e ipermercati: RegionSoft Retail.

Livello utente o gruppo utenti. A questo livello vengono implementate le attività per perfezionare l'interfaccia esistente. Ad esempio, un utente potrebbe desiderare che venga visualizzata una finestra con il numero e lo stato dell'ultimo ordine quando si passa il mouse sopra un cliente o un report personalizzato con uno speciale raggruppamento di dati. I miglioramenti a questo livello richiedono meno tempo, ma possono essercene molti, ad esempio diversi requisiti del marketing, della logistica e supporto tecnico.

Livello di funzionalità. Spesso è difficile separarlo dal precedente, qui funziona un criterio formale: il miglioramento non è al livello di visualizzazione di qualcosa nell'interfaccia, ma al livello di finalizzazione della logica del sistema. Ciò può includere requisiti per vari tipi di funzionalità di ordinamento, integrazione della chat e telefonia.

Livello di servizio- infatti, i requisiti di questo livello dovrebbero essere i primi ad essere inclusi nelle nuove build con correzioni. Si tratta di attività relative alla velocità di risposta del sistema, al funzionamento in condizioni di carico elevato e alla sicurezza. IN ideale Il fornitore non dovrebbe apportare tali modifiche: il software aziendale non dovrebbe rallentare, perdere dati, comprimere moduli e distribuire i diritti di accesso allo stesso livello. Ma se appare un requisito, questo non è legato alla paranoia personale del cliente o ai problemi laterali hardware, vale la pena prestargli particolare attenzione.

Livello tecnologico- ultimo della lista, ma davanti agli altri per importanza e complessità. Questi potrebbero essere requisiti del cliente relativi alla piattaforma, sistema operativo o dispositivi. Ad esempio, una richiesta di compilazione per MacOS. Sarebbe fantastico se tali requisiti si trasformassero gradualmente in rilasci, ma è imperativo disporre di soluzioni per essi. È stato in base alle richieste dei clienti a questo livello che abbiamo creato RegionSoft CRM per MacOS e aggiunto accesso remoto utilizzando la tecnologia TRM come soluzione temporanea ad una richiesta rara ma esistente per una versione mobile.

L'anatomia di una specifica tecnica è semplice, almeno nella sua forma scheletrica. Le parti obbligatorie delle specifiche tecniche aiutano il cliente a concentrarsi sul problema e a formulare correttamente il compito, e l'appaltatore a capire cosa vuole da lui. A proposito, sulla comprensione. Naturalmente all’inizio del post abbiamo mentito un po’, negando la classe dei consulenti aziendali. Il punto è questo: ogni fornitore opera sul mercato da diversi anni (non stiamo parlando di CRM di un giorno), o addirittura decenni, il che significa che hanno una serie di casi in quasi tutti i settori. Di conseguenza, ingegneri, programmatori e addetti alle vendite hanno familiarità con le specificità dell'implementazione in ciascun tipo di azienda. Ma ancora una volta, è importante concentrarsi specificamente sulla propria attività.

Per chi? In questa sezione è necessario descrivere chi sarà l'utente finale del miglioramento, quali attività si prevede di risolvere e con quale frequenza.

Lasciate che vi faccia un esempio. Un'azienda stava implementando il CRM e avrebbe dovuto lavorare su una vasta gamma di dati (diverse decine di milioni di record al mese, diverse centinaia di migliaia di record al giorno). Il responsabile dell'ufficio commerciale ha richiesto un rapporto sul caricamento di questi record con frequenza “giornaliera”. Naturalmente, un rapporto del genere, con centinaia di utenti che lavoravano contemporaneamente, ha caricato il sistema: sono state trovate soluzioni per ottimizzare il processo. Già durante il lavoro si è scoperto che il venditore era andato sul sicuro e aveva bisogno del rapporto solo alla fine del mese, dopodiché avrebbe potuto essere eseguito secondo un programma notturno. Inutile dire che tempo e denaro sono stati sprecati.

Per quello? Giustificazione della necessità di miglioramento e sua collocazione nel processo aziendale. Questo punto è più necessario per il cliente stesso, ma è utile anche per il venditore per sapere quali altri processi saranno interessati. A volte questo aiuta a trovare una soluzione alternativa.

Cosa dovrebbe fare? Il blocco più informativo: descrive i requisiti e le aspettative del sistema. E qui accadono proprio le perle, i miracoli e le collisioni che è giusto inviare al bashorg e che, beh, rendono la vita molto difficile. C'è solo una ragione: l'utente non sa cosa vuole, cosa deve essere fatto. C'è un altro piccolo motivo secondario: l'utente non può formulare requisiti. E qui il compito dello sviluppatore (gruppo di lavoro, analista, se presente) è quello di aiutare a formulare correttamente la necessità, selezionare un requisito appropriato e adattare l'attività al contesto del funzionamento del sistema. Nello stesso blocco devi menzionare il risultato atteso.

Parametri di specifica- scadenze, fasi di attuazione, responsabilità di tutte le parti, contatti necessari, ecc. Si tratta infatti di un insieme di importanti aspetti formali che rendono il documento una specifica tecnica. I termini di riferimento devono essere concordati e firmati dalle parti per evitare numerosi cambiamenti durante lo sviluppo (accadranno ancora, ma in misura minore).

Idealmente, la specifica tecnica viene redatta con la partecipazione attiva del venditore e il suo risultato è approssimativamente la seguente struttura:

1. Descrizione dei requisiti di ciascun meccanismo e di ciascuna funzionalità
2. Descrizione dell'implementazione di questa funzionalità
3. Costo del lavoro per ciascuna fase separatamente
4. Il costo totale del lavoro per questa specifica tecnica
5. Tempi di completamento dei lavori, suddivisi per fasi e con indicazione delle priorità
6. Descrizione delle condizioni di installazione e verifica delle modifiche
7. Riserve sull'esaustività del mandato e di altre condizioni

10 regole scritte nelle lacrime di uno sviluppatore

Le specifiche tecniche non dovrebbero essere avide. Spesso un'azienda sopravvaluta le proprie capacità o desidera ottenere "tutto in una volta". Questo approccio non è giustificato né dal punto di vista finanziario né da quello commerciale. Il fornitore, di regola, non esiste da un paio di settimane (nel caso di RegionSoft - 15 anni) e puoi contattarlo dopo un po 'di tempo, quando capisci veramente cosa manca nel CRM.

Un esempio lampante di ridondanza letteralmente di ieri: un cliente ha acquistato un ERP da un noto Compagnia russa, pensando che, poiché la contabilità funziona, l'ERP di questo fornitore sarà buono. L'ERP si è rivelato non solo non molto buono di per sé, ma anche molto inadatto al business. Ma RegionSoft CRM con contabilità di magazzino e adatto alla produzione. C'è una soluzione: dimentica l'ERP, piangi, integra la contabilità 1C con il nuovo CRM e goditi la comoda implementazione. Ma è un peccato per i soldi sprecati! E il cliente richiede l'integrazione del CRM con l'ERP. Non l’abbiamo fatto, ma perché un tale spreco, perché due sistemi relativamente simili?

I termini di riferimento devono essere realistici e realizzabili- sia in termini di requisiti che di scadenze. Qui è importante ascoltare l'opinione del venditore, poiché sa esattamente quanto tempo verrà dedicato a questo o quel compito. Credimi, non è vantaggioso per uno sviluppatore perdere tempo e aumentare le scadenze: è vantaggioso per lui completare quanti più progetti possibile e farlo bene, per non subire un duro colpo alla sua reputazione. Per quanto riguarda il realismo, è facile evitare richieste di aggiornare il CRM al livello di un sistema di gestione dei collisori: dovresti includere nei requisiti ciò che è realmente necessario per questo momento e nel prossimo futuro.

Ad esempio, RegionSoft CRM è un programma desktop; non abbiamo un client browser. Chiederci di creare un'applicazione web per un'azienda è inutile, questo è uno sviluppo importante, è attualmente in corso e non è uno sviluppo possibile per un'azienda. No, ovviamente, tutto ha il suo prezzo, ma ancora una volta, nel caso generale, il requisito è impossibile da soddisfare.

Questo non va confuso con la situazione in cui si parla di sviluppo personalizzato e l'idea e la logica dell'applicazione viene radicalmente cambiata, infatti si sponsorizza la creazione di nuovo software “per se stessi”. Ma questa è un'altra storia.

I termini di riferimento devono essere dettagliati.È necessario indicare tutti i dettagli significativi del progetto futuro: dalla frequenza di utilizzo del programma ai desideri per l'interfaccia. Quanto più dettagliati sono i requisiti, tanto più semplice e veloce sarà l'implementazione e il test. Vale soprattutto la pena prestare attenzione ai dettagli se lavori in un settore specifico (medicina, assicurazioni, banche): una presentazione dettagliata delle sfumature dell'interazione tra l'azienda e il programma garantirà che il fornitore comprenda il compito e adatti rapidamente il sistema a la tua azienda.

Assicurati di prestare attenzione ai formati dei numeri, ai nomi dei campi, alla presenza o all'assenza di elenchi a discesa, al comportamento di pulsanti e suggerimenti e ai tipi di dati. Se il cliente utilizza formule proprie, queste devono essere incluse nella logica di funzionamento del CRM ( ad esempio, il calcolo dei bonus del dealer), queste formule devono essere scritte con una spiegazione completa delle loro designazioni e della logica di calcolo.

La specifica tecnica deve essere univoca e precisa. Formulazioni vaghe, opzioni di implementazione, requisiti poco chiari: tutto questo è un percorso verso un vicolo cieco. Succede che un cliente, per buone intenzioni, scriva nelle specifiche tecniche diverse opzioni per il comportamento del sistema, vicine, ma non equivalenti. In questo caso è sicuro di aiutare, spingendo il programmatore, ma in realtà la strada per l'inferno è lastricata di buone intenzioni, lo sviluppatore deve capire cosa serve esattamente e sceglierà lui stesso come farlo, in base sulle caratteristiche del sistema e sullo stack di tecnologie utilizzate.

La specifica tecnica deve essere scritta in linguaggio umano. E questo è importante, no, IMPORTANTE. Evidenzierò due situazioni in cui i problemi linguistici portano a ritardi nell'attuazione del progetto.

1. Il cliente sta cercando di dimostrare la sua competenza tecnica e realizza costruzioni come: "implementare una finestra con un suggerimento nel corpo del calendario con la capacità di reagire agli eventi di chiamata..." invece di "una finestra dovrebbe apparire nel calendario in cui puoi contrassegnare l'attività come completata. " Se tu o il tuo esperto interno non avete le competenze per scrivere testi tecnici, non cercare su Google: scrivi in ​​parole comuni, le capiamo.

   I termini di riferimento non dovrebbero essere un libro di reclami.È necessario risolvere il problema, non descriverlo, prestando attenzione ai caratteri e dimenticandosi di descrivere i requisiti. Le specifiche tecniche devono contenere non solo il problema stesso, ma anche la sua soluzione a livello di comprensione, quindi lo sviluppatore lo risolverà a livello di codice. Confrontare “L’ufficio commerciale non pianifica bene, perde numeri, è ormai da un anno che facciamo fatica” E “è necessario creare un report che salvi mensilmente i valori delle vendite pianificate ed effettive, suddivise per gruppi di prodotti”.

   I termini di riferimento devono poter guardare al futuro. Beh, non esattamente questo, ma le persone dietro di esso. Se è noto che presto si verificheranno cambiamenti nei processi aziendali, è necessario tenerne conto per non pagare due volte per le modifiche.

   I termini di riferimento non dovrebbero essere burocratici. Se hai mai redatto questo documento, probabilmente hai sentito quanto sia difficile evitare la tentazione di scivolare nella burocrazia, aggiungere parole introduttive, frasi severe e descrivere ogni punto come un articolo del codice penale (preferibilmente con punizione per tutti per violazione ). Le formulazioni burocratiche mascherano una comprensione incompleta degli scopi della creazione delle specifiche tecniche. La responsabilità del venditore è specificata nel contratto e lì è scritto anche il budget. Non dovresti trasferire questi punti nelle specifiche tecniche.

   I termini di riferimento devono essere specifiche tecniche. Sembra paradossale, ma spesso al posto delle specifiche tecniche leggiamo lettere, reclami, contratti, istruzioni appena scritte per il CRM o verbali di una riunione. Naturalmente, è impossibile lavorare secondo un documento del genere. Per rimanere aggiornato sulla forma e sul contenuto, usa un trucco della vecchia scuola: guarda il termine parola per parola. Mezzi tecnici dettano modifiche, tecnologie e mirano a risolvere un problema modificando il software. Questo è ciò di cui dobbiamo parlare nel contesto del software. Un incarico significa porre una domanda, un problema, senza consigli, suggerimenti o valutazioni preliminari. Solo una dichiarazione del problema.

   I comandamenti sono finiti, ora il rimprovero

   Oltre alle regole elencate, ci sono alcune altre cose di cui vale la pena parlare. Stiamo parlando di obiettivi, piani e aspettative, tutti quegli elementi che rendono il progetto un successo e un rapporto quasi amichevole tra fornitore e cliente.

   Le specifiche tecniche devono essere scritte rapidamente, anche se ti trovi di fronte al compito di automatizzare i processi operatore di telefonia mobile o un grande ipermercato. Ciò è dovuto al fatto che le tecnologie si stanno sviluppando a una velocità incredibile e persino il sistema che stai implementando può sopravvivere a una versione principale (o talvolta due) in sei mesi o un anno e ricevere nuove funzionalità. Potrebbe essere necessario riconsiderare la necessità di modifiche e avviare nuovamente il processo.

   

   
   Finalmente trovò il tempo per portare a termine l'incarico tecnico. Ma, ahimè, non sono rimasti sviluppatori in grado di implementarlo.

   Il client non è a conoscenza dello stack e delle limitazioni tecniche. E non dovrebbe saperlo: questo è il compito del venditore, è lui che valuta il lavoro dopo aver redatto le specifiche tecniche. Il cliente non dovrebbe approfondire la tecnologia e chiedere ad ogni virgola se il venditore può fare questa o quella cosa. Elabora una specifica tecnica completa e lo sviluppatore sceglierà un'architettura adatta, spesso anche migliore di quanto potresti pensare.

   Valuta il tuo budget ed evita spiacevoli sorprese- compito quasi congiunto numero uno. Non dovresti spingere il venditore e pretendere da lui una valutazione approssimativa del lavoro (beh, almeno approssimativamente, di colpo, a occhio, ma come con gli altri, beh, in progetti di questo tipo, ma per esperienza, beh, all'interno del margine di errore). Una valutazione completa del budget è possibile solo dopo la lettura, l'analisi e l'approvazione finale del mandato. Se il tuo sviluppatore si comporta diversamente, preparati al fatto che la revisione costerà almeno il doppio.

   Sulla base dell'oggettiva necessità di cambiamenti e ampliamenti- Ho scritto sopra che lo sviluppatore non scompare ed è pronto ad apportare modifiche e integrazioni in base alle tue esigenze in qualsiasi momento. Pertanto, non provare a creare subito il CRM/ERP dei tuoi sogni, non pretendere dal venditore un pulsante "Tutto funziona mentre bevo caffè": lavora nel sistema, identifica i commenti critici per te e inizia a raccogliere requisiti e disegnare sulle specifiche tecniche.

   Puoi scrivere all'infinito su compiti tecnici; questo è un vero generatore non solo di meme e racconti, ma anche di mal di testa. Si può parlare di priorità e regole di progettazione, di GOST 1989, che rende disumane le specifiche tecniche, di standard IEEE, che sono un po' migliori, di prototipi e specifiche tecniche che li completano. Ma alla fine vorrei limitarmi ad una, la regola più importante: una specifica tecnica non è una norma di legge, non è GOST e non è un dogma, quindi se puoi migliorarla, migliorala, se puoi semplificare semplificatelo, se potete farlo con garbo e in modo che piaccia a tutti, fatelo. Sono sicuro che dopo questo nessuno ficcherà il naso alle specifiche tecniche e dirà che non è scritto lì. O quasi nessuno.

   Per tutto dicembre offriamo sconti su RegionSoft CRM e su tutto il nostro software. Dal 1 dicembre al 15 dicembre - 15% e condizioni elevate per rate e affitti. Non abbiamo il -70% e il -90%, perché manteniamo il prezzo delle licenze economicamente giustificato e non lo prendiamo dal nulla.

   Bene, se hai bisogno di un sistema CRM (con o senza modifiche), vai a il nostro sito web, si parla molto del CRM, dei suoi vantaggi e di altri software aziendali.

   E sì, siamo sempre alla ricerca di partner pronti a vendere CRM e altri prodotti, modificare e vendere CRM, vendere software e formare utenti. La divisione del reddito è equa e vantaggiosa per il partner. Te lo mostreremo, ti diremo, ti insegneremo. Scrivere a [e-mail protetta]

   Diapositive, diapositive. Fumetti tratti da http://www.modernanalyst.com/ e Pinterest. Se esiste una traduzione migliore, saremo lieti di includerla nel post.

Spesso allego prototipi di pagine in modo che il cliente capisca come sarà il suo sito. Quindi redigo un compito separato per il progettista del layout, con dettagli tecnici e spiegazioni che lo aiuteranno nel suo lavoro.

Quanto più complesso è il compito, tanto più dettagliate dovrebbero essere le specifiche tecniche. Quando ho partecipato a grandi progetti, ho visto specifiche tecniche lunghe 30 pagine.

Guram Sipki, fondatore dello studio digitale Udix Media

Prima di tutto, il cliente ha bisogno delle specifiche tecniche, in modo da capire come sarà il suo sito web e come verranno spesi i soldi. Se qualcosa viene fatto male, può fare riferimento alle specifiche tecniche e chiedere che venga rifatto.

La specifica tecnica viene elaborata dal responsabile del progetto dopo aver comunicato con il cliente e aver discusso l'incarico con il progettista.

Spesso i grandi clienti richiedono specifiche tecniche molto dettagliate, che descrivano ogni pulsante. Le piccole aziende, al contrario, non amano i documenti meticolosi di 100 pagine.

Un esempio di attività tecnica per il miglioramento del sito web

informazioni generali

Nome dell'automazione

"AS Sbyt"

Cliente

Esecutore

Base per il lavoro

Date previste per l'inizio e la fine dei lavori sulla creazione del sistema

Inizio lavori: 01.09.2010

Fine lavori: 31/12/2010

Scopo e obiettivi della creazione del sistema

Scopo del sistema

In fase di sviluppo sistema automatizzato progettato per automatizzare i processi di vendita aziendali.

Obiettivi della creazione del sistema

Obiettivi della creazione di un sistema automatizzato

Gli obiettivi dello sviluppo di "AS Sbyt" sono:

1. 3. Caratteristiche dell'oggetto di automazione

3.1 Processi aziendali aziendali

3.1. 1 Processo aziendale “Conclusione di un accordo”

Diventerà il tuo scudo; in questo documento, se dovesse succedere qualcosa, potrai puntare il dito contro uno sviluppatore senza scrupoli e pretendere che il tuo sito venga messo a norma.

Compito tecnico(in breve, “TOR”) è un documento che riflette i requisiti per il tuo futuro sito web nel modo più dettagliato e inequivocabile possibile.

Il sito web viene realizzato proprio sulla base delle specifiche tecniche. Più sarà dettagliato e inequivocabile, più il tuo nuovo sito soddisferà le tue aspettative.

I termini di riferimento per la creazione di un sito web - come legge, non dovrebbero consentire interpretazioni e discrepanze.

Lo sviluppatore fa tutto ciò che non è specificato nelle specifiche tecniche a sua discrezione.

· Guida dell'amministratore;

· Guida alla gestione dei contenuti;

· Guida d'installazione;

· Guida del programmatore.

2.20. Organizzazione e conduzione di corsi di formazione per specialisti del comitato investigativo presso la Procura della Federazione Russa

Si applicano i seguenti requisiti formativi:

· L'appaltatore deve organizzare la formazione per i dipendenti della commissione investigativa presso l'ufficio del pubblico ministero Federazione Russa composto da non più di 10 persone.

· La formazione deve essere condotta in russo.

· I locali per la formazione sono forniti dal Cliente.

· Il luogo e l'orario del corso dovranno essere concordati con il Cliente.

La formazione deve essere condotta su tutte le funzionalità del Sistema.

Nell'ambito della formazione è necessario realizzare il contenuto informativo di un sito pilota dell'Anello dei siti del comitato investigativo presso la Procura della Federazione Russa.

3.

Specifiche tecniche di esempio per il miglioramento del sito web

Importante

Durante il processo di implementazione, l'Appaltatore deve fornire assistenza al Cliente nell'ambito del Programma di implementazione.

6.1.11. In caso di scarsa preparazione del personale del Cliente per l'implementazione e di necessità di ulteriore assistenza da parte del Contraente per la corretta implementazione del software, dovrà essere redatto un protocollo aggiuntivo per concordare i prezzi contrattuali per la fornitura di informazioni e attività di consulenza.

6.2 La procedura per l'ulteriore supporto dei compiti AS “SALES”.

Il TOR deve indicare la complessità e il costo del lavoro per implementare requisiti aggiuntivi.

6.2.2. Il Contraente si impegna a mantenere una hotline telefonica per il supporto software.

Aspetti dell'interazione Prima di iniziare ad analizzare il processo di creazione di una specifica tecnica, parliamo del quadrilatero in cui si trovano l'appaltatore e il cliente quando iniziano il progetto. Requisiti- il comportamento desiderato del sistema, descritto dal cliente o dal titolare del processo, da implementare. Di norma, i requisiti vengono formati sulla base dell'esperienza lavorativa e della comprensione del comportamento corretto del programma.

Queste sono informazioni chiave per lo sviluppatore (fornitore), tuttavia, è nella fase di raccolta dei requisiti che si verifica il maggior numero di collisioni, errori, richieste non necessarie, ecc.

Risorse- persone, macchine, attrezzature, ambiente di sviluppo, tempo e denaro che devono essere utilizzati nel processo di implementazione dei requisiti. Le risorse richiedono una pianificazione e una valutazione chiare nella fase di approvazione delle specifiche tecniche.

Ciò può includere requisiti per vari tipi di funzionalità di ordinamento, integrazione della chat e telefonia.

Livello di servizio- infatti, i requisiti di questo livello dovrebbero essere i primi ad essere inclusi nelle nuove build con correzioni. Si tratta di attività relative alla velocità di risposta del sistema, al funzionamento in condizioni di carico elevato e alla sicurezza.

Attenzione

Idealmente, il fornitore non dovrebbe apportare tali modifiche: il software aziendale non dovrebbe rallentare, perdere dati, comprimere moduli e distribuire i diritti di accesso allo stesso livello. Ma se si presenta un requisito che non è legato alla paranoia personale del cliente o a problemi hardware, vale la pena prestargli maggiore attenzione.

Livello tecnologico- ultimo della lista, ma davanti agli altri per importanza e complessità.

Microsoft World o Microsoft Excel.

Personalmente utilizziamo prodotti software speciali quando sviluppiamo una landing page.

Con il loro aiuto, puoi creare rapidamente e facilmente progetti anche per siti complessi, ad esempio Balsamiq. Tuttavia, il modo in cui realizziamo l'intero prototipo è già stato descritto nell'articolo.

Sul tema: Prototipazione di siti web: creazione, strumenti e programmi.

La progettazione preliminare del progetto può essere eseguita insieme allo sviluppatore o trasferita completamente alle sue spalle.
La cosa principale, non dimenticarlo, è concordata e firmata da entrambe le parti.

TRUCCHI PER DISEGNARE TOR

Questi punti valgono sia per la compilazione del brief che per la stesura delle specifiche tecniche.

E in essi ti racconterò piccoli trucchi su come stilare le specifiche tecniche di un sito web e rendere più semplice la già difficile vita di un imprenditore:

1.

Assicurati che il cliente e l’esecutore si capiscano correttamente.”

I termini di riferimento non devono contenere aggettivi di qualità: bello, affidabile, moderno. Non possono essere compresi chiaramente. Ognuno ha i propri concetti di bellezza e modernità.

Aspetto. Qualcuno ha pensato che questo design fosse bellissimo e ne ha permesso l'utilizzo sul proprio sito web:

La stessa cosa accade con formulazioni vaghe che di per sé non significano nulla:

• Il sito deve piacere al cliente. E se è di cattivo umore?
• Il sito dovrebbe essere conveniente. Cosa significa? Conveniente per cosa?
• Il sito deve resistere a carichi pesanti. 10mila visitatori? O 10 milioni?
• Contenuti esperti di alta qualità. Bene, hai capito.

Verificare la presenza di ambiguità nel testo. Se c'è, riscrivilo.

Hai deciso di ordinare un sito web (aka landing page)? Come dimostra la pratica, non è così semplice. Centinaia di clienti, dopo aver visto il loro sito web finito, scoprono che non è adatto a loro: il design è sbagliato, il layout è scadente, i testi sono sbagliati, sono state aggiunte un sacco di funzioni non necessarie.

Per evitare tali conseguenze, sono necessarie specifiche tecniche per lo sviluppo del sito web.

NE HO BISOGNO?!

Non importa chi gestirà il sito: tu, un tuo parente, liberi professionisti per una paga modesta, un'azienda specializzata per un'enorme quantità di denaro...

Devono esserci specifiche tecniche per il sito.

Ad esempio, puoi chiedere di creare un report personalizzato per RegionSoft CRM oppure puoi ordinare l'integrazione con il sito. Si tratta di compiti con scadenze completamente diverse, qui la priorità è molto importante: dopo che i requisiti sono stati raccolti, analizzati e concordati con i dipendenti e la direzione, si può iniziare a creare una specifica tecnica.
Puoi chiedere il modulo al fornitore o crearlo tu stesso: in ogni caso, ci sono diverse regole ferree, la cui osservanza salverà grattacapi a te e al tuo fornitore CRM.

Anatomia di una specifica tecnica

Se parliamo del processo di creazione di una specifica tecnica, ci sono diverse fasi. Il loro passaggio sequenziale porta il cliente al miglioramento desiderato.
Eccoli.

Qui è importante ascoltare l'opinione del venditore, poiché sa esattamente quanto tempo verrà dedicato a questo o quel compito. Credimi, non è vantaggioso per uno sviluppatore perdere tempo e aumentare le scadenze: è vantaggioso per lui completare quanti più progetti possibile e farlo bene, per non subire un duro colpo alla sua reputazione.

Per quanto riguarda il realismo, evitare richieste di aggiornamento del CRM al livello di un sistema di gestione dei collisori è semplice: dovresti includere nei requisiti ciò che è realmente necessario al momento e nel prossimo futuro.

Ad esempio, RegionSoft CRM è un programma desktop; non abbiamo un client browser. Chiederci di creare un'applicazione web per un'azienda è inutile, questo è uno sviluppo importante, è attualmente in corso e non è uno sviluppo possibile per un'azienda.

Nomi completi e brevi del sistema informativo

Il nome completo del sistema è il sito web ufficiale del comitato investigativo della Procura della Federazione Russa.

Il nome breve del sistema è “SKP Site”, “System”, “Site”.

1.2. Nome del cliente dell'impianto e suoi dati

Nome: comitato investigativo della Procura della Federazione Russa

Posizione:

Informazioni

Mosca, vicolo Tekhnicheskiy, edificio 2

Indirizzo attuale: A

Persona di contatto del cliente:

Telefono: (4, (4;

Indirizzo e-mail

1.3. Elenco dei documenti sulla base dei quali viene creato il Sistema

Contratto statale n.________________ del ___ ___________ 2010

1.4.

Determinato in conformità con l'accordo.

2. Requisiti di sistema

2.1.

data di pagamento

Numero di pagamento

Numero di pagamento nel sistema di pagamento

Ammontare del pagamento

1. Seleziona le righe del file di trasferimento dati
2. Inizia a scorrere le righe del file di trasferimento dati
3. Leggi la riga del file di trasferimento dati
4. Ottieni il codice contratto dalla riga del file di trasferimento dati
5. Trovare l'elemento corrispondente per codice nella directory “Accordi della controparte”; se l'elemento non viene trovato, visualizzare il messaggio “Accordo con il codice non trovato...”
6. Se l'elemento viene trovato, aggiungi una riga alla tabella dei valori, dove: "Accordo" è l'elemento trovato, "Data" è "Data_plat", "Numero pagamento" è "Nomer_plat", "Importo" è "Summa_plat"
7. Dopo aver ricevuto l'ultima riga del file di trasferimento dati, terminare il ciclo
8. Per ogni riga della tabella valori creare un documento “Ordine di pagamento per ricezione fondi”.

Quando compili un brief o stabilisci i termini di riferimento per la progettazione di un sito web, non lasciare spazi vuoti.

Devi capire che "A discrezione dello sviluppatore" significa "Faccio quello che voglio" o "Tutto ciò che non è specificato viene fatto a discrezione dell'esecutore". E credimi, questa non è solo una scappatoia, ma un'intera finestra sull'Europa per lo sviluppatore.

E ovviamente questo non sempre accade.

Se incontri uno specialista competente, non devi preoccuparti del risultato.

Ma qui sorge un altro problema: in realtà può farlo bene, ma a te non piacerà in modo puramente soggettivo. E tutto sarà come nello scherzo noto a molti sviluppatori:

BREVEMENTE SULLE COSE PRINCIPALI

Sicuramente non rimpiangerai il tempo speso per elaborare e concordare i termini di riferimento per la creazione di un sito web o di una landing page.

Dopotutto, questo è lo strumento migliore per monitorare e risolvere i disaccordi che sorgono nel processo.

Quando fai clic su un distretto particolare, dovresti andare a una pagina con una descrizione testuale di quel distretto.

· Blocca “Blog del Presidente”- dovrebbe essere un elenco dei tre argomenti più recenti creati sul blog sotto forma di titolo dell'argomento e data della sua pubblicazione. Il nome dell'argomento sarà un collegamento che, una volta cliccato, dovrebbe portarti a una pagina del blog che descrive questo argomento. Questo blocco dovrebbe contenere anche un video che può essere riprodotto senza uscire pagina iniziale. Il video dovrebbe avere un collegamento "Commenti", che rappresenta il numero di commenti sull'immagine video specificata. Il collegamento "Commenti" dovrebbe portare a una pagina del blog con commenti sul video inviato.

Il piè di pagina dovrebbe contenere una casella di ricerca, informazioni sul copyright, ecc.

2.3.

Breveè un questionario con domande su contenuto, design, capacità tecniche Il tuo futuro sito web.

Naturalmente, un documento dettagliato firmato da entrambe le parti può sostituire il mandato.

Dopotutto, è praticamente la stessa cosa, l'unica differenza è che il brief è la tua visione, e le specifiche tecniche sono il documento finale basato sul tuo brief e sui commenti dello sviluppatore stesso.

Se alcuni punti causano difficoltà, non esitare a porre domande allo sviluppatore come "Cosa significa?", "In che modo ciò influirà sul funzionamento del mio sito?", poiché non tutti gli sviluppatori capiscono la tua stessa cosa.

O nella colonna “ Informazioni aggiuntive“Assicurati di indicare tutti i tuoi desideri che non sono stati inclusi nelle risposte alle domande.

Se questa colonna manca, aggiungila semplicemente alla fine del brief.

VK, Google, Facebook.

3.2.2 V account personale nella sezione ordini, aggiungi un campo per aggiungere un codice promozionale.

3.2.3 Invece della pagina che l'utente riceve dopo una richiesta di recupero della password (come name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), crea una pagina (come name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), che visualizzerà il contenuto del sito, avrà il campo "E-mail al momento della registrazione", una riga di controllo, una nuova password, una conferma della password e un pulsante per l'invio dei dati.

3.2.4 Quando si aggiungono articoli al carrello, dovrebbe essere visualizzato un messaggio che indica che l'articolo è stato aggiunto al carrello.

3.2.5 Aggiungere un messaggio di output che indica che la password non corrisponde ai parametri di sicurezza quando si registra un nuovo utente.

"_" ______________ 2010

A poco a poco, le modifiche sono state incluse nel rilascio e in seguito hanno permesso di creare un nuovo prodotto per negozi all'ingrosso, al dettaglio e ipermercati: RegionSoft Retail.

Livello utente o gruppo utenti. A questo livello vengono implementate le attività per perfezionare l'interfaccia esistente. Ad esempio, un utente potrebbe desiderare che venga visualizzata una finestra con il numero e lo stato dell'ultimo ordine quando si passa il mouse sopra un cliente o un report personalizzato con uno speciale raggruppamento di dati.

Le rielaborazioni a questo livello richiedono meno tempo, ma possono essercene molte, ad esempio diversi requisiti da parte dei dipartimenti di marketing, logistica e supporto tecnico.

Livello di funzionalità. Spesso è difficile separarlo dal precedente, qui funziona un criterio formale: il miglioramento non è al livello di visualizzazione di qualcosa nell'interfaccia, ma al livello di finalizzazione della logica del sistema.

Se dice porridge, forse dovresti scappare e non voltarti indietro.

• Assicuratevi contro la disonestà dell'esecutore. Quando il sito è pronto, può essere controllato secondo le specifiche tecniche. Ci sono incongruenze? Lo sviluppatore è obbligato a risolverli. Se collabori ufficialmente e hai stipulato un accordo, puoi anche forzarlo attraverso i tribunali.
• Semplificare la sostituzione degli artisti. Se il cliente e lo sviluppatore litigavano e scappavano, la creazione del sito può richiedere molto tempo. Quando sono presenti specifiche tecniche dettagliate, queste possono essere trasferite a un nuovo team: saranno coinvolti nel lavoro molto più velocemente.
• Scopri il costo dello sviluppo di un prodotto complesso.È impossibile stimare immediatamente i tempi e i costi esatti per lo sviluppo di un servizio web complesso. Per prima cosa devi capire come funzionerà il servizio e quali funzioni avrà.

C'è l'accesso root, i tuoi indirizzi IP, porte, regole di filtraggio e tabelle di routing.

Google PageSpeed ​​Insights lo è servizio gratuito raccomandazioni per i siti web per velocizzare la visualizzazione delle pagine nel browser dell'utente (https://developers.google.com/speed/pagespeed/insights/).

L’ottimizzazione per i motori di ricerca (o SEO) è un insieme di misure di ottimizzazione interna ed esterna per aumentare la posizione del sito nei risultati dei motori di ricerca per specifiche richieste degli utenti.

L'ottimizzazione del sito web esterno è la registrazione di un sito web in motori di ricerca, promozione nel nei social network, link building attirando link da altre risorse al sito promosso, banner pubblicitari, pubblicità contestuale.

L'ottimizzazione del sito interno è l'ottimizzazione del testo, degli URL, la modifica della struttura del sito, il collegamento, il controllo delle risposte del server.

Materiali disponibili Collegamenti ai tuoi siti preferiti, nonché opuscoli, riviste, fotografie - qualunque cosa, o forse hai un libro di marca già pronto. Allegato come archivio separato. Risoluzione minima e dispositivi di visualizzazione In questo paragrafo indicare da quali dispositivi si intende visualizzare il sito: PC, laptop, smartphone... Monitor PC da 19 a 27 pollici; Laptop da 15,6 a 17,3 pollici; Smartphone da 3,5 a 6 pollici; I tablet da 7 a 12 pollici mi servono versione mobile? Sì REQUISITI FUNZIONALI Insieme approssimativo di moduli (per gli utenti) Questa sezione dovrebbe elencarli tutti funzionalità, che desideri vedere sul sito.

Potrebbe trattarsi di un carrello della spesa, filtri del catalogo basati su vari parametri, la possibilità di effettuare un ordine online, lasciare una richiesta richiamata, iscrizione alla newsletter ed eventuali altre opzioni Il catalogo filtra per prezzo, in ordine alfabetico, per produttore.
CRUпtcj9b: s »xvzhb╟▌╤└u╟j_ ■ e╘dj» j ■ ╛eхhjя (gtt┬pb╟▌╤└u╟╛#╜┘al+ka kqяk3┴i≈###┐╜╙ ┐╜╙ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜ ┘al+kaxg [b: bvzhb╟▌╤└u╟╛#╜│ts & v█7┬m3aqnyjy╕ ° vzhb╟▌╤└u╟╛#╜┘al+kaxg [b: bvzhb╟▌╤└u╟ ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╒▀┬y╥XuF ≈≈K&ОQТе╦▒'%[н╓≥Lк"[Ц(b╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NлkZ ⌡ ┐ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх═с┬├6ыСыиЪ╖Bl╢╡ LeOь/РЯE∙rrм VC ╪ ┬ 7┴+iSo(╦°rБ╒┴***E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s_2╫J)E+H © OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Ricordi la legge di Murphy? Se puoi essere frainteso, sarai sicuramente frainteso. Questo è vero non solo nella comunicazione tra le persone, ma anche nella creazione di siti web. Il cliente voleva un secondo Facebook, ma ha ottenuto un forum per giovani allevatori di cani. Lo sviluppatore non ha indovinato cosa volesse il cliente: ha perso tempo.

In questa guida ti dirò cosa e perché devi scrivere nei termini di riferimento. Allo stesso tempo, ti mostrerò come non scrivere affinché la creazione delle specifiche tecniche non si trasformi in tempo perso.

L'articolo sarà utile:

• Per tutti coloro che sono coinvolti nella creazione di siti web: sviluppatori, designer, progettisti di layout.
• Capi progetto.
• Responsabili degli studi digitali.
• Imprenditori che intendono ordinare lo sviluppo di un sito web.

Per rendere utile il materiale, ho raccolto commenti di diversi sviluppatori, designer, project manager e proprietari di studi digitali. Ho aggiunto quelli più preziosi alla fine dell'articolo. Andiamo a scoprirlo.

Cos’è una specifica tecnica e perché è necessaria?

Una specifica tecnica è un documento che stabilisce i requisiti per il sito. Quanto più chiari e dettagliati saranno questi requisiti, tanto meglio tutti i partecipanti al processo capiranno come dovrebbe essere. Ciò significa che aumenta la possibilità che tutti siano soddisfatti del risultato.

L'obiettivo principale delle specifiche tecniche è garantire che il cliente e l'appaltatore si capiscano correttamente.

I vantaggi derivanti dalle specifiche tecniche sono numerosi. È diverso per ogni lato.

Vantaggi per il cliente:

• Comprendi per cosa paga e come sarà il sito. Potrai subito vedere la struttura, capire cosa funzionerà e come. Scopri se tutto ti va bene. In caso contrario, non è un problema modificarlo prima dell’inizio dello sviluppo.
• Vedere la competenza dell'esecutore. Se i termini di riferimento sono chiari e precisi, aumenta la fiducia nel promotore. Se dice porridge, forse dovresti scappare e non voltarti indietro.
• Assicuratevi contro la disonestà dell'esecutore. Quando il sito è pronto, può essere controllato secondo le specifiche tecniche. Ci sono incongruenze? Lo sviluppatore è obbligato a risolverli. Se collabori ufficialmente e hai stipulato un accordo, puoi anche forzarlo attraverso i tribunali.
• Semplificare la sostituzione degli artisti. Se il cliente e lo sviluppatore litigavano e scappavano, la creazione del sito può richiedere molto tempo. Quando sono presenti specifiche tecniche dettagliate, queste possono essere trasferite a un nuovo team: saranno coinvolti nel lavoro molto più velocemente.
• Scopri il costo dello sviluppo di un prodotto complesso.È impossibile stimare immediatamente i tempi e i costi esatti per lo sviluppo di un servizio web complesso. Per prima cosa devi capire come funzionerà il servizio e quali funzioni avrà. Per questo è necessario preparare le specifiche tecniche.

Benefici per l'esecutore:

• Capire cosa vuole il cliente. Al cliente vengono poste decine di domande, mostrati esempi e offerte soluzioni. Quindi scrivono tutto in un unico documento e lo concordano. Se va tutto bene, evviva, hai capito bene.
• Assicuratevi contro i desideri improvvisi del cliente. A volte ti imbatti in clienti che vogliono cambiare l'attività a metà. Se hai concordato e firmato i termini di riferimento, non ne hai paura. Se succede qualcosa, anche il tribunale sarà dalla tua parte.
• Mostra la tua competenza. Una specifica tecnica ben preparata mostrerà al cliente la competenza degli sviluppatori. Se l'azienda dubitava di fidarsi di te per lo sviluppo del sito web, molto probabilmente i dubbi verranno dissipati.
• Guadagnare soldi. Alcuni studi e sviluppatori offrono la preparazione delle specifiche tecniche come servizio separato.

• Facilitare e accelerare il processo di sviluppo. Una buona specifica tecnica indica la struttura del sito, le funzioni e gli elementi necessari in ogni pagina. Quando tutti i requisiti sono già davanti ai tuoi occhi, non resta che progettare e scrivere il codice.

Ora vediamo come creare una buona specifica tecnica che svolga tutte queste funzioni.

Il mandato è redatto dall'esecutore

In generale, chiunque può redigere specifiche tecniche. "Abbiamo bisogno di un sito Web per biglietti da visita per una clinica odontoiatrica": questo è già un compito tecnico. Ma svolgerà le sue funzioni? Difficilmente.

Una buona specifica tecnica viene sempre preparata dall'esecutore: un project manager o uno sviluppatore. Ovviamente, uno sviluppatore web ne sa di più sulla creazione di siti Web rispetto al proprietario di un bar o di una clinica dentistica. Dovrà quindi descrivere il progetto.

Ciò non significa che il cliente sparisca e alla fine compaia per scrivere: “Zbs, approvo”. Dovrebbe anche partecipare al processo:

Naturalmente il cliente può abbozzare la propria versione delle specifiche tecniche. Forse questo accelererà il processo di creazione delle specifiche tecniche finali. O forse il risultato sarà spazzatura che verrà gettata segretamente nella spazzatura.

Scrivi in ​​modo chiaro e accurato

Questo consiglio deriva dall'obiettivo principale dei termini di riferimento: "Assicurarsi che il cliente e l'appaltatore si capiscano correttamente".

I termini di riferimento non devono contenere aggettivi di qualità: bello, affidabile, moderno. Non possono essere compresi chiaramente. Ognuno ha i propri concetti di bellezza e modernità.

Aspetto. Qualcuno ha pensato che questo design fosse bellissimo e ne ha permesso l'utilizzo sul proprio sito web:

La stessa cosa accade con formulazioni vaghe che di per sé non significano nulla:

• Il sito deve piacere al cliente. E se è di cattivo umore?
• Il sito dovrebbe essere conveniente. Cosa significa? Conveniente per cosa?
• Il sito deve resistere a carichi pesanti. 10mila visitatori? O 10 milioni?
• Contenuti esperti di alta qualità. Bene, hai capito.

Verificare la presenza di ambiguità nel testo. Se c'è, riscrivilo. La tua formulazione dovrebbe essere chiara e precisa:

• Il sito deve caricarsi rapidamente → Qualsiasi pagina del sito deve avere più di 80 punti in Google PageSpeed ​​Insights.
• Carichi pesanti → 50mila visitatori in contemporanea.
• La pagina principale visualizza un elenco di articoli → Nella pagina principale viene visualizzato l'elenco degli ultimi 6 articoli pubblicati.
• Interfaccia di iscrizione minimalista e intuitiva → Campo “Lascia la tua e-mail” e pulsante “Iscriviti” → *schizzo disegnato*.

Abbiamo sistemato la formulazione, passiamo alla struttura.

Si prega di fornire informazioni generali

Tutti i membri del team devono comprendere correttamente cosa fa l'azienda e chi è il suo pubblico di riferimento. Affinché nessuno si confonda, è meglio scriverlo all'inizio del mandato.

Vale anche la pena indicare lo scopo del sito e descriverne in poche parole le funzionalità, per non ritrovarsi con un negozio online invece di un blog.

Spiega i termini difficili

La prima regola del mandato è che deve essere comprensibile a tutti i destinatari. Se intendi utilizzare termini che il tuo cliente, il proprietario di un negozio di giocattoli per bambini, potrebbe non capire, assicurati di spiegarli. In un linguaggio chiaro, non copia-incolla da Wikipedia.

Descrivere gli strumenti e i requisiti di hosting

Immagina di aver trascorso 2 mesi a creare un sito Web interessante. Ogni fase è stata coordinata con il cliente: era felice. E ora è il momento di consegnare il lavoro. Mostri il pannello di amministrazione e il cliente grida: “Cos'è questo? Modex?! Pensavo che l’avresti fatto su WordPress!”

Per evitare tali problemi, descrivere gli strumenti, i motori e le librerie utilizzate. Allo stesso tempo, indica i tuoi requisiti di hosting. Non si sa mai, lo farai in PHP e il client ha un server in .NET.

Elencare i requisiti per il funzionamento del sito

Il sito deve funzionare in tutti i browser attuali e su tutti i tipi di dispositivi. Sì, questo è ovvio per qualsiasi sviluppatore e cliente. Ma meglio scrivere per tutelare il cliente da un lavoro svolto in malafede.

Scrivi qui i requisiti relativi alla velocità di caricamento del sito, alla resistenza al carico, alla protezione dagli attacchi degli hacker e cose simili.

Specificare la struttura del sito

Prima di iniziare a disegnare il design e il layout, è necessario concordare con il cliente la struttura del sito.

Parla con il cliente e scopri di cosa ha bisogno. Riunisci sviluppatori, specialisti SEO, esperti di marketing, redattori capo e decidi quali pagine sono necessarie sul sito. Pensa a come saranno collegati tra loro, da quale potrai passare.

Puoi mostrare la struttura con un elenco, puoi disegnare uno schema a blocchi. Come preferisci.

Questa è una delle fasi più importanti del lavoro sul sito. La struttura è il fondamento. Se non ha successo, il sito risulterà storto.

Spiega cosa ci sarà in ogni pagina

Il cliente deve capire perché è necessaria ogni pagina e quali elementi saranno presenti su di essa. Ci sono due modi per dimostrarlo.

Prototipo- un modo più visivo e inequivocabile. Il contraente disegna schizzi di ciascuna pagina e li allega al capitolato d'oneri. Il cliente vede come sarà l'interfaccia del suo futuro sito web e dice cosa gli piace e cosa deve essere cambiato.

Enumerazione degli elementi- un'alternativa pigra al prototipo. Basta scrivere quali blocchi dovrebbero essere sulla pagina e cosa fanno.

Descrivere gli scenari di utilizzo del sito

Se stai creando una sorta di interfaccia non standard, mostrare solo la struttura e le miniature delle pagine non è sufficiente. È importante che l'intero team di esecuzione e il cliente comprendano come i visitatori utilizzeranno il sito. Gli script sono ottimi per questo. Il diagramma dello scenario è molto semplice:

• Azione dell'utente.
• Risposta del sito.
• Risultato.

Naturalmente, se stai creando un biglietto da visita o una pagina di destinazione standard, non è necessario scrivere script. Ma se sul sito sono presenti alcuni servizi interattivi, questo è molto desiderabile.

Maggiori informazioni sui casi d'uso su Wikipedia.

Determina chi è responsabile del contenuto

Alcuni sviluppatori creano subito un sito Web con contenuti. Altri mettono il pesce. Altri ancora possono scrivere testi, ma a un costo aggiuntivo. Concordatelo a terra e annotate nei termini di riferimento quali contenuti dovreste preparare.

È abbastanza difficile trovare criteri oggettivi per valutare la qualità dei testi. È meglio non scrivere altro che "Contenuti di alta qualità, interessanti e di vendita, utili per il pubblico di destinazione". È spazzatura, nessuno ne ha bisogno.

È utile specificare che tutto il contenuto deve essere univoco. Un'altra protezione per il cliente da artisti senza scrupoli.

Descrivi il design (se puoi)

Come per il testo, è difficile trovare criteri oggettivi per valutare il design di un sito web. Se tu e il cliente avete concordato una combinazione di colori, scrivetela. Se ha un brand book in cui sono specificati i font, indicali anche.

Non è necessario scrivere di design bello e moderno. Non significa niente, non ha potere e generalmente uff.

Invece di una conclusione: la struttura dei termini di riferimento

La struttura delle specifiche tecniche sarà diversa per i diversi compiti. È stupido creare le stesse specifiche tecniche per un nuovo social network e una landing page per la vendita all’ingrosso di carote. Ma in generale hai bisogno di queste sezioni:

• Informazioni sull'azienda e sul pubblico target, scopi e obiettivi del sito.
• Un glossario di termini che potrebbero non essere chiari al cliente.
• Requisiti tecnici per il layout e il funzionamento del sito.
• Descrizione delle tecnologie utilizzate e elenco dei requisiti di hosting.
• Struttura dettagliata del sito.
• Prototipi di pagine o descrizioni di elementi che dovrebbero essere presenti su di esse.
• Scenari per l'utilizzo di un'interfaccia non standard (opzionale).
• Elenco dei contenuti realizzati dallo sviluppatore.
• Requisiti di progettazione (facoltativo).

• Regole per la compilazione della Specifica dei Requisiti Software. SRS è il passo successivo nell'evoluzione delle specifiche tecniche. Necessario per progetti grandi e complessi.
• Standard e modelli di specifiche tecniche per lo sviluppo del software. Descrizioni di vari GOST e metodologie per la creazione di specifiche tecniche.

Questa è la fine della parte che ho scritto. Ma ce n'è un altro: i commenti degli specialisti che hanno contribuito alla realizzazione della guida. Leggilo, è anche interessante.

Commenti degli sviluppatori

Ho parlato con diversi sviluppatori per scoprire come creano le specifiche tecniche. Passo loro il microfono.

Prima di tutto, il cliente ha bisogno delle specifiche tecniche, in modo da capire come sarà il suo sito web e come verranno spesi i soldi. Se qualcosa viene fatto male, può fare riferimento alle specifiche tecniche e chiedere che venga rifatto.

La specifica tecnica viene elaborata dal responsabile del progetto dopo aver comunicato con il cliente e aver discusso l'incarico con il progettista.

Spesso i grandi clienti richiedono specifiche tecniche molto dettagliate, che descrivano ogni pulsante. Le piccole aziende, al contrario, non amano i documenti meticolosi di 100 pagine. È una lettura lunga ed è facile perdere qualcosa di importante. Più spesso formuliamo specifiche tecniche concise di 10-15 pagine.

Indichiamo:

• Informazioni sull'azienda e sullo scopo del sito.
• Requisiti per il design, combinazione di colori.
• Tecnologie e CMS utilizzati.
• Chi produce il contenuto: noi o il cliente.
• La struttura del sito fino ad ogni pagina.
• Descrizioni di ogni pagina. Non realizziamo prototipi, ma specifichiamo quali elementi dovrebbero essere sulla pagina e come dovrebbero funzionare.

Le ultime 2 sezioni sono le più importanti. Sono loro che forniscono un'idea di come sarà il sito e come funzionerà.

Un punto molto importante: non puoi semplicemente dare termini di riferimento agli sviluppatori e sperare che facciano tutto bene. La specifica tecnica è un elenco di requisiti per il sito; non può sostituire la comunicazione. È importante assicurarsi che ogni membro del team comprenda l'obiettivo generale e non si limiti a svolgere attività al volo. Se qualcosa non è chiaro è necessario spiegare, discutere e fare commenti dettagliati.

Nella vita capita spesso che una persona non riesca a spiegare ciò che vuole, anche nelle cose di tutti i giorni. Quando si tratta di spiegare i propri "desideri" a un programmatore, una persona cade semplicemente in uno stato di torpore.

Idealmente, le specifiche tecniche dovrebbero essere redatte dal cliente: solo lui sa di cosa ha bisogno. Ma in pratica, a causa della scarsa competenza del cliente nel campo 1C, spesso questo compito deve essere svolto dall’appaltatore. Il cliente esprime verbalmente le sue esigenze e il programmatore (consulente) le mette per iscritto.

Perché hai bisogno delle specifiche tecniche?

Qualsiasi, idealmente, dovrebbe essere accompagnato da specifiche tecniche. Si tratta, in primo luogo, di una chiara definizione del compito, delle scadenze e del metodo di attuazione. In secondo luogo, questo è un documento con l'aiuto del quale verranno risolte tutte le questioni controverse in futuro. Scrivere o meno le specifiche tecniche è, ovviamente, affare tuo; per me personalmente le specifiche tecniche facilitano il lavoro e la comunicazione con il cliente.

Ottieni 267 lezioni video su 1C gratuitamente:

Cosa dovrebbero contenere i termini di riferimento?

Quelli. l'incarico deve contenere:

• bersaglio— il problema che risolveremo implementando questa specifica;
• descrizione— una sintesi dei prossimi miglioramenti;
• metodo di implementazione— una descrizione dettagliata dei metodi per risolvere l'obiettivo. A questo punto, è necessario descrivere tutte le sfumature dell'attività nel linguaggio del programmatore: che tipo di attività stiamo creando/modificando, come dovrebbe apparire l'interfaccia, ecc. Se non parli "linguaggio del programmatore", ma "hai sentito qualcosa", è meglio non provare a scrivere in un linguaggio tecnico: risulta essere piuttosto divertente. La descrizione dovrebbe essere inequivocabile e non sollevare domande. Può contenere anche un esempio di implementazione di una soluzione simile in un'altra area;
• valutazione delle prestazioni- un punto molto importante, una descrizione del costo del lavoro.

Esistono anche standard statali per la scrittura delle specifiche tecniche: GOST. In pratica vengono utilizzati raramente, ma a volte il cliente insiste.

Per esperienza, durante la consegna del lavoro, molto spesso si presentano situazioni del tipo “te l'avevamo detto allora...”, il che non è molto piacevole, e spesso bisogna rifare tutto il lavoro. Pertanto, una specifica tecnica ben scritta rende la vita molto più semplice per entrambe le parti.

Esempi ed esempi di specifiche tecniche per 1C

Una piccola selezione che ho trovato liberamente disponibile su Internet. A partire dai documenti più semplici e accessibili fino a quelli piuttosto complessi.