Sarcina tehnică pentru rafinament în eșantion. Sarcina tehnică TK privind modernizarea ventilației în institutele de cercetare

Pavel Molanov.

Amintiți-vă de legea lui Murphy? Dacă este posibil să nu fiți înțeles corect, veți fi cu siguranță înțeles corect. Acest lucru este corect nu numai în comunicarea între oameni, ci și în crearea de site-uri. Clientul dorea cel de-al doilea "Facebook" și a primit forumul de crescători de câini tineri. Dezvoltatorul nu a ghicit liste de dorințe ale clientului - a petrecut timpul pierdut.

În acest ghid, vă voi spune ce și de ce trebuie să scrieți în lansarea tehnică. În același timp, voi arăta cum nu este necesar să scriem că crearea TK nu se înfășoară în timp petrecut.

Articolul va fi util:

• Toți cei care sunt legați de crearea de site-uri: dezvoltatori, designeri, cameramenii.
• Manageri de proiect.
• Șefii studiourilor Didjital.
• Antreprenorii care intenționează să comande dezvoltarea site-ului.

Pentru ca materialul să fie bun, am colectat comentarii de la mai mulți dezvoltatori, designeri, manageri de proiect și proprietari ai studiourilor Dijital. Cel mai valoros adăugat la sfârșitul articolului. Să înțelegem.

Care este cea mai mare parte și de ce este necesar

Sarcina tehnică este un document în care sunt înregistrate cerințele pentru site. Cei mai clară, aceste cerințe sunt pictate în detaliu, cu atât mai bine toți participanții la proces înțeleg ce ar trebui să fie. Deci, crește șansa ca toată lumea să rămână satisfăcută de rezultat.

Scopul principal al sarcinii tehnice: asigurați-vă că clientul și contractantul se înțeleg reciproc corect.

Utilizarea unei multe sarcini tehnice. Pentru fiecare parte este proprie.

Utilizați pentru client:

• Înțelegeți ce plătește bani și care va fi site-ul. Puteți vedea imediat structura, înțelegeți ce și cum va funcționa. Frecvență, dacă totul satisface. Dacă nu, schimbați fără probleme înainte de începerea dezvoltării.
• A se vedea competența artistului. Dacă cadrul tehnic este clar și clar - încrederea în dezvoltator crește. Dacă porridge este scris acolo - poate că merită să se rostogolească și să nu se uite în jur.
• Îndreptați-vă împotriva lipsitenței artistului. Când site-ul este gata, acesta poate fi verificat în funcție de sarcina tehnică. Există inconsecvențe? Dezvoltatorul trebuie să le corecteze. Dacă cooperezi oficial și a încheiat un contract - chiar puteți forța prin instanță.
• Simplificați înlocuirea artiștilor interpreți sau executanți. În cazul în care clientul și dezvoltatorul s-au maturizat și au fugit, crearea site-ului poate fi puternic întârziată. Când există o economie detaliată, aceasta poate fi transferată într-o echipă nouă - se va transforma în lucru uneori mai repede.
• Aflați costul dezvoltării unui produs complex. Evaluați timpul exact și costul dezvoltării unui serviciu web complex nu poate fi selectat. Mai întâi trebuie să înțelegeți cum va funcționa serviciul și ce funcții vor fi în ea. Pentru a face acest lucru și trebuie să pregătiți piața cazului.

Beneficiul pentru artist:

• Înțelegeți ce vrea clientul. Clientul este pus de zeci de întrebări, arată exemple, oferă soluții. Apoi scrieți totul într-un singur document și coordonați. Dacă totul este bine, ați înțeles corect.
• Îndreptați-vă împotriva apelor bruște ale clientului.Uneori există clienți care doresc să schimbe sarcina de la jumătatea drumului. Dacă ați fost de acord și ați semnat TK, nu sunteți teribil de similari. Caz în care, chiar și instanța va fi de partea dumneavoastră.
• Arătați-vă competența. ÎNTREȚINEREA PREGĂTĂȚII PRECITATELOR VA ARAZA CLIENTUL CUPRINSUL DEVOZITELOR. Dacă compania sa îndoit dacă să aibă încredere în dezvoltarea site-ului, se îndoiește cu un separă de mare probabilitate.
• A castiga bani. Unele studiouri și dezvoltatori oferă compilarea TK ca un serviciu separat.

• Facilitarea și accelerarea procesului de dezvoltare. În bună tk, structura site-ului, sunt indicate funcțiile și elementele necesare pe fiecare pagină. Când toate cerințele sunt deja înainte de ochii noștri - rămâne doar pentru a merge un cod sasy și de scriere.

Acum, să ne dăm seama cum să facem o economie bună care îndeplinește toate aceste funcții.

Întreținerea este un interpret

În general, piața poate face pe nimeni. "Avem nevoie de o carte de vizită pentru o clinică dentară" - aceasta este deja cea mai mare parte. Dar își va îndeplini funcțiile? Improbabil.

Bun TZ este întotdeauna artistul: manager de proiect sau dezvoltator. Evident, dezvoltatorul web înțelege crearea de site-uri mai mult decât proprietarul unei cafenele sau clinica dentară. Prin urmare, pentru a descrie proiectul îl va avea pentru el.

Acest lucru nu înseamnă că clientul dispare și apare chiar la capăt pentru a scrie: "Zbs, aprobând". De asemenea, ar trebui să participe la acest proces:

Desigur, clientul poate desena propria versiune a TK. Poate că acest lucru va accelera procesul de creare a economiei finale. Și poate că se dovedește gunoiul, care este în liniște aruncat în gunoi.

Scrieți cu siguranță și cu precizie

Acest sfat rezultă din obiectivul principal al pieței cazurilor - "Asigurați-vă că clientul și interpretul se înțeleg corect unul pe altul".

În sarcina tehnică nu ar trebui să fie adjective de înaltă calitate: frumos, fiabil, modern. Ele nu pot fi înțelese fără echivoc. Toată lumea are propriile sale concepte de frumusețe și modernitate.

Uite. Cineva la urma urmei, a considerat acest design frumos și a permis să utilizeze pe site-ul său web:

Același lucru - cu formulările vagi care nu înseamnă nimic singur:

• Site-ul ar trebui să-i placă clientul. Și dacă are o dispoziție proastă?
• Site-ul trebuie să fie convenabil. Ce înseamnă? Convenabil pentru ce?
• Site-ul trebuie să reziste la sarcini grele.10 mii de vizitatori? Sau 10 milioane?
• Conținutul de experți calitativi. Ei bine, ați înțeles.

Verificați dacă nu există ambiguitate în text. Dacă există - rescrie. Formularea dvs. trebuie să fie clară și exactă:

• Site-ul ar trebui să fie descărcat rapid → Orice pagină a site-ului trebuie să aibă mai mult de 80 de puncte în Insightele Google PagesPeed.
• Încărcături mari → 50 de mii de vizitatori în același timp.
• Pagina principală afișează o listă de articole. → Ultima pagină afișează o listă a ultimelor 6 articole publicate.
• Interfață de abonament ușor de utilizat cu utilizatorul → câmpul "Lăsați e-mail" și "Abonați-vă" → * Schiță trasă *.

Ne-am dat seama de formularea, să fim în structură.

Specificați informații generale

Toți membrii echipei ar trebui să înțeleagă corect ce face compania și care este audiența ei țintă. Astfel încât nimeni nu este confundat, este mai bine să se înregistreze la începutul pieței cazurilor.

Și totuși ar trebui să specificați scopul site-ului și să descrieți funcționalitatea pe scurt - pentru a nu obține un magazin online în loc de un blog.

Explicați termenii complexi

Prima regulă a designului tehnic - ar trebui să fie clară pentru toată lumea pentru care este destinată. Dacă veți folosi termenii care nu pot înțelege clientul dvs. - proprietarul unui magazin de jucării pentru copii - asigurați-vă că le puteți explica. Limba de înțelegere, nu o copie-paste de la Wikipedia.

Descrieți instrumentele și cerințele de găzduire

Imaginați-vă că ați făcut 2 luni un site răcoros. Fiecare etapă a fost coordonată cu clientul - este încântat. Și acum este timpul să luăm un loc de muncă. Afișați panoul de administrare, iar client strigă: "Ce este? Modex?! Credeam că o vei face pe "WordPress"!

Astfel încât să nu existe astfel de probleme, să descrieți instrumentele, motoarele și bibliotecile utilizate. În același timp, specificați cerințele pentru găzduire. Niciodată nu știți, veți face pe PHP - și clientul serverul este pe .net.

Listează cerințele pentru site

Site-ul ar trebui să funcționeze în toate browserele de versiuni topice și pe toate tipurile de dispozitive. Da, este evident pentru orice dezvoltator și orice client. Dar este mai bine să scrieți pentru a proteja clientul de la locul de muncă complet finalizat.

De asemenea, veți scrie cerințele pentru viteza de descărcare a site-ului, stabilitatea la încărcături, protecția împotriva atacurilor hackerului și a lucrurilor similare.

Specificați structura site-ului

Înainte de începerea proiectării și aspectului, trebuie să fiți de acord cu clientul structurii site-ului.

Job cu clientul, afla ce are nevoie. Colectați dezvoltatorii, Soshechnikov, comercianții, comandanții - și decideți ce pagini sunt necesare pe site. Gândiți-vă cum vor fi interconectați, cu care puteți merge.

