Tehnologije interakcije sa internim kupcem. Upravljanje projektima. Informisanje Kupca o tehnologiji upravljanja projektima

Želim se fokusirati na stvaranje pozitivne slike. Na osnovu prikupljenih početnih informacija odlučujemo kome od naših zaposlenika možemo vjerovati da će predstavljati našu firmu na prvom sastanku sa klijentom. Ovo je veoma važna tačka. Na primjer, ako za prvi kontakt pošaljemo odličnog specijaliste, a on ima minđušu u uhu, “kuharicu” natopljenu mašću itd., tada klijent može pogledati i reći: “Ma, ajde!” Dešava se. Ili, na primjer, uredan, dotjeran, u odijelu s kravatom, ali je ušao dječak od nekih 20 godina. A klijent gleda i kaže: „Ovo je dječak, o čemu da pričam s njim? Kako sa njima raditi - uopšte me ne poštuju, poslali su mi dečka! Stoga je prikupljanje ovih informacija neophodno, između ostalog, kako bi se razumjelo kome povjeriti prvi kontakt i kako se ponašati prema kontaktu, kako izgraditi legendu, kako se predstaviti.

Identifikacija donosioca odluka

Sljedeće vrlo važno pitanje je identifikaciju osoba koje stvarno donose odluke(tzv. LPR). Ova faza se sastoji od dvije stavke:

• Ispostavilo se, ko donosi odluke prema našem projektu.
• I druga tačka - identifikovane su osobe koje utiču na donosioce odluka.
  Šta to znači? Na primjer, poznato je da odluke u kompaniji donosi generalni direktor, a ima i finansijskog direktora i računovođu. To može biti računovođa koji radi sve što direktor kaže i mirno sjedi u ćošku, ili možda obrnuto, računovođa koji ovako govori direktoru šta da radi, a direktor ga posluša. A ako smo u početku otkrili da ta osoba ima utjecaja na svog direktora, onda je to naš adut, stoga trebamo pokušati uspostaviti odnose s tim računovođom. Uslovno sam rekao da je ovo računovođa - može biti bilo ko (na primjer, šef odjela prodaje ili neki zamjenik kojemu generalni direktor ili vlasnik kompanije potpuno vjeruje). Neophodno je uspostaviti odnose sa osobom koja utiče na donosioca odluka.

Cilj je, kao što vidite, identifikovati donosioce odluka. I rezultat je lista donosilaca odluka i osoba koje utiču na donosioce odluka.

Naše iskustvo to pokazuje pokušajte da se sastanete sa donosiocima odluka što je pre moguće- obično su ili top menadžment ili vlasnik kompanije. To ne mora da se desi pri prvom kontaktu, ali ako do takvog sastanka ne dođe u preliminarnoj fazi, onda, po pravilu, od našeg projekta neće biti ništa dobro.

Uspostavljanje partnerstva

Sljedeća faza - uspostavljanje partnerstava.

• U početku radimo naglasak na bilateralnoj odgovornosti: čak iu ugovoru, ako je moguće, ne propisujemo kupca-izvođača, već “ Prva strana" (ovo je Kupac) i " Druga strana” (ovo je Izvođač). Istina, ponekad neke velike državne strukture kažu da im pravna služba to ne dozvoljava, jer dokumente provjeravaju Trezor, Ministarstvo finansija i drugi. U ovom slučaju propisujemo standardni tekst - "Kupac i Izvođač". Ali ako je moguće, onda - "Prva" i "Druga strana".
• Na svaki način pokušavamo da dočaramo da je ovo zajednički rad. Lideri sa obe strane djeluju kao visoke ugovorne strane - upravo su oni odlučili napraviti ovaj projekat automatizacije. Za ovaj projekat oni regrutovati tim od kako od osoblja prvog stranke, one zaposlenih druga strana je tzv Zajednička radna grupa“, što čini projekat. Naravno, svaka strana ulaže u projekat svoje resurse: materijalne, tehnološke, metodološke, finansijske - jer, generalno, govorimo o prilično velikim projektima.
• Rad zajedničke radne grupe nadgleda« Zajednička nadzorna komisija" je najviše kontrolno tijelo, koje se obično sastoji od najvišeg rukovodstva obje strane.
• I potpisuje odgovornost svake strane tako da zaposlenici klijenta shvate da smo ne samo mi, već i oni odgovorni za projekat. Ulažemo mnogo vremena i truda da dočaramo klijentu da ovaj projekat radimo zajedno sa njegovim zaposlenima, te da njihov rad direktno zavisi od toga kakav će kvalitet i, posebno, u kom roku će projekat biti završen.

Pa rezultat ovoj fazi je fiksacija(formalno ili neformalno) odnosi ravnopravni partneri:

• Formalna fiksacija je ugovor.
• I neformalno - to mogu biti neki zvanični dokumenti u kojima se uvijek trudimo da propišemo "Prva i Druga strana" i njihov odnos.

Informisanje Kupca o tehnologiji upravljanja projektima

Sljedeća faza je informiranje kupca o tehnologiji.

