Contacte

Tehnologii de interacțiune cu clientul intern. Management de proiect. Informarea Clientului despre tehnologia de management al proiectelor

  • 25.11.2019

Proiectele sunt diferite și trebuie gestionate în moduri diferite. În proiecte mari unde un numar mare de dezvoltatori, ca să nu mai vorbim de analiști de afaceri, testeri și clienții actuali ai proiectului, problema coordonării acțiunilor vine în prim-plan, umbrind toate celelalte sarcini.

Tocmai pentru acest caz a fost inventată metodologia de management de proiect Agile.

Cele 4 postulate principale ale sale sunt următoarele:
- indivizii și interacțiunile lor sunt mai importante decât procesele și instrumentele;
- software-ul de lucru este mai important decât documentația completă,
- cooperarea cu clientul este mai importantă decât obligațiile contractuale,
Răspunsul la schimbare este mai important decât respectarea unui plan.

Concentrarea pe comunicare și pe rezultatul final, în loc să urmezi un plan și o documentație completă, îți oferă mai multă flexibilitate și îți permite să nu birocratizezi procedura de codare. Dezavantajul unei astfel de abordări democratice este lipsa unei planificări clare, necesitatea de a reface în mod constant părțile deja scrise ale codului și grăbirile obișnuite asociate cu aceasta.

În ciuda o serie de deficiențe, în multe cazuri metodologia agilă este indispensabilă. Prin urmare, orice șef al departamentului de dezvoltare ar trebui să fie familiarizat cu acesta.

Responsabilitățile șefului departamentului de dezvoltare

Dezvoltarea standardelor și politicilor de dezvoltare softwareîn conformitate cu politica generală IT a companiei;
- planificarea si coordonarea activitatii departamentului de dezvoltare;
- dezvoltarea si monitorizarea respectarii graficelor de proiect;
- evaluarea complexitatii proiectelor si repartizarea sarcinilor de dezvoltare intre programatori/dezvoltatori;
- managementul procesului de dezvoltare;
- dezvoltare termeni de referinta pe module software;
- planificarea si controlul executiei bugetare a departamentului;
- managementul resurselor externe implicate în dezvoltarea software-ului;
- elaborarea documentaţiei normative care reglementează activitatea departamentului şi procedura de interacţiune cu direcţiile funcţionale;
- participarea la dezvoltarea strategiei de dezvoltare a companiei.

Ofertele salariale și cerințele angajatorilor

Oferta medie de salariu pentru șeful departamentului de dezvoltare din Moscova este de 150.000 de ruble, în Sankt Petersburg - 117.000 de ruble, în Volgograd - 66.000 de ruble, în Voronezh - 75.000 de ruble, în Ekaterinburg - 100.000 de ruble, în Kazan - 0075 de ruble Krasnoyarsk - 90.000 de ruble, în Nijni Novgorod - 70.000 de ruble, în Novosibirsk - 85.000 de ruble, în Omsk - 75.000 de ruble, în Perm - 85.000 de ruble, în Rostov -pe Don - 75.000 ruble - 70,5000 ruble - 70,5000 ruble ruble, în Chelyabinsk - 84.000 de ruble.

Candidații care aplică pentru prima dată pentru postul de șef de dezvoltare trebuie să aibă educatie inalta(profil sau tehnic), experiență în dezvoltare software de cel puțin 3 ani. Este necesară cunoașterea principiilor de programare orientată pe obiecte și metodologie de dezvoltare software (RUP, MSF), sunt necesare abilități de lucru cu DBMS. Angajatorii salută cunoașterea mai multor limbaje de programare. Salariul inițial pentru șefii începători ai departamentelor de dezvoltare din Moscova variază de la 70.000 la 110.000 de ruble, la Sankt Petersburg - de la 55.000 la 86.000 de ruble, la Voronezh și Perm - de la 35.000 la 55.000 de ruble.


Oraș Nivelul veniturilor, frecați.
(nu exista experienta in acest post)
Moscova 70 000 - 110 000 - Studii superioare (tehnice/IT)
- Cunoașterea unuia sau mai multor limbaje de programare
- Înțelegerea principiilor programării orientate pe obiecte
- Cunostinte metodologie de dezvoltare software (RUP, MSF)
- Cunoștințe de limba engleză la nivelul citirii documentaţiei tehnice
- Experienta cu DBMS
- 3+ ani de experiență în dezvoltare software

Portretul solicitantului într-un interval
St.Petersburg 55 000 - 86 000
Volgograd 30 000 - 48 000
Voronej 35 000 - 55 000
Ekaterinburg 47 000 - 74 000
Kazan 35 000 - 55 000
Krasnoyarsk 42 000 - 66 000
Nijni Novgorod 33 000 - 52 000
Novosibirsk 39 000 - 62 000
permian 35 000 - 55 000
Omsk 40 000 - 63 000
Rostov-pe-Don 35 000 - 55 000
Samara 35 000 - 55 000
Ufa 37 000 - 55 000
Celiabinsk 40 000 - 62 000

De la candidații cu experiență în conducerea departamentului de dezvoltare de mai bine de 1 an, angajatorii se așteaptă, în primul rând, abilități organizaționale și de conducere dezvoltate. Cerințele postului se referă la experiența în planificarea, organizarea și implementarea proiectelor, dezvoltarea documentației tehnice, precum și abilitățile de utilizare. unelte management de proiect. Solicitanții pentru posturi vacante relevante din capitală se pot aștepta la un salariu de până la 140.000 de ruble, în orașul de pe Neva - până la 109.000 de ruble, în Voronezh și Perm - până la 70.000 de ruble.

Oraș Nivelul veniturilor, frecați.
(cu 1 an experienta in munca)		 Cerințe și dorințe pentru competențe profesionale
Moscova 110 000 - 140 000
- Abilitati de organizare si management dezvoltate
- Abilitati in planificarea, organizarea si implementarea proiectelor
- Abilități de utilizare a instrumentelor de management de proiect
- Capacitate de elaborare a documentatiei tehnice

Portretul solicitantului din gama a 2-a
St.Petersburg 86 000 - 109 000
Volgograd 48 000 - 62 000
Voronej 55 000 - 70 000
Ekaterinburg 74 000 - 94 000
Kazan 55 000 - 70 000
Krasnoyarsk 66 000 - 84 000
Nijni Novgorod 52 000 - 66 000
Novosibirsk 62 000 - 78 000
permian 55 000 - 70 000
Omsk 63 000 - 80 000
Rostov-pe-Don 55 000 - 70 000
Samara 55 000 - 70 000 Ufa 55 000 - 70 000 Celiabinsk 62 000 - 78 000