Puteți afișa lista de structuri, puteți desena o diagramă bloc. După cum preferați.

Aceasta este una dintre cele mai importante etape de lucru de pe site. Structura este o fundație. Dacă este nereușită - site-ul se va dovedi a fi o curbă.

Explicați ce se va întâmpla pe fiecare pagină

Clientul trebuie să înțeleagă de ce fiecare pagină are nevoie și ce elemente vor fi pe ea. Există două modalități de a arăta.

Prototip - mai mult mod vizual și mai ambiguu. Artistul atrage schițe ale fiecărei pagini și le face la lansarea tehnică. Clientul vede modul în care va arăta interfața viitorului său site și spune că îi place și ce merită să se schimbe.

Enumerarea elementelor - Alternativă leneș la prototip. Doar scrieți ce blocuri ar trebui să fie pe pagină și ce fac.

Site de canalizare Utilizați scenarii

Dacă faceți o interfață non-standard, arată doar structura și schițele paginilor nu sunt suficiente. Este important ca întreaga echipă a artiștilor interpreți sau client să înțeleagă modul în care vizitatorii vor folosi site-ul. În acest scop, scripturile sunt minunate. Schema de script este foarte simplă:

• Acțiunea utilizatorului.
• Răspunsul site-ului.
• Rezultat.

Desigur, dacă faceți o carte de vizită standard sau împrumuturi, nu aveți nevoie să scrieți scripturi. Dar dacă există anumite servicii interactive pe site - este foarte de dorit.

Citiți mai multe despre utilizarea scenariilor în Wikipedia.

Determinați cine este responsabil pentru conținut

Unii dezvoltatori fac site-ul imediat cu conținut. Alții au pus pește. Al treilea poate scrie texte, dar pentru o taxă suplimentară. Acceptați acest lucru pe țărm și fixați-vă în lansarea tehnică, ce conținut ar trebui să vă pregătiți.

Vino cu criterii obiective pentru evaluarea calității textelor sunt destul de dificile. Este mai bine să nu scrieți nimic decât conținut de înaltă calitate, interesant și de vânzare, util pentru publicul țintă. " Aceasta este gunoi, el nu are nevoie de nimeni.

Indicați că întregul conținut trebuie să fie unic - este util. O altă protecție a clientului de la artiștii fără scrupule.

Descrieți designul (dacă puteți)

Ca și în cazul textului, criteriile obiective pentru estimarea designului site-ului rezultă dificil. Dacă ați fost de acord cu clientul despre schema de culori - scrieți-l. Dacă are un brandbook, în care sunt prescrise fonturile - specificați-le.

Scrierea despre designul frumos și modern nu este necesară. Nu înseamnă nimic, nu are putere și în general Fu.

În loc de retragere: structura în vrac

Pentru diferite sarcini, structura lui Tk va fi a lor. Este prostie pentru a face aceleași sarcini tehnice pentru o nouă rețea socială și pentru transportul cu ridicata al morcovilor. Dar, în general, aveți nevoie de aceste secțiuni:

• Informații despre companie și publicul țintă, obiectivele și obiectivele site-ului.
• Glosar de termeni care pot fi incomprehensibil clientului.
• Cerințe tehnice pentru aspect și site de lucru.
• Descrierea tehnologiilor utilizate și a unei liste de cerințe de găzduire.
• Structura detaliată a site-ului.
• Prototipurile paginilor sau descrierea elementelor care ar trebui să fie pe ele.
• Scenarii de utilizare a unei interfețe non-standard (opțional).
• Lista conținutului care face dezvoltatorul.
• Cerințe de proiectare (opțional).

• Reguli pentru compilarea specificațiilor cerințelor software. SRS este următorul pas al evoluției bulgării. Nevoie de proiecte mari și complexe.
• Standardele și șabloanele TK pentru dezvoltarea de software. Descrierea diferiților invitați și metodologii pentru crearea de sarcini tehnice.

Acesta este sfârșitul părții pe care am scris-o. Dar există alte comentarii de către specialiștii care au ajutat la Hyde. Citiți, este, de asemenea, interesant.

Comentarii Dezvoltatori

Am vorbit cu mai mulți dezvoltatori pentru a afla cum fac în vrac. Eu transmit microfonul lor.

În primul rând, TK trebuie să fie client - astfel încât să înțeleagă ceea ce va fi site-ul său și ce bani merg. Dacă ceva nu este făcut așa - se poate referi la TK și va cere remake-ul.

TK este managerul de proiect după comunicarea cu clientul și discutați sarcina cu designerul.

Clienții mari solicită adesea un TK foarte detaliat, în care este descris fiecare buton. Companiile mici, dimpotrivă, nu-i plac documentele meticuloase pentru 100 de pagini. Citiți lung și ușor să pierdeți ceva important. Mai des facem Laconic TK pentru 10-15 pagini.

Specificăm:

• Informații despre companie și scopul site-ului.
• Cerințe de proiectare, Gama de culori.
• Tehnologii folosite și CMS.
• Care se ocupă de conținut - suntem sau clienți.
• Structura site-ului este de până la fiecare pagină.
• Descrierea fiecărei pagini. Nu prototipe, dar indică faptul că elementele ar trebui să fie pe pagină și cum ar trebui să funcționeze.

Ultimele două secțiuni sunt cele mai importante. Aceștia oferă o înțelegere care va fi site-ul și cum va funcționa.

Punct foarte important - este imposibil să dați doar designul tehnic dezvoltatorilor și sperăm că vor face totul bine. TK este o listă de site-uri pentru site, nu poate înlocui comunicarea. Este important să se asigure că fiecare membru al echipei înțelege un obiectiv comun și nu doar îndeplinește sarcini pe pârâu. Dacă ceva este incomprehensibil - este necesar să se explice, să discute, să dea comentarii detaliate.

Dacă treceți prin site-uri străine cu o cerere "Document de Cerințe de Produs", puteți găsi articole creative și convingătoare despre faptul că a murit sarcina tehnică (TK, PRD). În parte, este necesar să se conștientizeze - la dezvoltarea unui produs de la zero, prototipul pare mult mai interesant și mai eficient decât volumul înregistrărilor clientului, uneori foarte neprofesional. Cu toate acestea, dacă vorbim despre rafinamentul sistemului de bază, atunci este nevoie de o întoarcere complet diferită. Suntem configurați cu rafinament și cu dezvoltarea personalizată, așa că câinele a mâncat câinele dacă bucătarul nu ne mințește. În general, astăzi - despre cele mai clasice sarcini tehnice care sunt scrise pe rafinamentul software-ului achiziționat și instalat. Pe scurt, despre durere.

Motivul interacțiunii

Înainte de a trece la pregătirea procesului de creare a unei alocări tehnice, să vorbim despre un cvadriclu în care interpretul și clientul intră în proiect.

Cerințe- comportamentul dorit al sistemului descris de client sau deținătorul procesului care urmează să fie implementat. De regulă, cerințele sunt formate pe baza experienței de muncă, prezentarea comportamentului adecvat al programului. Acestea sunt informații cheie pentru dezvoltator (furnizor), însă este în stadiul de colectare a cerințelor pe care se ridică cel mai mare număr de coliziuni, erori, cereri inutile și așa mai departe.

Resurse - Oameni, mașini, echipamente, mediu de dezvoltare, timp și bani care urmează să fie utilizate în procesul de punere în aplicare a cerințelor. Resursele necesită o planificare și o evaluare clară în stadiul de aprobare a sarcinii tehnice. Plasarea competentă a priorităților de la client și distribuția resurselor de muncă de către furnizor vă permite să evitați să rupăm calendarul și să minimalizați alte riscuri.

Capabilități - Dacă scurt, atunci acesta poate face furnizorul (performer). Luați în considerare în exemplul RegiuniSoft CRM. Clientul cumpără sistemul și alcătuiește activitatea de rafinament: trebuie să creați integrarea cu site-ul și evenimentele de legare în CRM la numărul comenzii online al magazinului. Aceasta este o cerință cu adevărat efectuată, avem o resursă și posibilitatea de a face acest lucru. Și trebuie să se dezvolte și să se fixeze la CRM CMS, sistemul de management al conținutului site-ului. Teoretic, putem acest lucru, dar nu avem ocazia să o facem ieftin, iar clientul nu are ocazia să ne plătească atât de mult pentru a arunca resursele umane și temporare sarcinii. Ca urmare, clientul refuză să refuze această cerință - iar CMS nu este deosebit de necesar, totul este atât de bun. Dar despre "lăcomia" tz- mai târziu.

Restricții - un set de obstacole care fac sarcinile de la TK dificile sau imposibile: bugetul, stiva tehnologiei, problemele licențiate, interdicțiile legislative, configurațiile hardware și așa mai departe.

Astfel, toate cele patru entități sunt strâns legate între ele și determină succesul proiectului ca întreg. Luați în considerare fiecare element și încercați să evidențiați momentele critice pe care trebuie să le rețineți să lucrați la sarcina tehnică.

Colectarea și analiza cerințelor