• Na velikim projektima, bez greške, imamo " Kurs predavanja i seminara o uvodu u tehnologiju projektovanja". Na ovom kursu predavanja zaposlenima kod naručioca upoznajemo kako će se odvijati cijeli projektni proces:
  • Kako se projekt izrađuje pomoću naše tehnologije?
  • Ko je za šta odgovoran?
  • Ko šta radi?
  • Zašto se preduzimaju određene radnje?
  • Zašto je potreban ovaj dokument? Šta daje obema stranama? (da zaposlenima bude jasno da partnerstva pružaju koristi ne samo nama, već i klijentima).
  • U svakoj prilici, mi Obavještavamo donosioca odluka o svim problemima koji se javljaju u toku rada. Da bismo to učinili, imamo niz posebnih dnevnih dokumenata - na primjer, "Dnevnik kontakata" ili "Izjava o odstupanjima". I ako ne svakodnevno, nego svakih nekoliko dana, menadžment kupaca bi se trebao upoznati s njima. A budući da se u pravilu odmah pronađu izgovori: bio sam zauzet, nisam čitao itd., onda, shodno tome, moramo stalno podsjećati na to, možda čak i simulirati neke situacije koje primoravaju menadžment da pročita ove dokumente.

Rezultat ove faze je da su sve odgovorne osobe naručioca završile kurs predavanja i, što je najvažnije, da menadžment ima jasnu predstavu o tome kako se posao obavlja (naravno, ako je dovoljno čvrsto kontroliše projekat).

Organizacija odnosa sa Kupcem

Sljedeća faza je organizacija odnosa sa Kupcem. Ovdje želim da vam kažem o jednom zanimljivom "triku": imamo takve uloge na projektu (to nisu pozicije, već uloge) kao što su "Upravitelj ugovora" i "Upravitelj objekata" (najčešće se mogu kombinirati i sa nekim druga odgovornost). Kao što je navedeno na slajdu ovdje, ove uloge odgovaraju definicijama "loše" i "dobre".

• Menadžer ugovora je loše". To može biti pojedinac ili jedan od top menadžera. Najčešće funkciju menadžera ugovora obavlja menadžer projekta (ako je, naravno, u mogućnosti to učiniti). Ova osoba je „Ne“ – može doći do donosioca odluke i reći: „Ovako je zapisano u našem ugovoru, ali sada to radite drugačije i zbog toga dolazi do odstupanja. Hajde da to shvatimo." Uvijek ukazuje na nedostatke, neusklađenost sa tehnologijom, poziva na poštivanje dokumentacije Zato je uvek loš.
• ALI upravitelj objekata- ovaj dobar". Riječ je o osobi koja je iz različitih razloga razvila dobar odnos sa donosiocem odluka od strane kupca. Možda mu se samo dopao. Ili, na primjer, imaju nekakve veze (rod, klan, prijateljske - svejedno). Glavna stvar je da se klijent nalazi kod njega.
  Objekt menadžera zapravo održava ovaj objekt. Napominjemo da ovo nije menadžer projekta, već posebna osoba koja radi šta održava dobar odnos sa menadžmentom klijenta, a kada se pojave neki akutni problemi, on ih izglađuje.
  Na primjer, nakon što je ugovorni menadžer razgovarao sa klijentom o nepoštivanju nekih uslova naših ugovora (ovo se može završiti, općenito, nekom vrstom neugodnog razgovora za nas), dolazi menadžer objekta i počinje smirivati ​​klijenta .
  Nisam uzalud rekao da se objekat menadžera zove „dobar“. Uobičajeno se kaže da biti "fin momak" nije profesija. Ali ovo je naša profesija. Menadžer objekata je "fin momak". Možda nije stručan ni za šta, ali klijent se sa njim oseća dobro – došao je, razgovarao sa njim (možda o politici, fudbalu itd.), i klijent se osećao dobro, promenio mu se stav. Prije toga je klijent htio da nas za nešto ukori, da nas za nešto kazni, ali sada već sve razumije, generalno mu je neprijatno da loše priča sa nama.
  Ovo je funkcija upravitelja objekata. Dodjeljuje se svakom prilično ozbiljnom klijentu.

Naravno, sve o čemu govorim zahtijeva određena sredstva i troškove. I, naravno, stvaranje cijele ove strukture radi male trgovine nema smisla - sve se to radi samo zbog dovoljno velikih objekata.

Rezultat ove faze je imenovanje odgovarajućeg menadžera ugovora i objekata za ovog klijenta, jer je veoma važno pravilno odabrati te ljude.

Organizacija projektnih procesa

Sljedeća faza je organizacija projektnih procesa. Po mom mišljenju postoje samo dva od njih:

• Praćenje napretka projekta;
• I donošenje menadžerskih odluka na osnovu rezultata praćenja.

Najvažnije je uvjeriti kupca da radi po našoj tehnologiji. Ova procedura se objašnjava kupcu kako u ličnim razgovorima sa donosiocima odluka tako i kada odgovorni zaposleni prisustvuju kursu predavanja (objašnjava kako i šta će se dešavati na projektu - zaposlenici naručioca moraju obavezno pohađati ovaj kurs, uz potpis).

Ponekad može biti vrlo teško uvjeriti kupca da radi s našom tehnologijom. Na primjer, imali smo jednog klijenta - veoma veliku IT kompaniju. Štaviše, i sama se bavila automatizacijom na MS Navisionu, ali je iz određenih razloga odlučila da nas nazove kako bismo ih automatizirali na 1C. Dakle, rad s njima je bio prava noćna mora - svi su plakali, i menadžeri i programeri. Zato što je to bila velika kompanija (mi smo mali u odnosu na njih), a oni su mislili da znaju sve i pokušavali su da nas nauče. Stalno su govorili: "Momci, ne radite sve tako, postoji takva i takva tehnologija, tako treba da radite." Naravno, to se dogodilo samo na srednjem nivou, šef (koji je bio glavni vlasnik i generalni direktor kompanije) je naravno sve savršeno razumio i nakon njegove intervencije sve je odlučeno, ali ga je bilo jako teško dobiti. A na srednjem nivou postojali su stalni problemi, stalni pokušaji podučavanja.

