Technologie interakce s interním zákazníkem. Projektový management. Informování zákazníka o technologii projektového řízení

Chci se zaměřit na vytváření pozitivního obrazu. Na základě nashromážděných prvotních informací rozhodneme, kterému z našich zaměstnanců lze důvěřovat, že zastoupí naši firmu na prvním setkání s klientem. To je velmi důležitý bod. Pokud například na první kontakt vyšleme vynikajícího specialistu, který má v uchu náušnici, „kuchaře“ nasáklého tukem atd., pak se klient může podívat a říct: „Ale no tak!“ Stalo se to. Nebo třeba úhledný, upravený, v obleku a kravatě, ale vešel kluk asi 20. A klient se podívá a říká: „To je kluk, o čem si s ním mám povídat? Jak s nimi pracovat - vůbec mě nerespektují, poslali mi kluka! Proto je sběr těchto informací nezbytný mimo jiné proto, abychom pochopili, komu svěřit první kontakt a jak se ke kontaktovanému chovat, jak budovat legendu, jak se prezentovat.

Identifikace osob s rozhodovací pravomocí

Další velmi důležitou otázkou je identifikaci osob, které skutečně rozhodují(tzv. LPR). Tato fáze se skládá ze dvou položek:

• Ukazuje se, kdo rozhoduje podle našeho projektu.
• A druhý bod - jsou identifikovány osoby ovlivňující osoby s rozhodovací pravomocí.
  Co to znamená? Je například známo, že ve firmě rozhoduje generální ředitel, má také finančního ředitele a účetní. Může to být účetní, který dělá vše, co ředitel řekne, a sedí tiše v koutě, nebo třeba naopak účetní, který takhle řekne řediteli, co má dělat, a ředitel ho poslechne. A pokud jsme zpočátku odhalili, že tato osoba má vliv na svého ředitele, pak je to náš trumf, proto se musíme pokusit navázat vztahy s tímto účetním. Podmíněně jsem řekl, že se jedná o účetní - může to být kdokoli (například vedoucí obchodního oddělení nebo nějaký zástupce, kterému generální ředitel nebo majitel firmy zcela důvěřuje). Je nutné navázat vztahy s osobou ovlivňující rozhodovatele.

Cílem, jak vidíte, je identifikovat osoby s rozhodovací pravomocí. A výsledkem je seznam osob s rozhodovací pravomocí a osob, které rozhodovací pravomoci ovlivňují.

Naše zkušenost to ukazuje pokuste se co nejdříve setkat s těmi, kdo rozhodují- většinou jsou to buď top management nebo majitel firmy. Nemusí k tomu dojít při prvním kontaktu, ale pokud k takovému setkání v předběžné fázi nedojde, pak z našeho projektu zpravidla nic dobrého nevzejde.

Navazování partnerských vztahů

Další fáze - navazování partnerství.

• My zpočátku ano důraz na bilaterální odpovědnost: i ve smlouvě, je-li to možné, předepisujeme nikoli Zákazník-zhotovitel, ale „ První strana" (toto je zákazník) a " Druhá strana“ (toto je účinkující). Pravda, občas některé velké státní struktury říkají, že jim to právní oddělení neumožňuje, protože doklady kontroluje státní pokladna, ministerstvo financí a další. V tomto případě předepisujeme standardní znění – „Objednatel a zhotovitel“. Ale pokud je to možné, pak - "První" a "Druhá strana".
• Všemi prostředky se snažíme naznačit, že jde o společné dílo. Lídři na obou stranách jednat jako vysoké smluvní strany – právě oni se rozhodli tento projekt automatizace uskutečnit. Pro tento projekt, oni najmout tým jak ze štábu prvního strany zaměstnanců druhá strana je tzv Společná pracovní skupina“, která tvoří projekt. Každá strana samozřejmě investuje do projektu své zdroje: materiální, technologické, metodické, finanční – protože obecně se bavíme o poměrně velkých projektech.
• Na práci společné pracovní skupiny dohlíží« Společná dozorčí komise" je nejvyšším kontrolním orgánem, obvykle tvořeným vrcholovým managementem obou stran.
• A podepsat odpovědnost každé strany aby zaměstnanci zákazníka pochopili, že za projekt neseme odpovědnost nejen my, ale i oni. Vynakládáme mnoho času a úsilí na to, abychom klientovi sdělili, že tento projekt děláme společně s jeho zaměstnanci, a že na jejich práci přímo závisí a v jaké kvalitě a zejména v jakém čase bude projekt dokončen.

Studna výsledek tuto fázi je fixace(formální nebo neformální) vztahy rovnocenní partneři:

• Formální fixace je smlouva.
• A neformální – mohou to být nějaké oficiální dokumenty, ve kterých se vždy snažíme předepsat „První a Druhou stranu“ a jejich vztah.

Informování zákazníka o technologii projektového řízení

Další fází je informování zákazníka o technologii.