Acesta este un proces corporativ foarte important, în timpul căruia se dovedește că vor de la program (aici și apoi luăm CRM, ci metode lucrează cu alte tipuri de software) potențiali utilizatori. Dacă contactați un tip de furnizor de tip Vendor Sap sau Integrator System, atunci cu o mare probabilitate de probabilitate, vi se va oferi să utilizați serviciile unui consultant de afaceri (este un manager personal, el este managerul de cont, el este "acum dvs. Reprezentant în compania noastră "). De fapt, în majoritatea cazurilor este o piață obișnuită de vânzări tranzacționate, care are două sarcini: pentru a transforma costul proiectului și nu vă lasă să coborâți de pe cârlig.

Este deja aici o oră și nici măcar nu a atins bordul markerului alb. El nu este un analist real de sistem

Mai bine decât tine și angajații tăi, nimeni nu știe compania ta. Deci, colectarea și analiza cerințelor este exclusiv sarcina dvs. în care vânzătorul poate ajuta și trimite, dar în nici un caz nu poate interveni în acest proces. Adresați-vă dezvoltatorului despre implementări similare, verificați ce să plătiți atenția și continuați. Apropo, un bun asistent poate fi angajatul dvs. care cunoaște bine în subiectul de profil și reprezintă aproximativ arhitectura software-ului și un semn cu procesul de dezvoltare - poate acționa ca analist și un expert intern, pentru a închide procesul de creare a procesului Tk și comunicarea cu vânzătorul.

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

1. Creați un grup de lucru de la manageri și specialiști cu experiență de unități care vor utiliza CRM. Spuneți-ne despre soluția care ar trebui să aleagă, să ofere acces la versiunea demo.
2. Membrii grupului de lucru trebuie să transfere informații angajaților și să solicite dorințele lor la noul program în formă absolut gratuită. Dacă cineva de la angajați nu a întâlnit niciodată un astfel de software și nu este gata să vorbească în aspectul utilizării viitoare, trebuie să-l cereți să descrie sarcinile dvs. periodice, aceasta este o abordare universală.
3. Apoi, fiecare unitate se stabilește, care nu este în CRM sau ceea ce nu se potrivește și agregă informațiile.
4. Grupul de lucru analizează cerințele colectate, verifică și elimină intersecția. De exemplu, deseori departamentul de vânzări și departamentul de marketing sunt comandate de același raport, dar în cerințele pot fi numite domenii și entități în moduri diferite, deși datele din spatele lor sunt aceleași. În consecință, trebuie să ajungeți la o singură formă.
5. Grupul de lucru generează o listă de cerințe și pune priorități. În acest stadiu, puteți conecta furnizorul deoarece este responsabil pentru resurse. De exemplu, vă puteți cere să creați un raport personalizat pentru Regionsoft CRM și puteți comanda integrarea cu site-ul. Acest lucru este complet diferit în ceea ce privește sarcina, prioritatea este foarte importantă aici.

După ce cerințele sunt colectate, analizate și coordonate cu angajații și gestionarea, puteți începe să creați o sarcină tehnică. Puteți cere forma vânzătorului sau puteți face singur - în orice caz, există mai multe reguli de fier, care vor salva de la durerea de cap și de dvs. și furnizorul dvs. CRM.

Anatomia sarcinii tehnice

Dacă vorbim despre procesul de creare a unei sarcini tehnice, atunci există mai multe etape. Pasajul lor consistent și conduce clientul la rafinamentul dorit. Aici sunt ei.

• Detectarea - definirea cerințelor, problemele de depanare care trebuie rezolvate.
• Analiza - Analiza cerințelor, alocarea nevoilor cheie, generalizarea.
• Adaptarea este o evaluare a cerințelor în contextul capacităților CRM și a proceselor de afaceri existente.
• Documentație - descrierea formală și detaliată a cerințelor, coordonarea TK.
• Comunicarea cu vânzătorul (dezvoltatorul) este o interacțiune iterativă cu furnizorul cu privire la îmbunătățirile în funcție de TK compus.
• Implementarea este activitatea vânzătorului la crearea funcționalității necesare. Este mai bine dacă vânzătorul este în permanență în contact cu clientul - produsul de la ieșire va respecta cu exactitate viziunea clientului.
• Testarea - verificarea funcționalității angajaților furnizorilor, experți interni ai clientului și utilizatorilor finali pentru a stabili conformitatea rafinării și TK, performanța sistemului cu modificări.

În general, sarcina tehnică poate fi creată pe baza cerințelor mai multor niveluri care pot intersecta și coopera la crearea unui proiect sau nu interacționează deloc.

Nivelul de afaceri.- Nivelul global pe care sunt rezolvate sarcini complexe și prioritare. La acest nivel, integrarea, rafinamentul și modelarea proceselor de afaceri pot fi atribuite, dezvoltarea de noi module funcționale. De regulă, este o dezvoltare intensivă a resurselor, cu consultări serioase și o colaborare strânsă cu clientul. De exemplu, la un moment dat în regiunea CRM, o astfel de revizuire personalizată a fost depozitul, biroul de bilete și producția. Treptat, schimbările au intrat în eliberare și mai târziu au permis să creeze un produs nou pentru magazinele cu ridicata, cu amănuntul și hipermarketurile - Retail Retail.

Nivelul utilizatorului sau grupul de utilizatori.La acest nivel, sarcinile sunt implementate cu privire la revizuirea interfeței existente. De exemplu, utilizatorul poate dori ca atunci când deplasați un cursor, apare o fereastră cu numărul și starea ultimei comenzi sau a existat un raport personalizat cu o grupare specială de date. Rafinăria la acest nivel ocupă mai puțin timp, dar pot exista multe dintre ele - de exemplu, mai multe cerințe din partea departamentului de marketing, logistică și suport tehnic.

Nivelul funcționalității. Este adesea dificil să o separați de cel precedent, un criteriu formal funcționează aici - rafinamentul nu este la nivelul de afișare a nimic în interfață, ci la nivelul rafinării logicii sistemului. Aceasta include cerințele pentru diferite sortare, integrare cu capabilități de chat, telefonie.

Nivelul serviciului - De fapt, cerințele acestui nivel ar trebui să fie primele care intră în clădiri noi cu remedii. Acestea sunt sarcini pentru viteza răspunsului sistemului, care lucrează sub sarcină mare, securitate. În versiunea ideală, Vendor nu ar trebui să aibă astfel de îmbunătățiri - Software-ul corporativ nu trebuie să încetinească, să piardă datele, să se prăbușească și să distribuie permisiunile unui nivel. Dar dacă a apărut cerința și nu este legată de paraniza sau problemele personale ale clientului din partea hardware-ului, merită să o acordăm o atenție deosebită pentru el.

Nivelul de tehnologie - Ultima pe listă, dar în importanță și dificultate este înaintea restului. Acestea pot fi cerințele clienților asociate cu platforma, sistemul de operare sau dispozitive. De exemplu, o colecție de asamblare sub MacOS. Este foarte cool, dacă astfel de cerințe se procesează treptat în versiuni, dar există în mod necesar remedieri. Este de la solicitările clienților la acest nivel am realizat un ansamblu ASOFT CRM în cadrul MacOS și a adăugat accesul șters utilizând tehnologia TRM ca o soluție temporară a unei cereri de versiune mobilă rară, dar existentă.

Anatomia sarcinii tehnice este simplă, în orice caz sub forma unui schelet. Părțile obligatorii ale sarcinii tehnice ajută clientul să se concentreze asupra problemei și să formuleze sarcina în mod corect, iar contractantul - să înțeleagă ce vor de la el. Apropo, despre înțelegere. Desigur, la începutul postului, am supraviețuit ușor, refuzând consultanți de afaceri ca o clasă. Aceasta este: Fiecare furnizor funcționează pe piață timp de mai mulți ani (nu suntem cu privire la CRM-o zi), ci și zece ani, ceea ce înseamnă că există un set de cazuri în aproape fiecare industrie. În consecință, inginerii, programatorii și vânzările sunt familiarizați cu specificul implementării în fiecare tip de companie. Dar din nou, este important să vă concentrați asupra afacerii dvs.

Pentru cine?În această secțiune, este necesar să se descrie cine va fi un utilizator finit de rafinament, ce sarcini și cu ce frecvență este planificată să fie rezolvată.

Voi da un exemplu. În aceeași companie a introdus CRM, sa presupus că lucrează la o matrice de date destul de mare (câteva zeci de înregistrări pe lună, câteva sute de mii de înregistrări pe zi). Departamentul șef al vânzărilor a solicitat un raport privind descărcarea acestor înregistrări cu frecvența "zilnic". În mod natural, un astfel de raport cu lucrări simultane sute de utilizatori au încărcat sistemul - au fost găsite deciziile optimizării procesului. Deja în timpul lucrării, sa dovedit că vânzările au fost reconstruite și raportul este necesar numai de rezultatele lunii, iar apoi poate fi lansat pe un program pe timp de noapte. Merită să spuneți că timpul și banii au fost cheltuiți în zadar.

Pentru ce?Justificarea nevoii de rafinament și locul său în procesul de afaceri. Acest articol este mai necesar pentru client în sine, dar și vânzătorul de a ști ce vor fi afectate alte procese. Uneori ajută la găsirea unei soluții alternative.