Educatie suplimentaraîn domeniul IT și experiență în stabilirea unui ciclu complet de dezvoltare - acestea sunt cele mai tipice cerințe pentru solicitanții cu mai mult de 2 ani de experiență în managementul dezvoltării. Câștigurile pe care se pot baza astfel de specialiști ajung la 175.000 de ruble în companiile din capitală, 137.000 de ruble în Sankt Petersburg și 88.000 de ruble în Voronezh și Perm.

Oraș Nivelul veniturilor, frecați.
(cu experienta de peste 2 ani)		 Cerințe și dorințe pentru competențe profesionale
Moscova 140 000 - 175 000
- Educatie suplimentara in domeniul IT
- Experienta in realizarea unui ciclu complet de dezvoltare (de la specificatii tehnice pana la punerea in functiune a proiectului)

Portretul solicitantului din gama a 3-a
St.Petersburg 109 000 - 137 000
Volgograd 62 000 - 77 000
Voronej 70 000 - 88 000
Ekaterinburg 94 000 - 117 000
Kazan 70 000 - 88 000
Krasnoyarsk 84 000 - 105 000
Nijni Novgorod 66 000 - 82 000
Novosibirsk 78 000 - 98 000
permian 70 000 - 88 000
Omsk 80 000 - 100 000
Rostov-pe-Don 70 000 - 88 000
Samara 70 000 - 90 000
Ufa 70 000 - 88 000
Celiabinsk 78 000 - 100 000

Cele mai mari salarii sunt oferite șefilor departamentelor de dezvoltare mari intreprinderi. Acești angajatori solicită candidaților să aibă cel puțin 3 ani de experiență în organizații de dimensiune similară. Companiile cu parteneri străini preferă specialiști care vorbesc fluent limba engleză. Salariul maxim la Moscova ajunge la 300.000 de ruble, la Sankt Petersburg - 235.000 de ruble, la Voronezh și Perm - 150.000 de ruble.

Oraș Nivelul veniturilor, frecați.
(cu experienta de la 3 ani)		 Cerințe și dorințe pentru competențe profesionale
Moscova 175 000 - 300 000
- Experienta in managementul dezvoltarii in structura companie mare de la 3 ani

Dorință posibilă: Cunoașterea limbii engleze la un nivel conversațional sau fluent

Portretul solicitantului din gama a 4-a
St.Petersburg 137 000 - 235 000
Volgograd 77 000 - 130 000
Voronej 88 000 - 150 000
Ekaterinburg 117 000 - 200 000
Kazan 88 000 - 150 000
Krasnoyarsk 105 000 - 180 000
Nijni Novgorod 82 000 - 140 000
Novosibirsk 98 000 - 170 000
permian 88 000 - 150 000
Omsk 100 000 - 170 000
Rostov-pe-Don 88 000 - 150 000
Samara 90 000 - 150 000
Ufa 88 000 - 150 000
Celiabinsk 100 000 - 170 000

Portretul solicitantului

Dintre candidații pentru funcția de șef al departamentului de dezvoltare, majoritatea sunt bărbați de vârstă mijlocie, cu studii superioare. Reprezentanții sexului slab printre solicitanți sunt doar 5%, ceea ce este tipic pentru sectorul IT. 58% dintre solicitanți sunt specialiști cu vârsta cuprinsă între 30 și 39 de ani. 96% dintre șefii departamentelor de dezvoltare au studii superioare. Fiecare al treilea solicitant vorbește fluent limba engleză.

Cod de încorporare a blogului

Șef Departament Dezvoltare