Mi smo na svakom projektu, bez greške, Trudimo se da klijentu prenesemo tu ideju u svom poslu je profesionalac (a mi tu, naravno, ne idemo), a po pitanju automatizacije smo profesionalci, tako da treba vjerovati a ne pokušavati da nam govori šta i kako da radimo. Pogotovo ako nam ne kažu samo, već nas pokušavaju natjerati: „Hajde da uradimo drugačije, jer ja to želim“. To su stvari koje pokušavamo odmah zaustaviti. Naravno, "stop" je jaka riječ, u svakom slučaju pokušajte to objasniti dovoljno blago. Ako smo pristali na ovaj projekat, odlučili da nam odgovara, uključili se u ovu „bitku“, sada, naravno, moramo da radimo s tim.

Ograničenje želja klijenta

Sljedeća faza je ograničenje želja klijenta. Svi su se, vjerovatno, suočili s tim (kada počne tzv. "lista želja" - sve više i više). Ovdje to radimo vrlo jednostavno:

• Na primjer, kada klijent kaže da u predviđenom budžetu i rokovima i ovo i to mora biti urađeno, onda to počinje prilično često, teško objašnjavajući kako sve funkcioniše. Podsjećamo klijenta da kod njega imamo budžet, dodjeljuju se ljudi (zajednička radna grupa), svaka strana projekta ulaže svoja sredstva. Dakle, ako se pojavi dodatni posao, onda su potrebni dodatni sati, dodatni ljudi. Odakle ih uzeti?
  Ili ako klijent odugovlači sa projektom, onda i naši i njegovi miruju, a novac im se plaća. Gdje nabaviti ove resurse? Ne govorim o tome da ti ljudi ne samo da primaju platu, već donose i neki profit kompaniji. Naravno, kompanija ne želi da izgubi ovaj profit. Klijentu je dovoljno detaljno objašnjeno, a klijent obično vrlo dobro odgovara.
• Objašnjavamo dajemo detaljan digitalni izgled- gde, šta, do penija. I mi to kažemo ako želite da i mi ovo uradimo onda molim to će trajati toliko sati i oni moraju biti plaćeni. Na kraju se klijent slaže sa nama i ili odbija svoju "listu želja" ili plaća dodatne sate. Naravno, to se dešava na različite načine - sada malo idealizujem sliku.

Ovdje želim dati još jedan primjer odnosa. Radili smo sa jednom jako velikom kompanijom (oni su već bili u fazi održavanja) i tu su se periodično javljali neki zadaci za poboljšanja: na primjer, napraviti kakav škakljiv izvještaj ili nešto treće. I tako nam je glavni računovođa firme povjerio određeni posao i mi smo to uradili. A kada je došlo vrijeme za plaćanje, rekao je: „Uglavnom, pogriješio sam, ne treba nam sve ovo. Ali posao je obavljen, pa je bilo potrebno platiti. A on kaže: „Ne, neću da platim ovo, ali ne mogu da odem do predsednika kompanije i da mu kažem da sam budala i da sam pogrešno naručio“. Štaviše, kompanija je bila veoma velika, naftna kompanija, odnosi su bili dobri i sa njom i sa ovom osobom. I nismo insistirali – ne plaća, ne plaća. Iako smo zbog toga tada (bilo je 2004. godine) za nas izgubili prilično veliku svotu novca. Na kraju godine postojala je denominacija (azerbejdžanski manat je odbacio nule). A za sve klijente koji su bili u našoj službi, ovaj preračun smo uradili u radnom stanju - bez dodatnih para. Ali ovoj računovođi (tada je od tog incidenta prošlo bukvalno manje od godinu dana) prišli smo i rekli: „Sjećaš se, nisi nam platio? Onda smo otišli u susret. Sada, denominacija. Hajde da ovo uradimo besplatno?" Bez pitanja - mi smo izdali fakturu, on je platio.

Zašto sam naveo ovaj primjer? O važnosti dobrih odnosa. Da smo se tada podigli i tražili da nam isplatimo ovaj iznos, onda bismo imali rizik da izgubimo dobrog klijenta. I tako smo ostali u kontaktu s njim.

Ko je odgovoran za objašnjenje ovog budžeta:

• Ovo u načinu poslovanja, u redovnom toku rada je angažovan Projekt menadžer- šef zajedničke radne grupe koja, u stvari, realizuje projekat.
• Ako ne uspije, onda se povezuje ugovor menadžer, koji objašnjava brojkama i kaže da je ovo - kršenje ugovora, kršenje sporazuma.
• U najtežim slučajevima povezuje upravitelj objekata koji pokušava objasniti (već, naravno, bez ikakvog krutog okvira) kupcu zašto treba ograničiti svoje želje.

Obično, ako su brojevi napisani vrlo detaljno, onda je ovaj izgled i njegovo objašnjenje dovoljni.

Isporuka radova