Ce ar trebui să facă?Cel mai informativ bloc - descrie cerințele, așteptările sistemului. Și aici, foarte perle, miracole și coliziuni, care vin la bashomg și care sunt foarte complicate de viață. Provoca unul - utilizatorul nu știe ce vrea să facă. Există încă un mic subprik - utilizatorul nu poate formula cerințele. Și apoi sarcina dezvoltatorului (grupul de lucru, analitică, dacă este cazul) contribuie la articularea nevoii adevărate, alegeți o cerință exppedentă, introduceți sarcina în contextul sistemului. În același bloc, trebuie să menționați rezultatul așteptat.

Parametrii sarcinii tehnice- Termeni, etape de implementare, responsabilă din toate părțile, contactele necesare și așa mai departe. De fapt, aceasta este o combinație de lucruri formale importante care fac un document cu o sarcină tehnică. Sarcina tehnică trebuie să fie neapărat coordonată și semnată de părți pentru a evita numeroase modificări în dezvoltarea dezvoltării (acestea vor fi în continuare, dar într-un volum mai mic).

În versiunea ideală, sarcina tehnică este compilată cu participarea activă a furnizorului, iar totalul său este aproximativ o astfel de structură:

1. Descrierea cerințelor fiecărui mecanism și a fiecărei funcționalități
2. Descrierea implementării acestei funcții
3. Costul muncii pentru fiecare dintre pașii separat
4. Costul total al lucrărilor la această atribuire tehnică
5. Termeni de execuție a muncii cu o defalcare a etapelor și indicarea scenei
6. Descrierea condițiilor de instalare și testarea
7. Rezervări despre natura exhaustivă a sarcinii tehnice și a altor condiții

10 Reguli scrise de lacrimile dezvoltatorului

Sarcina tehnică de rafinament ar trebui să fie TK privind rafinamentul, nu o descriere de 300 de pagini a CRM, care este necesară pentru client. Înainte de elaborarea cerințelor, trebuie să citiți cu atenție interfața de sistem, capacitățile sale, documentația - cel mai probabil, cea mai mare parte a "Listă de dorințe" se află deja în aprovizionarea de bază. Aș recomanda să acordați atenție instrumentelor de rafinament încorporat (designeri, configurați, etc.) - poate că schimbările necesare vor putea să facă un programator regulat (în multe companii).

Sarcina tehnică nu ar trebui să fie lacomă.Adesea, afacerea se supraestimează capacitățile sau dorește să obțină "totul imediat". O astfel de abordare nu este justificată din punct de vedere al banilor sau din punct de vedere al afacerilor. Furnizor, de regulă, nu există câteva săptămâni (în cazul regiunilor - 15 ani) și puteți să-l contactați și după un timp, puteți înțelege cu adevărat ceea ce lipsește CRM.

Un exemplu luminos de redundanță este literal de ieri: Clientul a cumpărat ERP o singură companie rusă celebră, gândindu-se că contabilitatea contabilă, atunci ERP a acestui furnizor va fi bun. ERP sa dovedit a fi atât de mult în sine, dar foarte nu o afacere potrivită. Dar regiunile CRM cu contabilitate și producție de depozitare este adecvată. Există o soluție: să uitați de ERP, plângeți, integrați contabilitatea 1c cu un nou CRM și bucurați-vă într-o implementare convenabilă. Dar banii fără voce este păcat! Și clientul necesită integrarea CRM cu ERP. Nu am făcut asta, dar de ce o astfel de deșeu, de ce două sistem relativ similar?

Sarcina tehnică trebuie să fie realistă și îndeplinită - Ambele conform cerințelor și timpului. Este important să ascultați opinia vânzătorului, așa cum știe exact la ce oră merge la una sau altă sarcină. Crede-mă, dezvoltatorul nu este profitabil să tragă timpul și să vâneze termenul - este profitabil pentru aceasta să completeze cât mai multe proiecte și să o facă bine pentru a nu primi o lovitură reputației. În ceea ce privește realismul, evitați cererile de a termina CRM la nivelul sistemului de gestionare a coliziunilor pur și simplu: ar trebui să fie inclusă în cerințele a ceea ce este într-adevăr necesar în acest moment și în viitorul previzibil.

De exemplu, regiunile CRM este un program desktop, nu avem un client pentru un browser. Întrebându-ne să creăm o aplicație web pentru o singură companie, este lipsită de sens, este o dezvoltare majoră, se desfășoară acum și nu este posibilă perfecționarea pentru o singură companie. Nu, desigur, totul are prețul său, dar din nou - în general, cerința este impunerea.

Nu este nevoie să vă confundați cu situația în care vine vorba de dezvoltarea personalizată, iar ideea și logica aplicației sunt modificate în rădăcină, crearea unui nou software "pentru dvs." este practic crearea unui nou software. Dar aceasta este o altă poveste.

Sarcina tehnică trebuie să fie detaliată. Trebuie să specificați toate detaliile semnificative ale proiectului viitor: de la frecvența utilizării programului la dorințele de pe interfață. Cu cât sunt stabilite mai multe cerințele, cu atât vor fi implementate și mai rapide și mai rapide. Este deosebit de merită acordată atenție detaliilor dacă lucrați într-o anumită industrie (medicină, asigurare, bănci) - o declarație detaliată a nuanțelor interacțiunii de afaceri și a programului va asigura o înțelegere a sarcinii vânzătorului și adaptarea rapidă a sistemului către compania dvs.

Asigurați-vă că acordați atenție formatelor numerelor, denumirilor câmpurilor, prezenței sau absenței listelor derulante, comportamentului butoanelor și sugestiilor, tipurilor de date. Dacă clientul folosește propriile formule care trebuie să fie așezate în logica lucrării CRM ( de exemplu, calculul bonusurilor de dealer) Aceste formule trebuie să fie scrise cu decodificarea completă a denumirilor lor și logica de calcul.

Da, software-ul corporativ arată așa, și în ea există multe lucruri importante

Sarcina tehnică trebuie să fie lipsită de ambiguitate și exactă. Formularea neclară, opțiunile de implementare, cerințele fuzzy - în acest fel într-un capăt mort. Se întâmplă că un client din bune intenții scrie mai multe opțiuni pentru comportamentul sistemului, aproape, dar nu echivalent cu TP. În acest caz, el este sigur că el ajută, îi spune programatorului, dar, de fapt, intenția bună a drumului spre Iadul dezvoltatorului trebuie să înțeleagă exact ce are nevoie și cum să faceți acest lucru se va alege, pe baza caracteristicilor Sistemul și stack-ul tehnologiilor utilizate.

În acest an puteți da o singură dorință din nou. Numai, vă rog, nu-l pierdeți pe faptul că chiar nu pot îndeplini, cum ar fi cerințele de afaceri ușor de înțeles!

Sarcina tehnică trebuie să fie scrisă în limba umană. Și acest lucru este important, nu, este important. Voi aloca două situații în care problemele cu limba conduc la înăsprirea implementării proiectului.