• Na velkých projektech máme bezesporu „ Kurz přednášek a seminářů o úvodu do konstrukční technologie". V tomto kurzu přednášek přinášíme zaměstnancům zákazníka, jak bude celý proces projektu probíhat:
  • Jak vzniká projekt pomocí naší technologie?
  • Kdo je za co zodpovědný?
  • kdo co dělá?
  • Proč se provádějí určitá opatření?
  • Proč je tento dokument potřebný? Co dává oběma stranám? (aby bylo zaměstnancům jasné, že partnerství přináší výhody nejen nám, ale i zákazníkovi).
  • Při každé příležitosti, my O všech problémech, které se vyskytnou v průběhu práce, informujeme rozhodovatele. K tomu máme řadu speciálních denních dokumentů – například „Deník kontaktů“ nebo „Výpis odchylek“. A když ne denně, ale každých pár dní, mělo by se s nimi vedení zákazníka seznámit. A protože se zpravidla okamžitě najdou výmluvy: byl jsem zaneprázdněn, nečetl jsem atd., pak to musíme neustále připomínat, možná dokonce simulovat některé situace, které nutí vedení číst tyto dokumenty.

Výsledkem této fáze je, že všechny odpovědné osoby zákazníka absolvovaly kurz přednášek a hlavně, že vedení má jasnou představu o tom, jak se práce provádí (samozřejmě, pokud dostatečně přísně kontroluje projekt).

Organizace vztahů se zákazníkem

Další fází je organizace vztahů se zákazníkem. Zde vám chci říci o jednom zajímavém „triku“: na projektu máme takové role (nejsou to pozice, ale role) jako „Manažer kontraktu“ a „Objektový manažer“ (nejčastěji je lze také kombinovat a s některými jiná odpovědnost). Jak je uvedeno na tomto snímku, tyto role odpovídají definicím „špatných“ a „dobrých“.

• Manažer smlouvy je špatný". Může to být jednotlivec nebo jeden z vrcholových manažerů. Nejčastěji funkci manažera zakázky vykonává projektový manažer (pokud je toho samozřejmě schopen). Tato osoba je „Ne“ – může přijít za osobou s rozhodovací pravomocí a říct: „V naší smlouvě je to napsáno takto, ale teď to děláte jinak a kvůli tomu dochází k odchylce. Pojďme na to." Vždy upozorní na nedostatky, nedodržení technologie, vyzývá k dodržování dokumentace Proto je vždycky špatný.
• ALE správce objektů- tohle je dobré." Jedná se o osobu, která si z různých důvodů od zákazníka vytvořila dobrý vztah s rozhodovatelem. Možná se mu náhodou zalíbil. Nebo například mají nějaké vazby (příbuzenské, klanové, přátelské - jakékoli). Hlavní věc je, že se klient nachází u něj.
  Objekt manager ve skutečnosti udržuje tento objekt. Upozorňujeme, že toto není projektový manažer, je to zvláštní osoba, která dělá co udržuje dobré vztahy s vedením klienta, a když se vyskytnou nějaké akutní problémy, tak je vyhladí.
  Například poté, co manažer smlouvy s klientem promluví o nedodržování některých podmínek našich dohod (může to pro nás obecně skončit nějakým nepříjemným rozhovorem), přijde objektový manažer a začne klienta uklidňovat. .
  Ne nadarmo jsem řekl, že objekt manažera se nazývá „dobrý“. Běžně se říká, že být „hezkým chlapem“ není povolání. Ale to je naše profese. Správce objektů je ten „milý chlap“. Sice není na nic profesionální specialista, ale klient se s ním cítí dobře - přišel, mluvil s ním (třeba o politice, fotbale atd.) a klient se cítil dobře, změnil se jeho přístup. Klient nám před tím chtěl něco vytknout, za něco potrestat, ale teď už všemu rozumí, celkově je mu nepříjemné s námi mluvit špatně.
  Toto je funkce správce objektů. Přiděluje se každému poměrně vážnému klientovi.

Vše, o čem mluvím, samozřejmě vyžaduje určité zdroje a náklady. A samozřejmě nedává smysl vytvářet celou tuto strukturu kvůli malému obchodu - to vše se děje pouze kvůli dostatečně velkým objektům.

Výsledkem této fáze je jmenování příslušného správce smlouvy a objektu pro tohoto klienta, protože je velmi důležité tyto lidi správně vybrat.

Organizace projektových procesů

Další fází je organizace projektových procesů. Podle mého názoru jsou pouze dva:

• Monitorování průběhu projektu;
• A dělat manažerská rozhodnutí na základě výsledků monitorování.

Nejdůležitější je přesvědčit zákazníka, aby pracoval podle naší technologie. Tento pracovní řád je zákazníkovi vysvětlen jak při osobních rozhovorech s osobami s rozhodovací pravomocí, tak při účasti odpovědných pracovníků na průběhu přednášek (vysvětluje, jak a co se na projektu bude dít - zaměstnanci zákazníka se tohoto kurzu musí bezpodmínečně zúčastnit, pod podpisem ).