Isporuka radova. Ovdje, općenito, uglavnom nema velikih problema, jer Procedura primopredaje radova je vrlo detaljna u našoj relevantan dokumenata.

Ali u ovoj fazi, element neformalnosti ( dobar odnos), naravno takođe olakšava život i nama i kupcu također.

Svrha ove faze je da se postigne isporuka radova u potpunosti u skladu sa pravilima utvrđenim u relevantnim dokumentima, koji su aneks ugovora koji potpisujemo i naručilac i mi. Shodno tome, uvijek se može pokazati da postoje takva pravila.

Odnosi nakon projekta

I konačno, post-projektni odnosi. Ovo je takođe veoma važan deo. Čemu trebamo težiti na kraju projekta? Do zaključenja ugovora o uslugama, naravno. Ali to nije uvijek slučaj. Jer postoji koncept "rezultata", a postoji i koncept "ishoda" - a to su malo različite stvari.

Dat ću vam primjer. Imali smo projekat sa jednom veoma ozbiljnom kompanijom i rezultat na tom projektu je za nas bio sjajan - to je bio jedan od onih retkih slučajeva kada smo u potpunosti ispoštovali i budžet i rok, tačno onako kako smo prvobitno planirali. Ovo je bio rezultat. I rezultat projekta je bio da ugovor o uslugama nije potpisan. Štaviše, kupac je rekao da više nikada neće raditi s nama. Evo rezultata. Drugim riječima, rezultat je briljantan, ali rezultat je vrlo tužan.

Zašto se to dogodilo? Jer nije bilo neformalnih odnosa. Upravo smo tada razvili našu tehnologiju projektne dokumentacije i to je bio klijent na kojem je sva ta tehnologija, u svom punom sjaju, demonstrirana. I kada smo pitali kupca: "Pa, nećete raditi s nama - ali ima li tužbi prema nama?" I kroz zube od ljutnje nam je rečeno: „To je problem, ne možemo ništa da tvrdimo – šta god da kažeš, imaš papir za sve, a mi ne možemo ništa. Nismo zadovoljni sa ovim i nećemo više raditi s vama. Od drugih kompanija se može tražiti da urade nešto dodatno, ali vi to odbijate – evo vam budžeta, evo vam ga kako treba, evo roka. Odmaknite se - i odmah nam pokažite komad papira sa našim potpisom.

Dakle, rezultat je tužan. Ali još jednom naglašavam da je takav rezultat bio rezultat činjenice da nije bilo neformalnih odnosa.

Ovaj članak je zasnovan na izvještaju koji je autor pročitao na konferenciji IE Infostart 2014 29-31. oktobra 2014.

Pozivamo vas na novu konferenciju.

Dobar dan! Danas bih želio da pričam o načinima na koje klijent komunicira sa outsourcing kompanijom, kao i da dobijem komentare od vas o tome kako komunicirate sa svojim klijentima/programerima softvera. Ovaj članak je napisan na osnovu iskustva i uglavnom je namijenjen korisnicima softvera. Cilj je pronaći "uska grla" u odnosu između kupca i kompanije koja nudi usluge razvoja softvera.

Dozvolite mi da se predstavim: ja sam Yury Korkhov i ovaj članak je prvi na mom habreu. Završio Bjeloruski nacionalni tehnički univerzitet (inženjer sigurnosti), Bjeloruski državni univerzitet (investicioni menadžer). Radno iskustvo - više od 6 godina u IT-u na gotovo svim pozicijama: webmaster, layout dizajner, web dizajner, programer, projekt menadžer i honorarni UI developer, šef odjela... Ukupno, za to vrijeme, više od 80 projekata implementirani su: od malih sajtova, igrica za mobilne telefone do velikih internet portala... Glavni profil je upravljanje razvojem projekata iz IT oblasti. Radio je i na strani kupca i na strani developera, kako na ruskom tržištu tako i na stranom.

Pozadina stvaranja posta ili Hvala Wargaming.

Zaobići istoriju nastanka ovog posta ne bi bilo dobro, jer. Čitam habr jako dugo, ali moje ruke nisu stigle da napišem članak, ali ovdje je stvar "prilike" i sada je članak spreman.

Već par mjeseci pauzim od posla, jer sam umoran od outsourcinga, odlučio sam da pronađem smisao života i polako pripremam svoj projekat za lansiranje, a jednog lijepog dana zazvonio je telefon. Wargaming regruter (osnivači "tanchiki" i, po mom mišljenju, jedne od najboljih firmi u Minsku) zvao me je sa ponudom da intervjuišem za radno mjesto Vendor Manager (ovdje treba reći da nisam tražio posao , i, sudeći po njihovom upražnjenom mjestu, nisam im baš pristajao). "To je zanimljivo!" - Razmislio sam i odlučio da završim testni zadatak, pogotovo što mi je bio prilično zanimljiv. Regruter je rekao da imaju sve uslove za ugodan, zdrav (kondicija, osiguranje itd.) i dobro plaćen posao i, ne manje važno, trebalo bi mi oko 3 sata da obavim test zadatak. Sumnjam da bi neko uspeo da uradi ceo test zadatak u navedenom roku, što se mene tiče - ukupno je trebalo oko 6 sati.