1. Clientul încearcă să demonstreze alfabetizarea tehnică și arde tipul de tip: "Implementarea unei ferestre cu un indiciu în corpul calendarului cu posibilitatea de a apela un eveniment ..." În schimb ", în calendar ar trebui să fie Afișați o fereastră în care puteți marca sarcina așa cum este efectuată. " Dacă dvs. sau expertul dvs. intern nu aveți abilitățile de a scrie texte tehnice, nu Google - scrieți ca cuvinte obișnuite, le înțelegem.

   Sarcina tehnică nu ar trebui să fie o carte plină de planificare. Este necesar să rezolvăm problema și să nu o descriem, acordând atenție fonturilor și uitarea descrierii cerințelor. TK ar trebui să conțină nu numai problema însăși, ci și soluția sa la nivelul înțelegerii - în continuare dezvoltatorul va decide deja la nivelul codului. Comparaţie "Departamentul de vânzări planifică prost, pierde cifrele, deja lupte pentru un an" și "Trebuie să creați un raport care să păstreze valorile planului și de vânzările lunare lunar, în contextul grupurilor nomenclaturii".

   Sarcina tehnică ar trebui să poată privi în viitor.Ei bine, nu așa, dar oamenii stau în spatele lui. Dacă se știe că vor apărea schimbări în curând în procesele de afaceri, este necesar să se ia în considerare pentru a nu plăti pentru revizuire de două ori.

   Sarcina tehnică nu trebuie să fie birocratică. Dacă cel puțin o dată ați constituit acest document, probabil că ați simțit cât de greu să evitați tentația de a aluneca în birocrație, să se estompeze în cuvintele interioare, la revoluțiile stricte și să descrie fiecare element ca un articol al Codului penal (de preferință cu pedeapsa toată lumea pentru încălcare). Formulările birocratice maschează o înțelegere incompletă a obiectivelor de creare a TK. Responsabilitatea furnizorului este înregistrată în contract, bugetul este scris acolo. Nu purtați aceste puncte în sarcina tehnică.

   Sarcina tehnică ar trebui să fie o sarcină tehnică. Sună paradoxal, dar adesea în loc de TK am citit scrisori, plângeri, contracte, instrucțiuni re-scrise pentru CRM sau procesul-verbal al reuniunii. Desigur, este imposibil să lucrăm pentru un astfel de document. Pentru a nu scăpa de formular și de conținut, utilizați vechiul truc școlar: Luați în considerare termenul conform. Tehnic - înseamnă că rafinamentul este dictat, tehnica vizează rezolvarea problemei prin schimbarea software-ului. Aceasta este sarcina în contextul software-ului și trebuie să vorbiți. Sarcina înseamnă că problema, problemele, fără sfaturi, sfaturi și estimări preliminare. Doar o sarcină de formulare.

   Porțile s-au încheiat, acum recompensa

   În plus față de regulile enumerate, există mai multe lucruri despre care merită să spunem. Vorbim despre obiectivele, planurile și așteptările - toți cei care părăsesc, ceea ce face ca proiectul să aibă succes, iar relația vânzătorului și clientului este aproape prietenoasă.

   Sarcina tehnică trebuie să scrieți rapidChiar dacă aveți sarcina de a automatiza procesul unui operator celular sau a unui hipermarket mare. Acest lucru se datorează faptului că tehnologiile se dezvoltă la o viteză uriașă și chiar sistemul pe care îl implementați, timp de șase luni - pe an poate supraviețui unei lansare majoră (și uneori două), obține o nouă funcționalitate. Poate că trebuie să reconsiderați nevoia de a îmbunătăți și de a începe din nou procesul.

   

   
   În cele din urmă, a găsit timp pentru a completa tk. Dar, din păcate, nu există dezvoltatori în jurul valorii de acolo pentru ao implementa.

   Clientul nu știe despre stivă și limitări tehnice.Și nu trebuie să știe - aceasta este sarcina vânzătorului, este cel care evaluează munca după elaborarea unei sarcini tehnice. Clientul nu ar trebui să fie aprofundat în tehnologie și să ceară fiecare virgulă dacă vânzătorul poate face unul sau altul. Faceți un TK cuprinzător și dezvoltatorul va alege o arhitectură potrivită - adesea chiar mai bună decât credeți.

   Evaluați bugetul și evitați surprizele neplăcute - Aproape un număr comun numărul unu. Nu trebuie să rotiți vânzătorul și să cereți de la ea o evaluare aproximativă a lucrării (bine, cel puțin aproximativă cavitatea, la ochi și ca alții, bine, în proiectele de acest tip, și prin experiență, bine, în cadrul limitele erorii). O evaluare completă a bugetului este posibilă numai după citirea, analizarea și aprobarea finală a sarcinii tehnice. Dacă dezvoltatorul dvs. vine altfel - pregătiți-vă pentru faptul că rafinamentul va costa cel puțin de două ori mai scump.

   Treceți de nevoia obiectivă de modificări și extensii - Am scris mai sus că dezvoltatorul nu dispare și este gata să facă schimbări și completări la cerințele dvs. în orice moment. Prin urmare, nu încercați să creați imediat vise CRM / ERP, nu necesită butonul "Totul funcționează până când beau cafea" - lucrează în sistem, determină comentariile critice pentru dvs. și procedați la colectarea cerințelor și compilarea TK .

   Putem scrie despre sarcinile tehnice infinit, acesta este un generator real nu numai meme și bere, ci și dureri de cap. Puteți vorbi despre priorități și reguli de înregistrare, despre oaspeții 1989, ceea ce face TZ Inhuman, despre standardele IEEE, care sunt puțin mai bune, despre prototipuri și complementare TK. Dar, la final, aș dori să ne limităm la una, cea mai importantă regulă: sarcina tehnică nu este norma de drept, nu GOST și nu dogma, prin urmare, dacă vă puteți îmbunătăți - îmbunătățiți, puteți simplifica - Simplificați-vă poate face elegant și de a face posibil. Sunt sigur, nimeni după aceea nu împinge nasul în tk și nu va spune că nu este scris acolo. Sau aproape nimeni.

   Toate luna decembrie vom da reduceri la Regionsoft CRM și întregul software al dezvoltării noastre. De la 1 la 15 decembrie - 15% și condiții abrupte de tranșe și de închiriere. Nu avem -70% și -90%, deoarece păstrăm prețul rezonabil din punct de vedere economic pentru licențe și nu luăm din plafon.

   Ei bine, dacă aveți nevoie de un sistem CRM (cu rafinament sau fără), atunci haideți siteul nostru Există multe despre CRM, avantajele sale și alte programe corporative.

   Și da, căutăm mereu parteneri care sunt gata să vândă CRM și alte produse, să perfecționeze și să vândă CRM, să vândă software și să învețe utilizatorii. Divizia de venit este un partener cinstit și profitabil. Vom arăta, spune-mi, învață. Scrie pe [E-mail protejat]

   Diapozitive, diapozitive. Comicile luate de la http://www.moernanalyst.com/ și de la Pinterest. Dacă există o traducere mai bună - vom fi fericiți să o facem în post.

Dacă treceți prin site-uri străine cu o cerere "Document de Cerințe de Produs", puteți găsi articole creative și convingătoare despre faptul că a murit sarcina tehnică (TK, PRD). În parte, este necesar să se conștientizeze - la dezvoltarea unui produs de la zero, prototipul pare mult mai interesant și mai eficient decât volumul înregistrărilor clientului, uneori foarte neprofesional. Cu toate acestea, dacă vorbim despre rafinamentul sistemului de bază, atunci este nevoie de o întoarcere complet diferită. Suntem configurați cu rafinament și cu dezvoltarea personalizată, așa că câinele a mâncat câinele dacă bucătarul nu ne mințește. În general, astăzi - despre cele mai clasice sarcini tehnice care sunt scrise pe rafinamentul software-ului achiziționat și instalat. Pe scurt, despre durere.

Motivul interacțiunii

Înainte de a trece la pregătirea procesului de creare a unei alocări tehnice, să vorbim despre un cvadriclu în care interpretul și clientul intră în proiect.

Cerințe- comportamentul dorit al sistemului descris de client sau deținătorul procesului care urmează să fie implementat. De regulă, cerințele sunt formate pe baza experienței de muncă, prezentarea comportamentului adecvat al programului. Acestea sunt informații cheie pentru dezvoltator (furnizor), însă este în stadiul de colectare a cerințelor pe care se ridică cel mai mare număr de coliziuni, erori, cereri inutile și așa mai departe.

Resurse - Oameni, mașini, echipamente, mediu de dezvoltare, timp și bani care urmează să fie utilizate în procesul de punere în aplicare a cerințelor. Resursele necesită o planificare și o evaluare clară în stadiul de aprobare a sarcinii tehnice. Plasarea competentă a priorităților de la client și distribuția resurselor de muncă de către furnizor vă permite să evitați să rupăm calendarul și să minimalizați alte riscuri.

Capabilități - Dacă scurt, atunci acesta poate face furnizorul (performer). Luați în considerare în exemplul RegiuniSoft CRM. Clientul cumpără sistemul și alcătuiește activitatea de rafinament: trebuie să creați integrarea cu site-ul și evenimentele de legare în CRM la numărul comenzii online al magazinului. Aceasta este o cerință cu adevărat efectuată, avem o resursă și posibilitatea de a face acest lucru. Și trebuie să se dezvolte și să se fixeze la CRM CMS, sistemul de management al conținutului site-ului. Teoretic, putem acest lucru, dar nu avem ocazia să o facem ieftin, iar clientul nu are ocazia să ne plătească atât de mult pentru a arunca resursele umane și temporare sarcinii. Ca urmare, clientul refuză să refuze această cerință - iar CMS nu este deosebit de necesar, totul este atât de bun. Dar despre "lăcomia" tz- mai târziu.

Restricții - un set de obstacole care fac sarcinile de la TK dificile sau imposibile: bugetul, stiva tehnologiei, problemele licențiate, interdicțiile legislative, configurațiile hardware și așa mai departe.

Astfel, toate cele patru entități sunt strâns legate între ele și determină succesul proiectului ca întreg. Luați în considerare fiecare element și încercați să evidențiați momentele critice pe care trebuie să le rețineți să lucrați la sarcina tehnică.

Colectarea și analiza cerințelor

Acesta este un proces corporativ foarte important, în timpul căruia se dovedește că vor de la program (aici și apoi luăm CRM, ci metode lucrează cu alte tipuri de software) potențiali utilizatori. Dacă contactați un tip de furnizor de tip Vendor Sap sau Integrator System, atunci cu o mare probabilitate de probabilitate, vi se va oferi să utilizați serviciile unui consultant de afaceri (este un manager personal, el este managerul de cont, el este "acum dvs. Reprezentant în compania noastră "). De fapt, în majoritatea cazurilor este o piață obișnuită de vânzări tranzacționate, care are două sarcini: pentru a transforma costul proiectului și nu vă lasă să coborâți de pe cârlig.

Este deja aici o oră și nici măcar nu a atins bordul markerului alb. El nu este un analist real de sistem

Mai bine decât tine și angajații tăi, nimeni nu știe compania ta. Deci, colectarea și analiza cerințelor este exclusiv sarcina dvs. în care vânzătorul poate ajuta și trimite, dar în nici un caz nu poate interveni în acest proces. Adresați-vă dezvoltatorului despre implementări similare, verificați ce să plătiți atenția și continuați. Apropo, un bun asistent poate fi angajatul dvs. care cunoaște bine în subiectul de profil și reprezintă aproximativ arhitectura software-ului și un semn cu procesul de dezvoltare - poate acționa ca analist și un expert intern, pentru a închide procesul de creare a procesului Tk și comunicarea cu vânzătorul.

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