Někdy může být velmi obtížné přesvědčit zákazníka, aby pracoval s naší technologií. Měli jsme například jednoho klienta – velmi velkou IT společnost. Navíc se sama zabývala automatizací na MS Navision, ale z určitých důvodů se rozhodla zavolat nám, abychom je mohli automatizovat na 1C. Takže práce s nimi byla skutečná noční můra - všichni plakali, jak manažeři, tak programátoři. Protože to byla hodně velká firma (jsme oproti nim malí) a oni si mysleli, že všechno vědí a snažili se nás to naučit. Neustále říkali: "Kluci, neděláte všechno takhle, existuje taková a taková technologie, měli byste to dělat takto." Přirozeně se tak stalo až na střední úrovni, šéf (který byl hlavním majitelem a generálním ředitelem firmy) samozřejmě všemu perfektně rozuměl a po jeho zásahu bylo o všem rozhodnuto, ale získat ho bylo velmi obtížné. A na střední úrovni byly neustálé problémy, neustálé pokusy učit.

Jsme na každém projektu, bez selhání, Snažíme se klientovi předat myšlenku, že ve svém podnikání je profesionál (a my tam samozřejmě nechodíme) a v otázkách automatizace jsme profesionálové, takže musíme věřit a ne se snažit nám říkat, co a jak máme dělat. Zvlášť, když nám to jen neříkají, ale snaží se nám vnutit: "udělejme to jinak, protože já chci." To jsou věci, které se právě teď snažíme zastavit. Samozřejmě „stop“ je silné slovo, v každém případě se ho snažte vysvětlit dostatečně mírně. Pokud jsme s tímto projektem souhlasili, rozhodli jsme se, že nám vyhovuje, zapojili se do této „bitvy“, nyní s tím samozřejmě musíme pracovat.

Omezení přání klienta

Další fází je omezení přání klienta. S tím se asi setkal každý (když začíná tzv. "Wishlist" - další, další a další). Tady to uděláme úplně jednoduše:

• Když například klient řekne, že v rámci přiděleného rozpočtu a termínů se musí udělat i toto a toto, tak to začíná poměrně často, obtížný vysvětlení, jak to všechno funguje. Připomínáme klientovi, že s ním máme rozpočet, jsou alokováni lidé (společná pracovní skupina), každá strana projektu investuje své prostředky. Pokud tedy vznikne další práce, pak jsou zapotřebí další hodiny, další lidé. Odkud je vzít?
  Nebo pokud klient projekt zdržuje, pak jsou naši i jeho lidé nečinní a jsou jim vyplaceny peníze. Kde tyto zdroje získat? Nemluvím o tom, že tito lidé pobírají nejen mzdu, ale přinášejí firmě i nějaký zisk. Společnost samozřejmě nechce o tento zisk přijít. Klientovi je dostatečně podrobně vysvětlena a klient většinou velmi dobře reaguje.
• Vysvětlujeme poskytujeme podrobné digitální uspořádání- kam, co, do groše. A my to říkáme pokud chcete, abychom to udělali také pak prosím bude to trvat tolik hodin a musí se platit. Nakonec s námi klient souhlasí a svůj „Wishlist“ buď odmítne, nebo si hodiny navíc zaplatí. Samozřejmě se to děje různými způsoby - obrázek si teď trochu idealizuji.

Zde chci uvést další příklad vztahů. Spolupracovali jsme s jednou velmi velkou společností (ta už byla ve fázi údržby) a pravidelně tam vyvstávaly úkoly na vylepšení: například vytvořit nějakou záludnou zprávu nebo něco jiného. A tak nás hlavní účetní společnosti pověřil určitou prací a my jsme to udělali. A když přišel čas zaplatit, řekl: "Obecně jsem se mýlil, tohle všechno vůbec nepotřebujeme." Ale práce byla hotová, proto bylo nutné zaplatit. A on říká: "Ne, za tohle nezaplatím, ale nemůžu jít za prezidentem společnosti a říct mu, že jsem blázen a objednal jsem si špatnou věc." Navíc to byla společnost velmi velká, ropná společnost, vztahy byly dobré jak s ní, tak s touto osobou. A netrvali jsme na tom – neplatí, neplatí. I když kvůli tomu jsme pro nás v té době (psal se rok 2004) přišli o poměrně velké peníze. Na konci roku došlo k označení (Ázerbájdžánský manat vyřadil nuly). A pro všechny klienty, kteří byli v našich službách, jsme tento přepočet provedli v provozním stavu - žádné další peníze. Ale k tomuto účetnímu (v té době od toho incidentu neuplynul doslova ani rok) jsme přišli a řekli jsme: „Pamatuješ, nezaplatil jsi nám? Pak jsme se s vámi šli setkat. Nyní denominace. Uděláme to zadarmo?" Žádné otázky - my jsme vystavili fakturu, on zaplatil.

Proč jsem uvedl tento příklad? O důležitosti dobrých vztahů. Pokud bychom se pak vzchopili a požadovali, abychom nám tuto částku zaplatili, riskovali bychom, že ztratíme dobrého klienta. A tak jsme s ním zůstali v kontaktu.

Kdo je odpovědný za vysvětlení tohoto rozpočtu:

• Tento ve způsobu podnikání, v běžném pracovním procesu je zasnoubený Projektový manažer- vedoucí společné pracovní skupiny, která projekt fakticky realizuje.
• Pokud selže, připojí se manažer smlouvy, který vysvětluje čísly a říká, že toto je - porušení smlouvy, porušení dohody.
• V nejtěžších případech spojuje správce objektů který se snaží zákazníkovi vysvětlit (již samozřejmě bez jakéhokoli rigidního rámce), proč potřebuje omezit svá přání.