Na moju žalost, povratne informacije iz kompanije bile su u telefonskom razgovoru i bile su izražene u suhoparnoj frazi "sve je u redu, svima se dopalo" (ne sjećam se doslovno, ali suština je ovo) i bez ikakvih specifičnosti. Sumnjam da sam uspeo da ukažem na sva glavna „uska grla“; nije dobro gubiti rad, odlučio sam odgovore na testni zadatak (sa manjim izmjenama, radi pogodnosti) objaviti u javnosti i bit ću zahvalan habra publici na dopunama i zdravim komentarima na članak.

Šema interakcije između kupca i programera softvera od prvog sastanka do kraja odnosa.

1. Programer softvera je u mogućnosti da završi projekat.
2. Prije toga nije potpisan ugovor sa programerom softvera i nije bilo projekata.
3. TK je spreman.
4. Uslovi plaćanja su regulisani ugovorom.
5. Koriste se sistemi upravljanja projektima i metodologije razvoja softvera (XP, Scrum, Lean, Kanban, ScrumBut, itd.).
6. Popunjavanje aplikacije sadržajem (po potrebi) vrši klijent.

Aspekti ugovora između dobavljača razvoja softvera i kupca su korisni za dobavljača da ih izbjegava (pojednostavite, potpuno uklonite iz ugovora).

1. Odgovornost za poštivanje rokova leži na programeru, a ako rokovi budu propušteni u posljednjem trenutku (tj. programer nije unaprijed obavijestio da nije imao vremena prije zatvaranja), treba izreći kazne (postoji veliki izbor opcija).
   Razlog: nepoštovanje rokova je jedan od najvećih problema i spominjanje u ugovoru nije baš interesantno, jer. Uglavnom, nepoštovanje rokova leži na strani programera. Ovdje je potrebno uzeti u obzir da je teško precizno izračunati, ali je potrebno unaprijed upozoriti da programer nema vremena da završi razvojnu fazu u određenom roku i to mora biti propisano ugovorom .
2. Garantujemo uslove za otklanjanje "bugova" greškom programera koji nisu otkriveni na vreme. Uobičajeni garantni rok je 3 mjeseca.
   Razlog: često se dešava da neke „bugove“ nisu otklonjene ili su se već pojavile u procesu rada, pa se često pokušava ova stavka ne naznačiti ili skratiti vrijeme garancije. Moje mišljenje je da manje od 3 mjeseca nije dovoljno.
3. Prava na razvijeni softver, module, blokove itd. pripadaju kupcu i ne mogu se koristiti za naknadnu preprodaju.
   Razlog: Za programera je korisno imati prava intelektualnog vlasništva ili biti u mogućnosti da prodaje/koristi razvoj za druge klijente, što zauzvrat može dovesti kupca u neugodnu situaciju na tržištu.
4. Prilikom razvoja novog modula u sistemu koji utiče na rad drugih modula ili čitavog sistema, programer mora osigurati funkcionisanje cijelog sistema.
   Razlog: često razvoj jednog modula može štetiti radu drugog modula ili cjelokupnom sistemu općenito, a dalja poboljšanja mogu pasti na „rame“ (finansijski) klijenta. Programer je dužan uzeti u obzir strukturu cijelog sistema i, u slučaju „bagova“ koje je pronašao klijent, ispraviti ih besplatno.
5. Tehničku dokumentaciju za razvoj treba pripremiti uzimajući u obzir zahtjeve kupca.
   Razlog: za programere je korisno da se u potpunosti vežu za kupca i često se dešava da se dokumentacija ne vodi.
6. U slučaju izrade web stranice, izvođač mora uzeti u obzir SEO optimizaciju stranice i to: opis slika, stranica…
   Razlog: ušteda vremena na „sitnicama“, koje, ovisno o uslovima ugovora, mogu dovesti do finansijskih gubitaka za kupca (programer softvera štedi vrijeme/finansije).
7. Testiranje sistema treba da obezbedi programer sistema.
   Prihvatanje gotovog modula od strane kupca ne bi trebalo da se pretvori u testiranje sistema, tj. programer je dužan da o svom trošku preuzme eliminaciju identifikovanih „bagova“ od strane klijenta. Ovo je neophodno kako bi se osiguralo kvalitetno testiranje proizvoda od strane programera. Dok programer kaže "gotovo" i počne testiranje na strani klijenta, "bugovi" se popravljaju besplatno.
8. Odgovornost za hostovanje projekta na strani kupca preuzima programer. U tom slučaju, kupac je dužan osigurati da su tehnički zahtjevi za lokaciju ispunjeni.
   Razlog: hostovanje projekta na strani kupca ponekad može izazvati određene poteškoće, što može dovesti do "hattinga", pa bi odgovornost za hostovanje i konfigurisanje servera trebala biti na strani programera softvera.
9. Ako je programer softvera primoran da pribjegne pomoći stručnjaka izvan svog tima, dužan je preuzeti sve povezane rizike za curenje, gubitak podataka ili bilo koju drugu štetu koju vanjski zaposlenik može uzrokovati svojim djelovanjem ili nečinjenjem.
   Razlog: dešava se da se programer razboli, odustane itd. jedan od zaposlenih. U tom slučaju kupac mora biti osiguran.
10. Sigurnosne kopije projekta moraju biti dostavljene na strani programera najmanje jednom dnevno. Sve probleme sa gubitkom podataka o projektu treba da preuzme programer.
    Razlog: ovdje trebate navesti ko je odgovoran za sigurnost projekta u slučaju bilo kakvih kvarova.
