Termeni de referință pentru modernizarea ventilației în institutele de cercetare. Un exemplu de specificații tehnice și specificații tehnice pentru revizuire minoră Opțiuni pentru penalități

Atașez adesea prototipuri de pagini, astfel încât clientul să înțeleagă cum va arăta site-ul său. Apoi compun o sarcină separată pentru designerul de layout - cu detalii tehnice și explicații care vor ajuta în munca lui.

Cu cât sarcina este mai complexă, cu atât TOR ar trebui să fie mai detaliat. Când am participat la proiecte mari, am văzut termenii de referință și 30 de pagini.

Guram Sipki, fondatorul studioului digital Udix Media

În primul rând, clientul are nevoie de TK - pentru a înțelege cum va fi site-ul său și pe ce se cheltuiesc banii. Dacă ceva este greșit, el se poate referi la TK și poate cere să-l refacă.

TOR este întocmit de managerul de proiect după comunicarea cu clientul și discutarea sarcinii cu proiectantul.

Clienții mari solicită adesea specificații foarte detaliate, care descriu fiecare buton. Companiile mici, dimpotrivă, nu le plac documentele meticuloase de 100 de pagini.

Un exemplu de sarcină tehnică pentru finalizarea unui site

Informatii generale

Denumirea sistemului automatizat

„CA Vânzări”

Client

Executor testamentar

Baza muncii

Date programate pentru începerea și finalizarea lucrărilor la crearea sistemului

Început lucrări: 01.09.2010

Finalizare lucrări: 31.12.2010

Scopul și scopurile creării sistemului

Scopul sistemului

Sistemul automatizat în curs de dezvoltare este conceput pentru a automatiza procesele de vânzare ale unei întreprinderi.

Obiectivele creării unui sistem

Obiectivele creării unui sistem automatizat

Obiectivele dezvoltării AS SBYT sunt:

1. 3. Caracteristicile obiectului de automatizare

3.1 Procesele de afaceri ale întreprinderii

3.1. 1 Procesul de afaceri „Încheierea contractului”

Va deveni scutul tău, în acest document tu, caz în care, poți arăta cu degetul către un dezvoltator lipsit de scrupule și poți cere ca site-ul tău să fie adus în conformitate cu acesta.

Sarcina tehnică(pe scurt „TOR”) este un document care reflectă cerințele pentru viitorul dvs. site în modul cel mai detaliat și fără ambiguitate.

Site-ul este creat pe baza TK. Cu cât este mai detaliat și mai clar, cu atât noul dvs. site vă va satisface așteptările.

Termenii de referință pentru crearea site-ului - ca lege, nu ar trebui să permită interpretări și discrepanțe.

Tot ceea ce nu este specificat în TOR, dezvoltatorul face la propria sa discreție.

· Ghidul administratorului;

· Ghid pentru managerul de conținut;

· Ghid de instalare;

· Ghidul programatorului.

2.20. Organizarea și desfășurarea de formare pentru specialiștii Comitetului de anchetă din cadrul Procuraturii Federației Ruse

Se aplică următoarele cerințe de formare:

· Antreprenorul trebuie să desfășoare cursuri de formare pentru angajații Comitetului de anchetă din cadrul Procuraturii Federației Ruse, format din cel mult 10 persoane.

· Formarea ar trebui să se desfășoare în limba rusă.

· Sala de instruire este asigurată de Client.

· Locul și ora instruirii trebuie convenite cu Clientul.

Instruirea ar trebui să fie efectuată pentru toate funcționalitățile sistemului.

Ca parte a instruirii, este necesar să se desfășoare conținutul informativ al unui site pilot al Inelului de site-uri al Comitetului de investigație din cadrul Procuraturii Federației Ruse.

3.

Exemple de termeni de referință pentru dezvoltarea site-ului web

Important

Pe parcursul procesului de implementare, Antreprenorul va oferi asistență Clientului în cadrul Programului de Implementare.

6.1.11. În cazul unei pregătiri slabe a personalului Clientului pentru implementare și al necesității de asistență suplimentară din partea Antreprenorului pentru implementarea cu succes a software-ului, ar trebui întocmit un protocol suplimentar pentru convenirea prețurilor contractuale pentru furnizarea de informații și lucrări de consultanță.

6.2 Procedura pentru sprijinirea ulterioară a sarcinilor AS „VÂNZĂRI”.

După punerea în funcțiune a software-ului, pot fi implementate îmbunătățiri și dorințe suplimentare ale Clientului în conformitate cu TOR convenit cu Clientul.

Termenul de referință ar trebui să indice intensitatea muncii și costul muncii pentru a implementa cerințe suplimentare.

6.2.2. Antreprenorul se obligă să mențină o „linie fierbinte” telefonică pentru întreținerea software-ului.

Fațete ale interacțiunii Înainte de a trece la pregătirea procesului de creare a unei sarcini tehnice, să vorbim despre patrulaterul în care se încadrează antreprenorul și clientul la începerea proiectului. Cerințe- comportamentul dorit al sistemului, așa cum este descris de client sau deținătorul procesului, care urmează să fie implementat. De regulă, cerințele sunt formate pe baza experienței, reprezentarea comportamentului corect al programului.

Aceasta este o informație cheie pentru dezvoltator (vânzător), totuși, în etapa de colectare a cerințelor apar cel mai mare număr de coliziuni, erori, solicitări redundante etc.

Resurse- oameni, mașini, inventar, mediu de dezvoltare, timp și bani pentru a fi utilizați în procesul de implementare a cerințelor. Resursele necesită o planificare și o evaluare clară în etapa de aprobare a termenilor de referință.

Acestea includ cerințe pentru diferite tipuri de sortare, integrare prin chat și capabilități de telefonie.

Nivel de servicii- de fapt, cerințele acestui nivel ar trebui să fie primele care intră în build-uri noi cu remedieri. Acestea sunt sarcini în ceea ce privește viteza de răspuns a sistemului, lucrul sub sarcină mare și securitatea.

Atenţie

În mod ideal, vânzătorul nu ar trebui să aibă astfel de îmbunătățiri - software-ul corporativ nu ar trebui să încetinească, să piardă date, să restrângă formulare și să distribuie drepturi de acces de același nivel. Dar dacă a apărut o cerință și nu are legătură cu paranoia personală a clientului sau cu probleme din partea hardware, merită să-i acordăm o atenție deosebită.

Nivel de tehnologie- ultimul din listă, dar înaintea celorlalți ca importanță și complexitate.

Acestea pot fi cerințe ale clientului legate de platformă, sistem de operare sau dispozitive. De exemplu, o cerere de compilare pentru MacOS.

Microsoft World sau Microsoft Excel.

Personal, atunci când dezvoltăm o pagină de destinație, folosim produse software speciale.

Cu ajutorul lor, puteți crea rapid și ușor chiar și site-uri complexe - acesta este, de exemplu, Balsamiq. Cu toate acestea, modul în care realizăm întregul prototip a fost deja descris în articol.

Pe subiect: Prototiparea site-ului: creație, instrumente și programe.

Proiectarea pre-proiect poate fi realizată împreună cu dezvoltatorul sau mutată complet pe umerii acestuia.
Principalul lucru, nu uitați, apoi acordați-l și semnați-l de ambele părți.

LIFE HACKS PENTRU DEZVOLTAREA TOR

Aceste puncte se aplică în mod egal atât pentru completarea brief-ului, cât și pentru redactarea termenilor de referință.

Și în ele vă voi dezvălui câteva trucuri despre cum să creați o specificație tehnică pentru site și să ușurați viața deja dificilă a unui antreprenor:

1.

Asigurați-vă că clientul și interpretul se înțeleg corect.

Termenii de referință nu trebuie să conțină adjective de înaltă calitate: frumos, de încredere, modern. Ele nu pot fi înțelese clar. Fiecare are propriile concepte despre frumusețe și modernitate.

Uite. La urma urmei, cineva a crezut că acest design este frumos și a permis să fie folosit pe site-ul său web:

Același lucru - cu o formulare neclară care nu înseamnă nimic în sine:

• Site-ul trebuie să fie apreciat de către client. Dacă este într-o dispoziție proastă?
• Site-ul trebuie să fie ușor de utilizat. Ce înseamnă? Convenabil pentru ce?
• Locația trebuie să reziste la sarcini grele. 10 mii de vizitatori? Sau 10 milioane?
• Conținut de experți de calitate. Ei bine, ai înțeles ideea.

Verificați dacă există ambiguități în text. Dacă există - rescrie.

Te-ai decis să comanzi un site web (alias o pagină de destinație)? După cum arată practica, nu este atât de simplu. Sute de clienți, după ce și-au văzut site-ul terminat, constată că nu le convine: designul nu este același, aspectul este șchiopăt, textele lipsesc, au înșurubat o grămadă de funcții inutile.

Pentru a evita astfel de consecințe, aveți nevoie de o sarcină tehnică pentru dezvoltarea site-ului.

AM NEVOIE?!

Nu contează cine va fi executantul site-ului - tu însuți, ruda ta, freelanceri pentru o plată modestă, o companie specializată pentru o sumă imensă de bani...

Termenii de referință pentru site ar trebui să fie.

De exemplu, puteți cere să creați un raport personalizat pentru RegionSoft CRM sau puteți comanda integrarea cu site-ul. Acestea sunt sarcini complet diferite din punct de vedere al timpului, prioritatea este foarte importantă aici După ce cerințele sunt colectate, analizate și convenite cu angajații și managementul, puteți începe să creați termeni de referință.
Puteți fie să cereți formularul vânzătorului, fie să îl creați singur - în orice caz, există câteva reguli absolute care vă vor scuti de o bătaie de cap atât dvs., cât și furnizorului dvs. de CRM.

Anatomia unui termen de referință

Dacă vorbim despre procesul de creare a unei sarcini tehnice, atunci există mai multe etape. Trecerea lor consecventă conduce clientul la îmbunătățirea dorită.
Aici sunt ei.

Aici este important să ascultați părerea vânzătorului, deoarece el știe exact cât timp va dura pentru o anumită sarcină. Crede-mă, nu este profitabil pentru un dezvoltator să joace timp și să încheie termenul - este benefic pentru el să finalizeze cât mai multe proiecte și să o facă bine pentru a nu primi o lovitură la adresa reputației sale.