Obvykle, pokud jsou čísla napsána velmi podrobně, pak stačí toto rozložení a jeho vysvětlení.

Dodávka prací

Dodávka prací. Zde obecně nebývají velké problémy, protože Postup při předávání prací je v našem velmi podrobný relevantní dokumenty.

Ale v této fázi je prvek neformálnosti ( dobrý vztah), samozřejmě také usnadňuje život nám i zákazníkovi také.

Účelem této etapy je dosáhnout dodání díla plně v souladu s pravidly stanovenými v příslušných dokumentech, které jsou přílohou smlouvy podepsané klientem i námi. V souladu s tím lze vždy ukázat, že taková pravidla existují.

Postprojektové vztahy

A nakonec vztahy po projektu. To je také velmi důležitá část. Na co bychom se měli zaměřit na konci projektu? K uzavření servisní smlouvy, samozřejmě. Ale není tomu tak vždy. Protože existuje pojem „výsledek“ a existuje pojem „výsledek“ – a to jsou trochu odlišné věci.

Dám vám příklad. Měli jsme projekt s jednou velmi seriózní firmou a výsledek toho projektu byl pro nás skvělý - byl to jeden z těch vzácných případů, kdy jsme úplně dodrželi rozpočet i termín, přesně tak, jak bylo původně plánováno. Toto byl výsledek. A výsledkem projektu bylo, že smlouva o poskytování služeb nebyla podepsána. Navíc zákazník řekl, že už s námi nikdy nebude spolupracovat. Zde je výsledek. Jinými slovy, výsledek je skvělý, ale výsledek je velmi smutný.

Proč se to stalo? Protože tam nebyly žádné neformální vztahy. Právě jsme v té době vyvinuli naši technologii projektové dokumentace a to byl klient, na kterém byla všechna tato technologie ve své plné kráse předvedena. A když jsme se zeptali zákazníka: "No, nebudete s námi spolupracovat - ale jsou proti nám nějaké nároky?" A se zaťatými zuby hněvem nám bylo řečeno: „To je ten problém, že si nemůžeme dělat žádné nároky – ať řeknete cokoli, na všechno máte papír a my nemůžeme nic dělat. Nejsme s tím spokojeni a již s vámi nebudeme spolupracovat. Jiné firmy mohou být požádány, aby něco udělaly dodatečně, ale vy to odmítáte – tady je váš rozpočet, tady to máte jak má být, tady je termín. Ustupte - a hned nám ukážete papír s naším podpisem.

Takže výsledek je tristní. Ale ještě jednou zdůrazňuji, že takový výsledek byl způsoben tím, že neexistovaly žádné neformální vztahy.

Tento článek je založen na zprávě přečtené autorem na konferenci IE Infostart 2014 29.–31. října 2014.

Zveme vás na novou konferenci.

Dobrý den! Dnes bych rád pohovořil o způsobech, jakými klient komunikuje s outsourcingovou společností, a také od vás dostávat komentáře o tom, jak komunikujete se svými klienty/vývojáři softwaru. Tento článek je napsán na základě zkušeností a z velké části je určen pro zákazníky softwaru. Cílem je najít „úzká místa“ ve vztahu mezi zákazníkem a společností, která nabízí služby vývoje softwaru.

Dovolte mi, abych se představil: Jsem Yury Korkhov a tento článek je první v mém Habré. Absolvent Běloruské národní technické univerzity (bezpečnostní inženýr) a Běloruské státní univerzity (investiční manažer). Pracovní zkušenosti - více než 6 let v IT na téměř všech pozicích: webmaster, layout designer, webdesigner, programátor, projektový manažer a částečný úvazek UI vývojář, vedoucí oddělení... Celkem za tuto dobu více než 80 projektů byly realizovány: od malých stránek, her pro mobilní telefony až po velké internetové portály... Hlavním profilem je řízení vývoje projektů v oblasti IT. Působil jak na straně zákazníka, tak na straně developera, a to jak na ruském trhu, tak na zahraničním.

Pozadí k vytvoření příspěvku nebo Děkuji Wargaming.

Obcházet historii vzniku tohoto příspěvku by nebylo dobré, protože. Habr čtu už hodně dlouho, ale ruce se mi nedostaly k napsání článku, ale tady je to otázka „náhody“ a teď je článek hotový.

Už pár měsíců si dávám pauzu v práci, protože mě outsourcing nebaví, rozhodl jsem se najít smysl života a pomalu připravovat svůj projekt ke spuštění a jednoho krásného dne zazvonil telefon. Zavolal mi recruiter Wargaming (zakladatelé „tanchiki“ a podle mého názoru jedna z nejlepších firem v Minsku) s nabídkou na pohovor na volné místo Vendor Manager (zde je třeba říci, že jsem nehledal zaměstnání, a soudě podle jejich volného místa jsem jim nevyhovoval). "To je zajímavé!" - Pomyslel jsem si a rozhodl se dokončit testovací úkol, zejména proto, že pro mě byl docela zajímavý. Náborář řekl, že mají všechny podmínky pro příjemnou, zdravou (fitness, pojištění atd.) a dobře placenou práci a v neposlední řadě mi splnění testovacího úkolu zabere asi 3 hodiny. Pochybuji, že by někdo dokázal celý testovací úkol dokončit ve stanoveném čase, jako mně - celkem to trvalo asi 6 hodin.