11. Programer bi trebao polaziti od popularnosti korištenja tehnologija koje koristi pri odabiru.
    Razlog: vezanje za vlastite tehnologije, što će zakomplicirati život ako se korisnik prebaci na drugog programera.

Poznati načini precjenjivanja troškova outsourcinga u odnosu na stvarnost, pretpostavljam da ih ima više.

• Površna procjena troškova razvoja projekta u cjelini, bez podjele na faze, što može dovesti do 2x-3x viška troškova projekta.
• Nedostavljanje izvještaja o obavljenom poslu u roku određenom ugovorom ili nemogućnost kontrole napretka razvoja od strane klijenta
• Pogrešan izbor tehnologije u implementaciji tehničkog dijela može značajno povećati troškove razvoja.
• Nedostatak pravih stručnjaka u razvojnom timu, što povećava vrijeme i troškove razvoja.
• Fiksni trošak za razvoj projekta ili modula i dalje povećanje cijene za svaku sitnicu koju su obje strane drugačije shvatile.
• Određivanje fiksnih troškova razvoja projekta - zbog većeg rizika potrebno je uključiti u cijenu projekta.
• Prilikom izrade dizajna ne koristi se prototipizacija, a razvoj dizajna se vrši na osnovu tekstualnog TOR-a, što u konačnici dovodi do velikog broja poboljšanja/ispravki i, shodno tome, povećanja cijene projekta.
• Dodavanje/kompliciranje funkcionalnosti. Možete olakšati - otežati.
• “Lepa” tamo gde nisu potrebni (možete reći za admin. deo sajta, ako možete da koristite css okvire za brzu prilagodbu administratorskih delova - oni počinju da se razvijaju od nule).

Obrazac odnosa „kupac – dobavljač razvoja softvera“, koji je, po mom mišljenju, najbliži praktičnoj upotrebi.

Mnoge outsourcing kompanije ne žele da obezbede pristup svojim sistemima za upravljanje projektima bez davanja detaljnih informacija, ja lično smatram da pristup treba da bude omogućen na zahtev kupca. Klijent je odgovoran za implementaciju projekta i važno je vidjeti napredak razvoja u realnom vremenu!
Također, smatram da je razvoj softvera uzimajući u obzir kalkulaciju ukupne cijene projekta gubljenje novca i živaca, takav razvoj obično dovodi do konfliktnih situacija.

1. Plaćanje rada na osnovu satnice za rad zaposlenih ili prosječne cijene rada stručnjaka cijelog razvojnog tima. Evaluacija faza razvoja je neophodna. Zašto mislim da je ovaj oblik cijene optimalan:
   • Ne zahtijeva vrlo skrupulozan pristup u evaluaciji projekta, što je gotovo nemoguće učiniti 100% tačnim. Ako je procjena napravljena pogrešno i programer softvera to počne shvaćati, onda se funkcionalnost „povređuje“ gdje god je to moguće, što će u konačnici utjecati na upotrebljivost.
   • Poboljšava međusobno razumijevanje između programera softvera i klijenta, kao glavni zadatak se svodi na princip – „uradi to efikasno i brzo“, a ne „ulagati u skučen budžet i kako će to dobro funkcionirati“.
   • Klijent, na osnovu dnevnih izveštaja o utrošenim satima, može da vidi koliko vremena zaposleni provode na različitim blokovima tokom razvoja, što daje razumevanje brzine i kvaliteta rada zaposlenih programera softvera.
   • Interakcija između kupca i voditelja projekta se odvija što direktnije, tj. kada koristite skype, telefone itd.
2. Samo 2-nedeljni izveštaji i planovi se moraju slati poštom (radi kontrole).
3. Klijent daje prototip aplikacije ili ga razvija tim za razvoj softvera, ako je potrebno:
   • Pojednostavljuje razumijevanje glavne funkcionalnosti projekta.
   • Povećava ukupnu brzinu razvoja projekta.
   • Jasni zahtjevi za funkcionalnost i kupca i programera.
   • Jasno razumevanje kuda će se projekat kretati.
4. Sistem upravljanja projektom za praćenje napretka projekta i mogućnost praćenja procesa, razvojnog vremena utrošenog na svaki zadatak posebno. Nažalost, programeri rijetko daju pristup.
5. Poželjno je da cijeli projekat radi jedan tim, tj. ne bi trebalo biti da jednu fazu radi jedna kompanija, drugu drugu, i tako dalje.
6. Kontrolne tačke („pokreni“) svake 2 sedmice su optimalno vrijeme za kontrolu projekta.
7. U razvoju se prednost daje poznatim okvirima, takođe radi lakšeg prilagođavanja u slučaju bilo kakve situacije kada je potrebno preneti projekat na druge programere.
8. Testiranje kvaliteta na strani programera je direktna odgovornost. Prilikom prenosa projekta ili nekog njegovog dijela na klijenta, sve se mora detaljno provjeriti.
9. Podržavanje različitih pretraživača je direktan zadatak programera

Zaključak: glavna stvar je pridržavati se partnerskih / obostrano korisnih i povjerljivih odnosa s razumijevanjem da su programeri isti ljudi i kompliciranje njihovog života komplicira život sebi! Svako treba da bude odgovoran za svoj deo posla, klijent treba da bude odgovoran za davanje jasne tehničke specifikacije i brzo odgovaranje na pitanja koja se pojavljuju, ne zaboravljajući da plati rad, a programer - za kvalitet, tajming, brzinu. Ideal, naravno, nije postignut, ali smo na dobrom putu.