1. Creați un grup de lucru de la manageri și specialiști cu experiență de unități care vor utiliza CRM. Spuneți-ne despre soluția care ar trebui să aleagă, să ofere acces la versiunea demo.
2. Membrii grupului de lucru trebuie să transfere informații angajaților și să solicite dorințele lor la noul program în formă absolut gratuită. Dacă cineva de la angajați nu a întâlnit niciodată un astfel de software și nu este gata să vorbească în aspectul utilizării viitoare, trebuie să-l cereți să descrie sarcinile dvs. periodice, aceasta este o abordare universală.
3. Apoi, fiecare unitate se stabilește, care nu este în CRM sau ceea ce nu se potrivește și agregă informațiile.
4. Grupul de lucru analizează cerințele colectate, verifică și elimină intersecția. De exemplu, deseori departamentul de vânzări și departamentul de marketing sunt comandate de același raport, dar în cerințele pot fi numite domenii și entități în moduri diferite, deși datele din spatele lor sunt aceleași. În consecință, trebuie să ajungeți la o singură formă.
5. Grupul de lucru generează o listă de cerințe și pune priorități. În acest stadiu, puteți conecta furnizorul deoarece este responsabil pentru resurse. De exemplu, vă puteți cere să creați un raport personalizat pentru Regionsoft CRM și puteți comanda integrarea cu site-ul. Acest lucru este complet diferit în ceea ce privește sarcina, prioritatea este foarte importantă aici.

După ce cerințele sunt colectate, analizate și coordonate cu angajații și gestionarea, puteți începe să creați o sarcină tehnică. Puteți cere forma vânzătorului sau puteți face singur - în orice caz, există mai multe reguli de fier, care vor salva de la durerea de cap și de dvs. și furnizorul dvs. CRM.

Anatomia sarcinii tehnice

Dacă vorbim despre procesul de creare a unei sarcini tehnice, atunci există mai multe etape. Pasajul lor consistent și conduce clientul la rafinamentul dorit. Aici sunt ei.

• Detectarea - definirea cerințelor, problemele de depanare care trebuie rezolvate.
• Analiza - Analiza cerințelor, alocarea nevoilor cheie, generalizarea.
• Adaptarea este o evaluare a cerințelor în contextul capacităților CRM și a proceselor de afaceri existente.
• Documentație - descrierea formală și detaliată a cerințelor, coordonarea TK.
• Comunicarea cu vânzătorul (dezvoltatorul) este o interacțiune iterativă cu furnizorul cu privire la îmbunătățirile în funcție de TK compus.
• Implementarea este activitatea vânzătorului la crearea funcționalității necesare. Este mai bine dacă vânzătorul este în permanență în contact cu clientul - produsul de la ieșire va respecta cu exactitate viziunea clientului.
• Testarea - verificarea funcționalității angajaților furnizorilor, experți interni ai clientului și utilizatorilor finali pentru a stabili conformitatea rafinării și TK, performanța sistemului cu modificări.

În general, sarcina tehnică poate fi creată pe baza cerințelor mai multor niveluri care pot intersecta și coopera la crearea unui proiect sau nu interacționează deloc.

Nivelul de afaceri.- Nivelul global pe care sunt rezolvate sarcini complexe și prioritare. La acest nivel, integrarea, rafinamentul și modelarea proceselor de afaceri pot fi atribuite, dezvoltarea de noi module funcționale. De regulă, este o dezvoltare intensivă a resurselor, cu consultări serioase și o colaborare strânsă cu clientul. De exemplu, la un moment dat în regiunea CRM, o astfel de revizuire personalizată a fost depozitul, biroul de bilete și producția. Treptat, schimbările au intrat în eliberare și mai târziu au permis să creeze un produs nou pentru magazinele cu ridicata, cu amănuntul și hipermarketurile - Retail Retail.

Nivelul utilizatorului sau grupul de utilizatori.La acest nivel, sarcinile sunt implementate cu privire la revizuirea interfeței existente. De exemplu, utilizatorul poate dori ca atunci când deplasați un cursor, apare o fereastră cu numărul și starea ultimei comenzi sau a existat un raport personalizat cu o grupare specială de date. Rafinăria la acest nivel ocupă mai puțin timp, dar pot exista multe dintre ele - de exemplu, mai multe cerințe din partea departamentului de marketing, logistică și suport tehnic.

Nivelul funcționalității. Este adesea dificil să o separați de cel precedent, un criteriu formal funcționează aici - rafinamentul nu este la nivelul de afișare a nimic în interfață, ci la nivelul rafinării logicii sistemului. Aceasta include cerințele pentru diferite sortare, integrare cu capabilități de chat, telefonie.

Nivelul serviciului - De fapt, cerințele acestui nivel ar trebui să fie primele care intră în clădiri noi cu remedii. Acestea sunt sarcini pentru viteza răspunsului sistemului, care lucrează sub sarcină mare, securitate. În versiunea ideală, Vendor nu ar trebui să aibă astfel de îmbunătățiri - Software-ul corporativ nu trebuie să încetinească, să piardă datele, să se prăbușească și să distribuie permisiunile unui nivel. Dar dacă a apărut cerința și nu este legată de paraniza sau problemele personale ale clientului din partea hardware-ului, merită să o acordăm o atenție deosebită pentru el.

Nivelul de tehnologie - Ultima pe listă, dar în importanță și dificultate este înaintea restului. Acestea pot fi cerințele clienților asociate cu platforma, sistemul de operare sau dispozitive. De exemplu, o colecție de asamblare sub MacOS. Este foarte cool, dacă astfel de cerințe se procesează treptat în versiuni, dar există în mod necesar remedieri. Este de la solicitările clienților la acest nivel am realizat un ansamblu ASOFT CRM în cadrul MacOS și a adăugat accesul șters utilizând tehnologia TRM ca o soluție temporară a unei cereri de versiune mobilă rară, dar existentă.

Anatomia sarcinii tehnice este simplă, în orice caz sub forma unui schelet. Părțile obligatorii ale sarcinii tehnice ajută clientul să se concentreze asupra problemei și să formuleze sarcina în mod corect, iar contractantul - să înțeleagă ce vor de la el. Apropo, despre înțelegere. Desigur, la începutul postului, am supraviețuit ușor, refuzând consultanți de afaceri ca o clasă. Aceasta este: Fiecare furnizor funcționează pe piață timp de mai mulți ani (nu suntem cu privire la CRM-o zi), ci și zece ani, ceea ce înseamnă că există un set de cazuri în aproape fiecare industrie. În consecință, inginerii, programatorii și vânzările sunt familiarizați cu specificul implementării în fiecare tip de companie. Dar din nou, este important să vă concentrați asupra afacerii dvs.

Pentru cine?În această secțiune, este necesar să se descrie cine va fi un utilizator finit de rafinament, ce sarcini și cu ce frecvență este planificată să fie rezolvată.

Voi da un exemplu. În aceeași companie a introdus CRM, sa presupus că lucrează la o matrice de date destul de mare (câteva zeci de înregistrări pe lună, câteva sute de mii de înregistrări pe zi). Departamentul șef al vânzărilor a solicitat un raport privind descărcarea acestor înregistrări cu frecvența "zilnic". În mod natural, un astfel de raport cu lucrări simultane sute de utilizatori au încărcat sistemul - au fost găsite deciziile optimizării procesului. Deja în timpul lucrării, sa dovedit că vânzările au fost reconstruite și raportul este necesar numai de rezultatele lunii, iar apoi poate fi lansat pe un program pe timp de noapte. Merită să spuneți că timpul și banii au fost cheltuiți în zadar.

Pentru ce?Justificarea nevoii de rafinament și locul său în procesul de afaceri. Acest articol este mai necesar pentru client în sine, dar și vânzătorul de a ști ce vor fi afectate alte procese. Uneori ajută la găsirea unei soluții alternative.

Ce ar trebui să facă?Cel mai informativ bloc - descrie cerințele, așteptările sistemului. Și aici, foarte perle, miracole și coliziuni, care vin la bashomg și care sunt foarte complicate de viață. Provoca unul - utilizatorul nu știe ce vrea să facă. Există încă un mic subprik - utilizatorul nu poate formula cerințele. Și apoi sarcina dezvoltatorului (grupul de lucru, analitică, dacă este cazul) contribuie la articularea nevoii adevărate, alegeți o cerință exppedentă, introduceți sarcina în contextul sistemului. În același bloc, trebuie să menționați rezultatul așteptat.

Parametrii sarcinii tehnice- Termeni, etape de implementare, responsabilă din toate părțile, contactele necesare și așa mai departe. De fapt, aceasta este o combinație de lucruri formale importante care fac un document cu o sarcină tehnică. Sarcina tehnică trebuie să fie neapărat coordonată și semnată de părți pentru a evita numeroase modificări în dezvoltarea dezvoltării (acestea vor fi în continuare, dar într-un volum mai mic).

În versiunea ideală, sarcina tehnică este compilată cu participarea activă a furnizorului, iar totalul său este aproximativ o astfel de structură:

1. Descrierea cerințelor fiecărui mecanism și a fiecărei funcționalități
2. Descrierea implementării acestei funcții
3. Costul muncii pentru fiecare dintre pașii separat
4. Costul total al lucrărilor la această atribuire tehnică
5. Termeni de execuție a muncii cu o defalcare a etapelor și indicarea scenei
6. Descrierea condițiilor de instalare și testarea
7. Rezervări despre natura exhaustivă a sarcinii tehnice și a altor condiții