K mé lítosti byla zpětná vazba od společnosti v telefonickém rozhovoru a byla vyjádřena suchou frází „všechno je v pořádku, všem se to líbilo“ (nepamatuji si doslovně, ale podstata je tato) a bez jakýchkoliv specifik. Pochybuji, že jsem dokázal poukázat na všechna hlavní „úzká místa“; není dobré plýtvat prací, rozhodl jsem se odpovědi na testovací úlohu (s drobnými změnami, pro pohodlí) zveřejnit a budu vděčný publiku habra za doplnění a zdravé komentáře k článku.

Schéma interakce mezi zákazníkem a vývojářem softwaru od prvního setkání do konce vztahu.

1. Vývojář softwaru je schopen dokončit projekt.
2. Předtím nebyla podepsána smlouva s vývojářem softwaru a neexistovaly žádné projekty.
3. TK je připraven.
4. Platební podmínky upravuje smlouva.
5. Používají se systémy projektového řízení a metodiky vývoje softwaru (XP, Scrum, Lean, Kanban, ScrumBut atd.).
6. Vyplnění žádosti obsahem (v případě potřeby) provádí klient.

Aspektům smlouvy mezi dodavatelem vývoje softwaru a zákazníkem je pro dodavatele výhodné se vyhnout (zjednodušit, úplně odstranit ze smlouvy).

1. Odpovědnost za dodržení termínů je na developerovi a pokud termíny na poslední chvíli zmeškáte (tj. developer předem neoznámil, že nestihl před uzávěrkou), měly by být uvaleny sankce (je velký výběr možností).
   Důvod: nedodržování termínů je jeden z největších problémů a zmiňovat to ve smlouvě není moc zajímavé, protože. Nedodržení termínů je z velké části na straně developera. Zde je potřeba počítat s tím, že je to těžké přesně spočítat, ale je potřeba předem upozornit, že developer nestihne dokončit vývojovou etapu do určitého termínu a musí to být předepsáno ve smlouvě.
2. Záruční podmínky pro opravu „chyb“ vinou vývojáře, které nebyly včas odhaleny. Obvyklá záruční doba je 3 měsíce.
   Důvod: Často se stává, že některé „chyby“ nebyly opraveny nebo se již objevily v procesu práce, takže se tato položka často snaží neuvádět nebo zkracovat záruční dobu. Můj názor je, že méně než 3 měsíce je málo.
3. Práva na vyvinutý software, moduly, bloky atd. patří zákazníkovi a nelze je použít pro následný další prodej.
   Důvod: Pro developera je výhodné mít práva duševního vlastnictví nebo mít možnost prodávat/používat vývoj pro jiné klienty, což může zákazníka dostat do nepříjemné situace na trhu.
4. Při vývoji nového modulu v systému, který ovlivňuje chod ostatních modulů nebo celého systému, musí vývojář zajistit fungování celého systému.
   Důvod: často může vývoj jednoho modulu poškodit provoz jiného modulu nebo celého systému obecně a další vylepšení mohou padat na „ramena“ (finančně) klienta. Vývojář je povinen zohlednit strukturu celého systému a v případě „chyb“ nalezených klientem je zdarma opravit.
5. Technická dokumentace pro vývoj by měla být zpracována s ohledem na požadavky zákazníka.
   Důvod: Pro vývojáře je výhodné zcela se připoutat k zákazníkovi a často se stává, že dokumentace není udržována.
6. V případě tvorby webu musí zhotovitel vzít v úvahu SEO optimalizaci webu, konkrétně: popis obrázků, stránek…
   Důvod: úspora času na „maličkostech“, které v závislosti na podmínkách smlouvy mohou vést k finančním ztrátám pro zákazníka (vývojář softwaru šetří čas / finance).
7. Testování systému by měl zajistit vývojář systému.
   Převzetí hotového modulu zákazníkem by se nemělo změnit v testování systému, tzn. developer je povinen provést odstranění zjištěných „chyb“ klientem na vlastní náklady. To je nezbytné pro zajištění kvality testování produktu vývojářem. Ve chvíli, kdy vývojář řekne „hotovo“ a začne testování na straně klienta, jsou „chyby“ opraveny zdarma.
8. Odpovědnost za hostování projektu na straně zákazníka přebírá developer. Zákazník je v tomto případě povinen zajistit splnění technických požadavků na lokalitu.
   Důvod: hostování projektu na straně zákazníka může někdy způsobit určité potíže, které mohou vést k "kloboukování", takže odpovědnost za hostování a konfiguraci serveru by měla být na straně vývojáře softwaru.
9. Pokud je vývojář softwaru nucen uchýlit se k pomoci specialistů mimo svůj tým, je povinen vzít na sebe všechna související rizika úniku, ztráty dat nebo jakékoli jiné škody, kterou může svým jednáním či nečinností způsobit externí zaměstnanec.
   Důvod: stává se, že vývojář může onemocnět, skončit atd. jeden ze zaměstnanců. V tomto případě musí být zákazník pojištěn.