Abilități de management de proiect – această cerință se găsește adesea în posturile vacante pentru managerii de dezvoltare. De fapt, în spatele acestor cuvinte poate fi mult mai mult decât pare la prima vedere. A doua parte” (acesta este Interpretul). Adevărat, uneori unele mari structuri ale statului spun că departamentul juridic nu le permite să facă acest lucru, deoarece documentele sunt verificate de Trezorerie, Ministerul Finanțelor și alții. În acest caz, prescriem formularea standard - „Client și Antreprenor”. Dar, dacă este posibil, atunci - „Prima” și „A doua parte”.

  • Prin toate mijloacele, încercăm să transmitem că aceasta este o lucrare comună. Lideri de ambele părți acționează ca înalte părți contractante - ei au fost cei care au decis să realizeze acest proiect de automatizare. Pentru acest proiect, ei recrutați o echipă de Cum din personalul primului partidelor, cele ale angajatilor a doua latură este așa-numitul Grupul de lucru comun„, ceea ce face proiectul. Desigur, fiecare parte își investește resursele în proiect: materiale, tehnologice, metodologice, financiare - pentru că, în general, vorbim de proiecte destul de mari.
  • Activitatea grupului de lucru comun este supravegheată de« Comisia mixtă de supraveghere” este cel mai înalt organism de control, format de obicei din conducerea de vârf a ambelor părți.
  • Și semnează responsabilitatea fiecărei părți pentru ca angajații clientului să înțeleagă că nu doar noi, ci și ei suntem responsabili pentru proiect. Investim mult timp și efort pentru a transmite clientului că facem acest proiect împreună cu angajații săi și că munca lor depinde direct de ce calitate și, mai ales, în ce interval de timp va fi finalizat proiectul.

    • Bine rezultat această etapă este fixare(formal sau informal) relaţii parteneri egali:

    • Fixarea formală este un contract.
    • Și informal - pot fi niște documente oficiale în care încercăm întotdeauna să prescriem „Prima și a doua parte” și relația lor.

    Informarea Clientului despre tehnologia de management al proiectelor

    Următoarea etapă este informarea clientului despre tehnologie.

    • La proiectele mari, noi, fără greș, avem" Curs de prelegeri și seminarii de introducere în tehnologia designului". În acest curs de prelegeri, le aducem angajaților clientului cum se va desfășura întregul proces al proiectului:
      • Cum este realizat un proiect folosind tehnologia noastră?
      • Cine este responsabil pentru ce?
      • Cine ce face?
      • De ce se întreprind anumite acțiuni?
      • De ce este nevoie de acest document? Ce dă el ambelor părți? (pentru a le clarifica angajaților că parteneriatele oferă beneficii nu numai nouă, ci și clientului).
      • Cu fiecare ocazie, noi Informam decidentul despre toate problemele care apar in timpul muncii. Pentru a face acest lucru, avem o serie de documente zilnice speciale - de exemplu, „Jurnalul de contacte” sau „Declarația de abateri”. Și dacă nu zilnic, ci la câteva zile, conducerea clientului ar trebui să se familiarizeze cu acestea. Și întrucât, de regulă, se găsesc imediat scuze: am fost ocupat, nu am citit etc., atunci, în consecință, trebuie să reamintim în mod constant despre acest lucru, poate chiar să simulăm unele situații care obligă conducerea să citească aceste documente.

    Rezultatul acestei etape este că toate persoanele responsabile ale clientului au finalizat un curs de prelegeri și, cel mai important, că conducerea are o idee clară despre cum se desfășoară munca (în mod firesc, dacă controlează suficient de strâns proiectul).

    Organizarea relatiilor cu Clientul

    Următoarea etapă este organizarea relațiilor cu Clientul. Aici vreau să vă spun despre un „truc” interesant: avem astfel de roluri în proiect (acestea nu sunt posturi, ci roluri) precum „Contract Manager” și „Object Manager” (cel mai adesea pot fi combinate și cu unele altă responsabilitate). După cum este indicat pe slide-ul de aici, aceste roluri corespund definițiilor „rău” și „bun”.

    • Manager de contract este rău". Acesta poate fi o persoană sau unul dintre managerii de top. Cel mai adesea, funcția de manager de contract este îndeplinită de managerul de proiect (dacă, desigur, este capabil să facă acest lucru). Această persoană este „Nu” - poate veni la factorul de decizie și poate spune: „Este scris așa în contractul nostru, dar acum o faceți diferit și din această cauză există o abatere. Să ne dăm seama.” El subliniază întotdeauna deficiențe, nerespectarea tehnologiei, îndeamnă să respecte documentația De aceea e mereu rău.
    • DAR manager de obiecte- acesta bun". Aceasta este o persoană care, din diverse motive, a dezvoltat o relație bună cu decidentul de la client. Poate i s-a întâmplat să-l placă. Sau, de exemplu, au un fel de legături (rude, clan, prietenos - orice). Principalul lucru este că clientul este localizat la el.
      Obiectul manager menține de fapt acest obiect. Vă rugăm să rețineți că acesta nu este un manager de proiect, este o persoană specială care face ce mentine o relatie buna cu managementul clientului, iar când există unele probleme acute, el le netezește.
      De exemplu, după ce managerul de contract a vorbit cu clientul despre nerespectarea unor condiții din acordurile noastre (aceasta se poate termina, în general, cu un fel de conversație neplăcută pentru noi), managerul de obiect vine și începe să calmeze clientul .
      Nu degeaba am spus că obiectul manager se numește „bun”. Se spune în mod obișnuit că a fi un „băiat drăguț” nu este o profesie. Dar aceasta este profesia noastră. Managerul de obiecte este „tipul drăguț”. Poate că nu este un specialist profesionist în nimic, dar clientul se simte bine cu el - a venit, a vorbit cu el (poate despre politică, fotbal etc.), iar clientul s-a simțit bine, i s-a schimbat atitudinea. Înainte de asta, clientul avea de gând să ne mustre pentru ceva, să ne pedepsească pentru ceva, dar acum înțelege deja totul, este în general incomod să vorbească urât cu noi.
      Aceasta este funcția managerului de obiecte. Este atribuit fiecărui client destul de serios.

    Desigur, tot ceea ce vorbesc necesită anumite resurse și costuri. Și, desigur, a crea toată această structură de dragul unui mic magazin nu are sens - totul se face numai de dragul unor obiecte suficient de mari.

    Rezultatul acestei etape este numirea managerului de contract si obiect adecvat pentru acest client, deoarece este foarte important sa selectezi corect aceste persoane.

    Organizarea proceselor de proiect

    Următoarea etapă este organizarea proceselor de proiect. După părerea mea, sunt doar două dintre ele:

    • Monitorizarea progresului proiectului;
    • Și luarea deciziilor manageriale pe baza rezultatelor monitorizării.

    Cel mai important lucru este să convingem clientul să lucreze conform tehnologiei noastre. Această ordine de lucru este explicată clientului atât în ​​conversațiile personale cu factorii de decizie, cât și atunci când angajații responsabili participă la cursul de prelegeri (se explică cum și ce se va întâmpla pe proiect - angajații clientului trebuie să participe fără greș la acest curs, sub semnătură). ).

    Uneori poate fi foarte dificil să convingi un client să lucreze cu tehnologia noastră. De exemplu, am avut un client - o companie IT foarte mare. Mai mult, ea însăși era angajată în automatizări pe MS Navision, dar din anumite motive a decis să ne sune pentru a le putea automatiza pe 1C. Deci, lucrul cu ei a fost un adevărat coșmar - toată lumea plângea, atât managerii, cât și programatorii. Pentru că era o companie foarte mare (noi suntem mici în comparație cu ei), și au crezut că știu totul și au încercat să ne învețe. Ei au spus constant: „băieți, nu faceți totul așa, există așa și o tehnologie, ar trebui să o faceți așa.” Desigur, asta s-a întâmplat doar la nivelul mijlociu, șeful (care era proprietarul principal și directorul general al companiei), bineînțeles, a înțeles totul perfect, iar după intervenția sa totul s-a hotărât, dar a fost foarte greu să-l prindă. Iar la nivelul mediu au existat probleme constante, încercări constante de a preda.

    Suntem la fiecare proiect, fără greș, Încercăm să transmitem clientului ideea căîn afacerea lui este un profesionist (și noi, desigur, nu mergem acolo), iar în chestiunile de automatizare suntem profesioniști, așa că trebuie să avem încredere și să nu încercăm să ne spunem ce să facem și cum să facem. Mai ales dacă nu doar ne spun, ci încearcă să ne forțeze: „să facem altfel, că vreau eu”. Acestea sunt lucrurile pe care încercăm să le oprim imediat. Desigur, „opriți” este un cuvânt puternic, în orice caz, încercați să-l explicați suficient de blând. Dacă am fost de acord cu acest proiect, am decis că ni se potrivește, ne-am implicat în această „bătălie”, acum, desigur, trebuie să lucrăm cu el.

    Limitarea dorințelor clientului

    Următoarea etapă este limitarea dorinţelor clientului. Toată lumea, probabil, s-a confruntat cu asta (când începe așa-numita „Wishlist” - mai multe, din ce în ce mai multe). Aici o facem destul de simplu:

    • De exemplu, când un client spune că în bugetul și termenele alocate trebuie făcut și asta și asta, atunci începe destul de des, un lucru dificil. explicând cum funcționează totul. Reamintim clientului că avem un buget cu el, sunt alocați oameni (grup de lucru mixt), fiecare parte a proiectului își investește resursele. Prin urmare, dacă apare muncă suplimentară, sunt necesare ore suplimentare, persoane suplimentare. De unde să le ia?
      Sau dacă clientul întârzie proiectul, atunci atât ai noștri, cât și oamenii lui sunt inactiv și sunt plătiți cu bani. De unde să obțineți aceste resurse? Nu vorbesc despre faptul că acești oameni nu numai că primesc un salariu, ci aduc și ceva profit companiei. Firește, compania nu vrea să piardă acest profit. Este explicat clientului suficient de detaliat, iar clientul răspunde de obicei foarte bine.
    • Noi explicam oferim un aspect digital detaliat- unde, ce, până la bănuț. Și spunem asta dacă vrei să facem și noi asta atunci te rog va dura atât de multe ore și trebuie plătite. În final, clientul este de acord cu noi și fie refuză „Wishlist”-ul său, fie plătește ore suplimentare. Desigur, se întâmplă în moduri diferite - acum idealizez puțin imaginea.

    Aici vreau să dau un alt exemplu de relații. Am lucrat cu o companie foarte mare (erau deja în faza de întreținere) și acolo au apărut periodic unele sarcini de îmbunătățire: de exemplu, să facem un fel de raport complicat sau altceva. Și așa, contabilul șef al companiei ne-a încredințat anumite lucrări și am făcut-o. Și când a venit timpul să plătească, a spus: „În general, m-am înșelat, nu avem deloc nevoie de toate acestea”. Dar munca a fost făcută, prin urmare, a fost necesar să se plătească. Și el spune: „Nu, nu voi plăti pentru asta, dar nu pot să mă duc la președintele companiei și să-i spun că sunt un prost și am comandat ceva greșit”. Mai mult, firma era foarte mare, companie petroliera, relatiile erau bune atat cu ea cat si cu aceasta persoana. Și nu am insistat - nu plătește, nu plătește. Deși, din această cauză, am pierdut o sumă destul de mare de bani pentru noi în acel moment (era 2004). La sfârșitul anului a existat o denominație (manatul azerbaigian a aruncat zerouri). Și pentru toți clienții care au fost în serviciul nostru, am făcut această recalculare în stare de funcționare - fără bani în plus. Dar acestui contabil (la vremea aceea a trecut literalmente mai puțin de un an de la acel incident), ne-am apropiat și i-am spus: „Îți amintești, nu ne-ai plătit? Am mers apoi să vă întâlnim. Acum, denominația. Să facem asta gratis?" Fără întrebări - am emis o factură, el a plătit.

    De ce am dat acest exemplu? Despre importanța relațiilor bune. Dacă atunci ne-am fi ridicat și am fi cerut să ne plătim această sumă, atunci am fi avut riscul să pierdem un client bun. Și așa am păstrat legătura cu el.

    Cine este responsabil pentru explicarea acestui buget:

    • Acest în modul de afaceri; în cursul normal al muncii este logodit Manager de proiect- şeful grupului de lucru comun, care, de fapt, realizează proiectul.
    • Dacă eșuează, atunci se conectează manager de contract, care explică prin cifre și spune că acesta este - încălcare a contractului, încălcare a acordului.
    • În cele mai dificile cazuri conectează manager de obiecte care încearcă să explice (deja, desigur, fără nici un cadru rigid) clientului de ce trebuie să-și limiteze dorințele.

    De obicei, dacă numerele sunt scrise în detaliu, atunci acest aspect și explicația ei sunt suficiente.

    Livrarea lucrărilor

    Livrarea lucrărilor. Aici, în general, de obicei nu există mari probleme, pentru că Procedura de predare a lucrărilor este foarte detaliată în nostru relevante documente.

    Dar în această etapă, elementul de informalitate ( relatie buna), desigur, de asemenea face viața mai ușoară atât pentru noi, cât și pentru client de asemenea.

    Scopul acestei etape este realizarea livrării lucrărilor cu respectarea deplină a regulilor stabilite în documentele relevante, care constituie o anexă la contractul semnat atât de client, cât și de noi. În consecință, se poate arăta întotdeauna că există astfel de reguli.

    Relații post-proiect

    Și în sfârșit, relații post-proiect. Aceasta este, de asemenea, o parte foarte importantă. Ce ar trebui să urmărim la finalul proiectului? Până la încheierea unui contract de servicii, desigur. Dar acest lucru nu este întotdeauna cazul. Pentru că există conceptul de „rezultat”, și există conceptul de „rezultat” - și acestea sunt lucruri puțin diferite.

    Vă dau un exemplu. Am avut un proiect cu o companie foarte serioasă, iar rezultatul acelui proiect a fost genial pentru noi - a fost unul dintre acele cazuri rare când am îndeplinit complet atât bugetul, cât și termenul limită, exact așa cum era planificat inițial. Acesta a fost rezultatul. Iar rezultatul proiectului a fost că acordul de servicii nu a fost semnat. Mai mult, clientul a spus că nu va mai lucra niciodată cu noi. Iată rezultatul. Cu alte cuvinte, rezultatul este genial, dar rezultatul este foarte trist.

    De ce s-a întâmplat asta? Pentru că nu existau relații informale. Tocmai dezvoltasem tehnologia noastră de documentare a designului la acel moment, iar acesta a fost clientul pe care a fost demonstrată toată această tehnologie, în toată gloria ei. Și când l-am întrebat pe client: „Ei bine, nu veți lucra cu noi - dar există vreo pretenție împotriva noastră?” Și ni s-a spus printre dinți strânși de furie: „Aceasta este problema, că nu putem face nicio pretenție - orice ai spune, ai o bucată de hârtie pentru orice și nu putem face nimic. Nu suntem mulțumiți de asta și nu vom mai lucra cu tine. Alte companii pot fi rugate să facă ceva suplimentar, dar refuzi - iată bugetul tău, aici îl ai așa cum trebuie, iată termenul limită. Dă-te deoparte - și ne arăți imediat o bucată de hârtie cu semnătura noastră.

    Deci rezultatul este trist. Dar încă o dată subliniez că un astfel de rezultat s-a datorat faptului că nu existau relații informale.

    Acest articol se bazează pe un raport citit de autor la Conferința IE Infostart 2014 29-31 octombrie 2014.

    Vă invităm la o nouă conferință.

    O zi buna! Astăzi aș vrea să vorbesc despre modalitățile în care un client interacționează cu o companie de outsourcing și, de asemenea, să primesc comentarii de la dvs. despre modul în care interacționați cu clienții / dezvoltatorii de software. Acest articol este scris pe baza experienței și, în cea mai mare parte, este destinat clienților de software. Scopul este de a găsi „blocje” în relația dintre client și compania care oferă servicii de dezvoltare software.

    Permiteți-mi să mă prezint: sunt Yury Korkhov și acest articol este primul din Habré-ul meu. Absolvent al Universității Naționale Tehnice din Belarus (inginer de securitate), Universitatea de Stat din Belarus (manager de investiții). Experiență de lucru – peste 6 ani în IT în aproape toate posturile: webmaster, layout designer, web designer, programator, project manager și part-time UI developer, șef departament... În total, în acest timp, peste 80 de proiecte au fost implementate: de la site-uri mici, jocuri pentru telefoane mobile până la mari portaluri de Internet... Profilul principal este managementul dezvoltării proiectelor în domeniul IT. A lucrat atât pe partea clientului, cât și pe partea dezvoltatorului, atât pe piața rusă, cât și pe cea străină.

    Context pentru crearea postării sau Mulțumim Wargaming.

    Ocolirea istoriei creării acestei postări nu ar fi bine, pentru că. Citesc habr de foarte mult timp, dar mâinile mele nu au apucat să scrie un articol, dar aici este o chestiune de „șansă” și acum articolul este gata.

    De câteva luni iau o pauză de la serviciu, pentru că m-am săturat de outsourcing, am decis să găsesc sensul vieții și să-mi pregătesc încet proiectul pentru lansare, iar într-o bună zi a sunat telefonul. Un recrutor Wargaming (fondatorii „tanchiki” și, după părerea mea, una dintre cele mai bune firme din Minsk) m-a sunat cu o ofertă de interviu pentru postul vacant de Vendor Manager (aici trebuie spus că nu căutam un loc de muncă și, judecând după postul lor vacant, nu le-am potrivit). "Interesant!" - M-am gândit și am decis să duc la bun sfârșit sarcina de testare, mai ales că a fost destul de interesant pentru mine. Recruitorul a spus ca au toate conditiile pentru un job placut, sanatos (fitness, asigurare etc.) si bine platit si, nu in ultimul rand, mi-ar lua cam 3 ore sa duc la bun sfarsit sarcina de testare. Mă îndoiesc că cineva ar fi putut finaliza întreaga sarcină de testare în timpul specificat, ca și pentru mine - a durat aproximativ 6 ore în total.

    Spre regretul meu, feedback-ul companiei a fost într-o convorbire telefonică și a fost exprimat în expresia uscată „totul este bine, tuturor le-a plăcut” (nu îmi amintesc literal, dar esența este aceasta) și fără detalii. Mă îndoiesc că am reușit să evidențiez toate „gâturile de sticlă” principale; nu e bine să irosești munca, am decis să postez răspunsurile la sarcina de testare (cu modificări minore, pentru comoditate) în public și voi fi recunoscător publicului habra pentru completările și comentariile sănătoase la articol.

    Schema de interactiune client - dezvoltator software de la prima intalnire pana la sfarsitul relatiei.

    Când proiectați un circuit, mă refer la:
    1. Dezvoltatorul de software este capabil să finalizeze proiectul.
    2. Înainte de asta, contractul nu era semnat cu dezvoltatorul de software și nu existau proiecte.
    3. TK este gata.
    4. Termenele de plată sunt reglementate de contract.
    5. Sunt utilizate sisteme de management de proiect și metodologii de dezvoltare software (XP, Scrum, Lean, Kanban, ScrumBut etc.).
    6. Completarea aplicației cu conținut (dacă este necesar) se face de către client.

    Aspectele contractului dintre furnizorul de dezvoltare de software și client sunt avantajoase de evitat de către furnizor (simplificați, eliminați complet din contract).

    1. Responsabilitatea respectării termenelor revine dezvoltatorului, iar dacă termenele sunt ratate în ultimul moment (adică dezvoltatorul nu a anunțat în prealabil că nu a avut timp înainte de închidere), trebuie impuse penalități (există o selecție mare). de opțiuni).
      Motiv: nerespectarea termenelor este una dintre cele mai mari probleme și menționarea ei în contract nu este foarte interesantă, pentru că. În cea mai mare parte, nerespectarea termenelor limită este de partea dezvoltatorului. Aici trebuie să țineți cont de faptul că este dificil de calculat exact, dar este necesar să avertizați în prealabil că dezvoltatorul nu are timp să finalizeze etapa de dezvoltare într-o anumită perioadă de timp și acest lucru trebuie să fie prescris în contract.
    2. Condiții de garanție pentru remedierea „bug-urilor” din vina dezvoltatorului care nu au fost detectate la timp. Perioada obișnuită de garanție este de 3 luni.
      Motiv: se întâmplă adesea ca unele „defecțiuni” să nu fi fost remediate sau să fi apărut deja în procesul de lucru, astfel încât acest articol este adesea încercat să nu indice sau să reducă timpul de garanție. Parerea mea este ca mai putin de 3 luni nu sunt suficiente.
    3. Drepturi asupra software-ului dezvoltat, modulelor, blocurilor etc. aparțin clientului și nu poate fi utilizat pentru revânzarea ulterioară.
      Motiv: Este benefic pentru dezvoltator să aibă drepturi de proprietate intelectuală sau să poată vinde/utiliza dezvoltări pentru alți clienți, ceea ce la rândul său poate pune clientul într-o situație incomodă pe piață.
    4. La dezvoltarea unui modul nou în sistem care afectează funcționarea altor module sau a întregului sistem, dezvoltatorul trebuie să asigure funcționarea întregului sistem.
      Motiv: de multe ori dezvoltarea unui modul poate dăuna funcționării altui modul sau a întregului sistem în general, iar îmbunătățirile ulterioare pot cădea pe „umerii” (financiar) clientului. Dezvoltatorul este obligat să ia în considerare structura întregului sistem și, în cazul „bug-urilor” găsite de client, să o corecteze gratuit.
    5. Documentația tehnică pentru dezvoltare trebuie pregătită ținând cont de cerințele clientului.
      Motiv: este benefic pentru dezvoltatori să se lege complet de client și se întâmplă adesea ca documentația să nu fie menținută.
    6. În cazul dezvoltării unui site web, contractorul trebuie să țină cont de optimizarea SEO pentru site și anume: descrierea imaginilor, paginilor...
      Motiv: economisirea de timp la „lucruri mărunte”, care, în funcție de termenii contractului, poate duce la pierderi financiare pentru client (dezvoltatorul de software economisește timp/finanțe).
    7. Testarea sistemului ar trebui să fie furnizată de dezvoltatorul sistemului.
      Acceptarea de către client a modulului finit nu trebuie să se transforme în testarea sistemului, de exemplu. dezvoltatorul este obligat să întreprindă eliminarea „bug-urilor” identificate de către client pe cheltuiala sa. Acest lucru este necesar pentru a asigura testarea calității produsului de către dezvoltator. Până când dezvoltatorul spune „terminat” și începe testarea clientului, „bug-urile” sunt remediate gratuit.
    8. Responsabilitatea găzduirii proiectului din partea clientului este asumată de dezvoltator. În acest caz, clientul este obligat să se asigure că sunt îndeplinite cerințele tehnice ale site-ului.
      Motiv: găzduirea unui proiect de partea clientului poate provoca uneori anumite dificultăți, care pot duce la „pălărie”, așa că responsabilitatea pentru găzduirea și configurarea serverului ar trebui să fie de partea dezvoltatorului de software.
    9. În cazul în care dezvoltatorul de software este nevoit să recurgă la ajutorul unor specialiști din afara echipei sale, acesta este obligat să își asume toate riscurile asociate pentru scurgeri, pierderi de date sau orice alte daune pe care un angajat din exterior le poate provoca prin acțiunea sau inacțiunea sa.
      Motiv: se întâmplă ca un dezvoltator să se îmbolnăvească, să renunțe etc. unul dintre angajati. În acest caz, clientul trebuie să fie asigurat.
    10. Copiile de rezervă ale proiectului trebuie furnizate de partea dezvoltatorului cel puțin o dată pe zi. Orice problemă cu pierderea datelor din proiect ar trebui preluată de dezvoltator.
      Motiv: aici trebuie să indicați cine este responsabil pentru siguranța proiectului în cazul oricăror defecțiuni.
    11. Dezvoltatorul ar trebui să plece de la popularitatea utilizării tehnologiilor pe care le folosește atunci când alege.
      Motiv: legarea la propriile tehnologii, ceea ce va complica viața dacă clientul se mută la alt dezvoltator.

    Modalități cunoscute de supraestimare a costurilor de externalizare a muncii în raport cu realitatea Presupun că sunt mai multe.

    • O estimare superficială a costului dezvoltării proiectului în ansamblu, fără a-l împărți în etape, ceea ce poate duce la un exces de 2x-3x din costul proiectului.
    • Neprezentarea rapoartelor asupra lucrărilor efectuate în perioada specificată în contract sau incapacitatea de a controla progresul dezvoltării de către client
    • Alegerea greșită a tehnologiei în implementarea părții tehnice poate crește semnificativ costul dezvoltării.
    • Lipsa specialiștilor potriviți în echipa de dezvoltare, ceea ce crește timpul și costul dezvoltării.
    • Un cost fix pentru dezvoltarea unui proiect sau modul și o creștere suplimentară a costului pentru fiecare lucru mic pe care ambele părți l-au înțeles diferit.
    • Stabilirea fixă ​​a costurilor de dezvoltare a proiectului - un risc mai mare face necesară includerea în costul proiectului.
    • Atunci când se dezvoltă un design, prototipul nu este utilizat, iar dezvoltarea designului se realizează pe baza unei specificații tehnice textuale, ceea ce duce în cele din urmă la un număr mare de îmbunătățiri/corecții și, în consecință, la o creștere a costului proiectului.
    • Adăugarea/complicarea funcționalității. Poți să-l faci mai ușor - să-l faci mai greu.
    • „Frumos” acolo unde nu sunt necesare (puteți spune despre partea admin. a site-ului, dacă puteți folosi framework-uri css pentru personalizarea rapidă a părților admin. - încep să se dezvolte de la zero).

    Modelul de relație „client - furnizor de dezvoltare software”, care, în opinia mea, este cel mai apropiat de utilizare practică.

    Multe companii de outsourcing preferă să nu ofere acces la sistemele lor de management al proiectelor fără a oferi informații detaliate, eu personal cred că accesul ar trebui asigurat la cererea clientului. Clientul este responsabil pentru implementarea proiectului și este important să vadă progresul dezvoltării în timp real!
    De asemenea, cred că dezvoltarea de software ținând cont de calculul costului total al proiectului este o risipă de bani și un nerv, o astfel de dezvoltare duce de obicei la situații conflictuale.
    Principalele puncte în interacțiunea dintre dezvoltatorul de software și client, pe care le consider optime:
    1. Plata pentru muncă în funcție de salariul orar pentru munca angajaților sau costul mediu al muncii unui specialist al întregii echipe de dezvoltare. Este necesară evaluarea etapelor de dezvoltare. De ce cred că această formă de preț este optimă:
      • Nu necesită o abordare foarte scrupuloasă în evaluarea proiectelor, ceea ce este aproape imposibil de făcut 100% precis. Dacă evaluarea este făcută incorect și dezvoltatorul de software începe să înțeleagă acest lucru, atunci funcționalitatea este „încălcată” ori de câte ori este posibil, ceea ce va afecta în cele din urmă capacitatea de utilizare.
      • Îmbunătățește înțelegerea reciprocă între dezvoltatorul de software și client, ca sarcina principală se reduce la principiul - „fă-o eficient și rapid”, și nu „investiți într-un buget restrâns și cum va funcționa bine”.
      • Clientul, pe baza rapoartelor zilnice privind orele petrecute, poate vedea cât timp petrec angajații pe diferite blocuri în timpul dezvoltării, ceea ce oferă o înțelegere a vitezei și calității muncii angajaților dezvoltatorilor de software.
      • Interacțiunea dintre client și managerul de proiect se realizează cât mai direct posibil, adică. când folosești skype, telefoane etc.
    2. Doar rapoartele și planurile de 2 săptămâni trebuie trimise prin poștă (pentru control).
    3. Clientul oferă un prototip al aplicației sau este dezvoltat de echipa de dezvoltare software, dacă este necesar:
      • Simplifica înțelegerea principalelor funcționalități ale proiectului.
      • Crește viteza generală de dezvoltare a proiectului.
      • Cerințe clare pentru funcționalitatea clientului și a dezvoltatorului.
      • Înțelegerea clară a locului în care se va muta proiectul.
    4. Sistem de management al proiectelor pentru a urmări progresul proiectului și capacitatea de a monitoriza procesul, timpul de dezvoltare petrecut pe fiecare sarcină separat. Din păcate, dezvoltatorii oferă rareori acces.
    5. Este de dorit ca întregul proiect să fie realizat de o singură echipă, adică nu ar trebui ca o etapă să fie făcută de o companie, cealaltă de alta și așa mai departe.
    6. Puncte de control („run”) la fiecare 2 săptămâni este momentul optim pentru a controla proiectul.
    7. În dezvoltare, se preferă cadrele cunoscute, de asemenea pentru o adaptare mai ușoară în cazul oricărei situații în care este necesară transferarea proiectului către alți dezvoltatori.
    8. Testarea calității din partea dezvoltatorului este o responsabilitate directă. Când transferați un proiect sau o parte a acestuia către un client, totul trebuie verificat cu atenție.
    9. Sprijinirea diferitelor browsere este sarcina directă a dezvoltatorului

    Concluzie: principalul lucru este să adere la relații de parteneriat / reciproc avantajoase și de încredere, înțelegând că dezvoltatorii sunt aceiași oameni și complicarea vieții le complică viața pentru tine! Toată lumea ar trebui să fie responsabilă pentru partea sa din muncă, clientul ar trebui să fie responsabil pentru furnizarea unei specificații tehnice clare și să răspundă prompt la întrebările care apar, fără a uita să plătească pentru lucrare, iar dezvoltatorul - pentru calitate, timp, viteză. Idealul, desigur, nu a fost atins, dar suntem pe drumul cel bun.

    imi place

    21

    În diferite surse de literatură despre vânzări, puteți găsi un număr diferit de etape ale vânzării. Fiecare autor le consideră din punctul său de vedere.

    Îmi propun să luăm în considerare etapele cheie în lucrul cu Clientul>:

    Etapa 1 „Stabilirea contactului” sau „Stabilirea contactului”

    Orice vânzare începe din această etapă.

    Scopul acestei etape: să cucerească Clientul și să-l intereseze în continuare.

    La stabilirea contactului cu Clientul, este important să îl salutați și să vă prezentați.

    "Buna ziua. Numele meu este Mihail, sunt managerul companiei „Windows Plus”.

    Înainte de a începe o conversație despre nevoile Clientului, este recomandat să discutați cu el pe un subiect abstract (tehnica „Small Talk”) sau să oferiți ceai, cafea, puteți face un compliment sau utilizați o serie de alte tehnici a etapei de stabilire a contactului.

    "Ce stii despre compania noastra? De ce ne alegeți pe noi? Ce ai de gând să cumperi?

    Este important ca managerul, prin comportamentul sau non-verbal, sa demonstreze interes pentru contactul cu Clientul, dorinta de a-l ajuta, bunavointa. Comportamentul non-verbal include gesturi deschise, postură, zâmbet, înclinarea corpului spre Client, privirea deschisă.

    Este posibil să se determine dacă contactul cu Clientul a fost stabilit sau nu prin comportamentul Clientului. Dacă reacționează pozitiv la cuvintele managerului, se simte relaxat, pune el însuși întrebări, putem presupune că contactul a fost stabilit. Dacă Clientul nu menține contactul vizual cu managerul, este tensionat, nu răspunde la întrebări sau răspunde fără tragere de inimă, atunci este logic să aloci mai mult timp etapei de stabilire a contactului.

    Etapa 2 „Identificarea nevoilor”

    Scopul acestei etape: pentru a determina nevoile Clientului.

    Cu cât managerul determină mai precis nevoile Clientului, cu atât va face mai eficient o prezentare a bunurilor și serviciilor, care va duce ulterior la o afacere.

    La identificarea nevoilor, este important ca un manager să poată pune întrebări și să asculte Clientul.

    Atunci când interacționați cu Clientul, este important ca acesta să vorbească mai mult, și nu managerul; pentru aceasta, managerului i se recomandă să seteze mai multe întrebări deschise.

    Ce fereastră intenționați să cumpărați? Unde vei schimba fereastra? Care este clima în apartament iarna și vara? Cine mai locuiește în apartament? Din ce motive alegi o fereastră?

    Întrebări închise managerul permite specificarea nevoilor Clientului.

    „Aerisiți des camera? Ai animale? Vă este convenabil dacă măsuratorul nostru sosește mâine la ora 9 dimineața?”

    Întrebări alternative oferi clientului o gamă de opțiuni.

    „Este convenabil pentru tine să vină măsuratorul dimineața sau după-amiaza? Avem de gând să instalăm ferestre noi săptămâna aceasta sau viitoare?”

    Pe parcursul întregii întâlniri cu Clientul, este util să-l ascultați cu atenție, deoarece Clienții vorbesc adesea deschis despre nevoile lor înșiși. Dacă unele cuvinte ale Clientului nu sunt clare pentru manager sau acesta le-a ascultat, este recomandabil să îi adresați Clientului întrebări clarificatoare:

    „Am înțeles bine că aveți nevoie de o fereastră cu izolare fonică sporită? Din câte am înțeles, vrei ca o cerceve a ferestrei să fie pivotantă, iar cealaltă să fie înclinată?

    Este de dorit să rezumați rezultatul intermediar după fiecare problemă discutată. Mai ales dacă managerul discută cu Clientul mai multe produse sau servicii.

    „Astfel, am convenit că vom măsura mâine, iar săptămâna viitoare vom monta geamuri vineri. Așadar, intenționați să instalați două ferestre noi: în bucătărie, o fereastră cu două canape, cu canapea, iar într-o cameră, o fereastră cu trei canape, în care două canape sunt basculante și unul este „surd”.

    Este important să identificați cu exactitate nevoile clientului și abia apoi să realizați o prezentare a bunurilor și serviciilor.

    Etapa 3 „Prezentare”

    Ţintă: oferi un produs sau serviciu care satisface cel mai bine nevoile Clientului.

    Prezentarea produselor și serviciilor conține o descriere a caracteristicilor bunurilor și serviciilor, beneficiile din utilizarea acestora de către client și beneficiile pe care consumatorul le primește.

    Este util să începem prezentarea cu beneficiile cheie ale Clientului, care decurg din nevoile cumpărătorului, identificate de manager la etapa anterioară.

    Este important să distingem modul în care beneficiul unui produs sau serviciu diferă de un beneficiu.

    Avantaj este beneficiul pe care îl primește orice Client prin utilizarea acestui produs sau serviciu.

    „Cu acest serviciu, puteți economisi timp și puteți reduce costurile cu 10%. „Acest fiting vă permite să reduceți numărul de ajustări.”

    Beneficiu este o caracteristică sau un avantaj care vă permite să satisfaceți o nevoie specifică a Clientului.

    Astfel, orice caracteristică sau avantaj poate deveni un beneficiu, cu condiția ca Clientul să aibă nevoie de el.

    „Ați dorit ca fereastra să fie ușor de deschis și închis, armăturile de calitate europeană o pot oferi.” „Ați spus că apartamentul este situat la primul etaj și vă este teamă pentru securitatea apartamentului, vă sugerez să instalați feronerie antiefracție la noile ferestre.”

    În timpul prezentării, managerul trebuie să includă Clientul într-un dialog activ folosind întrebări.

    „Ce părere aveți despre propunerea mea?”, „Ce părere aveți despre asta?”, „Cum vă place propunerea mea?”

    Etapa 4 „Lucrul cu obiecțiile”

    Ţintă: pentru a înlătura îndoielile Clientului cu privire la achiziție și pentru a elimina negativul în legătură cu produsul sau serviciul.

    Pentru a reduce numărul de obiecții ale Clientului, este util ca managerul să dedice mai mult timp etapelor anterioare. Adesea obiecțiile Clienților sunt legate de faptul că contactul cu acesta nu a fost bine stabilit, nevoile sale au fost parțial identificate, sau prezentarea bunurilor și serviciilor nu a fost interesantă pentru Client, a fost prea lungă și nu i-a satisfăcut. are nevoie.

    Este important să percepem obiecțiile Clientului ca un semnal că managerul trebuie să-și corecteze comportamentul (mai ales dacă există o mulțime de obiecții).

    Pot apărea obiecții din partea Clientului și în etapele anterioare ale vânzării. Cum să tratăm obiecțiile care apar?

    Respectați în mod efectiv schema de gestionare a obiecțiilor:

    1. ascultați Clientul;

    2. să-și neutralizeze emoțiile folosind fraze de înțelegere;

    „Te înțeleg”, „Da, sunt de acord că este neplăcut...”

    3. clarifica, daca este necesar, informatiile folosind intrebari;

    4. oferi soluții constructive sau face o propunere alternativă.

    Există 4 tipuri de obiecții ale clienților:

    1. obiecții legate de modificări.

    „De ce am nevoie de asta”, „Nu văd rostul în asta”

    În confruntarea cu o astfel de obiecție, managerul trebuie să explice Clientului că riscurile sunt excluse, să arate consecințele dacă situația continuă, să dea exemple de experiență pozitivă folosind ceva pentru prima dată.

    „Achiziționând o fereastră cu feronerie europeană, sunteți garantat că veți fi protejat de curenți de aer, ajustări suplimentare ale presiunii cercevelei, blocarea mecanismului de închidere.”

    2. obiecții legate de preț.

    „Este prea scump pentru mine”.

    În argumentare, managerul ar trebui să acorde atenție beneficiului suplimentar pe care îl primește Clientul, puteți compara costul mărfurilor cu costul oricărui alt lucru nu foarte necesar sau puteți împărți costul la o anumită perioadă de timp.

    „Când cumpărați o fereastră de la compania noastră, primiți cadou un kit de îngrijire a ferestrelor, precum și posibilitatea de a utiliza reglarea gratuită a fitingurilor”, „O fereastră nouă frumoasă în bucătărie vă va costa doar 300 de ruble. într-o zi".

    3. obiecţii legate de experienţele negative.

    — Am auzit că ai un profil prost.

    Este util ca managerul să clarifice informațiile punând întrebări Clientului, să îi arate Clientului că îl înțelegi și să recunoști faptele evenimentelor neplăcute (în cazul în care acestea ar fi fost în realitate) și apoi să ofere o soluție alternativă.

    „Da într-adevăr, am avut un lot de profil defect, pe care l-am returnat furnizorului. În acest moment, am primit un lot nou, am fabricat și instalat deja peste 30 de ferestre, toți Clienții sunt mulțumiți.”

    4. obiecții legate de decizie.

    „Trebuie să mă gândesc”, „Trebuie să mă consult cu soția mea”.

    În tratarea unor astfel de obiecții, managerul poate clarifica încă o dată cu ce este legată o astfel de decizie, se poate asigura că clientul a acceptat și a înțeles toate informațiile și, de asemenea, poate utiliza metodele de finalizare a tranzacției.

    „Dacă semnăm un acord cu tine acum, atunci la sfârșitul săptămânii vei putea admira noua fereastră din bucătărie.” „Doar până la sfârșitul lunii avem reducere la acest produs”.

    Etapa 5 „Finalizarea tranzacției”

    Ţintă:împingeți Clientul la tranzacție și confirmați corectitudinea deciziei luate de acesta.

    Înainte de a finaliza o afacere (semnarea unui contract), managerul trebuie să se asigure că Clientul este pregătit să încheie o afacere.

    Acest lucru se poate vedea din semnalele pe care le arată:

    • feedback pozitiv despre un produs sau serviciu;
    • Clientul își exprimă aprobarea față de cuvintele managerului (aprobă, dă din cap, etc.);
    • spune direct că este de acord;
    • pune întrebări clarificatoare.

    Metode de finalizare a tranzacțiilor:

    1. metoda de limitare a conditiilor si timpului.

    „Dacă semnezi contractul astăzi, îți oferim o reducere de 20% la fereastră”.

    2. metoda complimentului.

    — Chiar ai făcut alegerea corectă.

    3. alternativă câștig-câștig.

    „Veți fi rezervat pentru o măsurare marți sau miercuri?”

    În concluzie, aș dori să spun că eficiența vânzărilor depinde de priceperea managerilor. Cu cât un manager are mai multe metode și tehnici de vânzare, cu atât este mai flexibil și mai de succes atunci când interacționează cu Clientul. Profesia de manager de vânzări necesită dezvoltarea constantă și autoperfecționarea competențelor. Vă dorim succes pe calea creșterii profesionale și a creșterii vânzărilor.




    Articole similare
    ultimele articole
    Articole populare
    Alegerea editorilor
    rin-tek.ru