sviđa mi se

U različitim izvorima literature o prodaji možete pronaći različit broj faza prodaje. Svaki autor ih razmatra sa svoje tačke gledišta.

Predlažem da razmotrimo ključne faze u radu sa Klijentom>:

Faza 1 "Uspostavljanje kontakta" ili "Uspostavljanje kontakta"

Svaka prodaja počinje od ove faze.

Svrha ove faze: pridobiti klijenta i zainteresovati ga za dalji kontakt.

Prilikom uspostavljanja kontakta sa Klijentom važno je pozdraviti ga i predstaviti se.

"Dobar dan. Zovem se Mihail, direktor sam kompanije "Windows Plus".

Prije nego započnete razgovor o potrebama Klijenta, preporučljivo je razgovarati s njim na neku apstraktnu temu (tehnika “Small Talk”), ili ponuditi čaj, kafu, možete napraviti kompliment ili koristiti niz drugih tehnika. u fazi uspostavljanja kontakta.

„Šta znate o našoj kompaniji? Zašto odabrati nas? Šta planirate kupiti?

Važno je da menadžer svojim neverbalnim ponašanjem pokaže interesovanje za kontakt sa Klijentom, želju da mu pomogne, dobru volju. Neverbalno ponašanje uključuje otvorene geste, držanje, osmeh, naginjanje tela prema Klijentu, otvoren pogled.

Da li je kontakt sa Klijentom uspostavljen ili ne, moguće je utvrditi ponašanjem Klijenta. Ako pozitivno reaguje na riječi menadžera, osjeća se opušteno, sam postavlja pitanja, možemo pretpostaviti da je kontakt uspostavljen. Ukoliko Klijent ne održava kontakt očima sa menadžerom, napet je, ne odgovara na pitanja ili nerado odgovara, onda ima smisla posvetiti više vremena fazi uspostavljanja kontakta.

Faza 2 "Identifikacija potreba"

Svrha ove faze: utvrditi potrebe Klijenta.

Što menadžer preciznije odredi potrebe Klijenta, to će efikasnije napraviti prezentaciju robe i usluga, što će naknadno dovesti do posla.

Kada identifikuje potrebe, važno je da menadžer bude u stanju da postavlja pitanja i sasluša klijenta.

Prilikom interakcije sa Klijentom važno je da on više priča, a ne menadžer; za to se menadžeru preporučuje da postavi više otvorena pitanja.

Koji prozor planirate da kupite? Gdje ćete promijeniti prozor? Kakva je klima u stanu zimi i ljeti? Ko još živi u stanu? Po kom osnovu birate prozor?

Zatvorena pitanja menadžer omogućava da specificira potrebe Klijenta.

„Da li često provetrite prostoriju? Imate li životinje? Da li vam odgovara da naš mjerač dođe sutra u 9 ujutro?”

Alternativna pitanja ponuditi klijentu izbor opcija.

„Da li vam odgovara da merač dođe ujutro ili popodne? Planiramo li instalirati nove prozore ove ili sljedeće sedmice?”

Tokom cijelog sastanka sa Klijentom, korisno ga je pažljivo saslušati, jer Klijenti često i sami otvoreno govore o svojim potrebama. Ukoliko menadžeru neke riječi Klijenta nisu jasne ili ih je poslušao, savjetuje se da klijentu postavi pojašnjavajuća pitanja:

“Jesam li dobro shvatio da vam je potreban prozor sa povećanom zvučnom izolacijom? Koliko sam shvatio, želite da se jedno krilo prozora okreće, a drugo da se naginje i okreće?”

Poželjno je sumirati međurezultat nakon svakog razmatranog pitanja. Pogotovo ako menadžer razgovara o nekoliko proizvoda ili usluga sa Klijentom.

“Tako smo se dogovorili da ćemo sutra mjeriti, a prozore ćemo postaviti sljedeće sedmice u petak. Dakle, planirate da ugradite dva nova prozora: u kuhinji dvokrilni prozor sa zaokretnim krilima i u prostoriji trokrilni prozor, u kojem su dva krila nagibno-okretna i jedan je "gluv".

Važno je precizno identifikovati potrebe klijenta i tek onda izvršiti prezentaciju robe i usluga.

Faza 3 "Prezentacija"

Cilj: ponuditi proizvod ili uslugu koja najbolje odgovara potrebama Klijenta.

Prezentacija proizvoda i usluga sadrži opis karakteristika robe i usluga, koristi od njihovog korišćenja od strane klijenta i koristi koje potrošač dobija.

Korisno je započeti prezentaciju ključnim pogodnostima Klijenta, koje proizilaze iz potreba kupca, koje je menadžer identifikovao u prethodnoj fazi.

Važno je razlikovati po čemu se korist proizvoda ili usluge razlikuje od koristi.

Prednost je pogodnost koju svaki Kupac dobiva korištenjem ovog proizvoda ili usluge.

"Sa ovom uslugom možete uštedjeti vrijeme i smanjiti troškove za 10%." "Ovo postavljanje vam omogućava da smanjite broj podešavanja."

Benefit je karakteristika ili prednost koja vam omogućava da zadovoljite specifične potrebe Klijenta.

Dakle, svaka karakteristika ili prednost može postati korist, pod uslovom da Klijent ima potrebu za tim.