10. Záložní kopie projektu musí být poskytnuty na straně vývojáře alespoň jednou denně. Případné problémy se ztrátou dat na projektu by měl převzít vývojář.
    Důvod: zde je třeba uvést, kdo je odpovědný za bezpečnost projektu v případě jakýchkoli poruch.
11. Vývojář by měl při výběru vycházet z oblíbenosti používání technologií, které používá.
    Důvod: vazba na vlastní technologie, které zkomplikují život, pokud zákazník přejde k jinému developerovi.

Známé způsoby, jak nadhodnocovat náklady na outsourcing práce vzhledem k realitě.Předpokládám, že je jich více.

• Povrchní odhad nákladů na vývoj projektu jako celku, bez jeho rozdělení na etapy, což může vést k 2x-3x převýšení nákladů projektu.
• Neposkytnutí zpráv o provedené práci ve lhůtě stanovené smlouvou nebo nemožnost kontroly postupu vývoje ze strany klienta
• Špatná volba technologie při realizaci technické části může výrazně prodražit vývoj.
• Nedostatek správných specialistů ve vývojovém týmu, což zvyšuje čas a náklady na vývoj.
• Fixní náklady na vývoj projektu nebo modulu a další zvýšení nákladů na každou maličkost, kterou obě strany chápaly odlišně.
• Stanovení fixních nákladů na vývoj projektu – vyšší riziko vyžaduje zahrnutí do nákladů projektu.
• Při vývoji designu se nepoužívá prototypování a vývoj designu se provádí na základě textové technické specifikace, což v konečném důsledku vede k velkému počtu vylepšení / oprav, a tedy ke zvýšení nákladů na projekt.
• Přidávání / komplikování funkčnosti. Můžete si to usnadnit – ztížit.
• „Krásné“ tam, kde nejsou potřeba (můžete říci o admin. části webu, pokud můžete použít css frameworky pro rychlé přizpůsobení admin. částí - začínají se vyvíjet od nuly).

Vztahový vzor ‚zákazník – dodavatel vývoje softwaru‘, který má podle mého názoru nejblíže k praktickému využití.

Mnoho outsourcingových společností raději neposkytne přístup ke svým systémům řízení projektů bez poskytnutí podrobných informací, osobně se domnívám, že přístup by měl být poskytnut na žádost zákazníka. Klient je zodpovědný za realizaci projektu a je důležité vidět vývoj v reálném čase!
Také si myslím, že vyvíjet software s přihlédnutím k kalkulaci celkových nákladů na projekt je plýtvání penězi a nervy, takový vývoj většinou vede ke konfliktním situacím.

1. Platba za práci na základě hodinové mzdy za práci zaměstnanců nebo průměrné ceny práce specialisty celého vývojového týmu. Vyhodnocení vývojových fází je nutné. Proč si myslím, že tato forma ceny je optimální:
   • Nevyžaduje příliš pečlivý přístup při hodnocení projektů, jehož 100% přesnost je téměř nemožné. Pokud je posouzení provedeno nesprávně a vývojář softwaru to začne chápat, pak je funkce „narušována“ všude, kde je to možné, což v konečném důsledku ovlivní použitelnost.
   • Zlepšuje vzájemné porozumění mezi vývojářem softwaru a klientem, as hlavní úkol je redukován na zásadu – „dělejte to efektivně a rychle“ a ne „investujte do napjatého rozpočtu a jak to bude dobře fungovat“.
   • Klient na základě denních reportů o strávených hodinách vidí, kolik času zaměstnanci tráví na různých blocích během vývoje, což dává pochopení rychlosti a kvality práce zaměstnanců vývojářů softwaru.
   • Interakce mezi zákazníkem a projektovým manažerem probíhá maximálně přímo, tzn. při používání skype, telefonů atd.
2. Pouze 2-týdenní zprávy a plány musí být zaslány poštou (pro kontrolu).
3. Klient poskytne prototyp aplikace nebo jej vyvine tým vývoje softwaru, pokud je to nutné:
   • Zjednodušuje pochopení hlavních funkcí projektu.
   • Zvyšuje celkovou rychlost vývoje projektu.
   • Jasné požadavky na funkčnost jak zákazníka, tak vývojáře.
   • Jasné pochopení toho, kam se projekt posune.
4. Systém řízení projektů pro sledování průběhu projektu a možnost sledovat proces, vývojový čas strávený na každém úkolu zvlášť. Bohužel vývojáři zřídka poskytují přístup.
5. Je žádoucí, aby celý projekt dělal jeden tým, tzn. nemělo by to být tak, že jednu etapu dělá jedna společnost, druhou jiná a tak dále.
6. Kontrolní body („run“) každé 2 týdny jsou optimální dobou pro kontrolu projektu.
7. Při vývoji jsou upřednostňovány známé frameworky, a to i pro snazší přizpůsobení v případě jakékoliv situace, kdy je potřeba projekt převést na jiné vývojáře.
8. Testování kvality na straně vývojáře je přímou odpovědností. Při převodu projektu nebo některé jeho části klientovi je nutné vše důkladně zkontrolovat.
9. Podpora různých prohlížečů je přímým úkolem vývojáře