În ceea ce privește realismul, evitarea solicitărilor de finalizare a CRM la nivelul unui sistem de control al coliderului este simplă: ar trebui să includeți în cerințe ceea ce este cu adevărat necesar în acest moment și în viitorul apropiat.

De exemplu, RegionSoft CRM este un program desktop, nu avem un client de browser. A ne cere să creăm o aplicație web pentru o singură companie este inutil, aceasta este o dezvoltare majoră, este în prezent în curs și nu este o posibilă perfecționare pentru o singură companie.

Denumirea completă și scurtă a sistemului informațional

Numele complet al sistemului este site-ul oficial al Comitetului de anchetă din cadrul Parchetului Federației Ruse.

Numele scurt al sistemului este „Site SKP”, „System”, „Site”.

1.2. Numele clientului sistemului și detaliile acestuia

Nume: Comitetul de anchetă din cadrul Procuraturii Federației Ruse

Locație: dl.

Info

Moscova, banda tehnică, clădirea 2

Adresa reala: A

Persoana de contact a Clientului:

Telefon: (4, (4;

Adresa de e-mail

1.3. Lista documentelor pe baza cărora este creat sistemul

Contract de stat Nr ________________ din data de ___ ___________ 2010

1.4.

Datele planificate de începere și finalizare pentru crearea Sistemului

Determinat în conformitate cu Acordul.

2. Cerințe de sistem

2.1.

Data de plată

Număr de plată

Numărul de plată în sistemul de plată

Suma de plata

1. Selectați Linii de fișier de transfer de date
2. Începeți să faceți bucla prin liniile fișierului de transfer de date
3. Citiți linia fișierului de transfer de date
4. Obțineți codul contractului din rândul fișierului de transfer de date
5. Găsiți elementul corespunzător după cod în directorul „Acorduri ale contrapărților”, dacă elementul nu este găsit, apoi afișați mesajul „Acordul cu codul nu a fost găsit...”
6. Dacă elementul este găsit, adăugați o linie la tabelul de valori, unde: „Acord” - elementul găsit, „Data” - „Data_plat”, „Număr de plată” - „Nomer_plat”, „Suma” - „Summa_plat”
7. După ce ați primit ultima linie a fișierului de transfer de date, terminați bucla
8. Pentru fiecare rând din tabelul de valori, creați un document „Primire ordin de plată a fondurilor”.

Când completați un brief sau compilați o specificație pentru proiectarea site-ului, nu lăsați spații în el.

Trebuie să înțelegeți că „La latitudinea dezvoltatorului” înseamnă „ce vreau, mă întorc” sau „Tot ceea ce nu este specificat se face la discreția interpretului”. Și credeți-mă, aceasta nu este doar o lacună, ci o întreagă fereastră către Europa pentru dezvoltator.

Și, desigur, nu este întotdeauna cazul.

Dacă aveți un specialist competent, atunci nu vă puteți îngrijora de rezultat.

Dar aici apare o altă problemă, el poate face cu adevărat bine, dar nu vă va plăcea pur subiectiv. Și totul va fi ca într-o glumă cunoscută de mulți dezvoltatori:

SCURT DESPRE PRINCIPALA

Cu siguranță nu veți regreta timpul petrecut cu compilarea și acordul asupra termenilor de referință pentru crearea unui site web sau a unei pagini de destinație.

La urma urmei, acesta este cel mai bun instrument al tău pentru controlul și rezolvarea dezacordurilor care apar în acest proces.

Când faceți clic pe un anumit district, acesta ar trebui să acceseze o pagină cu o descriere text a acestui district.

· Blocați „Blogul președintelui”- ar trebui să fie o listă cu ultimele trei subiecte create pe blog sub forma unui nume de subiect și data la care a fost publicată. Titlul subiectului va fi un link, atunci când dați clic, ar trebui să vă duce la pagina blogului cu o descriere a acestui subiect. De asemenea, acest bloc ar trebui să conțină un videoclip care poate fi redat fără a părăsi pagina principală. Videoclipul trebuie să aibă un link „Comentarii”, care este numărul de comentarii la videoclip. Linkul „Comentarii” ar trebui să conducă la o pagină de blog cu comentarii la videoclipul trimis.

Subsolul trebuie să conțină un câmp de căutare, informații despre drepturile de autor etc.

2.3.

scurt- acesta este un chestionar cu întrebări despre conținutul, designul, capacitățile tehnice ale viitorului tău site.

Desigur, un brief detaliat, semnat de ambele părți, poate înlocui termenii de referință.

La urma urmei, acesta este practic același, singura diferență este că brief-ul este viziunea ta, iar termenii de referință sunt documentul final bazat pe brief-ul tău și pe comentariile dezvoltatorului în sine.

Dacă anumite puncte provoacă dificultăți, atunci nu ezitați să adresați dezvoltatorului întrebări precum „Ce înseamnă asta?”, „Cum va afecta acest lucru funcționarea site-ului meu?”, Deoarece nu toți dezvoltatorii înțeleg același lucru ca și dvs.

Sau, în coloana „Informații suplimentare”, asigurați-vă că indicați toate dorințele dvs. care nu au fost incluse în răspunsurile la întrebări.

Dacă această coloană lipsește, adăugați-le la sfârșitul briefului.

VK, Google, Facebook.

3.2.2 În contul personal, în secțiunea comenzi, adăugați un câmp pentru adăugarea unui cod promoțional.

3.2.3 În locul paginii care vine utilizatorului după o solicitare de recuperare a parolei (de forma nume.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), creați o pagină (cu numele formularului. com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), care va afișa conținutul site-ului, va avea câmpul „E-mail în timpul înregistrării”, un șir de control, o nouă parolă, o confirmare a parolei, un buton pentru trimiterea datelor .

3.2.4 Când adăugați articole în coș, ar trebui să fie afișat un mesaj care să arate că articolul a fost adăugat în coș.

3.2.5 Adăugați un mesaj că parola nu se potrivește cu setările de securitate atunci când înregistrați un utilizator nou.

automatizateSistemul de VÂNZARE.Sarcina tehnică Pe foi Valabil de la „__” ____________ 2010

» _» ______________ 2010

Treptat, modificările au fost incluse în lansare, iar ulterior au permis crearea unui nou produs pentru magazine cu ridicata, cu amănuntul și hipermarketuri - RegionSoft Retail.

Nivel de utilizator sau grup de utilizatori. La acest nivel, sunt implementate sarcini pentru a rafina interfața existentă. De exemplu, un utilizator poate dori o fereastră cu numărul și starea ultimei comenzi să apară atunci când trece cu mouse-ul peste un client sau un raport personalizat cu o grupare specială de date.

Îmbunătățirile la acest nivel necesită mai puțin timp, dar pot fi multe - de exemplu, mai multe cerințe de la departamentele de marketing, logistică și suport tehnic.

nivelul de funcționalitate. De multe ori este dificil să-l separăm de cel precedent, aici funcționează un criteriu formal - rafinamentul nu este la nivelul afișării a ceva în interfață, ci la nivelul rafinamentului logicii sistemului.

Dacă acolo scrie terci, ar putea merita să alergi și să nu te uiți înapoi.

• Pentru a se asigura împotriva necinstei interpretului. Când site-ul este gata, acesta poate fi verificat conform termenilor de referință. Există neconcordanțe? Dezvoltatorul trebuie să le repare. Dacă cooperezi oficial și ai încheiat un acord, poți chiar să fii forțat prin instanțe.
• Simplificați înlocuirea interpreților. Dacă clientul și dezvoltatorul s-au certat și au fugit, crearea site-ului poate dura mult timp. Când există un termen de referință detaliat, acesta poate fi transferat unei noi echipe - se va implica în muncă de multe ori mai repede.
• Aflați costul dezvoltării unui produs complex. Este imposibil de estimat momentul exact și costul dezvoltării unui serviciu web complex imediat. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții va avea.

Există acces rădăcină, adrese IP private, porturi, reguli de filtrare și tabele de rutare.

Google PageSpeed ​​​​Insights este un serviciu gratuit de recomandare pentru site-uri web pentru a accelera redarea paginilor în browserul utilizatorului (https://developers.google.com/speed/pagespeed/insights/).

Optimizarea pentru motoarele de căutare (sau SEO) este un set de măsuri de optimizare internă și externă pentru a ridica poziția site-ului în rezultatele motoarelor de căutare pentru anumite solicitări ale utilizatorilor.

Optimizarea site-ului extern este înregistrarea site-ului în motoarele de căutare, promovarea în rețelele de socializare, construirea de link-uri prin atragerea de link-uri din alte resurse către site-ul promovat, banner publicitar, publicitate contextuală.

Optimizarea internă a site-ului este optimizarea textului, URL-urilor, editarea structurii site-ului, relinkarea, verificarea răspunsurilor serverului.

Materiale disponibile Link-uri către site-uri care vă plac, precum și broșuri, reviste, fotografii - orice, sau poate aveți o carte de brand gata făcută. Atașat într-o arhivă separată. Rezoluție minimă și dispozitive de afișare În acest paragraf, specificați dispozitivele de pe care intenționați să vizualizați site-ul - PC-uri, laptop-uri, smartphone-uri... Monitoare PC de la 19 la 27 inch; Notebook-uri de la 15,6 la 17,3 inchi; Smartphone-uri de la 3,5 la 6 inchi; Tablete de la 7 la 12 inci Aveți nevoie de o versiune mobilă? Da CERINȚE FUNCȚIONALE Set aproximativ de module (pentru utilizatori) În această secțiune, trebuie să enumerați toate funcționalitățile pe care doriți să le vedeți pe site.

Acesta poate fi un coș de cumpărături, filtre de catalog în funcție de diferiți parametri, posibilitatea de a plasa o comandă online, de a lăsa o cerere de apel înapoi, de abonament la un buletin informativ și de orice alte opțiuni.Catalog filtrează după preț, alfabetic, după producător.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EXHJya(gTT┬Pb╟▌╤└u╟╛#╜┘al+Kq╟k3┕²┴i├┕ ╜IWA▓BOЬ└vOЗb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜└u╟╛#╜┘al+КaXG[b:ьVzhb╟▌╤└u╟╛#╜┘al+КaXG[b:┌╌┕⛕┕⛕ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╥u╬╥╥ ≈≈K&ОQТё╦▒'%[n╓≥Lk"[Ts(b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚yb╖ ╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚bD'═\┘*NlkZ ⌡ . . ©OlM²K%j ┼╖`СsА≈K▐f²Yh▐Hd╟Fg╬lн∙╥е#⌡i<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Având în vedere faptul că li se cere adesea să dea exemple de TK, împărtășesc comunității câteva dintre evoluțiile mele. Aceste documente nu au valoare comercială (din cauza limitării anilor și a configurației), dar sper că pot fi utile ca mostre.

Sarcina tehnica:

automatizate

Sistemul de VÂNZARE.

Sarcina tehnică

Pe cearșafuri

„_” ______________ 2010

1. Informații generale

Denumirea sistemului automatizat

„CA Vânzări”

Client

Executor testamentar

Baza muncii

Date programate pentru începerea și finalizarea lucrărilor la crearea sistemului

Început lucrări: 01.09.2010

Finalizare lucrări: 31.12.2010

Scopul și scopurile creării sistemului

Scopul sistemului

Sistemul automatizat în curs de dezvoltare este conceput pentru a automatiza procesele de vânzare ale unei întreprinderi.

Obiectivele creării unui sistem

Obiectivele creării unui sistem automatizat

Obiectivele dezvoltării AS SBYT sunt:

1. 3. Caracteristicile obiectului de automatizare

3.1 Procesele de afaceri ale întreprinderii

3.1. 1 Procesul de afaceri „Încheierea contractului”

3.1.2. Procesul de afaceri „Plată”

1. 4. Cerințe de sistem.

4.1. Cerințe generale de sistem.

4.1.1. Metodele și modulele software dezvoltate în AS ar trebui să conțină posibilități de dezvoltare ulterioară a sistemului.

5.1.1. Sistemul dezvoltat ar trebui să fie format din sisteme automatizate, subsisteme și module contabile alocate în funcție de scopul lor funcțional în conformitate cu metodologia stabilită pentru construirea sistemelor automatizate de clasa financiară și economică.

5.1.2. AS dezvoltat ar trebui să asigure ușurința instalării unei stații de lucru automatizate (AWP) pentru fiecare executant specific, în conformitate cu sistemul de contabilitate existent.

5.1.3. AS în curs de dezvoltare ar trebui să asigure diferențierea drepturilor de acces ale utilizatorilor și să ofere posibilitatea de a accesa informații în măsura necesară și suficientă pentru îndeplinirea atribuțiilor fiecărui executant.

5.1.4. Protecția informațiilor împotriva accesului neautorizat ar trebui implementată folosind următoarele mecanisme:

1. Restricții privind drepturile de acces la nivelul platformei 1C:Enterprise 8.1.

2. Restricții suplimentare privind drepturile de acces la nivelul mediului de execuție.

5.1.4.1. Prioritatea ar trebui să fie restricționarea drepturilor de acces la nivel de platformă. Eliminarea restricțiilor suplimentare la nivel de rulare nu oferă drepturi de acces la obiectele sau funcțiile sistemului dacă le este impusă o restricție de sistem.

5.1.4.2 Securitatea informațiilor la nivel de platformă

· Protecția informațiilor la nivel de platformă este asigurată de instrumentele de sistem. În același timp, sunt reglementate drepturile de citire și editare a obiectelor de sistem, de utilizare a interfețelor, funcțiilor sistemului și de a efectua operațiuni de rutină cu datele sistemului informatic.

· Toate drepturile de acces ar trebui sistematizate în seturi adecvate - Rolurile sistemului informațional.

· Lista utilizatorilor sistemului informatic trebuie să fie stabilită de administratorul de sistem.

· Drepturile de acces ale fiecărui utilizator trebuie să fie determinate de setul de Roluri ale Sistemului Informațional de care dispune.

· Seturile de Roluri ale Sistemului Informațional disponibile pentru fiecare utilizator trebuie să fie determinate de administratorul de sistem.

· Când începe să lucreze în sistem, utilizatorul trebuie să parcurgă procedura de autorizare, indicând numele său în sistem și parolă.

5.1.4.3. Protecția informațiilor la nivel de rulare

Pentru un număr de directoare din sistem, ar trebui furnizate restricții suplimentare privind drepturile de editare.

Directoare pentru care este necesar să se stabilească o interdicție de editare în sistem:

• Abrevieri de adrese
• Monede
• Tipuri de decontari reciproce
• Activitatea contrapartidelor
• Grupuri de utilizatori
• Acte de identitate
• Pozițiile organizațiilor
• Subdiviziuni
• Utilizatori
• Elemente de flux de numerar
• Cheltuieli
• Tarife

5.1.5. Pentru a asigura siguranța informațiilor în caz de accidente, ar trebui asigurată arhivarea zilnică automată a datelor.

5.1.6. Cerințe de ergonomie și estetică tehnică

5.1.6.1 Pentru a asigura unificarea designului interfețelor utilizator, barele de instrumente și meniurile contextuale generate automat de platforma 1C ar trebui utilizate în mod implicit.

5.1.6.2 Terminologia utilizată pentru a desemna obiectele și acțiunile utilizatorului în sistem trebuie să respecte terminologia standard a domeniului subiectului.

5.2. Cerințe pentru structura și funcționarea AS „SBYT”.

5.2.1. AS „VÂNZĂRI” ar trebui să constea din următoarele subsisteme automate:

Subsistem pentru introducerea informațiilor primare despre abonat (încheierea unui acord);

Subsistem de generare a documentelor de plată;

Subsistem de comunicare cu sistemul ASKUE;

Subsistem de comunicare cu terminalele de plată.

5.2.2. Compoziția subsistemului pentru introducerea informațiilor primare despre abonat (încheierea unui acord) ar trebui să fie după cum urmează:

Document „Acord cu abonatul”;

5.2.3. Compoziția Subsistemului pentru generarea documentelor pentru plată ar trebui să fie următoarea:

Document „Chitanță”

Documentul „Acuzarea de penalități”

Document „Energie consumată”

Modul de verificare a stării decontărilor reciproce

5.2.4. Compoziția subsistemului de comunicații cu sistemul ASKUE ar trebui să fie după cum urmează:

Modul Comunicare cu sistemul ASKUE.

5.2.5. Compoziția subsistemului pentru comunicarea cu terminalele de plată ar trebui să fie următoarea:

Modul Comunicare cu terminalele de plată.

5.3. Cerințe pentru funcțiile modulului subsistemului pentru introducerea informațiilor primare despre abonat (încheierea unui acord)

5.3.1. Subsistemul pentru introducerea informațiilor primare despre abonat (încheierea unui acord) ar trebui să îndeplinească următoarele funcții:

Introducerea și stocarea informațiilor despre capacitatea instalată a contrapărții (denumită în continuare abonat);

Introducerea și stocarea informațiilor despre contoarele instalate ale abonatului;

Introducerea și stocarea informațiilor despre tarifele abonatului;

Introducerea și stocarea informațiilor privind condițiile de calcul a penalităților pentru abonat;

Introducerea și stocarea informațiilor despre termenii contractului;

5.4. Cerințe pentru funcțiile Subsistemului de generare a documentelor de plată

5.4.1. Subsistemul de generare a documentelor de plată ar trebui să îndeplinească următoarele funcții:

Stabilirea statutului decontărilor reciproce cu abonatul și stabilirea condițiilor de producere a penalităților.

Formarea documentelor de plată (chitanțe sau facturi de plată).

5.5. Cerințe pentru funcțiile Subsistemului de comunicații cu sistemul ASKUE

5.5.1. Subsistemele de comunicare cu sistemul AMR ar trebui să îndeplinească următoarele funcții:

Transfer de date privind contractele nou încheiate cu abonații. Cheia de comunicare trebuie să fie unicitatea perechii „Subscriber ID” - „Subscriber Agreement Code”.

Obținerea de date privind energia electrică consumată de către abonat. Cheia de comunicare trebuie să fie unicitatea perechii „Meter ID” - „Meter Code”.

5.6. Cerințe pentru funcțiile Subsistemului de comunicare cu terminalele de plată

5.6.1. Subsistemele de comunicare cu sistemul AMR ar trebui să îndeplinească următoarele funcții:

Obținerea de date privind plățile efectuate de abonați pentru energie electrică prin terminale de plată.

1. 6. Procedura de control și acceptare a AIS „VÂNZĂRI”.

6.1.Se stabilește următoarea procedură de prezentare și predare a rezultatelor lucrărilor către Client:

6.1.1. Antreprenorul demonstrează operabilitatea software-ului pe un exemplu de control.

6.1.2. Datele pentru cazul de testare sunt intocmite de reprezentantii Clientului.

6.1.3. Antreprenorul transferă software-ul către departamentul de informații al Clientului și antrenează administratorul Clientului.

6.1.4. Pe baza rezultatelor rezolvării cazului de testare, ar trebui pregătit un act privind transferul de software pentru operarea de probă.

6.1.5. În caz de discrepanță între funcționalitatea software-ului și cerințele TOR, Antreprenorul efectuează eliminarea comentariilor ca parte a costului total al dezvoltării AS.

6.1.6. Dacă există cerințe suplimentare ale Clientului față de TOR, se întocmește un TOR suplimentar pentru revizuire.

6.1.7. Prezența cerințelor suplimentare ale Clientului nu ar trebui să fie baza pentru refuzul de a semna Legea privind transferul de software pentru operarea de probă.

6.1.8. După transferul software-ului pentru funcționarea de probă, conform Programului de Implementare convenit cu Clientul, Antreprenorul efectuează o scurtă instruire a personalului Clientului pentru a lucra cu software-ul și transferă Instrucțiunile de lucru cu software-ul fiecărui subsistem.

6.1.9. La implementarea software-ului (operațiune de probă), Clientul efectuează:

Introducerea NSI-ului necesar;

Introducerea datelor reale;

Întocmirea rapoartelor și verificarea rezultatelor muncii.

6.1.10. Pe parcursul procesului de implementare, Antreprenorul va oferi asistență Clientului în cadrul Programului de Implementare.

6.1.11. În cazul unei pregătiri slabe a personalului Clientului pentru implementare și al necesității de asistență suplimentară din partea Antreprenorului pentru implementarea cu succes a software-ului, ar trebui întocmit un protocol suplimentar pentru convenirea prețurilor contractuale pentru furnizarea de informații și lucrări de consultanță.

6.2 Procedura pentru sprijinul suplimentar al sarcinilor AS „VÂNZARE”.

6.2.1. După punerea în funcțiune a software-ului, pot fi implementate îmbunătățiri și dorințe suplimentare ale Clientului în conformitate cu TOR convenit cu Clientul.

Termenul de referință ar trebui să indice intensitatea muncii și costul muncii pentru a implementa cerințe suplimentare.

6.2.2. Antreprenorul se obligă să mențină o „linie fierbinte” telefonică pentru întreținerea software-ului.

6.2.3. La cererea Clientului, Antreprenorul poate efectua întreținerea software-ului direct la Client, care ar trebui să fie efectuată pe baza unui acord suplimentar de întreținere a software-ului.

6.2.4. Erorile identificate de Client în termen de șase luni de la data transferului software-ului în exploatare trebuie eliminate de către Antreprenor prompt și gratuit.

În cazul în care Antreprenorul descoperă că eroarea a apărut ca urmare a acțiunilor incorecte ale Clientului, timpul petrecut de Antreprenor pentru găsirea și eliminarea acesteia trebuie plătit suplimentar.

6.2.5. Clientul, în termen de un an de la achiziționarea 1C: Enterprise, are dreptul de a primi gratuit toate actualizările de la 1C legate de dezvoltarea programelor 1C și modificările legislației. Instalarea modificărilor trebuie efectuată de sistemul de control automat al Clientului.

6.2.6. Antreprenorul garantează confidențialitatea conținutului bazelor de date ale Clientului și a oricăror alte informații primite de la Client în procesul de dezvoltare, implementare sau menținere a AS.

Proiect tehnic:

APROBARE TRIMITE PENTRU APROBARE

""______________ 2010" ""_______________ 2010

Anexă la caietul de sarcini din data „____” ________ 2010

automatizate

Sistemul de VÂNZARE.

Proiect tehnic

Pe cearșafuri

Valabil de la „__” ____________ 2010

Carti de referinta. 3

Contoare. 3

Tarife.. 3

Substații. 3

Opțiuni de penalizare. 3

Enumerări. 4

Tipuri de angajamente. 4

registrele de informații. 4

Înţeles Tariffs. 4

Tarife pentru abonați. 4

Datele contoarelor. cinci

Registre de acumulare. cinci

Consumul de energie. cinci

Documente.. 6

Acord cu abonatul.. 6

Energie consumata. 6

chitanta. 7

Calculul penalităților. nouă

Prelucrare. 10

Obținerea datelor din sistemul ASKUE. 10

Primirea datelor de la sistemul de plată.. 11

Carti de referinta

Contoare

Rechizite:

Tarife

Detalii: nr

Opțiuni de penalizare

Detalii: nr

Enumerări

Tipuri de angajamente

Valori:

Registre de informații

Termenii contractelor

Periodicitate: neperiodic

Scop: Conceput pentru a stoca valabilitatea contractelor cu abonații

măsurători

Înţeles Tariffs

Frecvență: zi

Scop: Conceput pentru a stoca tarifele și datele de la care tarifele încep să funcționeze.

măsurători

Recuzită		Scop
		Costul tarifului zilnic
		Costul tarifului pe noapte (este posibil să nu fie setat)

Tarifele abonaților

Frecvență: zi

Scop: Conceput pentru a stoca tarifele atribuite abonatului în conformitate cu acordurile

măsurători

Recuzită		Scop
	Tarife directoare	Tariful de abonat

Datele contoarelor

Frecvență: zi

Scop: Conceput pentru a stoca citirile contorului pentru facturarea ulterioară

măsurători

Recuzită		Scop
Ziua lecturilor		Citirea contorului
Readings Night		Citirea contorului

Registrele de acumulare

Consumul de energie

Scop: Conceput pentru a stoca informații despre consumul de energie pentru facturarea ulterioară

Tip registru: negociabil

măsurători

Documentele

Contract cu un abonat

Scop: Conceput pentru a reflecta faptul încheierii unui acord cu un abonat

Recuzită		Scop
contraparte	Director contrapărți
Acord de contrapartidă
	Tarife directoare
Putere instalată		Stocarea puterii instalate a abonatului în kWh
DateStartActions		Data de la care este valabil contractul
Data de încheiereAcțiuni		Data expirării contractului
Organizare	Directorul organizațiilor
OpțiuneAccrualFine
Nomenclatură	Nomenclatura directorului
Reglare manuală		Semnul ajustării manuale a afișărilor documentelor

Partea tabelară: Contoare și Tarife

Detinerea documentelor

Documentul este deținut:

Conform registrului de informații „Citirile contoarelor” unde prescrie contoarele abonatului și citirile inițiale ale contorului;

Conform registrului informativ „Tarifele abonatului”, unde tariful stabilit pentru abonat este prescris de la data începerii operațiunii contractului

Conform registrului de informații „Valabilitatea contractelor”, unde este scris contractul, data începerii valabilității și data expirării contractului

Energie consumata

Scop: Proiectat pentru a reflecta citirile contorului la o anumită dată

Completarea unui document

Documentul poate fi completat în două moduri: prin introducere manuală și prin apelarea procesării „Obținerea datelor din sistemul ASKUE”

Detinerea documentelor

Documentul este deținut:

Conform registrului de informații „Citirile contorului” unde prescrie citirile contorului la data documentului;

Conform registrului de acumulare „Energie consumată conform următorului algoritm:

1. Citirile contorului sunt preluate din registrul de informații „Citirile contorului” la data documentului și valoarea anterioară a citirilor contorului.

2. Diferențele de citire a valorilor sunt înregistrate în resursele corespunzătoare ale registrului de acumulare.

Imprimarea formularelor

Registrul citirilor contorului

chitanta

Scop: Conceput pentru a reflecta taxele pentru abonați

Completarea unui document

Documentul poate fi completat în două moduri: prin introducere manuală și prin apelarea procesării „calcul plății”

Partea tabelară: Citirile contorului

Recuzită		Scop
contraparte	Director contrapărți
Acord de contrapartidă	Contractele directoare ale contrapartidelor
Nomenclatură	Nomenclatura directorului
	Tarife directoare	Tariful abonatului conform contractului
	Contoare de director
TipAccruals	Tipuri de enumerare de angajamente
Energie consumată		Energie consumată
Valoarea tarifului		Valoarea tarifului la data documentului
acumulate		Suma percepută abonatului

Detinerea documentelor

Documentul este deținut:

Conform planului de conturi fiscale:

Imprimarea formularelor

Registrul de angajamente

Algoritmul de umplere

Documentul se completează pe baza directorului „Acorduri ale contrapărților”.

1. Contractele sunt selectate din director, pentru care, conform registrului de informații „Termeni de valabilitate a contractelor”, Data de începere este mai mică decât data documentului, iar Data de încheiere este mai mare decât data documentului;
2. Sunt selectate ghișeele corespunzătoare acestor contracte;
3. Pentru contoare, consumul de energie se determina ca cifra de afaceri conform registrului de acumulare „Consum de energie” pentru perioada cuprinsa intre data documentului si data documentului anterior, daca data documentului anterior este necunoscuta, atunci intreaga cifra de afaceri conform la registru se duce. Valoarea rezultată este înregistrată în câmpul „Energie consumată”
4. Tariful se stabileste in functie de contract si de valoarea tarifului la data documentului;
5. Setează tipul de acumulare „Conform citirilor contorului”;
6. Câmpul acumulat este calculat ca produs dintre energia consumată și valoarea tarifului.

Efectuarea algoritmului

CT. 90.01 cu analytics SubcontoKt1 - Nomenclatura.NomenclatureGroup, SubkontoKt2 - Nomenclatura.Cota TVA.

Dacă există un Sold Credit la contul 62.02, atunci plata în avans este compensată cu înregistrarea

Dt. 62.02 cu analize SubcontoDt1 - Contraparte, SubcontoDt2 - Contract de contraparte

Suma de înregistrare - valoarea minimă din soldul creditor la contul 62.02 și valoarea atributului „cumulat”)

Dt. 90.03 cu analize SubcontoDt1 - Nomenclatură.NomenclatureGroup, SubcontoDt2 - Nomenclatură.Cota TVA

CT. 62.01 cu analize SubcontoKt1 - Contraparte, SubkontoKt2 - Contract de contraparte

Suma de înregistrare = „Acumulat” * Cota TVA / (100 + cota TVA), unde cota TVA - „Nomenclatură. Cota TVA”

Calculul penalităților

Scop: conceput pentru a reflecta acumularea amenzilor pentru abonați

Completarea unui document

Documentul poate fi completat în două moduri: prin introducere manuală și prin apelarea procesării „cumularea amenzilor”

Partea tabelară: Citirile contorului

Recuzită		Scop
contraparte	Director contrapărți
Acord de contrapartidă	Contractele directoare ale contrapartidelor
OpțiuneAccrualFine	Opțiuni de penalizare din director
acumulate		Suma percepută abonatului

Detinerea documentelor

Documentul este deținut:

Conform planului de conturi autonom:

Conform planului de conturi fiscale:

Imprimarea formularelor

Registrul de angajamente

Bon de plată cu cod de bare

Codul de bare este generat folosind fontul „Infograftbarcode”

Algoritm de formare șir „0000”+Cod contract de abonat+Taxat

Formatul chitanței este atașat în fișierul КВ_1.mxl

Efectuarea algoritmului

Pentru fiecare rând din secțiunea tabelară „Citirile contorului”, trebuie făcute următoarele înregistrări:

Dt. 62.01 cu analize SubcontoDt1 - Contraparte, SubcontoDt2 - Contract de contraparte

CT. 91.01 cu analytics SubcontoKt1 - Alte venituri.

Suma de înregistrare - valoarea atributului „Acumulat”;

Prelucrare

Primirea datelor din sistemul ASKUE

			Precizie	Scop
				Codul contorului din sistemul „Vânzări”, se potrivește cu meter_ID din sistemul ASKUE
				Citirile zilnice ale contorului
				Citirile contorului de noapte

Detalii de procesare

Algoritm de procesare:

1. Obțineți codul de contor din linia fișierului de transfer de date
2. Găsiți elementul corespunzător în directorul „contoare” după cod, dacă elementul nu este găsit, apoi afișați mesajul „Contorul cu codul nu a fost găsit...”
3. Dacă elementul este găsit, adăugați o linie la tabelul de valori, unde: „counter” - elementul găsit, „IndicationsDay” - „Day”, „IndicationsNight” - „Night”
4. Dacă procesarea este apelată din documentul „Energie consumată” și numărul de linii

în tabelul cu valori mai mari decât 0, apoi scrieți conținutul tabelului cu valori în partea tabelară a documentului și postați documentul.

1. Dacă există rânduri în tabelul de valori și procesarea nu este apelată din documentul Energie Consumată, atunci creați documentul Energie Consumată cu data egală cu data curentă și apoi postați documentul.

Primirea datelor de la sistemul de plată

Formatul fișierului de transfer de date este DBF;

Structura fișierului de transfer de date:

Detalii de procesare

Algoritm de procesare:

1. Creați un tabel de valori cu structura:

1. Selectați Linii de fișier de transfer de date
2. Începeți să faceți bucla prin liniile fișierului de transfer de date
3. Citiți linia fișierului de transfer de date
4. Obțineți codul contractului din rândul fișierului de transfer de date
5. Găsiți elementul corespunzător după cod în directorul „Acorduri ale contrapărților”, dacă elementul nu este găsit, apoi afișați mesajul „Acordul cu codul nu a fost găsit...”
6. Dacă elementul este găsit, adăugați o linie la tabelul de valori, unde: „Acord” - elementul găsit, „Data” - „Data_plat”, „Număr de plată” - „Nomer_plat”, „Suma” - „Summa_plat”
7. După ce ați primit ultima linie a fișierului de transfer de date, terminați bucla
8. Pentru fiecare rând din tabelul de valori, creați un document „Primire ordin de plată a fondurilor”. Când creați un document, verificați dacă sistemul are un document cu o astfel de dată și un astfel de număr de document de intrare. Dacă documentul este prezent în sistem, atunci documentul nu este creat.
9. Reguli de completare a detaliilor documentului:

Recuzită	Valoarea de umplere
Tipul operațiunii
	RowTableValue.Date
Numărul documentului primit	StringTableValue.PaymentNumber
Data documentului primit	RowTableValue.Date
Acord de contrapartidă	StringTableValue.Contract

Depinde direct de cât de exact sunt întocmiți termenii de referință pentru finalizarea 1C, dacă sarcinile atribuite dezvoltatorilor vor fi rezolvate. Cu toate acestea, atunci când lucrați cu un astfel de document, există unele dificultăți. În sens larg, TOR prescrie normele pentru crearea și modernizarea unui sistem automatizat (AS), precum și procedura de lucru. Aceasta include, de asemenea, un set de standarde de lansare a proiectelor. Această înțelegere a rolului termenilor de referință este dictată de cerințele GOST 19.201-78 și 34.602-89, conform cărora TOR pentru 1C este în curs de dezvoltare. Există o altă interpretare a sensului acestui document, mai apropiată de practică.

Conform unei alte definiții, termenii de referință pentru finalizarea 1C este un document care reglementează scopul și parametrii viitorului sistem, precum și procesul de elaborare a documentației și lista acesteia. Această interpretare permite luarea în considerare a intereselor programatorilor și ale clientului.

Care ar trebui să fie TK?

Orice sarcină tehnică pentru dezvoltarea programului 1C este creată de antreprenor. Dar acesta nu este un programator, ci un analist. Acesta este un punct important, deoarece documentul trebuie redactat într-o limbă pe care clientul o înțelege, fără termeni tehnici de înaltă specialitate. Atunci când toate nuanțele proiectului sunt luate în considerare și informațiile sunt formulate corect, TOR este convenit cu toți clienții. Dacă este acceptat, programatorii sunt implicați în lucru. În același timp, rezultatul dorit ar trebui să fie subliniat clar în document. Acest lucru îi ajută pe dezvoltatori să stabilească obiectivul potrivit și să-l verifice în diferite etape. De asemenea, atunci când se elaborează termenii de referință pentru finalizarea 1C, trebuie acordată multă atenție formulării. Trebuie avut grijă ca acestea să fie suficient de specifice și să nu implice alte interpretări. Acesta este primul lucru de reținut când lucrați cu TK. De asemenea, trebuie să adoptați o abordare responsabilă a designului. Acest lucru este valabil și pentru pagina de titlu a documentului.

Principalele greșeli în termenii de referință pentru dezvoltarea 1C

Structura termenilor de referință este reglementată de GOST 34.602-89. Acest document conține cerințe clare pentru numărul și succesiunea blocurilor de informații din TOR. În același timp, nu există standarde stricte pentru metodele de prezentare. Această situație conține un potențial mare de rezolvare a unor probleme complexe și, în același timp, poate duce la multe erori în pregătirea documentului. Cele mai frecvente inexactități sunt:

1. Repetarea unor secțiuni în diferite interpretări.
2. Informațiile sunt date aleatoriu. În mod ideal, ar trebui să se refere la o structură specifică, cum ar fi procesele de afaceri sau modulele de sistem.
3. Informațiile din diferite secțiuni sunt prezentate cu diferite grade de detaliu.

Toate acestea împiedică clientul să înțeleagă informațiile care sunt prevăzute în TOR. Acest lucru complică procesul de cooperare, făcându-l mai consumator de timp.

După vizualizarea de către client, TOR eșantion pentru revizuirea 1C se poate modifica și nu întotdeauna în bine. Acest lucru, la rândul său, împiedică de obicei programatorii să perceapă corect informațiile. Acest lucru este valabil mai ales pentru specialiștii cu puțină experiență. În această etapă, apar adesea următoarele erori:

1. Cerințele diferitelor secțiuni se contrazic reciproc.
2. Formulele sunt inexacte.
3. În unele locuri, informațiile sunt prea detaliate.

A scăpa de toate aceste erori este ușor. Este necesar să ne concentrăm, în primul rând, pe rezultat, și nu pe prescrierea cu atenție a formulărilor. Merită să ne amintim că TOR descrie funcționalitatea proiectului, principalii parametri și scopul acestuia.

Cum să evitați greșelile în elaborarea specificațiilor tehnice?

Regula principală, care se aplică tuturor recomandărilor ulterioare, este că formularea trebuie să fie specifică. Pentru a face acest lucru, trebuie să utilizați link-uri către GOST, alte documente de reglementare. Acest lucru permite contractantului și clientului să perceapă informațiile în același mod.

Un exemplu de sarcină tehnică pentru finalizarea 1C implică utilizarea limbajului industriei de afaceri pentru care este implementat proiectul. Acest lucru este necesar, în primul rând, pentru client. În același timp, nu trebuie să utilizați nicio comparație în text, deoarece acestea pot fi interpretate în moduri diferite.

Reguli de bază la elaborarea termenilor de referință pentru elaborarea unui raport și a altor elemente ale 1C:

1. TK este creat în comun de către antreprenor și client.
2. Doar cerințele obiective ar trebui să fie prezentate muncii programatorilor. Pentru dezvoltarea cu succes a proiectului, viziunea subiectivă a clientului trebuie să fie menținută la minimum.
3. Este necesar să descriem în detaliu rezultatul de care are nevoie clientul. În același timp, în exemplul termenilor de referință pentru dezvoltarea configurației 1C, este necesar să se prescrie toți parametrii după care ar trebui să funcționeze elementul. În caz contrar, rezultatul poate fi foarte diferit de cel dorit.
4. Riscurile antreprenorului și ale clientului ar trebui să fie aproximativ egale și reduse la minimum.
5. Nu puteți folosi termeni care sunt folosiți în comunicarea de afaceri și nu sunt utilizați într-o anumită industrie.

Pentru a crea un TOR pentru elaborarea unui raport în 1C sau alt element, analistul trebuie să cunoască toate caracteristicile domeniului de activitate al clientului. În cerințe, trebuie să oferiți numai informații utile care sunt utile interpretului. Având în vedere că aici se acordă o atenție deosebită sarcinilor finale pe care software-ul trebuie să le rezolve, nu există un singur exemplu de sarcină tehnică.

Pericolul pregătirii incorecte a TOR

Erorile enumerate mai sus pot duce la o creștere a timpului necesar pentru a crea un sistem. Acest lucru implică costuri inutile și nemulțumire. Termenii de referință pentru dezvoltarea unei baze de date sau a unei alte configurații 1C ar trebui întocmiți de specialiști cu experiență. Beneficiul tuturor participanților depinde de modul în care acest document este înțeles. Clientul primește un sistem automat eficient pentru rezolvarea problemelor de afaceri. Totodată, antreprenorul are un alt client mulțumit. Proprietarii de afaceri trebuie să fie cât mai atenți atunci când aleg companiile partenere 1C, deoarece eficiența organizației depinde în mare măsură de cât de bine sunt redactați termenii de referință pentru revizuire.

Dacă parcurgeți site-uri străine cu cererea „document de cerințe ale produsului”, puteți găsi articole creative și convingătoare despre faptul că sarcina tehnică (TOR, PRD) este moartă. Parțial, trebuie să fim de acord cu acest lucru - atunci când dezvoltăm un produs de la zero, prototiparea pare mult mai interesantă și eficientă decât volumele de înregistrări ale clienților, uneori foarte neprofesioniste. Totuși, dacă vorbim despre finalizarea sistemului de bază, atunci lucrurile iau o cu totul altă întorsătură. Ne confruntăm atât cu revizuirea, cât și cu dezvoltarea personalizată, așa că câinele a fost mâncat la TK, dacă bucătarul nu ne minte. În general, astăzi - despre acele sarcini tehnice foarte clasice care sunt scrise pentru a finaliza software-ul achiziționat și instalat. Pe scurt, despre răni.

Fațete ale interacțiunii

Înainte de a trece la pregătirea procesului de creare a unei sarcini tehnice, să vorbim despre patrulater, în care se încadrează antreprenorul și clientul la începerea proiectului.

Cerințe- comportamentul dorit al sistemului, așa cum este descris de client sau deținătorul procesului, care urmează să fie implementat. De regulă, cerințele sunt formate pe baza experienței, reprezentarea comportamentului corect al programului. Aceasta este o informație cheie pentru dezvoltator (vânzător), totuși, în etapa de colectare a cerințelor apar cel mai mare număr de coliziuni, erori, solicitări redundante etc.

Resurse- oameni, mașini, inventar, mediu de dezvoltare, timp și bani pentru a fi utilizați în procesul de implementare a cerințelor. Resursele necesită o planificare și o evaluare clară în etapa de aprobare a termenilor de referință. Prioritizarea competentă din partea clientului și distribuirea resurselor de muncă din partea vânzătorului fac posibilă evitarea depășirii termenelor limită și minimizarea altor riscuri.

Oportunități- pe scurt, asta este ceea ce poate face cu adevărat un vânzător (interpret). Luați în considerare RegionSoft CRM ca exemplu. Clientul cumpără sistemul și întocmește o sarcină tehnică de revizuire: este necesară crearea unei integrări cu site-ul și legarea evenimentelor în CRM la numărul de comandă al magazinului online. Aceasta este o cerință realistă, avem resursa și capacitatea de a o face. Și, de asemenea, trebuie să dezvoltați și să vă legați de CRM CMS, un sistem de management al conținutului site-ului. Teoretic, putem face acest lucru, dar nu avem posibilitatea de a o face ieftin, iar clientul nu are posibilitatea de a ne plăti suficient pentru a transfera resurse umane și de timp în sarcină. Drept urmare, clientul refuză această cerință - și nu are nevoie cu adevărat de un CMS, oricum totul este în regulă. Dar despre „lăcomia” TK – mai târziu.

Restricții- un set de obstacole care fac dificilă sau imposibilă finalizarea sarcinilor din TOR: buget, stiva de tehnologie, probleme de licențiere, interdicții legale, configurații hardware etc.

Astfel, toate cele patru entități sunt strâns legate între ele și determină succesul proiectului în ansamblu. Să luăm în considerare fiecare element și să încercăm să evidențiem punctele critice de care trebuie să ținem cont atunci când lucrăm la termenii de referință.

Colectarea și analiza cerințelor

Acesta este un proces intern corporativ foarte important, în timpul căruia rezultă ce doresc potențialii utilizatori de la program (în continuare vom lua CRM, dar metodele funcționează cu alte tipuri de software). Dacă contactați un furnizor mare precum SAP sau un integrator de sistem, atunci cu un grad mare de probabilitate vi se vor oferi serviciile unui consultant de afaceri (este și manager personal, este și manager de cont, este și „ acum reprezentantul dumneavoastră în compania noastră”). De fapt, în cele mai multe cazuri, acesta este un vânzător obișnuit, bine pregătit, care are două sarcini: să achite costul proiectului și să nu te lase să scapi.

E aici de o oră și nici măcar nu a atins tabla albă. Nu este un adevărat analist de sisteme

Nimeni nu îți cunoaște compania mai bine decât tine și angajații tăi. Aceasta înseamnă că colectarea și analiza cerințelor este exclusiv sarcina dvs., în care vânzătorul poate ajuta și ghida, dar în niciun caz nu interfera cu procesul. Întrebați dezvoltatorul despre astfel de implementări, specificați ce să căutați și continuați. Apropo, angajatul dvs. care este bine versat în subiectul profilului și reprezintă aproximativ arhitectura software și este familiarizat cu procesul de dezvoltare poate fi un bun asistent - poate acționa ca analist și expert intern, poate închide procesul de creare a specificațiilor tehnice și comunicarea cu vânzătorul.

Există o schemă foarte simplă pentru colectarea cerințelor.

1. Creați un grup de lucru de manageri și specialiști cu experiență ai departamentelor care vor folosi CRM. Spuneți-ne despre soluția pe care o veți alege, oferiți acces la versiunea demo.
2. Membrii grupului de lucru trebuie să transmită informații angajaților și să le ceară urări pentru un nou program într-o formă absolut gratuită. Dacă unul dintre angajați nu a întâlnit niciodată un astfel de software și nu este pregătit să vorbească despre utilizarea viitoare, trebuie să-l cereți să-și descrie sarcinile periodice, aceasta este o abordare universală.
3. Fiecare divizie determină apoi ceea ce CRM nu se potrivește sau nu se potrivește și agregează informațiile.
4. Grupul de lucru analizează cerințele colectate, verifică și elimină intersecțiile. De exemplu, nu este neobișnuit ca un departament de vânzări și un departament de marketing să comande același raport, dar câmpurile și entitățile pot fi denumite diferit în cerințe, deși datele din spatele lor sunt aceleași. În consecință, este necesar să ajungem la o singură formă.
5. Grupul de lucru formează o listă de cerințe și stabilește prioritățile. În această etapă, puteți conecta furnizorul, deoarece el este responsabil pentru resurse. De exemplu, puteți cere să creați un raport personalizat pentru RegionSoft CRM sau puteți comanda integrarea cu site-ul. Acestea sunt sarcini complet diferite din punct de vedere al timpului, prioritatea este foarte importantă aici.

După ce cerințele sunt colectate, analizate și convenite cu angajații și conducerea, puteți începe să creați termeni de referință. Puteți fie să cereți formularul vânzătorului, fie să îl creați singur - în orice caz, există câteva reguli absolute care vă vor scuti de o bătaie de cap atât dvs., cât și furnizorului dvs. de CRM.

Anatomia unui termen de referință

Dacă vorbim despre procesul de creare a unei sarcini tehnice, atunci există mai multe etape. Trecerea lor consecventă conduce clientul la îmbunătățirea dorită. Aici sunt ei.

• Identificare - definirea cerințelor, căutarea problemelor care trebuie rezolvate.
• Analiza - analiza cerintelor, identificarea nevoilor cheie, generalizare.
• Adaptare - evaluarea cerințelor în contextul capabilităților CRM și al proceselor de afaceri existente.
• Documentație - o descriere formală și detaliată a cerințelor, aprobarea specificațiilor tehnice.
• Comunicarea cu furnizorul (dezvoltatorul) - interacțiune iterativă cu vânzătorul cu privire la îmbunătățiri în conformitate cu TOR compilat.
• Implementare - munca furnizorului de a crea funcționalitatea necesară. Este mai bine dacă vânzătorul este în permanență în contact cu clientul - astfel încât produsul rezultat se va potrivi cel mai bine cu viziunea clientului.
• Testare - verificarea funcționalității de către angajații vânzătorului, experții interni ai clientului și utilizatorii finali pentru a stabili conformitatea revizuirii cu TOR, operabilitatea sistemului cu modificări.

În general, termenii de referință pot fi creați pe baza cerințelor mai multor niveluri, care se pot suprapune și pot coopera la crearea proiectului sau să nu interacționeze deloc.

Nivel de afaceri- cel mai global nivel la care sunt rezolvate sarcini complexe și prioritare. Acest nivel include integrarea, rafinarea și modelarea proceselor de afaceri, dezvoltarea de noi module funcționale. De regulă, aceasta este o dezvoltare intensivă în resurse, cu consultări serioase și colaborare strânsă cu clientul. De exemplu, la un moment dat în RegionSoft CRM, contabilitatea depozitului, casa de marcat și producția erau astfel de modificări personalizate. Treptat, modificările au intrat în lansare, iar ulterior au permis crearea unui nou produs pentru magazine en-gros, retail și hipermarketuri - RegionSoft Retail.

Nivel de utilizator sau grup de utilizatori. La acest nivel, sunt implementate sarcini pentru a rafina interfața existentă. De exemplu, un utilizator poate dori o fereastră cu numărul și starea ultimei comenzi să apară atunci când trece cu mouse-ul peste un client sau un raport personalizat cu o grupare specială de date. Îmbunătățirile la acest nivel necesită mai puțin timp, dar pot fi multe - de exemplu, mai multe cerințe de la departamentele de marketing, logistică și suport tehnic.

nivelul de funcționalitate. De multe ori este dificil să-l separăm de cel precedent, aici funcționează un criteriu formal - rafinamentul nu este la nivelul afișării a ceva în interfață, ci la nivelul rafinamentului logicii sistemului. Acestea includ cerințe pentru diferite tipuri de sortare, integrare prin chat și capabilități de telefonie.

Nivel de servicii- de fapt, cerințele acestui nivel ar trebui să fie primele care intră în build-uri noi cu remedieri. Acestea sunt sarcini în ceea ce privește viteza de răspuns a sistemului, lucrul sub sarcină mare și securitatea. În mod ideal, vânzătorul nu ar trebui să aibă astfel de îmbunătățiri - software-ul corporativ nu ar trebui să încetinească, să piardă date, să restrângă formulare și să distribuie drepturi de acces de același nivel. Dar dacă a apărut o cerință și nu are legătură cu paranoia personală a clientului sau cu probleme din partea hardware, merită să-i acordăm o atenție deosebită.

Nivel de tehnologie- ultimul din listă, dar înaintea celorlalți ca importanță și complexitate. Acestea pot fi cerințe ale clientului legate de platformă, sistem de operare sau dispozitive. De exemplu, o cerere de compilare pentru MacOS. Este grozav dacă astfel de cerințe se dezvoltă treptat în versiuni, dar este necesar să existe remedieri ale acestora. Din solicitările clienților de la acest nivel am realizat asamblarea RegionSoft CRM pentru MacOS și am adăugat acces la distanță folosind tehnologia TRM ca soluție temporară la o solicitare rară, dar existentă, pentru o versiune mobilă.

Anatomia termenilor de referință este simplă, cel puțin sub forma unui schelet. Părțile obligatorii ale termenilor de referință îl ajută pe client să se concentreze asupra problemei și să formuleze sarcina corect, iar executantul să înțeleagă ce vrea de la el. Apropo, despre înțelegere. Bineînțeles, la începutul postării, eram puțin vicleni, refuzând consultanții de afaceri ca clasă. Ideea este aceasta: fiecare furnizor operează pe piață de câțiva ani (nu vorbim acum de CRM-uri de o zi), sau chiar de decenii, ceea ce înseamnă că are un set de cazuri în aproape fiecare industrie. În consecință, atât inginerii, programatorii, cât și agenții de vânzări sunt familiarizați cu specificul implementării fiecărui tip de companie. Dar din nou, este important să vă concentrați pe afacerea dvs.

Pentru cine?În această secțiune, trebuie să descrieți cine va fi utilizatorul final al revizuirii, ce sarcini și cât de des este planificat să o rezolve.

Vă dau un exemplu. O companie a implementat CRM, trebuia să lucreze pe o gamă destul de mare de date (câteva zeci de milioane de înregistrări pe lună, câteva sute de mii de înregistrări pe zi). Șeful departamentului de vânzări a solicitat un raport privind încărcarea acestor înregistrări cu o frecvență de „zilnic”. Desigur, un astfel de raport, în timp ce sute de utilizatori lucrau simultan, a încărcat sistemul - s-au găsit soluții pentru optimizarea procesului. Deja în cursul lucrărilor, s-a dovedit că vânzătorul era în siguranță și avea nevoie de raport abia la sfârșitul lunii, iar apoi putea fi lansat conform programului noaptea. Inutil să spun că s-au irosit timp și bani.

Pentru ce? Justificarea necesității de îmbunătățire și locul acesteia în procesul de afaceri. Acest articol este mai necesar clientului însuși, dar este util și pentru vânzător să știe ce alte procese vor fi afectate. Uneori ajută să găsiți o soluție alternativă.

Ce ar trebui făcut? Cel mai informativ bloc - descrie cerințele, așteptările de la sistem. Și aici se întâmplă chiar perlele, miracolele și ciocnirile, pe care trebuie să le trimiți la bashorg și care, ei bine, îngreunează viața. Există un singur motiv - utilizatorul nu știe ce vrea, ce trebuie făcut. Există un alt mic submotiv - utilizatorul nu poate formula cerințe. Și aici sarcina dezvoltatorului (grup de lucru, analist, dacă există) este să ajute la formularea corectă a nevoii, să selecteze o cerință adecvată și să încadreze sarcina în contextul sistemului. În același bloc, trebuie să menționați rezultatul așteptat.

Parametrii termenilor de referință- termene limită, etape de implementare, responsabil din toate părțile, contacte necesare etc. De fapt, acesta este un set de lucruri formale importante care fac din document o sarcină tehnică. Termenii de referință trebuie conveniți și semnați de către părți pentru a evita numeroase schimbări în timpul dezvoltării (vor fi în continuare, dar într-un volum mai mic).

În mod ideal, termenii de referință sunt întocmiți cu participarea activă a vânzătorului, iar rezultatul acestuia este aproximativ următoarea structură:

1. Descrierea cerințelor fiecărui mecanism și a fiecărei funcționalități
2. Descrierea implementării acestei funcționalități
3. Costul lucrării pentru fiecare etapă separat
4. Costul total al lucrării pentru această sarcină tehnică
5. Termenele de executare a lucrărilor cu defalcare pe etape și indicarea ordinii de prioritate
6. Descrierea condițiilor de instalare și de testare
7. Rezerve cu privire la caracterul exhaustiv al termenilor de referință și al altor condiții

10 reguli scrise în lacrimile dezvoltatorului

Termenii de referință pentru revizuire ar trebui să fie TOR pentru revizuire, și nu o descriere de 300 de pagini a CRM-ului de care are nevoie clientul. Înainte de a elabora cerințele, ar trebui să vă familiarizați cu interfața sistemului, capacitățile sale, documentația - cel mai probabil, cea mai mare parte a „Listei de dorințe” este deja în pachetul de bază. În al doilea pas, aș recomanda să acordați atenție instrumentelor de rafinare încorporate (designeri de rapoarte, configuratori etc.) - poate un programator full-time va putea face modificările necesare (multe companii le au).

Sarcina tehnică nu trebuie să fie lacomă. Adesea, o afacere își supraestimează capacitățile sau vrea să obțină „totul deodată”. Această abordare nu este justificată nici din punct de vedere al banilor, nici din punct de vedere al afacerilor. Un furnizor, de regulă, nu există de câteva săptămâni (în cazul RegionSoft - 15 ani), și îl puteți contacta după un timp, când înțelegeți cu adevărat ce lipsește în CRM.

Un exemplu viu de redundanță literalmente de ieri: un client a cumpărat ERP-ul unei companii ruse cunoscute, crezând că, deoarece contabilitatea funcționează, atunci ERP-ul acestui furnizor va fi bun. ERP s-a dovedit a nu fi prea bun în sine, dar foarte nepotrivit pentru afaceri. Dar RegionSoft CRM cu contabilitate de depozit și producție este potrivit. Există o soluție: uitați de ERP, plângeți, integrați contabilitatea 1C cu noul CRM și bucurați-vă de implementarea convenabilă. Dar banii umflați sunt păcat! Iar clientul cere să integreze CRM cu ERP. Nu am făcut asta, dar de ce o astfel de risipă, de ce două sisteme relativ similare?

Termenii de referință trebuie să fie realiști și realizabili- atât în ​​ceea ce privește cerințele, cât și termenele limită. Aici este important să ascultați părerea vânzătorului, deoarece el știe exact cât timp va dura pentru o anumită sarcină. Crede-mă, nu este profitabil pentru un dezvoltator să joace timp și să încheie termenul - este benefic pentru el să finalizeze cât mai multe proiecte și să o facă bine pentru a nu primi o lovitură la adresa reputației sale. În ceea ce privește realismul, evitarea solicitărilor de finalizare a CRM la nivelul unui sistem de control al coliderului este simplă: ar trebui să includeți în cerințe ceea ce este cu adevărat necesar în acest moment și în viitorul apropiat.

De exemplu, RegionSoft CRM este un program desktop, nu avem un client de browser. A ne cere să creăm o aplicație web pentru o singură companie este inutil, aceasta este o dezvoltare majoră, este în prezent în curs și nu este o posibilă perfecționare pentru o singură companie. Nu, desigur, totul are prețul său, dar din nou - în cazul general, cerința este imposibilă.

Nu trebuie confundat cu situația când vine vorba de dezvoltare personalizată și ideea și logica aplicației se schimbă radical, de fapt, crearea de software nou „pentru sine” este sponsorizată. Dar asta e altă poveste.

Specificația trebuie detaliată. Este necesar să se indice toate detaliile semnificative ale viitorului proiect: de la frecvența utilizării programului până la dorințele pentru interfață. Cu cât cerințele sunt mai detaliate, cu atât implementarea și testarea vor fi mai ușoare și mai rapide. Merită să acordați atenție detaliilor dacă lucrați într-o anumită industrie (medicină, asigurări, bănci) - o prezentare detaliată a nuanțelor interacțiunii dintre afacere și program va asigura că vânzătorul înțelege sarcina și adaptează rapid sistem către compania dumneavoastră.

Asigurați-vă că acordați atenție formatelor de numere, numelor de câmpuri, prezenței sau absenței listelor derulante, comportamentului butoanelor și sugestiilor și tipurilor de date. Dacă clientul folosește propriile formule care trebuie incluse în logica CRM ( de exemplu, calculul bonusurilor dealerilor), aceste formule trebuie scrise cu o explicație completă a denumirilor lor și a logicii de calcul.

Da, software-ul corporativ arată cam așa și există o mulțime de lucruri mici importante în el.

Termenii de referință trebuie să fie clari și precisi. Formulare vagă, opțiuni de implementare, cerințe neclare - toate acestea sunt o cale către o fundătură. Se întâmplă ca un client, din bune intenții, să scrie în TOR mai multe opțiuni pentru comportamentul sistemului, care sunt apropiate, dar nu echivalente. În acest caz, el este sigur că ajută, îl îndeamnă pe programator, dar, de fapt, drumul spre iad este pavat cu bune intenții; dezvoltatorul trebuie să înțeleagă exact de ce este nevoie și va alege el însuși cum să o facă, pe baza caracteristicile sistemului și teancul de tehnologii utilizate.

Anul acesta vă puteți pune din nou o dorință. Doar te rog, nu-l irosește cu ceva ce nici măcar eu nu pot îndeplini, cum ar fi cerințe clare de afaceri!

Termenii de referință trebuie să fie redactați în limbaj uman.Și acest lucru este important, nu, IMPORTANT. Voi evidenția două situații în care problemele cu limbajul duc la o întârziere în implementarea proiectului.

1. Clientul încearcă să-și demonstreze cunoștințele tehnice și construcții de garduri precum: „implementați o fereastră cu un indiciu în corpul calendarului cu capacitatea de a reacționa la un apel de eveniment...” în loc de „ar trebui să apară o fereastră în calendar în care puteți marca sarcina ca finalizată”. Dacă dumneavoastră sau expertul dumneavoastră intern nu aveți abilitățile de a scrie texte tehnice, nu căutați pe google - scrieți în cuvinte obișnuite, le înțelegem.

   Termenii de referință nu ar trebui să fie o carte de reclamații. Trebuie să rezolvăm problema, nu să o descriem, acordând atenție fonturilor și uitând de descrierea cerințelor. TOR ar trebui să conțină nu numai problema în sine, ci și soluția acesteia la nivel de înțelegere - atunci dezvoltatorul o va rezolva deja la nivel de cod. Comparaţie „departamentul de vânzări planifică prost, pierde cifre, ne luptăm de un an”Și „este necesar să se creeze un raport care să salveze lunar valorile planului și faptul vânzărilor, în contextul grupelor de produse”.

   Termenii de referință ar trebui să poată privi spre viitor. Ei bine, nu tocmai asta, ci oamenii din spatele lui. Dacă se știe că în curând vor avea loc schimbări în procesele de afaceri, acest lucru trebuie luat în considerare pentru a nu plăti revizuirea de două ori.

   Termenii de referință nu trebuie să fie birocratici. Dacă ai întocmit vreodată acest document, trebuie să fi simțit cât de greu este să eviți tentația de a aluneca în birocrație, să adaugi cuvinte introductive, rânduri stricte și să descrii fiecare articol ca pe un articol din Codul Penal (de preferință cu pedeapsă pentru toată lumea pt. încălcare). Formularea birocratică maschează o înțelegere incompletă a obiectivelor creării TK. Responsabilitatea vânzătorului este precizată în contract, acolo este scris și bugetul. Nu trebuie să transferați aceste puncte către sarcina tehnică.

   Termenii de referință trebuie să fie termenii de referință. Sună paradoxal, dar adesea în loc de specificații tehnice citim scrisori, reclamații, contracte, instrucțiuni nou scrise pentru CRM sau procese verbale de întâlnire. Desigur, este imposibil să lucrezi la un astfel de document. Pentru a nu scăpa de formă și conținut, folosește trucul din vechea școală: uită-te la termenul cuvânt cu cuvânt. Tehnic înseamnă că dictează rafinament, tehnică, are ca scop rezolvarea problemei prin schimbarea software-ului. Aceasta este sarcina în contextul software-ului și trebuie să vorbiți. O sarcină înseamnă a pune o întrebare, o problemă, fără sfaturi, indicii și estimări preliminare. Doar o declarație a problemei.

   S-au terminat poruncile, acum mustrarea

   Pe lângă regulile de mai sus, mai sunt câteva lucruri despre care merită să vorbim. Vorbim despre obiective, planuri și așteptări - toți cei care pleacă care fac ca proiectul să aibă succes, iar relația dintre vânzător și client este aproape prietenoasă.

   Termenii de referință trebuie redactați rapid, chiar dacă vă confruntați cu sarcina de a automatiza procesele unui operator de telefonie mobilă sau unui mare hipermarket. Acest lucru se datorează faptului că tehnologiile se dezvoltă cu o viteză extraordinară și chiar și sistemul pe care îl implementați poate supraviețui unei lansări majore (și, uneori, două) în șase luni sau un an, obține o nouă funcționalitate. Poate fi necesar să se reconsidere nevoia de îmbunătățiri și să se reia procesul.

   

   
   În cele din urmă, a găsit timp să termine TK-ul. Dar, din păcate, nu au mai rămas dezvoltatori care să-l implementeze.

   Clientul nu cunoaște stiva și limitările tehnice.Și nu ar trebui să știe - aceasta este sarcina vânzătorului, el este cel care evaluează munca după întocmirea termenilor de referință. Clientul nu ar trebui să se aprofundeze în tehnologie și să întrebe fiecare virgulă dacă vânzătorul poate face asta sau acela. Elaborați un TOR cuprinzător și dezvoltatorul va alege arhitectura potrivită - adesea chiar mai bună decât ați putea crede.

   Estimați-vă bugetul și evitați surprizele neplăcute- aproape sarcina comună numărul unu. Nu trebuie să trageți vânzătorul și să cereți de la el o evaluare aproximativă a lucrării (bine, cel puțin aproximativ, de la mână, cu ochii, dar ca și alții, ei bine, în proiecte de acest tip, dar din experiență, bine, bine, în cadrul marja de eroare). O estimare a bugetului complet este posibilă numai după citirea, analiza și aprobarea finală a termenilor de referință. Dacă dezvoltatorul dvs. face altfel, pregătiți-vă pentru faptul că revizuirea va costa cel puțin de două ori mai mult.

   Porniți de la nevoia obiectivă de schimbări și extinderi- Am scris mai sus că dezvoltatorul nu dispare și este gata să facă oricând modificări și completări conform cerințelor dumneavoastră. Prin urmare, nu încercați să creați imediat vise CRM / ERP, nu solicitați de la vânzător butonul „Totul funcționează în timp ce beau cafea” - lucrați în sistem, identificați comentariile critice pentru dvs. și începeți să colectați cerințe și să redactați specificații tehnice .

   Puteți scrie la nesfârșit despre sarcini tehnice, acesta este un adevărat generator de meme și povești, ci și o durere de cap. Puteți vorbi despre priorități și reguli de proiectare, despre GOST 1989, care face TK inuman, despre standardele IEEE, care sunt puțin mai bune, despre prototipuri și TK care le completează. Dar, în cele din urmă, aș dori să mă limitez la una, cea mai importantă regulă: termenii de referință nu sunt o regulă de drept, nu GOST și nu o dogmă, prin urmare, dacă poți îmbunătăți - îmbunătăți, poți simplifica - simplificați, o puteți face cu grație și astfel încât tuturor să placă - fă-o. Sunt sigur că după asta nimeni nu își va băga nasul în TK și nu va spune că asta nu este scris acolo. Sau aproape nimeni.

   Pe tot parcursul lunii decembrie, oferim reduceri pentru RegionSoft CRM și pentru toate software-urile dezvoltate de noi. De la 1 decembrie până la 15 decembrie - 15% și condiții de rate și închiriere cool. Nu avem -70% și -90%, pentru că păstrăm un preț justificat economic pentru licențe, și nu-l luăm din plafon.

   Ei bine, dacă aveți nevoie de un sistem CRM (cu sau fără modificare), atunci accesați siteul nostru, există multe despre CRM, beneficiile sale și alte software-uri corporative.

   Și da, căutăm mereu parteneri care sunt gata să vândă CRM și alte produse, să îmbunătățească și să vândă CRM, să vândă software și să formeze utilizatori. Împărțirea veniturilor este corectă și benefică partenerului. Arată, spune, învață. Scrie la [email protected]

   Diapozitive, diapozitive. Benzi desenate preluate de pe http://www.modernanalyst.com/ și de pe Pinterest. Dacă există o traducere mai bună, vom fi bucuroși să o includem în postare.

Mulți se confruntă cu faptul că este destul de dificil să explicăm pe scurt și clar ceea ce ne dorim în viața de zi cu zi. Și atunci când trebuie să încredințați o sarcină unui specialist pentru a scrie un program pentru o organizație sau un antreprenor individual, ținând cont de caracteristicile și de propriile dorințe de funcționalitate, atunci puteți, în general, să „atârnă”.

Cine ar trebui să scrie TOR?

Desigur, termenii de referință trebuie să fie furnizați de client, pentru că cu siguranță își cunoaște nevoile și capacitățile. Dar, după cum arată practica, marea majoritate a clienților nu sunt competenți în domeniul 1C. De aceea, interpretul însuși este adesea forțat să se aprofundeze în nevoile clientului, să înțeleagă ce produs final are nevoie și, în consecință, să aranjeze toate acestea în scris pentru programator.

De ce este nevoie de o specificație?

Într-o situație ideală, cu una sau alta rafinare în produsul software 1C, este necesară o sarcină tehnică. În primul rând, trebuie precizate sarcinile, termenele limită și metoda de execuție.

Acesta este un document important, deoarece în cazul oricăror probleme controversate, elaborarea competentă a termenilor de referință va fi punctul de plecare al negocierilor.

Pentru a întocmi sau nu o specificație tehnică - fiecare decide singur, dar acest lucru cu siguranță nu va fi de prisos: va simplifica comunicarea cu clientul și va conferi lucrării un caracter de afaceri și concret.



Să desemnăm o listă cu cele mai importante elemente care ar trebui să fie în termenii de referință:

1. Scop / Sarcină. Formulați ce ar trebui implementat în final.

2. Descriere. Descrieți pe scurt conținutul îmbunătățirilor planificate.

3. Metoda de implementare. Descrieți în detaliu metodele prin care se dorește atingerea scopului. Este necesar să înregistrați toate caracteristicile sarcinii în limbajul de programare: registre, directoare (creați-le sau editați-le); proiectarea interfeței etc. Pentru cei care nu sunt familiarizați și au auzit doar ceva despre un anumit limbaj de programare, vă sfătuim să nu faceți încercări inutile de a „vorbi” într-un limbaj tehnic. pentru că În mod ideal, o descriere este o afirmație uscată care exclude ambiguitatea și posibilitatea unor întrebări inutile. În plus, acest paragraf poate include un exemplu despre modul în care o astfel de programare a fost deja făcută undeva.

4. Evaluarea muncii. Acest articol este foarte important - trebuie să descrie costurile forței de muncă.

Încă două puncte importante: există standarde aprobate pentru scrierea specificațiilor tehnice - GOST. Ele sunt rar folosite acum, dar unii clienți pot cere să le folosească în mod vechi.

Și în al doilea rând, atunci când lucrarea este predată, poate apărea așa ceva - „dar ți-am cam cerut să faci asta și asta atunci ...”. Există șansa ca va trebui să începi să faci totul de la bun început.

Prin urmare, repetăm ​​că un TOR bine scris va fi util atât pentru client, cât și pentru antreprenor.

Exemplu de TOR pentru un programator

Termeni de referință 1C pentru revizuirea prelucrării externe


Ţintă
Este necesar să configurați încărcarea datelor de la 1C în AWP-ul băncii.


Descriere

În legătură cu trecerea organizației la configurația 1C „Salariul și personalul unei instituții de stat”, este necesară dezvoltarea altor procesări care să realizeze funcționalități similare pe noua configurație.

Încărcarea datelor ar trebui să se bazeze pe documentele „Cerere de deschidere a conturilor personale ale angajaților” și „Declarație de plată a salariilor către bancă”.


Datele inițiale

Procesare disponibilă pentru configurația 1C „Salariul unei instituții bugetare”, care încarcă date din documentul „Cerere de deschidere a conturilor personale ale angajaților” și alte directoare și se înregistrează într-un fișier DBF pentru schimbul de date cu o bancă standard AWP.

Procesarea descarcă datele în câmpurile TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN, informații relevante din configurația 1C introdusă anterior în documentul specificat și alte tabele contabile. Se încarcă numărul de personal, numele complet al angajatului, datele sale de pașaport și adresa, ziua de naștere și cetățenia.


Mod de implementare

Acestea vor fi rapoarte externe și procesare folosind mecanismul de extensie, dacă parametrii actuali de compatibilitate a bazei de date și capabilitățile platformei o permit. Când schimbați configurația bazei de date, ar trebui să creați: directoare, documente, registre.


Evaluare job

P Sunt necesare 5 zile lucrătoare de lucru al programatorului.