"Želeli ste da se prozor lako otvara i zatvara, okovi evropskog kvaliteta to mogu da obezbede." “Rekli ste da se stan nalazi na prvom spratu i bojite se za sigurnost stana, predlažem vam da ugradite protivprovalnu opremu na nove prozore.”

Tokom prezentacije, menadžer treba da uključi klijenta u aktivan dijalog pomoću pitanja.

“Šta mislite o mom prijedlogu?”, “Šta mislite o ovome?”, “Kako vam se sviđa moj prijedlog?”

Faza 4 "Rad sa prigovorima"

Cilj: otkloniti sumnje Kupca u vezi sa kupovinom i otkloniti negativnost u vezi sa proizvodom ili uslugom.

Kako bi se smanjio broj prigovora Klijenta, korisno je da menadžer posveti više vremena prethodnim fazama. Često se zamjerke Klijenta odnose na činjenicu da kontakt sa njim nije dobro uspostavljen, da su njegove potrebe djelimično identifikovane, ili da predstavljanje roba i usluga nije bilo interesantno Klijentu, predugo i nije zadovoljavalo njegove potrebe.

Prigovore Klijenta važno je shvatiti kao signal da menadžer treba da ispravi svoje ponašanje (naročito ako ima mnogo prigovora).

Prigovori Klijenta mogu se pojaviti iu prethodnim fazama prodaje. Kako se nositi s prigovorima koji se pojavljuju?

Učinkovito se pridržavajte sheme rješavanja prigovora:

1. saslušati Klijenta;

2. neutralizirati svoje emocije koristeći fraze razumijevanja;

„Razumem te“, „Da, slažem se da je neprijatno...“

3. razjasniti, ako je potrebno, informacije pomoću pitanja;

4. ponuditi konstruktivna rješenja ili dati alternativni prijedlog.

Postoje 4 vrste prigovora kupaca:

1. primjedbe na promjene.

„Zašto mi ovo treba“, „Ne vidim smisao u tome“

U rješavanju takvog prigovora, menadžer mora objasniti Klijentu da su rizici isključeni, pokazati posljedice ako se situacija nastavi, navesti primjere pozitivnog iskustva u korištenju nečega po prvi put.

„Kupovinom prozora sa evropskim okovom garantovano ćete biti zaštićeni od propuha, dodatnih podešavanja pritiska krila, zaglavljivanja mehanizma za zatvaranje.”

2. prigovori vezani za cijenu.

"Preskupo je za mene".

U argumentaciji, menadžer treba da obrati pažnju na dodatnu korist koju klijent dobija, možete uporediti cenu robe sa cenom bilo koje druge stvari koja nije posebno potrebna ili podeliti trošak sa određenim vremenskim periodom.

“Kada kupite prozor od naše kompanije, na poklon dobijate komplet za njegu prozora, kao i mogućnost korištenja besplatnog podešavanja okova”, “Prekrasan novi prozor u kuhinji koštat će vas samo 300 rubalja. za jedan dan“.

3. zamjerke vezane za negativna iskustva.

"Čuo sam da imaš loš profil."

Korisno je da menadžer pojasni informacije postavljajući pitanja Klijentu, da pokaže Klijentu da ga razumete i da uvažava činjenice o nemilim događajima (u slučaju da su bili u stvarnosti) i zatim ponudi alternativno rešenje.

“Da, zaista, imali smo seriju neispravnog profila, koje smo vratili dobavljaču. Trenutno smo dobili novu seriju, već smo proizveli i montirali više od 30 prozora, svi klijenti su zadovoljni.”

4. prigovori na odluku.

„Moram da razmislim”, „Moram da se konsultujem sa svojom ženom.”

U rješavanju ovakvih prigovora, menadžer može još jednom razjasniti s čime je takva odluka povezana, uvjeriti se da je klijent prihvatio i razumio sve informacije, te koristiti metode za završetak transakcije.

“Ako sada sa vama potpišemo ugovor, onda ćete krajem sedmice moći da se divite novom prozoru u kuhinji.” "Samo do kraja mjeseca imamo popust na ovaj proizvod."

Faza 5 "Završetak transakcije"

Cilj: gurnuti Klijenta na transakciju i potvrditi ispravnost odluke koju je on donio.

Prije sklapanja posla (potpisa ugovora), menadžer se mora uvjeriti da je Klijent spreman za sklapanje posla.

To se može vidjeti iz signala koje pokazuje:

• pozitivne povratne informacije o proizvodu ili usluzi;
• Klijent izražava odobravanje na riječi menadžera (pristaje, klima glavom, itd.);
• direktno kaže da se slaže;
• postavlja pojašnjavajuća pitanja.

Načini zaključivanja posla:

1. način ograničavanja uslova i vremena.

"Ako danas potpišete ugovor, dajemo vam 20% popusta na prozor."

2. metoda komplimenta.

"Zaista si napravio pravi izbor."

3. win-win alternativa.

„Hoćete li biti zakazani za merenje u utorak ili sredu?“

U zaključku želim da kažem da efikasnost prodaje zavisi od veštine menadžera. Što više metoda i tehnika prodaje menadžer ima, to je fleksibilniji i uspješniji u interakciji s klijentom. Profesija menadžera prodaje zahtijeva stalan razvoj i samousavršavanje vještina. Želimo Vam uspjeh na putu profesionalnog rasta i povećanja prodaje.