Závěr: hlavní věcí je dodržovat partnerské / oboustranně výhodné a důvěryhodné vztahy s tím, že vývojáři jsou stejní lidé a komplikování jejich života komplikuje život i vám! Každý by měl být zodpovědný za svou část práce, klient by měl být zodpovědný za poskytnutí jasné technické specifikace a promptně reagovat na vznikající dotazy, nezapomínat na zaplacení za práci a developer - za kvalitu, načasování, rychlost. Ideálu samozřejmě nebylo dosaženo, ale jsme na správné cestě.

Mám rád

V různých zdrojích literatury o prodeji lze nalézt různý počet fází prodeje. Každý autor je posuzuje ze svého úhlu pohledu.

Navrhuji zvážit klíčové fáze práce s klientem>:

Fáze 1 „Navázání kontaktu“ nebo „Navázání kontaktu“

Jakýkoli prodej začíná od této fáze.

Účel této etapy: zvítězit nad Klientem a zajímat ho o další kontakt.

Při navazování kontaktu s Klientem je důležité pozdravit ho a představit se.

"Dobré odpoledne. Jmenuji se Michail, jsem manažerem společnosti "Windows Plus".

Před zahájením rozhovoru o potřebách klienta se doporučuje promluvit si s ním na abstraktní téma (technika „Small Talk“) nebo nabídnout čaj, kávu, můžete složit kompliment nebo použít řadu dalších technik. fáze navázání kontaktu.

„Co víte o naší společnosti? Proč nás vybrat? Co plánujete koupit?

Je důležité, aby manažer svým neverbálním chováním projevoval zájem o kontakt s Klientem, chuť mu pomoci, dobrou vůli. Neverbální chování zahrnuje otevřená gesta, držení těla, úsměv, sklon těla ke klientovi, otevřený pohled.

Z chování Klienta lze určit, zda byl kontakt s Klientem navázán či nikoli. Pokud na slova manažera reaguje pozitivně, cítí se uvolněně, sám se ptá, můžeme předpokládat, že kontakt byl navázán. Pokud Klient neudržuje oční kontakt s manažerem, je napjatý, neodpovídá na otázky nebo odpovídá neochotně, pak má smysl věnovat více času fázi navazování kontaktu.

Fáze 2 "Identifikace potřeb"

Účel této etapy: určit potřeby Klienta.

Čím přesněji manažer určí potřeby klienta, tím efektivněji provede prezentaci zboží a služeb, která následně povede k obchodu.

Při identifikaci potřeb je důležité, aby manažer mohl klást otázky a naslouchat klientovi.

Při interakci s Klientem je důležité, aby více mluvil on a ne manažer, proto se manažerovi doporučuje nastavit více otevřené otázky.

Jaké okno si plánujete pořídit? Kde budete měnit okno? Jaké je klima v bytě v zimě a v létě? Kdo další bydlí v bytě? Na základě čeho vybíráte okno?

Uzavřené otázky manažer umožňuje specifikovat potřeby Klienta.

„Často větráte místnost? Máte zvířata? Vyhovuje vám, když náš měřič dorazí zítra v 9 hodin?

Alternativní otázky nabídnout klientovi výběr možností.

„Vyhovuje vám, aby měřič přišel ráno nebo odpoledne? Plánujeme tento nebo příští týden instalovat nová okna?“

Během celé schůzky s Klientem je užitečné mu pozorně naslouchat, protože Klienti často sami o svých potřebách mluví otevřeně. Pokud některá slova klienta nejsou manažerovi jasná nebo je poslouchal, je vhodné položit klientovi upřesňující otázky:

„Pochopil jsem správně, že potřebujete okno se zvýšenou zvukovou izolací? Pokud jsem pochopil, chcete, aby jedno křídlo okna bylo otočné a druhé sklopné a otočné?

Po každé probírané problematice je žádoucí shrnout mezivýsledek. Zejména pokud manažer s klientem projednává několik produktů nebo služeb.

„Dohodli jsme se tedy, že zítra budeme měřit a příští týden v pátek budeme instalovat okna. Plánujete tedy osazení dvou nových oken: do kuchyně dvoukřídlé okno s výklopně-kyvnými křídly a do pokoje tříkřídlé okno, ve kterém jsou dvě křídla výklopná a výklopná. jeden je „hluchý“.

Je důležité přesně identifikovat potřeby klienta a teprve poté provést prezentaci zboží a služeb.

Fáze 3 "Prezentace"

Cílová: nabízet produkt nebo službu, která nejlépe odpovídá potřebám klienta.

Prezentace produktů a služeb obsahuje popis vlastností zboží a služeb, výhody z jejich užívání klientem a výhody, které spotřebitel získává.

Prezentaci je užitečné začít klíčovými výhodami klienta, které vyplývají z potřeb kupujícího, identifikovaných manažerem v předchozí fázi.

Je důležité rozlišovat, jak se užitek produktu nebo služby liší od užitku.

Výhoda je výhoda, kterou každý zákazník získá používáním tohoto produktu nebo služby.

"S touto službou můžete ušetřit čas a snížit náklady o 10 %." "Toto kování umožňuje snížit počet úprav."

Výhoda je vlastnost nebo výhoda, která umožňuje uspokojit konkrétní potřebu Klienta.