10 Reguli scrise de lacrimile dezvoltatorului

Sarcina tehnică de rafinament ar trebui să fie TK privind rafinamentul, nu o descriere de 300 de pagini a CRM, care este necesară pentru client. Înainte de elaborarea cerințelor, trebuie să citiți cu atenție interfața de sistem, capacitățile sale, documentația - cel mai probabil, cea mai mare parte a "Listă de dorințe" se află deja în aprovizionarea de bază. Aș recomanda să acordați atenție instrumentelor de rafinament încorporat (designeri, configurați, etc.) - poate că schimbările necesare vor putea să facă un programator regulat (în multe companii).

Sarcina tehnică nu ar trebui să fie lacomă.Adesea, afacerea se supraestimează capacitățile sau dorește să obțină "totul imediat". O astfel de abordare nu este justificată din punct de vedere al banilor sau din punct de vedere al afacerilor. Furnizor, de regulă, nu există câteva săptămâni (în cazul regiunilor - 15 ani) și puteți să-l contactați și după un timp, puteți înțelege cu adevărat ceea ce lipsește CRM.

Un exemplu luminos de redundanță este literal de ieri: Clientul a cumpărat ERP o singură companie rusă celebră, gândindu-se că contabilitatea contabilă, atunci ERP a acestui furnizor va fi bun. ERP sa dovedit a fi atât de mult în sine, dar foarte nu o afacere potrivită. Dar regiunile CRM cu contabilitate și producție de depozitare este adecvată. Există o soluție: să uitați de ERP, plângeți, integrați contabilitatea 1c cu un nou CRM și bucurați-vă într-o implementare convenabilă. Dar banii fără voce este păcat! Și clientul necesită integrarea CRM cu ERP. Nu am făcut asta, dar de ce o astfel de deșeu, de ce două sistem relativ similar?

Sarcina tehnică trebuie să fie realistă și îndeplinită - Ambele conform cerințelor și timpului. Este important să ascultați opinia vânzătorului, așa cum știe exact la ce oră merge la una sau altă sarcină. Crede-mă, dezvoltatorul nu este profitabil să tragă timpul și să vâneze termenul - este profitabil pentru aceasta să completeze cât mai multe proiecte și să o facă bine pentru a nu primi o lovitură reputației. În ceea ce privește realismul, evitați cererile de a termina CRM la nivelul sistemului de gestionare a coliziunilor pur și simplu: ar trebui să fie inclusă în cerințele a ceea ce este într-adevăr necesar în acest moment și în viitorul previzibil.

De exemplu, regiunile CRM este un program desktop, nu avem un client pentru un browser. Întrebându-ne să creăm o aplicație web pentru o singură companie, este lipsită de sens, este o dezvoltare majoră, se desfășoară acum și nu este posibilă perfecționarea pentru o singură companie. Nu, desigur, totul are prețul său, dar din nou - în general, cerința este impunerea.

Nu este nevoie să vă confundați cu situația în care vine vorba de dezvoltarea personalizată, iar ideea și logica aplicației sunt modificate în rădăcină, crearea unui nou software "pentru dvs." este practic crearea unui nou software. Dar aceasta este o altă poveste.

Sarcina tehnică trebuie să fie detaliată. Trebuie să specificați toate detaliile semnificative ale proiectului viitor: de la frecvența utilizării programului la dorințele de pe interfață. Cu cât sunt stabilite mai multe cerințele, cu atât vor fi implementate și mai rapide și mai rapide. Este deosebit de merită acordată atenție detaliilor dacă lucrați într-o anumită industrie (medicină, asigurare, bănci) - o declarație detaliată a nuanțelor interacțiunii de afaceri și a programului va asigura o înțelegere a sarcinii vânzătorului și adaptarea rapidă a sistemului către compania dvs.

Asigurați-vă că acordați atenție formatelor numerelor, denumirilor câmpurilor, prezenței sau absenței listelor derulante, comportamentului butoanelor și sugestiilor, tipurilor de date. Dacă clientul folosește propriile formule care trebuie să fie așezate în logica lucrării CRM ( de exemplu, calculul bonusurilor de dealer) Aceste formule trebuie să fie scrise cu decodificarea completă a denumirilor lor și logica de calcul.

Da, software-ul corporativ arată așa, și în ea există multe lucruri importante

Sarcina tehnică trebuie să fie lipsită de ambiguitate și exactă. Formularea neclară, opțiunile de implementare, cerințele fuzzy - în acest fel într-un capăt mort. Se întâmplă că un client din bune intenții scrie mai multe opțiuni pentru comportamentul sistemului, aproape, dar nu echivalent cu TP. În acest caz, el este sigur că el ajută, îi spune programatorului, dar, de fapt, intenția bună a drumului spre Iadul dezvoltatorului trebuie să înțeleagă exact ce are nevoie și cum să faceți acest lucru se va alege, pe baza caracteristicilor Sistemul și stack-ul tehnologiilor utilizate.

În acest an puteți da o singură dorință din nou. Numai, vă rog, nu-l pierdeți pe faptul că chiar nu pot îndeplini, cum ar fi cerințele de afaceri ușor de înțeles!

Sarcina tehnică trebuie să fie scrisă în limba umană. Și acest lucru este important, nu, este important. Voi aloca două situații în care problemele cu limba conduc la înăsprirea implementării proiectului.

1. Clientul încearcă să demonstreze alfabetizarea tehnică și arde tipul de tip: "Implementarea unei ferestre cu un indiciu în corpul calendarului cu posibilitatea de a apela un eveniment ..." În schimb ", în calendar ar trebui să fie Afișați o fereastră în care puteți marca sarcina așa cum este efectuată. " Dacă dvs. sau expertul dvs. intern nu aveți abilitățile de a scrie texte tehnice, nu Google - scrieți ca cuvinte obișnuite, le înțelegem.

   Sarcina tehnică nu ar trebui să fie o carte plină de planificare. Este necesar să rezolvăm problema și să nu o descriem, acordând atenție fonturilor și uitarea descrierii cerințelor. TK ar trebui să conțină nu numai problema însăși, ci și soluția sa la nivelul înțelegerii - în continuare dezvoltatorul va decide deja la nivelul codului. Comparaţie "Departamentul de vânzări planifică prost, pierde cifrele, deja lupte pentru un an" și "Trebuie să creați un raport care să păstreze valorile planului și de vânzările lunare lunar, în contextul grupurilor nomenclaturii".

   Sarcina tehnică ar trebui să poată privi în viitor.Ei bine, nu așa, dar oamenii stau în spatele lui. Dacă se știe că vor apărea schimbări în curând în procesele de afaceri, este necesar să se ia în considerare pentru a nu plăti pentru revizuire de două ori.

   Sarcina tehnică nu trebuie să fie birocratică. Dacă cel puțin o dată ați constituit acest document, probabil că ați simțit cât de greu să evitați tentația de a aluneca în birocrație, să se estompeze în cuvintele interioare, la revoluțiile stricte și să descrie fiecare element ca un articol al Codului penal (de preferință cu pedeapsa toată lumea pentru încălcare). Formulările birocratice maschează o înțelegere incompletă a obiectivelor de creare a TK. Responsabilitatea furnizorului este înregistrată în contract, bugetul este scris acolo. Nu purtați aceste puncte în sarcina tehnică.

   Sarcina tehnică ar trebui să fie o sarcină tehnică. Sună paradoxal, dar adesea în loc de TK am citit scrisori, plângeri, contracte, instrucțiuni re-scrise pentru CRM sau procesul-verbal al reuniunii. Desigur, este imposibil să lucrăm pentru un astfel de document. Pentru a nu scăpa de formular și de conținut, utilizați vechiul truc școlar: Luați în considerare termenul conform. Tehnic - înseamnă că rafinamentul este dictat, tehnica vizează rezolvarea problemei prin schimbarea software-ului. Aceasta este sarcina în contextul software-ului și trebuie să vorbiți. Sarcina înseamnă că problema, problemele, fără sfaturi, sfaturi și estimări preliminare. Doar o sarcină de formulare.

   Porțile s-au încheiat, acum recompensa

   În plus față de regulile enumerate, există mai multe lucruri despre care merită să spunem. Vorbim despre obiectivele, planurile și așteptările - toți cei care părăsesc, ceea ce face ca proiectul să aibă succes, iar relația vânzătorului și clientului este aproape prietenoasă.

   Sarcina tehnică trebuie să scrieți rapidChiar dacă aveți sarcina de a automatiza procesul unui operator celular sau a unui hipermarket mare. Acest lucru se datorează faptului că tehnologiile se dezvoltă la o viteză uriașă și chiar sistemul pe care îl implementați, timp de șase luni - pe an poate supraviețui unei lansare majoră (și uneori două), obține o nouă funcționalitate. Poate că trebuie să reconsiderați nevoia de a îmbunătăți și de a începe din nou procesul.

   

   
   În cele din urmă, a găsit timp pentru a completa tk. Dar, din păcate, nu există dezvoltatori în jurul valorii de acolo pentru ao implementa.

   Clientul nu știe despre stivă și limitări tehnice.Și nu trebuie să știe - aceasta este sarcina vânzătorului, este cel care evaluează munca după elaborarea unei sarcini tehnice. Clientul nu ar trebui să fie aprofundat în tehnologie și să ceară fiecare virgulă dacă vânzătorul poate face unul sau altul. Faceți un TK cuprinzător și dezvoltatorul va alege o arhitectură potrivită - adesea chiar mai bună decât credeți.

   Evaluați bugetul și evitați surprizele neplăcute - Aproape un număr comun numărul unu. Nu trebuie să rotiți vânzătorul și să cereți de la ea o evaluare aproximativă a lucrării (bine, cel puțin aproximativă cavitatea, la ochi și ca alții, bine, în proiectele de acest tip, și prin experiență, bine, în cadrul limitele erorii). O evaluare completă a bugetului este posibilă numai după citirea, analizarea și aprobarea finală a sarcinii tehnice. Dacă dezvoltatorul dvs. vine altfel - pregătiți-vă pentru faptul că rafinamentul va costa cel puțin de două ori mai scump.

   Treceți de nevoia obiectivă de modificări și extensii - Am scris mai sus că dezvoltatorul nu dispare și este gata să facă schimbări și completări la cerințele dvs. în orice moment. Prin urmare, nu încercați să creați imediat vise CRM / ERP, nu necesită butonul "Totul funcționează până când beau cafea" - lucrează în sistem, determină comentariile critice pentru dvs. și procedați la colectarea cerințelor și compilarea TK .

   Putem scrie despre sarcinile tehnice infinit, acesta este un generator real nu numai meme și bere, ci și dureri de cap. Puteți vorbi despre priorități și reguli de înregistrare, despre oaspeții 1989, ceea ce face TZ Inhuman, despre standardele IEEE, care sunt puțin mai bune, despre prototipuri și complementare TK. Dar, la final, aș dori să ne limităm la una, cea mai importantă regulă: sarcina tehnică nu este norma de drept, nu GOST și nu dogma, prin urmare, dacă vă puteți îmbunătăți - îmbunătățiți, puteți simplifica - Simplificați-vă poate face elegant și de a face posibil. Sunt sigur, nimeni după aceea nu împinge nasul în tk și nu va spune că nu este scris acolo. Sau aproape nimeni.

   Toate luna decembrie vom da reduceri la Regionsoft CRM și întregul software al dezvoltării noastre. De la 1 la 15 decembrie - 15% și condiții abrupte de tranșe și de închiriere. Nu avem -70% și -90%, deoarece păstrăm prețul rezonabil din punct de vedere economic pentru licențe și nu luăm din plafon.

   Ei bine, dacă aveți nevoie de un sistem CRM (cu rafinament sau fără), atunci haideți siteul nostru Există multe despre CRM, avantajele sale și alte programe corporative.

   Și da, căutăm mereu parteneri care sunt gata să vândă CRM și alte produse, să perfecționeze și să vândă CRM, să vândă software și să învețe utilizatorii. Divizia de venit este un partener cinstit și profitabil. Vom arăta, spune-mi, învață. Scrie pe [E-mail protejat]

   Diapozitive, diapozitive. Comicile luate de la http://www.moernanalyst.com/ și de la Pinterest. Dacă există o traducere mai bună - vom fi fericiți să o facem în post.