Jakákoli vlastnost nebo výhoda se tak může stát přínosem, pokud to Klient potřebuje.

"Chtěli jste, aby se okno snadno otevíralo a zavíralo, kování evropské kvality to může poskytnout." "Říkal jste, že byt se nachází v přízemí a bojíte se o bezpečnost bytu, navrhuji, abyste na nová okna nainstalovali kování proti vloupání."

Během prezentace musí manažer zapojit klienta do aktivního dialogu pomocí otázek.

"Jak se vám líbí můj návrh?", "Co si o tom myslíte?", "Jak se vám líbí můj návrh?"

Fáze 4 „Práce s námitkami“

Cílová: rozptýlit pochybnosti Zákazníka o nákupu a odstranit negativa ve vztahu k produktu nebo službě.

Pro snížení počtu námitek Klienta je užitečné, aby manažer věnoval více času předchozím etapám. Často jsou námitky Klientů spojeny s tím, že kontakt s ním nebyl dobře navázán, jeho potřeby byly částečně identifikovány nebo prezentace zboží a služeb nebyla pro Klienta zajímavá, byla příliš dlouhá a neuspokojovala jeho potřeby.

Námitky Klienta je důležité vnímat jako signál, že manažer potřebuje korigovat své chování (zejména pokud je námitek hodně).

Námitky ze strany klienta mohou vzniknout i v předchozích fázích prodeje. Jak se vypořádat se vznikajícími námitkami?

Efektivně dodržujte schéma zpracování námitek:

1. naslouchat Klientovi;

2. neutralizovat jeho emoce pomocí frází porozumění;

"Chápu tě", "Ano, souhlasím, že je to nepříjemné ..."

3. v případě potřeby objasnit informace pomocí otázek;

4. nabídnout konstruktivní řešení nebo předložit alternativní návrh.

Existují 4 typy námitek zákazníků:

1. námitky související se změnami.

"Proč to potřebuji", "Nevidím v tom smysl"

Při řešení takové námitky musí manažer klientovi vysvětlit, že rizika jsou vyloučena, ukázat důsledky, pokud situace bude pokračovat, uvést příklady pozitivních zkušeností s prvním použitím něčeho.

„Zakoupením okna s evropským kováním máte zaručenou ochranu před průvanem, dodatečným nastavením přítlaku křídla, zablokováním zavíracího mechanismu.“

2. námitky související s cenou.

"Je to pro mě příliš drahé."

V argumentaci by měl manažer věnovat pozornost dalšímu zvýhodnění, které klient získává, můžete porovnat náklady na zboží s náklady na jakoukoli jinou ne příliš potřebnou věc nebo rozdělit náklady na určité časové období.

„Když si koupíte okno od naší společnosti, získáte jako dárek sadu pro péči o okna a také možnost využít bezplatnou úpravu kování“, „Krásné nové okno v kuchyni vás bude stát pouhých 300 rublů. ve dne".

3. námitky související s negativními zkušenostmi.

"Slyšel jsem, že máš špatný profil."

Pro manažera je užitečné upřesnit informace kladením otázek Klientovi, ukázat Klientovi, že mu rozumíte a uznat fakta o nepříjemných událostech (pokud byly ve skutečnosti) a následně nabídnout náhradní řešení.

„Ano, měli jsme šarži vadného profilu, kterou jsme vrátili dodavateli. V tuto chvíli jsme obdrželi novou šarži, vyrobili a namontovali již více než 30 oken, všichni klienti jsou spokojeni.“

4. námitky související s rozhodnutím.

"Musím přemýšlet", "Musím se poradit se svou ženou."

Při řešení takových námitek si manažer může znovu ujasnit, s čím takové rozhodnutí souvisí, ujistit se, že klient všechny informace přijal a pochopil, a také použít způsoby dokončení transakce.

"Pokud s vámi nyní podepíšeme smlouvu, pak na konci týdne budete moci obdivovat nové okno v kuchyni." "Pouze do konce měsíce máme slevu na tento produkt."

Fáze 5 "Dokončení transakce"

Cílová: tlačit Klienta k transakci a potvrdit správnost jím učiněného rozhodnutí.

Před dokončením obchodu (podpisem smlouvy) se manažer musí ujistit, že je klient připraven uzavřít obchod.

To lze vidět ze signálů, které ukazuje:

• pozitivní zpětná vazba na produkt nebo službu;
• Klient vyjadřuje souhlas se slovy manažera (souhlasí, kývá hlavou apod.);
• přímo říká, že souhlasí;
• klade upřesňující otázky.

Způsoby dokončení obchodu:

1. metoda omezujících podmínek a času.

"Pokud smlouvu podepíšete dnes, dáme vám 20% slevu na okno."

2. metoda komplimentu.

"Opravdu jste se rozhodl správně."

3. win-win alternativa.

"Budete objednaní na měření v úterý nebo ve středu?"

Na závěr bych chtěl říci, že efektivita prodeje závisí na šikovnosti manažerů. Čím více metod a prodejních technik manažer má, tím flexibilnější a úspěšnější je při interakci s klientem. Profese obchodního manažera vyžaduje neustálý rozvoj a sebezdokonalování dovedností. Přejeme Vám úspěch na cestě profesního růstu a zvýšení prodeje.