Din cât de precis sarcina tehnică pentru finalizarea 1c, depinde în mod direct, dacă sarcinile stabilite înainte de dezvoltatori vor fi rezolvate. În același timp, atunci când lucrați cu un astfel de document există unele dificultăți. Într-o înțelegere largă a TK, normele sunt prescrise la crearea și modernizarea unui sistem automat (AC), precum și a ordinii de lucru. Acest lucru include, de asemenea, un set de standarde de lansare a proiectului. Această înțelegere a rolului sarcinii tehnice este dictată de cerințele GOST 19.201-78 și 34.602-89, conform căreia se dezvoltă dezvoltarea TK pentru 1C. Există o altă interpretare a valorii acestui document, mai aproape de practică.

Conform unei alte definiții, sarcina tehnică pentru finalizarea 1c este un document care reglementează scopul și parametrii viitorului sistem, precum și procesul de elaborare a documentației și a listei acesteia. O astfel de interpretare ne permite să luăm în considerare interesele programatorilor și clientului.

Ce ar trebui să fie tk?

Orice sarcină tehnică pentru dezvoltarea programului 1c este creată de contractant. Dar acest lucru nu face un programator, ci un analist. Acesta este un punct important, deoarece documentul trebuie să fie întocmit în limba, de înțeles cu clientul, fără termeni tehnici foarte specializați. Când toate nuanțele de proiect sunt luate în considerare și informațiile sunt definite corect, TK este coordonat cu toți clienții. În cazul acceptării sale, sunt conectați programatori. În același timp, rezultatul dorit ar trebui să fie clar subliniat în document. Ajută dezvoltatorii să pună corect obiectivul și verificați cu ea în diferite etape. De asemenea, o atenție deosebită în pregătirea sarcinii tehnice privind finalizarea 1c merită să plătească formulările. Ar trebui urmată astfel încât să fie suficient de specifice și nu și-au asumat alte interpretări. Acesta este primul lucru pe care trebuie să-l amintiți când lucrați cu TK. De asemenea, este necesar să se apropie de designul. Acest lucru se aplică foii de titlu a documentului.

Principalele erori în sarcina tehnică pentru dezvoltarea de 1c

Structura pieței cazurilor este reglementată de GOST 34.602-89. Acest document conține cerințe clare pentru numărul și secvența blocurilor de informații din TK. În același timp, nu există standarde stricte pentru metodele de prezentare. Această situație cuprind un mare potențial de rezolvare a sarcinilor complexe și, în același timp, poate implica multe erori în pregătirea documentului. Cel mai adesea sunt următoarele inexactități:

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

Toate acestea împiedică înțelegerea informațiilor de către client, care este prezentată în TK. Acest lucru complică procesul de cooperare, făcând mai mult timp consumator.

După vizionarea clientului, eșantionul TK privind finalizarea 1c se poate schimba și nu întotdeauna spre bine. Aceasta, la rândul său, împiedică, de obicei, programatorii să perceapă informațiile corecte. Acest lucru este valabil mai ales pentru specialiștii cu experiență mică. În această etapă, apar adesea următoarele erori:

1. Cerințele diferitelor secțiuni contrazic reciproc.
2. Formulările sunt inexacte.
3. Informațiile locale nu sunt detaliate.

Scapa de toate erorile enumerate pur și simplu. Este necesar să navigați, în primul rând, pe rezultat, și nu pentru formularea atentă a prescrierii. Merită să ne amintim că TK descrie funcționalitatea proiectului, principalii săi parametri și scopuri.

Cum să evitați greșelile în dezvoltarea tk?

Regula principală care se aplică tuturor recomandărilor ulterioare este formularea ar trebui să fie specifică. Pentru a face acest lucru, trebuie să utilizați linkuri către GOST, alte documente de reglementare. Acest lucru permite contractantului și clientului să perceapă informațiile într-un fel.

Un exemplu de sarcină tehnică de a rafina 1c implică utilizarea limbii industriei pentru care se efectuează proiectul. Este necesar, în primul rând, pentru client. În același timp, în text nu merită să utilizați nicio comparație, deoarece acestea pot fi interpretate în moduri diferite.

Principalele reguli în elaborarea unei alocări tehnice la elaborarea unui raport și a altor elemente 1C:

1. TK este creat în comun de către contractant și de client.
2. Numai cerințele obiective ar trebui să fie plasate pe funcționarea programatorilor. Pentru dezvoltarea cu succes a proiectului, viziunea subiectivă a clientului trebuie să fie redusă la minimum.
3. Trebuie să descrieți rezultatul în detaliu că nevoile clienților. În același timp, în exemplul unei sarcini tehnice pentru dezvoltarea configurației 1c, trebuie să prescrieți toți parametrii pentru care ar trebui să funcționeze elementul. În caz contrar, rezultatul poate diferi foarte mult de cel dorit.
4. Riscurile artistului și ale clientului trebuie să fie aproximativ egale și minimizate.
5. Este imposibil să se folosească termeni care sunt utilizați în comunicarea în afaceri și nu sunt aplicate într-o anumită industrie.

Pentru a crea un TK cu privire la elaborarea unui raport în 1c sau alt element, analistul ar trebui să cunoască toate caracteristicile activităților clientului. În cerințele de care aveți nevoie pentru a oferi numai informații utile care sunt utile contractorului. Având în vedere că o atenție deosebită este acordată sarcinilor finale aici, care ar trebui să rezolve software-ul, nu există exemplul uniform al sarcinii tehnice.

Pericol de compilație incorectă a tk

Erorile enumerate mai sus pot duce la o creștere a timpului care este cheltuită pentru crearea sistemului. Aceasta implică cheltuieli suplimentare și nemulțumire. Sarcina tehnică pentru dezvoltarea bazei de date sau alte configurații 1C ar trebui să fie specialiști cu experiență. Din câte documentul este disponibil pentru înțelegere, beneficiul tuturor participanților depinde. Clientul primește un sistem automatizat eficient pentru rezolvarea sarcinilor de afaceri. În același timp, contractantul este un alt client mulțumit. Proprietarii de afaceri trebuie să fie cât mai aproape posibil de selecția companiilor partenere 1C, deoarece eficacitatea organizației depinde de cât de calitativ, depinde eficacitatea organizației.